Standard for securing Yandex Cloud infrastructure 1.1

IntroductionIntroduction

This document provides recommendations for technical protection measures and helps you choose information security measures when deploying information systems in Yandex Cloud.
The recommendations and security measures described in the standard have links to the Guides and solutions for setting up secure resource configurations with standard and additional information security tools available to Yandex Cloud users.
The standard also describes different methods and tools for verifying recommendation compliance, such as:

• Using the management console UI
• Using the Yandex Cloud CLI
• Manually

What is new in version 1.1What is new in version 1.1

List of changes to version 1.1. compared to version 1.0:

• Added the following items:

  • 1.20 Impersonation is used wherever possible.
  • 1.21 Resource labels are used.
  • 1.22 Yandex Cloud security notifications are enabled.
  • 1.23 The auditor role is used to prevent access to user data.
  • 3.4.2 Integrity control of a VM runtime environment.
  • 3.28 Antivirus protection is used.
  • 3.29 Yandex Managed Service for Kubernetes security guidelines are used.
  • 4.16 There is a guide for cloud administrators on handling compromised secrets.

• Updated the following items:

  • 1.4, 1.14 Added recommendations for using the auditor role.
  • 1.9 Added recommendations for placing critical service accounts in separate folders.
  • 1.12 Added editor to the list of privileged roles assigned at the organization, cloud, and folder levels.
  • 4.7 Added a guide on how to encrypt data in Yandex Managed Service for PostgreSQL and Yandex Managed Service for Greenplum® using pgcrypto and KMS.
  • 4.13 Added recommendations for using Yandex Lockbox in Terraform without writing the information to .tfstate.

• Added the 9. Application security section:

  • 9.1 Yandex SmartCaptcha is used.
  • 9.2 Enabled the scan on push policy for the containerized image vulnerability scanner.
  • 9.3 Container images are periodically scanned.
  • 9.4 Container images used in a production environment have the last scan date a week ago or less.
  • 9.5 Software artifacts are built using attestations.
  • 9.6 Artifacts within a pipeline can be signed using Cosign, a third-party command line utility.
  • 9.7 Artifacts are checked when deployed in Yandex Managed Service for Kubernetes.
  • 9.8 Ready-made blocks of a secure pipeline are used.

ScopeScope

The recommendations are designed for solution architects, technical specialists, and information security experts who use the following services when developing secure cloud systems and security policies to work with the cloud platform:

• Identity and Access Management (IAM)
• Application Load Balancer
• Audit Trails
• Certificate Manager
• Cloud DNS
• Cloud Logging
• Compute Cloud
• Key Management Service
• Yandex Lockbox
• Managed Service for ClickHouse®
• Managed Service for GitLab
• Managed Service for MongoDB
• Managed Service for MySQL
• Managed Service for PostgreSQL
• Managed Service for Redis
• Network Load Balancer
• Object Storage
• Cloud Organization
• Resource Manager
• Virtual Private Cloud
• Managed Service for YDB

The standard can be used as the basis for developing company-specific recommendations. Not all of the information security measures and recommendations from this document are applicable. Moreover, additional measures and recommendations that are not included in the current standard may be required.

Structure of the standardStructure of the standard

The standard describes recommendations for the following security objectives:

• Authentication and access control
• Network security
• Secure configuration of a virtual environment
• Data encryption and key management
• Collecting, monitoring, and analyzing audit logs
• Vulnerability management
• Backups
• Physical security
• Application security

Requirements to meet before you startRequirements to meet before you start

Before you perform checks, make sure that:

• You have the YC CLI installed and set up according to the instructions.
• You have logged in to the management console.
• The jq utility is installed.

You can automate the audit of compliance with all the recommendations using available solutions from our partners:

• Neocat: Product for cloud security management from Neoflex. It is used as an isolated installation within the user cloud perimeter and no administrator privileges need to be granted.
• Cloud Advisor: Agentless platform that identifies and prioritizes cloud security risks, helps you reduce costs, ensure compliance with regulatory requirements, and manage your cloud infrastructure.

Responsibility limitationResponsibility limitation

Yandex Cloud uses the concept of Shared responsibility. Where the lines are drawn for who is responsible for security depends on the services used by the system in the cloud, their usage model, i.e., infrastructure as a service (IaaS), platform as a service (PaaS), or software as a service (SaaS), and the security tools and policies the cloud provider has in place.

Terms and abbreviationsTerms and abbreviations

This document uses the terms and definitions introduced in ISO/IEC 27000:2018 and ISO/IEC 29100:2011, as well as the terms from the Yandex Cloud glossary.

1. Authentication and access control1. Authentication and access control

In Yandex Cloud, identification, authentication, and access control is performed by Yandex Identity and Access Management (IAM) and Yandex Cloud Organization.

The platform works with three categories of users:

• Yandex accounts: Accounts in Yandex ID.
• Federated accounts: Accounts in a corporate SAML-compatible identity federation, such as Active Directory.
• Service accounts: Accounts that can be used by programs to manage resources.

Yandex ID accounts and federated accounts are authenticated in their own systems. Yandex Cloud has no access to these users' passwords and only authenticates service accounts via IAM.

User access to cloud resources is regulated by roles. Yandex Cloud services may provide different levels of granularity while granting permissions: in some cases, a role can be assigned directly to a service resource, in other cases, permissions are only granted at the level of the folder or cloud where the service resource is located.

This ensures interaction of different categories of resources, roles, and users in the Yandex Cloud infrastructure. Access to resources is managed by IAM. IAM controls each request and makes sure that all operations with resources are only run by users who have the appropriate permissions.

1.1 An identity federation (Single Sign-On, SSO) is configured1.1 An identity federation (Single Sign-On, SSO) is configured

Yandex Cloud Organization is a single service for managing the organizational structure, setting up integration with the employee catalog, and differentiating user access to the organization's cloud resources.

For the purpose of centralized account management, use SAML-compatible identity federations. By using identity federations, a company can set up Single Sign-On, which is authentication in Yandex Cloud via their IdP server. With this approach, employees can use their corporate accounts that are subject to the company's security policies, such as:

• Revoking and blocking accounts.
• Password policies.
• Limiting the number of unsuccessful login attempts.
• Blocking access sessions upon expiry of a preset user's idle time.
• Two-factor authentication.

To make sure that all authentication requests from Yandex Cloud contain a digital signature, enable the Sign authentication requests option. To complete the configuration, download and install a Yandex Cloud certificate. You can download the certificate in the Sign authentication requests field immediately after creating a federation.

Guides and solutions to use:

• Guide on setting up SAML-based identity federations.
• Guide on configuring a SAML-based federation with KeyCloak.

1.2 Yandex ID accounts are only used in exceptional cases1.2 Yandex ID accounts are only used in exceptional cases

The best approach to account management, in terms of security, is using identity federations (for more information, see recommendation 1.1). Therefore, you should do your best to ensure that your organization's list of users only contains federated users (those with the FEDERATION ID attribute) and there are as few Yandex ID accounts on the list as possible. The following exceptions are allowed:

• Account with the billing.accounts.owner permissions (technically, this role can now be granted to a Yandex ID account only).
• Account with the organization-manager.organizations.owner and resource-manager.clouds.owner permissions, only if you use it in case of emergency, such as when a federation's setup failed. If necessary, you can delete a privileged passport account with the organization-manager.organizations.owner role from an organization.
• External accounts, such as those of your contract partners or contractors, which, for some reason, you cannot register in your IdP.

Guides and solutions to use:

Remove all the accounts that have a Yandex ID from your organization, except those on the list of allowed exceptions.

1.3 Only appropriate administrators can manage IAM group membership1.3 Only appropriate administrators can manage IAM group membership

You can conveniently control access to resources via user groups. Make sure to control access to a group as a resource. Users with access permissions to the group can manage other users' membership in the group. Users are granted these permissions in the following cases:

• The user is assigned the organization-manager.groups.memberAdmin role for an organization.
• The user is assigned the organization-manager.groups.memberAdmin role for a specific group as a resource.
• The user is assigned the organization-manager.organizations.owner or admin role or another privileged role for the entire organization.
• The user is assigned the admin or editor role for a specific group as a resource (this is not recommended).

Guides and solutions to use:

Remove the group access rights from the accounts that do not require them.

1.4 Service roles are used instead of primitive roles: admin, editor, viewer, and auditor1.4 Service roles are used instead of primitive roles: admin, editor, viewer, and auditor

The principle of least privilege requires assigning users the minimum required roles. We do not recommend using primitive roles, such as admin, editor, viewer, and auditor that are valid for all services, because this contradicts the principle of least privilege. To ensure more selective access control and implementation of the principle of least privilege, use service roles that only contain permissions for a certain type of resources in the specified service. You can see the list of all service roles in the Yandex Cloud roll reference.

Use the auditor role without data access wherever possible.

Guides and solutions to use:

Analyze the accounts found with the admin, editor, and viewer primitive roles assigned and replace them with service granular roles based on your role matrix.

1.5 Cloud entities with service accounts are registered and limited1.5 Cloud entities with service accounts are registered and limited

A service account is an account that can be used by a program to manage resources in Yandex Cloud. A service account is used to make requests as an application.

• Do not use employee accounts instead of service accounts. If, for example, an employee quits or moves to a different department, their account permissions are disabled, which may lead to an application failure.
• Do not write service account keys directly to your application's code, configuration files, or environment variables.

When using service accounts:

• Assign a service account to a VM instance and get a token using the metadata service.

• In addition, set up a local firewall on the VM instance so that only the necessary processes and system users have access to the metadata service (IP address: 169.254.169.254).

  Example of blocking access for all users except the specified one (in this case, root):

  sudo iptables --append OUTPUT --proto tcp \
  --destination 169.254.169.254 --match owner ! --uid-owner root \
  --jump REJECT
  

The cloud entities with service accounts assigned must be registered and limited, because, for example, if a service account is assigned to a VM, a hacker may get the service account's token from the metadata service from within the VM.

Guides and solutions to use:

Remove the service accounts from the cloud entities that do not require them.

1.6 There are no cloud keys represented as plaintext in the VM metadata service1.6 There are no cloud keys represented as plaintext in the VM metadata service

Do not write service account keys and other keys to the VM metadata directly. Assign a service account to a VM instance and get a token using the metadata service. Sensitive data may be stored in any metadata field. However, the most common one is user-data (due to its use in the cloud-init utility).

See the list of all regular expressions used to search for cloud accounts' credential secrets:

• yandex_cloud_iam_cookie_v1 : c1.[A-Z0-9a-z_-]+[=]{0,2}.[A-Z0-9a-z_-]{86}[=]{0,2}
  Yandex.Cloud Session Cookie
• yandex_cloud_iam_token_v1 : t1.[A-Z0-9a-z_-]+[=]{0,2}.[A-Z0-9a-z_-]{86}[=]{0,2}
  Yandex.Cloud IAM token
• yandex_cloud_iam_api_key_v1 : AQVN[A-Za-z0-9_-]{35,38}
  Yandex.Cloud API Keys (Speechkit, Vision, Translate)
• yandex_passport_oauth_token : y[0-6]_[-_A-Za-z0-9]{55}
  Yandex Passport OAuth token
• yandex_cloud_iam_access_secret : YC[a-zA-Z0-9_-]{38}
  Yandex.Cloud AWS API compatible Access Secret

Guides and solutions to use:

Remove the keys from the metadata of the VMs with deviations found:

curl -X POST -H "Authorization: Bearer <IAM_token>" \
  -d '{"delete":["<SSH_key_name>"]}' https://compute.api.cloud.yandex.net/compute/v1/instances/<VM_ID>/updateMetadata

1.7 Getting a token via AWS IMDSv1 is disabled on the VM1.7 Getting a token via AWS IMDSv1 is disabled on the VM

The cloud has a metadata service that provides information about VM performance.

From inside a VM, metadata is available in the following formats:

• Google Compute Engine (some fields are not supported).
• Amazon EC2 (some fields are not supported).

Amazon EC2 Instance Metadata Service version 1 (IMDSv1) has a number of drawbacks. The most critical of them is that there is a risk of compromising a service account token via the metadata service using a Server-Side Request Forgery (SSRF) attack. For more information, see the official AWS blog. Therefore, AWS has released IMDSv2, the second version of the metadata service.

So far, Yandex Cloud does not support version 2, so it is strongly recommended to technically disable getting a service account token via the Amazon EC2 metadata service.

The Google Compute Engine metadata service uses an additional header to protect against SSRF and enhance security.

You can disable getting a service account token via Amazon EC2 using the aws_v1_http_token:DISABLED VM parameter.

Guides and solutions to use:

Under metadata_options, set the aws_v1_http_token parameter to DISABLED for the found VMs:

yc compute instance update <VM_ID> \
  --metadata-options aws-v1-http-token=DISABLED

1.8 Service accounts have minimum privileges granted1.8 Service accounts have minimum privileges granted

Follow the principle of least privilege and assign to the service account only the roles necessary to run the application.

Guides and solutions to use:

Remove the unnecessary rights from the service account using IAM.

1.9 Only trusted administrators have access to service accounts1.9 Only trusted administrators have access to service accounts

You can grant permissions to use a service account under another user or service account.
Follow the principle of least privilege when granting access to a service account as a resource: if the user has service account permissions, they also have access to all of its permissions. Assign roles that allow using and managing service accounts to a minimum number of users.
Each service account with extended rights should be placed as a resource in a separate folder. It prevents accidental granting of rights to this account along with the rights to the folder with the respective service component.

Guides and solutions to use:

Remove the unnecessary service account rights using IAM.

1.10 Service account keys are rotated on a regular basis1.10 Service account keys are rotated on a regular basis

Yandex Cloud lets you create the following access keys for service accounts:

• IAM tokens that are valid for 12 hours.
• API keys with unlimited validity.
• Authorized keys with unlimited validity.
• AWS API-compatible static access keys with unlimited validity.

You need to rotate keys with unlimited validity yourself: delete and generate new ones. You can check out the date when a key was created in its properties. Perform key rotation at least once in 90 days as recommended in the information security standards, such as PCI DSS.

Guides and solutions to use:

Follow the guide for rotating keys depending on their type.

1.11 Two-factor authentication is set up for privileged accounts1.11 Two-factor authentication is set up for privileged accounts

We recommend using two-factor authentication (2FA) for cloud infrastructure access control to avoid the risk of compromising user accounts. Access to the Yandex Cloud management console can be based on 2FA.

To enable two-factor authentication, contact an identity provider that supports 2FA and set up a SAML-compliant identity federation. Yandex Cloud has no IdP of its own and user identification is done using external services, such as Yandex ID or corporate systems integrated via identity federations. For example, if you are using an IdP of Active Directory or Keycloak, set up 2FA in these systems. Make sure to set up 2FA at least for privileged cloud accounts.

For a Yandex ID account, set up 2FA using this guide.

Guides and solutions to use:

• Two-factor authentication: Yandex ID.
• KeyCloak: Creating other credentials.
• Configure Additional Authentication Methods for AD FS.

1.12 Privileged roles are only granted to trusted administrators1.12 Privileged roles are only granted to trusted administrators

Yandex Cloud privileged users include accounts with the following roles:

• billing.accounts.owner.
• admin assigned for a billing account.
• organization-manager.organizations.owner.
• organization-manager.admin.
• resource-manager.clouds.owner​.
• admin and editor assigned for an organization.
• admin and editor assigned for a cloud.
• admin and editor assigned for a folder.

The billing.accounts.owner role is granted automatically when creating a billing account and cannot be reassigned to another user. The role allows you to perform any action with the billing account.

The billing.accounts.owner role can only be assigned to a Yandex ID account. An account with the billing.accounts.owner role is used when setting up payment methods and adding clouds.

Make sure to properly secure this account: it offers significant privileges and cannot be federated with a corporate account.

The most appropriate approach would be to not use this account on a regular basis:

• Only use it for initial setup and updates.
• When actively using this account, enable two-factor authentication (2FA) in Yandex ID.
• After that, if you do not use the bank card payment method (only available for this role), set a strong password for this account (generated using specialized software), disable 2FA, and refrain from using this account unnecessarily.
• Change the password to a newly generated one each time you use the account.

We recommend disabling 2FA only for this account and if it is not assigned to a specific employee. Thus you can avoid linking this critical account to a personal device.

To manage a billing account, assign the admin or editor role for the billing account to a dedicated employee with a federated account.

To view billing data, assign the viewer role for the billing account to a dedicated employee with a federated account.

By default, the organization-manager.organizations.owner role is granted to the user who creates an organization: the organization owner. The role allows you to appoint organization owners as well as use all the administrator privileges.

The resource-manager.clouds.owner role is assigned automatically when you create your first cloud in the organization. A user with this role can perform any operation with the cloud or its resources and grant cloud access to other users: assign roles and revoke them.

Assign the resource-manager.clouds.owner and organization-manager.organizations.owner roles to one or more employees with a federated account. Set a strong password for the Yandex ID account that was used to create the cloud, and use it only when absolutely necessary (for example, if the federated access fails).

Make sure to fully protect your federated account that is granted one of the privileged roles listed above:

• Enable two-factor authentication.
• Disable authentication from devices beyond the company's control.
• Configure login attempt monitoring and set alert thresholds.

Assign federated accounts the admin roles for clouds, folders, and billing accounts. Minimize the number of accounts with these roles and regularly review the expedience of these roles for the accounts they are assigned to.

Guides and solutions to use:

If any roles granted to untrusted administrators are found, investigate why and remove the respective rights.

1.13 Strong passwords are set for local users of managed DBs1.13 Strong passwords are set for local users of managed DBs

To use a database at the application level, in addition to IAM service roles, a separate local user is created: the database owner. The following password policy applies to this user:

• The password must include numbers, uppercase letters, lowercase letters, and special characters.
• It must be at least 8 characters long.

1.14 Contractor and third-party access control is enabled1.14 Contractor and third-party access control is enabled

If you grant third-party contractors access to your clouds, make sure to follow these security measures:

• Assign permissions to contractor employees based on the principle of least privilege.
• If possible, create a separate account for third-party employees in your corporate IdP and assign the required policies to this account.
• Require them to handle their account secrets with care.
• Review the relevance of external user access to your cloud infrastructure.
• Use the auditor role without data access wherever possible.

1.15 The proper resource model is used1.15 The proper resource model is used

When developing an access model for your infrastructure, we recommend the following approach:

• At least one organization per company.
• Group resources by purpose and store them in separate folders. To ensure the strictest isolation, place them in a separate cloud.
• Place any critical resources in a separate folder or cloud. These include resources related to the processing of payment data, personal data, and trade secret data.
• Host the resource groups that require different administrative permissions in different folders or clouds (DMZ, CDE, security, backoffice, and so on).
• When developing apps, make sure to isolate test and production environments.
• Put shared resources (e.g., network and security groups) into a separate shared resource folder (if you separate components into folders).

1.16 There is no public access to your organization resources1.16 There is no public access to your organization resources

Yandex Cloud allows you to grant public access to your resources. You can grant public access by assigning access permissions to public groups (All authenticated users, All users).

Public group details:

• All authenticated users: All users who have authenticated. These are all registered users or Yandex Cloud service accounts: both from your clouds and other users' clouds.
• All users: Any user. No authentication is required.

Make sure that these groups have no public access to your resources: clouds, folder, buckets, and more.

Guides and solutions to use:

If All users and All authenticated users have access permissions, you need to delete these permissions.

1.17 Contact information of the person in charge of an organization is valid1.17 Contact information of the person in charge of an organization is valid

When registering a cloud in Yandex Cloud, customers enter their contact information. For example, an email address is used for notifications about incidents, scheduled maintenance activities, and so on.

For instance, if abnormal activities in the customer's organization are detected on the cloud side or the IAM cloud keys get available in external GitHub repositories, the customer receives a notification. This feature is implemented thanks to Yandex Cloud participating in the Github Secret scanning partner program and analyzing secrets in Yandex search. If any keys are compromised in a public repository, delete the secret from the repository and its history, as well as revoke the keys.

Make sure the contact information is valid and messages are sent to multiple persons in charge from the specified email address.

Guides and solutions to use:

Specify up-to-date contact information using the guide.

1.18 The cookie lifetime in a federation is less than 6 hours1.18 The cookie lifetime in a federation is less than 6 hours

In the identity federation settings, make sure the Cookie lifetime parameter value is less than or equal to 6 hours. Thus you minimize the risk of compromising cloud users' workstations.

Guides and solutions to use:

Set the Cookie lifetime to 6 hours (21600 seconds) or less.

1.19 Tokens for cloud functions and VMs are issued via service accounts1.19 Tokens for cloud functions and VMs are issued via service accounts

To get an IAM token when executing a function, assign a service account to the function. 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. Do the same for your VMs.

1.20 Impersonation is used wherever possible1.20 Impersonation is used wherever possible

Impersonation allows a user to perform actions under a service account and to temporarily extend user permissions without generating static credentials for the user. It may be useful for use cases such as duty, local development, or permission verification.

Guides and solutions to use:

If the iam.serviceAccounts.tokenCreator role is missing, set up impersonation for service accounts to provide temporary access to critical data by following this guide.

1.21 Resource labels are used1.21 Resource labels are used

Labels are required to monitor data streams and tag critical resources for privilege management.
For example, for tagging resources involved in processing personal data under Federal Law No. FZ-152 of the Russian Federation on Personal Data, select the 152-fz:true label for:

• Folders
• Yandex Object Storage buckets
• Yandex Lockbox secrets
• Managed DB clusters

Guides and solutions to use:

Guide on managing labels

1.22 Yandex Cloud security notifications are enabled1.22 Yandex Cloud security notifications are enabled

To get notifications of security-related events, such as vulnerability detection and elimination, we recommend selecting security notifications in the management console.

Guides and solutions to use:

1. Make sure that notifications are set up.
2. Enable the Security option in the notification settings in the management console.

1.23 The auditor role is used to prevent access to user data1.23 The auditor role is used to prevent access to user data

Assign the auditor role to users that do not require data access, such as external contractors or auditors.
auditor is a role with least privilege without access to service data. It grants permission to read service configurations and metadata.
The auditor role allows you to perform the following operations:

• View information about a resource.
• View resource metadata.
• View a list of operations with a resource.

To control access more selectively and implement the principle of least privilege, use the auditor role by default.

Guides and solutions to use:

1. Assign the auditor role to users requiring no data access.
2. Remove the unnecessary account rights using IAM.

2. Network security2. Network security

This section provides users with recommendations on security settings in Yandex Virtual Private Cloud.

To isolate applications from each other, put resources in different security groups, and, if strict isolation is required, in different networks. By default, internal network traffic is allowed, while traffic between networks is not. Traffic between networks is only allowed via a VM with two network interfaces in different networks, VPN, or Yandex Cloud Interconnect.

2.1 Cloud objects use a firewall or security groups2.1 Cloud objects use a firewall or security groups

With built-in security groups, you can manage VM access to resources and security groups in Yandex Cloud or resources on the internet. A security group is a set of rules for incoming and outgoing traffic that can be assigned to a VM's network interface. Security groups work like a stateful firewall: they monitor the status of sessions and, if a rule allows a session to be created, they automatically allow response traffic. See the guide on how to set up security groups in Creating a security group. You can specify a security group in the VM settings.

You can use security groups to protect:

• VMs
• Managed databases
• Yandex Application Load Balancer load balancers
• Yandex Managed Service for Kubernetes clusters

The list of available services is being extended.

You can manage network access without security groups, for example, using a separate VM as a firewall based on an NGFW image from Yandex Cloud Marketplace or a custom image. Using the NGFW can be critical to customers if they need the following features:

• Logging network connections.
• Streaming traffic analysis for malicious content.
• Detecting network attacks by signature.
• Other features of conventional NGFW solutions.

Make sure you use security groups in your clouds on each cloud object, or a separate VM based on the NGFW from Cloud Marketplace, or the Bring Your Own Image (BYOI) approach that allows you to deploy your own equipment or system images.

Guides and solutions to use:

• Apply security groups to any objects that have no group.
• To apply security groups through Terraform, set up security groups (dev/stage/prod) using Terraform.
• To use the NGFW, install the Check Point NGFW on your VM.
• Refer to this guide on using the UserGate NGFW in the cloud.
• Use NGFW in active-passive mode.

2.2 Virtual Private Cloud has at least one security group2.2 Virtual Private Cloud has at least one security group

To apply security groups to your cloud objects in Virtual Private Cloud, make sure there is at least one security group. You can also create a default security group that will be assigned to cloud objects when connecting to subnets if they have no security group. Make sure that each network has at least one security group.

Guides and solutions to use:

Create a security group in each Virtual Private Cloud with restricted access rules, so that it can be assigned to cloud objects.

2.3 Security groups have no access rule that is too broad2.3 Security groups have no access rule that is too broad

A security group lets you grant network access to absolutely any IP address on the internet as well as across all port ranges. A dangerous rule looks as follows:

• Port range: 0-65535 or empty.
• Protocol: Any or TCP/UDP.
• Source: CIDR.
• CIDR blocks: 0.0.0.0/0 (access from any IP address) or ::/0 (ipv6).

Make sure to only allow access through the ports that your application requires to run and from the IPs to connect to your objects from.

Guides and solutions to use:

Delete the dangerous rule in each security group or edit it by specifying trusted IPs.

2.4 Access through control ports is only allowed for trusted IPs2.4 Access through control ports is only allowed for trusted IPs

We recommend that you only allow access to your cloud infrastructure through control ports from trusted IP addresses. Make sure your access rules specified in the security group contain no broad rules that allow access through control ports:

• Port range: 22, 3389, or 21.
• Protocol: TCP.
• Source: CIDR.
• CIDR blocks: 0.0.0.0/0 (access from any IP address) or ::/0 (ipv6).

Guides and solutions to use:

Delete the dangerous rule in each security group or specify trusted IPs.

2.5 DDoS protection is enabled2.5 DDoS protection is enabled

Yandex Cloud has basic and extended DDoS protection. Make sure to use at least basic protection.

• Yandex DDoS Protection is the Virtual Private Cloud component that safeguards cloud resources from DDoS attacks. DDoS Protection is provided in partnership with Qrator Labs. You can enable it yourself for an external IP address through cloud administration tools. Supported up to OSI L4.
• Advanced protection against DDoS attacks operates at Levels 3 and 7 of the OSI model. You can also follow load and attack parameters and enable Solidwall WAF in your Qrator Labs account. To enable advanced protection, contact your manager or technical support.

Guides and solutions to use:

• All materials about DDoS protection in Yandex Cloud.

2.6 Protected remote access is used2.6 Protected remote access is used

To enable administrators to establish remote connections to your cloud resources, use one of the following:

• Site-to-site VPN between a remote site, e.g., your office, and a cloud. As a remote access gateway, use a VM featuring a site-to-site VPN based on an image from Cloud Marketplace.

  Setup options:

  • Creating an IPsec VPN tunnel using the strongSwan.
  • Creating a site-to-site VPN connection to Yandex Cloud using Terraform.
  • Client VPN between remote devices and Yandex Cloud. As a remote access gateway, use a VM featuring a client VPN based on an image from Cloud Marketplace.

  See the details in the Creating a VPN connection using OpenVPN section. You can also use certified data cryptographic security tools.

• Dedicated private connection between a remote site and Yandex Cloud using Cloud Interconnect.

To access the infrastructure using control protocols (such as SSH or RDP), create a bastion VM. You can do this using a free Teleport solution. Access to the bastion VM or VPN gateway from the internet must be restricted.

For better control of administrative actions, we recommend that you use PAM (Privileged Access Management) solutions that support administrator session logging (for example, Teleport). For SSH and VPN access, we recommend that you avoid using passwords and use public keys, X.509 certificates, and SSH certificates instead. When setting up SSH for your VMs, we recommend that you use the SSH certificates (including for the SSH host).

To access web services deployed in the cloud, use TLS version 1.2 or higher.

2.7 Outbound internet access control is performed2.7 Outbound internet access control is performed

Possible options for setting up outbound internet access:

• Public IP address. Assigned to a VM according to the one-to-one NAT rule.
• Egress NAT (NAT gateway). Enables internet access for a subnet through a shared pool of Yandex Cloud public IP addresses. We do not recommend using Egress NAT for critical interactions, since the NAT gateway's IP address might be used by multiple clients at the same time. This feature must be taken into account when modeling threats for your infrastructure.
• NAT instance. The NAT function is performed by a separate VM. You can create this VM using a NAT instance image from Cloud Marketplace.

Comparison of internet access methods:

Regardless of which option you select for setting up outbound internet access, be sure to limit traffic using one of the mechanisms described above. To build a secure system, use static IP addresses, since they can be added to the list of exceptions of the receiving party's firewall.

Guides and solutions to use:

• If any VM has public IPs, make sure they are required. Otherwise, delete an external IP address in the VM settings.
• If any NAT-Gateway is found, make sure it is required. Otherwise, delete it.
• If any NAT instance is found, make sure it is required. Otherwise, delete it.

2.8 DNS queries are not passed to third-party recursive resolvers2.8 DNS queries are not passed to third-party recursive resolvers

To increase fault tolerance, some traffic may be routed to third-party recursive resolvers. To avoid this, contact support.

3. Secure configuration of a virtual environment3. 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.

OverviewOverview

3.1 A serial console is either used under control or not used3.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.

We do not recommend using access to the serial console unless it is absolutely necessary.

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

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 practices3.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 running terraform plan and terraform 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.

Scan your Terraform manifests using Checkov with Yandex Cloud support.

• Example: Scanning .tf files with Checkov
• Example: Storing a Terraform state in Object Storage.

3.4. Integrity control is performed3.4. Integrity control is performed

3.4.1 File integrity control3.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:

• Wazuh
• Osquery

Paid solutions are also available in Yandex Cloud marketplace, such as Kaspersky Security.

3.4.2 Integrity control of a VM runtime environment3.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.

3.5 Principles of protection against side-channel attacks are used3.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 about side-channel attack protection in cloud environments.

Yandex Object StorageYandex Object Storage

3.6 No public access to a Object Storage bucket is allowed3.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:

• IAM verification
• Bucket policy
• Access Control Lists (ACLs)

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

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

Guides and solutions to use:

Enable the required policy.

3.8 In Object Storage, the Object locks feature is enabled3.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.

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 enabled3.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 up3.10 In Object Storage, Cross-Origin Resource Sharing (CORS) is set up

If cross-domain requests to objects in buckets are required, the customer should configure the CORS policy in accordance with the customer's information security requirements. For more information, see the Object Storage documentation, CORS configuration of buckets.

Guides and solutions to use:

Set up CORS.

Managed Services for DatabasesManaged Services for Databases

3.11 A security group is assigned in managed databases3.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.

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

Guides and solutions to use:

Disable public access if it is not required.

3.13 The deletion protection feature is enabled3.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.

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.14 The setting that enables access from DataLens is not activated unless needed3.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.

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.15 Access from the management console is disabled in managed databases3.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.

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 GatewayCloud Functions and Yandex API Gateway

3.16 Public cloud functions are only used in exceptional cases3.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.

Guides and solutions to use:

Disable public access.

3.17 Side-channel attacks in Cloud Functions are considered3.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.

3.18 Specifics of time synchronization in Cloud Functions are considered3.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 considered3.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 network3.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.

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 YDBManaged Service for YDB

3.21 Recommendations for using confidential data in YDB are followed3.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 option.

3.22 Recommendations for SQL injection protection in YDB are followed3.22 Recommendations for SQL injection protection in YDB are followed

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.23 No public access to YDB is allowed3.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.

Guides and solutions to use:

Disable public access if it is not required.

3.24 Recommendations for YDB backups are followed3.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 RegistryYandex Container Registry

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

Guides and solutions to use:

Specify the IP addresses for registry access.

Yandex Container SolutionYandex 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.

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.26 A Yandex Certificate Manager certificate is valid for at least 30 days3.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.

Guides and solutions to use:

Update the certificate or set up auto updates.

Yandex Managed Service for GitLabYandex Managed Service for GitLab

3.27 Recommendations on security settings for a GitLab instance are followed3.27 Recommendations on security settings for a GitLab instance are followed

See the recommendations here.

3.28 Antivirus protection is used3.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.

Guides and solutions to use:

Follow the vendor guide to install the AV solution.

3.29 Yandex Managed Service for Kubernetes security recommendations are used3.29 Yandex Managed Service for Kubernetes security recommendations are used

Check the recommendations in Security Kubernetes.

4. Data encryption and key management4. Data encryption and key management

IntroductionIntroduction

Yandex Cloud provides built-in encryption features for a number of services. It is the customer's responsibility to enable encryption in these services and implement encryption in other components for processing critical data. Data encryption and encryption key management are performed by Key Management Service (KMS).

Yandex Cloud APIs support cipher suites in specific TLS versions that are compliant with PCI DSS and other standards.

Encryption at restEncryption at rest

By default, all user data at rest is encrypted at the Yandex Cloud level. Encryption at the Yandex Cloud level implements one of the best practices for protecting user data and is performed using Yandex Cloud keys.

If your corporate information security policy sets specific key size and rotation frequency requirements, you can encrypt data with your own keys. To do this, you can use the KMS service and its integration with other Yandex Cloud services or implement data plane encryption completely on your own.

Yandex Cloud provides data-at-rest encryption for the following services:

• Object Storage.
• Managed Service for Kubernetes.

4.1 In Yandex Object Storage, encryption of data at rest using KMS keys is enabled4.1 In Yandex Object Storage, encryption of data at rest using KMS keys is enabled

To protect critical data in Yandex Object Storage, we recommend using bucket server-side encryption with Yandex Key Management Service keys. This encryption method protects against accidental or intentional publication of the bucket content on the web. For more information, see Encryption in the Object Storage documentation.

Guides and solutions to use:

Configure bucket encryption using the guide.

Encryption in transitEncryption in transit

In most cases, you can only connect to Yandex Cloud services over HTTPS. However, some scenarios allow data plane access to services over HTTP, without connection encryption at the application level. In all these scenarios, the user can choose the protocol to be used for data plane operations (HTTP or HTTPS) in the service settings, and specify their own TLS certificate if HTTPS is selected.

Yandex Cloud allows you to use your own TLS certificates for the following services:

• Object Storage.
• Application Load Balancer.
• API Gateway.
• Cloud CDN.

4.2 HTTPS is enabled for hosting static websites in Yandex Object Storage4.2 HTTPS is enabled for hosting static websites in Yandex Object Storage

Object Storage supports secure connections over HTTPS. You can upload your own security certificate if a connection to your Object Storage website requires HTTPS access. Integration with Certificate Manager is also supported. See the instructions in the Object Storage documentation:

• Configuring HTTPS
• Bucket

When using Object Storage, make sure that support for TLS protocols below version 1.2 is disabled at the client level. Use the bucket policy aws:securetransport to ensure that running without TLS is disabled for the bucket.

Guides and solutions to use:
Enable access over HTTPS if a bucket is used for hosting a static website.

4.3 Yandex Application Load Balancer uses HTTPS4.3 Yandex Application Load Balancer uses HTTPS

Application Load Balancer supports an HTTPS listener with a certificate uploaded from Certificate Manager. See how to set up the listener in the Yandex Application Load Balancer documentation.

Guides and solutions to use:

Enable an HTTPS listener using the instructions.

4.4 Yandex API Gateway uses HTTPS and its own domain4.4 Yandex API Gateway uses HTTPS and its own domain

API Gateway supports secure connections over HTTPS. You can link your own domain and upload your own security certificate to access your API gateway over HTTPS.

Guides and solutions to use:

1. In the management console, select the cloud or folder to enable domains and certificates in.
2. In the list of services, select API Gateway → Gateway settings → Domains.
3. Enable the domains and certificates.

4.5 Yandex Cloud CDN uses HTTPS and its own SSL certificate4.5 Yandex Cloud CDN uses HTTPS and its own SSL certificate

Cloud CDN supports secure connections to origins over HTTPS. You can also upload your own security certificate to access your CDN resource over HTTPS.

Guides and solutions to use:

Enable a certificate and HTTPS using the instructions.

Providing encryption on your ownProviding encryption on your own

When using services without built-in encryption, it is the customer's responsibility to ensure that critical data is encrypted.

4.6 For critical VMs, disk encryption using KMS is set up4.6 For critical VMs, disk encryption using KMS is set up

If disk encryption is required, place your application files on a VM's secondary disk (not the boot disk) and configure full disk encryption for it.

Guides and solutions to use:

VM disk encryption using KMS.

4.7 For critical data, MDB encryption with KMS is used4.7 For critical data, MDB encryption with KMS is used

If data encryption is required, make sure to encrypt data at the application level prior to writing it to a database, for example, using KMS and an add-on, such as pgcrypto.

yc managed-postgresql database get <database_name> --cluster-id <managed_postgre_cluster_id> --format=json | jq -r '.extensions | .[].name'

Guides and solutions to use:

You can learn how to encrypt data in Yandex Managed Service for PostgreSQL and Yandex Managed Service for Greenplum® using pgcrypto in Using pgcrypto in Managed Service for Greenplum®.

4.8 Data encryption at the application level is used4.8 Data encryption at the application level is used

For client-side encryption before uploading data to a Yandex Object Storage bucket, you can use the following approaches:

• Integrating Object Storage with the Key Management Service service for client-side encryption. For more information, see "Recommended cryptographic libraries".
• Using third-party client-side encryption libraries prior to sending data to Object Storage. If you use third-party data encryption libraries and your own key management methods, make sure your operation model, algorithms, and key sizes comply with regulatory requirements.

For client-side encryption, we recommend that you use the following libraries:

• AWS Encryption SDK and its KMS integration.
• Google Tink and its KMS integration.
• Yandex Cloud SDK with any other cryptographic library compatible with PCI DSS or any standards used in your company.

For a comparison of libraries, see the KMS documentation, Which encryption method should I choose?.

Managing keysManaging keys

We recommend that you use Key Management Service for encrypting data and managing keys. KMS helps you protect data in the Yandex Cloud infrastructure. You can also use it to encrypt or decrypt any of your data.

KMS uses AES-GCM encryption mode. You can select the key length (128, 192, or 256 bits) and set up the preferred key rotation period.

4.9 Key Management Service keys are stored in a hardware security module (HSM)4.9 Key Management Service keys are stored in a hardware security module (HSM)

In production environments, we recommend using separate keys whose every cryptographic operation will only be handled inside a HSM. For more information, see Hardware security module (HSM).

To use the HSM, when creating a key, select AES-256 HSM as the algorithm type. The HSM will handle all operations with this key internally, and no additional actions are required.

We recommend using HSMs for KMS keys to enhance the security level.

Guides and solutions to use:

Set the encryption algorithm for KMS keys to AES-256 HSM.

4.10 Permissions to manage keys in KMS are granted to users under control4.10 Permissions to manage keys in KMS are granted to users under control

To access the KMS service, you need an IAM token.

To automate operations with KMS, we recommend that you create a service account and run commands and scripts under it. If you use VMs, get an IAM token for your service account using the mechanism of assigning a service account to your VM. For other ways to get an IAM token for your service account, see the IAM documentation,  Getting an IAM token for a service account.

We recommend that you grant granular permissions for specific keys in the KMS service to your users and service accounts. For more information, see the KMS documentation, Access management in Key Management Service.

For more information about security measures for access control, see Authentication and access control.

To check the KMS key access permissions, check who has access permissions for:

• Organization, cloud, and folders with the admin, editor, kms.admin, kms.editor, and kms.keys.encrypterDecrypter permissions.
• kms.keys.encrypterDecrypter and kms.editor keys.

Guides and solutions to use:

Check out who is granted access to KMS keys.

4.11 For KMS keys, rotation is enabled4.11 For KMS keys, rotation is enabled

To improve the security of your infrastructure, we recommend that you categorize your encryption keys into two groups:

• Keys for services that process critical data but do not store it, e.g., Message Queue and Cloud Functions.
• Keys for services that store critical data, e.g., Managed Services for Databases.

For the first group, we recommend that you set up automatic key rotation with a rotation period longer than the data processing period in these services. When the rotation period expires, the old key versions must be deleted. In the case of automatic rotation and the deletion of old key versions, previously processed data cannot be restored and decrypted.

For data storage services, we recommend that you either manually rotate keys or use automatic key rotation, depending on your internal procedures for processing critical data.

A secure value for AES-GCM mode is encryption using 4294967296 (= 2³²) blocks. Having reached this number of encrypted blocks, you need to create a new DEK version. For more information about the AES-GCM operating mode, see the NIST materials.

For more information about key rotation, see the KMS documentation, Key version.

Guides and solutions to use:

Set the key rotation period.

4.12 Make sure that deletion protection is enabled for KMS keys4.12 Make sure that deletion protection is enabled for KMS keys

Deleting a KMS key always means destroying data. Therefore, make sure to protect the keys against accidental deletion. KMS has the necessary feature.

Guides and solutions to use:

Enable deletion protection.

Managing secretsManaging secrets

Do not use critical data and access secrets, such as authentication tokens, API keys, and encryption keys, explicitly in the code, cloud object names and descriptions, VM metadata, etc. Instead, use secret storage services, such as Lockbox or HashiCorp Vault.

4.13 The organization uses Yandex Lockbox for secure secret storage4.13 The organization uses Yandex Lockbox for secure secret storage

Do not use critical data and access secrets, such as authentication tokens, API keys, and encryption keys, explicitly in the code, cloud object names and descriptions, VM metadata, etc. Instead, use secret storage services, such as Lockbox or HashiCorp Vault (from Cloud Marketplace).

Lockbox securely stores secrets in an encrypted form only. Encryption is performed using KMS. For secret access control, use service roles.

You can learn how to use the service in the Lockbox documentation.

Vault allows you to use KMS as a trusted service for encrypting secrets. This is implemented through the Auto Unseal mechanism.

To store secrets with Vault, you can use a VM based on an image from Cloud Marketplace with a pre-installed HashiCorp Vault build and Auto Unseal support. You can find the guide on setting up Auto Unseal in the KMS documentation, Auto Unseal in Hashicorp Vault.

Guides and solutions to use:

Store secrets in Lockbox or Hashicorp Vault from Marketplace.

4.14 For Serverless Containers and Cloud Functions, Lockbox secrets are used4.14 For Serverless Containers and Cloud Functions, Lockbox secrets are used

When working with Serverless Containers or Cloud Functions, it is often necessary to use a secret (such as a token or password).

If you specify secret information in environment variables, it can be viewed by any cloud user with permissions to view and use a function, which causes information security risks.

We recommend using Serverless integration with Lockbox for that. You can use a specific secret from Yandex Lockbox and a service account with access rights to this secret to use it in a function or container.

Make sure that the secrets are used as described above.

Guides and solutions to use:

Delete the secret data from env and use the Lockbox integration functionality.

4.15 When working with Container Optimized Image, secret encryption is used4.15 When working with Container Optimized Image, secret encryption is used

KMS supports the encryption of secrets used in a Terraform configuration, e.g., for transferring secrets to a VM in encrypted form. See the Encrypting secrets in Hashicorp Terraform section of the KMS documentation. It is not safe to openly transmit secrets through environment variables, because they are displayed in the VM properties.

Guides and solutions to use:

Encrypting secrets in Terraform to transfer them to a VM from a Container Optimized Image.

For other recommendations on how to use Terraform safely, see Secure configuration: Terraform.

4.16 There is a guide for cloud administrators on what to do if their cloud secrets are compromised4.16 There is a guide for cloud administrators on what to do if their cloud secrets are compromised

In Yandex Cloud, the Secret Scanning Service is enabled for everyone by default.
It detects structured cloud secrets that are available in the public domain in the following sources:

• Public GitHub repositories
• Yandex search index
• Helm charts in the Kubernetes marketplace

The following cloud secrets are detected:

• Yandex Cloud Session Cookie
• Yandex Cloud IAM token
• Yandex Cloud API Key
• Yandex Passport OAuth token
• Yandex Cloud AWS API compatible Access Secret
• (NEW) Yandex Cloud SmartCaptcha Server Key
• (NEW) Lockbox structured secrets

The service automatically notifies a customer of any found secrets belonging to their infrastructure:

• By email
• Using Yandex Audit Trails events

Guides and solutions to use:

Make sure that:

• Contact information of the person in charge of an organization is valid.
• Yandex Audit Trails is enabled at the organization level.
• The administrator has read the guide to follow if secrets are compromised.

5. Collecting, monitoring, and analyzing audit logs5. Collecting, monitoring, and analyzing audit logs

IntroductionIntroduction

An audit log is a record of all events in the system, including access to it and operations performed. By collecting and verifying audit logs, you can monitor compliance with the established security procedures and standards and identify vulnerabilities in your security mechanisms.

Events in audit logs occur on different levels:

• Yandex Cloud level: Events that occur with Yandex Cloud resources.
• OS level.
• Application level.
• Network level (Flow Logs).

5.1 Yandex Audit Trails is enabled at the organization level5.1 Yandex Audit Trails is enabled at the organization level

The main tool for collecting Yandex Cloud level logs is Yandex Audit Trails. This service allows you to collect audit logs about events happening to Yandex Cloud resources and upload these logs to Yandex Object Storage buckets or Cloud Logging log groups for further analysis or export. See this guide on how to start collecting logs. You can also learn more about the event format or check out the event reference.

To collect metrics, analyze Yandex Cloud-level events, and set up notifications, we recommend using Yandex Monitoring. It helps you track, for example, a sharp increase in the load on Compute Cloud, the number of Application Load Balancer requests per second (RPS), or significant changes in event statistics in Identity and Access Management.

You can also use Monitoring to monitor the health of the Audit Trails service itself and track security events. You can export metrics to a SIEM system via the API, see the instructions.

Solution: Monitoring Audit Trails and security events using Monitoring

You can export audit logs to a Cloud Logging or Data Streams log group and to a customer's SIEM system to analyze information about events and incidents.

List of important Yandex Cloud-level events to search for in audit logs:

Solution: Searching for important security events in audit logs

You can enable Yandex Audit Trails at the folder, cloud, and organization level. We recommend enabling Yandex Audit Trails at the level of the entire organization. Thus you will be able to collect audit logs in a centralized manner, e.g., to a separate security cloud.

5.2 Yandex Audit Trails events are exported to SIEM systems5.2 Yandex Audit Trails events are exported to SIEM systems

Solutions for exporting Yandex Cloud audit logs are available for the following SIEM systems:

• ArcSight: Collecting, monitoring, and analyzing audit logs in ArcSight SIEM

• Splunk: Collecting, monitoring, and analyzing audit logs in Splunk SIEM

• MaxPatrol SIEM: Collecting, monitoring, and analyzing audit logs in MaxPatrol SIEM

• Wazuh: Collecting, monitoring, and analyzing audit logs in Wazuh

For more information about MaxPatrol, see this section.

You can set up export to any SIEM using GeeseFS or s3fs. These utilities allow mounting a Yandex Object Storage bucket as a VM local disk. Next, you need to install a SIEM connector on your VM and configure reading JSON files from the bucket. You can also use utilities compatible with AWS Kinesis datastreams if sending audit logs to Yandex Data Streams.

If you have no SIEM, you can also analyze audit logs manually using one of the following methods (in descending order of convenience):

• Searching for Yandex Cloud events in Yandex Query.

• Searching for Yandex Cloud events in Cloud Logging.

• Searching for Yandex Cloud events in Object Storage.

5.3 Responding to Yandex Audit Trails events is set up5.3 Responding to Yandex Audit Trails events is set up

You can respond to Yandex Audit Trails events using your SIEM tools or manually. You can also use automatic responses.

Using Yandex Cloud Functions, you can configure alerts about Audit Trails events, as well as automatic responses to malicious actions, including removing dangerous rules or revoking access rights.

Solution: Notifications and responses to Audit Trails information security events using IAM / Cloud Functions + Telegram

5.4 Hardening of the Object Storage bucket that stores Yandex Audit Trails audit logs is done5.4 Hardening of the Object Storage bucket that stores Yandex Audit Trails audit logs is done

If you write Yandex Audit Trails audit logs to a Yandex Object Storage bucket, make sure the bucket is set up using best security practices, such as:

• 4.1 In Yandex Object Storage, encryption of data at rest using KMS keys is enabled.
• 3.8 In Yandex Object Storage, logging of actions with buckets is enabled.
• 3.8 In Yandex Object Storage, the Object locks feature is enabled.
• 3.7 In Yandex Object Storage, Bucket Policies are used.
• 3.6 No public access to the Yandex Object Storage bucket is allowed.

You can use a solution for secure Yandex Object Storage bucket setup with Terraform.

5.5 Audit logs are collected at the OS level5.5 Audit logs are collected at the OS level

When using IaaS cloud services and Kubernetes node groups, the customer is responsible for ensuring OS security and collecting OS-level events on their own. Free tools for collecting standard OS-generated events and exporting them to the customer's SIEM system include:

• Osquery
• Filebeat (ELK)
• Wazuh

Additional event generation options can be implemented using Auditd for Linux or Sysmon for Windows.

You can collect Linux system metrics (CPU, RAM, and disk space usage) with Unified Agent in Monitoring.

You can also export OS events to Cloud Logging using a Fluent Bit plugin or to Data Streams.

To describe events to be searched for in audit logs, we recommend using Sigma format, which is supported by popular SIEM systems. The Sigma repository contains a library of events described in this format.

To get the exact time of OS- and application-level events, configure clock synchronization by following this guide.

5.6 Audit logs are collected at the application level5.6 Audit logs are collected at the application level

Customers may collect events that occur at the level of applications deployed on Compute Cloud resources on their own. For example, save application logs to files and transfer them to a SIEM system using the tools listed in the subsection above.

5.7 Logs are collected at the network level5.7 Logs are collected at the network level

Currently, VPC network traffic event logs (Flow Logs) can only be collected by customers. You can use Yandex Cloud Marketplace solutions (such as NGFW, IDS/IPS, or network products) or free software for collecting and transmitting events. You can also collect network-level logs using different agents, e.g., HIDS.

6. Managing vulnerabilities6. Managing vulnerabilities

IntroductionIntroduction

Yandex Cloud is responsible for managing vulnerabilities and security updates in managed services. The client is responsible for managing vulnerabilities and security updates for all other system components.

For an example of the scope of responsibility for managing vulnerabilities and security updates, see Requirement 5 in the PCI DSS responsibility matrix.

6.1 A vulnerability scanner is used for container images6.1 A vulnerability scanner is used for container images

We recommend using the image vulnerability scanner integrated into Container Registry.

6.2 Vulnerability scanning is performed at the cloud IP level6.2 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:

• Nmap
• OpenVAS
• OWASP ZAP

Example of a free scanner that operates 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.

6.3 External security scans are performed according to the cloud rules6.3 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.

6.4 The process of security updates is set up6.4 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.

6.5 A Web Application Firewall is used6.5 A Web Application Firewall is used

To mitigate risks associated with web attacks, we recommend using a Web Application Firewall (WAF). A client can install and maintain a WAF independently or use the Yandex Smart Web Security WAF.

Installing a WAF on your ownInstalling a WAF on your own

WAF images are available from the Yandex Cloud Marketplace. License types and other required information are available in the product descriptions.

Solution: A fault-tolerant installation of PT Application Firewall built on Yandex Cloud

You can also install Wallarm WAF in Managed Service for Kubernetes. See the guide in the Wallarm documentation. This is a BYOL licensing model (a license purchased from a third-party vendor).

Yandex Smart Web Security WAFYandex Smart Web Security WAF

A client can use the Yandex Smart Web Security WAF. A web application firewall analyzes HTTP requests to a web app according to pre-configured rules. Based on the analysis results, certain actions are applied to HTTP requests.

You can manage the web application firewall using a WAF profile that connects to the security profile as a separate rule.

For more information about connecting to a security profile, see Getting started with a WAF profile.

7. Backups7. Backups

7.1 Cloud Backup or the scheduled snapshot mechanism is used7.1 Cloud Backup or the scheduled snapshot mechanism is used

Make sure that all VMs in your organization get backed up using:

• Scheduled snapshots.
• Cloud Backup.

8. Physical security8. Physical security

Yandex Cloud ensures the physical security of data centers. See a detailed description of its physical security measures.

If critical data is transmitted outside Yandex Cloud, the customer is responsible for managing physical access at all data processing locations.

9. Application security9. Application security

Recommendations for protecting your application against botsRecommendations for protecting your application against bots

9.1 Yandex SmartCaptcha is used9.1 Yandex SmartCaptcha is used

To mitigate the risks associated with automated attacks on applications, we recommend using Yandex SmartCaptcha. The service checks user requests with its ML algorithms and only shows challenges to those users whose requests it considers suspicious. You do not have to place the "I’m not a robot" button on the page.

Guides and solutions to use:

Guide on creating a CAPTCHA in Yandex SmartCaptcha.

Recommendations on building a secure pipelineRecommendations on building a secure pipeline

Yandex Cloud allows customers to achieve compliance of software they develop at all Supply-chain Levels for Software Artifacts (SLSA), provided that they follow the guidelines given in this section. When using Yandex Managed Service for GitLab, a customer automatically achieves SLSA Level 2 compliance.

9.2 Docker image scans on push to Yandex Container Registry9.2 Docker image scans on push to Yandex Container Registry

Auto scans of Docker images on push are critical for early detection and elimination of vulnerabilities to ensure secure deployment of containers. Reports on completed scans provide a brief description of detected vulnerabilities and issues and help you set priorities and eliminate security risks in containerized applications.

Guides and solutions to use:

Guide on scanning Docker images on push.

9.3 Regular scanning of Docker images stored in Container Registry9.3 Regular scanning of Docker images stored in Container Registry

Scheduled scanning of Docker images is an automated process that checks containerized images for vulnerabilities and compliance with security standards. Such scans are regular and automatic to ensure the consistency of image checks for vulnerabilities and maintain a high security level in the long run. Reports on completed scans provide a brief description of detected vulnerabilities and issues and help you set priorities and eliminate security risks in containerized applications.

We recommend setting up a schedule for scans to be run at least once a week.

Guides and solutions to use:

Guide on scheduled scanning of Docker images.

9.4 Containerized images used in production environments have the last scan date a week ago or less9.4 Containerized images used in production environments have the last scan date a week ago or less

Checking Docker images used in production environments with the last scan date not older than a week ensures that you continuously monitor and update security measures, eliminating potential vulnerabilities that might have occurred since the last scan. This also helps you make sure you are not deploying containers with recently detected vulnerabilities and enhance the security level. You can automate this process by setting up a schedule in the Vulnerability scanner.

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 REGISTRY_ID in $(yc container registry list --folder-id $FOLDER_ID --format=json | jq -r '.[].id');
do for IMAGE_ID in $(yc container image list --registry-id $REGISTRY_ID --format=json | jq -r '.[].id';)
do LAST_SCAN_DATE=$(yc container image get-last-scan-result --image-id $IMAGE_ID --format=json 2>/dev/null | jq -r '.scanned_at');
[ ! -z "$LAST_SCAN_DATE" ] && [ $(date --date "$LAST_SCAN_DATE" +'%s') -lt $(date --date '7 days ago' +'%s') ] && echo "Regitry ID - $REGISTRY_ID, Image ID - $IMAGE_ID, Last scan date - $LAST_SCAN_DATE"
done;
done;
done;
done

9.5 Software artifacts are built using attestations9.5 Software artifacts are built using attestations

Attestations are used when building software artifacts to ensure a secure and verifiable record of an artifact's origin, integrity, and SBOM compliance. This helps ensure the artifact reliability throughout its lifecycle. A software bill of materials (SBOM) is required to secure a supply chain, manage vulnerabilities, comply with requirements, assess risks, ensure transparency, and respond to incidents in an effective way.

With Managed Service for GitLab, attestations are easier to use, as the service has a feature for generating a provenance attestation. An SBOM can be generated using syft, a third-party software tool.

Guides and solutions to use:

Gitlab guide for software artifact attestation.

9.6 Ensuring artifact integrity9.6 Ensuring artifact integrity

Signing artifacts enhances security to ensure your software validity, integrity, reliability, and compliance with the requirements.

Guides and solutions to use:

You can sign artifacts within a pipeline using Cosign, a third-party command line utility for signing artifacts, images, and in-to-to attestations, and then upload them to Yandex Container Registry.

9.7 Artifacts are verified on deployment9.7 Artifacts are verified on deployment

To ensure the reliability, security, and compatibility of applications in Managed Service for Kubernetes, a service for automatic scaling and deployment of applications, you need to minimize the risk of issues, vulnerabilities, and failures during your application deployment and runtime. To do this, use signatures and signature verification in Managed Service for Kubernetes with Cosign and Kyverno.

Guides and solutions to use:

Guide on setting up the artifact signature.

9.8 Protected templates of a secure pipeline are used9.8 Protected templates of a secure pipeline are used

When working with Managed Service for GitLab, make sure you use built-in GitLab security mechanisms to secure your pipeline. The following options of pipeline usage are available for your projects:

• Creating a pipeline in an individual project and connecting it to other projects using the include function. Available for all license types.
• Using the Compliance framework and pipeline mechanism that you can run in any group project. Available for the Ultimate license.
• Copying pipeline sections to .gitlab-ci.yml files in your projects.

ClickHouse® is a registered trademark of ClickHouse, Inc.