Contact UsGet started
© 2024 Iron Hive LLC Belgrade

3. Secure configuration of a virtual environment

Written by
Improved by
Updated at November 14, 2024

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. For risks of using the serial console, see Getting started with the serial console in the Yandex Compute Cloud documentation.

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.

  1. In the management console, select the folder to check the VMs in.
  2. In the list of services, select Compute Cloud.
  3. Open the settings of all the necessary VMs.
  4. Under Access, find the Additional parameter.
  5. Serial console access must be disabled.
  6. If it is disabled for all the VMs, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. 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

  3. 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.
  1. In the management console, select the folder to check the VMs in.
  2. In the list of services, select Compute Cloud.
  3. Go to the Disks tab.
  4. Open the settings of all disks.
  5. Under Source, find the Identifier parameter.
  6. If every disk displays the ID of your benchmark image, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. 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=<ID of your benchmark image>
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

  3. 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:

  1. Find out why these VM disks use an image different from the benchmark one.
  2. 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, payment system data, etc. Instead, you should use services to store and use secrets in the configuration, such as: HashiCorp Vault 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:

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 with Yandex Cloud support.

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 incorporated

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 about side-channel attack protection in cloud environments.

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:

  1. If a request passes the IAM check, the next step is the bucket policy check.

  2. Bucket policy rules are checked in the following order:

    1. If the request meets at least one of the Deny rules, access is denied.
    2. If the request meets at least one of the Allow rules, access is allowed.
    3. If the request doesn't meet any of the rules, access is denied.

  3. If the request fails the IAM or bucket policy check, access verification is performed based on an object's ACL.

In IAM, a bucket inherits the same access permissions as those of the folder and cloud where it is 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 permissions 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

  1. In the management console, select the cloud or folder to check the buckets in.
  2. In the list of services, select Object Storage.
  3. Click the three dots next to each bucket and check its ACL for allUsers and allAuthenticatedUsers.
  4. Open the bucket and check the ACL of each of its objects for allUsers and allAuthenticatedUsers.
  5. Check that the object Read access section has the Public parameter enabled. Otherwise, proceed to the "Guides and solutions to use".

  1. Configure the AWS CLI to work with a cloud.

  2. Run the command below to check the bucket ACL for allUsers and allAuthenticatedUsers:

    aws --endpoint-url=https://storage.yandexcloud.net s3api get-bucket-acl  <name of your bucket>

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.

  1. In the management console, select the cloud or folder to check the bucket policies in.
  2. In the list of services, select Object Storage.
  3. Go to Bucket policy.
  4. Make sure that at least one policy is enabled. Otherwise, proceed to the "Guides and solutions to use".

  1. Configure the AWS CLI to work with a cloud.

  2. Run the command below to check the bucket ACL for allUsers and allAuthenticatedUsers:

    aws --endpoint-url=https://storage.yandexcloud.net s3api get-bucket-policy --bucket <name of your bucket>

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.

  1. In the management console, select the cloud or folder to check the buckets in.
  2. In the list of services, select Object Storage.
  3. Open the settings of all buckets.
  4. Go to the Versioning tab and make sure it is enabled. Otherwise, proceed to the "Guides and solutions to use".

  1. Configure the AWS CLI to work with a cloud.

  2. Run the command below to check whether versioning is enabled:

    aws --endpoint https://storage.yandexcloud.net \
s3api get-bucket-versioning \
--bucket <name of your bucket>

  3. Run the command below to check whether versioning is enabled:

    aws --endpoint-url=https://storage.yandexcloud.net/ \
s3api get-object-lock-configuration \
--bucket <name of your bucket>

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, 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 you need cross-domain requests to objects in buckets, the client should configure the Cross-Origin Resource Sharing (CORS) policy in accordance with the client's information security requirements. For more information, see the Object Storage documentation, CORS configuration of buckets.

  1. In the management console, select the cloud or folder to check the buckets in.
  2. In the list of services, select Object Storage.
  3. Open the settings of all buckets.
  4. 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.

3.11 Use Yandex Security Token Service to get access keys to Object Storage

Yandex Security Token Service: Yandex Identity and Access Management component to get temporary access keys compatible with AWS S3 API.

Temporary access keys as an authentication method are only supported in Yandex Object Storage.

With temporary keys, you can set up granular access to buckets for multiple users with a single service account. The service account permissions must include all the permissions you want to grant using temporary keys.

A temporary access key is created based on a static key, but, unlike it, it has a limited lifetime and access permissions. Access permissions and lifetime are set for each temporary key individually. The maximum key lifetime is 12 hours.

To set up access permissions for the key, you need an access policy in JSON format based on this schema.

Temporary Security Token Service keys inherit the access permissions of the service account, but are limited by the access policy. If you set up a temporary key's access policy to allow operations not allowed for the service account, such operations will not be performed.

Guides and solutions to use:

Create a temporary access key using Security Token Service.

3.12 Pre-signed URLs are generated for isolated cases of access to specific objects in Object Storage private buckets

Object Storage incorporates several access management mechanisms. To learn how these mechanisms interact, see Access management methods in Object Storage: Overview.

With pre-signed URLs, any web user can perform various operations in Object Storage, such as:

  • Downloading an object
  • Uploading an object
  • Creating a bucket

A pre-signed URL is a URL containing request authorization data in its parameters. Pre-signed URLs can be created by users with static access keys.

We recommend using pre-signed URLs to users who are not authorized in the cloud but need access to specific objects in the bucket. This way you follow the principle of least privilege and avoid opening access to all the objects in the bucket.

Guides and solutions to use:

Create a pre-signed URL and communicate it to the user.

Managed Services for Databases

3.13 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.

  1. In the management console, select the cloud or folder to check the databases in.
  2. In the list of services, select a service or services with managed databases.
  3. In the object settings, find the Security group parameter and make sure that at least one security group is assigned.
  4. 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".

  1. 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

  2. The output should return an empty string. Otherwise, proceed to the "Guides and solutions to use".

  1. 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

  2. The output should return an empty string. 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.14 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.

  1. In the management console, select the cloud or folder to check the databases in.
  2. In the list of services, select a service or services with managed databases.
  3. In the object settings, go to the Hosts tab.
  4. 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".

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. 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

  3. 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.15 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.

  1. In the management console, select the cloud or folder to check the databases in.
  2. In the list of services, select a service or services with managed databases.
  3. In the object settings, go to the Advanced settings tab.
  4. 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".

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. 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

  3. The output should return an empty string. Otherwise, proceed to the "Guides and solutions to use".

Guides and solutions to use:

  1. In the management console, select the cloud or folder to enable deletion protection in.
  2. In the list of services, select a service or services with managed databases.
  3. In the object settings, go to the Advanced settings tab.
  4. In the object parameters, enable Deletion protection.

3.16 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.

  1. In the management console, select the cloud or folder to check the databases in.
  2. In the list of services, select a service or services with managed databases.
  3. In the object settings, go to the Advanced settings tab.
  4. If the parameters of each object have Access from DataLens disabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. 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

  3. The output should return an empty string. Otherwise, proceed to the "Guides and solutions to use".

Guides and solutions to use:

  1. In the management console, select the cloud or folder to disable access from DataLens in.
  2. In the list of services, select a service or services with managed databases.
  3. In the object settings, go to the Advanced settings tab.
  4. In the object parameters, disable Access from DataLens.

3.17 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.

  1. In the management console, select the cloud or folder to check the databases in.
  2. In the list of services, select a service or services with managed databases.
  3. In the object settings, go to the Advanced settings tab.
  4. 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".

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. 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

  3. If an empty string is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".

Guides and solutions to use:

  1. In the management console, select the cloud or folder to disable access from the management console in.
  2. In the list of services, select a service or services with managed databases.
  3. In the object settings, go to the Advanced settings tab.
  4. In the object parameters, disable Access from console.

Cloud Functions and Yandex API Gateway

3.18 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 function access permissions. We recommend using private functions and assigning rights to invoke functions to specific cloud users.

  1. In the management console, select the cloud or folder to check the functions in.
  2. In the list of services, select Cloud Functions.
  3. Open all the functions.
  4. In the function settings, go to the Overview tab.
  5. 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".

  1. Run the command below to search for allUsers access permissions 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

  2. If none of the specified resources contain allUsers and allAuthenticatedUsers, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".

Guides and solutions to use:

Disable public access.

3.19 Side-channel attacks in Cloud Functions are addressed

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.20 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.21 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 automatically processes this JSON document and returns data in a standard HTTP response to the user. 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.22 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.
  1. In the management console, select the cloud or folder to check the functions in.
  2. In the list of services, select Cloud Functions.
  3. Open all the functions.
  4. In the object settings, go to the Edit function version tab.
  5. If the parameters of each object have Network — VPC set, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".

  1. 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

  2. If an empty string is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".

Guides and solutions to use:

  1. Select the cloud or folder to check the functions in.
  2. Select Cloud Functions in the list of services.
  3. Open the function.
  4. In the object settings, go to the Edit function version tab.
  5. Set Network — VPC.

Managed Service for YDB

3.23 Recommendations for using confidential data in YDB are addressed

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 option.

3.24 Recommendations for SQL injection protection in YDB are addressed

When working with the database, use parameterized prepared statements to protect against SQL injection. If the application dynamically generates query templates, you must prevent the injection of untrusted user input into the SQL query template.

3.25 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.

  1. In the management console, select the cloud or folder to check the database in.
  2. In the list of services, select Managed Service for YDB.
  3. Open all the databases.
  4. In the database settings, go to the Network tab.
  5. 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".

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. 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

  3. The output should return an empty string. Otherwise, proceed to the "Guides and solutions to use".

Guides and solutions to use:

Disable public access if it is not required.

3.26 Recommendations for YDB backups are addressed

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.27 ACL by IP address is set up for Yandex Container Registry

We recommend that you limit access to your Container Registry to specific IPs.

  1. In the management console, select the cloud or folder to check the registry in.
  2. In the list of services, select Container Registry.
  3. In the settings of the specific registry, go to the Access for IP address tab.
  4. 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".

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. 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

  3. 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.

  1. In the management console, select the cloud or folder to check the VMs in.
  2. In the list of services, select Compute Cloud.
  3. Open the settings of a specific VM with a Container Optimized Image.
  4. In the Docker container's Settings, find the Privileged mode parameter.
  5. If it is disabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. 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

  3. 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:

  1. In the management console, select the cloud or folder to check the VMs in.
  2. In the list of services, select Compute Cloud.
  3. Open the settings of a specific VM with a Container Optimized Image.
  4. In the Docker container's Settings, disable the Privileged mode parameter.

3.28 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.

  1. In the management console, select the cloud or folder to check the VMs in.
  2. In the list of services, select Yandex Certificate Manager.
  3. Open the settings of each certificate and find the End date parameter.
  4. 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".

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. 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

  3. 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.29 GitLab security guidelines are followed

See the recommendations here.

Run a manual check.

3.30 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.31 Yandex Managed Service for Kubernetes security guidelines are used

Check the recommendations in Security Kubernetes.

3.32 Connecting to a VM or Kubernetes node via OS Login

OS Login is a convenient way to manage connections to virtual machines and Yandex Managed Service for Kubernetes cluster nodes over SSH via the YC CLI or a standard SSH client with an SSH certificate or SSH key previously added to the organization user's OS Login or service account profile in Yandex Cloud Organization.

OS Login links the account of a virtual machine or Kubernetes node user with the account of an organization or service account user. To manage access to virtual machines and Kubernetes nodes, enable the OS Login access option at the organization level, then activate OS Login access on each virtual machine or Kubernetes node separately.

Thus, you can easily manage access to virtual machines and Kubernetes nodes by assigning appropriate roles to users or service accounts. If you revoke the roles, the user or service account will lose access to all virtual machines and Kubernetes nodes with OS Login access enabled.

Guides and solutions to use:

3.33 Vulnerability scanning is performed at the cloud IP level

We recommend that clients scan their own hosts for vulnerabilities. Cloud resources support the installation of custom virtual images of vulnerability scanners or software agents on hosts. There are many fee-based and free solutions for scanning.

Network scanners scan hosts that are accessible over a network. Generally, authentication can be configured on network scanners.

Examples of free network scanners:

Example of a free scanner operating as an agent on hosts: Wazuh. Wazuh can also be used as a host-based intrusion detection system (IDS).

You can also use a solution from Cloud Marketplace.

Run a manual check.

3.34 External security scans are performed according to the cloud rules

Customers hosting their own software in Yandex Cloud can perform external security scans for the hosted software, including penetration tests. You can run your own scans or use contractors. For more information, see Rules for performing external security scans.

Run a manual check.

3.35 The process of security updates is set up

A client must perform their own security updates within their scope of responsibility. Various automated tools are available for centralized automated OS and software updates.

Yandex Cloud publishes security bulletins to notify customers of newly discovered vulnerabilities and security updates.

Previous
Network security
Next
Data encryption and key management