Yandex Cloud infrastructure security standard 1.2
Introduction
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
Scope
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
- Managed Service for Redis
- 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 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 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 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 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 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 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.
Tip
Use federated accounts instead of Yandex ID accounts whenever possible. Keep in mind that there is a separate role, organization-manager.federations.admin
, you can use to manage a federation.
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.
- Open the Yandex Cloud console in your browser.
- Go to All services → Yandex Cloud Organization → Federations.
- Make sure the list contains at least one identity federation configured. Otherwise, proceed to the
Guides and solutions to use
.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
View information about the federations configured:
yc organization-manager federation saml list \ --organization-id=<organization ID>
-
Make sure the list contains at least one identity federation configured. Otherwise, proceed to the
Guides and solutions to use
.
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 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 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
andresource-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 theorganization-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.
- Open the Yandex Cloud console in your browser.
- Go to All services → Yandex Cloud Organization → Users.
- If the Federation column is set to federation for all the accounts (but for those on the above list of exceptions allowed), the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for non-federated accounts in your organization, but for the ID of the account included in the list of valid exceptions:
yc organization-manager user list --organization-id=<organization ID> \ --format=json | jq -r '.[] | select(.subject_claims.sub!="<ID of account from list of allowed exceptions>")' | jq -r 'select(.subject_claims.federation | not)'
-
If there are no accounts in the list, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
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 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
oradmin
role or another privileged role for the whole organization. - User has the
admin
oreditor
role for a specific group as a resource (this is not recommended).
- Open the Yandex Cloud console in your browser.
- Go to All services → Yandex Cloud Organization → Groups → Select a group → Group access permissions.
- Toggle the Inherited roles switch.
- If the list does not contain any accounts that must have no permission to manage group membership, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
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 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 roll reference.
Use the auditor role without data access wherever possible.
- Open the Yandex Cloud console in your browser.
- Go to All services → Yandex Cloud Organization → Users.
- Make sure no accounts in the Access permissions column have these primitive roles:
admin
,editor
, orviewer
. Otherwise, proceed to theGuides and solutions to use
. - Next, go to the global cloud menu (click the cloud in the initial cloud menu). Select the Access permissions tab.
- Make sure no accounts in the Roles column have these primitive roles:
admin
,editor
, orviewer
. Otherwise, proceed to theGuides and solutions to use
. - Next, go to each folder of each cloud and, similarly, navigate to the Access permissions tab.
- Make sure no accounts in the Roles column have these primitive roles:
admin
,editor
, orviewer
. Otherwise, proceed to theGuides and solutions to use
.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for accounts with primitive roles assigned at the organization level:
export ORG_ID=<organization ID> yc organization-manager organization list-access-bindings \ --id=${ORG_ID} \ --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="editor" or .role_id=="viewer")'
-
If there are no accounts in the list, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
. -
Run the command below to search for accounts with primitive roles assigned at the cloud level:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="editor" or .role_id=="viewer")' done
-
If there are no accounts in the list, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
. -
Run the command below to search for accounts with primitive roles assigned at the level of all folders in your clouds:
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 yc resource-manager folder list-access-bindings --id=$FOLDER_ID --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="editor" or .role_id=="viewer")' done; done
-
If there are no accounts in the list, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
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 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.
- Open the Yandex Cloud console in your browser.
- Go to the appropriate folder and open the settings of the VM you need.
- Click Edit.
- The service account data is displayed.
- Repeat the steps for all VMs in all folders.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for VMs with assigned service accounts in your organization:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc compute instance get --id=$VM_ID --format=json | jq -r '. | select(.service_account_id)' | jq -r '.id' done; done; done
-
If there are no lines in the list or only accounted entities are output, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
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 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
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for cloud keys in the metadata service represented as plaintext, using the example of Yandex Cloud AWS API Compatible Access Secret:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc compute instance get --id=$VM_ID --full --format=json | jq -r '. | select(.metadata."user-data")| .metadata."user-data" | match("YC[a-zA-Z0-9_\\-]{38}") | .string' && echo $VM_ID done; done; done
-
If there are no lines in the list, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
. -
Run the command below to search for plaintext cloud keys in the metadata service. Here we use a Yandex Cloud IAM token as an example:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc compute instance get --id fhm2i4a72v44kdqaqhid --full --format=json | jq -r '. | select(.metadata."user-data")| .metadata."user-data" | match("t1\\.[A-Z0-9a-z_-]+[=]{0,2}\\.[A-Z0-9a-z_-]{86}[=]{0,2}") | .string' done; done; done
-
If there are no lines in the list, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
Guides and solutions to use:
Remove the keys from the metadata of the VMs with deviations found:
- In the management console
, select the folder the VM belongs to. - Select Compute Cloud.
- Click the VM name.
- In the top-right corner of the page, click
Edit VM. - Open the Metadata menu and remove the keys by clicking
.
If you do not have the Yandex Cloud command line interface yet, install and initialize it.
The folder specified in the CLI profile is used by default. You can specify a different folder using the --folder-name
or --folder-id
parameter.
-
View a description of the CLI command to remove metadata:
yc compute instance remove-metadata --help
-
Remove the keys:
yc compute instance remove-metadata <VM_ID> --keys <SSH_key_name>
To remove SSH keys from the VM metadata, use the updateMetadata REST API method for the Instance resource or the InstanceService/UpdateMetadata gRPC API call.
In your request, provide the delete
parameter with the SSH key.
REST API request example
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 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
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.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for VMs with IMDSv1 enabled for getting a token:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc compute instance get --id=$VM_ID --format=json | jq -r '. | select(.metadata_options.aws_v1_http_token=="ENABLED")' | jq -r '.id' done; done; done
-
If there are no lines in the list, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
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 granted
Follow the principle of least privilege and assign to the service account only the roles necessary to run the application.
- Open the Yandex Cloud console in your browser.
- Go to the appropriate folder.
- In the list of services, select Identity and Access Management.
- In the left-hand panel, select
Service accounts. - Check the list of service accounts.
- Repeat the steps for other folders.
- Go to the Access permissions tab at the cloud and folder levels.
To view organization-level access permissions, you need to use the YC CLI.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to output all the service accounts of the organization in
<service_account_ID>:<service_account_name>
format: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 SA in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc iam service-account list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id + ":" + .[].name' done; done; done
-
Run the command below to output all the access permissions of a given service account assigned for the organization:
export ORG_ID=<organization ID> yc organization-manager organization list-access-bindings \ --id=${ORG_ID} \ --format=json | jq -r '.[] | select(.subject.type=="serviceAccount")'
-
View the service account's access permissions in all clouds:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.subject.type=="serviceAccount")' && echo $CLOUD_ID done;
-
View the service account's access permissions in all folders:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do yc resource-manager folder list-access-bindings --id=$FOLDER_ID --format=json | jq -r '.[] | select(.subject.type=="serviceAccount")' && echo $FOLDER_ID done; done
-
Make sure the lists indicate no excessive permissions. Otherwise, proceed to the
Guides and solutions to use
.
Guides and solutions to use:
Remove the excessive permissions from the service account using IAM.
1.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.
- Open the Yandex Cloud console in your browser.
- Go to the appropriate folder.
- In the list of services, select Identity and Access Management.
- In the left-hand panel, select
Service accounts. - Click the service account you need and go to the Access permissions tab.
- Check the access permissions assigned to the service account.
- Make sure the list only contains valid administrators. Otherwise, proceed to the
Guides and solutions to use
.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to output all the service accounts in the clouds:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.subject.type=="serviceAccount")' && echo $CLOUD_ID done;
-
Run the command below to output all the access permissions for a specific service account as a resource:
yc iam service-account list-access-bindings \ --id <service_account_ID>
-
Make sure the list only contains valid administrators. Otherwise, proceed to the
Guides and solutions to use
.
Guides and solutions to use:
Remove the unnecessary service account permissions using IAM.
1.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 with unlimited validity.
- Authorized keys with unlimited validity.
- AWS API-compatible static access keys with unlimited validity.
You need to rotate keys with unlimited validity yourself: delete and generate new ones. You can check out the date when a key was created in its properties. Perform key rotation at least once in 90 days as recommended in the information security standards, such as PCI DSS.
- Open the Yandex Cloud console in your browser.
- Go to the appropriate folder.
- In the list of services, select Identity and Access Management.
- In the left-hand panel, select
Service accounts. - Click the service account you need and see the date of each key's generation under Access key properties.
- Repeat the steps for each of your folders.
- Make sure the keys were created less than 90 days ago. Otherwise, proceed to the
Guides and solutions to use
.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Check when static access keys were created:
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 SA in $(yc iam service-account list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc iam access-key list --service-account-id=$SA --format=json | jq -r '.[] | "key_id" + ":" + .id + "," + "sa_id" + ":" + .service_account_id + "," + "created_at" + ":" + .created_at ' done; done; done
-
Check when authorized keys were created:
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 SA in $(yc iam service-account list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc iam key list --service-account-id=$SA --format=json | jq -r '.[] | "key_id" + ":" + .id + "," + "sa_id" + ":" + .service_account_id + "," + "created_at" + ":" + .created_at ' done; done; done
-
Check when API access keys were created:
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 SA in $(yc iam service-account list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc iam api-key list --service-account-id=$SA --format=json | jq -r '.[] | "key_id" + ":" + .id + "," + "sa_id" + ":" + .service_account_id + "," + "created_at" + ":" + .created_at ' done; done; done
-
Make sure no list of keys of any type contains keys with the
created_at
value older than 90 days. Otherwise, proceed to theGuides and solutions to use
.
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 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
- Open the Yandex ID UI in your browser.
- Go to the Security
tab. - Make sure login with an additional key is selected as the login option.
- If the key-based login is configured, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
. - If you are using external IdPs, follow the guides to check the settings.
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 administrators
Yandex Cloud privileged users include accounts with the following roles:
billing.accounts.owner
admin
assigned for a billing accountorganization-manager.organizations.owner
organization-manager.admin
resource-manager.clouds.owner
admin
andeditor
assigned for an organizationadmin
andeditor
assigned for a cloudadmin
andeditor
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.
Checking roles for the Yandex Cloud Billing service:
- Open the Yandex Cloud management console in your browser.
- Go to Yandex Cloud Billing
. - Check who is granted the roles:
billing.accounts.owner
andadmin
.
Checking roles for an organization:
- Open the Yandex Cloud management console in your browser.
- Go to All services → Yandex Cloud Organization → Users.
- Check which users have the
admin
,organization-manager.organizations.owner
,organization-manager.admin
, andresource-manager.clouds.owner
roles.
Checking roles for a cloud:
- Open the Yandex Cloud management console in your browser.
- Go to the global cloud menu: click the cloud in the initial cloud menu. Select the Access permissions tab.
- Check which users have the
admin
,editor
, andresource-manager.clouds.owner
roles.
To check roles for a folder:
- Open the Yandex Cloud management console in your browser.
- Next, go to each folder of each cloud and, similarly, select the Access permissions tab.
- Check to whom the
admin
role is granted. - Make sure all the privileged roles are granted to trusted administrators. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Find organization-level privileged permissions:
export ORG_ID=<organization ID> yc organization-manager organization list-access-bindings --id=${ORG_ID} \ --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="organization-manager.organizations.owner" or .role_id=="organization-manager.admin" or .role_id=="resource-manager.clouds.owner" or role_id=="resource-manager.clouds.editor")'
-
Find cloud-level privileged permissions:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="resource-manager.clouds.owner" or role_id=="resource-manager.clouds.editor")' && echo $CLOUD_ID done
-
Run the command below to search for privileged permissions at the level of all folders in your clouds:
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 yc resource-manager folder list-access-bindings --id=$FOLDER_ID --format=json | jq -r '.[] | select(.role_id=="admin")' && echo $FOLDER_ID done; done
-
Make sure all the privileged roles are granted to trusted administrators. Otherwise, proceed to the
Guides and solutions to use
.
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 DBs
To use a database at the application level, in addition to IAM service roles, a separate local user is created: the database owner. The following password policy applies to this user:
- The password must include numbers, uppercase letters, lowercase letters, and special characters.
- It must be at least 8 characters long.
Make sure the password is regularly rotated in manual mode and meets your company password policies. The password is stored on the client side and cannot be viewed in the management console, CLI, and API.
1.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.
Check all accounts in your organization and make sure you are aware of all contractor and third-party accounts and follow the recommendations above.
1.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).
Analyze your resource model and make sure it follows the recommendations given above.
public access
to your organization resources
1.16 There is no 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.
Warning
Now All users
is only supported in the following services: Object Storage (if ACL-based access management is used), Container Registry, and Cloud Functions. For other services, assigning a role to the All users
group is equivalent to assigning the role to All authenticated users
.
Make sure that these groups have no public access to your resources: clouds, folder, buckets, and more.
Checking roles in a cloud:
- Open the Yandex Cloud management console in your browser.
- Next, go to the global cloud menu (click the cloud in the initial cloud menu). Select the Access permissions tab.
- Check whether there are
All users
andAll authenticated users
among users.
Checking roles in a folder:
- Open the Yandex Cloud management console in your browser.
- Go to the appropriate folder of the cloud you need and open the Access permissions tab.
- Check whether there are
All users
andAll authenticated users
among users. - Repeat the steps for all folders in all your clouds.
Checking roles in Object Storage:
- Open the Yandex Cloud management console in your browser.
- Go to the desired cloud and find Object Storage.
- Click the three dots next to the bucket and check its ACL for
allUsers
,allAuthenticatedUsers
. - Open the bucket and check the ACLs of each of its objects for
allUsers
,allAuthenticatedUsers
. - Open the bucket's global settings, select Object read access, and make sure the Public parameter is disabled.
- Repeat the steps for all the buckets and objects in all of your clouds.
Checking roles in Container Registry:
- Open the Yandex Cloud management console in your browser.
- Next, go to each cloud and find Container Registry.
- Open the appropriate registry and click Access permissions on the left.
- Check whether there are
All users
andAll authenticated users
among users. - Repeat the steps for all your clouds.
Checking roles in Cloud Functions:
- Open the Yandex Cloud management console in your browser.
- Next, go to each cloud and find Cloud Functions.
- Open all cloud functions and make sure the Public access parameter is disabled.
- Make sure none of the specified resources contain
All users
orAll authenticated users
. Otherwise, proceed to theGuides and solutions to use
.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for accounts with primitive roles assigned at the organization level:
export ORG_ID=<organization ID> yc organization-manager organization list-access-bindings \ --id=${ORG_ID} \ --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="organization-manager.organizations.owner" or .role_id=="organization-manager.admin" or .role_id=="resource-manager.clouds.owner")'
-
Run the command below to search for cloud-level access permissions such as
allUsers
andallAuthenticatedUsers
:export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.subject.id=="allAuthenticatedUsers" or .subject.id=="allUsers")' && echo $CLOUD_ID done
-
Run the command below to search for folder-level access permissions such as
allUsers
andallAuthenticatedUsers
: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 yc resource-manager folder list-access-bindings --id=$FOLDER_ID --format=json | jq -r '.[] | select(.subject.id=="allAuthenticatedUsers" or .subject.id=="allUsers")' && echo $FOLDER_ID done; done
-
Run the command below to search for the
allUsers
andallAuthenticatedUsers
access permissions at the Container Registry level in all folders:export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for CR in $(yc container registry list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc container registry list-access-bindings --id $CR --format=json | jq -r '.[] | select(.subject.id=="allAuthenticatedUsers" or .subject.id=="allUsers")' && echo $CR done; done; done
-
Run the command below to search for the
allUsers
andallAuthenticatedUsers
access permissions at the Cloud Functions level in all folders:export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for FUN in $(yc serverless function list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc serverless function list-access-bindings --id $FUN --format=json | jq -r '.[] | select(.subject.id=="allAuthenticatedUsers" or .subject.id=="allUsers")' && echo $FUN done; done; done
-
Make sure none of the specified resources contain
allUsers
orallAuthenticatedUsers
. Otherwise, proceed to theGuides and solutions to use
.
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 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
Make sure the contact information is valid and messages are sent to multiple persons in charge from the specified email address.
- Open the Yandex Cloud management console in your browser.
- Go to Yandex Cloud Billing
. - Go to the Account data tab.
- At the bottom, click Edit data in Yandex Balance.
- Verify the specified contact information.
- Make sure the contact details are valid. Otherwise, proceed to the
Guides and solutions to use
.
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 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.
- Open the Yandex Cloud management console in your browser.
- Go to the Organizations tab.
- Next, open the Federations tab and select your federation.
- Find the Cookie lifetime parameter.
- Make sure its value is less than or equal to 6 hours. Otherwise, proceed to the
Guides and solutions to use
.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for accounts with primitive roles assigned at the organization level:
export ORG_ID=<organization ID> for FED in $(yc organization-manager federation saml list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do yc organization-manager federation saml get --id bpfdshe1skaqcjp6uc50 --format=json | jq -r '. | select(.cookie_max_age>"21600s")' done
-
The output should return an empty string. If the result with the current federation's settings is output, where
cookie_max_age
> 21600s, proceed to theGuides and solutions to use
.
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 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.
Analyze all of your VMs and cloud functions in terms of manually created service account tokens. Tokens are used properly if you assign a service account to an entity and use the account's token from within via the metadata service.
1.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.
- In the management console
, click the name of the cloud you need in the left-hand panel. - Go to the Access permissions tab and check if the
iam.serviceAccounts.tokenCreator
role is there.
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 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:
The example below shows how to check if there is a label to a Yandex Virtual Private Cloud cloud network. You can perform similar checks for other resource labels.
- In the management console
, select the folder. - Select Virtual Private Cloud.
- Check it for labels.
Guides and solutions to use:
1.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.
- In the management console
, click Settings . - Go to the Notifications section.
- In the notification settings, enable the Security option.
Guides and solutions to use:
- Make sure that notifications are set up.
- Enable the Security option in the notification settings in the management console.
1.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.
- In the management console
, go to the relevant folder. - Click the Access permissions tab.
- Click Assign roles.
- In the Configure access bindings window, click Select user.
- Select a user from the list or search by user.
- Click Add role.
- Select the
auditor
role in the folder. - Click Save.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for accounts with the
auditor
role assigned at the organization level:export ORG_ID=<organization_ID> yc organization-manager organization list-access-bindings \ --id=${ORG_ID} \ --format=json | jq -r '.[] | select(.role_id=="auditor")'
If the list of accounts is empty, go to the
Guides and solutions to use
. -
Run the command below to search for accounts with the
auditor
role assigned at the cloud level:export ORG_ID=<organization_ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.role_id=="auditor")' done
If the list of accounts is empty, go to the
Guides and solutions to use
. -
Run the command below to search for accounts with the
auditor
role assigned at the level of all folders in your clouds: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 yc resource-manager folder list-access-bindings --id=$FOLDER_ID --format=json | jq -r '.[] | select(.role_id=="auditor")' done; done
If the list of accounts is empty, go to the
Guides and solutions to use
.
Guides and solutions to use:
- Assign the
auditor
role to users requiring no data access. - Remove the excessive account permissions using IAM.
1.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 consolelast_used_at
field when using the API to invoke access key management methods.
For more information, see Service account keys.
- In the management console
, navigate to the folder the service account with access keys belongs to. - In the list of services, select Identity and Access Management.
- In the left-hand panel, select
Service accounts. - In the list that opens, select the service account you need.
- You can see the time of the last key use in the table with key info under Date of last use.
2. 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 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.
Check if there are security groups in different objects:
- Open the Yandex Cloud management console
in your browser. - Go to each cloud and folder and open all resources listed in "Objects that security groups can be applied to", one by one.
- In the object settings, find the Security group parameter and make sure that at least one security group is assigned.
- If the parameters of each object with security group support have at least one group set, the recommendation is fulfilled. Otherwise, proceed to Guides and solutions to use.
Check whether the NGFW is used instead of security groups:
- Open the Yandex Cloud management console in your browser.
- Go to each cloud and folder and open all VM disks one by one.
- In the disk settings, find the Marketplace product parameter.
- If the disk's Marketplace product parameters have one of the NGFW product names specified: Check Point CloudGuard IaaS — Firewall & Threat Prevention PAYG or UserGate NGFW, the recommendation is fulfilled. Otherwise, proceed to Guides and solutions to use.
-
See what organizations are available to you and write down the
ID
you need:yc organization-manager organization list
-
Run the command below to search for cloud objects with no security group:
export ORG_ID=<Organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc compute instance get --id=$VM_ID --format=json | jq -r '. | select(.network_interfaces[].security_group_ids | not)' | jq -r '.id' done; done; done
-
If an empty string is output, the recommendation is fulfilled. If you get the cloud resource
ID
in the output, proceed to Guides and solutions to use.
Check whether the NGFW is used instead of a security group:
-
Run the command to search for the NGFW in the cloud. By default, the command searches for Checkpoint or Usergate. If you use a custom image, specify it.
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 DISK_ID in $(yc compute disk list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc compute disk get --id=$DISK_ID --format=json | jq -r '. | select(.product_ids[0]=="f2ecl4ak62mjbl13qj5f" or .product_ids[0]=="f2eqc5sac8o5oic7m99k")' | jq -r '.id' done; done; done
-
If you get the
ID
of a VM with the NGFW in the output, the recommendation is fulfilled. If you get an empty string, proceed to Guides and solutions to use.
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 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.
- Open the Yandex Cloud console in your browser.
- Go to each cloud and then to each folder and each Virtual Private Cloud.
- Go to Security groups.
- If at least one security group for each Virtual Private Cloud or the default security group is found, the recommendation is fulfilled. Otherwise, proceed to Guides and solutions to use.
-
See what organizations are available to you and write down the
ID
you need:yc organization-manager organization list
-
Run the command below to search for folders with no security group:
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 echo "SG_ID: " && yc vpc security-group list --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(.id)' | jq -r '.id' && echo "FOLDER_ID: " $FOLDER_ID && echo "-----" done; done
-
If each
SG_ID
combination has theID
specified in front of theFOLDER_ID
of the folder it resides in, the recommendation is fulfilled. Otherwise, proceed to Guides and solutions to use.
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 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).
Warning
If no port range is set, it is considered that access is granted across all ports (0-65535).
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.
- Open the Yandex Cloud console in your browser.
- Go to each cloud and then to each folder and each Virtual Private Cloud.
- Go to Security groups.
- If there is no security group containing network access rules that allow access through any port and from any IP address (for explanation, see above), the recommendation is fulfilled. Otherwise, proceed to Guides and solutions to use.
-
See what organizations are available to you and write down the
ID
you need:yc organization-manager organization list
-
Find security groups with a dangerous access rule:
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 echo "SG_ID: " && yc vpc security-group list --folder-id=$FOLDER_ID \ --format=json | jq -r '.[] | select(.rules[].direction=="INGRESS" and .rules[].ports.to_port=="65535" and .rules[].cidr_blocks.v4_cidr_blocks[]=="0.0.0.0/0")' | jq -r '.id' \ && echo "FOLDER_ID: " $FOLDER_ID && echo "-----" done; done
-
If an empty value is set in
SG_ID
next toFOLDER_ID
, the recommendation is fulfilled. If you see a non-emptySG_ID
, proceed to Guides and solutions to use.
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 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).
- Open the Yandex Cloud console in your browser.
- Go to each cloud and then to each folder and each Virtual Private Cloud.
- Go to Security groups.
- If there is no security group containing network access rules that allow access through control ports from any IP address (for explanation, see above), the recommendation is fulfilled. Otherwise, proceed to Guides and solutions to use.
-
See what organizations are available to you and write down the
ID
you need:yc organization-manager organization list
-
Run the command below to search for security groups with dangerous access rules:
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 echo "SG_ID: " && yc vpc security-group list --folder-id=$FOLDER_ID \ --format=json | jq -r '.[] | select(.rules[].direction=="INGRESS" and (.rules[].ports.to_port=="22" or .rules[].ports.to_port=="3389" or .rules[].ports.to_port=="21") and .rules[].cidr_blocks.v4_cidr_blocks[]=="0.0.0.0/0")' | jq -r '.id' \ && echo "FOLDER_ID: " $FOLDER_ID && echo "-----" done; done
-
If an empty value is set in
SG_ID
next toFOLDER_ID
, the recommendation is fulfilled; if theSG_ID
is not empty, proceed to Guides and solutions to use.
Guides and solutions to use:
Delete the dangerous rule in each security group or specify trusted IPs.
2.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.
- Open the Yandex Cloud console in your browser.
- Open all created networks.
- Go to IP addresses.
- If all the public IP addresses have the DDoS protection column set to Enabled, the recommendation is fulfilled. Otherwise, proceed to Guides and solutions to use.
Contact your account manager to find out if you have extended DDoS protection activated.
-
See what organizations are available to you and write down the
ID
you need:yc organization-manager organization list
-
Run the command below to search for IP addresses with no DDOS protection:
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 echo "Address_ID: " && yc vpc address list --folder-id=$FOLDER_ID \ --format=json | jq -r '.[] | select(.external_ipv4_address.requirements.ddos_protection_provider=="qrator" | not)' | jq -r '.id' \ && echo "FOLDER_ID: " $FOLDER_ID && echo "-----" done; done
-
If an empty value is set in
Address_ID
next toFOLDER_ID
, the recommendation is fulfilled; otherwise, proceed to Guides and solutions to use.
Guides and solutions to use:
- All materials about DDoS protection in Yandex Cloud.
2.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
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.
- Open the Yandex Cloud console in your browser.
- Open all created networks.
- Go to the Route tables section.
- If routes to remote sites' private networks through VMs with a VPN gateway are found, the recommendation is fulfilled.
- Check the VMs in each cloud for VPN gateways. In addition, check if their security groups have open ports for the VPN.
Contact your account manager to find out if you have Cloud Interconnect activated. If yes, check if remote access is used.
2.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:
Public IP address |
Egress NAT |
NAT instance |
Advantages: |
Advantages: |
Advantages: |
|
|
|
Disadvantages: |
Disadvantages: |
Disadvantages: |
|
|
|
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.
- Open the Yandex Cloud console in your browser.
- Go to the appropriate folder.
- Go to IP addresses.
- If all the public IP addresses have the DDoS protection column set to Enabled, the recommendation is fulfilled. otherwise, proceed to Guides and solutions to use.
-
See what organizations are available to you and write down the
ID
you need:yc organization-manager organization list
-
Run the command below to search for all VMs with public IPs:
export ORG_ID=<Organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do echo "VM_ID: " && yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(.network_interfaces[].primary_v4_address.one_to_one_nat.address)' | jq -r '.id' \ && echo "FOLDER_ID: " $FOLDER_ID && echo "-----" done; done
-
If an empty value is set in
VM_ID
next toFOLDER_ID
, the recommendation is fulfilled; otherwise, proceed to Guides and solutions to use. -
Run the command below to see if there is Egress NAT (NAT gateway):
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 echo "NAT_GW: " && yc vpc gateway list --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(.id)' | jq -r '.id' && echo "FOLDER_ID: " $FOLDER_ID && echo "-----" done; done
-
If an empty value is set in
NAT_GW
next toFOLDER_ID
, the recommendation is fulfilled; otherwise, proceed to the Guides and solutions to use. -
Run the command below to see if there is a NAT instance:
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 DISK_ID in $(yc compute disk list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc compute disk get --id=$DISK_ID --format=json | jq -r '. | select(.product_ids[0]=="fd8v7ru46kt3s4o5f0uo")' | jq -r '.id' done; done; done
-
If an empty string is output, the recommendation is fulfilled. If you see the NAT instance
ID
, proceed to Guides and solutions to use.
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 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 environment
This section provides recommendations to customers on security settings in Yandex Cloud services and the use of additional data protection tools in virtual environments.
Overview
3.1 A serial console is either used under control or not used
On VMs, access to the serial console is disabled by default. For risks of using the serial console, see Getting started with the serial console in the Yandex Compute Cloud documentation.
When working with a serial console:
- Make sure that critical data is not output to the serial console.
- If you enable SSH access to the serial console, make sure that both the credentials management and the password used for logging in to the operating system locally are compliant with regulator standards. For example, in an infrastructure for storing payment card data, passwords must meet PCI DSS requirements: it must contain both letters and numbers, be at least 7 characters long, and be changed at least once every 90 days.
Note
According to the PCI DSS standard, access to a VM via a serial console is considered "non-console", and Yandex Cloud uses TLS encryption for it.
We do not recommend using access to the serial console unless it is absolutely necessary.
- In the management console, select the folder to check the VMs in.
- In the list of services, select Compute Cloud.
- Open the settings of all the necessary VMs.
- Under Access, find the Additional parameter.
- Serial console access must be disabled.
- If it is disabled for all the VMs, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Find the VM with access to the serial console enabled:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do echo "VM_ID: " && yc compute instance get --id=$VM_ID --full --format=json | jq -r '. | select(.metadata."serial-port-enable"=="1")' | jq -r '.id' && echo "FOLDER_ID: " $FOLDER_ID && echo "-----" done; done; done
-
If an empty value is set in VM_ID next to FOLDER_ID, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
If the serial console should not be used on the VM, disable it.
3.2 A benchmark image is used for VM deployment
When deploying virtual machines, we recommend:
- Preparing a VM image whose system settings correspond to your information security policy. You can create an image using Packer. See Getting started with Packer.
- Use this image to create a virtual machine or instance group.
- Look up the virtual machine's information to check that it was created using this image.
- In the management console, select the folder to check the VMs in.
- In the list of services, select Compute Cloud.
- Go to the Disks tab.
- Open the settings of all disks.
- Under Source, find the Identifier parameter.
- If every disk displays the ID of your benchmark image, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for the VM disks that do not contain the ID of your benchmark image:
export ORG_ID=<organization ID> export IMAGE_ID=<ID of your benchmark image> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for DISK_ID in $(yc compute disk list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do echo "DISK_ID: " && yc compute disk get --id=$DISK_ID \ --format=json | jq -r --arg IMAGE_ID $IMAGE_ID '. | select(."source_image_id"==$IMAGE_ID | not)' | jq -r '.id' && echo "FOLDER_ID: " $FOLDER_ID && echo "-----" done; done; done
-
If an empty value is set in DISK_ID next to FOLDER_ID, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
- Find out why these VM disks use an image different from the benchmark one.
- Recreate the VMs with the appropriate image.
3.3 Terraform is used in accordance with best information security practices
With Terraform, you can manage a cloud infrastructure using configuration files. If you change the files, Terraform will automatically detect which part of your configuration is already deployed, and what should be added or removed. For more information, see Getting started with Terraform.
We do not recommend using private information in Terraform configuration files, such as passwords, secrets, personal data, 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 theterraform plan
andterraform 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.
Note
When a configuration is deployed, you can delete the configuration file with private data.
Scan your Terraform manifests using Checkov
Collect data about using the Terraform best security practices from different points.
3.4. Integrity control is performed
3.4.1 File integrity control
Numerous information security standards require integrity control of critical files. To do this, you can use free host-based solutions:
Paid solutions are also available in Yandex Cloud marketplace, such as Kaspersky Security.
Collect data about using integrity control from different points.
3.4.2 Integrity control of a VM runtime environment
To control a VM's runtime environment (e.g., to enable access from the VM to a secure repository only when running it in the YC CLI cloud), you can use the identity document mechanism. When creating a VM, an identity document that stores information about the VM is generated. It contains IDs of the VM, Yandex Cloud Marketplace product, disk image, etc. This document is signed with a Yandex Cloud certificate. The document and its signature are available to VM processes through the metadata service. Thus, the processes identify the VM runtime environment, disk image, etc., to restrict access to the resources under monitoring.
Make sure that critical VMs have identity documents signed.
3.5 Principles of protection against side-channel attacks are incorporated
To ensure the best protection against CPU level side-channel attacks (such as Spectre or Meltdown):
- Use full-core virtual machines (instances with a CPU share of 100%).
- Install updates for your operating system and kernel that ensure side-channel attack protection (for example, Kernelpage-tableisolation for Linux
or applications built using Retpoline ).
We recommend that you use dedicated hosts for the most security-critical resources.
Learn more
Yandex Object Storage
3.6 No public access to a Object Storage bucket is allowed
We recommend assigning minimum roles for a bucket using IAM and supplementing or itemizing them using a bucket policy (for example, to restrict access to the bucket by IP, grant granular permissions for objects, and so on).
Access to Object Storage resources is verified at three levels:
Verification procedure:
-
If a request passes the IAM check, the next step is the bucket policy check.
-
Bucket policy rules are checked in the following order:
- If the request meets at least one of the Deny rules, access is denied.
- If the request meets at least one of the Allow rules, access is allowed.
- If the request doesn't meet any of the rules, access is denied.
-
If the request fails the IAM or bucket policy check, access verification is performed based on an object's ACL.
In IAM, a bucket inherits the same access permissions as those of the folder and cloud where it is located. For more information, see Inheritance of bucket access permissions by Yandex Cloud public groups. Therefore, we recommend that you only assign the minimum required roles to certain buckets or objects in Object Storage.
Bucket policies are used for additional data protection, for example, to restrict access to a bucket by IP, grant granular rights permissions to objects, and so on.
With ACLs, you can grant access to an object bypassing IAM verification and bucket policies. We recommend setting strict ACLs for buckets.
Example of a secure Object Storage configuration: Terraform
- In the management console, select the cloud or folder to check the buckets in.
- In the list of services, select Object Storage.
- Click the three dots next to each bucket and check its ACL for
allUsers
andallAuthenticatedUsers
. - Open the bucket and check the ACL of each of its objects for
allUsers
andallAuthenticatedUsers
. - Check that the object Read access section has the Public parameter enabled. Otherwise, proceed to the "Guides and solutions to use".
-
Configure the AWS CLI to work with a cloud.
-
Run the command below to check the bucket ACL for
allUsers
andallAuthenticatedUsers
:aws --endpoint-url=https://storage.yandexcloud.net s3api get-bucket-acl <name of your bucket>
Guides and solutions to use:
If public access is enabled, remove it or perform access control (grant permission to access public data consciously).
3.7 Object Storage uses Bucket Policies
Bucket policies set permissions for actions with buckets, objects, and object groups. A policy is triggered when a user makes a request to a resource. As a result, the request is either executed or rejected.
Bucket Policy examples:
- Policy that only enables object download from a specified range of IP addresses.
- Policy that prohibits downloading objects from the specified IP address.
- Policy that provides different users with full access only to certain folders, with each user being able to access their own.
- Policy that gives each user and service account full access to a folder named the same as the user ID or service account ID.
We recommend making sure that your Object Storage bucket uses at least one policy.
- In the management console, select the cloud or folder to check the bucket policies in.
- In the list of services, select Object Storage.
- Go to Bucket policy.
- Make sure that at least one policy is enabled. Otherwise, proceed to the "Guides and solutions to use".
-
Configure the AWS CLI to work with a cloud.
-
Run the command below to check the bucket ACL for
allUsers
andallAuthenticatedUsers
:aws --endpoint-url=https://storage.yandexcloud.net s3api get-bucket-policy --bucket <name of your bucket>
Guides and solutions to use:
Enable the required policy.
3.8 In Object Storage, the Object locks feature is enabled
When processing critical data in buckets, you must ensure that data is protected from deletion and that versions are backed up. This can be achieved by versioning and lifecycle management mechanisms, as well as by using object locks.
Bucket versioning is the ability to store the history of object versions. Each version is a complete copy of the object and occupies space in Object Storage. Using version control protects your data from both unintentional user actions and application faults.
If you delete or modify an object with versioning enabled, a new version of the object with a new ID is effectively created. In the case of deletion, the object becomes unreadable, but its version is kept and can be restored.
For more information about setting up versioning, see the Object Storage documentation, Bucket versioning.
For more information about lifecycles, see the Object Storage documentation, Bucket object lifecycles and Bucket object lifecycle configuration.
In addition, to protect object versions against deletion, use object locks. For more information about object lock types and how to enable them, see the documentation.
The storage period of critical data in a bucket is determined by the client's information security requirements and information security standards. For example, the PCI DSS standard states that audit logs should be stored for at least one year and be available online for at least three months.
- In the management console, select the cloud or folder to check the buckets in.
- In the list of services, select Object Storage.
- Open the settings of all buckets.
- Go to the Versioning tab and make sure it is enabled. Otherwise, proceed to the "Guides and solutions to use".
-
Configure the AWS CLI to work with a cloud.
-
Run the command below to check whether versioning is enabled:
aws --endpoint https://storage.yandexcloud.net \ s3api get-bucket-versioning \ --bucket <name of your bucket>
-
Run the command below to check whether versioning is enabled:
aws --endpoint-url=https://storage.yandexcloud.net/ \ s3api get-object-lock-configuration \ --bucket <name of your bucket>
Guides and solutions to use:
If public access is enabled, remove it or use access control (by only enabling it when necessary and if approved).
3.9 In Object Storage, logging of actions with buckets is enabled
When using Object Storage to store critical data, be sure to enable logging of actions with buckets. For more information, see the Object Storage documentation, Logging actions with a bucket.
This makes sure that data-plane logs with the following objects are written: PUT, DELETE, GET, POST, OPTIONS, HEAD.
In a similar way, you can request writing these logs to Audit Trails, except reads. In the future, all these logs will be written to Audit Trails.
You can also analyze Object Storage logs in DataLens. For more information, see Analyzing Object Storage logs using DataLens.
Guides and solutions to use:
You can only use Terraform/API to check if logging is enabled by following the instructions.
3.10 In Object Storage, Cross-Origin Resource Sharing (CORS) is set up
If you need cross-domain requests
- In the management console, select the cloud or folder to check the buckets in.
- In the list of services, select Object Storage.
- Open the settings of all buckets.
- Go to the CORS tab and make sure that the configuration is set up. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Set up CORS.
3.11 Use Yandex Security Token Service to get access keys to Object Storage
Yandex Security Token Service: Yandex Identity and Access Management component to get temporary access keys compatible with AWS S3 API.
Temporary access keys as an authentication method are only supported in Yandex Object Storage.
With temporary keys, you can set up granular access to buckets for multiple users with a single service account. The service account permissions must include all the permissions you want to grant using temporary keys.
A temporary access key is created based on a static key, but, unlike it, it has a limited lifetime and access permissions. Access permissions and lifetime are set for each temporary key individually. The maximum key lifetime is 12 hours.
To set up access permissions for the key, you need an access policy in JSON format based on this schema.
Temporary Security Token Service keys inherit the access permissions of the service account, but are limited by the access policy. If you set up a temporary key's access policy to allow operations not allowed for the service account, such operations will not be performed.
Guides and solutions to use:
Create a temporary access key using Security Token Service.
3.12 Pre-signed URLs are generated for isolated cases of access to specific objects in Object Storage private buckets
Object Storage incorporates several access management mechanisms. To learn how these mechanisms interact, see Access management methods in Object Storage: Overview.
With pre-signed URLs, any web user can perform various operations in Object Storage, such as:
- Downloading an object
- Uploading an object
- Creating a bucket
A pre-signed URL is a URL containing request authorization data in its parameters. Pre-signed URLs can be created by users with static access keys.
We recommend using pre-signed URLs to users who are not authorized in the cloud but need access to specific objects in the bucket. This way you follow the principle of least privilege and avoid opening access to all the objects in the bucket.
Guides and solutions to use:
Create a pre-signed URL and communicate it to the user.
Managed Services for Databases
3.13 A security group is assigned in managed databases
We recommend prohibiting internet access to databases that contain critical data, in particular PCI DSS data or private data. Configure security groups to only allow connections to the DBMS from specific IP addresses. To do this, follow the steps in Creating a security group. You can specify a security group in the cluster settings or when creating the cluster in the network settings section.
- In the management console, select the cloud or folder to check the databases in.
- In the list of services, select a service or services with managed databases.
- In the object settings, find the Security group parameter and make sure that at least one security group is assigned.
- If the parameters of each object have at least one security group set, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
Run the command below to search for Managed PostgreSQL DBs with no SG:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for DB_ID in $(yc managed-postgresql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-postgresql cluster get --id=$DB_ID --format=json | jq -r '. | select(.security_group_ids | not)' | jq -r '.id' done; done; done
-
The output should return an empty string. Otherwise, proceed to the "Guides and solutions to use".
-
Run the command below to search for Managed MySQL DBs with no SG:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql cluster get --id=$DB_ID --format=json | jq -r '. | select(.security_group_ids | not)' | jq -r '.id' done; done; done
-
The output should return an empty string. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
If any databases without security groups are found, assign them or enable the Default security group functionality.
3.14 No public IP address is assigned in managed databases
Assigning a public IP to a managed database raises information security risks. We do not recommend assigning an external IP unless it is absolutely necessary.
- In the management console, select the cloud or folder to check the databases in.
- In the list of services, select a service or services with managed databases.
- In the object settings, go to the Hosts tab.
- If the parameters of each object have the Public access option disabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for managed DB clusters with public IPs:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql hosts list --cluster-id=$DB_ID --format=json | jq -r '.[] | select(.assign_public_ip)' | jq -r '.cluster_id' done; done; done
-
If an empty string is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Disable public access if it is not required.
3.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.
- In the management console, select the cloud or folder to check the databases in.
- In the list of services, select a service or services with managed databases.
- In the object settings, go to the Advanced settings tab.
- If the parameters of each object have the Deletion protection option enabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for managed DB clusters with deletion protection disabled:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql cluster get --id=$DB_ID --format=json | jq -r '. | select(.deletion_protection | not)' | jq -r '.id' done; done; done
-
The output should return an empty string. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
- In the management console, select the cloud or folder to enable deletion protection in.
- In the list of services, select a service or services with managed databases.
- In the object settings, go to the Advanced settings tab.
- In the object parameters, enable Deletion protection.
3.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.
- In the management console, select the cloud or folder to check the databases in.
- In the list of services, select a service or services with managed databases.
- In the object settings, go to the Advanced settings tab.
- If the parameters of each object have Access from DataLens disabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Find managed DB clusters with access from DataLens enabled:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql cluster get --id=$DB_ID --format=json | jq -r '. | select(.config.access.data_lens)' | jq -r '.id' done; done; done
-
The output should return an empty string. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
- In the management console, select the cloud or folder to disable access from DataLens in.
- In the list of services, select a service or services with managed databases.
- In the object settings, go to the Advanced settings tab.
- In the object parameters, disable Access from DataLens.
3.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.
- In the management console, select the cloud or folder to check the databases in.
- In the list of services, select a service or services with managed databases.
- In the object settings, go to the Advanced settings tab.
- If the parameters of each object have Access from the management console disabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for managed DB clusters with access from the management console enabled:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql cluster get --id=$DB_ID --format=json | jq -r '. | select(.config.access.web_sql)' | jq -r '.id' done; done; done
-
If an empty string is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
- In the management console, select the cloud or folder to disable access from the management console in.
- In the list of services, select a service or services with managed databases.
- In the object settings, go to the Advanced settings tab.
- In the object parameters, disable Access from console.
Cloud Functions and Yandex API Gateway
3.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.
- In the management console, select the cloud or folder to check the functions in.
- In the list of services, select Cloud Functions.
- Open all the functions.
- In the function settings, go to the Overview tab.
- If the parameters of each object have the Public function option disabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
Run the command below to search for
allUsers
access permissions at the Cloud Functions level in all folders:export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for FUN in $(yc serverless function list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc serverless function list-access-bindings --id $FUN --format=json | jq -r '.[] | select(.subject.id=="allAuthenticatedUsers" or .subject.id=="allUsers")' && echo $FUN done; done; done
-
If none of the specified resources contain
allUsers
andallAuthenticatedUsers
, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Disable public access.
3.19 Side-channel attacks in Cloud Functions are addressed
Hosts and hypervisors running Cloud Functions contain all the applicable updates for side-channel attack protection. However, keep in mind that different clients' functions are not isolated by cores. Thus, there is technically an attack surface between one user's function and another's. Yandex Cloud security experts believe that side-channel attacks are unlikely in the context of functions, but this risk must be accounted for, particularly in the overall threats and risk analysis model employed by the PCI DSS infrastructure.
Make sure the most critical systems do not use Cloud Functions or this is considered in the risk analysis model.
3.20 Specifics of time synchronization in Cloud Functions are considered
The Cloud Functions service does not guarantee time synchronization prior to or during execution of requests by functions. To generate a function log with exact timestamps on the Cloud Functions side, output the log to stdout. The client can also independently accept function execution logs and label them with a timestamp on the receiving side. In this case, the timestamp is taken from the time source synced with Yandex Cloud. For more information about time synchronization, see the Compute Cloud documentation, Configuring clock synchronization.
3.21 Specifics of header management in Cloud Functions are considered
If the function is called to process an HTTP request, the returned result should be a JSON document containing the HTTP response code, response headers, and response content. Cloud Functions automatically processes this JSON document and returns data in a standard HTTP response to the user. The client needs to manage the response headers on their own in accordance with regulator requirements and the threat model. For more information on how to process an HTTP request, refer to the Cloud Functions manual, Invoking a function in Cloud Functions.
3.22 Serverless Containers/Cloud Functions uses the VPC internal network
By default, the function is invoked in the isolated IPv4 network with the NAT gateway enabled. For this reason, only public IPv4 addresses are available.
If necessary, you can specify a cloud network in function settings. In this case, the function:
- Is executed in a given cloud network.
- Has access to the internet and user resources in the given network, such as databases and VMs.
- Has an IP address within the
198.19.0.0/16
range when accessing user resources.
- In the management console, select the cloud or folder to check the functions in.
- In the list of services, select Cloud Functions.
- Open all the functions.
- In the object settings, go to the Edit function version tab.
- If the parameters of each object have Network — VPC set, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
Run the command below to search for any cloud functions that have no network settings specified in VPC:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for VER in $(yc serverless function version list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc serverless function version get $VER --format=json | jq -r '. | select(.connectivity.network_id | not)' | jq -r '.id' done; done; done
-
If an empty string is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
- Select the cloud or folder to check the functions in.
- Select Cloud Functions in the list of services.
- Open the function.
- In the object settings, go to the Edit function version tab.
- Set Network — VPC.
Managed Service for YDB
3.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
3.24 Recommendations for SQL injection protection in YDB are addressed
When working with the database, use parameterized prepared statements
3.25 No public access to YDB is allowed
When accessing the database in dedicated mode, we recommend that you use it inside VPC, disabling public access to it from the internet. In serverless mode, the database can be accessed from the internet. You must therefore take this into account when modeling threats to your infrastructure. For more information about the operating modes, see the Serverless and dedicated modes section in the Managed Service for YDB documentation.
When setting up database permissions, use the principle of least privilege.
- In the management console, select the cloud or folder to check the database in.
- In the list of services, select Managed Service for YDB.
- Open all the databases.
- In the database settings, go to the Network tab.
- If the parameters of each object have the Public IP addresses option disabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for managed DB clusters with public IPs:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql hosts list --cluster-id=$DB_ID --format=json | jq -r '.[] | select(.assign_public_ip)' | jq -r '.cluster_id' done; done; done
-
The output should return an empty string. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Disable public access if it is not required.
3.26 Recommendations for YDB backups are addressed
When creating on-demand backups, make sure that the backup data is properly protected.
When creating backups on demand in Object Storage, follow the recommendations in the Object Storage subsection above (for example, use the built-in bucket encryption feature).
Yandex Container Registry
3.27 ACL by IP address is set up for Yandex Container Registry
We recommend that you limit access to your Container Registry to specific IPs.
- In the management console, select the cloud or folder to check the registry in.
- In the list of services, select Container Registry.
- In the settings of the specific registry, go to the Access for IP address tab.
- If specific IPs to allow access for are set in the parameters, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for CRs that are not filtered by IP:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for CR in $(yc container registry list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc container registry list-ip-permissions --id=$CR --format=json | jq -r '.[] | select(.ip)' | jq -r '.action' && echo $CR "IF ACTION PULL/PUSH exist before CR then OK" done; done; done
-
If PULL/PUSH is output before each registry ID, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Specify the IP addresses for registry access.
Yandex Container Solution
We do not recommend that you use privileged containers to run loads that process untrusted user input. Privileged containers should be used for the purposes of administering VMs or other containers.
- In the management console, select the cloud or folder to check the VMs in.
- In the list of services, select Compute Cloud.
- Open the settings of a specific VM with a Container Optimized Image.
- In the Docker container's Settings, find the Privileged mode parameter.
- If it is disabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for CRs that are not filtered by IP:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc compute instance get --id=$VM_ID --full --format=json | jq -r '. | select(.metadata."docker-container-declaration")| .metadata."docker-container-declaration" | match("privileged: true") | .string' && echo $VM_ID done; done; done
-
If there is no
privileged: true
in front of each VM ID, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
- In the management console, select the cloud or folder to check the VMs in.
- In the list of services, select Compute Cloud.
- Open the settings of a specific VM with a Container Optimized Image.
- In the Docker container's Settings, disable the Privileged mode parameter.
3.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.
- In the management console, select the cloud or folder to check the VMs in.
- In the list of services, select Yandex Certificate Manager.
- Open the settings of each certificate and find the End date parameter.
- If the parameter shows that the certificate will be valid for at least 30 days more, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Search for any of your organization's certificates with the end date:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for CERT_ID in $(yc certificate-manager certificate list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc certificate-manager certificate get --id $CERT_ID --format=json | jq -r '. | "Date of the end " + .not_after + " --- Cert_ID " + .id' done; done; done
-
If there is no
privileged: true
in front of each VM ID, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Update the certificate or set up auto updates.
Yandex Managed Service for GitLab
3.29 GitLab security guidelines are followed
See the recommendations here.
Run a manual check.
3.30 Antivirus protection is used
Make sure to provide anti-malware protection within your scope of responsibility. You can use a variety of solutions from our partners in Yandex Cloud Marketplace.
Antivirus solution images are available in Yandex Cloud Marketplace. License types and other required information are available in the product descriptions.
Make sure that critical systems are protected with antivirus solutions.
Guides and solutions to use:
Follow the vendor guide to install the AV solution.
3.31 Yandex Managed Service for Kubernetes security guidelines are used
Check the recommendations in Security Kubernetes.
3.32 Connecting to a VM or Kubernetes node via OS Login
OS Login is a convenient way to manage connections to virtual machines and Yandex Managed Service for Kubernetes cluster nodes over SSH via the YC CLI or a standard SSH client with an SSH certificate or SSH key previously added to the organization user's OS Login or service account profile in Yandex Cloud Organization.
OS Login links the account of a virtual machine or Kubernetes node user with the account of an organization or service account user. To manage access to virtual machines and Kubernetes nodes, enable the OS Login access option at the organization level, then activate OS Login access on each virtual machine or Kubernetes node separately.
Thus, you can easily manage access to virtual machines and Kubernetes nodes by assigning appropriate roles to users or service accounts. If you revoke the roles, the user or service account will lose access to all virtual machines and Kubernetes nodes with OS Login access enabled.
Guides and solutions to use:
- Enabling OS Login access at the organization level.
- Setting up OS Login access on an existing VM.
- Connecting to a virtual machine via OS Login.
- Connecting to a Kubernetes node via OS Login.
3.33 Vulnerability scanning is performed at the cloud IP level
We recommend that clients scan their own hosts for vulnerabilities. Cloud resources support the installation of custom virtual images of vulnerability scanners or software agents on hosts. There are many fee-based and free solutions for scanning.
Network scanners scan hosts that are accessible over a network. Generally, authentication can be configured on network scanners.
Examples of free network scanners:
Example of a free scanner operating as an agent on hosts: Wazuh
You can also use a solution from Cloud Marketplace.
Run a manual check.
3.34 External security scans are performed according to the cloud rules
Customers hosting their own software in Yandex Cloud can perform external security scans for the hosted software, including penetration tests. You can run your own scans or use contractors. For more information, see Rules for performing external security scans.
Run a manual check.
3.35 The process of security updates is set up
A client must perform their own security updates within their scope of responsibility. Various automated tools are available for centralized automated OS and software updates.
Yandex Cloud publishes security bulletins to notify customers of newly discovered vulnerabilities and security updates.
4. Data encryption and key management
Introduction
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 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 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.
- In the management console, select the cloud or folder to check the buckets in.
- In the list of services, select Object Storage.
- Go to the bucket settings.
- Go to the Encryption tab.
- Make sure that encryption is enabled and the KMS encryption key is specified.
- If encryption is enabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
Configure the AWS CLI to work with a cloud.
-
Run the command below to check whether encryption is enabled:
aws --endpoint-url=https://storage.yandexcloud.net/ \ s3api get-bucket-encryption \ --bucket <bucket_name>
-
If encryption is enabled, the recommendation is fulfilled. Otherwise, proceed to "Guides and solutions to use".
Guides and solutions to use:
Configure bucket encryption using the guide.
Encryption 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 in the service settings a protocol for data plane operations (HTTP or HTTPS) and specify their own TLS certificate if HTTPS is selected.
Note
When working with (or connecting to) Yandex Cloud APIs, make sure to use TLS 1.2 or higher, since its prior versions are vulnerable.
For example, by using the gRPC interfaces of Yandex Cloud, you can enforce TLS 1.2 or higher. That's because gRPC is based on HTTP/2 where TLS 1.2 is the minimum supported TLS version.
Support for legacy TLS protocols in Yandex Cloud services will gradually be discontinued.
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 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:
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.
- In the management console, select the cloud or folder to check the buckets in.
- In the list of services, select Object Storage.
- Go to the bucket settings.
- Go to the HTTPS tab.
- Make sure that access over the protocol is enabled and a certificate is specified.
- If access over HTTPS is enabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
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 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.
- In the management console, select the cloud or folder to check the load balancers in.
- In the list of services, select Application Load Balancer.
- Go to the load balancer settings.
- Make sure that HTTPS is specified for the load balancer.
- If HTTPS is specified, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to output the list of all load balancers without HTTPS:
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 ALB in $(yc application-load-balancer load-balancer list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc application-load-balancer load-balancer get --id $ALB --format json | jq -r '. | select(.listeners[0].tls | not)' | jq -r '.id' done; done; done
-
If an empty list is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Enable an HTTPS listener using the instructions.
4.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.
- In the management console, select the cloud or folder to check the gateways in.
- In the list of services, select API Gateway → Gateway settings → Domains.
- Make sure the domain and certificate are enabled.
- If the domain and certificate are active, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to output the list of all API gateways without any domains and certificates enabled:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for APIGW in $(yc serverless api-gateway list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc serverless api-gateway get --id $APIGW --format json | jq -r '. | select(.attached_domains[0].certificate_id | not)' | jq -r '.id' done; done; done
-
If an empty list is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
- In the management console, select the cloud or folder to enable domains and certificates in.
- In the list of services, select API Gateway → Gateway settings → Domains.
- Enable the domains and certificates.
4.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.
- In the management console, select the cloud or folder to check the resources in.
- In the list of services, select Cloud CDN.
- Go to the resource settings, the Additional tab.
- Make sure the Origin request protocol field is set to HTTPS.
- Make sure the Certificate field specifies your own certificate or a Let’s encrypt certificate.
- If HTTPS and your own certificate are specified, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to output the list of all resources without any certificates and HTTPS to origins enabled:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for CDN in $(yc cdn resource list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc cdn resource get --id $CDN --format json | jq -r '. | select(.origin_protocol=="HTTPS" and .ssl_certificate.type=="CM" | not)' | jq -r '.id' done; done; done
-
If an empty list is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Enable a certificate and HTTPS using the instructions.
Providing 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 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
.
Make sure that the stored data is encrypted.
To get a list of all extensions set in a database, run this command:
yc managed-postgresql database get <database_name> --cluster-id <managed_postgre_cluster_id> --format=json | jq -r '.extensions | .[].name'
If the command output contains the pgcrypto
string, the database has an extension for application-level data encryption enabled.
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 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?.
Make sure that the stored data is encrypted.
4.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
)
When creating a disk, make sure to enable Encrypted disk.
Guides and solutions to use:
Encrypt the disk of your Yandex Compute Cloud VM.
Managing keys
We recommend using Key Management Service to encrypt data and manage keys. KMS helps you protect data in the Yandex Cloud infrastructure. You can also use it to encrypt or decrypt any of your data.
KMS uses AES-GCM encryption mode. You can select the key length (128, 192, or 256 bits) and set up the preferred key rotation period.
4.9 Key Management Service keys are stored in a hardware security module (HSM)
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.
- In the management console, select the cloud or folder to check the keys in.
- In the list of services, select Key Management Service.
- Go to the Keys tab.
- Make sure the Encryption algorithm field is set to AES-256 HSM.
- If AES-256 HSM is specified, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to output the list of all of your organization's KMS keys and their encryption algorithms:
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 yc kms symmetric-key list --folder-id=$FOLDER_ID --format json | jq -r '.[] | "KEY_ID " + .id + "FOLDER_ID " + .folder_id + "ALGORITM_ID " + .default_algorithm' done; done
-
If the encryption algorithm contains AES-256 HSM, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
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 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
, orkms.keys.encrypterDecrypter
) - Keys (
kms.keys.encrypterDecrypter
andkms.editor
)
- In the management console, select the cloud or folder to check the key access permissions in.
- Click the Access permissions tab.
- Make sure the
admin
,editor
,kms.admin
,kms.editor
, andkms.keys.encrypterDecrypter
roles are only granted to controlled users. - You can check the actual key access permissions only via the CLI.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for accounts at the organization level:
export ORG_ID=<organization ID> yc organization-manager organization list-access-bindings --id=${ORG_ID} --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="editor" or .role_id=="kms.admin" or .role_id=="kms.editor" or .role_id=="kms.keys.encrypterDecrypter")'
-
If there are no accounts in the list, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
Find accounts with roles assigned at the cloud level:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="editor" or .role_id=="kms.admin" or .role_id=="kms.editor" or .role_id=="kms.keys.encrypterDecrypter")' done
-
If there are no accounts in the list, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
Run the command below to search for accounts with primitive roles assigned at the level of all folders in your clouds:
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 yc resource-manager folder list-access-bindings --id=$FOLDER_ID --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="editor" or .role_id=="kms.admin" or .role_id=="kms.editor" or .role_id=="kms.keys.encrypterDecrypter")' && echo $FOLDER_ID done; done
-
If there are no accounts in the list, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
Find accounts with roles assigned at the key level:
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 KEY in $(yc kms symmetric-key list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc kms symmetric-key list-access-bindings --id $KEY --format json done; done; done
Guides and solutions to use:
Check out who is granted access to KMS keys.
4.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 (= 232) 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
Note
Destroying any version of a key means destroying all data encrypted with it. You can protect a key against deletion by setting the deletionProtection parameter. However, it does not protect against deleting individual versions.
For more information about key rotation, see the KMS documentation, Key version.
- In the management console, select the cloud or folder to check the keys in.
- In the list of services, select Key Management Service.
- Go to the key settings.
- Find the Rotation period parameter.
- If the parameter is set to any value different from No rotation, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to output the list of all of your organization's KMS keys and their encryption algorithms:
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 yc kms symmetric-key list --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(.rotation_period | not)' | jq -r '.id' done; done
-
If an empty list is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Set the key rotation period.
4.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.
- In the management console, select the cloud or folder to check the keys in.
- In the list of services, select Key Management Service.
- Go to the key settings.
- Find the Deletion protection parameter.
- If it is set to Yes, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to output the list of all KMS keys without protection against deletion:
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 yc kms symmetric-key list --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(.deletion_protection | not)' | jq -r '.id' done; done
-
If an empty list is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Enable deletion protection.
Managing 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 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
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.
Note
When working in Terraform, we recommend using a script to fill in.tfstate
file.
- In the management console, select the cloud or folder to check the secrets in.
- In the list of services, select Lockbox.
- Make sure that at least one Lockbox secret is used.
- Find the Deletion protection parameter.
- If Lockbox is used or Kubernetes VMs or entities have Hashicorp Vault installed, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for at least one Lockbox secret:
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 yc lockbox secret list --folder-id=$FOLDER_ID --format=json done; done
-
If an empty list is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
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 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.
- In the management console, select the cloud or folder to check the functions in.
- In the list of services, select Cloud Functions.
- Go to the function settings, the Editor tab.
- Find the Lockbox secrets parameter.
- If the parameters of each object specify Lockbox secrets or there are no environment variables with secret data, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
Run the command below to search for all the cloud functions that use no Lockbox secrets and make sure that these functions use no secret data in environment variables:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for VER in $(yc serverless function version list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc serverless function version get $VER --format=json | jq -r '. | select(.secrets | not)' | jq -r '.id' done; done; done
-
If an empty list is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
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 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 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 logs
Introduction
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).
Note
For more information about Kubernetes events, see Collecting, monitoring, and analyzing audit logs in Yandex Managed Service for Kubernetes.
5.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.
- In the management console, select the cloud or folder to check the functions in.
- In the list of services, select Yandex Audit Trails.
- Make sure the Filter parameter is set to Organization.
- In addition, check that the destination of logs is Yandex Object Storage bucket, Cloud Logging log group, and Data Streams, that they are up and running, and that the logs are available for further analysis.
5.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.
Make sure that audit logs from Yandex Audit Trails are exported for analysis to a SIEM system or analyzed in the cloud using one of the available methods.
5.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.
5.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.
Run a manual check.
5.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:
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
To describe events to be searched for in audit logs, we recommend using Sigma
To get the exact time of OS- and application-level events, configure clock synchronization by following this guide.
Run a manual check.
5.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.
Run a manual check.
5.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.
Run a manual check.
5.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.
-
In the management console
, select the folder where your trail is located. -
In the list of services, select Audit Trails.
-
Select the trail you need.
-
Make sure the trail info page in Collecting data events lists all the services you want to collect data event logs for, specifying the correct audit log scope for each service.
List of supported services:
- Yandex Cloud DNS
- Yandex Compute Cloud
- Yandex Identity and Access Management
- Yandex Key Management Service
- Yandex Lockbox
- Yandex Managed Service for MongoDB
- Yandex Managed Service for MySQL®
- Yandex Managed Service for PostgreSQL
- Yandex Object Storage
- Yandex SpeechSense
- Yandex Smart Web Security
- Yandex Wiki
- Yandex WebSQL
6. Backups
6.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
- In the management console, select the cloud or folder to check the VMs in.
- In the list of services, select Compute Cloud.
- Make sure that the scheduled snapshot policy is set up on the VMs.
- In the list of services, select Cloud Backup.
- Make sure that it is enabled.
7. 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 security
Recommendations for protecting your application against bots
8.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.
- In the management console
, select the folder. - Select Yandex SmartCaptcha.
- Make sure at least one CAPTCHA is created for your application.
Guides and solutions to use:
Guide on creating a CAPTCHA in Yandex SmartCaptcha.
Recommendations 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)
8.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.
- In the management console
, select the folder the registry with Docker images belongs to. - Select the appropriate registry in Container Registry.
- Go to the Vulnerability scanner tab and click Edit settings.
- Make sure Docker image scans on push are enabled.
Guides and solutions to use:
Guide on scanning Docker images on push.
8.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.
- In the management console
, select the folder the registry with Docker images belongs to. - Select the appropriate registry in Container Registry.
- Go to the Vulnerability scanner tab and click Edit settings.
- Make sure that scheduled Docker image scans are enabled with a frequency of 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 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.
Run the command below to search for containerized images with the last scan date a week ago or less:
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 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
Make sure that artifact attestation is performed while building an application.
Guides and solutions to use:
Gitlab guide for software artifact attestation
8.6 Ensure artifact integrity
Signing artifacts enhances security to ensure your software validity, integrity, reliability, and compliance with the requirements.
Make sure that artifacts are signed while building an application.
Guides and solutions to use:
To sign artifacts within a pipeline, you can use Cosign
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 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.
Make sure that artifacts are verified while building an application.
Guides and solutions to use:
Guide on setting up the artifact signature.
8.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 theUltimate
license. - Copying pipeline sections to
.gitlab-ci.yml
files in your projects.
8.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
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.
- In the management console
, select the folder where you want to check the Smart Web Security status. - In the list of services, select Smart Web Security.
- Make sure you have security profiles created.
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 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.
- In the management console
, select the folder where you want to check a security profile for a WAF rule. - In the list of services, select Smart Web Security.
- Make sure your security profile has a security rule of the web application firewall type.
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 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.
- In the management console
, select the folder you want to check for ARL profiles. - In the list of services, select Smart Web Security.
- In the left-hand panel, select
ARL profiles and make sure you have ARL profiles connected to your security profile.
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 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
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.
- In the management console
, select the folder where your GitLab instance is located. - In the list of services, select Managed Service for GitLab.
- Select the instance you need and click Edit in the top-right corner of the page.
- Make sure to select a configured approval rule configuration in the Approval rules field.
Guides and solutions to use:
Enabling approval rules in the GitLab instance
9. Kubernetes security
Introduction
Yandex Managed Service for Kubernetes provides an environment for managing containerized applications in the 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 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.
- Make sure that names and descriptions of clusters, node groups, namespaces, services, and pods contain no sensitive data.
- Check configuration files for critical data.
- In the management console
, select the folder where your Managed Service for Kubernetes instance is located. - In the list of services, select Managed Service for Kubernetes.
- Make sure that Kubernetes node labels and Yandex Cloud service resource labels contain no sensitive data.
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 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.
Wherever possible, ensure maximum isolation between resources.
9.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:
-
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:
9.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
, andk8s.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.
Make sure the above recommendations are met.
9.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
- Using the kube-bench
tool, check whether the node group configuration is compliant with CIS Kubernetes Benchmark. The tool officially supports the Yandex Cloud node groups. - Starboard Operator
is a free tool that helps you automate scanning of images for vulnerabilities and checking that the configuration is compliant with CIS Kubernetes Benchmark. Starboard Operator supports integration with kube-bench and is used for its automatic startup.
9.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
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
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 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.
- In the management console
, select the folder the registry with Docker images belongs to. - Select the appropriate registry in Container Registry.
- Go to the Vulnerability scanner tab and click Edit settings.
- Make sure that scheduled Docker image scans are enabled with a frequency of at least once a week.
Guides and solutions to use:
9.8 One of the three latest Kubernetes versions is used with update monitoring
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.
To get a list of available versions for a Kubernetes cluster:
- Go to the folder page and select Managed Service for Kubernetes.
- Click the name of the Kubernetes cluster.
- Click Edit in the top-right corner.
- View the list of available versions in the Kubernetes version field under Master configuration.
To get a list of available versions for a Kubernetes node group:
- Go to the folder page and select Managed Service for Kubernetes.
- Click the name of the Kubernetes cluster you need and go to the Nodes manager tab.
- Select the Kubernetes node group from the list and click Edit in the top-right corner.
- Get a list of available versions in the Kubernetes version field.
If you do not have the Yandex Cloud command line interface yet, install and initialize it.
The folder specified in the CLI profile is used by default. You can specify a different folder using the --folder-name
or --folder-id
parameter.
To get a list of available versions, run the following command:
yc managed-kubernetes list-versions
To get a list of available versions, use the list.
Guides and solutions to use:
9.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.
Make sure that you have backups of your data from node groups of Kubernetes clusters.
Guides and solutions to use:
You can create backups of Kubernetes cluster node group data using the Velero
When working with Velero that is installed manually, you can use nfs
9.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:
You can control Dockerfile in your CI/CD pipeline using the Conftest
When using minimal images or distroless images without a shell, we recommend using ephemeral containers
Make sure you have the check lists in place to meet the requirements for secure creation of images.
9.11 The Kubernetes security policy is in place
The requirements listed in Kubernetes Pod Security Standards
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
Verify compliance with the Kubernetes Pod Security Standards.
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
- Kyverno CLI
9.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
You can also use:
Make sure that audit logs are being collected.
ClickHouse® is a registered trademark of ClickHouse, Inc