4. Data encryption and key and secret management
Introduction
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 are performed by 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 the KMS service and its integration with other Yandex Cloud services or implement data plane encryption completely on your own.
Yandex Cloud provides data-at-rest encryption for the following services:
- Object Storage
- Managed Service for Kubernetes
4.1 In Yandex Object Storage, encryption of data at rest using KMS keys is enabled
To protect critical data in Yandex Object Storage, we recommend using bucket server-side encryption with Yandex 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 the Object Storage documentation.
- In the management console, select the cloud or folder to check the buckets in.
- In the list of services, select Object Storage.
- Go to the bucket settings.
- Go to the Encryption tab.
- Make sure that encryption is enabled and the KMS encryption key is specified.
- If encryption is enabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
Configure the AWS CLI to work with a cloud.
-
Run the command below to check whether encryption is enabled:
aws --endpoint-url=https://storage.yandexcloud.net/ \ s3api get-bucket-encryption \ --bucket <bucket_name>
-
If encryption is enabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Configure bucket encryption using the guide.
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 in the service settings: HTTP or HTTPS, and specify their own TLS certificate if HTTPS is selected.
Note
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:
- Object Storage
- Application Load Balancer
- API Gateway
- Cloud CDN
4.2 HTTPS is enabled for hosting static websites in Yandex Object Storage
Object Storage supports secure connections over HTTPS. You can upload your own security certificate if a connection to your Object Storage website requires HTTPS access. Integration with Certificate Manager is also supported. See the instructions in the Object Storage documentation:
When using Object Storage, make sure that support for TLS protocols below version 1.2 is disabled at the client level. Use the aws:securetransport
bucket policy to make sure running without TLS is disabled for the bucket.
- In the management console, select the cloud or folder to check the buckets in.
- In the list of services, select Object Storage.
- Go to the bucket settings.
- Go to the HTTPS tab.
- Make sure that access over the protocol is enabled and a certificate is specified.
- If access over HTTPS is enabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Enable access over HTTPS if a bucket is used for hosting a static website.
4.3 Yandex Application Load Balancer uses HTTPS
Application Load Balancer supports an HTTPS listener with a certificate uploaded from Certificate Manager. For information on how to set up the listener, see the Yandex Application Load Balancer documentation.
- In the management console, select the cloud or folder to check the load balancers in.
- In the list of services, select Application Load Balancer.
- Go to the load balancer settings.
- Make sure that HTTPS is specified for the load balancer.
- If HTTPS is specified, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to output the list of all load balancers without HTTPS:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for ALB in $(yc application-load-balancer load-balancer list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc application-load-balancer load-balancer get --id $ALB --format json | jq -r '. | select(.listeners[0].tls | not)' | jq -r '.id' done; done; done
-
If an empty list is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Enable an HTTPS listener using the instructions.
4.4 Yandex API Gateway uses HTTPS and its own domain
API Gateway supports secure connections over HTTPS. You can link your own domain and upload your own security certificate to access your API gateway over HTTPS.
- In the management console, select the cloud or folder to check the gateways in.
- In the list of services, select API Gateway → Gateway settings → Domains.
- Make sure the domain and certificate are enabled.
- If the domain and certificate are active, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to output the list of all API gateways without any domains and certificates enabled:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for APIGW in $(yc serverless api-gateway list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc serverless api-gateway get --id $APIGW --format json | jq -r '. | select(.attached_domains[0].certificate_id | not)' | jq -r '.id' done; done; done
-
If an empty list is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
- In the management console, select the cloud or folder to enable domains and certificates in.
- In the list of services, select API Gateway → Gateway settings → Domains.
- Enable the domains and certificates.
4.5 Yandex Cloud CDN uses HTTPS and its own SSL certificate
Cloud CDN supports secure connections to origins over HTTPS. You can also upload your own security certificate to access your CDN resource over HTTPS.
- In the management console, select the cloud or folder to check the resources in.
- In the list of services, select Cloud CDN.
- Go to the resource settings, the Additional tab.
- Make sure the Origin request protocol field is set to HTTPS.
- Make sure the Certificate field specifies your own certificate or a Let’s encrypt certificate.
- If HTTPS and your own certificate are specified, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to output the list of all resources without any certificates and HTTPS to origins enabled:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for CDN in $(yc cdn resource list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc cdn resource get --id $CDN --format json | jq -r '. | select(.origin_protocol=="HTTPS" and .ssl_certificate.type=="CM" | not)' | jq -r '.id' done; done; done
-
If an empty list is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Enable a certificate and HTTPS using the instructions.
Providing encryption on your own
When using services without built-in encryption, it is the customer's responsibility to ensure that critical data is encrypted.
4.6 For critical data, MDB encryption with KMS is used
If data encryption is required, make sure to encrypt data at the application level prior to writing it to a database, for example, using KMS and an add-on, such as pgcrypto
.
Make sure that the stored data is encrypted.
To get a list of all extensions set in a database, run this command:
yc managed-postgresql database get <database_name> --cluster-id <managed_postgre_cluster_id> --format=json | jq -r '.extensions | .[].name'
If the command output contains the pgcrypto
string, the database has an extension for application-level data encryption enabled.
Guides and solutions to use:
See Using pgcrypto in Managed Service for Greenplum® for instructions on how to encrypt data in Yandex Managed Service for PostgreSQL and Yandex Managed Service for Greenplum® using pgcrypto
.
4.7 Data encryption at the application level is used
For client-side encryption before uploading data to a Yandex Object Storage bucket, you can use the following approaches:
- Integrating Object Storage with the Key Management Service 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.
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?.
Make sure that the stored data is encrypted.
4.8 Encryption of disks and virtual machine snapshots is used
By default, all data on Yandex Compute Cloud disks is encrypted at the storage database level using a system key. This protects your data from being compromised in the event of a physical theft of disks from Yandex Cloud data centers.
We also recommend encrypting disks and disk snapshots using Yandex Key Management Service custom symmetric keys. This approach allows you to:
- Protect against the potential threats of data isolation breach and compromise at the virtual infrastructure level.
- Control the encryption and lifecycle of KMS keys, as well as manage them. For more information, see Key management.
- Improve access control to the data on your disk by setting permissions for KMS keys. For more information, see Configuring access permissions for a symmetric encryption key.
- Use Yandex Audit Trails to track encryption and decryption operations performed using your KMS key. For more information, see Key usage audit.
You can encrypt the following types of disks:
- Network SSD (
network-ssd
) - Network HDD (
network-hdd
) - Non-replicated SSD (
network-ssd-nonreplicated
) - Ultra high-speed network storage with three replicas (SSD) (
network-ssd-io-m3
)
When creating a disk, make sure to enable Encrypted disk.
Guides and solutions to use:
Encrypt the disk of your Yandex Compute Cloud VM.
Managing keys
We recommend using Key Management Service for data encryption and key management. Made to protect data in the Yandex Cloud infrastructure, KMS can also encrypt and decrypt any of your data.
KMS uses AES-GCM encryption mode. You can select the key length: 128/192/256 and set up the preferred key rotation period.
4.9 Key Management Service keys are stored in a hardware security module (HSM)
In production environments, we recommend using separate keys whose every cryptographic operation will only be handled inside a HSM. For more information, see Hardware security module (HSM).
To use the HSM, when creating a key, select AES-256 HSM as the algorithm type. The HSM will handle all operations with this key internally, and no additional actions are required.
We recommend using HSMs for KMS keys to enhance the security level.
- In the management console, select the cloud or folder to check the keys in.
- In the list of services, select Key Management Service.
- Go to the Keys tab.
- Make sure the Encryption algorithm field is set to AES-256 HSM.
- If AES-256 HSM is specified, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to output the list of all of your organization's KMS keys and their encryption algorithms:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do yc kms symmetric-key list --folder-id=$FOLDER_ID --format json | jq -r '.[] | "KEY_ID " + .id + "FOLDER_ID " + .folder_id + "ALGORITM_ID " + .default_algorithm' done; done
-
If the encryption algorithm contains AES-256 HSM, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Set the encryption algorithm for KMS keys to AES-256 HSM.
4.10 Permissions to manage keys in KMS are granted to controlled users
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 granular permissions for specific keys in the KMS service to your users and service accounts. 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.
To check the KMS key access permissions, check who has access permissions for:
- Organization, cloud, or folder (such permissions as
admin
,editor
,kms.admin
,kms.editor
, orkms.keys.encrypterDecrypter
) - Keys (
kms.keys.encrypterDecrypter
andkms.editor
)
- In the management console, select the cloud or folder to check the key access permissions in.
- Click the Access permissions tab.
- Make sure the
admin
,editor
,kms.admin
,kms.editor
, andkms.keys.encrypterDecrypter
roles are only granted to controlled users. - You can check the actual key access permissions only via the CLI.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for accounts at the organization level:
export ORG_ID=<organization ID> yc organization-manager organization list-access-bindings --id=${ORG_ID} --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="editor" or .role_id=="kms.admin" or .role_id=="kms.editor" or .role_id=="kms.keys.encrypterDecrypter")'
-
If there are no accounts in the list, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
Find accounts with roles assigned at the cloud level:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="editor" or .role_id=="kms.admin" or .role_id=="kms.editor" or .role_id=="kms.keys.encrypterDecrypter")' done
-
If there are no accounts in the list, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
Run the command below to search for accounts with primitive roles assigned at the level of all folders in your clouds:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); \ do yc resource-manager folder list-access-bindings --id=$FOLDER_ID --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="editor" or .role_id=="kms.admin" or .role_id=="kms.editor" or .role_id=="kms.keys.encrypterDecrypter")' && echo $FOLDER_ID done; done
-
If there are no accounts in the list, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
Find accounts with roles assigned at the key level:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for KEY in $(yc kms symmetric-key list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc kms symmetric-key list-access-bindings --id $KEY --format json done; done; done
Guides and solutions to use:
Check out who is granted access to KMS keys.
4.11 For KMS keys, rotation is enabled
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, such as Message Queue or Cloud Functions.
- Keys for services that store critical data, e.g., Managed Services for Databases.
For the first group, we recommend that you set up automatic key rotation with a rotation period 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
Note
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.
- In the management console, select the cloud or folder to check the keys in.
- In the list of services, select Key Management Service.
- Go to the key settings.
- Find the Rotation period parameter.
- If the parameter is set to any value different from No rotation, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to output the list of all of your organization's KMS keys and their encryption algorithms:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do yc kms symmetric-key list --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(.rotation_period | not)' | jq -r '.id' done; done
-
If an empty list is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Set the key rotation period.
4.12 The deletion protection is enabled for KMS keys
Deleting a KMS key always means destroying data. Therefore, make sure to protect the keys against accidental deletion. KMS has the necessary feature.
- In the management console, select the cloud or folder to check the keys in.
- In the list of services, select Key Management Service.
- Go to the key settings.
- Find the Deletion protection parameter.
- If it is set to Yes, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to output the list of all KMS keys without protection against deletion:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do yc kms symmetric-key list --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(.deletion_protection | not)' | jq -r '.id' done; done
-
If an empty list is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Enable deletion protection.
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 Lockbox or HashiCorp Vault.
4.13 The organization uses Yandex Lockbox for secure secret storage
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 Lockbox or HashiCorp Vault (from Cloud Marketplace).
Lockbox securely stores secrets in an encrypted form only. Encryption is performed using KMS. For secret access control, use service roles.
You can learn how to use the service in the Lockbox documentation.
Vault
To store secrets with Vault, you can use a VM based on an image from Cloud Marketplace with a pre-installed HashiCorp Vault build and Auto Unseal support. You can find the guide on setting up Auto Unseal in the KMS documentation, Auto Unseal in Hashicorp Vault.
Note
When working in Terraform, we recommend using a script to fill in.tfstate
file.
- In the management console, select the cloud or folder to check the secrets in.
- In the list of services, select Lockbox.
- Make sure that at least one Lockbox secret is used.
- Find the Deletion protection parameter.
- If Lockbox is used or Kubernetes VMs or entities have Hashicorp Vault installed, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for at least one Lockbox secret:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do yc lockbox secret list --folder-id=$FOLDER_ID --format=json done; done
-
If an empty list is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Store secrets in Lockbox or Hashicorp Vault from Marketplace.
4.14 For Serverless Containers and Cloud Functions, Lockbox secrets are used
When working with Serverless Containers or Cloud Functions, it is often necessary to use a secret (such as a token or password).
If you specify secret information in environment variables, it can be viewed by any cloud user with permissions to view and use a function, which causes information security risks.
We recommend using Serverless integration with Lockbox for that. You can use a specific secret from Yandex Lockbox and a service account with access rights to this secret to use it in a function or container.
Make sure that the secrets are used as described above.
- In the management console, select the cloud or folder to check the functions in.
- In the list of services, select Cloud Functions.
- Go to the function settings, the Editor tab.
- Find the Lockbox secrets parameter.
- If the parameters of each object specify Lockbox secrets or there are no environment variables with secret data, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
Run the command below to search for all the cloud functions that use no Lockbox secrets and make sure that these functions use no secret data in environment variables:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for VER in $(yc serverless function version list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc serverless function version get $VER --format=json | jq -r '. | select(.secrets | not)' | jq -r '.id' done; done; done
-
If an empty list is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Delete the secret data from env and use the Lockbox integration functionality.
4.15 When working with Container Optimized Image, secret encryption is used
KMS supports the encryption of secrets used in a Terraform configuration, e.g., for transferring secrets to a VM in encrypted form. See Encrypting secrets in Hashicorp Terraform in the KMS documentation. It is not safe to openly provide secrets through environment variables, because they are displayed in the VM properties.
Guides and solutions to use:
Encrypting secrets in Terraform to transfer them to a VM from a Container Optimized Image
For other recommendations on how to use Terraform safely, see Secure configuration: Terraform.
4.16 There is a guide for cloud administrators on handling compromised secrets
In Yandex Cloud, the Secret Scanning Service is enabled for everyone by default.
It detects structured cloud secrets that are available in the public domain in the following sources:
- Public GitHub repositories
- Yandex search index
- Helm charts in the Kubernetes marketplace
The following cloud secrets are detected:
- Yandex Cloud Session Cookie
- Yandex Cloud IAM token
- Yandex Cloud API Key
- Yandex Passport OAuth token
- Yandex Cloud AWS API compatible Access Secret
- (NEW) Yandex Cloud SmartCaptcha Server Key
- (NEW) Lockbox structured secrets
The service automatically notifies a customer of any found secrets belonging to their infrastructure:
- By email
- Using Yandex Audit Trails events
Guides and solutions to use:
Make sure that:
- Contact information of the person in charge of an organization is valid.
- Yandex Audit Trails is enabled at the organization level.
- The administrator has read the guide to follow if secrets are compromised.