Standard for securing Yandex Cloud infrastructure 1.1
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
What is new in version 1.1
List of changes to version 1.1. compared to version 1.0:
-
Added the following items:
- 1.20 Impersonation is used wherever possible.
- 1.21 Resource labels are used.
- 1.22 Yandex Cloud security notifications are enabled.
- 1.23 The
auditor
role is used to prevent access to user data. - 3.4.2 Integrity control of a VM runtime environment.
- 3.28 Antivirus protection is used.
- 3.29 Yandex Managed Service for Kubernetes security guidelines are used.
- 4.16 There is a guide for cloud administrators on handling compromised secrets.
-
Updated the following items:
- 1.4, 1.14 Added recommendations for using the
auditor
role. - 1.9 Added recommendations for placing critical service accounts in separate folders.
- 1.12 Added
editor
to the list of privileged roles assigned at the organization, cloud, and folder levels. - 4.7 Added a guide on how to encrypt data in Yandex Managed Service for PostgreSQL and Yandex Managed Service for Greenplum® using
pgcrypto
and KMS. - 4.13 Added recommendations for using Yandex Lockbox in Terraform without writing the information to
.tfstate
.
- 1.4, 1.14 Added recommendations for using the
-
Added the 9. Application security section:
- 9.1 Yandex SmartCaptcha is used.
- 9.2 Enabled the scan on push policy for the containerized image vulnerability scanner.
- 9.3 Container images are periodically scanned.
- 9.4 Container images used in a production environment have the last scan date a week ago or less.
- 9.5 Software artifacts are built using attestations.
- 9.6 Artifacts within a pipeline can be signed using Cosign, a third-party command line utility.
- 9.7 Artifacts are checked when deployed in Yandex Managed Service for Kubernetes.
- 9.8 Ready-made blocks of a secure pipeline are used.
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:
- Identity and Access Management (IAM)
- Application Load Balancer
- Audit Trails
- Certificate Manager
- Cloud DNS
- Cloud Logging
- Compute Cloud
- Key Management Service
- Yandex Lockbox
- Managed Service for ClickHouse®
- Managed Service for GitLab
- Managed Service for MongoDB
- Managed Service for MySQL
- Managed Service for PostgreSQL
- Managed Service for Redis
- Network Load Balancer
- Object Storage
- Cloud Organization
- Resource Manager
- Virtual Private Cloud
- Managed Service for YDB
The standard can be used as the basis for developing company-specific recommendations. Not all of the information security measures and recommendations from this document are applicable. Moreover, additional measures and recommendations that are not included in the current standard may be required.
Structure of the standard
The standard describes recommendations for the following security objectives:
- Authentication and access control
- Network security
- Secure configuration of a virtual environment
- Data encryption and key management
- Collecting, monitoring, and analyzing audit logs
- Vulnerability management
- Backups
- Physical security
- Application security
Requirements to meet before you start
Before you perform checks, make sure that:
- You have the YC CLI installed and set up according to the instructions.
- You have logged in to the management console
. - The jq utility is installed.
You can automate the audit of compliance with all the recommendations using available solutions from our partners:
- Neocat: Product for cloud security management from Neoflex. It is used as an isolated installation within the user cloud perimeter and no administrator privileges need to be granted.
- Cloud Advisor: Agentless platform that identifies and prioritizes cloud security risks, helps you reduce costs, ensure compliance with regulatory requirements, and manage your cloud infrastructure.
Responsibility 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 control
In Yandex Cloud, identification, authentication, and access control is performed by Yandex Identity and Access Management (IAM) and Yandex Cloud Organization.
The platform works with three categories of users:
- Yandex accounts: Accounts in Yandex ID.
- Federated accounts: Accounts in a corporate SAML-compatible identity federation, such as Active Directory.
- Service accounts: Accounts that can be used by programs to manage resources.
Yandex ID accounts and federated accounts are authenticated in their own systems. Yandex Cloud has no access to these users' passwords and only authenticates service accounts via IAM.
User access to cloud resources is regulated by roles. Yandex Cloud services may provide different levels of granularity while granting permissions: in some cases, a role can be assigned directly to a service resource, in other cases, permissions are only granted at the level of the folder or cloud where the service resource is located.
This ensures interaction of different categories of resources, roles, and users in the Yandex Cloud infrastructure. Access to resources is managed by IAM. IAM controls each request and makes sure that all operations with resources are only run by users who have the appropriate permissions.
1.1 An identity federation (Single Sign-On, SSO) is 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
, that is used for federation management.
To make sure that all authentication requests from Yandex Cloud contain a digital signature, enable the Sign authentication requests option. To complete the configuration, download and install a Yandex Cloud certificate. You can download the certificate in the Sign authentication requests field immediately after creating a federation.
- Open the Yandex Cloud console in your browser.
- Go to All services → Yandex Cloud Organization → Federations.
- If the list contains at least one identity federation configured, 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
-
View information about the federations configured:
yc organization-manager federation saml list \ --organization-id=<organization ID>
-
If the list contains at least one identity federation configured, the recommendation is fulfilled. 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.2 Yandex ID accounts are only used in exceptional cases
The best approach to account management, in terms of security, is using identity federations (for more information, see recommendation 1.1). Therefore, you should do your best to ensure that your organization's list of users only contains federated users (those with the FEDERATION ID
attribute) and there are as few Yandex ID accounts on the list as possible. The following exceptions are allowed:
- Account with the
billing.accounts.owner
permissions (technically, this role can now be granted to a Yandex ID account only). - Account with the
organization-manager.organizations.owner
andresource-manager.clouds.owner
permissions, only if you use it in case of emergency, such as when a federation's setup failed. If necessary, you can delete a privileged passport account with 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 the account on the list of valid 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 to the group can manage other users' membership in the group. Users are granted these permissions in the following cases:
- The user is assigned the
organization-manager.groups.memberAdmin
role for an organization. - The user is assigned the
organization-manager.groups.memberAdmin
role for a specific group as a resource. - The user is assigned the
organization-manager.organizations.owner
oradmin
role or another privileged role for the entire organization. - The user is assigned 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 the desired group → Group access rights.
- 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 rights 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 the specified service. You can see the list of all service roles in the Yandex Cloud roll reference.
Use the auditor role without data access wherever possible.
- Open the Yandex Cloud console in your browser.
- Go to All services → Yandex Cloud Organization → Users.
- If no accounts in the Access rights column have such primitive roles as
admin
,editor
, andviewer
, the recommendation is fulfilled. 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 rights tab.
- If no accounts in the Roles column have such primitive roles as
admin
,editor
, andviewer
, the recommendation is fulfilled. Otherwise, proceed to theGuides and solutions to use
. - Next, go to each folder of each cloud and, similarly, select the Access rights tab.
- If no accounts in the Roles column have such primitive roles as
admin
,editor
, andviewer
, the recommendation is fulfilled. 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 a service account to a VM instance and get a token using the metadata service.
-
In addition, set up a local firewall on the VM instance so that only the necessary processes and system users have access to the metadata service (IP address:
169.254.169.254
).Example of blocking access for all users except the specified one (in this case,
root
):sudo iptables --append OUTPUT --proto tcp \ --destination 169.254.169.254 --match owner ! --uid-owner root \ --jump REJECT
The cloud entities with service accounts assigned must be registered and limited, because, for example, if a service account is assigned to a VM, a hacker may get the service account's token from the metadata service from within the VM.
- 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. Sensitive data may be stored in any metadata field. However, the most common one is user-data
(due to its use in the cloud-init utility).
See the list of all regular expressions used to search for cloud accounts' credential secrets:
- yandex_cloud_iam_cookie_v1 : c1.[A-Z0-9a-z_-]+[=]{0,2}.[A-Z0-9a-z_-]{86}[=]{0,2}
Yandex.Cloud Session Cookie - yandex_cloud_iam_token_v1 : t1.[A-Z0-9a-z_-]+[=]{0,2}.[A-Z0-9a-z_-]{86}[=]{0,2}
Yandex.Cloud IAM token - yandex_cloud_iam_api_key_v1 : AQVN[A-Za-z0-9_-]{35,38}
Yandex.Cloud API Keys (Speechkit, Vision, Translate) - yandex_passport_oauth_token : y[0-6]_[-_A-Za-z0-9]{55}
Yandex Passport OAuth token - yandex_cloud_iam_access_secret : YC[a-zA-Z0-9_-]{38}
Yandex.Cloud AWS API compatible Access Secret
-
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 cloud keys in the metadata service represented as plaintext, using the example of a Yandex Cloud IAM 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 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.
- Click
Edit VM in the top-right corner of the page. - 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.
Sample REST API request
curl -X POST -H "Authorization: Bearer <IAM_token>" \
-d '{"delete":["<SSH_key_name>"]}' https://compute.api.cloud.yandex.net/compute/v1/instances/<VM_ID>/updateMetadata
1.7 Getting a token via AWS IMDSv1 is disabled on the 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.
- At the top of the screen, go to the Service accounts tab.
- Check the list of service accounts.
- Repeat the steps for other folders.
- Go to the Access rights tab at the cloud and folder levels.
You can only view the organization-level access rights in 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 rights of a specific service account to 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 rights 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 rights 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
-
If the lists do not contain any rights that are not required, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
Guides and solutions to use:
Remove the unnecessary rights 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 rights should be placed as a resource in a separate folder. It prevents accidental granting of rights to this account along with the rights to the folder with the respective service component.
- Open the Yandex Cloud console in your browser.
- Go to the appropriate folder.
- At the top of the screen, go to the Service accounts tab.
- Click the service account you need and go to the Access rights tab.
- Check the access rights assigned to the service account.
- If the list only contains valid administrators, 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 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 rights to a specific service account as a resource:
yc iam service-account list-access-bindings \ --id <service_account_ID>
-
If the list only contains valid administrators, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
Guides and solutions to use:
Remove the unnecessary service account rights using IAM.
1.10 Service account keys are rotated on a regular basis
Yandex Cloud lets you create the following access keys for service accounts:
- IAM tokens that are valid for 12 hours.
- API keys with unlimited validity.
- Authorized keys with unlimited validity.
- AWS API-compatible static access keys with unlimited validity.
You need to rotate keys with unlimited validity yourself: delete and generate new ones. You can check out the date when a key was created in its properties. Perform key rotation at least once in 90 days as recommended in the information security standards, such as PCI DSS.
- Open the Yandex Cloud console in your browser.
- Go to the appropriate folder.
- At the top of the screen, go to the Service accounts tab.
- Click the service account and see the date of each key's generation under Access key properties.
- Repeat the steps for each of your folders.
- If the keys were created less than 90 keys ago, 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
-
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
-
If the list of keys of any type contains no keys with the date in the
created_at
field greater than 90 days, the recommendation is fulfilled. 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 account, set up 2FA using this guide
- Open the Yandex ID UI in your browser.
- Go to the Security
tab. - Make sure that the login method using an additional key is specified.
- If this method is set up, 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 account.organization-manager.organizations.owner
.organization-manager.admin
.resource-manager.clouds.owner
.admin
andeditor
assigned for an organization.admin
andeditor
assigned for a cloud.admin
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 as well as use all the administrator privileges.
The resource-manager.clouds.owner
role is assigned automatically when you create your first cloud in the organization. A user with this role can perform any operation with the cloud or its resources and grant cloud access to other users: assign roles and revoke them.
Assign the resource-manager.clouds.owner
and organization-manager.organizations.owner
roles to one or more employees with a federated account. Set a strong password for the Yandex ID account that was used to create the cloud, and use it only when absolutely necessary (for example, if the federated access fails).
Make sure to fully protect your federated account that is granted one of the privileged roles listed above:
- Enable two-factor authentication.
- Disable authentication from devices beyond the company's control.
- Configure login attempt monitoring and set alert thresholds.
Assign federated accounts the admin
roles for clouds, folders, and billing accounts. Minimize the number of accounts with these roles and regularly review the expedience of these roles for the accounts they are assigned to.
Checking roles for the Yandex Cloud Billing service:
- Open the Yandex Cloud management console in your browser.
- Go to Yandex Cloud Billing
. - Check to whom the
billing.accounts.owner
andadmin
roles are granted.
Checking roles for an organization:
- Open the Yandex Cloud management console in your browser.
- Go to All services → Yandex Cloud Organization → Users.
- Check to whom the
admin
,organization-manager.organizations.owner
,organization-manager.admin
, andresource-manager.clouds.owner
roles are granted.
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 rights tab.
- Check to whom the
admin
,editor
, andresource-manager.clouds.owner
roles are granted.
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 rights tab.
- Check to whom the
admin
role is granted. - If all the privileged roles are granted to trusted administrators, 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 organization-level privileged rights:
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 rights:
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 rights 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
-
If all the privileged roles are granted to trusted administrators, the recommendation is fulfilled. 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 rights.
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.
- If possible, create a separate account for third-party employees in your corporate IdP and assign the required policies to this account.
- Require them to handle their account secrets with care.
- Review the relevance of external user access to your cloud infrastructure.
- Use the auditor role without data access wherever possible.
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 users who have authenticated. These are all registered users or Yandex Cloud service accounts: both from your clouds and other users' clouds.All users
: Any user. No authentication is required.
Warning
Currently, All users
is only supported for the following services: Object Storage (when using ACL-based access management), Container Registry, and Cloud Functions. For other services, assigning a role to the All users
group is the same as doing so 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 rights tab.
- Check whether there are
All users
andAll authenticated users
among the users.
Checking roles in a folder:
- Open the Yandex Cloud management console in your browser.
- Go to the appropriate folder of the appropriate cloud and open the Access rights tab.
- Check whether there are
All users
andAll authenticated users
among the 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
andallAuthenticatedUsers
. - Open the bucket and check the ACL of each of its objects for
allUsers
andallAuthenticatedUsers
. - 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 rights on the left.
- Check whether there are
All users
andAll authenticated users
among the 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.
- If there are no
All users
andAll authenticated users
subjects in each specified resource, the recommendation is fulfilled. 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")'
-
To search for
allUsers
andallAuthenticatedUsers
access permissions at the cloud level, run the following command: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
-
To search for
allUsers
andallAuthenticatedUsers
access permissions at the folder level, run the following command: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
-
To search for
allUsers
andallAuthenticatedUsers
access permissions at the Container Registry level in all folders, run the following command: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
-
To search for
allUsers
andallAuthenticatedUsers
access permissions at the Cloud Functions level in all folders, run the following command: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 contains
allUsers
andallAuthenticatedUsers
, the recommendation is fulfilled. Otherwise, proceed to theGuides and solutions to use
.
Guides and solutions to use:
If All users
and All authenticated users
have access permissions, you need to delete these permissions.
1.17 Contact information of the person in charge of an organization is 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.
- If it is valid, the recommendation is fulfilled. 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.
- If its value is less than or equal to 6 hours, 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 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
-
If an empty string is output, the recommendation is fulfilled. 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 receives an IAM token using built-in Yandex Cloud mechanisms without having to transfer any secrets to the function from outside. Do the same for your VMs.
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 bindings 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, for tagging resources involved in processing personal data under Federal Law No. FZ-152 of the Russian Federation on Personal Data, select the 152-fz:true
label for:
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 that do not require data access, such as external contractors or auditors.
auditor
is a role with least privilege without access to service data. It grants permission to read service configurations and metadata.
The auditor
role allows you to perform the following operations:
- View information about a resource.
- View resource metadata.
- View a list of operations with a resource.
To control access more selectively and implement the principle of least privilege, use the auditor
role by default.
- In the management console
, go to the appropriate folder. - Click the Access bindings 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 unnecessary account rights using IAM.
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. See the guide on how to set up security groups in Creating a security group. You can specify a security group in the VM settings.
You can use security groups to protect:
- VMs
- Managed databases
- Yandex Application Load Balancer load balancers
- Yandex Managed Service for Kubernetes clusters
The list of available services is being extended.
You can manage network access without security groups, for example, using a separate VM as a firewall based on an NGFW image from Yandex Cloud Marketplace or a custom image. Using the NGFW can be critical to customers if they need the following features:
- Logging network connections.
- Streaming traffic analysis for malicious content.
- Detecting network attacks by signature.
- Other features of conventional NGFW solutions.
Make sure you use security groups in your clouds on each cloud object, or a separate VM based on the NGFW from Cloud Marketplace, or the Bring Your Own Image (BYOI) approach that allows you to deploy your own equipment or system images.
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 the "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 Marketplace product parameters have one of the NGFW product names specified, such as Check Point CloudGuard IaaS — Firewall & Threat Prevention PAYG or UserGate NGFW, 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 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 the result with the cloud resource
ID
is output, proceed to the "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 the
ID
of a VM with the NGFW is output, the recommendation is fulfilled. If an empty string is output, proceed to the "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 Check Point NGFW on your VM. - Refer to this guide
on using the UserGate NGFW in the cloud. - Use NGFW in active-passive
mode.
2.2 Virtual Private Cloud has at least one security 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 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 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 of the
SG_ID
combinations next to theFOLDER_ID
of the folder hosting it has theIDs
specified, the recommendation is fulfilled. Otherwise, proceed to the "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-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 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 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 the "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 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 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 the "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 the Virtual Private Cloud component that safeguards cloud resources from DDoS attacks. DDoS Protection is provided in partnership with Qrator Labs. You can enable it yourself for an external IP address through cloud administration tools. Supported up to OSI L4.
- Advanced protection against DDoS attacks operates at Levels 3 and 7 of the OSI model. You can also follow load and attack parameters and enable Solidwall WAF in your Qrator Labs account. To enable advanced protection, contact your manager or technical support.
- 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 the "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 the "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 details in the Creating a VPN connection using OpenVPN section. You can also use certified data cryptographic security tools.
-
Dedicated private connection between a remote site and Yandex Cloud using Cloud Interconnect.
To access the infrastructure using control protocols (such as SSH or RDP), create a bastion VM. You can do this using a free Teleport
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 |
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 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 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 the "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
ID
of the NAT instance, proceed to the "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 passed to third-party recursive resolvers
To increase fault tolerance, some traffic may be routed to third-party recursive resolvers. To avoid this, contact support.
3. Secure configuration of a virtual environment
This section provides recommendations to customers on security settings in Yandex Cloud services and the use of additional data protection tools in virtual environments.
Overview
3.1 A serial console is either used under control or not used
On VMs, access to the serial console is disabled by default. The risks of using the serial console are listed in the Yandex Compute Cloud documentation, Getting started with the serial console.
When working with a serial console:
- Make sure that critical data is not output to the serial console.
- If you enable SSH access to the serial console, make sure that both the credentials management and the password used for logging in to the operating system locally are compliant with regulator standards. For example, in an infrastructure for storing payment card data, passwords must meet PCI DSS requirements: it must contain both letters and numbers, be at least 7 characters long, and be changed at least once every 90 days.
Note
According to the PCI DSS standard, access to a VM via a serial console is considered "non-console", and Yandex Cloud uses TLS encryption for it.
We do not recommend using access to the serial console unless it is absolutely necessary.
- In the management console, select the folder to check the VMs in.
- In the list of services, select Compute Cloud.
- Open the settings of all the necessary VMs.
- Under Access, find the Additional parameter.
- Serial console access must be disabled.
- If it is disabled for all the VMs, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Find the VM with access to the serial console enabled:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do echo "VM_ID: " && yc compute instance get --id=$VM_ID --full --format=json | jq -r '. | select(.metadata."serial-port-enable"=="1")' | jq -r '.id' && echo "FOLDER_ID: " $FOLDER_ID && echo "-----" done; done; done
-
If an empty value is set in VM_ID next to FOLDER_ID, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
If the serial console should not be used on the VM, disable it.
3.2 A benchmark image is used for VM deployment
When deploying virtual machines, we recommend:
- Preparing a VM image whose system settings correspond to your information security policy. You can create an image using Packer. See Getting started with Packer.
- Use this image to create a virtual machine or instance group.
- Look up the virtual machine's information to check that it was created using this image.
- In the management console, select the folder to check the VMs in.
- In the list of services, select Compute Cloud.
- Go to the Disks tab.
- Open the settings of all disks.
- Under Source, find the Identifier parameter.
- If every disk displays the ID of your benchmark image, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for the VM disks that do not contain the ID of your benchmark image:
export ORG_ID=<organization ID> export IMAGE_ID=<your reference image ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for DISK_ID in $(yc compute disk list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do echo "DISK_ID: " && yc compute disk get --id=$DISK_ID \ --format=json | jq -r --arg IMAGE_ID $IMAGE_ID '. | select(."source_image_id"==$IMAGE_ID | not)' | jq -r '.id' && echo "FOLDER_ID: " $FOLDER_ID && echo "-----" done; done; done
-
If an empty value is set in DISK_ID next to FOLDER_ID, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
- Find out why these VM disks use an image different from the benchmark one.
- Recreate the VMs with the appropriate image.
3.3 Terraform is used in accordance with best information security practices
With Terraform, you can manage a cloud infrastructure using configuration files. If you change the files, Terraform will automatically detect which part of your configuration is already deployed, and what should be added or removed. For more information, see Getting started with Terraform.
We do not recommend using private information in Terraform configuration files, such as passwords, secrets, personal data, or payment system data. Instead, you should use services for storing and using secrets in the configuration file, such as HashiCorpVault from Cloud Marketplace or Lockbox (to transfer secrets to the target object without using Terraform).
If you still need to enter private information in the configuration, take the following security measures:
- Use sensitive = true
for private information to exclude it from the console output when runningterraform plan
andterraform apply
. - Use terraformremotestate
. We recommend uploading a Terraform state to Object Storage and setting up configuration locks using Managed Service for YDB to prevent simultaneous edits by administrators. - Use the mechanism for transferring secrets to Terraform via env
instead of plain text or use built-in KeyManagementService features for encrypting data in Terraform using a separate file with private data. Learn more about this technique .
For more information about Object Storage security, see Object Storage below.
Note
When a configuration is deployed, you can delete the configuration file with private data.
Scan your Terraform manifests using Checkov
Collect data about using the Terraform best security practices from different points.
3.4. Integrity control is performed
3.4.1 File integrity control
Numerous information security standards require integrity control of critical files. To do this, you can use free host-based solutions:
Paid solutions are also available in Yandex Cloud marketplace, such as Kaspersky Security.
Collect data about using integrity control from different points.
3.4.2 Integrity control of a VM runtime environment
To control a VM's runtime environment (e.g., to enable access from the VM to a secure repository only when running it in the YC CLI cloud), you can use the identity document mechanism. When creating a VM, an identity document that stores information about the VM is generated. It contains IDs of the VM, Yandex Cloud Marketplace product, disk image, etc. This document is signed with a Yandex Cloud certificate. The document and its signature are available to VM processes through the metadata service. Thus, the processes identify the VM runtime environment, disk image, etc., to restrict access to the resources under monitoring.
Make sure that critical VMs have identity documents signed.
3.5 Principles of protection against side-channel attacks are used
To ensure the best protection against CPU level side-channel attacks (such as Spectre or Meltdown):
- Use full-core virtual machines (instances with a CPU share of 100%).
- Install updates for your operating system and kernel that ensure side-channel attack protection (for example, Kernelpage-tableisolation for Linux
or applications built using Retpoline ).
We recommend that you use dedicated hosts for the most security-critical resources.
Learn more
Yandex Object Storage
3.6 No public access to a Object Storage bucket is allowed
We recommend assigning minimum roles for a bucket using IAM and supplementing or itemizing them using a bucket policy (for example, to restrict access to the bucket by IP, grant granular permissions for objects, and so on).
Access to Object Storage resources is verified at three levels:
Verification procedure:
-
If a request passes the IAM check, the next step is the bucket policy check.
-
Bucket policy rules are checked in the following order:
- If the request meets at least one of the Deny rules, access is denied.
- If the request meets at least one of the Allow rules, access is allowed.
- If the request doesn't meet any of the rules, access is denied.
-
If the request fails the IAM or bucket policy check, access verification is performed based on an object's ACL.
In the IAM service, a bucket inherits the same access rights as those of the folder and cloud where it's located. For more information, see Inheritance of bucket access permissions by Yandex Cloud public groups. Therefore, we recommend that you only assign the minimum required roles to certain buckets or objects in Object Storage.
Bucket policies are used for additional data protection, for example, to restrict access to a bucket by IP, grant granular rights to objects, and so on.
With ACLs, you can grant access to an object bypassing IAM verification and bucket policies. We recommend setting strict ACLs for buckets.
Example of a secure Object Storage configuration: Terraform
- In the management console, select the cloud or folder to check the buckets in.
- In the list of services, select Object Storage.
- Click the three dots next to each bucket and check their ACLs for
allUsers
andallAuthenticatedUsers
. - Open the bucket and check the ACL of each of its objects for
allUsers
andallAuthenticatedUsers
. - Check that the object Read access section has the Public parameter enabled. Otherwise, proceed to the "Guides and solutions to use".
-
Configure the AWS CLI to work with a cloud.
-
Run the command below to check the bucket ACL for
allUsers
andallAuthenticatedUsers
:aws --endpoint-url=https://storage.yandexcloud.net s3api get-bucket-acl <your bucket's name>
Guides and solutions to use:
If public access is enabled, remove it or perform access control (grant permission to access public data consciously).
3.7 Object Storage uses Bucket Policies
Bucket policies set permissions for actions with buckets, objects, and object groups. A policy is triggered when a user makes a request to a resource. As a result, the request is either executed or rejected.
Bucket Policy examples:
- Policy that only enables object download from a specified range of IP addresses.
- Policy that prohibits downloading objects from the specified IP address.
- Policy that provides different users with full access only to certain folders, with each user being able to access their own.
- Policy that gives each user and service account full access to a folder named the same as the user ID or service account ID.
We recommend making sure that your Object Storage bucket uses at least one policy.
- In the management console, select the cloud or folder to check the bucket policies in.
- In the list of services, select Object Storage.
- Go to Bucket policy.
- Make sure that at least one policy is enabled. Otherwise, proceed to the "Guides and solutions to use".
-
Configure the AWS CLI to work with a cloud.
-
Run the command below to check the bucket ACL for
allUsers
andallAuthenticatedUsers
:aws --endpoint-url=https://storage.yandexcloud.net s3api get-bucket-policy --bucket <your bucket's name>
Guides and solutions to use:
Enable the required policy.
3.8 In Object Storage, the Object locks feature is enabled
When processing critical data in buckets, you must ensure that data is protected from deletion and that versions are backed up. This can be achieved by versioning and lifecycle management mechanisms, as well as by using object locks.
Bucket versioning is the ability to store the history of object versions. Each version is a complete copy of the object and occupies space in Object Storage. Using version control protects your data from both unintentional user actions and application faults.
If you delete or modify an object with versioning enabled, a new version of the object with a new ID is effectively created. In the case of deletion, the object becomes unreadable, but its version is kept and can be restored.
For more information about setting up versioning, see the Object Storage documentation, Bucket versioning.
For more information about lifecycles, see the Object Storage documentation, Bucket object lifecycles and Bucket object lifecycle configuration.
In addition, to protect object versions against deletion, use object locks. For more information about object lock types and how to enable them, see the documentation.
The storage period of critical data in a bucket is determined by the client's information security requirements and information security standards. For example, the PCI DSS standard states that audit logs should be stored for at least one year and be available online for at least three months.
- In the management console, select the cloud or folder to check the buckets in.
- In the list of services, select Object Storage.
- Open the settings of all buckets.
- Go to the Versioning tab and make sure it is enabled. Otherwise, proceed to the "Guides and solutions to use".
-
Configure the AWS CLI to work with a cloud.
-
Run the command below to check whether versioning is enabled:
aws --endpoint https://storage.yandexcloud.net \ s3api get-bucket-versioning \ --bucket <your bucket's name>
-
Run the command below to check whether versioning is enabled:
aws --endpoint-url=https://storage.yandexcloud.net/ \ s3api get-object-lock-configuration \ --bucket <your bucket's name>
Guides and solutions to use:
If public access is enabled, remove it or use access control (by only enabling it when necessary and if approved).
3.9 In Object Storage, logging of actions with buckets is enabled
When using Object Storage to store critical data, be sure to enable logging of actions with buckets. For more information, see the Object Storage documentation, Logging actions with a bucket.
This makes sure that data-plane logs with the following objects are written: PUT, DELETE, GET, POST, OPTIONS, and HEAD.
In a similar way, you can request writing these logs to Audit Trails, except reads. In the future, all these logs will be written to Audit Trails.
You can also analyze Object Storage logs in DataLens. For more information, see Analyzing Object Storage logs using DataLens.
Guides and solutions to use:
You can only use Terraform/API to check if logging is enabled by following the instructions.
3.10 In Object Storage, Cross-Origin Resource Sharing (CORS) is set up
If cross-domain requests
- In the management console, select the cloud or folder to check the buckets in.
- In the list of services, select Object Storage.
- Open the settings of all buckets.
- Go to the CORS tab and make sure that the configuration is set up. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Set up CORS.
Managed Services for Databases
3.11 A security group is assigned in managed databases
We recommend prohibiting internet access to databases that contain critical data, in particular PCI DSS data or private data. Configure security groups to only allow connections to the DBMS from specific IP addresses. To do this, follow the steps in Creating a security group. You can specify a security group in the cluster settings or when creating the cluster in the network settings section.
- In the management console, select the cloud or folder to check the databases in.
- In the list of services, select a service or services with managed databases.
- In the object settings, find the Security group parameter and make sure that at least one security group is assigned.
- If the parameters of each object have at least one security group set, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
Run the command below to search for Managed PostgreSQL DBs with no SG:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for DB_ID in $(yc managed-postgresql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-postgresql cluster get --id=$DB_ID --format=json | jq -r '. | select(.security_group_ids | not)' | jq -r '.id' done; done; done
-
If an empty string is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
Run the command below to search for Managed MySQL DBs with no SG:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql cluster get --id=$DB_ID --format=json | jq -r '. | select(.security_group_ids | not)' | jq -r '.id' done; done; done
-
If an empty string is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
If any databases without security groups are found, assign them or enable the Default security group functionality.
3.12 No public IP address is assigned in managed databases
Assigning a public IP to a managed database raises information security risks. We do not recommend assigning an external IP unless it is absolutely necessary.
- In the management console, select the cloud or folder to check the databases in.
- In the list of services, select a service or services with managed databases.
- In the object settings, go to the Hosts tab.
- If the parameters of each object have the Public access option disabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for managed DB clusters with public IPs:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql hosts list --cluster-id=$DB_ID --format=json | jq -r '.[] | select(.assign_public_ip)' | jq -r '.cluster_id' done; done; done
-
If an empty string is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Disable public access if it is not required.
3.13 The deletion protection feature is enabled
In Yandex Cloud managed databases, you can enable deletion protection. Deletion protection manages cluster protection from accidental deletion by a user. Enabled protection will not prevent a manual connection to a cluster to delete data.
- In the management console, select the cloud or folder to check the databases in.
- In the list of services, select a service or services with managed databases.
- In the object settings, go to the Advanced settings tab.
- If the parameters of each object have the Deletion protection option enabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for managed DB clusters with deletion protection disabled:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql cluster get --id=$DB_ID --format=json | jq -r '. | select(.deletion_protection | not)' | jq -r '.id' done; done; done
-
If an empty string is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
- In the management console, select the cloud or folder to enable deletion protection in.
- In the list of services, select a service or services with managed databases.
- In the object settings, go to the Advanced settings tab.
- In the object parameters, enable Deletion protection.
3.14 The setting that enables access from DataLens is not activated unless needed
Do not enable access to databases containing critical data from the management console, DataLens, or other services unless you have to. Access from DataLens may be required for data analysis and visualization. For such access, the Yandex Cloud service network is used, with authentication and TLS encryption. You can enable and disable access from DataLens or other services in the cluster settings or when creating it in the advanced settings section.
- In the management console, select the cloud or folder to check the databases in.
- In the list of services, select a service or services with managed databases.
- In the object settings, go to the Advanced settings tab.
- If the parameters of each object have Access from DataLens disabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Find managed DB clusters with access from DataLens enabled:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql cluster get --id=$DB_ID --format=json | jq -r '. | select(.config.access.data_lens)' | jq -r '.id' done; done; done
-
If an empty string is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
- In the management console, select the cloud or folder to disable access from DataLens in.
- In the list of services, select a service or services with managed databases.
- In the object settings, go to the Advanced settings tab.
- In the object parameters, disable Access from DataLens.
3.15 Access from the management console is disabled in managed databases
You may need access to the database from the management console to send SQL queries to the database and visualize the data structure.
We recommend that you enable this type of access only if needed, because it raises information security risks. In normal mode, use a standard DB connection as a DB user.
- In the management console, select the cloud or folder to check the databases in.
- In the list of services, select a service or services with managed databases.
- In the object settings, go to the Advanced settings tab.
- If the parameters of each object have Access from the management console disabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for managed DB clusters with access from the management console enabled:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql cluster get --id=$DB_ID --format=json | jq -r '. | select(.config.access.web_sql)' | jq -r '.id' done; done; done
-
If an empty string is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
- In the management console, select the cloud or folder to disable access from the management console in.
- In the list of services, select a service or services with managed databases.
- In the object settings, go to the Advanced settings tab.
- In the object parameters, disable Access from console.
Cloud Functions and Yandex API Gateway
3.16 Public cloud functions are only used in exceptional cases
In cases where the use of public functions is not explicitly required, we recommend that you use private functions. For more information about setting up access to functions, see Managing rights to access functions. We recommend using private functions and assigning rights to invoke functions to specific cloud users.
- In the management console, select the cloud or folder to check the functions in.
- In the list of services, select Cloud Functions.
- Open all the functions.
- In the function settings, go to the Overview tab.
- If the parameters of each object have the Public function option disabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
Run the command below to search for
allUsers
access rights at the Cloud Functions level in all folders:export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for FUN in $(yc serverless function list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc serverless function list-access-bindings --id $FUN --format=json | jq -r '.[] | select(.subject.id=="allAuthenticatedUsers" or .subject.id=="allUsers")' && echo $FUN done; done; done
-
If none of the specified resources contain
allUsers
andallAuthenticatedUsers
, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Disable public access.
3.17 Side-channel attacks in Cloud Functions are considered
Hosts and hypervisors running Cloud Functions contain all the applicable updates for side-channel attack protection. However, keep in mind that different clients' functions are not isolated by cores. Thus, there is technically an attack surface between one user's function and another's. Yandex Cloud security experts believe that side-channel attacks are unlikely in the context of functions, but this risk must be accounted for, particularly in the overall threats and risk analysis model employed by the PCI DSS infrastructure.
Make sure the most critical systems do not use Cloud Functions or this is considered in the risk analysis model.
3.18 Specifics of time synchronization in Cloud Functions are considered
The Cloud Functions service does not guarantee time synchronization prior to or during execution of requests by functions. To generate a function log with exact timestamps on the Cloud Functions side, output the log to stdout. The client can also independently accept function execution logs and label them with a timestamp on the receiving side. In this case, the timestamp is taken from the time source synced with Yandex Cloud. For more information about time synchronization, see the Compute Cloud documentation, Configuring clock synchronization.
3.19 Specifics of header management in Cloud Functions are considered
If the function is called to process an HTTP request, the returned result should be a JSON document containing the HTTP response code, response headers, and response content. Cloud Functions will automatically process this JSON and the user will receive data as a standard HTTP response. The client needs to manage the response headers on their own in accordance with regulator requirements and the threat model. For more information on how to process an HTTP request, refer to the Cloud Functions manual, Invoking a function in Cloud Functions.
3.20 Serverless Containers/Cloud Functions uses the VPC internal network
By default, the function is invoked in the isolated IPv4 network with the NAT gateway enabled. For this reason, only public IPv4 addresses are available.
If necessary, you can specify a cloud network in function settings. In this case, the function:
- Is executed in a given cloud network.
- Has access to the internet and user resources in the given network, such as databases and VMs.
- Has an IP address within the
198.19.0.0/16
range when accessing user resources.
- In the management console, select the cloud or folder to check the functions in.
- In the list of services, select Cloud Functions.
- Open all the functions.
- In the object settings, go to the Edit function version tab.
- If the parameters of each object have Network — VPC set, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
Run the command below to search for any cloud functions that have no network settings specified in VPC:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for VER in $(yc serverless function version list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc serverless function version get $VER --format=json | jq -r '. | select(.connectivity.network_id | not)' | jq -r '.id' done; done; done
-
If an empty string is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
- Select the cloud or folder to check the functions in.
- Select Cloud Functions in the list of services.
- Open the function.
- In the object settings, go to the Edit function version tab.
- Set Network — VPC.
Managed Service for YDB
3.21 Recommendations for using confidential data in YDB are followed
It's prohibited to use confidential data as the names of databases, tables, columns, directories, and so on. It's prohibited to send critical data, such as payment card details, to Managed Service for YDB (both Dedicated and Serverless) as clear text. Prior to sending data, be sure to encrypt it at the application level. For this you can use the KMS service or any other method compliant with the regulator standard. For data where the storage period is known in advance, we recommend that you configure the Time To Live
3.22 Recommendations for SQL injection protection in YDB are followed
When working with the database, use parameterized prepared statements
3.23 No public access to YDB is allowed
When accessing the database in dedicated mode, we recommend that you use it inside VPC, disabling public access to it from the internet. In serverless mode, the database can be accessed from the internet. You must therefore take this into account when modeling threats to your infrastructure. For more information about the operating modes, see the Serverless and dedicated modes section in the Managed Service for YDB documentation.
When setting up database permissions, use the principle of least privilege.
- In the management console, select the cloud or folder to check the database in.
- In the list of services, select Managed Service for YDB.
- Open all the databases.
- In the database settings, go to the Network tab.
- If the parameters of each object have the Public IP addresses option disabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for managed DB clusters with public IPs:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for DB_ID in $(yc managed-mysql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc managed-mysql hosts list --cluster-id=$DB_ID --format=json | jq -r '.[] | select(.assign_public_ip)' | jq -r '.cluster_id' done; done; done
-
If an empty string is output, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Disable public access if it is not required.
3.24 Recommendations for YDB backups are followed
When creating on-demand backups, make sure that the backup data is properly protected.
When creating backups on demand in Object Storage, follow the recommendations in the Object Storage subsection above (for example, use the built-in bucket encryption feature).
Yandex Container Registry
3.25 ACL by IP address is set up for Yandex Container Registry
We recommend that you limit access to your Container Registry to specific IPs.
- In the management console, select the cloud or folder to check the registry in.
- In the list of services, select Container Registry.
- In the settings of the specific registry, go to the Access for IP address tab.
- If specific IPs to allow access for are set in the parameters, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for CRs that are not filtered by IP:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for CR in $(yc container registry list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc container registry list-ip-permissions --id=$CR --format=json | jq -r '.[] | select(.ip)' | jq -r '.action' && echo $CR "IF ACTION PULL/PUSH exist before CR then OK" done; done; done
-
If PULL/PUSH is output before each registry ID, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Specify the IP addresses for registry access.
Yandex Container Solution
We do not recommend that you use privileged containers to run loads that process untrusted user input. Privileged containers should be used for the purposes of administering VMs or other containers.
- In the management console, select the cloud or folder to check the VMs in.
- In the list of services, select Compute Cloud.
- Open the settings of a specific VM with a Container Optimized Image.
- In the Docker container's Settings, find the Privileged mode parameter.
- If it is disabled, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for CRs that are not filtered by IP:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc compute instance get --id=$VM_ID --full --format=json | jq -r '. | select(.metadata."docker-container-declaration")| .metadata."docker-container-declaration" | match("privileged: true") | .string' && echo $VM_ID done; done; done
-
If there is no
privileged: true
in front of each VM ID, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
- In the management console, select the cloud or folder to check the VMs in.
- In the list of services, select Compute Cloud.
- Open the settings of a specific VM with a Container Optimized Image.
- In the Docker container's Settings, disable the Privileged mode parameter.
3.26 A Yandex Certificate Manager certificate is valid for at least 30 days
You can use Yandex Certificate Manager to manage TLS certificates for your API gateways in the API Gateway, as well as your websites and buckets in Object Storage. Application Load Balancer is integrated with Certificate Manager for storing and installing certificates. We recommend that you use Certificate Manager to obtain your certificates and rotate them automatically.
When using TLS in your application, we recommend that you limit the list of your trusted root certificate authorities (root CA).
When using certificate pinning, keep in mind that Let's Encrypt certificates are valid for 90 days
We recommend that you update certificates in advance if they are not updated automatically.
- In the management console, select the cloud or folder to check the VMs in.
- In the list of services, select Yandex Certificate Manager.
- Open the settings of each certificate and find the End date parameter.
- If the parameter shows that the certificate will be valid for at least 30 days more, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Search for any of your organization's certificates with the end date:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for CERT_ID in $(yc certificate-manager certificate list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc certificate-manager certificate get --id $CERT_ID --format=json | jq -r '. | "Date of the end " + .not_after + " --- Cert_ID " + .id' done; done; done
-
If there is no
privileged: true
in front of each VM ID, the recommendation is fulfilled. Otherwise, proceed to the "Guides and solutions to use".
Guides and solutions to use:
Update the certificate or set up auto updates.
Yandex Managed Service for GitLab
3.27 Recommendations on security settings for a GitLab instance are followed
See the recommendations here.
Run a manual check.
3.28 Antivirus protection is used
Make sure to provide anti-malware protection within your scope of responsibility. You can use a variety of solutions from our partners in Yandex Cloud Marketplace.
Antivirus solution images are available in Yandex Cloud Marketplace. License types and other required information are available in the product descriptions.
Make sure that critical systems are protected with antivirus solutions.
Guides and solutions to use:
Follow the vendor guide to install the AV solution.
3.29 Yandex Managed Service for Kubernetes security recommendations are used
Check the recommendations in Security Kubernetes.
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 the "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 the protocol to be used for data plane operations (HTTP or HTTPS) in the service settings, and specify their own TLS certificate if HTTPS is selected.
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 bucket policy aws:securetransport
to ensure that 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. See how to set up the listener in 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 VMs, disk encryption using KMS is set up
If disk encryption is required, place your application files on a VM's secondary disk (not the boot disk) and configure full disk encryption for it.
Manually check whether this solution is used for critical VMs.
Guides and solutions to use:
4.7 For critical data, MDB encryption with KMS is used
If data encryption is required, make sure to encrypt data at the application level prior to writing it to a database, for example, using KMS and an add-on, such as pgcrypto
.
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
line, it means that the database has an extension for application-level data encryption enabled.
Guides and solutions to use:
You can learn how to encrypt data in Yandex Managed Service for PostgreSQL and Yandex Managed Service for Greenplum® using pgcrypto
in Using pgcrypto in Managed Service for Greenplum®.
4.8 Data encryption at the application level is 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.
Managing keys
We recommend that you use Key Management Service for encrypting data and managing keys. KMS helps you protect data in the Yandex Cloud infrastructure. You can also use it to encrypt or decrypt any of your data.
KMS uses AES-GCM encryption mode. You can select the key length (128, 192, or 256 bits) and set up the preferred key rotation period.
4.9 Key Management Service keys are stored in a hardware security module (HSM)
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 users under control
To access the KMS service, you need an IAM token.
To automate operations with KMS, we recommend that you create a service account and run commands and scripts under it. If you use VMs, get an IAM token for your service account using the mechanism of assigning a service account to your VM. For other ways to get an IAM token for your service account, see the IAM documentation, Getting an IAM token for a service account.
We recommend that you grant granular permissions for specific keys in the KMS service to your users and service accounts. For more information, see the KMS documentation, Access management in Key Management Service.
For more information about security measures for access control, see Authentication and access control.
To check the KMS key access permissions, check who has access permissions for:
- Organization, cloud, and folders with the
admin
,editor
,kms.admin
,kms.editor
, andkms.keys.encrypterDecrypter
permissions. kms.keys.encrypterDecrypter
andkms.editor
keys.
- In the management console, select the cloud or folder to check the key access permissions in.
- Click the Access bindings tab.
- Make sure the
admin
,editor
,kms.admin
,kms.editor
, andkms.keys.encrypterDecrypter
roles are only granted to users under control. - 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, e.g., Message Queue and Cloud Functions.
- Keys for services that store critical data, e.g., Managed Services for Databases.
For the first group, we recommend that you set up automatic key rotation with a rotation period longer than the data processing period in these services. When the rotation period expires, the old key versions must be deleted. In the case of automatic rotation and the deletion of old key versions, previously processed data cannot be restored and decrypted.
For data storage services, we recommend that you either manually rotate keys or use automatic key rotation, depending on your internal procedures for processing critical data.
A secure value for AES-GCM mode is encryption using 4294967296 (= 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 Make sure that deletion protection is enabled for KMS keys
Deleting a KMS key always means destroying data. Therefore, make sure to protect the keys against accidental deletion. KMS has the necessary feature.
- 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 the Encrypting secrets in Hashicorp Terraform section of the KMS documentation. It is not safe to openly transmit secrets through environment variables, because they are displayed in the VM properties.
Guides and solutions to use:
Encrypting secrets in Terraform to transfer them to a VM from a Container Optimized Image
For other recommendations on how to use Terraform safely, see Secure configuration: Terraform.
4.16 There is a guide for cloud administrators on what to do if their cloud secrets are compromised
In Yandex Cloud, the Secret Scanning Service is enabled for everyone by default.
It detects structured cloud secrets that are available in the public domain in the following sources:
- Public GitHub repositories
- Yandex search index
- Helm charts in the Kubernetes marketplace
The following cloud secrets are detected:
- Yandex Cloud Session Cookie
- Yandex Cloud IAM token
- Yandex Cloud API Key
- Yandex Passport OAuth token
- Yandex Cloud AWS API compatible Access Secret
- (NEW) Yandex Cloud SmartCaptcha Server Key
- (NEW) Lockbox structured secrets
The service automatically notifies a customer of any found secrets belonging to their infrastructure:
- By email
- Using Yandex Audit Trails events
Guides and solutions to use:
Make sure that:
- Contact information of the person in charge of an organization is valid.
- Yandex Audit Trails is enabled at the organization level.
- The administrator has read the guide to follow if secrets are compromised.
5. Collecting, monitoring, and analyzing audit 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.
Events in audit logs occur on different levels:
- Yandex Cloud level: Events that occur with Yandex Cloud resources.
- OS level.
- Application level.
- Network level (Flow Logs).
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. See this guide on how to start collecting logs. You can also learn more about the event format or check out the event reference.
To collect metrics, analyze Yandex Cloud-level events, and set up notifications, we recommend using Yandex Monitoring. It helps you track, for example, a sharp increase in the load on Compute Cloud, the number of Application Load Balancer requests per second (RPS), or significant changes in event statistics in Identity and Access Management.
You can also use Monitoring to monitor the health of the Audit Trails service itself and track security events. You can export metrics to a SIEM system via the API, see the instructions.
Solution: Monitoring Audit Trails and security events using Monitoring
You can export audit logs to a Cloud Logging or Data Streams log group and to a customer's SIEM system to analyze information about events and incidents.
List of important Yandex Cloud-level events to search for in audit logs:
Solution: Searching for important security events in audit logs
You can enable Yandex Audit Trails at the folder, cloud, and organization level. We recommend enabling Yandex Audit Trails at the level of the entire organization. Thus you will be able to collect audit logs in a centralized manner, e.g., to a separate security cloud.
- 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 your VM and configure reading JSON files from the bucket. You can also use utilities compatible with AWS Kinesis datastreams if sending audit logs to Yandex Data Streams.
If you have no SIEM, you can also analyze audit logs manually using one of the following methods (in descending order of convenience):
-
Searching for Yandex Cloud events in Yandex Query.
-
Searching for Yandex Cloud events in Cloud Logging.
-
Searching for Yandex Cloud events in Object Storage.
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.
6. Managing vulnerabilities
Introduction
Yandex Cloud is responsible for managing vulnerabilities and security updates in managed services. The client is responsible for managing vulnerabilities and security updates for all other system components.
For an example of the scope of responsibility for managing vulnerabilities and security updates, see Requirement 5 in the PCI DSS responsibility matrix
6.1 A vulnerability scanner is used for container images
We recommend using the image vulnerability scanner integrated into Container Registry.
- In the management console, select the cloud or folder to check the images in.
- In the list of services, select Container Registry.
- Go to each of the images and check the value of the Scan status column.
6.2 Vulnerability scanning is performed at the cloud IP level
We recommend that clients scan their own hosts for vulnerabilities. Cloud resources support the installation of custom virtual images of vulnerability scanners or software agents on hosts. There are many fee-based and free solutions for scanning.
Network scanners scan hosts that are accessible over a network. Generally, authentication can be configured on network scanners.
Examples of free network scanners:
Example of a free scanner that operates as an agent on hosts: Wazuh
You can also use a solution from Cloud Marketplace.
Run a manual check.
6.3 External security scans are performed according to the cloud rules
Customers hosting their own software in Yandex Cloud can perform external security scans for the hosted software, including penetration tests. You can run your own scans or use contractors. For more information, see Rules for performing external security scans.
Run a manual check.
6.4 The process of security updates is set up
A client must perform their own security updates within their scope of responsibility. Various automated tools are available for centralized automated OS and software updates.
Yandex Cloud publishes security bulletins to notify customers of newly discovered vulnerabilities and security updates.
6.5 A Web Application Firewall is used
To mitigate risks associated with web attacks, we recommend using a Web Application Firewall (WAF). A client can install and maintain a WAF independently or use the Yandex Smart Web Security WAF.
Installing a WAF on your own
WAF images are available from the Yandex Cloud Marketplace. License types and other required information are available in the product descriptions.
Solution: A fault-tolerant installation of PT Application Firewall built on Yandex Cloud
You can also install Wallarm WAF in Managed Service for Kubernetes. See the guide
Yandex Smart Web Security WAF
A client can use the Yandex Smart Web Security WAF. A web application firewall analyzes HTTP requests to a web app according to pre-configured rules. Based on the analysis results, certain actions are applied to HTTP requests.
You can manage the web application firewall using a WAF profile that connects to the security profile as a separate rule.
For more information about connecting to a security profile, see Getting started with a WAF profile.
- In the management console, select the cloud or folder to check the security profile in.
- In the list of services, select Smart Web Security.
- Check that the security profile was created with the Web Application Firewall rule type.
7. Backups
7.1 Cloud Backup or the scheduled snapshot mechanism is used
Make sure that all VMs in your organization get backed up using:
- Scheduled snapshots.
- Cloud Backup.
- 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.
8. Physical security
Yandex Cloud ensures the physical security of data centers. See a detailed description of its physical security measures.
If critical data is transmitted outside Yandex Cloud, the customer is responsible for managing physical access at all data processing locations.
9. Application security
Recommendations for protecting your application against bots
9.1 Yandex SmartCaptcha is used
To mitigate the risks associated with automated attacks on applications, we recommend using Yandex SmartCaptcha. The service checks user requests with its ML algorithms and only shows challenges to those users whose requests it considers suspicious. You do not have to place the "I’m not a robot" button on the page.
- 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)
9.2 Docker image scans on push to Yandex Container Registry
Auto scans of Docker images on push are critical for early detection and elimination of vulnerabilities to ensure secure deployment of containers. Reports on completed scans provide a brief description of detected vulnerabilities and issues and help you set priorities and eliminate security risks in containerized applications.
- In the management console
, select the folder that 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.
9.3 Regular scanning of Docker images stored in Container Registry
Scheduled scanning of Docker images is an automated process that checks containerized images for vulnerabilities and compliance with security standards. Such scans are regular and automatic to ensure the consistency of image checks for vulnerabilities and maintain a high security level in the long run. Reports on completed scans provide a brief description of detected vulnerabilities and issues and help you set priorities and eliminate security risks in containerized applications.
We recommend setting up a schedule for scans to be run at least once a week.
- In the management console
, select the folder that 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.
9.4 Containerized images used in production environments have the last scan date a week ago or less
Checking Docker images used in production environments with the last scan date not older than a week ensures that you continuously monitor and update security measures, eliminating potential vulnerabilities that might have occurred since the last scan. This also helps you make sure you are not deploying containers with recently detected vulnerabilities and enhance the security level. You can automate this process by setting up a schedule in the Vulnerability scanner.
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
9.5 Software artifacts are built using attestations
Attestations are used when building software artifacts to ensure a secure and verifiable record of an artifact's origin, integrity, and SBOM compliance. This helps ensure the artifact reliability throughout its lifecycle. A software bill of materials (SBOM) is required to secure a supply chain, manage vulnerabilities, comply with requirements, assess risks, ensure transparency, and respond to incidents in an effective way.
With Managed Service for GitLab, attestations are easier to use, as the service has a feature for generating a provenance attestation
Make sure that artifact attestation is performed while building an application.
Guides and solutions to use:
Gitlab guide for software artifact attestation
9.6 Ensuring 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:
You can sign artifacts within a pipeline using Cosign
9.7 Artifacts are verified on deployment
To ensure the reliability, security, and compatibility of applications in Managed Service for Kubernetes, a service for automatic scaling and deployment of applications, you need to minimize the risk of issues, vulnerabilities, and failures during your application deployment and runtime. To do this, use signatures and signature verification in Managed Service for Kubernetes with Cosign and Kyverno.
Make sure that artifacts are verified while building an application.
Guides and solutions to use:
Guide on setting up the artifact signature.
9.8 Protected templates of a secure pipeline are used
When working with Managed Service for GitLab, make sure you use built-in GitLab security mechanisms to secure your pipeline. The following options of pipeline usage are available for your projects:
- Creating a pipeline in an individual project and connecting it to other projects using the
include
function . Available for all license types. - Using the
Compliance framework and pipeline
mechanism that you can run in any group project. Available for theUltimate
license. - Copying pipeline sections to
.gitlab-ci.yml
files in your projects.
ClickHouse® is a registered trademark of ClickHouse, Inc