Data encryption and key management
Yandex Cloud provides built-in encryption features for a number of services. It is the customer's responsibility to enable encryption in these services and implement encryption in other components for processing critical data. Data encryption and encryption key management is done by Yandex Key Management Service (KMS).
Yandex Cloud APIs support cipher suites in specific TLS versions that are compliant with PCI DSS and other standards.
Encryption at rest
By default, all user data at rest is encrypted at the Yandex Cloud level. Encryption at the Yandex Cloud level implements one of the best practices for protecting user data and is performed using Yandex Cloud keys.
If your corporate information security policy sets specific key size and rotation frequency requirements, you can encrypt data with your own keys. To do this, you can use KMS and its integration with other Yandex Cloud services or implement data plane encryption all by yourself.
Yandex Cloud provides data-at-rest encryption for the following services:
Compute Cloud
To protect critical data in Compute Cloud, we recommend encrypting disks and disk snapshots with Key Management Service keys.
For more information, see Encryption in Compute Cloud.
Object Storage
To protect critical data in Object Storage, we recommend using bucket server-side encryption with Key Management Service keys. This encryption method protects against accidental or intentional publication of the bucket content on the web.
For more information, see Encryption in Object Storage.
Managed Service for Kubernetes
Managed Service for Kubernetes has a built-in secret encryption mechanism. For more information, see Secrets in Kubernetes below.
Encryption in transit
In most cases, you can only connect to Yandex Cloud services over HTTPS. However, some scenarios allow data plane access to services over HTTP, without connection encryption at the application level. In all these scenarios, the user can choose the protocol to be used for data plane operations (HTTP or HTTPS) in the service settings, and specify their own TLS certificate if HTTPS is selected.
Warning
When working with (or connecting to) Yandex Cloud APIs, make sure to use TLS 1.2 or higher, since its prior versions are vulnerable. For example, by using the gRPC interfaces of Yandex Cloud, you can enforce TLS 1.2 or higher. That's because gRPC is based on HTTP/2 where TLS 1.2 is the minimum supported TLS version. Support for legacy TLS protocols in Yandex Cloud services will gradually be discontinued.
Yandex Cloud allows you to use your own TLS certificates for the following services:
- Yandex Object Storage
- Yandex Application Load Balancer
- Yandex Virtual Private Cloud (VPC)
- Yandex API Gateway
- Yandex Cloud CDN
Object Storage
Object Storage supports secure connections over HTTPS. You can upload your own security certificate if a connection to your Object Storage site requires HTTPS access. Additionally, you can use integration with Yandex Certificate Manager. See the instructions in the Object Storage documentation:
When using Object Storage, be sure that support for TLS protocols below version 1.2 is disabled at the client level. Use the bucket policy aws:securetransport to ensure that running without TLS is disabled for the bucket.
Application Load Balancer
Application Load Balancer supports an HTTPS listener with a certificate uploaded from Certificate Manager. See how to set up the listener in the Application Load Balancer documentation.
Virtual Private Cloud (VPC)
You can find viable options for using encrypted communication channels in Setting up remote access and communication channels.
Please note: Yandex Cloud Interconnect does not provide built-in encryption mechanisms. Be sure to enable encryption in transit on your own by:
- Deploying encrypted VPN gateways in the cloud, such as VMs running Check Point images from Yandex Cloud Marketplace.
- Using application-level encryption.
- Using GOST VPN.
API Gateway
Yandex API Gateway supports secure connections over HTTPS. You can upload your own security certificate to access your API gateway over HTTPS.
Cloud CDN
Cloud CDN supports secure connections over HTTPS. You can upload your own security certificate to access your CDN resource over HTTPS.
Providing encryption on your own
When using services with no built-in encryption, it's the customer's responsibility to ensure that critical data is encrypted.
Managed Services for Databases
If data encryption is mandatory under regulatory requirements, make sure to encrypt data at the application level prior to writing it to a database, for example, using KMS.
Yandex Message Queue
If you use Yandex Message Queue to transfer critical data or secrets (encryption keys, API keys, and so on), be sure to encrypt this data at the application level before you send it to Message Queue, for example, using KMS. For the KMS key, we recommend that you set up a rotation period greater than or equal to the maximum message processing time in Message Queue.
Yandex Object Storage
For client-side encryption before uploading data to a Yandex Object Storage bucket, you can use the following approaches:
- Integrating Object Storage with Key Management Service for client-side encryption. For more information, see Recommended cryptographic libraries.
- Using third-party client-side encryption libraries prior to sending data to Object Storage. If you use third-party data encryption libraries and your own key management methods, make sure your operation model, algorithms, and key sizes comply with regulatory requirements.
Recommended cryptographic libraries
For client-side encryption, we recommend that you use the following libraries:
- AWS Encryption SDK and its KMS integration.
- Google Tink and its KMS integration.
- Yandex Cloud SDK with any other cryptographic library compatible with PCI DSS or any standards used in your company.
For a comparison of libraries, see the KMS documentation, Which encryption method should I choose?.
Managing keys
We recommend that you use Yandex Key Management Service for encrypting data and managing keys. KMS helps you protect data in the Yandex Cloud infrastructure. You can also use it to encrypt or decrypt any of your data.
KMS uses AES-GCM encryption mode. You can select the key length (128, 192, or 256 bits) and set up the preferred key rotation period. You can also create a key whose every cryptographic operation will only be handled inside a hardware security module (HSM). For more information, see Hardware security module (HSM).
Authentication and authorization in KMS
To access the KMS service, you need an IAM token.
To automate operations with KMS, we recommend that you create a service account and run commands and scripts under it. If you use VMs, get an IAM token for your service account using the mechanism of assigning a service account to your VM. For other ways to get an IAM token for your service account, see the IAM documentation, Getting an IAM token for a service account.
We recommend that you grant your users and service accounts granular permissions for specific keys in the KMS service. For more information, see the KMS documentation, Access management in Key Management Service.
For more information about security measures for access control, see Authentication and access control.
Key rotation
To improve the security of your infrastructure, we recommend that you categorize your encryption keys into two groups:
- Keys for services that process critical data but do not store it. For example, Yandex Message Queue,Yandex Cloud Functions.
- Keys for services that store critical data. For example, Managed Services for Databases.
For the first group of keys, we recommend that you set up automatic key rotation with a rotation period slightly longer than the data processing period in these services. When the rotation period expires, the old key versions must be deleted. In the case of automatic rotation and the deletion of old key versions, previously processed data cannot be restored and decrypted.
For data storage services, we recommend that you either manually rotate keys or use automatic key rotation, depending on your internal procedures for processing critical data.
A secure value for AES-GCM mode is encryption using 4294967296 (= 232) blocks. Having reached this number of encrypted blocks, you need to create a new DEK version. For more information about the AES-GCM operating mode, see the NIST materials
Alert
Destroying any version of a key means destroying all data encrypted with it. You can protect a key against deletion by setting the deletionProtection parameter. However, it does not protect against deleting individual versions.
For more information about key rotation, see the KMS documentation, Key version.
Managing secrets
Do not use critical data and access secrets, such as authentication tokens, API keys, and encryption keys, explicitly in the code, cloud object names and descriptions, VM metadata, etc. Instead, use secret storage services, such as Yandex Lockbox or HashiCorp Vault.
Yandex Lockbox
Yandex Lockbox securely stores secrets: they are only stored in encrypted form with encryption performed using KMS. For secret access control, use service roles.
To learn how to use the service, see the Lockbox documentation.
HashiCorp Vault
Vault
To store secrets with Vault, you can use a VM based on an image from Yandex Cloud Marketplace with a pre-installed HashiCorp Vault build and Auto Unseal support. To learn how to set up Auto Unseal, see the Auto Unseal in Hashicorp Vault section in the KMS documentation.
Secrets in Kubernetes
To store secrets, such as passwords, OAuth tokens, and SSH keys, use one of the following methods:
-
How Kubernetes secrets
work.By default, secrets are stored unencrypted in etcd. However, Managed Service for Kubernetes allows you to encrypt secrets using KMS. To enable the encryption of secrets, specify a KMS key when creating a Kubernetes cluster. You cannot add the key when you edit the cluster. For more information, see Encrypting secrets in Yandex Managed Service for Kubernetes in the KMS documentation.
-
Yandex Lockbox.
See the instructions in the Yandex Lockbox documentation, Syncing with Yandex Managed Service for Kubernetes secrets.
-
HashiCorp Vault with KMS support from Yandex Cloud Marketplace.
Transferring secrets to a VM using Terraform and KMS
KMS supports the encryption of secrets used in a Terraform configuration, such as to transfer secrets to a VM in encrypted form. See the instructions in the KMS documentation, Encrypting secrets in Hashicorp Terraform. It is not safe to explicitly pass secrets through environment variables, because they are displayed in the VM properties.
For other recommendations on how to use Terraform safely, see Secure configuration: Terraform.