CSPM — Cloud Security Posture ManagementCSPM — Cloud Security Posture Management

Rules for checking cloud resource configuration.

Two-factor authentication is set up for all local usersTwo-factor authentication is set up for all local users

kind	severity	ID
automatic	high	access.userpool-mfa

DescriptionDescription

How the rule works: It checks whether two-factor authentication (2FA) is enabled for the user pool or organization.

Risks when not complying with the rule:

• Compromising the password entails granting full access to the cloud. * Risks of leaks and data loss: confidential data theft, data encryption with the aim of extortion, etc. * Risks for the infrastructure: irreversible deletion of VM instances and disks, changes in DNS records to reroute traffic, etc. * Identity and Access Management risks and service account risks: creating new users with admin privileges, stealing API keys and service accounts, getting long-term backdoor access.

Instructions and solutionsInstructions and solutions

Set up two-factor authentication for all local users in Yandex Identity Hub.

Two-factor authentication boosts protection for user accounts by employing not only the password during authentication but also another factor on top of that: one-time code (in an authenticator app under the TOTP standard or in an SMS message) or means of authentication as per WebAuthn (FIDO2)).

Multi-factor authentication requirements enforced on users are specified in MFA policies:

• Create an MFA policy in the Yandex Identity Hub UI in Cloud Center. * Add all users of the pool to the target groups of this policy.

Service account keys are rotated on a regular basisService account keys are rotated on a regular basis

kind	severity	ID
automatic	high	iam.sa-key-rotation

DescriptionDescription

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

• IAM tokens that are valid for 12 hours. * API keys: You can choose any validity period. * Authorized keys with unlimited validity. * AWS API-compatible static access keys with unlimited validity.

It is recommended 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.

This control checks the last update and usage date. In cases where it is impossible to determine the last update date (for example, when starting CSPM for the first time), it is recommended that the control is performed manually.

Instructions and solutionsInstructions and solutions

Follow the guide for rotating keys depending on their type.

The period since the service account was last used does not exceed 90 daysThe period since the service account was last used does not exceed 90 days

kind	severity	ID
automatic	medium	iam.unused-service-account

DescriptionDescription

How the rule works: The rule tracks the date of the service account's last authentication date and outputs accounts that were last authenticated more than 90 days ago.

Risks when not complying with the rule:

• Unauthorized use of a service account.
• Accumulation of unused service account keys with indefinite validity.
• No database for investigating incidents.
• Violation of the principle of least privilege for unactive accounts.

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 on behalf of an application.

It is crucial to track the date of last authentication for service accounts. Not doing so means there is no way to detect unexpected use scenarios for service accounts: during off-hours, from an unusual access point, or after the application has been taken out of service.

Especially dangerous in this regard are service accounts with elevated privileges. An unused account with extensive rights is a ready-made attack vector when its key is compromised.

If a service account's key is compromised and there is no data on its last authentication date, no timeline can be drawn up for the incident, and there is no way to assess the scale of unauthorized access or identify affected resources. This directly increases mean time to repair (MTTR) and incident impact.

Instructions and solutionsInstructions and solutions

• Follow the principle of least privilege when assigning access permissions to service accounts.
• Regularly audit access permissions through Cloud Infrastructure Entitlement Management (CIEM) to detect unactive service accounts with excessive permissions.
• Keep service account keys in Yandex Lockbox rather than in code or environment variables.

The period since access keys were last used does not exceed 90 daysThe period since access keys were last used does not exceed 90 days

kind	severity	ID
automatic	medium	iam.unused-key

DescriptionDescription

How the rule works: The rule outputs access keys in Yandex Identity and Access Management that were last used more than 90 days ago.

Risks when not complying with the rule:

• Indefinite unauthorized access.
• No ways to detect a compromise without monitoring.
• Leaks through VM metadata.
• Expansion of privileges through the service account.

Static keys do not have a validity period. This makes them a complete outlier in terms of risk, since a static key in the hands of an attacker is valid indefinitely. If the key is not used or monitored, compromises may stay permanently hidden.

Yandex Cloud displays the date and time of the service account's last authentication and that of each key's last use. An unused key generates no activity, so its compromise and backdoor use by an attacker may stay undetected.

Static keys end up in the user-data field of the VM instance metadata. Unused keys left forgotten in metadata remain a possible attack vector.

If a service account is assigned to a VM instance, an attacker can get its token through the metadata service from within the instance. This account's static key, unused and unrotated, grants identical access without the attacker having to compromise the instance itself.

Instructions and solutionsInstructions and solutions

• Update static keys at least once every 90 days.
• Delete unused keys.
• Keep static keys in Yandex Lockbox secrets rather than in code, configuration files, or environment variables.
• Employ impersonation instead of static keys whenever possible, as it does not require generating long-living credentials.
• Whenever possible, use temporary tokens via Yandex Security Token Service (STS) instead of static keys. Unlike the latter, temporary tokens have a limited lifetime and access permissions. Access permissions and lifetime are set for each temporary key individually.

Yandex ID accounts are used only in exceptional casesYandex ID accounts are used only in exceptional cases

kind	severity	ID
automatic	medium	yid-organization

DescriptionDescription

How the rule works: The rule is considered violated if even one Yandex ID account has been found in the organization.

Risks when not complying with the rule:

• Yandex ID accounts cannot be subject to any security policies. These latter include revoking and suspending accounts, limiting the number of unsuccessful login attempts, password policies, etc. * No centralized access revocation is possible when an employee resigns. If an employee resigns, their Yandex ID account continues existing independently of the organization. * The session lifetime cannot be managed. A long-term session on a compromised workstation enables attackers to act on behalf of the user without re-authenticating. * The OAuth token can be leaked. The OAuth token of a Yandex ID account is valid for one year.

Federated accounts offer more security than Yandex ID accounts.

Using an identity federation is the best way to reduce risks related to unauthorized access.

• Corporate security policies (password policies, suspension, 2FA) apply in a centralized and enforced fashion. * The account lifecycle is managed in IdP, and an employee's resignation automatically ends their access to Yandex Cloud. * The session lifetime is limited at the organization level. * Privileged roles are assigned to accounts protected with corporate tools for monitoring and device management. * Audit and incident response are carried out in a unified corporate system, rather than scattered across employees' accounts.

Instructions and solutionsInstructions and solutions

Delete all Yandex ID accounts from your organization, apart from cases that qualify as allowed exceptions. For the remaining Yandex ID accounts, set up 2FA.

The following exceptions are allowed:

• Account with the billing.accounts.owner permissions (technically, only a Yandex ID account can have this role at the moment). * Account with the organization-manager.organizations.owner and resource-manager.clouds.owner permissions, if used in emergencies only, e.g., when the configuration of your federation fails. If you need to, you can delete a privileged Yandex account with the organization-manager.organizations.owner role from an organization. * External accounts, such as those of your contract partners or contractors, which, for whatever reason, you cannot register in your federation.

Only authorized administrators manage memberships in user groupsOnly authorized administrators manage memberships in user groups

kind	severity	ID
manual	high	access.user-groups-access

DescriptionDescription

Working in the cloud requires following the principle of least privilege and granting users no more permissions than they need to address their respective tasks.

Make sure to manage access permissions to a user group as a resource. Failing to do so may result in users getting excess permissions allowing them to manage the membership of other users in the group.

This check detects cases where users get such permissions:

• User has the organization-manager.groups.memberAdmin role for the organization. * User has the organization-manager.groups.memberAdmin role for a specific group as a resource. * User has the organization-manager.organizations.owner or admin role or another privileged role for the whole organization. * User has the admin or editor role for a specific group as a resource (this is not recommended).

Instructions and solutionsInstructions and solutions

Guides and solutions to use:

1. In the left-hand panel of the Cloud Center interface, select Groups and in the list that opens, click the line with the group in question. 2. Navigate to the Group access rights tab and enable the Inherited roles option. 3. Follow the instructions for revoking a role for an organization or user group to take away permissions from unauthorized accounts.

Service accounts have minimum privileges granted on the organization levelService accounts have minimum privileges granted on the organization level

kind	severity	ID
automatic	information	access.sa-privileges-org-roles

DescriptionDescription

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

This rule detects service accounts with the following roles within the organization:

• admin * editor * resource-manager.clouds.owner

Instructions and solutionsInstructions and solutions

• Use Security Deck to revoke the service account's excessive access permissions. * Revoke the excessive permissions from the service account using IAM.

Service accounts have minimum privileges granted on the service levelService accounts have minimum privileges granted on the service level

kind	severity	ID
automatic	information	access.sa-privileges-service-roles

DescriptionDescription

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

This rule detects service accounts with the following roles within the service:

• compute.admin * storage.admin * iam.serviceAccounts.admin * vpc.admin * k8s.admin * lockbox.admin * kms.admin

Instructions and solutionsInstructions and solutions

• Use Security Deck to revoke the service account's excessive access permissions. * Revoke the excessive permissions from the service account using IAM.

Only trusted administrators have privileged rolesOnly trusted administrators have privileged roles

kind	severity	ID
manual	medium	access.check-privileged-roles

DescriptionDescription

When creating your billing account, you get the billing.accounts.owner role automatically. Any user with the billing.accounts.owner role can remove this role from the billing account creator and change the owner. The role allows you to perform any action with the billing account.

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

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

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

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

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

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

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

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

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

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

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

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

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

Instructions and solutionsInstructions and solutions

Check access rights for the Yandex Cloud Billing service:

1. Go to Yandex Cloud Billing. 2. In the left-hand panel, select Access management. 3. Check which users have the billing.accounts.owner and admin roles.

Check access rights for an organization:

1. Go to Yandex Identity Hub 2. In the left-hand panel, select Access bindings. 3. Check which users have the admin, organization-manager.organizations.owner, organization-manager.admin, and resource-manager.clouds.owner roles.

Check access rights for a cloud or a folder:

1. In the management console, select the cloud or folder to check access permissions in. 2. Click the Access permissions tab. 3. Check which users have the admin, editor, resource-manager.clouds.owner, and resource-manager.clouds.editor roles.

Make sure all the privileged roles are granted to trusted administrators. If any roles granted to untrusted administrators are found, investigate why and remove the respective permissions.

Resource labels are usedResource labels are used

kind	severity	ID
manual	information	o11y.labeled-resources

DescriptionDescription

This rule checks labels on folder level and lists the folders missing the labels.

A label is a key-value pair in <label_name>=<label_value> format. You can use labels to break resources into logical groups and to monitor data streams and tag critical resources for privilege management.

Labels are crucial when it comes to structurizing and carrying out inventory of the infrastructure by attributes. This is especially important when there are many resources and they are dynamically created/deleted.

Instructions and solutionsInstructions and solutions

You can add, delete, or update resource labels in the management console, Yandex Cloud CLI, and Terraform. For more infromation, read the Managing labels guide.

Yandex Object Storage uses bucket policiesYandex Object Storage uses bucket policies

kind	severity	ID
manual	high	access.bucket-access-policy

DescriptionDescription

Bucket policies set permissions for actions with buckets, objects, and object groups. A policy applies 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.

Instructions and solutionsInstructions and solutions

1. In the management console, select the cloud or folder where resides the bucket which you want to check bucket policies for. 2. Go to Object Storage and select the bucket in question. 3. In the left-hand menu, select Security and go to the Access policy tab. 4. If at least one policy is enabled, the rule is considered satisfied. Otherwise, it is recommended to configure an access policy for the bucket.

Permissions to manage keys in KMS are granted to authorized usersPermissions to manage keys in KMS are granted to authorized users

kind	severity	ID
manual	medium	access.kms-keys-access

DescriptionDescription

To minimize the risk of compromising user account credentials, it is recommended to grant users and service accounts granular permissions for particular keys in Yandex Key Management Service. For more information, see Access management in Key Management Service.

This rule checks access permissions for KMS keys and returns all the users that are assigned either of the following roles:

• admin, editor, kms.admin, kms.editor, or kms.keys.encrypterDecrypter for organization, clouds, or folders. * kms.keys.encrypterDecrypter or kms.editor for KMS keys.

Instructions and solutionsInstructions and solutions

It is recommended to follow these principles when granting permissions for KMS keys:

• To access Yandex Key Management 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 Yandex Identity and Access Management 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.

Container images used in the production environment have the last scan date of one week ago or lessContainer images used in the production environment have the last scan date of one week ago or less

kind	severity	ID
manual	medium	appsec.registry-recently-scan

DescriptionDescription

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.

Instructions and solutionsInstructions and solutions

Set up automatically scheduled Docker images scanning for vulnerabilities

There is no access to Kubernetes APIThere is no access to Kubernetes API

kind	severity	ID
automatic	medium	k8s.api-security

DescriptionDescription

We do not recommend granting access to Kubernetes API from the internet. Use firewall protection where needed (for example, security groups).

Instructions and solutionsInstructions and solutions

It is recommended to use Kubernetes clusters that are not accessible from the internet. For guidance on creating such a cluster, see Creating and configuring a Kubernetes cluster with no internet access.

If a cluster must be accessible from the internet, configure it using these firewall options:

• Configure security groups for the cluster. * Use network policy configuration tools via the Calico (basic) or Cilium CNI (advanced) plugins in Yandex Cloud. Apply default deny rules for inbound and outbound traffic by default, permitting only necessary traffic. * For online endpoints, allocate an independent Kubernetes cluster or independent node groups (using such mechanisms as Taints and Tolerations + Node affinity). This creates a DMZ, limiting your attack surface so that if your nodes are compromised online, the impact is minimized. * Use an Ingress resource to enable incoming network access to your workloads via HTTP/HTTPS. There are at least two Ingress controller options that you can use in Yandex Cloud:

• NGINX Ingress Controller. * Yandex Application Load Balancer Ingress controller.

Managed Service for Kubernetes® uses secure configurationManaged Service for Kubernetes® uses secure configuration

kind	severity	ID
manual	medium	k8s.secure-configuration

DescriptionDescription

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

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

Instructions and solutionsInstructions and solutions

• Using the kube-bench tool, check whether the node group configuration is compliant with CIS Kubernetes Benchmark. The tool officially supports the Yandex Cloud node groups. * Starboard Operator is a free tool that helps you automate scanning of images for vulnerabilities and checking that the configuration is compliant with CIS Kubernetes Benchmark. Starboard Operator supports integration with kube-bench and is used for its automatic startup.

Separate service accounts are used for cluster and node groupSeparate service accounts are used for cluster and node group

kind	severity	ID
manual	high	k8s.access

DescriptionDescription

When creating a cluster in Managed Service for Kubernetes, specify two service accounts:

• Cluster service account: On behalf of this service account, Managed Service for Kubernetes manages cluster nodes, subnets for pods and services, disks, load balancers, encrypts and decrypts secrets. * Node group service account: Under this service account, Managed Service for Kubernetes cluster nodes get authenticated in Yandex Container Registry or Yandex Cloud Registry. For other container registries, you do not need to assign roles to the service account.

Instructions and solutionsInstructions and solutions

Make sure that the access of IAM accounts to Managed Service for Kubernetes resources is managed at the following levels:

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

Security events monitoring for a Yandex Managed Service for GitLab instance in progressSecurity events monitoring for a Yandex Managed Service for GitLab instance in progress

kind	severity	ID
automatic	medium	o11y.gitlab-audited

DescriptionDescription

The rule checks whether log collection is set up for a Yandex Managed Service for GitLab instance.

The core log collection tool is Yandex Audit Trails. It enables collecting audit logs about events occurring to Yandex Cloud resources and uploading these logs to an Object Storage bucket or a log group in Cloud Logging for further analysis or export.

Audit Trails events in Managed Service for GitLab are control plane events, which include creating, deleting, and modifying an instance, as well as execution events and more. For more information, see the Audit Trails reference.

Instructions and solutionsInstructions and solutions

Guides and solutions to use:

Set up log collection using Yandex Audit Trails:

1. Create a bucket with restricted access. 2. Assign the required roles to the service accounts. 3. Create a trail.

Audit Trails events in Managed Service for GitLab are control plane events, which include creating, deleting, and modifying an instance, as well as execution events and more. For more information, see the Audit Trails reference.

The Yandex Audit Trails service is operating properlyThe Yandex Audit Trails service is operating properly

kind	severity	ID
automatic	medium	o11y.audit-trails-no-errors

DescriptionDescription

The Yandex Audit Trails service check helps promptly detect audit log collection failures, which is essential for continuous security monitoring and compliance with audit requirements. Unavailability or malfunction of Audit Trails may lead to the loss of cloud operations data, reducing transparency and increasing the risk of undetected incidents.

This check returns the list of trails within the organization that are currently in the Error status.

Instructions and solutionsInstructions and solutions

If a trail enters the Error state, create a temporary trail with the same audit log collection scope and an appropriate destination object. This helps prevent interruptions in audit log collection and potential data loss. For more information, see Creating a trail to upload audit logs.

Once a new trail has been created, you can begin restoring the operation of the existing one that is in the Error state. You can do this independently or with assistance from our technical support team.

The Kubernetes security policy is in placeThe Kubernetes security policy is in place

kind	severity	ID
automatic	high	k8s.kspm

DescriptionDescription

Kubernetes Security Posture Management (KSPM) ensures the security of containerized applications and images they use.

The KSPM module automatically identifies all Kubernetes clusters and containers in the specified workspace, and deploys security components in them as defined in the configuration. New clusters automatically get security coverage, without requiring manual search or installation of any components.

The module continuously assesses workloads for misconfigurations and provides runtime security monitoring through sensors that detect attacks targeting nodes and containers.

The KSPM configuration is set when you create a workspace and may include checking clusters for compliance with the following standards:

• Kubernetes Pod Security Standards (Restricted): This standard contains security controls based on the Kubernetes Pod Security Standards (PSS) Restricted profile. A restricted profile is the most secure and provides the highest detection efficiency for container-based attacks. It applies strict security policies that may require modifying applications to ensure compliance. A restricted profile is recommended for security-critical applications and environments where maximum security is required.

• Kubernetes Pod Security Standards (Baseline): This standard contains security controls based on the Kubernetes Pod Security Standards (PSS) Baseline profile. A baseline profile is designed for easy implementation and provides common best practices for container security. It prevents the most common security issues in containers while maintaining compatibility with most applications. The baseline profile is a good starting point for organizations just getting started with container security.

• Microsoft Threat Matrix for Kubernetes: This standard contains security controls based on the Microsoft Threat Matrix for Kubernetes, which is a framework that helps security teams understand and fend off threats specific to Kubernetes environments. It provides a comprehensive approach to attack methods and defensive strategies tailored for container orchestration platforms.

• CIS Kubernetes Benchmark: This standard includes recommendations from the CIS Kubernetes Benchmark for secure configuration of Kubernetes worker node components. Only automatic checks from section 4 Worker Nodes are included.

Instructions and solutionsInstructions and solutions

Use the KSPM module to protect Kubernetes clusters and containers in your workspace:

1. Create a service account KSPM will use to view Managed Service for Kubernetes cluster info, install the necessary components, and perform checks. 2. Assign to the service account the security-deck.worker role for the organization, cloud, or folder. 3. Create a Security Deck workspace, specify the clouds and folders you want to control the security of clusters in, and select the industry standards and regulations the resources you have chosen will be benchmarked against. 4. On the new workspace page, click Workspace Parameters and navigate to the KSPM tab. 5. Under Scope of control, select the clouds, folders, or clusters within the workspace resources where compliance with the Kubernetes security rules will be enforced. 6. Click Save and confirm the action.

For more information, see Activating KSPM.

User group mapping is configured in an identity federationUser group mapping is configured in an identity federation

kind	severity	ID
automatic	low	access.user-groups-mapping

DescriptionDescription

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

If you have created user groups in your identity provider or plan to do so, you can map user groups between the IdP and Yandex Identity Hub. Users in the identity provider's groups will be granted the same access permissions for Yandex Cloud resources as their respective groups in Identity Hub.

Instructions and solutionsInstructions and solutions

Configure group mapping between your identity provider and Yandex Identity Hub.

Only trusted administrators have access to service accountsOnly trusted administrators have access to service accounts

kind	severity	ID
manual	information	access.privileged-sa-access

DescriptionDescription

You can grant a user or another service account permission to use a service account.

Follow the principle of least privilege when granting access for a service account as a resource. A user with permission to use a service account also inherits all permissions assigned to that service account. Assign roles that allow the use and management of service accounts only to a minimal number of trusted users.

Each service account with extended permissions should be placed as a resource in a separate folder. This helps prevent accidentally granting permissions for a service account along with the permissions for the folder with the respective service component.

Instructions and solutionsInstructions and solutions

Validate the access rights assigned for service accounts. The recommendation is considered satisfied if the list contains only trusted administrators. Otherwise, follow this guide to revoke any excessive permissions using the Identity and Access Management service.

To manage access centrally, use the CIEM module. Refer to the guides below for instructions:

• Viewing a list of a subject's accesses * Revoking a subject's access

ACL by IP address is set up for Yandex Container RegistryACL by IP address is set up for Yandex Container Registry

kind	severity	ID
automatic	medium	access.acl-container-registry

DescriptionDescription

It is recommended that you limit access to your Container Registry to specific IPs.

1. In the management console, select the cloud or folder to check the registry in. 2. In the list of services, select Container Registry. 3. In the settings of the specific registry, go to the Access for IP address tab. 4. If specific IPs to allow access for are set in the parameters, the recommendation is fulfilled. Otherwise, proceed to "Guides and solutions to use".

Instructions and solutionsInstructions and solutions

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

No public access to the Object Storage bucketNo public access to the Object Storage bucket

kind	severity	ID
manual	medium	access.bucket-public-access

DescriptionDescription

It is recommended to assign minimum roles for a bucket using IAM and supplementing or itemizing them using a bucket policy (for example, to restrict access to the bucket by IP, grant granular permissions for objects, and so on).

Access to Object Storage resources is verified at three levels:

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

Verification procedure:

1. If a request passes the IAM check, the next step is the bucket policy check. 2. Bucket policy rules are checked in the following order: 1. If the request meets at least one of the Deny rules, access is denied. 2. If the request meets at least one of the Allow rules, access will be allowed. 3. If the request does not meet any of the rules, access will be denied. 3. If the request fails the IAM or bucket policy check, access verification is performed based on an object's ACL.

In IAM, a bucket inherits the same access permissions as those of the folder and cloud where it is located. For more information, see Inheritance of bucket access permissions by Yandex Cloud public groups. Therefore, we recommend that you only assign the minimum required roles to certain buckets or objects in Object Storage.

Bucket policies are used for additional data protection, for example, to restrict access to a bucket by IP, issue granular permissions to objects, and so on.

With ACLs, you can grant access to an object bypassing IAM verification and bucket policies. We recommend setting strict ACLs for buckets.

Example of a secure Object Storage configuration: Terraform

Instructions and solutionsInstructions and solutions

It is recommended to assign 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).

If public access is required, it is recommended to use DSPM to monitor the presence of sensitive data in buckets.

Access from the management console is disabled in managed databasesAccess from the management console is disabled in managed databases

kind	severity	ID
automatic	low	access.db-console-access

DescriptionDescription

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.

Instructions and solutionsInstructions and solutions

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

The setting for access from DataLens is not active if not neededThe setting for access from DataLens is not active if not needed

kind	severity	ID
automatic	low	access.db-datalens-access

DescriptionDescription

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.

Instructions and solutionsInstructions and solutions

Instructions and solutions for implementation:

1. In the management console, select the cloud or folder where you want to disable access from DataLens. 2. In the list of services, select the service(s) where the managed databases are located. 3. In the object settings, go to the Additional settings tab. 4. In the object's parameters, disable the Access from DataLens option.

The minimum required scopes for service account API keys are definedThe minimum required scopes for service account API keys are defined

kind	severity	ID
automatic	medium	access.defined-key-scopes

DescriptionDescription

This rule detects API keys without specified scopes.

A scope is the total of the actions a service account is allowed to perform with the service's resources. A service can have more than one scope. You cannot use an API key with specified scopes in other services or scopes.

In addition to service account access permissions, you can define scopes to restrict the use of API keys. Configuring scope limits and expiration dates will reduce the risk of unauthorized use of your keys. Assign only the strictly required scopes to API keys.

more details: https://yandex.cloud/en/docs/security/standard/authentication#api-key-scopes

Instructions and solutionsInstructions and solutions

Create an API key with a specified scope.

An identity federation (Single Sign-On, SSO) is configuredAn identity federation (Single Sign-On, SSO) is configured

kind	severity	ID
automatic	information	access.idp

DescriptionDescription

Yandex Cloud provides two options for centralized identity management:

• Identity federation (external IdP) for single sign-on (SSO) access to applications. With SSO, users can access multiple applications without having to enter their username and password every time.

If your company has a user and access management system (e.g., Active Directory or Google Workspace), you can use it to authenticate employees in Yandex Identity Hub. In which case you do not need to create a new Yandex account for every employee. They can get access to Yandex Cloud services using their corporate accounts.

• User pools for linking your domains and managing access permissions, authentication settings, and My account data you can edit.

Pools and users in pools exist only at the organization level and are subject to Yandex Cloud security policies.

Instructions and solutionsInstructions and solutions

For centralized identity management, use SAML-compatible identity federations or user pools.

With identity federations, you can set up single sign-on authentication in Yandex Cloud via your own IdP server. This way, your employees can use their corporate accounts that are subject to the company security policies.

For more information, see Identity federations.

User pools group local users together, thus allowing you to manage them centrally, link your domains, manage access permissions, authentication settings, and My account data you can edit.

Learn more about creating user pools here.

Service roles are used instead of primitive roles: admin, editor, viewerService roles are used instead of primitive roles: admin, editor, viewer

kind	severity	ID
manual	medium	access.min-privileges

DescriptionDescription

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

Use the auditor role without data access wherever possible.

Instructions and solutionsInstructions and solutions

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.

Follow this guide to view the full list of a subject's access permissions.

OS Login is used for connection to a VMOS Login is used for connection to a VM

kind	severity	ID
automatic	low	access.os-login-onto-hosts.vm

DescriptionDescription

OS Login is a convenient way to manage connections to VMs over SSH via the CLI or a standard SSH client with an SSH certificate or SSH key, which you first need to add to the OS Login profile of organization user or service account in Yandex Identity Hub.

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

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

Instructions and solutionsInstructions and solutions

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

There is no public access to your organization's resourcesThere is no public access to your organization's resources

kind	severity	ID
manual	high	access.public-access

DescriptionDescription

This rule checks if there is a public access granted to All authenticated users and All users within an organization, cloud or folder.

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

Public group details:

• All authenticated users: All authenticated users. This means all registered Yandex Cloud users or service accounts, both from your clouds and other users' clouds.

• All users: Any user. No authentication is required.

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

Instructions and solutionsInstructions and solutions

If you detect that All users and All authenticated users have the access permissions that they should not have, remove these permissions using CIEM module.

Service accounts have minimum privileges grantedService accounts have minimum privileges granted

kind	severity	ID
manual	high	access.sa-privileges

DescriptionDescription

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

Instructions and solutionsInstructions and solutions

• Use Yandex Security Deck to view the full list of a service account's access permissions. * Use Security Deck to revoke the service account's excessive access permissions. * Remove the excessive permissions from the service account using IAM.

The serial console is either controlled or not usedThe serial console is either controlled or not used

kind	severity	ID
automatic	medium	access.serial-console

DescriptionDescription

On VMs, access to the serial console is disabled by default. For risks of using the serial console, see Getting started with a serial console in the Yandex Compute Cloud documentation.

When working with a serial console:

• Make sure that critical data is not output to the serial console. * If SSH access to the serial console is enabled, make sure that both the credentials management routine and the password used to log in to the operating system locally are as per the regulatory standards. For example, in an infrastructure for storing payment card data, passwords must meet the PCI DSS requirements: they must contain both letters and numbers, be at least 7 characters long, and be changed at least every 90 days.

It is not recommended to use access to the serial console unless it is absolutely necessary.

Evaluate the risk of enabling access through the serial console, considering the following factors:

• The VM will be accessible for management from the internet even if there is no external IP address. * A user successfully authenticated in the Yandex Cloud management console with appropriate VM permissions will be able to access the VM's serial console from the Yandex Cloud management console. Access to the VM's serial console from an SSH client (e.g., Putty) or CLI is also possible by authenticating via an SSH key. Therefore, it is necessary to carefully control the SSH key and terminate the web session to reduce the risks of its interception. * The session will be available simultaneously to all users who have the right to access the serial console. * Actions of one user will be visible to other users if they are viewing the serial console output at the same time. * An unfinished session can be used by another user.

We recommend enabling the serial console only in case of extreme necessity, granting such access to a narrow circle of people, and using strong passwords to access the VM.

Make sure to disable access to the serial console after you have finished working with it.

Instructions and solutionsInstructions and solutions

It is recommended to disable access to the serial console

Yandex Application Load Balancer uses HTTPSYandex Application Load Balancer uses HTTPS

kind	severity	ID
automatic	high	appsec.alb-https

DescriptionDescription

Application Load Balancer supports an HTTPS listener with a certificate uploaded from Certificate Manager. See listener setup description in the Yandex Application Load Balancer documentation.

Instructions and solutionsInstructions and solutions

Enable an HTTPS listener using this guide.

API gateways use HTTPS and their own domainsAPI gateways use HTTPS and their own domains

kind	severity	ID
automatic	medium	appsec.api-gateway-https

DescriptionDescription

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

Without using HTTPS, traffic between the client and API gateway is transmitted unencrypted, running the following risks:

• Hackers intercepting data via, for example, MITM (man-in-the-middle) attacks. * Leaks of confidential information, such as personal data, payment data, authorization tokens, passwords, etc.

Instructions and solutionsInstructions and solutions

Guides and solutions to use:

1. In the management console, select the folder the API gateway is in. 2. Go to API Gateway and in the window that opens, click the line with the API gateway in question. 3. In the left-hand menu, select Domains and click Attach. 4. In the window that opens, select a TLS certificate and specify the domain name matching this certificate. 5. Click Attach.

Yandex Cloud CDN uses HTTPS and its own SSL certificateYandex Cloud CDN uses HTTPS and its own SSL certificate

kind	severity	ID
automatic	low	appsec.cdn-https

DescriptionDescription

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

Instructions and solutionsInstructions and solutions

Enable a certificate and HTTPS using the instructions.

Application DDoS protection is enabled (L7)Application DDoS protection is enabled (L7)

kind	severity	ID
automatic	high	appsec.ddos-protection.l7

DescriptionDescription

Yandex Cloud provides basic and advanced DDoS protection as well as protection at the application level with Yandex Smart Web Security. Make sure to use at least basic protection.

• Yandex Smart Web Security is a service for protection against DDoS attacks and bots at application level L7 of the OSI model. Smart Web Security connects to Yandex Application Load Balancer. In a nutshell, the service checks the HTTP requests sent to the protected resource against the rules configured in the security profile. Depending on the results of the check, the requests are forwarded to the protected resource, blocked, or sent to Yandex SmartCaptcha for additional verification. * Yandex DDoS Protection is a Virtual Private Cloud component that safeguards cloud resources from DDoS attacks. DDoS Protection is provided in partnership with Curator. You can enable it yourself for an external IP address through cloud administration tools. Supported up to OSI L4. * Advanced DDoS protection is available at OSI layers 3, 4, and 7. You can also track load and attack metrics and enable Solidwall WAF in your Curator account. To enable advanced protection, contact your manager or technical support.

Instructions and solutionsInstructions and solutions

• How to create a security profile in Smart Web Security

Network DDoS protection is enabled (L3)Network DDoS protection is enabled (L3)

kind	severity	ID
automatic	high	appsec.ddos-protection.l3

DescriptionDescription

Yandex Cloud provides basic and advanced DDoS protection. Make sure to use at least basic protection.

Yandex DDoS Protection is a VPC component that safeguards cloud resources from DDoS attacks. DDoS Protection is provided in partnership with Qrator Labs. Supported up to OSI L4.

Activating Yandex DDoS Protection for VM instances or network load balancers allows you to efficiently respond to attacks aiming to overwhelm the channel capacity and computing resources of your VM instances.

To prevent such attacks, DDoS Protection:

• Constantly analyzes all incoming traffic. * Detects the above issues in the network and transport layers. * Automatically diverts unwanted traffic when its intensity threatens the health of your service in Yandex Cloud.

Advanced DDoS protection is available at OSI layers 3, 4, and 7. You can also track load and attack metrics and enable Solidwall WAF in your Curator account.

Instructions and solutionsInstructions and solutions

Use Yandex DDoS Protection to protect your cloud resources against DDoS attacks on basic level. You can enable DDoS Protection with a single click: just select the DDoS protection checkbox when creating your VM and reserving public IP addresses.

Enable and set up advanced DDoS protection at OSI layers 3, 4, and 7. To enable advanced protection, contact support or fill out this form.

When creating a registry in Yandex Container Registry, keep the safe registry settings by defaultWhen creating a registry in Yandex Container Registry, keep the safe registry settings by default

kind	severity	ID
automatic	medium	appsec.periodic-scan

DescriptionDescription

When creating a new registry, use the default options to make sure it meets the Yandex Cloud security standard:

• Docker images are automatically scanned as they are uploaded to the registry. * Docker images in the registry are regularly re-scanned, i.e., every 7 days with an option to switch to daily scanning in the settings.

Instructions and solutionsInstructions and solutions

1. In the management console, select the folder where you want to create a registry. 2. In the list of services, select Container Registry. 3. Click Create registry. 4. In the Name field, enter a name for the registry. The naming requirements are as follows:

• It must be from 2 to 63 characters long. * It can only contain lowercase Latin letters, numbers, and hyphens. * It must start with a letter and cannot end with a hyphen. 5. Under Automatic scanning:

• Keep Scan Docker images on push enabled to scan Docker images at their upload to the repository. * Keep Scan all Docker images in the registry enabled. Adjust the scanning frequency if you need to. 6. Click Create registry.

Advanced Rate Limiter is implementedAdvanced Rate Limiter is implemented

kind	severity	ID
automatic	medium	appsec.use-arl

DescriptionDescription

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

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

Instructions and solutionsInstructions and solutions

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

Yandex SmartCaptcha is usedYandex SmartCaptcha is used

kind	severity	ID
automatic	low	appsec.use-smartcaptcha

DescriptionDescription

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.

Instructions and solutionsInstructions and solutions

Yandex SmartCaptcha service

Yandex Smart Web Security profile is usedYandex Smart Web Security profile is used

kind	severity	ID
automatic	high	appsec.use-sws

DescriptionDescription

Yandex Smart Web Security protects you against DDoS attacks, web attacks, and bots at application level L7 of the OSI model. Smart Web Security connects to Yandex Application Load Balancer.

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

Instructions and solutionsInstructions and solutions

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

Web Application Firewall is implementedWeb Application Firewall is implemented

kind	severity	ID
automatic	medium	appsec.use-waf

DescriptionDescription

To mitigate risks associated with web attacks, we recommend using the Yandex Smart Web Security web application firewall (WAF). A web application firewall analyzes HTTP requests to a web app according to pre-configured rules. Based on the analysis results, certain actions are applied to HTTP requests.

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

Instructions and solutionsInstructions and solutions

Create a WAF profile and connect it to a security profile in Smart Web Security. It is recommended to configure and test your security profile Basic and Smart Protection rules beforehand.

1. Create a WAF profile. 2. Configure a WAF rule set. 3. Add an exclusion rule to the WAF profile. 4. Attach the WAF profile to your security profile.

When creating a registry in Yandex Container Registry, keep the safe registry settings by defaultWhen creating a registry in Yandex Container Registry, keep the safe registry settings by default

kind	severity	ID
manual	medium	appsec.secure-registry

DescriptionDescription

The lack of control over new Docker images leads to risks associated with the following factors:

• use of vulnerable containers; * introduction of malicious code; * slower response to threats.

Automatic vulnerability scanning when new images are added to the Container Registry will help reduce these risks.

Instructions and solutionsInstructions and solutions

1. In the management console, select the folder where you want to create a registry. 2. Go to Container Registry. 3. Click Create registry. 4. Specify a name for the registry. Follow these naming requirements:

• Length: between 3 and 63 characters. * It can only contain lowercase Latin letters, numbers, and hyphens. * It must start with a letter and cannot end with a hyphen. 5. Under Automatic scanning:

• Keep the Scan Docker images on push option enabled to scan Docker images at their upload to the repository. * Keep the Scan all Docker images in the registry option enabled, and set scanning frequency if necessary. 6. Click Create registry.

Getting an IAM token through the metadata service in AWS IMDSv1 format is disabled on the VMGetting an IAM token through the metadata service in AWS IMDSv1 format is disabled on the VM

kind	severity	ID
automatic	high	aws-token

DescriptionDescription

Yandex Compute Cloud features a metadata service for VM instances that provides info on their operation 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 the risk of a service account token getting compromised through the metadata service by means of a server-side request forgery (SSRF) attack. For more information, see the official AWS blog.

Instructions and solutionsInstructions and solutions

To get a service account's IAM token from within the VM, we recommend using metadata in Google Compute Engine format.

Make sure to disable getting an IAM token through the metadata service in IMDSv1 format.

Guides and solutions to use:

For the VMs found in the metadata_options section, set aws_v1_http_token to DISABLED:

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

Cloud Backup or scheduled snapshots are usedCloud Backup or scheduled snapshots are used

kind	severity	ID
automatic	high	backup.compute-disks

DescriptionDescription

This rule lists virtual machines which do not have configured back up policy.

It is important to configure back ups since it is the only practical way to restore VM's operation after a data loss or a data corruption. Without back ups, any incident leads to non-recoverable loss and operational downtime.

In cloud, there are two options to back up VMs:

• Scheduled snapshots * Cloud Backup

Instructions and solutionsInstructions and solutions

Backups in Compute Cloud includes snapshots of disks connected to VMs and Yandex Cloud Backup usage.

Cloud Backup is a service for creating backups and restoring Yandex Cloud resources and their data.

You can connect to Cloud Backup either a new Yandex Compute Cloud VM as soon as its is created or an existing VM with active and configured apps, resources, data, etc.

For Cloud Backup to be able to back up and restore a VM, the VM must be associated with a backup policy.

The Yandex Certificate Manager certificate is valid for at least 30 daysThe Yandex Certificate Manager certificate is valid for at least 30 days

kind	severity	ID
automatic	medium	crypto.certificate-validity

DescriptionDescription

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.

Instructions and solutionsInstructions and solutions

Update the certificate or setup auto updates.

We recommend that you update certificates in advance if they are not updated automatically.

Deletion protection is enabled for KMS keysDeletion protection is enabled for KMS keys

kind	severity	ID
automatic	high	crypto.keys-deletion-protection

DescriptionDescription

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

Instructions and solutionsInstructions and solutions

Enable deletion protection.

The Key Management Service keys are stored in the hardware Security module (HSM)The Key Management Service keys are stored in the hardware Security module (HSM)

kind	severity	ID
manual	medium	crypto.keys-hsm

DescriptionDescription

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 HSM as the algorithm type. The HSM will handle all operations with this key internally, and no additional actions are required.

It is recommended to use HSMs for KMS keys to enhance the security level.

Instructions and solutionsInstructions and solutions

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

Key rotation is enabled for KMS keysKey rotation is enabled for KMS keys

kind	severity	ID
automatic	high	crypto.keys-rotation

DescriptionDescription

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

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

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

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

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

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

Instructions and solutionsInstructions and solutions

Set the key rotation period.

Encryption of disks and virtual machine snapshots is usedEncryption of disks and virtual machine snapshots is used

kind	severity	ID
automatic	medium	crypto.managed-vm-kms

DescriptionDescription

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

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

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

You can encrypt the following types of disks:

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

Instructions and solutionsInstructions and solutions

Encrypt the disk of your Yandex Compute Cloud VM.

The organization uses Yandex Lockbox for secure secret storageThe organization uses Yandex Lockbox for secure secret storage

kind	severity	ID
automatic	low	crypto.secrets-lockbox

DescriptionDescription

Critical data and access secrets (authentication tokens, API keys, and encryption keys, etc.) should not be used in plain text in code, cloud object names and descriptions, VM metadata, etc. Use secret storage services instead, e.g., Lockbox.

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

Instructions and solutionsInstructions and solutions

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

Lockbox secrets are used for Serverless Containers and Cloud FunctionsLockbox secrets are used for Serverless Containers and Cloud Functions

kind	severity	ID
automatic	medium	crypto.secrets-serverless

DescriptionDescription

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.

Instructions and solutionsInstructions and solutions

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

• Transmitting Yandex Lockbox secrets to a container. * Transmitting Yandex Lockbox secrets to a function.

At-rest encryption with a KMS key is enabled in Yandex Object StorageAt-rest encryption with a KMS key is enabled in Yandex Object Storage

kind	severity	ID
automatic	medium	data.object-storage-encryption

DescriptionDescription

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.

Instructions and solutionsInstructions and solutions

It is recommended to enable data encryption for buckets with critical data.

HTTPS for static website hosting is enabled in Yandex Object StorageHTTPS for static website hosting is enabled in Yandex Object Storage

kind	severity	ID
automatic	high	data.storage-https

DescriptionDescription

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

• Configuring HTTPS * Bucket

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

Instructions and solutionsInstructions and solutions

Enable access over HTTPS if the bucket is used to host a static website.

Deletion protection is enabledDeletion protection is enabled

kind	severity	ID
automatic	low	db.db-deletion-protection

DescriptionDescription

In Yandex Cloud managed databases, you can enable deletion protection. The deletion protection feature safeguards the cluster against accidental deletion by a user. Even with cluster deletion protection enabled, one can still connect to the cluster manually and delete the data.

Instructions and solutionsInstructions and solutions

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

The cookie lifetime timeout in the federation is less than 6 hoursThe cookie lifetime timeout in the federation is less than 6 hours

kind	severity	ID
manual	high	cookie-timeout.organization

DescriptionDescription

Limiting the validity period of cookies is a key security measure for web applications, as it significantly reduces the risks associated with the compromise of user sessions. A short timeout minimizes the potential damage in the event of cookie theft (e.g., through XSS or MITM attacks) and limits the time during which an attacker can use the intercepted data.

In addition, automatic session termination after a predetermined period (e.g., 6 hours) prevents unauthorized access if a user forgets to log out of their account on a foreign device or if their device has been compromised.

Instructions and solutionsInstructions and solutions

In your identity federation settings make sure the Cookie lifetime value is less or equal to 6 hours. This would help minimize the risk of compromising cloud users' workstations.

Set the Cookie lifetime to 6 hours (21,600 seconds) or less.

Access to Kubernetes components is limited by IP address, port, and protocolAccess to Kubernetes components is limited by IP address, port, and protocol

kind	severity	ID
automatic	medium	k8s.network-firewall-scope

DescriptionDescription

We recommend using security groups to configure safe access to Kubernetes cluster components under the principle of least privilege. To establish access to cluster components, only open the required ports over the required network protocols, and only for trusted IP addresses.

Instructions and solutionsInstructions and solutions

Create a security group and configure it for working in a Kubernetes cluster.

In your configuration, follow the key principles that apply to security group settings for Kubernetes clusters:

• Do not use security rules with broad access rules:

• Port range: 0-65535. * Protocol: Any. * Source: CIDR. * CIDR blocks: IPv4 0.0.0.0/0 or IPv6 ::/0 (access allowed from any address). * Create dedicated security groups for:

• Kubernetes masters * Kubernetes nodes * Load balancers and ingress controllers * Databases and backends * Bastion hosts * In your security rules, use links to other security groups instead of resource IP addresses (in the Source/Target field, select Security groups instead of CIDR). This enables maintaining network access when editing resource IP addresses. * Limit egress traffic. We recommend that you clearly indicate ranges of IP addresses and ports as well as target protocols in the security rules for outgoing traffic. * Enable logging for Kubernetes clusters. * Enable Flow Logs Kubernetes to monitor traffic.

Audit log collection is set up for incident investigationAudit log collection is set up for incident investigation

kind	severity	ID
manual	high	k8s.network-policy

DescriptionDescription

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

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

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

Instructions and solutionsInstructions and solutions

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

You can also use:

• KubiScan * Krane * Yandex Audit Trails audit logs

No public IP address is assigned in managed databasesNo public IP address is assigned in managed databases

kind	severity	ID
automatic	medium	network.db-ip

DescriptionDescription

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.

Instructions and solutionsInstructions and solutions

It is recommended to delete the IP address linked to the database

A security group is assigned in managed databasesA security group is assigned in managed databases

kind	severity	ID
automatic	high	network.db-security-group

DescriptionDescription

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

Instructions and solutionsInstructions and solutions

It is recommended to set up a security group for the database cluster

Cloud resources are protected by a firewall or security groupsCloud resources are protected by a firewall or security groups

kind	severity	ID
automatic	high	network.firewall

DescriptionDescription

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

You can use security groups to protect:

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

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

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

Make sure that your clouds use any of the following:

• Security groups in each cloud object. * A separate NGFW VM from Cloud Marketplace. * BYOI principle, e.g., your own disk image.

Instructions and solutionsInstructions and solutions

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

Security groups have no access rule that is too broadSecurity groups have no access rule that is too broad

kind	severity	ID
automatic	medium	network.network-firewall-scope

DescriptionDescription

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

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

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

Instructions and solutionsInstructions and solutions

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

In Virtual Private Cloud, a security group is created; the default security group is not usedIn Virtual Private Cloud, a security group is created; the default security group is not used

kind	severity	ID
automatic	medium	network.network-firewall

DescriptionDescription

A security group (SG) is a resource created at the cloud network level. Once created, a security group can be used in Yandex Cloud services to control network access to an object it applies to.

A default security group (DSG) is created automatically while creating a new cloud network. The default security group has the following properties:

• It will allow any network traffic, both egress and ingress, in the new cloud network. * It applies to traffic passing through all subnets in the network where the DSG is created. * It is only used if no security group is explicitly assigned to the object yet. * You cannot delete the DSG: it is deleted automatically when deleting the network.

The default security group is a convenient but insecure mechanism that automatically allows all network traffic (incoming and outgoing) for your network objects. While simplifying the initial setup, such openness creates significant risks:

• Attackers can get access to resources through public interfaces. * Uncontrolled traffic makes your network more vulnerable to DDoS attacks and port scanning. * The DSG remains active until you assign another security group to the object.

We recommend you to create a security group of your own with rules explicitly allowing only the traffic you need (e.g., HTTP/HTTPS for web servers or SSH for administration) and assign this group to your cloud objects (VMs, Kubernetes clusters, etc.) to override the DSG.

This is important because without your rules cloud resources remain open to all and any connections from the internet, whereas security groups of your own enable the principle of least privilege, thus reducing the attack surface.

You can combine security groups by assigning up to five groups per object for more flexible access control.

Instructions and solutionsInstructions and solutions

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

Serverless Containers/Cloud Functions uses the VPC internal networkServerless Containers/Cloud Functions uses the VPC internal network

kind	severity	ID
manual	information	network.serverless-uses-vpc

DescriptionDescription

By default, the function is launched in an isolated IPv4 network with NAT gateway enabled. For this reason, only public IPv4 addresses are available. You cannot fix the address.

Networking between two functions, as well as between functions and user resources, is limited:

• Incoming connections are not supported. For example, you cannot access the internal components of a function over the network, even if you know the IP address of its instance. * Outgoing connections are supported via TCP, UDP, and ICMP. For example, a function can access a Yandex Compute Cloud VM or a Yandex Managed Service for YDB DB on the user's network. * Functions are cross-zoned: you cannot explicitly specify a subnet or select an availability zone to run a function.

If necessary, you can specify a cloud network in the function settings. In such case:

• The function will be executed in the specified cloud network. * While being executed, the function will get an IP address in the relevant subnet and access to all the network resources. * The function will have access not only to the internet but also to user resources located in the specified network, such as databases, virtual machines, etc. * The function will have an IP address within the 198.19.0.0/16 range when accessing user resources. * You can only specify a single network for functions, containers, and API gateways that reside in the same cloud.

Instructions and solutionsInstructions and solutions

1. In the management console, select the cloud or folder to check functions in. 2. Go to Cloud Functions. 3. Open the function. 4. In the object settings, go to the Edit function version tab. 5. In the Network field, select the cloud network you need. 6. Click Save changes.

No public access to managed YDBNo public access to managed YDB

kind	severity	ID
automatic	low	network.ydb-public

DescriptionDescription

When accessing the database in dedicated mode, we recommend that you use it inside VPC and disable 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.

Instructions and solutionsInstructions and solutions

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.

Yandex Audit Trails is enabled at the organization levelYandex Audit Trails is enabled at the organization level

kind	severity	ID
automatic	high	o11y.audit-trails

DescriptionDescription

The main tool for collecting Yandex Cloud level logs is Yandex Audit Trails. This service allows you to collect audit logs about events happening to Yandex Cloud resources and upload these logs to Yandex Object Storage buckets or Cloud Logging log groups for further analysis or export. For information on how to start collecting logs, see this guide.

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

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

To learn more, see Comparing management and data event logs.

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

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

Solution: Monitoring Audit Trails and security events using Monitoring

You can export audit logs to 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

Guides and solutionsGuides and solutions

• 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

Data events are monitoredData events are monitored

kind	severity	ID
manual	medium	o11y.data-plane-events

DescriptionDescription

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

You need to enable collection of data event audit logs individually for each supported service.

Instructions and solutionsInstructions and solutions

We recommend to choose Get all events for Yandex Identity and Access Management and Yandex Cloud DNS, as well as for the following services if used:

• Yandex Certificate Manager * Yandex Compute Cloud * Yandex Key Management Service * Yandex Lockbox * Yandex Managed Service for ClickHouse® * Yandex Managed Service for Kubernetes® * Yandex Managed Service for MongoDB * Yandex Managed Service for MySQL® * Yandex Managed Service for PostgreSQL * Yandex Managed Service for Valkey™ * Yandex Object Storage * Yandex Smart Web Security * Yandex WebSQL

The Object lock feature is enabled in Object StorageThe Object lock feature is enabled in Object Storage

kind	severity	ID
manual	medium	s3.used-object-lock

DescriptionDescription

When processing critical data in buckets, it is necessary to ensure protection against deletion and maintain version backups. This can be achieved using mechanisms for versioning, lifecycle management, and object version locking.

Bucket versioning is the ability to store a history of object versions. Each version represents a full copy of the object and occupies the corresponding amount of space in Object Storage. Using version management, you can protect your data both from unintentional user actions and from application failures.

If an object is deleted or modified with versioning enabled, a new version of the object with a new ID is actually created. When an object is deleted, it becomes unavailable for reading, but its version is retained and can be restored.

The retention period for critical data in the bucket is determined by the client’s information security (IS) requirements and information security standards. For example, the PCI DSS standard stipulates that audit logs must be retained for at least one year, with at least three months of data available online.

Instructions and solutionsInstructions and solutions

For more information about setting up versioning, see Bucket versioning in the Object Storage guide.

For more information about lifecycles, see Bucket object lifecycles and Bucket object lifecycle configuration in the Object Storage guide.

In addition, to protect object versions against deletion, use object locks. For more information about object lock types and how to enable them, refer to the guide.

The retention period for critical data in the bucket is determined by the client’s information security (IS) requirements and information security standards. For example, the PCI DSS standard stipulates that audit logs must be retained for at least one year, with at least three months of data available online.

Access through control ports is only allowed for trusted IPsAccess through control ports is only allowed for trusted IPs

kind	severity	ID
automatic	medium	trusted-ip

DescriptionDescription

We recommend that you only allow access to your cloud infrastructure through control ports for trusted IP addresses.

This check displays a list of all security groups containing broad rules that allow access through control ports:

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

Instructions and solutionsInstructions and solutions

Make sure your security groups' rules only allow access to your infrastructure through control ports for trusted IP addresses.

Guides and solutions to use:

If such access is allowed for a broad range of addresses, specify the trusted IP addresses in the relevant access rules:

1. In the management console, select the folder where your security group resides. 2. Go to Virtual Private Cloud. 3. In the left-hand panel, select Security groups and in the list that opens, click the line with the group in question. 4. In the top-right corner, click Edit. 5. In the Rules section, in the line with the rule allowing access through control ports for a broad range of addresses, click ... and select Edit. 6. In the CIDR blocks field, enter only the trusted address for which access will be allowed, e.g., 198.51.100.17/32.

To add several trusted addresses to a rule, click Add. 7. Click Save to save the rule settings. 8. Click Save to save the security group settings.

Access to Kubernetes components through control ports is only allowed for trusted IPsAccess to Kubernetes components through control ports is only allowed for trusted IPs

kind	severity	ID
automatic	medium	trusted-ip-k8s

DescriptionDescription

We recommend that you allow access to Kubernetes components in your cloud infrastructure through control ports for trusted IP addresses only.

This check displays a list of all security groups containing broad rules that allow access through control ports:

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

Instructions and solutionsInstructions and solutions

Make sure your security groups' rules allow access to Kubernetes components through control ports for trusted IP addresses only.

Guides and solutions to use:

If such access is allowed for a broad range of addresses, specify the trusted IP addresses in the relevant access rules:

1. In the management console, select the folder where your security group resides. 2. Go to Virtual Private Cloud. 3. In the left-hand panel, select Security groups and in the list that opens, click the line with the group in question. 4. In the top-right corner, click Edit. 5. In the Rules section, in the line with the rule allowing access through control ports for a broad range of addresses, click ... and select Edit. 6. In the CIDR blocks field, enter only the trusted address for which access will be allowed, e.g., 198.51.100.17/32.

To add several trusted addresses to a rule, click Add. 7. Click Save to save the rule settings. 8. Click Save to save the security group settings.