Key management
VA.gov systems may process sensitive information that must be protected from unauthorized parties. We utilize cryptography to protect this information and associated secrets. This document outlines guidelines and general practices for managing cryptographic keys and access credentials for protected systems.
Access to all systems must be made over encrypted channels.
Sensitive information must be encrypted at rest.
Sensitive information must not be communicated over public channels.
Exchanging information over a public channel
Sensitive information should never be exchanged in plain text over a public channel. Utilize the VA's email-based encryption when possible. Temporary keys and tokens may be transmitted via Keybase. Before transmission, personal information must be encrypted with GPG and sent only to verified parties. Lync File Transfer may be used to transmit sensitive information, but secrets should never be sent via Lync messages.
Password/Authentication resets
Voice verification must accompany a written request for a password/authentication reset.
Portable devices
Access to VA.gov information systems must only occur through approved portable devices utilizing previously approved cryptographic technology. Report of lost or stolen devices should occur as soon as possible so keys may be revoked.
System level
Amazon Web Services
Engineers may be provided access to the Amazon Web Services web dashboard. They may also receive an access key that permits access to the Amazon Web Services API. Multi-factor authentication is required for all user accounts.
Credentials must be stored securely on an encrypted drive. Access keys must utilize restricted permissions that permit only single-user access.
KMS
Cryptographic keys should be managed by Amazon's KMS when possible. This provides auditing, oversight, and management capabilities to VA.gov Platform personnel.
PostgreSQL
VA.gov's application database, which may contain sensitive information, is encrypted at rest with Amazon's KMS-based RDS encryption (AES-256).
Unless there are explicitly defined reasons otherwise, future RDS databases should be encrypted with KMS by default.
Redis/Memcached
Redis and Memcached instances, provided by AWS Elasticache, do not support automatic encryption. Applications must encrypt sensitive information before transmission into either of these systems.
EBS
Sensitive information is not currently stored on EBS volumes. Future EBS volumes should be encrypted by default with Amazon KMS.
S3
S3 buckets for internal use should encrypt content with Amazon S3-Managed Keys or Amazon KMS-Managed Keys (AES-256).
SSH Keys
A 2048-bit RSA key should be provided at a minimum, while a 4096-bit RSA key is recommended. Private keys must be password protected. Public keys should be provided to the Dev Ops team and archived in configuration management.
Associated private keys must never be transmitted over a public channel. If there is reason to believe a key has been compromised, the Platform Tech Support Team should be notified immediately so the key can be revoked. Private keys stored on portable devices must utilize restricted permissions that permit only single-user access.
SSL Certificates
SSL certificates encrypt web traffic to the Platform, across the broader VA network, and with third-party service providers. Application-specific, client-side certificates are needed to integrate with various services, using a certificate for each environment.
Public-facing web pages and APIs use a commercially provided SSL certificate (SSLMate).
External Integrations - such as communication with VA services or external third parties - use certificates provided by the VA PKI team (Venafi).
Note: These certificates are managed by Platform personnel.
For more information, see https://depo-platform-documentation.scrollhelp.site/developer-docs/external-service-integrations
Client-side authentication should be negotiated by the VA.gov forward proxy. Keys should not be made directly available to the application.
Internal communication with the VA.gov forward proxy utilizes a self-signed SSL certificate.
Application level
Secrets must not be stored in an application’s source code. Applications retrieve protected keys and secrets during the deployment process. These keys will be encrypted and secured in AWS Parameter Store (KMS-backed).
The application should keep protected information and keys in memory and not on disk. Sensitive information should be protected by user accounts and permissions on the underlying system when disk storage is required. The underlying disk should be encrypted.
Where possible, the application should delegate authentication and secret management to an isolated internal system (such as the forward proxy).
Documentation should be provided for each key to permit regeneration in the event of a compromise.
Help and feedback
Get help from the Platform Support Team in Slack.
Submit a feature idea to the Platform.