3. Secure configuration of a virtual environment
This section provides recommendations to customers on security settings in Yandex Cloud services and the use of additional data protection tools in virtual environments.
Overview
3.1 A serial console is either used under control or not used
On VMs, access to the serial console is disabled by default. 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, passwords 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 a VM via a serial console is considered "non-console", and Yandex Cloud uses TLS encryption for it.
We do not recommend using access to the serial console unless it is absolutely necessary.
- In the management console, select the folder to check the VMs in.
- In the list of services, select Compute Cloud.
- Open the settings of all the necessary VMs.
- Under Access, find the Additional parameter.
- Serial console access must be disabled.
- If it is disabled for all the VMs, 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
-
Find the VM with access to the serial console 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 VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do echo "VM_ID: " && yc compute instance get --id=$VM_ID --full --format=json | jq -r '. | select(.metadata."serial-port-enable"=="1")' | jq -r '.id' && echo "FOLDER_ID: " $FOLDER_ID && echo "-----" done; done; done
-
If an empty value is set in VM_ID next to FOLDER_ID, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
If the serial console should not be used on the VM, disable it.
3.2 A benchmark image is used for VM deployment
When deploying virtual machines, we recommend:
- Preparing 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 virtual machine or instance group.
- Look up the virtual machine's information to check that it was created using this image.
- In the management console, select the folder to check the VMs in.
- In the list of services, select Compute Cloud.
- Go to the Disks tab.
- Open the settings of all disks.
- Under Source, find the Identifier parameter.
- If every disk displays the ID of your benchmark image, 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 the VM disks that do not contain the ID of your benchmark image:
export ORG_ID=<organization ID> export IMAGE_ID=<your reference image 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 DISK_ID in $(yc compute disk list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do echo "DISK_ID: " && yc compute disk get --id=$DISK_ID \ --format=json | jq -r --arg IMAGE_ID $IMAGE_ID '. | select(."source_image_id"==$IMAGE_ID | not)' | jq -r '.id' && echo "FOLDER_ID: " $FOLDER_ID && echo "-----" done; done; done
-
If an empty value is set in DISK_ID next to FOLDER_ID, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
- Find out why these VM disks use an image different from the benchmark one.
- Recreate the VMs with the appropriate image.
3.3 Terraform is used in accordance with best information security practices
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 HashiCorpVault from Cloud Marketplace or Lockbox (to transfer secrets to the target object without using Terraform).
If you still need to enter private information in the configuration, take the following security measures:
- Use sensitive = true
for private information to exclude it from the console output when runningterraform plan
andterraform apply
. - Use terraformremotestate
. We recommend uploading a Terraform state to Object Storage and setting up configuration locks using Managed Service for YDB to prevent simultaneous edits by administrators. - Use the mechanism for transferring secrets to Terraform via env
instead of plain text or use built-in KeyManagementService 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.
Note
When a configuration is deployed, you can delete the configuration file with private data.
Scan your Terraform manifests using Checkov
Collect data about using the Terraform best security practices from different points.
3.4. Integrity control is performed
3.4.1 File integrity control
Numerous information security standards require integrity control of critical files. To do this, you can use free host-based solutions:
Paid solutions are also available in Yandex Cloud marketplace, such as Kaspersky Security.
Collect data about using integrity control from different points.
3.4.2 Integrity control of a VM runtime environment
To control a VM's runtime environment (e.g., to enable access from the VM to a secure repository only when running it in the YC CLI cloud), you can use the identity document mechanism. When creating a VM, an identity document that stores information about the VM is generated. It contains IDs of the VM, Yandex Cloud Marketplace product, disk image, etc. This document is signed with a Yandex Cloud certificate. The document and its signature are available to VM processes through the metadata service. Thus, the processes identify the VM runtime environment, disk image, etc., to restrict access to the resources under monitoring.
Make sure that critical VMs have identity documents signed.
3.5 Principles of protection against side-channel attacks are used
To ensure the best protection against CPU level side-channel attacks (such as Spectre or Meltdown):
- Use full-core virtual machines (instances with a CPU share of 100%).
- Install updates for your operating system and kernel that ensure side-channel attack protection (for example, Kernelpage-tableisolation for Linux
or applications built using Retpoline ).
We recommend that you use dedicated hosts for the most security-critical resources.
Learn more
Yandex Object Storage
3.6 No public access to a Object Storage bucket is allowed
We recommend assigning minimum roles for a bucket using IAM and supplementing or itemizing them using a bucket policy (for example, to restrict access to the bucket by IP, grant granular permissions for objects, and so on).
Access to Object Storage resources is verified at three levels:
Verification procedure:
-
If a request passes the IAM 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 doesn't meet any of the rules, access is denied.
-
If the request fails the IAM or bucket policy check, access verification is performed based on an object's ACL.
In the IAM 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 permissions by Yandex Cloud public groups. Therefore, 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, grant granular rights to objects, and so on.
With ACLs, you can grant access to an object bypassing IAM verification and bucket policies. We recommend setting strict ACLs for buckets.
Example of a secure Object Storage configuration: Terraform
- In the management console, select the cloud or folder to check the buckets in.
- In the list of services, select Object Storage.
- Click the three dots next to each bucket and check their ACLs for
allUsers
andallAuthenticatedUsers
. - Open the bucket and check the ACL of each of its objects for
allUsers
andallAuthenticatedUsers
. - Check that the object Read access section has the Public parameter enabled. Otherwise, proceed to the "Guides and solutions to use".
-
Configure the AWS CLI to work with a cloud.
-
Run the command below to check the bucket ACL for
allUsers
andallAuthenticatedUsers
:aws --endpoint-url=https://storage.yandexcloud.net s3api get-bucket-acl <your bucket's name>
Guides and solutions to use:
If public access is enabled, remove it or perform access control (grant permission to access public data consciously).
3.7 Object Storage uses Bucket Policies
Bucket policies set permissions for actions with buckets, objects, and object groups. A policy is triggered when a user makes a request to a resource. As a result, the request is either executed or rejected.
Bucket Policy examples:
- Policy that only enables object download from a specified range of IP addresses.
- Policy that prohibits downloading objects from the specified IP address.
- Policy that provides different users with full access only to certain folders, with each user being able to access their own.
- Policy that gives each user and service account full access to a folder named the same as the user ID or service account ID.
We recommend making sure that your Object Storage bucket uses at least one policy.
- In the management console, select the cloud or folder to check the bucket policies in.
- In the list of services, select Object Storage.
- Go to Bucket policy.
- Make sure that at least one policy is enabled. Otherwise, proceed to the "Guides and solutions to use".
-
Configure the AWS CLI to work with a cloud.
-
Run the command below to check the bucket ACL for
allUsers
andallAuthenticatedUsers
:aws --endpoint-url=https://storage.yandexcloud.net s3api get-bucket-policy --bucket <your bucket's name>
Guides and solutions to use:
Enable the required policy.
3.8 In Object Storage, the Object locks feature is enabled
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, as well as by using object locks.
Bucket versioning is the ability to store the history of object versions. Each version is a complete copy of the object and occupies space in Object Storage. Using version control protects your data from both unintentional user actions and application faults.
If you delete or 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.
For more information about lifecycles, see the Object Storage documentation, Bucket object lifecycles and Bucket object lifecycle configuration.
In addition, to protect object versions against deletion, use object locks. For more information about object lock types and how to enable them, see the documentation.
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 be available online for at least three months.
- In the management console, select the cloud or folder to check the buckets in.
- In the list of services, select Object Storage.
- Open the settings of all buckets.
- Go to the Versioning tab and make sure it is enabled. 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 versioning is enabled:
aws --endpoint https://storage.yandexcloud.net \ s3api get-bucket-versioning \ --bucket <your bucket's name>
-
Run the command below to check whether versioning is enabled:
aws --endpoint-url=https://storage.yandexcloud.net/ \ s3api get-object-lock-configuration \ --bucket <your bucket's name>
Guides and solutions to use:
If public access is enabled, remove it or use access control (by only enabling it when necessary and if approved).
3.9 In Object Storage, logging of actions with buckets is enabled
When using Object Storage to store critical data, be sure to enable logging of actions with buckets. For more information, see the Object Storage documentation, Logging actions with a bucket.
This makes sure that data-plane logs with the following objects are written: PUT, DELETE, GET, POST, OPTIONS, and HEAD.
In a similar way, you can request writing these logs to Audit Trails, except reads. In the future, all these logs will be written to Audit Trails.
You can also analyze Object Storage logs in DataLens. For more information, see Analyzing Object Storage logs using DataLens.
Guides and solutions to use:
You can only use Terraform/API to check if logging is enabled by following the instructions.
3.10 In Object Storage, Cross-Origin Resource Sharing (CORS) is set up
If cross-domain requests
- In the management console, select the cloud or folder to check the buckets in.
- In the list of services, select Object Storage.
- Open the settings of all buckets.
- Go to the CORS tab and make sure that the configuration is set up. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Set up CORS.
Managed Services for Databases
3.11 A security group is assigned in managed 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. To do this, follow the steps in Creating a security group. You can specify a security group in the cluster settings or when creating the cluster in the network settings section.
- In the management console, select the cloud or folder to check the databases in.
- In the list of services, select a service or services with managed databases.
- In the object settings, find the Security group parameter and make sure that at least one security group is assigned.
- If the parameters of each object have at least one security group set, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
Run the command below to search for Managed PostgreSQL DBs with no SG:
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 DB_ID in $(yc managed-postgresql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-postgresql cluster get --id=$DB_ID --format=json | jq -r '. | select(.security_group_ids | not)' | jq -r '.id' done; done; done
-
If an empty string is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
Run the command below to search for Managed MySQL DBs with no SG:
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 DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql cluster get --id=$DB_ID --format=json | jq -r '. | select(.security_group_ids | not)' | jq -r '.id' done; done; done
-
If an empty string is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
If any databases without security groups are found, assign them or enable the Default security group functionality.
3.12 No public IP address is assigned in managed databases
Assigning a public IP to a managed database raises information security risks. We do not recommend assigning an external IP unless it is absolutely necessary.
- In the management console, select the cloud or folder to check the databases in.
- In the list of services, select a service or services with managed databases.
- In the object settings, go to the Hosts tab.
- If the parameters of each object have the Public access option disabled, 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 managed DB clusters with public IPs:
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 DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql hosts list --cluster-id=$DB_ID --format=json | jq -r '.[] | select(.assign_public_ip)' | jq -r '.cluster_id' done; done; done
-
If an empty string is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Disable public access if it is not required.
3.13 The deletion protection feature is enabled
In Yandex Cloud managed databases, you can enable deletion protection. Deletion protection manages cluster protection from accidental deletion by a user. Enabled protection will not prevent a manual connection to a cluster to delete data.
- In the management console, select the cloud or folder to check the databases in.
- In the list of services, select a service or services with managed databases.
- In the object settings, go to the Advanced settings tab.
- If the parameters of each object have the Deletion protection option enabled, 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 managed DB clusters with deletion protection disabled:
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 DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql cluster get --id=$DB_ID --format=json | jq -r '. | select(.deletion_protection | not)' | jq -r '.id' done; done; done
-
If an empty string 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 deletion protection in.
- In the list of services, select a service or services with managed databases.
- In the object settings, go to the Advanced settings tab.
- In the object parameters, enable Deletion protection.
3.14 The setting that enables access from DataLens is not activated unless needed
Do not enable access to databases containing critical data from the management console, DataLens, or other services unless you have to. Access from DataLens may be required for data analysis and visualization. For such access, the Yandex Cloud service network is used, with authentication and TLS encryption. You can enable and disable access from DataLens or other services in the cluster settings or when creating it in the advanced settings section.
- In the management console, select the cloud or folder to check the databases in.
- In the list of services, select a service or services with managed databases.
- In the object settings, go to the Advanced settings tab.
- If the parameters of each object have Access from DataLens disabled, 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
-
Find managed DB clusters with access from DataLens 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 DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql cluster get --id=$DB_ID --format=json | jq -r '. | select(.config.access.data_lens)' | jq -r '.id' done; done; done
-
If an empty string 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 disable access from DataLens in.
- In the list of services, select a service or services with managed databases.
- In the object settings, go to the Advanced settings tab.
- In the object parameters, disable Access from DataLens.
3.15 Access from the management console is disabled in managed databases
You may need access to the database from the management console to send SQL queries to the database and visualize the data structure.
We recommend that you enable this type of access only if needed, because it raises information security risks. In normal mode, use a standard DB connection as a DB user.
- In the management console, select the cloud or folder to check the databases in.
- In the list of services, select a service or services with managed databases.
- In the object settings, go to the Advanced settings tab.
- If the parameters of each object have Access from the management console disabled, 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 managed DB clusters with access from the management console 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 DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql cluster get --id=$DB_ID --format=json | jq -r '. | select(.config.access.web_sql)' | jq -r '.id' done; done; done
-
If an empty string 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 disable access from the management console in.
- In the list of services, select a service or services with managed databases.
- In the object settings, go to the Advanced settings tab.
- In the object parameters, disable Access from console.
Cloud Functions and Yandex API Gateway
3.16 Public cloud functions are only used in exceptional cases
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 Managing rights to access functions. We recommend using private functions and assigning rights to invoke functions to specific cloud users.
- In the management console, select the cloud or folder to check the functions in.
- In the list of services, select Cloud Functions.
- Open all the functions.
- In the function settings, go to the Overview tab.
- If the parameters of each object have the Public function option disabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
Run the command below to search for
allUsers
access rights at the Cloud Functions level in all folders: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 FUN in $(yc serverless function list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc serverless function list-access-bindings --id $FUN --format=json | jq -r '.[] | select(.subject.id=="allAuthenticatedUsers" or .subject.id=="allUsers")' && echo $FUN done; done; done
-
If none of the specified resources contain
allUsers
andallAuthenticatedUsers
, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Disable public access.
3.17 Side-channel attacks in Cloud Functions are considered
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.
Make sure the most critical systems do not use Cloud Functions or this is considered in the risk analysis model.
3.18 Specifics of time synchronization in Cloud Functions are considered
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.
3.19 Specifics of header management in Cloud Functions are considered
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, refer to the Cloud Functions manual, Invoking a function in Cloud Functions.
3.20 Serverless Containers/Cloud Functions uses the VPC internal network
By default, the function is invoked in the isolated IPv4 network with the NAT gateway enabled. For this reason, only public IPv4 addresses are available.
If necessary, you can specify a cloud network in function settings. In this case, the function:
- Is executed in a given cloud network.
- Has access to the internet and user resources in the given network, such as databases and VMs.
- Has an IP address within the
198.19.0.0/16
range when accessing user resources.
- In the management console, select the cloud or folder to check the functions in.
- In the list of services, select Cloud Functions.
- Open all the functions.
- In the object settings, go to the Edit function version tab.
- If the parameters of each object have Network — VPC set, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
Run the command below to search for any cloud functions that have no network settings specified in VPC:
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(.connectivity.network_id | not)' | jq -r '.id' done; done; done
-
If an empty string is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
- Select the cloud or folder to check the functions in.
- Select Cloud Functions in the list of services.
- Open the function.
- In the object settings, go to the Edit function version tab.
- Set Network — VPC.
Managed Service for YDB
3.21 Recommendations for using confidential data in YDB are followed
It's prohibited to use confidential data as the names of databases, tables, columns, directories, and so on. It's prohibited to send critical data, such as payment card details, to Managed Service for YDB (both Dedicated and Serverless) as clear text. Prior to sending data, be sure to encrypt it at the application level. For this you can use the KMS service or any other method compliant with the regulator standard. For data where the storage period is known in advance, we recommend that you configure the Time To Live
3.22 Recommendations for SQL injection protection in YDB are followed
When working with the database, use parameterized prepared statements
3.23 No public access to YDB is allowed
When accessing the database in dedicated mode, we recommend that you use it inside VPC, disabling 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 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.
- In the management console, select the cloud or folder to check the database in.
- In the list of services, select Managed Service for YDB.
- Open all the databases.
- In the database settings, go to the Network tab.
- If the parameters of each object have the Public IP addresses option disabled, 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 managed DB clusters with public IPs:
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 DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql hosts list --cluster-id=$DB_ID --format=json | jq -r '.[] | select(.assign_public_ip)' | jq -r '.cluster_id' done; done; done
-
If an empty string is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Disable public access if it is not required.
3.24 Recommendations for YDB backups are followed
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
3.25 ACL by IP address is set up for Yandex Container Registry
We recommend that you limit access to your Container Registry to specific IPs.
- In the management console, select the cloud or folder to check the registry in.
- In the list of services, select Container Registry.
- In the settings of the specific registry, go to the Access for IP address tab.
- If specific IPs to allow access for are set in the parameters, 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 CRs that are not filtered by IP:
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 CR in $(yc container registry list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc container registry list-ip-permissions --id=$CR --format=json | jq -r '.[] | select(.ip)' | jq -r '.action' && echo $CR "IF ACTION PULL/PUSH exist before CR then OK" done; done; done
-
If PULL/PUSH is output before each registry ID, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Specify the IP addresses for registry access.
Yandex Container Solution
We do not recommend that you use privileged containers to run loads that process untrusted user input. Privileged containers should be used for the purposes of administering VMs or other containers.
- In the management console, select the cloud or folder to check the VMs in.
- In the list of services, select Compute Cloud.
- Open the settings of a specific VM with a Container Optimized Image.
- In the Docker container's Settings, find the Privileged mode parameter.
- If it is disabled, 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 CRs that are not filtered by IP:
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 VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc compute instance get --id=$VM_ID --full --format=json | jq -r '. | select(.metadata."docker-container-declaration")| .metadata."docker-container-declaration" | match("privileged: true") | .string' && echo $VM_ID done; done; done
-
If there is no
privileged: true
in front of each VM ID, 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 check the VMs in.
- In the list of services, select Compute Cloud.
- Open the settings of a specific VM with a Container Optimized Image.
- In the Docker container's Settings, disable the Privileged mode parameter.
3.26 A Yandex Certificate Manager certificate is valid for at least 30 days
You can use Yandex Certificate Manager to manage TLS certificates for your API gateways in the API Gateway, as well as your websites and buckets in Object Storage. 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
We recommend that you update certificates in advance if they are not updated automatically.
- In the management console, select the cloud or folder to check the VMs in.
- In the list of services, select Yandex Certificate Manager.
- Open the settings of each certificate and find the End date parameter.
- If the parameter shows that the certificate will be valid for at least 30 days more, 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
-
Search for any of your organization's certificates with the end date:
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 CERT_ID in $(yc certificate-manager certificate list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc certificate-manager certificate get --id $CERT_ID --format=json | jq -r '. | "Date of the end " + .not_after + " --- Cert_ID " + .id' done; done; done
-
If there is no
privileged: true
in front of each VM ID, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Update the certificate or set up auto updates.
Yandex Managed Service for GitLab
3.27 Recommendations on security settings for a GitLab instance are followed
See the recommendations here.
Run a manual check.
3.28 Antivirus protection is used
Make sure to provide anti-malware protection within your scope of responsibility. You can use a variety of solutions from our partners in Yandex Cloud Marketplace.
Antivirus solution images are available in Yandex Cloud Marketplace. License types and other required information are available in the product descriptions.
Make sure that critical systems are protected with antivirus solutions.
Guides and solutions to use:
Follow the vendor guide to install the AV solution.
3.29 Yandex Managed Service for Kubernetes security recommendations are used
Check the recommendations in Security Kubernetes.