CSPM — Cloud Security Posture ManagementCSPM — Cloud Security Posture Management

Rules for checking cloud resource configuration.

Responding to security events is set upResponding to security events is set up

DescriptionDescription

How the rule works: The rule checks whether the Security Deck workspace at hand has Threat Detector (TD) enabled.

Risks when not complying with the rule:

• Without notifications, the organization has no way to quickly learn about threats to services in real time. This creates delays in response, which, in turn, increases the likelihood of attackers successfully exploiting vulnerabilities.
• Anomalous activities, such as unauthorized operations on resources, may go undetected. The incident then escalates without response, exacerbating the damage.

Threat Detector (TD) is the first line of response to security incidents in a user's cloud infrastructure in Yandex Security Deck. This module enables automatically identifying suspicious activity and notifying the user about any discovered threats. Threat Detector analyzes audit events found in the client's infrastructure and registered using Yandex Audit Trails.

Each time a rule is triggered by a potential security threat, Security Deck generates an alert with detailed information about the event and recommendations for how to remove the threat.

Instructions and solutionsInstructions and solutions

Make sure to enable Threat Detector (TD) when creating a workspace in Security Deck. For more information, see this guide.

Each time a rule is triggered by a potential security threat, you get an alert with detailed information about the event and recommendations for how to remove the threat.

API keys for AI Studio services must have a defined lifetimeAPI keys for AI Studio services must have a defined lifetime

DescriptionDescription

How this rule works: The system evaluates whether API keys created to work with AI Studio have a determined lifetime.

Yandex Cloud allows you to define the API key lifetime; the maximum lifetime, however, must be defined by the organization policy.

The recommended default lifetime is 90 days for cloud systems and 30 days for high-risk AI systems and agents. Both AWS API-compatible static access keys and authorized keys may not have any server-defined lifetime; this is why they require manual or automated rotation using the createdAt property, as well as deleting unused keys.

Instructions and solutionsInstructions and solutions

1. Get all key types for each service account used in AI, MCP, and DataSphere:

   yc iam api-key list --service-account-id <sa-id> --format json 
   

2. If the retrieved keys do not have any value in the expires at field, their lifetime is unlimited. 3. Make sure to re-issue such keys and define their lifetime.

API keys for AI Studio services must have restricted scopesAPI keys for AI Studio services must have restricted scopes

DescriptionDescription

How the rule works: The system evaluates AI Studio API keys with defined scopes and outputs a list of keys with overly broad permissions.

The API key scope must comply with the least privilege principle. If you do not specify a scope when creating an API key via the CLI, API, or Terraform, a broad set of default scopes is applied. Such a key often gets access not only to AI service operations, but also to Monitoring, Search API, Serverless Functions and Containers Invoke.

You cannot change the API key scope after you create it; you can, however, re-issue the key with the minimum required scopes and delete the legacy key once the client migration is complete.

Instructions and solutionsInstructions and solutions

1. Get the service account API keys:

   yc iam api-key list --service-account-id <sa-id> --format json 
   

2. For each key, get the details:

   yc iam api-key get --id <key-id> --format json 
   

   Here is a list of scopes for an API key created via the CLI, API, or Terraform without specifying scopes: yc.ai.imageGeneration.execute, yc.ai.languageModels.execute, yc.ai.speechkitStt.execute, yc.ai.speechkitTts.execute, yc.ai.translate.execute, yc.ai.vision.execute, yc.monitoring.manage, yc.search-api.execute, yc.serverless.containers.invoke, yc.serverless.functions.invoke.

   If the key's retrieved scope matches the default list or is broader than the minimum required application profile, it constitutes a violation.

   The minimum recommended profiles are:

   • Text generation only: yc.ai.languageModels.execute
   • Image generation only: yc.ai.imageGeneration.execute
   • Speech-to-text only: yc.ai.speechkitStt.execute
   • Text-to-speech only: yc.ai.speechkitTts.execute * Translate only: yc.ai.translate.execute
   • Vision/OCR only: yc.ai.vision.execute
   • MCP invoke only: yc.serverless.mcpGateways.invoke
   • Workflow execution only: yc.serverless.workflows.execute

   The additional available scopes that must not be used unless explicitly required are yc.monitoring.manage, yc.monitoring.read, yc.search-api.execute, yc.serverless.functions.invoke, yc.serverless.containers.invoke, yc.serverless.workflows.execute, yc.serverless.mcpGateways.invoke, yc.logging.write, yc.datasphere.community-projects.manageResource, yc.speech-sense.use, and and other scopes from the current API key reference.

3. If you created a key via the AI Studio interface, do not rely on the creation source. Always verify the key's actual scopes. 4. Re-issue the key with the minimum required scopes:

   yc iam api-key create --service-account-id <sa-id> --scopes <scope1>,<scope2> --expires-at <iso8601> 
   

4. Update consumers, and then delete the legacy key:

   yc iam api-key delete --id <old-key-id> 
   

In Terraform, use the current attribute: scopes = [...]. Do not use lifecycle.ignore_changes for scopes if your goal is to detect and remediate drift.

Yandex DataSphere service accounts must not be assigned critical rolesYandex DataSphere service accounts must not be assigned critical roles

DescriptionDescription

How the rule works: The system verifies that the service accounts linked to Yandex DataSphere communities or projects do not have any roles higher than editor.

In DataSphere, user ML code, jobs, and operations with DataSphere Notebook can be run under a project or community service account or service agent; this requires strict adherence to least privilege principle. Roles that allow managing Yandex Identity and Access Management, service accounts, secrets, encryption keys, object storages, virtual machines, networks, or AI resources pose a particularly high security risk.

Instructions and solutionsInstructions and solutions

1. Get the list of DataSphere projects and communities:

   yc datasphere community list --format json yc datasphere project list --community-id <id> --format json 
   

   If your version does not support CLI commands, use REST API or UI export:

   • Community list
   • Project list

2. For each project or community, identify the associated service account or agent. If the field in question is unavailable in CLI or API, check the details in the Datasphere UI.

3. Check the access permissions these service accounts have by using CIEM.

4. The current DataSphere roles that must be cross-referenced with the Yandex Identity and Access Management role reference before running the scanner are: datasphere.community-projects.viewer, datasphere.community-projects.developer, datasphere.community-projects.editor, datasphere.community-projects.admin, datasphere.communities.viewer, datasphere.communities.developer, datasphere.communities.editor, datasphere.communities.admin.

5. If a specific role is missing from the tenant or reference, the scanner must not abort the task; log it as role not found / not applicable.

6. The prohibited roles for the runtime environment or service accounts in DataSphere without exception are: admin, editor, resource-manager.clouds.owner, resource-manager.admin, iam.serviceAccounts.admin, iam.serviceAccounts.tokenCreator, lockbox.admin, lockbox.editor, kms.admin, kms.editor, storage.admin, compute.admin, vpc.admin, datasphere.communities.admin, datasphere.communities.editor, datasphere.community-projects.admin, datasphere.community-projects.editor, ai.admin, ai.editor, ai.models.admin, ai.models.editor, as well as any excessive *.admin / *.editor permissions.

7. Allow only the minimum required roles for the resources currently in use, such as:

   • storage.viewer or upload roles only to a specific bucket.
   • lockbox.payloadViewer only to a specific secret.
   • ai.models.user or specific ai.*.user roles if the project in question if the project actively calls models.
   • Minimum roles for logging and monitoring, only when required.

The solution is to delete broad roles, create a dedicated service account for the project or community, assign the minimum required roles to a minimum list of resources, and run the scan again.

Different service accounts must be used for different tools, agents, and MCP serversDifferent service accounts must be used for different tools, agents, and MCP servers

DescriptionDescription

How the rule works: The system evaluates service accounts assigned to the MCP server, Cloud Functions, and Workflows. If a single service account is assigned to more than one object, the rule is considered violated.

A service account must be mapped to a single security boundary. You do not have to always adhere to the one service account per resource principle: it is acceptable to use a single account within an approved logical agent if MCP Gateway, Cloud Functions, and Workflow share the same security boundary, owner, data classification, and minimum access requirements. However, sharing a service account across independent agents, MCP Gateway, DataSphere projects, or Tools creates an excessive potential impact. Development, staging, and production environments must use different service accounts.

Instructions and solutionsInstructions and solutions

1. Get an inventory of all component types: MCP Gateway, Functions, Containers, Workflows, DataSphere projects and communities, XXX, AI Assistants and agent wrappers.

2. For each resource, save its type, id, name, folderId, owner, dataClass, environment, serviceAccountId.

3. Get service accounts for serverless resources:

   yc serverless mcp-gateway get --name <name> --format json 
   

4. Use different service accounts for different tools, agents, and MCP servers. You may want to grant granular roles to a service account when working with MCP servers, such as serverless.mcpGateways.viewer.

Do not use highly privileged service accounts for MCP servers, functions, and workflowsDo not use highly privileged service accounts for MCP servers, functions, and workflows

DescriptionDescription

How the rule works: The system checks whether service accounts assigned to MCP servers, functions, and workflows implementing Tools (or individual steps within such workflows) have permissions higher than editor.

By compromising the service account under which an agent workload is running, an attacker can gain access beyond a single tool or gateway.

Roles that allow managing Yandex Identity and Access Management, service accounts, Lockbox secrets, KMS keys, Serverless containers and object storages, as well as the organization-manager role, pose a particularly high security risk.

The admin and editor primitive roles are prohibited without exception for the service account under which an agent workload is running. The viewer and auditor read roles are not always administrative; however, they can lead to data leaks and require separate justification.

Instructions and solutionsInstructions and solutions

1. Get an inventory of MCP Gateway, Functions, Containers, and Workflows.

2. For each resource, determine its serviceAccountId:

   yc serverless function get --name <name> --format json 
   

3. Revoke access permissions through CIEM.

Non-public functions, workflows, and tools that require authorization must not be connected to public MCP servers.Non-public functions, workflows, and tools that require authorization must not be connected to public MCP servers.

DescriptionDescription

How the rule works: The system verifies that functions, workflows, and tools linked to the MCP server are public.

This scenario can lead to a confused deputy vulnerability and potential proxy abuse, where an external subject leverages a public MCP gateway as an intermediary to invoke an internal tool.

The risk arises even if the tool itself is not directly public: it is sufficient for the public gateway to have a service account with permissions that allow accessing the internal tool.

This rule relates to OWASP MCP07:2025 Insufficient Authentication & Authorization and excessive privilege risks.

Instructions and solutionsInstructions and solutions

1. Identify public MCP gateways by running a check based on the Use public MCP servers only when strictly required rule.

2. Get the list of tools of the public gateway:

   yc serverless mcp-gateway get --name <gateway-name> --format json
   

Use public MCP servers only when strictly requiredUse public MCP servers only when strictly required

DescriptionDescription

How the rule works: The system checks whether the created MCP server is public.

By default, any MCP gateway must be private. Public access expands the attack surface and creates a risk of unauthorized execution of Tools and agent logic. Binding the allUsers public group with the serverless.mcpGateways.anonymousInvoker role poses a particularly high security risk, since it allows anonymous calls to MCP Gateway.

Granting access to the allAuthenticatedUsers group with a role that allows invoking a resource or service is also considered public access, even though it requires authentication in Yandex Cloud.

This rule maps to OWASP MCP07:2025 Insufficient Authentication & Authorization.

Instructions and solutionsInstructions and solutions

1. Get the list of MCP gateways:

   yc serverless mcp-gateway list --format json 
   

2. For each gateway, check access to a public group:

   yc serverless mcp-gateway list-access-bindings --name <name> --format json 
   

Do not grant privileged roles in AI services to system groups or groups with a large number of subjectsDo not grant privileged roles in AI services to system groups or groups with a large number of subjects

DescriptionDescription

How the rule works: The system checks whether there are system groups within the organization.

You should grant privileged AI and MCP roles to narrow groups only if they are genuinely required to perform a specific task. Roles for managing models, datasets, AI Assistant, and MCP Gateway, as well as ai.adminand ai.editor and model response moderation roles pose a particularly high security risk.

Such roles must never be assigned to public and system groups. For the viewer and auditor read roles, as well as *user roles, the risk is lower; however, broad assignment still requires review.

Instructions and solutionsInstructions and solutions

1. Get the organization’s access bindings:

   yc organization-manager organization list-access-bindings --id <org-id> --format json 
   

2. Also check bindings at the folder and cloud levels if you assign AI and MCP roles below the organization level.

3. The critical- and high-risk roles for broad groups are: ai.admin, ai.editor, ai.models.admin, ai.models.editor, ai.datasets.admin, ai.datasets.editor, ai.guardrails.admin, ai.guardrails.editor, ai.assistants.admin, ai.assistants.editor, serverless.mcpGateways.admin, serverless.mcpGateways.editor.

4. The medium-risk and potentially high-risk roles for broad groups are: ai.viewer, ai.auditor, ai.models.user, ai.models.viewer, ai.datasets.user, ai.datasets.viewer, ai.guardrails.user, ai.guardrails.viewer, ai.assistants.user, ai.assistants.viewer, ai.languageModels.user, ai.imageGeneration.user, ai.translate.user, ai.vision.user, ai.speechkit-stt.user, ai.speechkit-tts.user, ai.playground.user, serverless.mcpGateways.invoker.

5. Before deploying to a specific tenant, cross-reference the role names with the current role reference. If the role is missing from the tenant, the scanner must not abort the task; instead, it must issue the role not found / not applicable message.

6. Retrieve group membership:

   yc organization-manager group list-members --group-id <id> --format json 
   

7. Public and system groups (allUsers, allAuthenticatedUsers) are always a violation for privileged roles.

8. Broad group threshold:

   • By default: Over 50 human subjects.
   • For high-risk roles (ai.admin, ai.editor, ai.models.admin, ai.models.editor, serverless.mcpGateways.admin, serverless.mcpGateways.editor): Over 10 human subjects.

The solution is to create a restricted group with an owner, an approval process for granting permissions, and regular access reviews, transfer the role to this group, and remove the permission assignment from the broad or public group.

Secrets used by MCP Gateway и Tools should be stored in Yandex LockboxSecrets used by MCP Gateway и Tools should be stored in Yandex Lockbox

DescriptionDescription

How the rule works: If there are AI Studio resources in the environment, the system verifies that tokens for connecting to Tools are stored in Yandex Lockbox.

The secrets stored in MCP Gateway and Tools must be stored in Yandex Lockbox.

Only the service account that actively runs Tools must have access to the secret payload, and it must be restricted to that specific secret.

For Cloud Functions and Serverless Containers, you should use native secret injection into the runtime configuration, ensuring that the function version or container revision stores a reference to the secret rather than the raw value.

For Workflows, secrets must not be provided through input parameters; the workflow must retrieve the secret payload either via runtime access to Lockbox or through a supported secure integration.

For external HTTP Tools, the secret header must not be stored in plain text within the MCP Gateway configuration.

This rule maps to OWASP MCP01:2025 Token Mismanagement and Secret Exposure.

Instructions and solutionsInstructions and solutions

1. Get the list of MCP gateways and the associated tools:

   
   yc serverless mcp-gateway list --format json; 
   

2. For each gateway run:

   
   yc serverless mcp-gateway get --name <gateway-name> --format json 
   

Password policy is PCI DSS 4.0 compliantPassword policy is PCI DSS 4.0 compliant

DescriptionDescription

How the rule works: The rule automatically checks whether the password policy set for the pool's users complies with the following requirements:

• New passwords cannot be similar to previous ones.
• Passwords must be at least seven characters long and it may contain digits as well as uppercase and lowercase letters.
• The password lifetime is no longer than 90 days.
• The number of wrong password entries before lockout is no greater than six.
• The number of previous passwords that cannot be reused when changing a password — no more than 4.
• The lockout duration is at least 30 minutes.

Risks when not complying with the rule:

Weak passwords are one of the primary causes of account compromises. Hackers employ brute force attacks, dictionary attacks, and database leaks to gain access to user accounts. With no password policy in place, users can set easy or previously used passwords. This results in vulnerabilities that are difficult to spot and fix manually.

A password policy decreases such risks. Yandex Cloud provides certain password policy recommendations.

A PCI DSS-compliant password policy sets the following requirements for user passwords:

• Minimum length: 12 characters. The password contains letters and digits. Special characters as well as uppercase and lowercase letters are recommended.
• Requirement 8.2.4: Users must change their password at least once in 90 days. When using MFA, however, frequent password changes are not mandatory.
• Requirement 8.2.5: The new password must not be identical to the last four passwords.
• Requirement 8.2.6: When logging in for the first time or resetting the password, the user must change the temporary password.

Additional requirements:

• Requirement 8.1.6: Lockout occurs after six wrong password entries. The lockout lasts at least 30 minutes or until an admin lifts it.
• Requirement 8.1.8: Automatic logout occurs after 15 minutes of idle time.
• Requirement 8.3: Multi-factor authentication (MFA) is always mandatory in case of remote access to the cardholder data environment (CDE) as well as in case of admin access.

Instructions and solutionsInstructions and solutions

1. Log in to Yandex Identity Hub using an administrator or organization owner account.

2. In the left-hand panel, click User pools and select a user pool.

3. Navigate to the Overview → Password policy → Set up policy → tab.

4. In the Password complexity section:

   • In the Mandatory field, select the character types for the password by activating the following options:

     • Lowercase Latin letters
     • Uppercase Latin letters
     • Numbers

   • In the Minimum length field, specify the minimum number of characters in the password but not fewer than seven.

5. Optionally, under Password uniqueness, in the Password verification field, enable You cannot use passwords included in the database of common passwords. This will protect users from using passwords that can be easily guessed using a dictionary.

6. In the Password lifetime section, set a password lifetime of no longer than 90 days.

7. In the Protection against password guessing section, set the following:

   • Number of wrong password entries before lockout, no greater than six.
   • Interval for counting wrong entries in minutes.
   • Lockout duration, at least 30 minutes.

The cloud administrator receives a notification in case their cloud's secret gets compromisedThe cloud administrator receives a notification in case their cloud's secret gets compromised

DescriptionDescription

How the rule works: The rule checks whether the workspace has Basic Threat Detector rules enabled and the Cloud secret was exposed rule is not among the exceptions.

Threat Detector (TD) analyzes audit events found in the client's infrastructure and registered using Yandex Audit Trails. This module automatically identifies suspicious activity and notifies the user on any threats discovered.

The module's requirements include the Cloud secret was exposed check. This check aims at detecting leaks of cloud credentials, including API keys, tokens, access keys, OAuth tokens, and other secrets associated with Identity and Access Management (IAM).

Credentials, such as access keys or tokens, provide direct access to the cloud's resources. If they end up in public or unreliable sources, such as code repositories, logs, or third-party websites, this may result in security compromises, unauthorized access, and loss of control over the infrastructure.

This rule is triggered when a secret leak is detected by the monitoring system. It identifies the type of the leaked secret (whether it be an IAM token, API key, service account access key, Lockbox secret, or other) and points to the service account which it is associated with. Also recorded is the URL where the secret was found.

Instructions and solutionsInstructions and solutions

Enable the Basic Threat Detector rules check:

1. Navigate to Security Deck.

2. In the left-hand panel, select Workspace and in the window that opens, select your Security Deck workspace.

3. Click Workspace parameters.

4. Navigate to the Control modules tab.

5. Expand the Threat Detection standard list.

   Tip

   If the module is not on the list, contact a manager to gain access.

6. Enable Basic Threat Detector rules.

Kubernetes clusters are checked for CIS complianceKubernetes clusters are checked for CIS compliance

DescriptionDescription

How the rule works: The rule checks whether the CIS Benchmark for Kubernetes ruleset is enabled and whether Kubernetes Security Posture Management (KSPM) has clusters and nodes.

The CIS Benchmark for Kubernetes ruleset is one of the KSPM standards that can be enabled for a Security Deck workspace. It follows the guidelines of the CIS Kubernetes Benchmark, which is an international standard, and comprises rules for checking whether the kubelets on the cluster's worker nodes have a secure configuration.

Kubelet has broad permissions, including pod management, access to secrets and logs, and exec into containers. Therefore, if its configuration is vulnerable, it is one of the most dangerous attack vectors for privilege escalation in a cluster.

The benchmark's rules help detect key types of threats:

• Unauthorized access to the kubelet API.
• Authentication by certificate between the apiserver and kubelet.
• Certificate rotation.
• Access permissions to the configuration files (kubelet.conf, config.yaml, service file).
• Authentication mode and the kubelet's permission to manage iptables.

Whenever the rule is triggered, you get an alert with details on the violation, a list of facts and affected resources, and guidelines to fix the issue.

Instructions and solutionsInstructions and solutions

Enable the CIS Benchmark for Kubernetes check:

1. Navigate to Security Deck.
2. In the left-hand panel, select Workspace and in the window that opens, select your Security Deck workspace.
3. Click Workspace parameters.
4. Navigate to the Control modules tab.
5. Expand the list of KSPM standards.
6. Enable CIS Benchmark™ requirements for Kubernetes.

Managed Kubernetes cluster is regionalManaged Kubernetes cluster is regional

DescriptionDescription

How the rule works: The rule checks whether the Managed Kubernetes cluster at hand is regional.

A regional Managed Kubernetes cluster is one whose control plane nodes and worker nodes are distributed across several availability zones within one geographical region.

A regional cluster complies with these information security requirements:

• Business continuity requirements.
• Requirements of the GOST R 57580 standard and 152-FZ (Russian Federal Law on Personal Data).

Regional clusters boost reliability by replicating both control plane and worker nodes across several zones within a region. A zonal cluster creates a unified point of failure for the entire security infrastructure, from monitoring and responding to managing secrets and audit.

Instructions and solutionsInstructions and solutions

• Create a dedicated cloud network for your cluster. Do not use this network together with other services.
• Create one subnet in each of these three availability zones: ru-central1-a, ru-central1-b, and ru-central1-d. Deploy the master hosts and node groups in these subnets.
• Use non-overlapping ranges of IP addresses for subnets, pods, and services. Factor in cluster growth for your address space in advance.
• Configure security groups before creating the cluster. Allow only necessary traffic: between the master and nodes, between nodes, from load balancers.
• If your cluster does not require internet access, create it without a public IP address and set up access through a NAT gateway or Yandex Cloud Interconnect.

Outbound internet access control is performedOutbound internet access control is performed

DescriptionDescription

How the rule works: The rule ensures inventory of resources with external network access through an external IP address in the VM settings or with a NAT gateway in place.

Egress traffic control is one of the fundamental cybersecurity measures. It helps prevent data leaks, protects against anyone using your infrastructure to attack other services or systems, and decreases the risks associated with a public IP address. Without egress traffic control, you cannot see which data goes outside of your infrastructure and where. This makes it impossible to detect anomalies or investigate security issues.

Risks when not complying with the rule:

• Using the infrastructure for attacks: A compromised VM may become a source of DDoS, port scanning, or brute force attacks against outside resources.
• Data exfiltration: With no egress traffic limitations in effect, malicious software or an insider can freely export your data elsewhere.
• C2 communications: Malicious software can set up a control channel through unregulated egress traffic.
• Violation of threat modeling in isolated environments: Unauthorized creation of a public IP address or NAT gateway completely nullifies the isolation of a protected environment.
• Public IP address (egress NAT) risk: A shared address pool may lead to an address ending up in blacklists due to other lessees' actions.
• No audit: There is no way to investigate incidents and no compliance with regulatory requirements.

Instructions and solutionsInstructions and solutions

• If a VM has public IPs, make sure they are absolutely necessary. Otherwise, delete the external IP address in the VM settings.
• If there is a NAT gateway, make sure it is absolutely necessary. Otherwise, delete it.
  To delete a VM's public IP address:

1. Go to Compute Cloud.
2. Select your VM.
3. Under Network, click ... in the top-right corner of your network interface's section and select Disassociate public IP address.
4. In the window that opens, click Delete.

To delete a NAT gateway:

1. Before deleting your NAT gateway, disassociate it from all route tables that use it.
2. Go to Virtual Private Cloud.
3. On the left-hand panel, select Gateways.
4. Click ... in the row with your NAT gateway's name and select Delete.
5. In the window that opens, click Delete.

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

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

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

Risks if the rule is not followed: Long-lived service account keys that are never rotated become a persistent attack vector. If a key is leaked — through a code repository, logs, or a compromised system — an attacker can use it indefinitely until it is manually revoked. Regular rotation limits the window of exposure for any compromised key.

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

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

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

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

DescriptionDescription

How this rule works: This is a manual check. The rule cannot automatically enumerate who has group membership management rights — it relies on the administrator reviewing IAM role bindings for the organization and for individual groups as resources. The rule flags cases where users hold organization-manager.groups.memberAdmin, admin, editor, or other privileged roles that grant group membership management capabilities.

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

Risks if the rule is not followed: If unauthorized users can manage group memberships, they can add themselves or others to groups that have privileged roles in the cloud. This is a form of privilege escalation — an attacker who gains access to an account with group management rights can silently grant themselves access to any resource the group has permissions for, without directly modifying IAM role bindings.

Instructions and solutionsInstructions and solutions

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

DescriptionDescription

How this rule works: The rule automatically scans IAM role assignments at the organization level and identifies service accounts that have been granted admin, editor, or resource-manager.clouds.owner roles. It flags these service accounts regardless of whether the roles are actively used. The rule does not verify whether the assignment is justified by a specific use case.

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

Risks if the rule is not followed: A service account with organization-level admin or editor roles has the ability to modify access policies, create and delete resources, and manage other service accounts across the entire organization. If the service account's key is compromised — for example, leaked in a repository or log file — an attacker gains organization-wide administrative access, which can lead to a complete takeover of the cloud environment.

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

DescriptionDescription

How this rule works: The rule automatically scans IAM role assignments across the organization and identifies service accounts that have been granted any of the listed service-level admin roles (compute.admin, storage.admin, iam.serviceAccounts.admin, vpc.admin, k8s.admin, lockbox.admin, kms.admin). It flags these service accounts regardless of whether the roles are actively used.

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

Risks if the rule is not followed: Service accounts with admin-level roles on critical services can perform any operation within those services. A compromised service account key gives an attacker the ability to read all secrets from Lockbox, decrypt data with KMS keys, modify network configurations, or take over Kubernetes clusters — depending on which admin roles are assigned. Limiting service accounts to the minimum required roles reduces the impact of any key compromise.

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

DescriptionDescription

How this rule works: The rule automatically identifies all accounts that have any of the listed privileged roles assigned at the organization, cloud, folder, or billing account level. It then requires manual review to confirm that each account with a privileged role is a trusted administrator. The rule does not automatically determine whether the assignment is legitimate.

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.

Risks if the rule is not followed: Privileged roles in the hands of untrusted or compromised accounts give an attacker full control over the organization's cloud infrastructure — the ability to create and delete resources, change access policies, read encryption keys and secrets, and disable audit logging. A single compromised privileged account can lead to a complete takeover of the cloud environment.

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

DescriptionDescription

How this rule works: 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.

Risks if the rule is not followed: Without resource labels, it is difficult to identify which resources belong to which team, environment, or project. This makes it harder to enforce access controls, track costs, respond to incidents, or perform security reviews. Unlabeled resources may be overlooked during decommissioning, leaving orphaned infrastructure that expands the attack surface.

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

DescriptionDescription

How this rule works: This is a manual check. The rule automatically finds buckets that have no bucket policy configured at all. It flags these buckets for manual review — the administrator must decide whether a policy is needed based on the bucket's sensitivity and use case. The rule does not verify whether IAM roles alone provide sufficient access control.

Bucket policies describe who, and under what conditions, can perform operations on a bucket and the objects in it. Compared to IAM roles, bucket policies allow finer-grained rules — restrict access by source IP, HTTP referer, object prefix, or specific actions.

Examples of useful policies:

• allow downloading objects only from a specified IP range;
• block downloads from a specific IP;
• give each user full access only to a specific prefix in the bucket;
• give a service account access only to a folder named after its ID.

Buckets without any bucket policy rely entirely on IAM. That works, but loses the ability to express conditions like "downloads from the office network only" or "writes from CI/CD only".

See recommendations for context.

Risks if the rule is not followed: Without bucket policies, there is no way to enforce network-level or context-based access restrictions on Object Storage. A compromised IAM credential grants unrestricted access to the bucket from any location, and there is no deny layer to block access from untrusted IPs or to prevent accidental writes from unauthorized sources.

Instructions and solutionsInstructions and solutions

For each bucket without a policy, decide whether one is needed:

1. If the bucket is internal and IAM roles already give the right access, no policy is required — confirm this in the manual verification.
2. If the bucket would benefit from extra conditions (IP restrictions, prefix-based access, deny rules), configure a bucket policy — start from one of the policy examples in the documentation.
3. After applying, verify that legitimate clients still work and that the cases the policy is meant to block are actually blocked.

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

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

DescriptionDescription

How this rule works: The rule automatically scans IAM role assignments across the organization, clouds, and folders, and also checks direct role assignments on KMS keys. It flags all users and service accounts that have any of the listed roles that grant KMS encryption/decryption or management capabilities. The rule requires manual review to confirm that each flagged account legitimately needs the assigned KMS permissions.

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.

Risks if the rule is not followed: Overly broad KMS permissions mean that a compromised account or service account can decrypt any data protected by KMS keys in the organization, not just the data it legitimately needs to access. This undermines the purpose of encryption at rest — an attacker who gains access to such an account can read all encrypted data without needing to break the encryption itself.

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

DescriptionDescription

Vulnerability databases (CVE) are updated continuously: a base image that scanned clean a month ago may have several known vulnerabilities today, simply because new ones were published.

Rescanning images regularly catches such cases — without it, you have no way to know that an image you are still running has become vulnerable. For most production registries, weekly scanning is the minimum; daily is better.

Yandex Container Registry can run scans automatically on a schedule.

Risks if the rule is not followed: Without regular rescanning, production workloads may run images with known vulnerabilities that were published after the last scan — giving attackers a window to exploit them before they are detected.

Instructions and solutionsInstructions and solutions

For each registry used in production:

1. Enable scheduled scanning of all Docker images in the registry, with a frequency of at least once a week.
2. After scanning, review the scan results and rebuild affected images with patched base layers.
3. Integrate scanning into the CI/CD pipeline so that new vulnerabilities are caught at build time as well.

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

DescriptionDescription

How this rule works: The rule checks whether Kubernetes clusters in the organization's folders have external IP addresses assigned, which would make the Kubernetes API accessible from the internet.

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

Risks if the rule is not followed: Exposing the Kubernetes API to the internet makes it a target for automated scanning, brute-force attacks against credentials, and exploitation of API server vulnerabilities. A successful attack can give an attacker full control over the cluster, all workloads running in it, and the secrets stored there.

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

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.

Risks if the rule is not followed: Insecure node group configurations — such as privileged containers, disabled audit logging, or overly permissive file system permissions — can be exploited by an attacker who gains access to a node. These misconfigurations can enable container escapes, privilege escalation, and lateral movement across the cluster.

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

DescriptionDescription

A cluster in Managed Service for Kubernetes uses two service accounts:

• Cluster service account — Managed Service for Kubernetes uses it to manage cluster nodes, subnets for Pods and Services, disks, load balancers, and to encrypt and decrypt secrets.
• Node group service account — cluster nodes use it to authenticate in Container Registry when pulling images. For other registries, no roles need to be granted to this service account.

Using the same service account for both purposes is convenient at first, but it gives every node in the cluster the permissions of the cluster service account — including the ability to manage nodes, subnets, and load balancers. A compromised node can then change the cluster's network or scale node groups, not only pull images.

Splitting the roles between two service accounts limits the blast radius of a compromised node to what it actually needs.

Risks if the rule is not followed: If a single service account is used for both the cluster and node groups, a compromised node gains full cluster management permissions. An attacker who takes control of a node can modify the cluster's network configuration, scale or delete node groups, and access secrets — far beyond what a node should be able to do.

Instructions and solutionsInstructions and solutions

Use two separate service accounts for the cluster:

1. Create a service account for the cluster and grant it the roles required for cluster management.
2. Create a separate service account for the node group and grant it only the container-registry.images.puller role on the registries from which the cluster pulls images.
3. For an existing cluster with a shared service account, create the missing one and switch the cluster or node group to it through updating the cluster or updating the node group.

For details on access management in Managed Service for Kubernetes, see the service security documentation.

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

DescriptionDescription

The rule verifies 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.

Risks if the rule is not followed: Without audit log collection for GitLab, security-relevant events — such as instance creation, modification, or deletion — are not recorded. This makes it impossible to detect unauthorized changes to the GitLab instance, investigate incidents, or demonstrate compliance with change management requirements.

Instructions and solutionsInstructions and solutions

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

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.

Risks if the rule is not followed: A trail in error state silently stops collecting audit logs. During the outage, all cloud operations — including potentially malicious ones — go unrecorded. This creates a blind spot in security monitoring and may result in compliance violations if audit log retention requirements cannot be met.

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

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

DescriptionDescription

How the rule works: it checks that group mapping is configured in each SAML federation.

In organizations with a lot of users, you may need to grant the same access permissions for Yandex Cloud resources to multiple users at once. In 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.

Risks if the rule is not followed: Without group mapping, access permissions must be assigned manually to each user, increasing the risk of misconfiguration and excessive privilege grants. Users who leave a group in the identity provider may retain their Yandex Cloud access indefinitely, creating orphaned permissions that can be exploited.

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

DescriptionDescription

How this rule works: The rule automatically identifies all accounts (users and service accounts) that have any access rights assigned for service accounts — including the ability to use, impersonate, or manage them. It flags these accounts for review. The rule does not automatically determine whether the access is legitimate or excessive.

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.

Risks if the rule is not followed: A user with access to a privileged service account effectively inherits all of that account's permissions. If too many users can use or manage a powerful service account, a compromised user account becomes a path to privilege escalation — the attacker can act as the service account and perform any action it is authorized for, including accessing sensitive data, modifying infrastructure, or creating new credentials.

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

DescriptionDescription

A registry in Yandex Container Registry is by default reachable from any IP address — anyone with valid credentials can pull or push images from anywhere on the internet.

IP-based access control lets you restrict pull and push operations on a registry to a specific list of IP addresses or CIDR ranges. This adds a network-level boundary on top of IAM: even if a service account token leaks, an attacker outside the allowed IP ranges still cannot use it to pull images (and learn what runs in your infrastructure) or push backdoored images.

Risks if the rule is not followed: Without IP-based access control, a leaked service account token can be used from any location to pull images (exposing your infrastructure inventory) or push backdoored images into the registry, potentially compromising all workloads that use them.

Instructions and solutionsInstructions and solutions

Restrict access to the registry to known IP ranges:

1. Determine which IPs need to pull and push images — typically the cluster's egress IPs (NAT gateway), CI/CD runner pools, and a small set of administrator addresses.
2. Set IP permissions on the registry for the PULL and PUSH actions, listing only those ranges.
3. After saving, verify from an unrelated IP that pull and push are blocked, and from an allowed IP that they still work.

See the Container Registry documentation for details.

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

DescriptionDescription

How this rule works: This rule finds buckets that look publicly accessible — confirm whether each found bucket really should be public, then mark the rule's status manually. The rule does not catch all ways of granting public access — for example, IAM role changes and anonymous_access_flags are not detected automatically.

A bucket in Object Storage becomes publicly accessible when one of the following is configured: an IAM role granted to a system public group (All users / All authenticated users), an allUsers / allAuthenticatedUsers entry in the bucket or object ACL, a bucket policy that allows access without authentication, or anonymous access enabled on the bucket itself.

Risks if the rule is not followed: Public access on a bucket that is not meant to be public is one of the most frequent root causes of data leaks in cloud infrastructure — sensitive files, backups, and configuration data can be read or downloaded by anyone on the internet.

Instructions and solutionsInstructions and solutions

For each bucket from the list:

• If public access is not needed, remove it: revoke roles granted to public groups, remove allUsers / allAuthenticatedUsers from the bucket and object ACL, edit or delete the bucket policy, disable anonymous_access_flags.
• If the bucket really has to be public (for example, hosting a static website), document this and grant the narrowest access possible — read-only, only on the prefixes that should be exposed.
• For one-off sharing of individual objects from a non-public bucket, use pre-signed URLs instead of opening the whole bucket.
• For buckets that contain or might contain sensitive data, use DSPM of Security Deck to monitor what is stored there.

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

DescriptionDescription

How this rule works: The rule automatically checks whether the "Access from console" option is enabled on managed database clusters. It flags all clusters where this option is active, regardless of whether the access has been used. The rule does not verify whether the access is actively monitored or whether it is needed for a legitimate purpose.

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.

Risks if the rule is not followed: Console access to managed databases allows any user with the appropriate IAM role to run arbitrary operations, bypassing application-level access controls and audit logging. This increases the risk of accidental data exposure, unauthorized data modification, and makes it harder to attribute database changes to specific application actions.

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

DescriptionDescription

How this rule works: The rule automatically checks whether the "Access from DataLens" option is enabled on managed database clusters. It flags all clusters where this option is active. The rule does not verify whether the DataLens integration is actively used or whether it is needed for a legitimate business purpose.

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.

Risks if the rule is not followed: Enabling DataLens access to databases with critical data unnecessarily expands the attack surface. If a DataLens account or dashboard is compromised, an attacker can query sensitive data directly from the database. Unnecessary integrations also complicate access auditing and increase the number of paths through which data can be exfiltrated.

Instructions and solutionsInstructions and solutions

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

DescriptionDescription

How this rule works: The rule automatically scans all API keys for service accounts in the organization and identifies keys that have no scopes defined. It flags these keys regardless of whether they are actively used. The rule does not verify whether the key has been rotated recently or whether it is stored securely.

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

Risks if the rule is not followed: An API key without defined scopes can be used to call any API that the service account has access to. If such a key leaks — for example, into a public repository or log file — an attacker can use it to access all services the account is authorized for, not just the one the key was intended for. Scoped keys limit the damage from a key compromise to a single service or action.

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

DescriptionDescription

How this rule works: The rule checks whether centralized identity management (federation or user pools) is configured for the organization.

Yandex Cloud has two ways to manage user accounts centrally:

• Identity federation (external IdP) for single sign-on (SSO) into Yandex Cloud. If your company already runs a user and access management system (Active Directory, Google Workspace, Keycloak), you can use it to authenticate employees in Yandex Identity Hub — no need to create a separate Yandex account for each employee, and the company's password and account policies stay in effect.

• User pools for centrally managing local accounts in your domains, with control over authentication settings and account data.

Without centralized account management, employees use personal Yandex ID accounts to access cloud resources. That works, but offboarding becomes manual and error-prone, password and 2FA policies cannot be enforced from one place, and the company has limited visibility into who has active access.

Risks if the rule is not followed: Former employees may retain access to cloud resources, corporate security policies (password complexity, 2FA) cannot be enforced uniformly, and there is no centralized audit trail for access events — making it difficult to detect unauthorized access.

Instructions and solutionsInstructions and solutions

Set up centralized account management for the organization:

• For most companies, configure a SAML-compatible identity federation with your existing IdP — this enables SSO and inherits the company's account policies.
• For accounts that do not fit into the corporate IdP (for example, partners, contractors), use user pools.
• Enable group mapping between the IdP and Identity Hub so that role assignments follow IdP groups, not individual accounts.

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

DescriptionDescription

How this rule works: This is a manual check. The rule automatically identifies accounts that have primitive roles (admin, editor, viewer, auditor) assigned at the cloud or folder level. It flags these accounts for manual review — the administrator must confirm whether the broad role is justified or whether it should be replaced with a more specific service role. The rule does not automatically determine whether the assignment is legitimate.

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.

Risks if the rule is not followed: Primitive roles like editor or admin grant broad permissions across all cloud services. If an account with such a role is compromised, the attacker gains the ability to modify or delete resources, read secrets, and change access policies across the entire cloud or folder — far beyond what the account legitimately needed. Using service-specific roles limits the blast radius of any credential compromise.

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

DescriptionDescription

How this rule works: The rule automatically checks whether OS Login is enabled on virtual machines. It flags VMs where OS Login is not configured, meaning access is managed through manually distributed SSH keys rather than through IAM-linked identities. The rule does not verify whether the VMs are actively used or whether existing SSH keys have been audited.

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.

Risks if the rule is not followed: Without OS Login, VM access is managed through manually distributed SSH keys that are not tied to IAM identities. When an employee leaves or a key is compromised, there is no centralized way to revoke access — each key must be manually removed from every VM. Unmanaged SSH keys can persist indefinitely, giving former employees or attackers continued access to virtual machines.

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

DescriptionDescription

How this rule works: This is a manual check. The rule checks if there is a public access granted to All authenticated users and All users within an organization, cloud or folder.

In Yandex Cloud you can grant public access to a resource by assigning a role to one of the system public groups:

• All authenticated users — all authenticated users. This includes every Yandex Cloud user and service account, both from your clouds and from other users' clouds.
• All users — any user, no authentication required.

Public access is a frequent cause of data leaks and unauthorized changes, because it opens a resource to a much wider audience than usually intended. It should stay only on resources that are deliberately made public — for example, a static website served from an Object Storage bucket.

Risks if the rule is not followed: Granting public access to resources exposes them to all internet users or all Yandex Cloud users, leading to potential data leaks, unauthorized modifications, and compliance violations — especially if the resource contains sensitive or personal data.

Instructions and solutionsInstructions and solutions

Find all roles granted to All users and All authenticated users — the full list is available in the CIEM module of Security Deck.

For each resource where such a role is granted:

• If the resource should not be public, remove the role.
• If the resource should be public, make sure that this is intentional.
• Check higher levels first — organization, cloud, and folder — and only then the resource itself: roles granted on higher levels are inherited by everything below.

Service accounts have minimum privileges grantedService accounts have minimum privileges granted

DescriptionDescription

How this rule works: This is a manual check. The rule helps identify service accounts that may have excessive privileges by surfacing them for review. The administrator must audit the roles assigned to each service account and confirm that they are the minimum required for the application to function. The rule does not automatically determine which roles are excessive.

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

Risks if the rule is not followed: Service accounts with excessive privileges expand the blast radius of any key compromise. If a service account key leaks — for example, into a code repository, container image, or log file — an attacker can use it to perform any action the account is authorized for. Overly broad roles mean that a single leaked key can give access to sensitive data, allow infrastructure modifications, or enable lateral movement across the cloud environment.

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

DescriptionDescription

How this rule works: The rule finds VMs where access to the serial console is enabled, so you can confirm that this was a planned change.

By default, access to the serial console of a virtual machine in Yandex Compute Cloud is disabled. The serial console gives a low-level connection to the OS — it shows boot logs, system messages, and accepts local logins.

When access is enabled, several risks appear:

• Sensitive data (credentials, keys, configuration) can leak through the console output.
• Anyone with the role for serial console access can connect, and several users can share the same session at once.
• A session left open can be picked up by another user.

Read more in Getting started with the serial console in the Yandex Compute Cloud documentation.

Risks if the rule is not followed: Enabled serial console access can expose sensitive data through console output, allow unauthorized users to connect to the VM's OS, and enable session hijacking — all without leaving traces in standard access logs.

Instructions and solutionsInstructions and solutions

For each VM where serial console access is enabled, decide whether it is needed:

• If it is not, disable access on the VM.
• If it must stay enabled, grant the compute.editor or compute.admin role only to a small group of administrators who actually need it, use a strong password for local OS login and rotate it regularly, make sure secrets are not written to the console output, and after work in the management console sign out of Yandex Cloud or close the browser tab to end the session.

Yandex Application Load Balancer uses HTTPSYandex Application Load Balancer uses HTTPS

DescriptionDescription

How this rule works: The rule checks whether Application Load Balancer listeners use HTTPS instead of plain HTTP.

Application Load Balancer supports both HTTP and HTTPS listeners. With an HTTP listener, traffic between clients and the balancer goes in clear text — anyone with access to the network in between can read or change requests and responses, including credentials, session cookies, and personal data.

Encrypting web traffic with TLS is an industry standard: modern browsers mark plain HTTP sites as insecure, restrict features such as authentication and geolocation on them, and increasingly drop HTTP support for new APIs.

For any service handling user data or authentication, use an HTTPS listener with a TLS certificate from Certificate Manager.

Risks if the rule is not followed: Without HTTPS, all traffic between users and the load balancer is transmitted in clear text, exposing credentials, session tokens, and personal data to interception or modification by anyone with network access (MITM attacks).

Instructions and solutionsInstructions and solutions

Set up an HTTPS listener on the balancer:

1. Add a TLS certificate to Certificate Manager — issue one through Let's Encrypt or import your own.
2. Add an HTTPS listener to the balancer using the TLS termination guide.
3. If the HTTP listener should remain only as a redirect to HTTPS, configure a redirect from HTTP to HTTPS. Otherwise, remove it.

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

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.

Risks if the rule is not followed: Without HTTPS, traffic between the client and API gateway is transmitted unencrypted, enabling hackers to intercept data via MITM attacks and exposing confidential information such as personal data, payment data, authorization tokens, and passwords.

Instructions and solutionsInstructions and solutions

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

DescriptionDescription

Cloud CDN supports two paths that can carry user traffic in clear text: from the client to the CDN edge and from the CDN edge to the origin. If either path uses HTTP, traffic between users and the origin (including authentication cookies and other sensitive data) can be read or modified by anyone on the network in between.

Encrypting web traffic with TLS is an industry standard: modern browsers mark plain HTTP sites as insecure and restrict features such as authentication and geolocation on them. The recommended setup for a CDN resource is HTTPS on both legs — from the client to the edge and from the edge to the origin — using a TLS certificate from Certificate Manager.

Risks if the rule is not followed: Without HTTPS on CDN paths, authentication cookies, session tokens, and other sensitive data transmitted between users and the origin can be intercepted or modified by attackers with network access, enabling session hijacking and data theft.

Instructions and solutionsInstructions and solutions

Configure HTTPS for the CDN resource:

1. Add a TLS certificate to Certificate Manager — issue one through Let's Encrypt or import your own.
2. Enable HTTPS on the CDN resource and select the certificate.
3. Configure the CDN to connect to the origin over HTTPS, and enable redirect from HTTP to HTTPS for client-side traffic.

Application DDoS protection is enabled (L7)Application DDoS protection is enabled (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.

Risks if the rule is not followed: Without L7 DDoS protection, application-layer attacks can exhaust backend resources, causing service outages even when network-level protection is in place. Attackers can craft HTTP floods or slow-loris attacks that bypass L3/L4 defenses and render web applications unavailable to legitimate users.

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)

DescriptionDescription

How this rule works: The rule verifies that Yandex DDoS Protection is enabled on public IPs. If you use a third-party DDoS protection product, mark the rule as completed manually.

Without L3/L4 DDoS protection, a public IP of a VM or a Network Load Balancer is fully exposed to volumetric attacks: an attacker can saturate the channel or exhaust the workload's capacity simply by sending enough traffic.

Yandex DDoS Protection is a Virtual Private Cloud feature that protects cloud resources from such attacks at OSI layers 3 and 4. With it enabled, Yandex Cloud continuously analyses incoming traffic to the protected IP, detects anomalies, and drops unwanted traffic when its volume threatens the workload.

There is also advanced DDoS protection that covers OSI layers 3, 4, and 7 and gives access to detailed attack and load metrics.

Risks if the rule is not followed: Without L3/L4 DDoS protection, a volumetric attack can saturate the network channel or exhaust the workload's resources, causing complete service unavailability and potential financial losses.

Instructions and solutionsInstructions and solutions

Enable basic DDoS protection on every public IP that should not be exposed to volumetric attacks:

1. When creating a VM or reserving a public IP, select DDoS protection — see Enabling DDoS Protection.
2. For workloads with strict availability requirements, request advanced protection or contact technical support.

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

DescriptionDescription

Yandex Container Registry can scan Docker images for vulnerabilities both when an image is pushed and on a schedule. By default, both options are enabled, and rescanning happens every 7 days, with the option to switch to daily.

Without scheduled rescans, an image that passed scanning on push can become vulnerable later — when a new CVE is discovered in one of its layers — and the cluster will keep running it. Default settings are calibrated to catch this; turning them off requires a deliberate reason.

Risks if the rule is not followed: Without scheduled rescanning, images that were clean at push time can silently become vulnerable as new CVEs are published, and the cluster will continue running them — leaving known vulnerabilities undetected and unpatched in production.

Instructions and solutionsInstructions and solutions

Make sure that on every registry the following options are enabled (Container Registry → Registry → Settings → Automatic scanning):

• Scan Docker images on push — scans every image at upload.
• Scan all Docker images in the registry — periodically rescans existing images. The frequency should be at least weekly; switch to daily for production registries.

Read more in Vulnerability scanner and Scanning Docker images in the Container Registry documentation.

Advanced Rate Limiter is implementedAdvanced Rate Limiter is implemented

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.

Risks if the rule is not followed: Without rate limiting, web applications are vulnerable to HTTP flood attacks and API abuse that can exhaust backend resources and cause denial of service. Attackers can also exploit unrestricted access for credential brute-forcing or automated data harvesting.

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

DescriptionDescription

Public web forms — sign-in, registration, password recovery, comment forms, search — are a typical target for automated attacks: bots register fake accounts, brute-force passwords, scrape content, and submit spam.

Yandex SmartCaptcha protects forms from such requests. The service evaluates each request with ML models and shows a challenge only to suspicious clients, so most real users are not interrupted by a "I'm not a robot" check.

Risks if the rule is not followed: Without CAPTCHA protection, public web forms are vulnerable to automated bot attacks — credential stuffing, account enumeration, spam submissions, and content scraping — which can lead to account takeovers, service abuse, and data theft.

Instructions and solutionsInstructions and solutions

Add SmartCaptcha to public forms that bots could abuse:

1. Create a SmartCaptcha and add the client-side widget to the form.
2. On the server, validate the SmartCaptcha token before processing the form.
3. Monitor the SmartCaptcha statistics to tune the captcha mode based on the share of traffic that is being challenged.

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

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.

Risks if the rule is not followed: Without Smart Web Security, web applications are exposed to L7 DDoS attacks, bot traffic, and web exploits (such as SQL injection and XSS) that can compromise application availability and data integrity. Unprotected endpoints are a primary target for automated attack tools.

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

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.

Risks if the rule is not followed: Without a WAF, web applications are vulnerable to OWASP Top 10 attacks including SQL injection, cross-site scripting (XSS), and remote code execution. These attacks can lead to data breaches, account takeovers, and full application compromise.

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

DescriptionDescription

Without automatic vulnerability scanning, every new Docker image pushed to the registry is added to the inventory unchecked: vulnerable base layers and components, accidentally introduced malicious code, and outdated dependencies all reach the cluster as if nothing happened.

Container Registry can scan images automatically at push and surface the results in the scan report — this is the fastest way to learn about a problem before the image is deployed.

Risks if the rule is not followed: Without automatic scanning on push, vulnerable images, malicious code, and outdated dependencies can silently reach production clusters — where they may be exploited before anyone notices.

Instructions and solutionsInstructions and solutions

Enable scanning on push for every registry:

1. In the management console open the registry settings (Container Registry → registry → Settings).
2. Under Automatic scanning, enable Scan Docker images on push.
3. Review scan results for the latest images and address any vulnerabilities found before deploying them.

For new registries, this option is enabled by default — keep it that way.

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

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.

Risks if the rule is not followed: If IMDSv1 is enabled, an SSRF vulnerability in any application running on the VM can allow an attacker to steal the service account IAM token from the metadata endpoint. With this token, the attacker gains all permissions of the service account, potentially enabling lateral movement, data exfiltration, or full cloud account takeover.

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.

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

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

DescriptionDescription

Backups for VM disks are the only practical way to recover from data loss or corruption — accidental deletion, ransomware, a failed update, hardware failure. Without backups, an incident on the VM directly turns into permanent data loss and downtime.

Yandex Cloud offers two ways to back up VM disks:

• Cloud Backup — a managed backup service with policies, retention rules, and the ability to restore on a different VM.
• Scheduled disk snapshots — a Compute Cloud feature that periodically creates snapshots of the disks.

Risks if the rule is not followed: Without backups, any data loss event — accidental deletion, ransomware, hardware failure, or a failed update — results in permanent, unrecoverable data loss and extended downtime with no way to restore the previous state.

Instructions and solutionsInstructions and solutions

Configure backups for the VM:

• For production workloads, activate Cloud Backup and attach the VM to a backup policy with a retention period that matches your recovery requirements.
• For other VMs, create a snapshot schedule for the disks and pick a frequency and retention period that match how often the data changes.
• Periodically verify that backups can actually be restored — an unverified backup is not a backup.

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

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.

Risks if the rule is not followed: An expired TLS certificate causes browsers and clients to display security warnings or refuse connections entirely, resulting in service unavailability. Expired certificates also indicate a lapse in security hygiene that may signal broader certificate management failures, potentially leaving services exposed to man-in-the-middle attacks.

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

DescriptionDescription

A key in Key Management Service is the gateway to the data it encrypts: lose the key, and the data encrypted with it is unrecoverable.

For keys that protect business-critical data — encrypted Object Storage buckets, etcd of a Managed Service for Kubernetes cluster, secrets in Lockbox — accidental deletion is one of the most damaging operations possible. Deletion protection makes the deletion call fail until someone explicitly turns the protection off, which gives time to notice and stop a wrong action.

Risks if the rule is not followed: Accidental or malicious deletion of a KMS key permanently destroys all data encrypted with it — including Object Storage buckets, Kubernetes cluster state, and Lockbox secrets — with no possibility of recovery.

Instructions and solutionsInstructions and solutions

Enable deletion protection on every KMS key that encrypts data you cannot afford to lose:

1. In the management console, open the key settings (KMS → key → Edit).
2. Enable deletion protection.
3. Limit who can disable the flag — the role kms.editor is enough to remove protection, so review who has it through the CIEM module of Security Deck.
4. Make sure that key removal goes through a planned change — confirm with the data owner first, then disable protection and delete.

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)

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.

HSM-backed keys provide hardware-enforced isolation, ensuring cryptographic operations cannot be performed outside the secure hardware boundary.

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

DescriptionDescription

Each version of a KMS key contains its own key material — the actual cryptographic key used to encrypt and decrypt data. Rotation creates a new version with new key material, while previous versions stay available for decrypting data that was already encrypted with them.

Rotation is what makes data retention practical: when the time comes to remove old data, you can also retire the key version that protected it, and the key material disappears together with the data.

Key Management Service supports both manual and automatic rotation. The right setup depends on whether the key protects data the service stores or only data the service processes:

• Keys for services that only process data (Message Queue, Cloud Functions). Set up automatic rotation with a period longer than how long any one piece of data is processed. Old key versions can be retired once the data they protected has been processed.
• Keys for services that store data (managed databases, encrypted disks, Object Storage). Use manual rotation or automatic rotation that aligns with your data retention rules. Old versions should be retired only after all data encrypted with them has been re-encrypted or deleted — destroying a version that still has data behind it makes that data unrecoverable.

Risks if the rule is not followed: Without key rotation, a compromised key version remains in use indefinitely — any data encrypted with it stays at risk for as long as the key is not rotated, and there is no mechanism to limit the exposure window after a potential key compromise.

Instructions and solutionsInstructions and solutions

For each KMS key in production:

1. Decide whether the key encrypts data the service stores or only processes — that determines when old versions can be retired.
2. Set the rotation period on the key, aligning it with your data retention rules.
3. For keys that protect stored data, document a procedure for safely retiring old versions — only after all data encrypted with them has been re-encrypted or deleted.

Read more about key versions in the KMS documentation.

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

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)

Risks if the rule is not followed: Without customer-managed KMS encryption, you have no control over who can decrypt disk data at the infrastructure level. Customer-managed keys allow you to revoke access to data by disabling the key, and to audit all cryptographic operations via Audit Trails.

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

DescriptionDescription

Critical data and access secrets — authentication tokens, API keys, encryption keys, database passwords — should not be stored as plain text in code, in resource names and descriptions, in VM metadata, or in similar places. Anyone with access to the source code, the cloud console, or VM metadata then has access to those secrets.

Yandex Lockbox is a managed secret storage service. It keeps secrets encrypted with a key from Key Management Service, gives them out only to authorized accounts, and writes every access to Audit Trails.

Risks if the rule is not followed: Credentials stored in plain text in code, configuration, or metadata can be extracted by anyone with read access to those locations — developers, CI/CD pipelines, or an attacker who gains access to the repository or VM. A leaked secret can be used to access cloud resources, databases, or external services, often without leaving a trace in audit logs.

Instructions and solutionsInstructions and solutions

Move secrets out of code, configuration, and metadata into Lockbox:

1. Create a secret in Lockbox for each credential or sensitive value used by your workloads.
2. Grant access to the secret only to the service account of the workload that really needs it — use the lockbox.payloadViewer role.
3. Read secrets from the workload directly from Lockbox — for example, from a VM through the SDK or CLI, and from Managed Service for Kubernetes via the External Secrets Operator with Yandex Lockbox support.
4. Remove the secret from the original location (code, config, metadata) and rotate it — the old value should be considered exposed.

More details: Lockbox documentation.

Use DSPM to find potentially exposed secrets in your storage.

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

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.

Risks if the rule is not followed: Secrets stored in environment variables are visible to any cloud user with permissions to view the function or container configuration. They may also appear in audit logs, deployment pipelines, or infrastructure-as-code repositories. Using Lockbox ensures secrets are stored encrypted, access-controlled, and auditable separately from the function configuration.

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

DescriptionDescription

By default, Object Storage encrypts data at rest with a service-managed key, transparently to the user.

For buckets with sensitive data — personal data, payment data, intellectual property — it is worth using server-side encryption with a key that you control yourself, from Key Management Service. With this approach, the bucket cannot decrypt its objects without access to your KMS key, which adds an extra layer of control: revoking access to the KMS key effectively cuts off access to the data, even for cloud users with permissions on the bucket.

Risks if the rule is not followed: Without customer-managed KMS encryption, you cannot revoke access to bucket data independently of IAM permissions. If bucket access controls are misconfigured or a privileged account is compromised, the data is accessible in plaintext. Customer-managed encryption adds a second independent access control layer — the KMS key — that can be revoked or audited separately.

Instructions and solutionsInstructions and solutions

Enable server-side encryption with your KMS key for buckets with sensitive data:

1. Create a symmetric KMS key in the same folder as the bucket.
2. Enable bucket encryption with this key — for new buckets at creation, for existing buckets through bucket settings.
3. Restrict access to the key so that only the workloads that legitimately need to read the bucket have the kms.keys.encrypterDecrypter role on it.
4. Document the operational impact: rotating or disabling the key changes who can read the bucket.

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

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.

Risks if the rule is not followed: Without HTTPS, data transmitted between users and the static website is sent in plaintext, exposing it to interception and man-in-the-middle attacks. Sensitive content, session tokens, or form submissions can be captured by network attackers. Modern browsers also warn users about or block HTTP-only sites, reducing trust and availability.

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

DescriptionDescription

All managed database services in Yandex Cloud support a deletion_protection flag at the cluster level. With it enabled, attempts to delete the cluster — through the management console, CLI, API, or Terraform — fail until the flag is turned off.

Deletion protection prevents the most damaging mistake: an accidental cluster removal that destroys both the data and the configuration. Note that the flag protects only against cluster deletion as such — a user with editor-level access can still connect to the cluster and DROP data inside it, so deletion protection does not replace careful access management or backups.

Risks if the rule is not followed: Without deletion protection, a single mistaken command or a compromised account with editor rights can permanently destroy a production database cluster along with all its data. Recovery from such an event requires restoring from a backup, which takes time and may result in data loss if the backup is not current.

Instructions and solutionsInstructions and solutions

Enable deletion protection on every production database cluster:

1. In the management console, open the cluster settings of the corresponding managed database service.
2. In Advanced settings, enable Deletion protection.
3. Document who is allowed to disable the flag (for example, only members of the platform team) and review this through the CIEM module of Security Deck.
4. Make sure backup retention covers your recovery requirements — deletion protection is not a substitute for backups.

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

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.

Risks if the rule is not followed: Long-lived session cookies give attackers an extended window to use stolen credentials — a compromised cookie from an XSS or MITM attack can be used for hours or days, enabling prolonged unauthorized access to cloud resources.

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

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.

Risks if the rule is not followed: Without properly scoped security groups, Kubernetes cluster components — the API server, node ports, and internal services — may be reachable from unintended sources. This increases the attack surface and can allow an attacker who gains a foothold in the network to reach and exploit cluster components that should not be accessible.

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

DescriptionDescription

How this rule works: this rule requires manual verification of audit log collection setting.

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.

Risks if the rule is not followed: Without audit log collection at all levels, security incidents in the Kubernetes cluster cannot be detected or investigated. An attacker who escalates privileges, modifies workloads, or exfiltrates data leaves no trace that can be reviewed after the fact, making incident response and forensic analysis impossible.

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

DescriptionDescription

Managed databases in Yandex Cloud can be created with a public IP — a host that is reachable directly from the internet. With a public IP, the database listens for connections from any address; only its security group and the database's authentication stand between an attacker and the data.

For most workloads, application servers and the database run inside the same cloud network and a public IP on the database is unnecessary. Public IPs are appropriate only when the database really has to be reached from outside Yandex Cloud, and even then access should be tightly restricted at the network level.

Risks if the rule is not followed: A database with a public IP is exposed to automated scanning, brute-force attacks against database credentials, and exploitation of database engine vulnerabilities. Even with a strong password, a zero-day or a misconfigured security group can give an attacker direct access to all data stored in the database.

Instructions and solutionsInstructions and solutions

For each managed database with a public IP:

• If external access is not required, remove the public IP so that the database is reachable only from the cloud network.
• If external access is required, attach a security group that allows traffic only from a small list of trusted IP ranges and only on the database port.
• Make sure the database uses TLS for client connections and that authentication uses strong passwords or, where supported, certificates.

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

DescriptionDescription

A managed database in Yandex Cloud can be created without a security group. Without one, network access to the database depends on the network's default security group, which usually allows all traffic — anything in the cloud network (and, with a public IP, anything on the internet) can reach the database port.

Even with strong authentication in the database itself, an unrestricted network surface exposes the database to scans, brute-force attacks, and exploitation of any future vulnerability. A security group narrows this surface to a known list of clients.

Risks if the rule is not followed: Without a security group, the database port is reachable from any resource in the cloud network and potentially from the internet. This broad exposure makes the database a target for automated attacks and significantly increases the risk of unauthorized access, data exfiltration, or data destruction.

Instructions and solutionsInstructions and solutions

Attach a security group to every managed database:

1. Create a security group that allows traffic only from the IP ranges or other security groups that need to connect to the database (typically: application Pods or VMs, BI tools, administrative bastion).
2. Attach the group to the database — for an existing cluster, edit network settings; for a new cluster, set it at creation.
3. Make sure the rule covers only the database port (for example, 5432 for PostgreSQL, 3306 for MySQL) and the right protocol.

For databases with PCI DSS or personal data, additionally restrict access to the IP ranges of trusted networks only — do not leave the database reachable from the internet.

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

DescriptionDescription

How this rule works: This control automatically checks if each network interface connected to the VM has other than a default security group assigned. If an external firewall is used, please manually change the rule status.

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.

Risks if the rule is not followed: Without explicit security group rules, VMs are protected only by the default group which allows all inbound and outbound traffic. This means any internet-accessible VM is reachable on all ports, dramatically increasing the attack surface. Attackers can probe and exploit any open service on the VM without any network-level barrier.

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

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.

Risks if the rule is not followed: An overly broad security group rule exposes all services running on the VM or resource to the entire internet. Attackers can scan and exploit any open port — including administrative interfaces, databases, or internal APIs — without needing to bypass any network-level control. This is one of the most common causes of cloud security incidents.

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

DescriptionDescription

A security group in Virtual Private Cloud controls inbound and outbound network traffic for cloud objects it is attached to — virtual machines, Managed Service for Kubernetes clusters, load balancers, managed databases.

A new cloud network always has a default security group — it is created automatically and allows all inbound and outbound traffic. The default group is convenient when you start, but it does not enforce any restrictions: an object that has no other security group attached gets unrestricted network access through it.

For real workloads, create your own security groups with explicit rules — for example, only HTTP/HTTPS for a web server or only SSH from a bastion host — and attach them to objects in the network. Up to five security groups can be attached to one object.

Risks if the rule is not followed: Using only the default security group means all cloud objects in the network have unrestricted inbound and outbound traffic. Without custom security groups with explicit allow rules, there is no network-level segmentation — any compromised resource can freely communicate with all other resources in the network, and any internet-facing port is accessible to external attackers.

Instructions and solutionsInstructions and solutions

For each cloud network:

1. Create a security group with rules that allow only the protocols, ports, and source addresses that the workload really needs.
2. Attach this group to virtual machines, Kubernetes clusters, managed databases, and other objects in the network — this overrides the default group for them.
3. In rules, prefer references to other security groups over hardcoded IP addresses (in the Source/Destination field choose Security group instead of CIDR) — this keeps access rules working when IP addresses change.

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

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.

Risks if the rule is not followed: Without VPC integration, serverless functions can only access public internet endpoints — they cannot reach private cloud resources such as managed databases, internal VMs, or private API endpoints without exposing those resources to the internet. This may force teams to make internal resources publicly accessible, increasing the overall attack surface.

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

DescriptionDescription

Yandex Managed Service for YDB has two modes:

• Dedicated — a database deployed in your VPC. By default it is reachable only from the cloud network; a public endpoint can be enabled but is not required.
• Serverless — a database that is always available from the internet (the service handles routing and capacity for you). For serverless databases, the public endpoint is part of the service model and cannot be turned off.

For Dedicated databases, exposing the endpoint to the internet without a clear reason adds an unnecessary attack surface. For Serverless databases, the public endpoint should be considered when threat-modelling — access control rests entirely on database authentication and authorization.

See Serverless and Dedicated modes in the Managed Service for YDB documentation.

Risks if the rule is not followed: A publicly exposed Dedicated YDB endpoint can be targeted by brute-force attacks, vulnerability exploitation, or denial-of-service attacks directly from the internet. Without network-level restrictions, the database relies entirely on its own authentication mechanisms, which may be insufficient if credentials are weak or leaked.

Instructions and solutionsInstructions and solutions

For Dedicated databases:

• Disable the public endpoint if it is not needed; access the database only from inside the VPC.
• If the public endpoint must stay enabled, treat the database the same way as a publicly reachable workload — restrict access at the database level and monitor authentication events.

For Serverless databases:

• Apply the principle of least privilege: grant each application or user only the database roles they really need.
• Use service accounts for application connections and store their credentials in Lockbox.

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

DescriptionDescription

Yandex Audit Trails is the main tool for collecting Yandex Cloud audit logs. It records what happens to cloud resources and uploads the logs to an Object Storage bucket or a Cloud Logging log group for further analysis or export.

Audit Trails distinguishes two types of events:

• Management events — actions on cloud configuration: creating, updating, deleting infrastructure components, users, policies. Recorded by default once a trail is created.
• Data events — actions on data and resources inside services (for example, accessing objects in a bucket). Not recorded by default; need to be enabled separately for each service.

Audit Trails can be enabled at folder, cloud, or organization level. Enabling at the organization level is the recommended configuration: it gives a single, centralized stream of logs for the whole organization — typically into a separate security cloud — which is what most monitoring and compliance setups expect.

Risks if the rule is not followed: Without Audit Trails enabled at the organization level, there is no centralized record of who did what across all clouds and folders. Security incidents cannot be investigated, unauthorized changes go undetected, and compliance requirements for audit logging cannot be met. Attackers who compromise cloud accounts can operate without leaving a traceable record.

Instructions and solutionsInstructions and solutions

Enable Audit Trails at the organization level:

1. Create a trail at the organization level and choose the destination — an Object Storage bucket, a Cloud Logging log group, or a Yandex Data Streams stream.
2. For services where data events matter (IAM, KMS, Lockbox, Object Storage, Managed Service for Kubernetes, managed databases), enable data event collection on the trail.
3. Forward the destination to your SIEM or another monitoring system — see the rule "Yandex Audit Trails events are exported to a SIEM system".
4. Set up monitoring for the trail's own health (Error state, gaps in events) — see the rule "The Yandex Audit Trails service is operating properly".

For the list of important security events to look for in audit logs, see the solution library on GitHub.

Data events are monitoredData events are monitored

DescriptionDescription

How this rule works:

The rule ensures that events are monitored for the following services:

• Yandex Identity and Access Management: Creating and deleting service accounts, assigning roles, granting and revoking access permissions, creating and deleting keys, and other events.
• Yandex Certificate Manager: Creating, updating, and deleting SSL certificates, importing certificates, establishing links with resources.
• Yandex Key Management Service: Creating, rotating, and deleting encryption keys, updating access permissions to keys.
• Yandex Lockbox: Creating, updating, and deleting secrets, managing secret versions.
• Yandex Managed MySQL and Yandex Managed PostgreSQL: Creating, updating, and deleting databases and users, granting and revoking access permissions.

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.

Risks if the rule is not followed: Without data event monitoring, actions on sensitive data — such as reading secrets from Lockbox, accessing objects in Object Storage, or executing queries against managed databases — are invisible in audit logs. This makes it impossible to detect data exfiltration, unauthorized access to sensitive resources, or insider threats operating at the data level.

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

DescriptionDescription

Object Lock in Object Storage prevents object versions from being deleted or overwritten for a defined retention period. Even an account with full permissions on the bucket cannot remove a locked version until the lock expires.

For buckets that store data which must not be deleted — audit logs, financial records, evidence for an investigation, immutable backups — Object Lock is what makes the data resistant to operator mistakes, malicious actions of a compromised account, and ransomware that tries to overwrite versions.

Object Lock requires the bucket to have versioning enabled, because the lock is applied to a specific version of an object.

Retention periods are set by your information security requirements: for example, PCI DSS requires audit logs to be kept for at least one year, with at least three months immediately available.

Risks if the rule is not followed: Without Object Lock, audit logs, financial records, and other immutable data can be deleted or overwritten — whether by operator error, a compromised account, or ransomware. This undermines the integrity of audit trails, makes forensic investigation impossible after an incident, and may result in non-compliance with regulations that require tamper-proof log retention.

Instructions and solutionsInstructions and solutions

For each bucket where data must be protected from deletion:

1. Enable versioning on the bucket.
2. Enable Object Lock and choose a default retention type (GOVERNANCE or COMPLIANCE) and period that match your security requirements.
3. Optionally configure lifecycle rules to control storage class and clean-up of expired non-current versions automatically.

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

DescriptionDescription

How this rule works: this rule 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).

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

Risks if the rule is not followed: Allowing SSH (port 22), RDP (port 3389), or FTP (port 21) access from any IP address exposes cloud infrastructure to brute-force attacks, credential stuffing, and exploitation of vulnerabilities in remote access services. Attackers continuously scan the internet for open control ports and attempt unauthorized access. A single compromised VM can serve as a pivot point for lateral movement across the entire cloud environment.

Instructions and solutionsInstructions and solutions

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

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

DescriptionDescription

How this rule works: this rule 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).

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

Risks if the rule is not followed: Allowing SSH (port 22), RDP (port 3389), or FTP (port 21) access from any IP address exposes Kubernetes nodes and cluster components to brute-force attacks, credential stuffing, and exploitation of vulnerabilities in remote access services. Attackers can scan the internet for open control ports and attempt to gain unauthorized access to cluster infrastructure.

Instructions and solutionsInstructions and solutions

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

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.