Yandex Cloud infrastructure security standard 1.2

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

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:

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

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.

Standard structureStandard structure

The standard describes recommendations for the following security objectives:

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

Requirements and preparationRequirements and preparation

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 management1. Authentication and access management

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 and federated accounts are authenticated in their own systems. Yandex Cloud has no access to the passwords of these account users and only authenticates service accounts using 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 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.1.1 User group mapping is set up in an identity federation1.1.1 User group mapping is set up in an identity federation

In organizations with a lot of users, you may need to grant the same access permissions for Yandex Cloud resources to multiple users at once. In this case, it is more efficient to grant roles and permissions to a group rather than individually.

If you have configured user groups in your identity provider or plan to do so, set up user group mapping between the identity provider and Cloud Organization. Users in the identity provider's groups will be granted the same access permissions to Yandex Cloud resources as their respective groups in Cloud Organization.

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, only a Yandex ID account can have this role at the moment).
• Account with the organization-manager.organizations.owner and resource-manager.clouds.owner permissions, if used in emergencies only, e.g., when configuration of your federation fails. 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 for a group can manage other users' membership in that group. Users get these permissions in the following cases:

• User has the organization-manager.groups.memberAdmin role for the organization.
• User has the organization-manager.groups.memberAdmin role for a specific group as a resource.
• User has the organization-manager.organizations.owner or admin role or another privileged role for the whole organization.
• User has 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 permissions 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 a given service. You can see the list of all service roles in the Yandex Cloud roles 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 the service account to the VM and get the token via the metadata service.

• Additionally, set up the local firewall on the VM to allow access to the metadata service (IP address: 169.254.169.254) only to the appropriate processes and system users.

  Example of denying access to 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. You can store sensitive data 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 \
  --request POST \
  --header "Authorization: Bearer <IAM_token>" \
  --data '{"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 excessive permissions 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 permissions should be placed as a resource in a separate folder. It prevents accidental granting of permissions for this account along with the permissions for the folder with the respective service component.

Guides and solutions to use:

Remove the unnecessary service account permissions 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 allows you to create the following access keys for service accounts:

• IAM tokens that are valid for 12 hours.
• API keys: You can choose any validity period.
• 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, 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 and 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 permissions.

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 contain 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.
• Where possible, create a separate account for third-party employees in your corporate IdP and assign the relevant 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 authenticated users. 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 you detect that All users and All authenticated users have the access permissions that they should not have, remove 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 will get an IAM token by means of built-in Yandex Cloud tools so that you do not have to provide any secrets to the function externally. 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, to tag resources which handle personal data under Federal Law No. FZ-152 of the Russian Federation on Personal Data, select the 152-fz:true label for:

• Folder
• Yandex Object Storage bucket
• Yandex Lockbox secret
• 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 who do not need access to data, e.g., 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 excessive account permissions using IAM.

1.24 Tracking the date of last access key use in Yandex Identity and Access Management1.24 Tracking the date of last access key use in Yandex Identity and Access Management

To ensure security and control over access to resources, monitor cases of unauthorized use of keys, and delete unused keys without the risk of disrupting Yandex Cloud services, you can track the dates of last use of service account access keys. You can find this info on the service account page in the management console or in the last_used_at field when using the API to invoke access key management methods.

For more information, see Service account keys.

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. For a guide on how to set up security groups, see Creating a security group. You can specify a security group in the VM settings.

You can use security groups to protect:

• VM
• 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, e.g., by 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 NGFW on your VM: Check Point.
• 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 to 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 a 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 DDoS protection 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 guide in Creating a VPN connection using OpenVPN. 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 provided to third-party recursive resolvers2.8 DNS queries are not provided 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. 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.

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

• Specify sensitive = true for private information to prevent outputting it to the console when running the terraform plan and terraform apply commands.
• 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 followed3.5 Principles of protection against side-channel attacks are followed

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 does not 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, issue granular 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

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

Guides and solutions to use:

Set up CORS.

3.11 Use Yandex Security Token Service to get access keys to Object Storage3.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 buckets3.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 DatabasesManaged Services for Databases

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

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

Guides and solutions to use:

Disable public access if it is not required.

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

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

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

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

Guides and solutions to use:

Disable public access.

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

3.20 Special aspects of time synchronization in Cloud Functions are considered3.20 Special aspects 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 Special aspects of header management in Cloud Functions are considered3.21 Special aspects 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 network3.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.

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.23 Recommendations for using confidential data in YDB are addressed3.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 addressed3.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 allowed3.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.

Guides and solutions to use:

Disable public access if it is not required.

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

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

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

Guides and solutions to use:

Update the certificate or set up auto updates.

Yandex Managed Service for GitLabYandex Managed Service for GitLab

3.29 GitLab security guidelines are followed3.29 GitLab security guidelines are followed

See the recommendations here.

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

Guides and solutions to use:

Follow the vendor guide to install the AV solution.

3.31 Yandex Managed Service for Kubernetes security guidelines are used3.31 Yandex Managed Service for Kubernetes security guidelines are used

Check the recommendations in Security Kubernetes.

3.32 OS Login is used for connection to a VM or Kubernetes node3.32 OS Login is used for connection to a VM or Kubernetes node

OS Login is a convenient way to manage connections to VMs and Yandex Managed Service for Kubernetes cluster nodes via SSH through the YC CLI or via a standard SSH client with an SSH certificate or SSH key, which you first need to add to the OS Login profile of organization user or service account in Yandex Cloud Organization.

OS Login links the account of a virtual machine or Kubernetes node user with that 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 and 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 from a user or service account, they will lose access to all virtual machines and Kubernetes nodes with OS Login access enabled.

Guides and solutions to use:

• Enabling OS Login access at the organization level.
• Setting up OS Login access on an existing VM.
• Connect to the virtual machine via OS Login.
• Connecting to a Kubernetes node via OS Login.

3.33 Vulnerability scanning is performed at the cloud IP level3.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:

• Nmap
• OpenVAS
• OWASP ZAP

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.

3.34 External security scans are performed according to the cloud rules3.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.

3.35 The process of security updates is set up3.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.

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 in the service settings: HTTP or HTTPS, 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 aws:securetransport bucket policy to make sure 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. For information on how to set up the listener, see 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 data, MDB encryption with KMS is used4.6 For critical data, MDB encryption with KMS is used

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

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

Guides and solutions to use:

See Using pgcrypto in Managed Service for Greenplum® for instructions on how to encrypt data in Yandex Managed Service for PostgreSQL and Yandex Managed Service for Greenplum® using pgcrypto.

4.7 Data encryption at the application level is used4.7 Data encryption at the application level is used

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

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

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

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

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

4.8 Encryption of disks and virtual machine snapshots is used4.8 Encryption of disks and virtual machine snapshots is used

By default, all data on Yandex Compute Cloud disks is encrypted at the storage database level using a system key. This protects your data from being compromised in the event of a physical theft of disks from Yandex Cloud data centers.

We also recommend encrypting disks and disk snapshots using Yandex Key Management Service custom symmetric keys. This approach allows you to:

• Protect against the potential threats of data isolation breach and compromise at the virtual infrastructure level.
• Control the encryption and lifecycle of KMS keys, as well as manage them. For more information, see Key management.
• Improve access control to the data on your disk by setting permissions for KMS keys. For more information, see Configuring access permissions for a symmetric encryption key.
• Use Yandex Audit Trails to track encryption and decryption operations performed using your KMS key. For more information, see Key usage audit.

You can encrypt the following types of disks:

• Network SSD (network-ssd)
• Network HDD (network-hdd)
• Non-replicated SSD (network-ssd-nonreplicated)
• Ultra high-speed network storage with three replicas (SSD) (network-ssd-io-m3)

Guides and solutions to use:

Encrypt the disk of your Yandex Compute Cloud VM.

Managing keysManaging keys

We recommend using Key Management Service for data encryption and key management. Made to protect data in the Yandex Cloud infrastructure, KMS can also encrypt and decrypt any of your data.

KMS uses AES-GCM encryption mode. You can select the key length: 128/192/256 and set up the preferred key rotation period.

4.9 Key Management Service keys are stored in a hardware security module (HSM)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 controlled users4.10 Permissions to manage keys in KMS are granted to controlled users

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

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

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

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

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

• Organization, cloud, or folder (such permissions as admin, editor, kms.admin, kms.editor, or kms.keys.encrypterDecrypter)
• Keys (kms.keys.encrypterDecrypter and kms.editor)

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, such as Message Queue or Cloud Functions.
• Keys for services that store critical data, e.g., Managed Services for Databases.

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

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

A secure value for AES-GCM mode is encryption using 4294967296 (= 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 The deletion protection is enabled for KMS keys4.12 The deletion protection is enabled for KMS keys

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

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 Encrypting secrets in Hashicorp Terraform in the KMS documentation. It is not safe to openly provide secrets through environment variables, because they are displayed in the VM properties.

Guides and solutions to use:

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

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

4.16 There is a guide for cloud administrators on handling compromised secrets4.16 There is a guide for cloud administrators on handling compromised secrets

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

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

The following cloud secrets are detected:

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

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

• By email
• Using Yandex Audit Trails events

Guides and solutions to use:

Make sure that:

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

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.

There are different levels of audit log events:

• Yandex Cloud level: Events related to 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. For information on how to start collecting logs, see this guide.

Audit Trails audit logs may contain two types of events: management events and data events.

Management events are actions you take to configure Yandex Cloud resources, such as creating, updating, or deleting infrastructure components, users, or policies. Data events are updates and actions performed on data and resources within Yandex Cloud services. By default, Audit Trails does not log data events. You need to enable collection of data event audit logs individually for each supported service.

For more information, see Comparing management and data event logs.

To collect metrics, analyze Yandex Cloud-level events, and set up notifications, we recommend using Yandex Monitoring. For example, it can help you track spikes in Compute Cloud workload, Application Load Balancer RPS, or significant changes in Identity and Access Management event statistics.

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

5.8 Data events are monitored5.8 Data events are monitored

A data event audit log is a JSON object with a record of events related to Yandex Cloud resources. Data event monitoring makes it easier for you to collect additional events from cloud services and, as a result, effectively respond to security incidents in clouds. This also helps you ensure your cloud infrastructure meets regulatory requirements and industry standards. For example, you can keep track of your employees' access permissions to sensitive data stored in buckets.

6. Backups6. Backups

6.1 Use Cloud Backup or scheduled snapshots6.1 Use Cloud Backup or scheduled snapshots

Make sure to back up all VMs in your organization using one of these options:

• Scheduled snapshots
• Cloud Backup

7. Physical security7. 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.

8. Application security8. Application security

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

8.1 Use Yandex SmartCaptcha8.1 Use Yandex SmartCaptcha

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.

8.2 Implement scanning of Docker images when uploading them to Yandex Container Registry8.2 Implement scanning of Docker images when uploading them 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.

8.3 Schedule regular scanning of Docker images stored in Container Registry8.3 Schedule 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.

8.4 Make sure containerized images used in production environments have the last scan date of one week ago or less8.4 Make sure containerized images used in production environments have the last scan date of one 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

8.5 Use attestations when building software artifacts8.5 Use attestations when building software artifacts

Attestations used when building software artifacts help 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.

8.6 Ensure artifact integrity8.6 Ensure artifact integrity

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

Guides and solutions to use:

To sign artifacts within a pipeline, you can use Cosign, a third-party command line utility for signing artifacts, images, and in-to-to attestations. Then you can upload these artifacts to Yandex Container Registry.

A special build of Cosign allows you to store the created digital signature key pair in Yandex Key Management Service, sign files and artifacts with the private key of the pair, and verify a digital signature using its public key.

For more information, see Signing and verifying Container Registry Docker images in Yandex Managed Service for Kubernetes.

8.7 Verify artifacts on deployment8.7 Verify artifacts 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.

8.8 Use protected templates of a secure pipeline8.8 Use protected templates of a secure pipeline

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. This option is available for all license types.
• Using the Compliance framework and pipeline mechanism that you can run in any group project. It is available for the Ultimate license.
• Copying pipeline sections to .gitlab-ci.yml files in your projects.

8.9 Use a Yandex Smart Web Security security profile8.9 Use a Yandex Smart Web Security security profile

Yandex Smart Web Security is a service for protection against DDoS attacks and bots at application level L7 of the OSI model. Smart Web Security connects to Yandex Application Load Balancer.

In a nutshell, the service checks the HTTP requests sent to the protected resource against the rules configured in the security profile. Depending on the results of the check, the requests are forwarded to the protected resource, blocked, or sent to Yandex SmartCaptcha for additional verification.

Guides and solutions to use:

Creating a security profile and connecting it to a virtual host of an L7 load balancer.

8.10 Use a web application firewall8.10 Use a web application firewall

To mitigate risks associated with web attacks, we recommend using the Yandex Smart Web Security web application firewall (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 a security profile in Smart Web Security as a separate rule.

Guides and solutions to use:

Creating a WAF profile and connecting it to a security profile in Smart Web Security.

8.11 Use Advanced Rate Limiter8.11 Use Advanced Rate Limiter

Advanced Rate Limiter (ARL) is a module used to monitor and limit web app loads. The module allows you to set a limit on the number of HTTP requests over a certain period of time. All requests above the limit will be blocked. You can set a single limit for all traffic or configure specific limits to segment requests by certain parameters. For the purposes of limits, you can count requests one by one or group them together based on specified characteristics.

You need to connect your ARL profile to the security profile in Smart Web Security.

Guides and solutions to use:

Creating an ARL profile and connecting it to a security profile in Smart Web Security.

8.12 Set up approval rules8.12 Set up approval rules

With Yandex Managed Service for GitLab, you can flexibly set up mandatory approval rules for adding code to the target project branch. This feature is an alternative to the GitLab Enterprise Edition’s Approval Rules tool and is available regardless of the GitLab version.

If a GitLab instance has the approval rules enabled, Managed Service for GitLab analyzes approvals from reviewers for compliance with the specified rules. If there are not enough approvals, a thread is created in a merge request that blocks it from being merged to the target branch. Editing the merge request creates or updates a comment in the thread with its current compliance status. Once all the required approvals are obtained, the thread is closed.

If you close a thread manually, it will be created again. If a merge request is approved regardless of the existing rules, users with the Maintainer role or higher will receive an email notification about the violated code approval workflow.

Guides and solutions to use:

Enabling approval rules in the GitLab instance

9. Kubernetes security9. Kubernetes security

IntroductionIntroduction

Yandex Managed Service for Kubernetes provides an environment for managing containerized applications in Yandex Cloud infrastructure. Deploy, scale, and manage applications in containers using Kubernetes.

The user is responsible for all actions made inside the Kubernetes node. The user is responsible for the security of the nodes and their proper setup in accordance with PCI DSS requirements and other security standards.

Yandex Cloud is responsible for the Kubernetes API security.

The user is responsible for correctly choosing security settings in Managed Service for Kubernetes, including selecting the channel and the update schedule.

9.1 The use of sensitive data is limited9.1 The use of sensitive data is limited

To comply with PCI DSS or other security standards when using Managed Service for Kubernetes, do not:

• Use sensitive data in names and descriptions of clusters, node groups, namespaces, services, and pods.
• Use sensitive data in Kubernetes node labels and Yandex Cloud service resource labels.
• Use sensitive data in pod manifests.
• Use sensitive data in etcd in clear text.
• Write sensitive data to Managed Service for Kubernetes logs.

Guides and solutions to use:

Manually edit the names or contents of manifests and other configuration files if they use sensitive data.

9.2 Resources are isolated from each other9.2 Resources are isolated from each other

Wherever possible, ensure maximum isolation between resources:

• Use a separate organization for each "big" project.
• Use a separate cloud for each development team.
• Use a separate Kubernetes cluster located in a separate folder for each service.
• Use a separate namespace for each microservice.
• Your clouds must have no shared resources. Cloud members must have access only to their clouds.

Less strict isolation models are also possible, e.g., where:

• Projects are deployed in different clouds.
• Development teams use independent folders.
• Services have separate Kubernetes clusters.
• Microservices use different namespaces.

9.3 There is no access to the Kubernetes API and node groups from untrusted networks9.3 There is no access to the Kubernetes API and node groups from untrusted networks

We do not recommend granting access to the Kubernetes API and node groups from non-trusted networks, e.g., from the internet. Use firewall protection where needed (for example, security groups).

Guides and solutions to use:

• Guide on creating a cluster without internet access.

• Security group setup guide.

• Use network policy configuration tools via the Calico (basic) or Cilium CNI (advanced) plugins in Yandex Cloud. By default, apply the default deny rules for incoming and outgoing traffic with only the relevant traffic allowed.

• For online endpoints, allocate an independent Kubernetes cluster or independent node groups (using such mechanisms as Taints and Tolerations + Node affinity). By doing this, you establish a DMZ so that if your nodes are compromised online, your attack surface is small.

• To enable incoming network access to your workloads via HTTP/HTTPS, use the Ingress resource. There are at least two Ingress controller options that you can use in Yandex Cloud:

  • NGINX Ingress Controller.
  • Application Load Balancer of an Ingress controller.

9.4 Authentication and access management are configured in Managed Service for Kubernetes9.4 Authentication and access management are configured in Managed Service for Kubernetes

For the Kubernetes cluster to run, you need two service accounts: the service account of the cluster and the service account of the node group. The access of IAM accounts to Managed Service for Kubernetes resources is managed at the following levels:

• Managed Service for Kubernetes service roles (access to the Yandex Cloud API): These enable you to control clusters and node groups (for example, create a cluster, create/edit/delete a node group, and so on).
• Service roles to access the Kubernetes API: These let you control cluster resources via the Kubernetes API (for example, perform standard actions with Kubernetes: create, delete, view namespaces, work with pods, deployments, create roles, and so on). Only the basic global roles at the cluster level are available: k8s.cluster-api.cluster-admin, k8s.cluster-api.editor, and k8s.cluster-api.viewer.
• Primitive roles: These are global primitive IAM roles that include service roles (e.g., the primitive admin role includes both the service administration role and the administrative role to access the Kubernetes API).
• Standard Kubernetes roles: Inside the Kubernetes cluster itself, you can use Kubernetes tools to create both regular roles and cluster roles. Thus you can manage access for IAM accounts at the namespace level. To assign IAM roles at the namespace level, you can manually create RoleBinding objects in a relevant namespace stating the cloud user's IAM ID in the subjects name field.

9.5 Managed Service for Kubernetes uses a safe configuration9.5 Managed Service for Kubernetes uses a safe configuration

In Managed Service for Kubernetes, the user is fully in control of all node group settings, but only partially in control of the master settings. The user is responsible for the whole cluster's security.

The CIS Kubernetes Benchmark standard is designed to build a secure Kubernetes configuration, including node configurations. In Yandex Cloud, the Kubernetes node groups are deployed by default with the configuration that complies with CIS Kubernetes Benchmark.

9.6 Data encryption and Managed Service for Kubernetes secret management are done in ESO as a Service format9.6 Data encryption and Managed Service for Kubernetes secret management are done in ESO as a Service format

At the Kubernetes etcd level, encrypt secrets using an in-built mechanism from Yandex Cloud.

We recommend that you use SecretManager solutions to work with Kubernetes secrets. Yandex Lockbox is such a solution in Yandex Cloud.

Yandex Lockbox was integrated with Kubernetes using the External Secrets open-source project. In Cloud Marketplace, the solution is available in the basic simplified scenario: External Secrets Operator with Yandex Lockbox support.

The most secure recommended option for encrypting secrets is ESO as a Service (External Secrets Operator as a service). When using ESO, the global administrator has access to the namespace where ESO is installed, and administrators of individual namespaces create their own SecretStore objects (where they specify IAM-authorized access keys for their Lockbox secrets). If this SecretStore object is compromised, only the authorized key of one specific namespace is compromised (rather than all of them, as in the case of Shared ClusterSecretStore).

Guides and solutions to use:

• Guide on working with External Secrets and Yandex Lockbox from the project description.
• Guide on working with External Secrets and Yandex Lockbox from the Yandex Cloud documentation.

9.7 Docker images are stored in a Container Registry registry configured for regular image scanning9.7 Docker images are stored in a Container Registry registry configured for regular image scanning

To ensure effective security, we recommend using Container Registry to store Docker images to be deployed in Managed Service for Kubernetes. This allows you to quickly respond to new vulnerabilities in images using built-in recurrent vulnerability scanning.

You should perform vulnerability scanning at least once a week. This will help you detect and eliminate vulnerabilities in images in a timely manner, which significantly reduces risks of unauthorized access to your resources and increases security level of your infrastructure.

Using Container Registry to store images will also provide centralized image version control for simpler updates and security management.

Guides and solutions to use:

• Guide on scheduled scanning of Docker images.

9.8 One of the three latest Kubernetes versions is used, updates are monitored9.8 One of the three latest Kubernetes versions is used, updates are monitored

For Kubernetes, both automatic and manual updates are available for clusters and node groups. You can request a manual update of the Kubernetes cluster or its nodes to the latest supported version at any time. Manual updates bypass any configured maintenance windows and maintenance exceptions. Kubernetes issues updates in a regular manner. To meet the Information Security standards:

• Select a relevant update channel and enable either automatic installation of updates, or manual installation immediately after publication in the selected channel.
• Double-check that the ad settings meet the Information Security standards.
• Use one of the three latest Kubernetes versions, because updates (including security updates) are only released for these versions.

yc managed-kubernetes list-versions

Guides and solutions to use:

• Guide on how to update a cluster automatically.
• Guide on how to update a cluster manually.

9.9 Backup is configured9.9 Backup is configured

To ensure continuous operation and data protection, we recommend using backups in Managed Service for Kubernetes. With backups, you can quickly recover the service without experiencing any data or time loss in the wake of a malfunction or accident. Data in Kubernetes clusters is securely stored and replicated within the Yandex Cloud infrastructure. However, you can back up data from Kubernetes cluster node groups at any time and store them in Yandex Object Storage or other types of storage.

Guides and solutions to use:

You can create backups of Kubernetes cluster node group data using the Velero tool. It supports working with Yandex Cloud disks using the Kubernetes CSI driver and helps create snapshots of disks and volumes.

When working with Velero that is installed manually, you can use nfs, emptyDir, local, or any other type of volumes without built-in support for snapshots. To use such a volume type, install Velero with the restic plugin. Velero installed from Cloud Marketplace does not include the restic plugin.

• Guide on Kubernetes cluster backup in Object Storage.

9.10 Check lists are in place for security when creating and using Docker images9.10 Check lists are in place for security when creating and using Docker images

Secure Docker image creation and operation practices ensure protection against potential vulnerabilities, malware, and unauthorized access to data. They ensure image integrity and security compliance while also preventing potential threats coming from its deployment in the infrastructure. Use these check lists to meet requirements for secure creation of images:

• Dockerfile best practices.
• Kubernetes Security Checklist and Requirements.

You can control Dockerfile in your CI/CD pipeline using the Conftest utility.

When using minimal images or distroless images without a shell, we recommend using ephemeral containers.

9.11 The Kubernetes security policy is in place9.11 The Kubernetes security policy is in place

The requirements listed in Kubernetes Pod Security Standards allow you to prevent threats related to Kubernetes objects, such as unauthorized access to confidential data and execution of malicious code.

These requirements allow you to ensure security and reliability of applications in a Kubernetes cluster. To achieve compliance, you can either use the built-in Kubernetes tool called Pod Security Admission Controller or open-source software, e.g., OPA Gatekeeper or Kyverno.

Guides and solutions to use:

• You can also use the following tools within CI/CD to monitor compliance with the Pod Security Standards:

  • Kyverno CLI
  • The gator CLI

• Kubesec

9.12 Audit log collection is set up for incident investigation9.12 Audit log collection is set up for incident investigation

Events available to the user in the Managed Service for Kubernetes service can be classified as levels:

• Kubernetes API events (Kubernetes audit logging)
• Kubernetes node events
• Kubernetes pod events
• Kubernetes metrics
• Kubernetes flow logs

For more information about setting up audit event logging at various levels, see Collecting, monitoring, and analyzing Managed Service for Kubernetes audit logs.

In Managed Service for Kubernetes, you can audit the current role model used in the service. To do this, open the Kubernetes cluster page in the management console, and go to the Access management tab.

You can also use:

• KubiScan
• Krane
• Yandex Audit Trails events

ClickHouse® is a registered trademark of ClickHouse, Inc.