Secure configuration
This section provides recommendations to customers on security settings in Yandex Cloud services and the use of additional data protection tools.
Default passwords
Yandex Cloud services do not have default credentials. In each service, the client specifically assigns user passwords and other secrets. However, software managed by the client that is installed on virtual machines or inside containers may contain initial credentials that should be changed (for example, the login admin
with the password admin
).
To automatically verify credentials, we recommend using paid security scanners or the following free tools:
Managing infrastructure
In IaaS services, the customer is responsible for the configuration of their resources.
To check your host compliance with the security standards and best practices, we recommend using the free utility OpenSCAP
Serial console
Access to the serial console is disabled on VMs by default. We do not recommend enabling it for security reasons. The risks of using the serial console are listed in the Yandex Compute Cloud documentation, Getting started with the serial console.
When working with a serial console:
- Make sure that critical data is not output to the serial console.
- If you enable SSH access to the serial console, make sure that both the credentials management and the password used for logging in to the operating system locally are compliant with regulator standards. For example, in an infrastructure for storing payment card data, a password must meet PCI DSS requirements: it must contain both letters and numbers, be at least 7 characters long, and be changed at least once every 90 days.
Note
According to the PCI DSS standard, access to VMs via a serial console is considered "non-console" access, and Yandex Cloud uses TLS encryption for it.
Preparing VM images
When deploying a VM instance, we recommend you to:
- Prepare a VM image whose system settings correspond to your information security policy. You can create an image using Packer. See Getting started with Packer.
- Use this image to create a VM or instance group.
- Look up the VM details to check that this image was actually used to create the disk.
Terraform
With Terraform, you can manage a cloud infrastructure using configuration files. If you change the files, Terraform will automatically detect which part of your configuration is already deployed, and what should be added or removed. For more information, see Getting started with Terraform.
We do not recommend using private information in Terraform configuration files, such as passwords, secrets, personal data, or payment system data. Instead, you should use services for storing and using secrets in the configuration file, such as HashiCorp Vault from Yandex Cloud Marketplace or Yandex Lockbox (to transfer secrets to the target object without using Terraform).
If you still need to enter private information in the configuration, you should take the following security measures:
-
Use sensitive = true
for private information to exclude it from the console output ofterraform plan
andterraform apply
. -
Use terraform remote state
. We recommend uploading a Terraform state to Yandex Object Storage (see Uploading Terraform states to Object Storage) and setting up configuration locking using Yandex Managed Service for YDB to prevent simultaneous editing by administrators (see a setup example ). -
Use the mechanism for transferring secrets to Terraform via env
instead of plain text or use built-in Yandex Key Management Service features for encrypting data in Terraform (using a separate file with private data) (learn more about this technique ).For more information about Object Storage security, see Object Storage below.
Warning
When a configuration is deployed, you can delete the configuration file with private data.
Scan your Terraform manifests using Checkov
Integrity control
Numerous information security standards require integrity control of critical files. To do this, you can use free host-based solutions:
In Cloud Marketplace, paid solutions are also available, such as CloudGuard.
Side-channel attacks
To ensure the best protection against CPU side-channel attacks (for example, Spectre or Meltdown):
- Use full-core VMs (that is, VMs with the CPU share of 100%).
- Use VMs with an even number of cores (2 cores, 4 cores, and so on).
- Make sure to install such updates for the OS and kernel that are protected from side-channel attacks (for example, Kernel page-table isolation for Linux
, applications built with Retpoline ).
We recommend that you use dedicated hosts for the most security-critical resources.
Learn more
Object Storage
Data encryption
When using Object Storage, set up encryption for critical data at rest and in transit. Object Storage provides built-in encryption. For more information, see Data encryption and key management.
Access restriction
We recommend assigning minimum roles to a bucket using Yandex Identity and Access Management, then making them broader or more specific using BucketPolicy (for example, to restrict access to the bucket by IP addresses, grant granular rights to objects, and so on).
Access to Object Storage resources is verified at three levels:
Verification procedure:
- If a request passes the Identity and Access Management check, the next step is the bucket policy check.
- Bucket policy rules are checked in the following order:
- If the request meets at least one of the
Deny
rules, access is denied. - If the request meets at least one of the
Allow
rules, access is allowed. - If the request does not meet any of the rules, access is denied.
- If the request meets at least one of the
- If the request fails the Identity and Access Management or bucket policy check, access verification is performed based on an object's ACL.
In the Identity and Access Management service, a bucket inherits the same access rights as those of the folder and cloud where it's located. For more information, see Inheritance of bucket access rights by Yandex Cloud system groups. For this reason, we do not recommend assigning roles for entire folders in Object Storage. We recommend that you only assign the minimum required roles to certain buckets or objects in Object Storage.
Bucket policies are used for additional data protection, for example, to restrict access to a bucket by IP addresses, grant granular rights to objects, and so on.
With ACLs, you can grant access to an object bypassing Identity and Access Management verification and bucket policies. We recommend setting strict ACLs for buckets.
Deletion protection and version backups
When processing critical data in buckets, you must ensure that data is protected from deletion and that versions are backed up. This can be achieved by versioning and lifecycle management mechanisms.
Bucket versioning is the ability to store the history of object versions. Each version is a complete copy of an object and occupies space in Object Storage. Using version control protects your data from both unintentional user actions and application faults.
If you delete/modify an object with versioning enabled, a new version of the object with a new ID is effectively created. In the case of deletion, the object becomes unreadable, but its version is kept and can be restored.
For more information about setting up versioning, see the Object Storage documentation, Bucket versioning.
The lifecycle management mechanism allows you to set a policy for deleting or moving data, for example:
- Delete all non-current versions of objects (condition type: NoncurrentVersionExpiration) on expiry of a certain number of days since the version became non-current.
- Delete all current versions of objects (condition type: Expiration) on expiry of a certain number of days since they were uploaded.
For more information about lifecycles, see the Object Storage documentation, Object lifecycles and Bucket object lifecycle configuration.
The storage period of critical data in a bucket is determined by the client's information security requirements and information security standards. For example, the PCI DSS standard states that audit logs should be stored for at least one year and should be readily available online for at least three months.
Audits
When using Object Storage to store critical data, be sure to enable logging of actions with buckets and configure the versioning mechanism and lifecycle for objects with logs. For more information, see Logging actions with a bucket in the Object Storage documentation.
You can also analyze Object Storage logs in Yandex DataLens.
Cross-Origin Resource Sharing (CORS)
If cross-domain requests to bucket objects are required, the client should configure the CORS (cross-origin resource sharing) policy in accordance with the client's information security requirements. For more information, see CORS configuration of buckets in the Object Storage documentation.
Managed Services for Databases
We recommend prohibiting internet access to databases that contain critical data, in particular PCI DSS data or private data. Configure security groups to only allow connections to the DBMS from specific IP addresses. See the instructions in Create a security group. You can specify a security group in the cluster settings or when creating the cluster in the network settings section.
Do not enable access to databases containing critical data from the management console, DataLens, or other services, unless explicitly required. You may need access to the database from the management console to send SQL queries to the database and visualize the data structure, or access from DataLens to visualize and analyze data. For such access , use the Yandex Cloud service network with authentication and TLS encryption. You can enable and disable access from the management console, DataLens, or other services in the cluster settings or when creating it in the advanced settings section.
Yandex Cloud Functions and Yandex API Gateway
Using a service account
To get an IAM token when executing a function, you must assign a service account for the function. See the instructions in Using functions to get an IAM token for a service account. In this case, the function receives an IAM token using built-in Yandex Cloud mechanisms without having to transfer any secrets to the function from outside.
Function access control
In cases where the use of public functions is not explicitly required, we recommend that you use private functions. For more information about setting up access to functions, see Making a function private.
Side-channel attacks in Cloud Functions
Hosts and hypervisors running Cloud Functions contain all the applicable updates for side-channel attack protection. However, keep in mind that different clients' functions are not isolated by cores. Thus, there is technically an attack surface between one user's function and another's. Yandex Cloud security experts believe that side-channel attacks are unlikely in the context of functions, but this risk must be accounted for, particularly in the overall threats and risk analysis model employed by the PCI DSS infrastructure.
Specifics of time synchronization in functions
The Cloud Functions service does not guarantee time synchronization prior to or during execution of requests by functions. To generate a function log with exact timestamps on the Cloud Functions side, output the log to stdout. The client can also independently accept function execution logs and label them with a timestamp on the receiving side. In this case, the timestamp is taken from the time source synced with Yandex Cloud. For more information about time synchronization, see the Compute Cloud documentation, Configuring clock synchronization using NTP
Managing HTTP headers in functions
If the function is called to process an HTTP request, the returned result should be a JSON document containing the HTTP response code, response headers, and response content. Cloud Functions will automatically process this JSON and the user will receive data as a standard HTTP response.
The client needs to manage the response headers on their own in accordance with regulator requirements and the threat model. For more information on how to process an HTTP request, see the Cloud Functions documentation, Invoking a function using HTTP.
Managed Service for YDB
Operations with data
It's prohibited to use confidential data, particularly PCI DSS data, as the names of database, tables, columns, folders, and so on. It's prohibited to send PCI DSS data to Managed Service for YDB (both Dedicated and Serverless) as clear text. Prior to sending data, be sure to encrypt the data at the application level. For this you can use the Key Management Service service or any other PCI DSS-compliant method. For data where the storage period is known in advance, we recommend that you configure the Time To Live
SQL injection protection
When working with the database, use parameterized prepared statements
Network access
When accessing the database in dedicated mode, we recommend that you use it inside Yandex Virtual Private Cloud and disable public access to it from the internet. In serverless mode, the database can be accessed from the internet. You must therefore take this into account when modeling threats to your PCI DSS infrastructure. For more information about the operating modes, see the Serverless and dedicated modes section in the Managed Service for YDB documentation.
When setting up database permissions, use the principle of least privilege.
Backups
When creating on-demand backups, make sure that the backup data is properly protected.
When creating backups on demand in Object Storage, follow the recommendations in the Object Storage subsection above (for example, use the built-in bucket encryption feature).
Yandex Container Registry and Yandex Container Solution
We do not recommend that you use privileged containers to run loads that process untrusted user input. Privileged containers must be used for the purposes of administering VMs or other containers. We recommend that you use delete policies for automatically deleting outdated container images.
We recommend using the image vulnerability scanner integrated into Yandex Container Registry.
Yandex Certificate Manager
Certificate Manager allows you to manage TLS certificates for API gateways in the API Gateway service and for websites and buckets in Object Storage. Yandex Application Load Balancer is integrated with Certificate Manager for storing and installing certificates. We recommend that you use Certificate Manager to obtain your certificates and rotate them automatically.
When using TLS in your application, we recommend that you limit the list of your trusted root certificate authorities (root CA). When using certificate pinning, keep in mind that Let's Encrypt certificates are valid for 90 days