[Yandex Cloud documentation](../../index.md) > [Yandex Security Deck](../index.md) > [Rule reference](index.md) > CSPM

## CSPM — Cloud Security Posture Management

Rules for checking cloud resource configuration.

### Only authorized administrators manage memberships in user groups {#user-groups-access}

#|
|| **kind** | **severity** | **ID** ||
|| manual | high | access.user-groups-access ||
|#

#### Description

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](../../organization/concepts/groups.md) 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](../../iam/concepts/access-control/roles.md) 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).

#### Guides and solutions to use

1. In the left-hand panel of the [Cloud Center interface](https://center.yandex.cloud/organization), 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](../../organization/operations/revoke-role.md) or [user group](../../organization/operations/access-manage-group.md#remove-access-binding) to take away permissions from unauthorized accounts.

### Service accounts have minimum privileges granted on the organization level {#sa-privileges-org-roles}

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

#### Description

Follow the principle of least privilege and [assign to the service account](../../iam/operations/roles/grant.md) 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`

#### Guides and solutions to use

**Guides and solutions to use:**

* Use Security Deck to [revoke](../operations/ciem/revoke-permissions.md) the service account's excessive access permissions.
* [Revoke](../../iam/operations/roles/revoke.md) the excessive permissions from the service account using IAM.

### Service accounts have minimum privileges granted on the service level {#sa-privileges-service-roles}

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

#### Description

Follow the principle of least privilege and [assign to the service account](../../iam/operations/roles/grant.md) 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`

#### Guides and solutions to use

**Guides and solutions to use:**

* Use Security Deck to [revoke](../operations/ciem/revoke-permissions.md) the service account's excessive access permissions.
* [Revoke](../../iam/operations/roles/revoke.md) the excessive permissions from the service account using IAM.

### Only trusted administrators have privileged roles {#check-privileged-roles}

#|
|| **kind** | **severity** | **ID** ||
|| manual | medium | access.check-privileged-roles ||
|#

#### Description

{% note warning "**Manual verification**" %}

This rule automatically finds accounts with any of these roles assigned:

* `billing.accounts.owner`
* `admin` assigned for a billing account
* `organization-manager.organizations.owner`
* `organization-manager.admin`
* `resource-manager.clouds.owner`
* `admin` and `editor` assigned for an organization
* `admin` and `editor` assigned for a cloud
* `admin` and `editor` assigned for a folder
* `resource-manager.clouds.editor`

This rule requires an additional manual check. Upon completion, please change the rule's status.

{% endnote %}

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.

#### Guides and solutions to use

**Guides and solutions to use:**

Check access rights for the Yandex Cloud Billing service:

1. Go to [Yandex Cloud Billing](https://center.yandex.cloud/billing/accounts).
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](https://center.yandex.cloud/organization)
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](https://console.yandex.cloud), 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 used {#labeled-resources}

#|
|| **kind** | **severity** | **ID** ||
|| manual | information | o11y.labeled-resources ||
|#

#### Description

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.

#### Guides and solutions to use

**Guides and solutions to use:**

You can add, delete, or update resource labels in the management console, Yandex Cloud CLI, and Terraform. For more infromation, read the [Managing labels](../../resource-manager/operations/manage-labels.md) guide.

### Yandex Object Storage uses bucket policies {#bucket-access-policy}

#|
|| **kind** | **severity** | **ID** ||
|| manual | high | access.bucket-access-policy ||
|#

#### Description

{% note warning "**Manual verification**" %}

This rule automatically finds buckets with no bucket policy applied.

This rule requires a manual check. Upon completion, please change the rule's status.

{% endnote %}

[Bucket policies](../../storage/concepts/policy.md) set permissions for actions with buckets, objects, and object groups. A policy applies when a user makes a request to a resource. As a result, the request is either executed or rejected.

Bucket policy [examples](../../storage/concepts/policy.md#config-examples):

* Policy that only enables object download from a specified range of IP addresses.
* Policy that prohibits downloading objects from the specified IP address.
* Policy that provides different users with full access only to certain folders, with each user being able to access their own.
* Policy that gives each user and service account full access to a folder named the same as the user ID or service account ID.

We recommend making sure that your Object Storage bucket uses at least one policy.

#### Guides and solutions to use

**Guides and solutions to use:**

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

### Cloud Backup or scheduled snapshots are used {#compute-disks}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | high | backup.compute-disks ||
|#

#### Description

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

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

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

* Scheduled snapshots
* Cloud Backup

#### Guides and solutions to use

[Backups](../../compute/concepts/backups.md) in Compute Cloud includes snapshots of disks connected to VMs and Yandex Cloud Backup usage.

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

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

For Cloud Backup to be able to back up and restore a VM, the VM must be associated with a [backup policy](../../backup/concepts/policy.md).

### Permissions to manage keys in KMS are granted to authorized users {#kms-keys-access}

#|
|| **kind** | **severity** | **ID** ||
|| manual | medium | access.kms-keys-access ||
|#

#### Description

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](../../kms/security/index.md).

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.

#### Guides and solutions to use

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

* To access Yandex Key Management Service, you need an [IAM token](../../iam/concepts/authorization/iam-token.md).
* To automate operations with KMS, we recommend that you create a [service account](../../iam/concepts/users/service-accounts.md) 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](../../compute/operations/vm-connect/auth-inside-vm.md) 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](../../iam/operations/iam-token/create-for-sa.md).
* 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](../../kms/security/index.md).

For more information about security measures for access control, see [Authentication and access control](../../security/standard/authentication.md).

### Container images used in the production environment have the last scan date of one week ago or less {#registry-recently-scan}

#|
|| **kind** | **severity** | **ID** ||
|| manual | medium | appsec.registry-recently-scan ||
|#

#### Description

Checking Docker images used in production environments with the last scan date not older than a week ensures that you continuously monitor and update security measures, eliminating potential vulnerabilities that might have occurred since the last scan. This also helps you make sure you are not deploying containers with recently detected vulnerabilities and enhance the security level. 

You can automate this process by setting up a [schedule](../../container-registry/operations/scanning-docker-image.md#scheduled).

#### Guides and solutions to use

**Guides and solutions to use:**

[Set up](../../container-registry/operations/scanning-docker-image.md#scheduled) automatically scheduled Docker images scanning for vulnerabilities

### There is no access to Kubernetes API {#api-security}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | medium | k8s.api-security ||
|#

#### Description

We do not recommend granting access to Kubernetes API from the internet. Use firewall protection where needed (for example, [security groups](../../vpc/concepts/security-groups.md)).

{% note info "**Note**" %}

This rule checks only for external IP addresses on Kubernetes clusters.

{% endnote %}

#### Guides and solutions to use

**Guides and solutions to use:**
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](../../managed-kubernetes/tutorials/k8s-cluster-with-no-internet.md).

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

* [Configure security groups for the cluster](../../managed-kubernetes/operations/connect/security-groups.md).
* Use network policy configuration tools via the [Calico](../../managed-kubernetes/concepts/network-policy.md#calico) (basic) or [Cilium CNI](../../managed-kubernetes/concepts/network-policy.md#cilium) (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](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/#:~:text=Node%20affinity%20is%20a%20property,onto%20nodes%20with%20matching%20taints) + [Node affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/)). This creates a DMZ, limiting your attack surface so that if your nodes are compromised online, the impact is minimized.
* Use an [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) resource to enable incoming network access to your workloads via HTTP/HTTPS. There are at least two controller options that you can use in Yandex Cloud:

    * [Yandex Cloud Gwin Controller](../../managed-kubernetes/alb-ref/gwin-index.md).
    * [Yandex Application Load Balancer Ingress controller](../../application-load-balancer/tools/k8s-ingress-controller/index.md).

### Managed Service for Kubernetes® uses secure configuration {#secure-configuration}

#|
|| **kind** | **severity** | **ID** ||
|| manual | medium | k8s.secure-configuration ||
|#

#### Description

{% note warning "**Manual Check**" %}

Please check if you have implemented controls for node group settings.

{% endnote %}

In Managed Service for Kubernetes, the user is fully in control of all node group settings but only partially in control of the [master](../../managed-kubernetes/concepts/index.md#master) settings. The user is responsible for the whole cluster's security.

The [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes) 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.

#### Guides and solutions to use

**Guides and solutions to use:**

* Using the [kube-bench](https://github.com/aquasecurity/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](https://blog.aquasec.com/automate-kubernetes-compliance) 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 group {#access}

#|
|| **kind** | **severity** | **ID** ||
|| manual | high | k8s.access ||
|#

#### Description

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

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

#### Guides and solutions to use

**Guides and solutions to use:**

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

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

### Security events monitoring for a Yandex Managed Service for GitLab instance in progress {#gitlab-audited}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | medium | o11y.gitlab-audited ||
|#

#### Description

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

The core log collection tool is [Yandex Audit Trails](../../audit-trails/index.md). 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](../../audit-trails/concepts/format.md), which include creating, deleting, and modifying an instance, as well as execution events and more. For more information, see the [Audit Trails reference](../../audit-trails/concepts/events.md#managed-service-for-gitlab).

#### Guides and solutions to use

**Guides and solutions to use**:

[Set up log collection](../../audit-trails/quickstart.md) using Yandex Audit Trails:

1. [Create a bucket with restricted access](../../storage/quickstart.md#the-first-bucket).
2. [Assign the required roles to the service accounts](../../audit-trails/quickstart.md#before-you-begin).
3. [Create a trail](../../audit-trails/quickstart.md#create-a-trail).

Audit Trails events in Managed Service for GitLab are [control plane events](../../audit-trails/concepts/format.md), which include creating, deleting, and modifying an instance, as well as execution events and more. For more information, see the [Audit Trails reference](../../audit-trails/concepts/events.md#managed-service-for-gitlab).

### The Yandex Audit Trails service is operating properly {#o11y-audit-trails-no-errors}

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

#### Description

The [Yandex Audit Trails](../../audit-trails/index.md) 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](../../audit-trails/concepts/trail.md) within the organization that are currently in the `Error` status.

#### Recommendations

**Guides and solutions to use:**

If a trail enters the `Error` state, create a temporary trail with the same audit log [collection scope](../../audit-trails/concepts/trail.md#collecting-area) and an appropriate [destination object](../../audit-trails/concepts/trail.md#target). This helps prevent interruptions in audit log collection and potential data loss. For more information, see [Creating a trail to upload audit logs](../../audit-trails/operations/create-trail.md).

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](https://center.yandex.cloud/support) team.

### The Kubernetes security policy is in place {#k8s-kspm}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | high | k8s.kspm ||
|#

#### Description

[Kubernetes Security Posture Management (KSPM)](../concepts/kspm.md) ensures the security of containerized applications and images they use.

The KSPM module automatically identifies all Kubernetes clusters and containers in the specified [workspace](../concepts/workspace.md), 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](../operations/workspaces/create.md) 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](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted). 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](https://kubernetes.io/docs/concepts/security/pod-security-standards/#baseline). 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](https://www.microsoft.com/en-us/security/blog/2020/04/02/attack-matrix-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](https://www.cisecurity.org/benchmark/kubernetes) for secure configuration of Kubernetes worker node components. Only automatic checks from section `4 Worker Nodes` are included.

#### Recommendations

**Guides and solutions to use:**

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

1. [Create](../../iam/operations/sa/create.md) a service account KSPM will use to view Managed Service for Kubernetes cluster info, install the necessary components, and perform checks.
2. [Assign](../../iam/operations/sa/assign-role-for-sa.md) to the service account the `security-deck.worker` [role](../security/index.md#security-deck-worker) for the organization, cloud, or folder.
3. [Create](../operations/workspaces/create.md) 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](../operations/kspm/enable-kspm.md).

### User group mapping is configured in an identity federation {#access-user-groups-mapping}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | low | access.user-groups-mapping ||
|#

#### Description

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](../../organization/operations/federation-group-mapping.md) 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.

#### Recommendations

**Guides and solutions to use:**

[Configure](../../organization/operations/federation-group-mapping.md) group mapping between your identity provider and Yandex Identity Hub.

### Only trusted administrators have access to service accounts {#access-privileged-sa-access}

#|
|| **kind** | **severity** | **ID** ||
|| manual | information | access.privileged-sa-access ||
|#

#### Description

{% note info %}

This rule automatically identifies accounts that have access rights assigned for service accounts.

{% endnote %}

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](../../iam/operations/sa/set-access-bindings.md) 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.

#### Recommendations

**Guides and solutions to use:**

Validate the access rights assigned for service accounts. The recommendation is considered satisfied if the list contains only trusted administrators. Otherwise, follow this [guide](../../iam/operations/roles/revoke.md) to revoke any excessive permissions using the Identity and Access Management service.

To manage access centrally, use the [CIEM module](https://center.yandex.cloud/security/iam-diagnostics/). Refer to the guides below for instructions:

* [Viewing a list of a subject's accesses](../operations/ciem/view-permissions.md)
* [Revoking a subject's access](../operations/ciem/revoke-permissions.md)

### Access permissions of users and service accounts are regularly audited using the Yandex Security Deck CIEM {#access-check-bindings}

#|
|| **kind** | **severity** | **ID** ||
|| manual | information | access.check-bindings ||
|#

#### Description

{% note warning "**Manual verification**" %}

The rule requires a manual check. Upon completion, please change the rule's status.

{% endnote %}

To ensure data and cloud infrastructure security, you need to regularly audit the access permissions of users and service accounts.

[Cloud Infrastructure Entitlement Management](https://center.yandex.cloud/security/iam-diagnostics/) or CIEM is a tool that provides a centralized view of the full list of access permissions for the organization's [resources](../../iam/concepts/access-control/resources-with-access-control.md), granted to [subjects](../../iam/concepts/access-control/index.md#subject): users, service accounts, [user groups](../../organization/concepts/groups.md), [system groups](../../iam/concepts/access-control/system-group.md), and [public groups](../../iam/concepts/access-control/public-group.md). The tool also makes it easy to revoke excessive access permissions from subjects.

For more information, see [Cloud Infrastructure Entitlement Management (CIEM)](../concepts/ciem.md).

#### Recommendations

**Guides and solutions to use:**

Use the [Cloud Infrastructure Entitlement Management](../concepts/ciem.md) module to centrally view all access permissions granted to individual [subjects](../../iam/concepts/access-control/index.md#subject) and groups for organization [resources](../../iam/concepts/access-control/resources-with-access-control.md), and to revoke any permissions that are excessive.

For a quick start with the CIEM module, refer to the guides below:

* [Viewing a list of a subject's accesses](../operations/ciem/view-permissions.md)
* [Revoking a subject's access](../operations/ciem/revoke-permissions.md)

### ACL by IP address is set up for Yandex Container Registry {#acl-container-registry}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | medium | access.acl-container-registry ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for ACL settings on Container Registry instances.

{% endnote %}

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

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

#### Guides and solutions

Guides and solutions to use:

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

### No public access to the Object Storage bucket {#bucket-public-access}

#|
|| **kind** | **severity** | **ID** ||
|| manual | medium | access.bucket-public-access ||
|#

#### Description

{% note warning "**Manual check**" %}

Make sure that the found buckets actually require public access. Please change the status manually.

{% endnote %}

{% note alert "**Attention**" %}

This control does not automatically check access when IAM roles are modified or when public access is specified via anonymous_access_flags. Manual verification is required.

{% endnote %}

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

Access to Object Storage resources is verified at three levels:

* [IAM verification](../../iam/concepts/index.md)
* [Bucket policy](../../storage/concepts/policy.md)
* [Access Control Lists (ACLs)](../../storage/concepts/acl.md)

**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](../../storage/concepts/acl.md#inheritance). 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](https://github.com/yandex-cloud-examples/yc-s3-secure-bucket)

#### Guides and solutions

Guides and solutions to use:

* It is recommended to assign minimum roles for a bucket using IAM and supplementing or itemizing them using a bucket policy (for example, to restrict access to the bucket by IP, grant granular permissions for objects, and so on).
* If public access is required, it is recommended to use DSPM to monitor the presence of sensitive data in buckets.

### Public IP addresses are not assigned to virtual machines {#compute-public-ip}

#|
|| **kind** | **severity** | **ID** ||
|| manual | medium | access.compute-public-ip ||
|#

#### Description

{% note warning "**Manual verification**" %}

Make sure that the found virtual machines actually require a public IP address. Manually mark the control as completed.

{% endnote %}

Virtual machines with public IP addresses are accessible from the internet. It is recommended to use public IP addresses only for resources that require direct access from the internet (e.g., NAT instances or bastion hosts). For other resources, it is recommended to use private IP addresses and organize access through VPN or bastion hosts.

#### Guides and solutions

* Make sure that virtual machines with public IP addresses actually require direct internet access.
* For resources that do not require direct internet access, use private IP addresses.
* Organize access to resources with private IP addresses through VPN or bastion hosts.

### Access from the management console is disabled in managed databases {#db-console-access}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | low | access.db-console-access ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for management console access settings on managed database clusters.

{% endnote %}

You may need access to the database from the management console to send [SQL queries](../../managed-postgresql/operations/web-sql-query.md) to the database and visualize the data structure.

We recommend that you enable this type of access only if needed, because it raises information security risks. In normal mode, use a standard DB connection as a DB user.

#### Guides and solutions

Guides and solutions to use:

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

### The setting for access from DataLens is not active if not needed {#db-datalens-access}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | low | access.db-datalens-access ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for DataLens access settings on managed database clusters.

{% endnote %}

Do not enable access to databases containing critical data from the management console, [DataLens](../../datalens/index.md), or other services unless you have to. Access from DataLens may be required for data analysis and visualization. For such access, the Yandex Cloud service network is used, with authentication and TLS encryption. You can enable and disable access from DataLens or other services in the cluster settings or when creating it in the advanced settings section.

#### Guides and solutions

Instructions and solutions for implementation:

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

### The minimum required scopes for service account API keys are defined {#defined-key-scopes}

#|
|| **kind** | **severity** | **ID** ||
|| manual | medium | access.defined-key-scopes ||
|#

#### Description

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](../../iam/concepts/authorization/api-key.md#scoped-api-keys) to restrict the use of [API keys](../../iam/concepts/authorization/api-key.md). 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: <<../../security/standard/authentication.md#api-key-scopes>>

#### Guides and solutions

**Guides and solutions to use:**

[Create](../../iam/operations/authentication/manage-api-keys.md#create-api-key) an API key with a specified scope.

### Service roles are used instead of primitive roles: admin, editor, viewer {#min-privileges}

#|
|| **kind** | **severity** | **ID** ||
|| manual | medium | access.min-privileges ||
|#

#### Description

This rule requires manual check. After checking the necessity for the privileges, please change the rule status.

The principle of least privilege (see [best practices](../../iam/best-practices/using-iam-securely.md#restrict-access)) 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 roles reference: [link](../../iam/roles-reference.md).

Use the [auditor](../../iam/roles-reference.md#auditor) role without data access wherever possible.

#### Guides and solutions

Guides and solutions to use:

* Analyze the accounts found with the admin, editor, and viewer primitive roles assigned and replace them with auditor role or service granular roles, based on your role matrix: <../../iam/roles-reference.md>
* Follow this guide to view the full list of a subject's access permissions: <../operations/ciem/view-permissions.md>

### OS Login is used for connection to a VM or Kubernetes node {#vm}

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

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for OS Login usage on virtual machines and Kubernetes nodes.

{% endnote %}

[OS Login](../../organization/concepts/os-login.md) is a convenient way to manage connections to [VMs](../../compute/concepts/vm.md) over SSH via the [CLI](../../cli/quickstart.md) 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](../../iam/concepts/users/service-accounts.md) 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](../../organization/operations/os-login-access.md) the OS Login access option at the organization level and then [activate](../../compute/operations/vm-connect/enable-os-login.md) 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.

#### Guides and solutions

Guides and solutions to use:

* [Enabling OS Login access at the organization level](../../organization/operations/os-login-access.md)
* [Setting up OS Login access on an existing VM](../../compute/operations/vm-connect/enable-os-login.md)
* [Connect to the virtual machine via OS Login](../../compute/operations/vm-connect/os-login.md)

### There is no public access to your organization's resources {#public-access}

#|
|| **kind** | **severity** | **ID** ||
|| manual | high | access.public-access ||
|#

#### Description

{% note warning "**Manual verification**" %}

This rule requires manual check. After checking the necessity for the public access, please change the rule status.

{% endnote %}

Yandex Cloud allows you to grant public access to your resources. You can grant public access by assigning access permissions to [public groups](../../iam/concepts/access-control/public-group.md) (All authenticated users, All users).

Public group details:

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

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

{% note alert "**Warning**" %}

Now `All users` is only supported in the following services: Object Storage (if ACL-based access management is used), Container Registry, and Cloud Functions. For other services, assigning a role to the `All users` group is equivalent to assigning a role to `All authenticated users`.

{% endnote %}

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

#### Guides and solutions

Guides and solutions to use:

* If you detect that All users and All authenticated users have the access permissions that they should not have, remove these permissions using [CIEM module](../concepts/ciem.md).

### Service accounts have minimum privileges granted {#sa-privileges}

#|
|| **kind** | **severity** | **ID** ||
|| manual | high | access.sa-privileges ||
|#

#### Description

{% note warning "**Manual verification**" %}

This rule requires manual check. After auditing the required privileges, please change the rule status.

{% endnote %}

Follow the principle of least privilege and [assign to the service account](../../iam/operations/roles/grant.md) only the roles necessary to run the application.

#### Guides and solutions

**Guides and solutions to use:**

* Use Yandex Security Deck to [view](../operations/ciem/view-permissions.md) the full list of a service account's access permissions.
* Use Security Deck to [revoke](../operations/ciem/revoke-permissions.md) the service account's excessive access permissions.
* [Remove](../../iam/operations/roles/revoke.md) the excessive permissions from the service account using IAM.

### The serial console is either controlled or not used {#serial-console}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | medium | access.serial-console ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for serial console access on virtual machines.

{% endnote %}

On VMs, access to the serial console is disabled by default. For risks of using the serial console, see [Getting started with a serial console](../../compute/operations/serial-console/index.md) in the Yandex Compute Cloud documentation.

When working with a serial console:

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

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

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

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

[Do not forget to disable access](../../compute/operations/serial-console/index.md) after working with the serial console.

#### Guides and solutions

Guides and solutions to use:

* It is recommended to disable access to the serial console: <../../compute/operations/serial-console/index.md>

### In Yandex Application Load Balancer, HTTPS is used {#alb-https}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | high | appsec.alb-https ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for HTTPS listener settings on Application Load Balancer.

{% endnote %}

[Application Load Balancer service](../../application-load-balancer/index.md) supports an HTTPS listener with loading a [certificate](../../certificate-manager/concepts/imported-certificate.md) from Certificate Manager. See the [listener configuration description](../../application-load-balancer/concepts/application-load-balancer.md#listener) in the Yandex Application Load Balancer documentation.

#### Guides and solutions

* [Enable the HTTPS listener according to the instructions](../../application-load-balancer/tutorials/tls-termination/index.md)

### API gateways use HTTPS and their own domains {#api-gateway-https}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | medium | appsec.api-gateway-https ||
|#

#### Description

[Yandex API Gateway](../../api-gateway/index.md) ensures secure connections over HTTPS. You can link your own domain and upload your own [security certificate](../../certificate-manager/concepts/index.md#types) to access your [API gateway](../../api-gateway/concepts/index.md) over HTTPS.

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

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

#### Guides and solutions

Guides and solutions to use:

1. In the [management console](https://console.yandex.cloud/), select the folder the API gateway is in.
1. [Go](../../console/operations/select-service.md#select-service) to API Gateway and in the window that opens, click the line with the API gateway in question.
1. In the left-hand menu, select **Domains** and click **Attach**.
1. In the window that opens, select a TLS certificate and specify the domain name matching this certificate.
1. Click **Attach**.

### Yandex Cloud CDN uses HTTPS and its own SSL certificate {#cdn-https}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | low | appsec.cdn-https ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for HTTPS configuration and SSL certificates on CDN resources.

{% endnote %}

[Cloud CDN](../../cdn/index.md) supports secure connections to origins over HTTPS. You can also upload your own security certificate to access your [CDN resource](../../cdn/concepts/resource.md) over HTTPS.

#### Guides and solutions

Guides and solutions to use:

* [Enable a certificate and HTTPS using the instructions](../../cdn/operations/resources/configure-basics.md)

### Application DDoS protection is enabled (L7) {#l7}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | high | appsec.ddos-protection.l7 ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks Smart Web Security security profiles for ALB.

{% endnote %}

{% note warning "**Manual verification**" %}

If an external DDoS protection software is used, please change the status manually.

{% endnote %}

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](../../smartwebsecurity/quickstart.md) is a service for protection against DDoS attacks and bots at application level L7 of the [OSI model](https://en.wikipedia.org/wiki/OSI_model). Smart Web Security [connects](../../smartwebsecurity/quickstart.md) to Yandex Application Load Balancer. In a nutshell, the service checks the HTTP requests sent to the protected resource against the [rules](../../smartwebsecurity/concepts/rules.md) configured in the [security profile](../../smartwebsecurity/concepts/profiles.md). Depending on the results of the check, the requests are forwarded to the protected resource, blocked, or sent to [Yandex SmartCaptcha](../../smartcaptcha/index.md) for additional verification.

[Yandex DDoS Protection](../../vpc/ddos-protection/index.md) 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](../../vpc/concepts/address.md) through cloud administration tools. Supported up to OSI L4.

[Advanced](https://yandex.cloud/en/services/ddos-protection) 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.

#### Guides and solutions

Guides and solutions to use:

* [How to create a security profile in Smart Web Security](../../smartwebsecurity/operations/profile-create.md)
* [Webinar: DDoS Protection in Yandex Cloud](https://youtu.be/KWGbLQTth5U)

### Network DDoS protection is enabled (L3) {#appsec-ddos-protection-l3}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | high | appsec.ddos-protection.l3 ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks Yandex DDoS Protection security profiles. If an external DDoS protection software is used, please change the status manually.

{% endnote %}

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

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

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

To prevent such attacks, DDoS Protection:

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

[Advanced DDoS protection](https://yandex.cloud/en/services/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.

#### Recommendations

**Guides and solutions to use:**

Use [Yandex DDoS Protection](https://yandex.cloud/en/services/ddos-protection) to protect your cloud resources against DDoS attacks on basic level. You can [enable DDoS Protection](../../vpc/operations/enable-ddos-protection.md) with a single click: just select the **DDoS protection** checkbox when creating your VM and reserving public IP addresses.

Enable and set up advanced DDoS protection at OSI layers 3, 4, and 7. To enable advanced protection, [contact support](https://center.yandex.cloud/support/tickets) or fill out [this form](https://yandex.cloud/en/services/ddos-protection#contact-form).

### Docker images are scanned when uploaded to Container Registry {#periodic-scan}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | high | appsec.periodic-scan ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for Docker image scanning policies in Container Registry.

{% endnote %}

When creating a new [registry](../../container-registry/concepts/registry.md), use the default options to make sure it meets the Yandex Cloud security standard:

* Docker images are automatically scanned as they are uploaded to the registry.

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

**How to manually check rule:**

1. In the [management console](https://console.yandex.cloud/), select the folder the registry with Docker images belongs to.

2. Select the appropriate registry in **Container Registry**.

3. Navigate to the **Vulnerability scanner** tab and click **Edit settings**.

4. Make sure that scheduled Docker image scans are enabled with a frequency of at least once a week.

#### Guides and solutions

Guides and solutions to use:

* [Guide on scheduled scanning of Docker images](../../container-registry/operations/scanning-docker-image.md#scheduled)

### Advanced rate limiter is implemented {#use-arl}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | medium | appsec.use-arl ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for Advanced Rate Limiter configuration.

{% endnote %}

{% note warning "**Manual Check**" %}

This rule checks only the built-in information security features in Yandex Cloud. If an applied protection is used, please manually mark the rule as completed.

{% endnote %}

[Advanced Rate Limiter (ARL)](../../smartwebsecurity/concepts/arl.md) 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](../../smartwebsecurity/concepts/profiles.md) in Smart Web Security.

#### Guides and solutions

Guides and solutions to use:

* [Creating an ARL profile and connecting it to a security profile in Smart Web Security](../../smartwebsecurity/quickstart.md#arl)

### Yandex SmartCaptcha is used {#use-smartcaptcha}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | low | appsec.use-smartcaptcha ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for Yandex SmartCaptcha usage in applications.

{% endnote %}

To mitigate the risks associated with automated attacks on applications, we recommend using [Yandex SmartCaptcha](https://yandex.cloud/en/services/smartcaptcha). The service checks user requests with its ML algorithms and only shows challenges to those users whose requests it considers suspicious. You do not have to place the "I'm not a robot" button on the page.

#### Guides and solutions

Guides and solutions to use:

* [Yandex SmartCaptcha service](https://yandex.cloud/en/services/smartcaptcha)

### Yandex Smart Web Security profile is used {#use-sws}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | high | appsec.use-sws ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for Yandex Smart Web Security profile configuration.

{% endnote %}

[Yandex Smart Web Security](../../smartwebsecurity/quickstart.md) protects you against DDoS attacks, web attacks, and bots at application level L7 of the [OSI model](https://en.wikipedia.org/wiki/OSI_model). Smart Web Security [connects](../../smartwebsecurity/quickstart.md) to Yandex Application Load Balancer.

In a nutshell, the service checks the HTTP requests sent to the protected resource against the [rules](../../smartwebsecurity/concepts/rules.md) configured in the [security profile](../../smartwebsecurity/concepts/profiles.md). Depending on the results of the check, the requests are forwarded to the protected resource, blocked, or sent to [Yandex SmartCaptcha](../../smartcaptcha/index.md) for additional verification.

{% note warning "**Manual Check**" %}

This rule checks only the built-in information security features in Yandex Cloud. If an applied protection is used, please manually mark the rule as completed.

{% endnote %}

#### Guides and solutions

Guides and solutions to use:

* [Creating a security profile and connecting it to a virtual host of an L7 load balancer](../../smartwebsecurity/quickstart.md)

### Web application firewall is implemented {#use-waf}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | medium | appsec.use-waf ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for Web Application Firewall configuration.

{% endnote %}

{% note warning "**Manual Check**" %}

This rule checks only the built-in information security features in Yandex Cloud. If an applied protection is used, please manually mark the rule as completed.

{% endnote %}

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](../../smartwebsecurity/concepts/rules.md#rule-action) are applied to HTTP requests.

You can manage the web application firewall using a [WAF profile](../../smartwebsecurity/concepts/waf.md) that connects to a [security profile](../../smartwebsecurity/concepts/profiles.md) in Smart Web Security as a separate [rule](../../smartwebsecurity/concepts/rules.md).

#### Guides and solutions

Guides and solutions to use:

* [Creating a WAF profile and connecting it to a security profile in Smart Web Security](../../smartwebsecurity/quickstart.md#waf)

### When creating a registry in Yandex Container Registry, keep the safe registry settings by default {#secure-registry}

#|
|| **kind** | **severity** | **ID** ||
|| manual | medium | appsec.secure-registry ||
|#

#### Description

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

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

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

#### Guides and solutions to use

1. In the [management console](https://console.yandex.cloud/), select the folder where you want to create a registry.
2. Go to Container Registry.
3. Click **Create registry**.
4. Specify a name for the registry. Follow these naming requirements:

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

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

### Getting an IAM token through the metadata service in AWS IMDSv1 format is disabled on the VM {#aws-token}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | high | aws-token ||
|#

#### Description

Yandex Compute Cloud features a [metadata service](../../compute/concepts/vm-metadata.md) 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](https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/).

#### Guides and solutions to use

To [get](../../compute/operations/vm-metadata/get-vm-metadata.md#example5) a service account's IAM token from within the VM, we recommend using metadata in Google Compute Engine format.

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

**Guides and solutions to use**:

For the VMs found in the `metadata_options` section, set [aws_v1_http_token](../../compute/api-ref/grpc/Instance/update.md#yandex.cloud.compute.v1.MetadataOptions) to `DISABLED`:

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

### Cloud Backup or scheduled snapshots are used {#compute-disks}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | high | backup.compute-disks ||
|#

#### Description

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

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

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

* Scheduled snapshots
* Cloud Backup

#### Guides and solutions to use

[Backups](../../compute/concepts/backups.md) in Compute Cloud includes snapshots of disks connected to VMs and Yandex Cloud Backup usage.

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

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

For Cloud Backup to be able to back up and restore a VM, the VM must be associated with a [backup policy](../../backup/concepts/policy.md).

### The Yandex Certificate Manager certificate is valid for at least 30 days {#certificate-validity}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | medium | crypto.certificate-validity ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks certificate validity periods in Yandex Certificate Manager.

{% endnote %}

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](https://letsencrypt.org/docs/faq/#what-is-the-lifetime-for-let-s-encrypt-certificates-for-how-long-are-they-valid).

#### Guides and solutions

* Update the certificate or setup auto updates.
* [We recommend that you update certificates in advance if they are not updated automatically](../../certificate-manager/concepts/challenges.md#auto)

### Deletion protection is enabled for KMS keys {#keys-deletion-protection}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | high | crypto.keys-deletion-protection ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for deletion protection settings on KMS keys.

{% endnote %}

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

#### Guides and solutions

* Enable deletion protection: <https://yandex.cloud/en/docs/kms/operations/key#update>

### The Key Management Service keys are stored in the hardware Security module(HSM) {#keys-hsm}

#|
|| **kind** | **severity** | **ID** ||
|| manual | medium | crypto.keys-hsm ||
|#

#### Description

{% note warning "**Manual check**" %}

This rule requires manual verification of HSM key storage settings.

{% endnote %}

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) <https://yandex.cloud/en/docs/kms/concepts/hsm>.

To use the HSM, when creating a key, select AES-256 HSM as the algorithm type. The HSM will handle all operations with this key internally, and no additional actions are required.

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

#### Guides and solutions

* Set the encryption algorithm for KMS keys to AES-256 HSM: <https://yandex.cloud/en/docs/kms/operations/symmetric-encryption>

### Key rotation is enabled for KMS keys {#keys-rotation}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | high | crypto.keys-rotation ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for key rotation settings on KMS keys.

{% endnote %}

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

* Keys for services that process critical data but do not store it, such as Message Queue or Cloud Functions.

* Keys for services storing critical data, e.g., Managed Services for Databases.

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

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

A secure value for AES-GCM mode is encryption using 4294967296 (= 2^32^) blocks. Having reached this number of encrypted blocks, you need to create a new DEK version. For more information about the AES-GCM operating mode, see the [NIST materials](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf).

{% note alert "**Note**" %}

Destroying any version of a key means destroying all data encrypted with it. You can protect a key against deletion by setting the deletionProtection parameter. However, it does not protect against deleting individual versions.

{% endnote %}

For more information about key rotation, see the [KMS documentation, Key version](../../kms/concepts/version.md).

#### Guides and solutions

* [Set the key rotation period](../../kms/concepts/version.md)

### Encryption of disks and virtual machine snapshots is used {#managed-vm-kms}

#|
|| **kind** | **severity** | **ID** ||
|| manual | medium | crypto.managed-vm-kms ||
|#

#### Description

{% note warning "**Manual check**" %}

This rule requires manual verification of disk encryption settings.

{% endnote %}

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](../../compute/concepts/snapshot.md) using [Yandex Key Management Service custom symmetric keys](../../kms/concepts/key.md). 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](../../kms/operations/key.md).

* 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](../../kms/operations/key-access.md).

* Use Yandex Audit Trails to track encryption and decryption operations performed using your KMS key. For more information, see [Key usage audit](../../kms/concepts/index.md#keys-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`)

#### Guides and solutions

* [Encrypt the disk of your Yandex Compute Cloud VM](../../compute/operations/disk-control/disk-encrypt.md)

### Service account keys are rotated on a regular basis {#sa-key-rotation}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | high | crypto.sa-key-rotation ||
|#

#### Description

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

* [IAM tokens](../../iam/concepts/authorization/iam-token.md) that are valid for 12 hours.
* [API keys](../../iam/concepts/authorization/api-key.md): You can choose any validity period.
* [Authorized keys](../../iam/concepts/authorization/key.md) with unlimited validity.
* [AWS API-compatible static access keys](../../iam/concepts/authorization/access-key.md) 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.

#### Guides and solutions

Follow the [guide](../../iam/operations/compromised-credentials.md#key-reissue) for rotating keys depending on their type.

### The organization uses Yandex Lockbox for secure secret storage {#secrets-lockbox}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | low | crypto.secrets-lockbox ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for the use of Yandex Lockbox for secret storage.

{% endnote %}

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

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

{% note alert "**Note**" %}

When working in Terraform, we recommend using a script to [fill in](https://terraform-provider.yandexcloud.net/Resources/lockbox_secret_version) the contents of a secret. This ensures that its contents do not remain in the `.tfstate` file.

{% endnote %}

#### Guides and solutions

* You can learn how to use the service in the Lockbox documentation: <../../lockbox/index.md>

### Lockbox secrets are used for Serverless Containers and Cloud Functions {#secrets-serverless}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | medium | crypto.secrets-serverless ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for the use of Lockbox secrets in serverless functions and containers.

{% endnote %}

When working with Serverless Containers or Cloud Functions, it is often necessary to use a secret (such as a token or password).

If you specify secret information in environment variables, it can be viewed by any cloud user with permissions to view and use a function, which causes information security risks.

We recommend using Serverless integration with Lockbox for that. You can use a specific secret from Yandex Lockbox and a service account with access rights to this secret to use it in a function or container.

Make sure that the secrets are used as described above.

#### Guides and solutions

* Delete secret data from env and use the Lockbox integration functionality:
  * Transmitting Yandex Lockbox secrets to a container: <https://yandex.cloud/en/docs/serverless-containers/operations/lockbox-secret-transmit>
  * Transmitting Yandex Lockbox secrets to a function: <https://yandex.cloud/en/docs/functions/operations/function/lockbox-secret-transmit>

### At-rest encryption with a KMS key is enabled in Yandex Object Storage {#object-storage-encryption}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | medium | data.object-storage-encryption ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for encryption settings on Object Storage buckets.

{% endnote %}

To protect critical data in Yandex Object Storage, we recommend using bucket server-side encryption with Yandex Key Management Service keys. This encryption method protects against accidental or intentional publication of the bucket content on the web. For more information, see [Encryption](../../storage/concepts/encryption.md) in the Object Storage documentation.

#### Guides and solutions

* It is recommended to enable data encryption for buckets with critical data: <../../tutorials/security/server-side-encryption.md>

### HTTPS for static website hosting is enabled in Yandex Object Storage {#storage-https}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | high | data.storage-https ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for HTTPS settings on Object Storage static websites.

{% endnote %}

[Object Storage](../../storage/index.md) 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](../../certificate-manager/index.md) is also supported. See the instructions in the Object Storage documentation:

* Configuring [HTTPS](../../storage/operations/hosting/certificate.md)
* [Bucket](../../storage/concepts/bucket.md)

When using [Object Storage](../../storage/index.md), make sure that support for TLS protocols below version 1.2 is disabled at the client level. Use the aws:[securetransport](../../storage/s3/api-ref/policy/conditions.md) bucket policy to make sure running without TLS is disabled for the bucket.

#### Guides and solutions

* Enable access over HTTPS if the bucket is used to host a static website: <../../storage/operations/hosting/certificate.md>

### Deletion protection is enabled {#db-deletion-protection}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | low | db.db-deletion-protection ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for deletion protection on managed database clusters.

{% endnote %}

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

#### Guides and solutions

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

### The cookie lifetime timeout in the federation is less than 6 hours {#cookie-timeout-organization}

#|
|| **kind** | **severity** | **ID** ||
|| manual | high | cookie-timeout.organization ||
|#

#### Description

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.

#### Guides and solutions to use

In your [identity federation](../../organization/concepts/add-federation.md) 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.

### Managed Service for Kubernetes uses secure configuration {#kubernetes-safe-config}

#|
|| **kind** | **severity** | **ID** ||
|| manual | medium | k8s.kubernetes-safe-config ||
|#

#### Description

{% note warning "**Manual check**" %}

Please check if you have implemented controls for node group settings.

{% endnote %}

In Managed Service for Kubernetes, the user is fully in control of all node group settings, but only partially in control of the [master](../../managed-kubernetes/concepts/index.md#master) settings. The user is responsible for the whole cluster's security.

The [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes) 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.

#### Guides and solutions

* Using the [kube-bench](https://github.com/aquasecurity/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](https://blog.aquasec.com/automate-kubernetes-compliance) 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.

### Access to Kubernetes components is limited by IP address, port, and protocol {#k8s-network-firewall-scope}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | medium | k8s.network-firewall-scope ||
|#

#### Description

We recommend using [security groups](../../vpc/concepts/security-groups.md) 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.

#### Guides and solutions to use

[Create](../../vpc/operations/security-group-create.md) a security group and [configure](../../managed-kubernetes/operations/connect/security-groups.md) 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](../../managed-kubernetes/concepts/index.md#master)
    * Kubernetes [nodes](../../managed-kubernetes/concepts/index.md#node-group)
    * [Load balancers](../../application-load-balancer/concepts/application-load-balancer.md) and [ingress controllers](../../application-load-balancer/tools/k8s-ingress-controller/index.md)
    * Databases and backends
    * [Bastion hosts](../../tutorials/routing/bastion.md)
* 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](../../security/domains/kubernetes.md#flow-logs-kubernetes) to monitor traffic.

### Audit log collection is set up for incident investigation {#network-policy}

#|
|| **kind** | **severity** | **ID** ||
|| manual | high | k8s.network-policy ||
|#

#### Description

{% note warning "**Manual check**" %}

This rule requires manual verification of audit log collection setting.

{% endnote %}

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](../../security/domains/kubernetes.md#collection-monitoring-analysis-audit-logs).

#### Guides and solutions to use

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](https://console.yandex.cloud/), and go to the **Access management** tab.

You can also use:

* [KubiScan](https://github.com/cyberark/KubiScan)
* [Krane](https://github.com/appvia/krane)
* Yandex Audit Trails [audit logs](../../managed-kubernetes/at-ref.md)

### Only authorized administrators manage memberships in user groups {#group-membership-admin}

#|
|| **kind** | **severity** | **ID** ||
|| manual | high | iam.group-membership-admin ||
|#

#### Description

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](../../organization/concepts/groups.md) 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](../../iam/concepts/access-control/roles.md) 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).

#### Guides and solutions to use

1. In the left-hand panel of the [Cloud Center interface](https://center.yandex.cloud/organization), 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](../../organization/operations/revoke-role.md) or [user group](../../organization/operations/access-manage-group.md#remove-access-binding) to take away permissions from unauthorized accounts.

### A security group is assigned in managed databases {#db-ip}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | high | network.db-ip ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for security group assignment on managed database clusters.

{% endnote %}

We recommend prohibiting internet access to databases that contain critical data, in particular PCI DSS data or private data. Configure security groups to only allow connections to the DBMS from particular IP addresses. To do this, follow the steps in [Creating a security group](../../vpc/operations/security-group-create.md). You can specify a security group in the cluster settings or when creating the cluster in the network settings section.

#### Guides and solutions

* [It is recommended to set up a security group for the database cluster](../../vpc/concepts/security-groups.md)

### No public IP address is assigned in managed databases {#db-security-group}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | medium | network.db-security-group ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for public IP address assignment on managed database clusters.

{% endnote %}

Assigning a public IP to a managed database raises information security risks. We do not recommend assigning an external IP unless it is absolutely necessary.

Remove public access if it is not required.

#### Guides and solutions

* It is recommended to delete the IP address linked to the database: <https://yandex.cloud/en/docs/vpc/operations/address-delete>

### Cloud resources are protected by a firewall or security groups {#firewall}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | high | network.firewall ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks security groups availability for the following types of resources:
`enum <resource-type>`

{% endnote %}

{% note warning "**Manual verification**" %}

This rule requires manual check. After checking and update, please change the rule status.

{% endnote %}

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](../../vpc/operations/security-group-create.md). You can specify a security group in the VM settings.

You can use security groups to protect:

* VM
* Managed databases: <https://yandex.cloud/en/services#data-platform>
* Yandex Application Load Balancer: <../../application-load-balancer/index.md>
* Yandex Managed Service for Kubernetes: <../../managed-kubernetes/index.md>

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: <../../compute/operations/image-create/upload.md>

#### Guides 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: <https://github.com/yandex-cloud/yc-solution-library-for-security/tree/master/network-sec/segmentation>
* To use the NGFW, install the NGFW on your VM: Check Point: <https://github.com/yandex-cloud/yc-solution-library-for-security/tree/master/network-sec/checkpoint-1VM>
* Refer to this guide on using the UserGate NGFW in the cloud: <https://docs.google.com/document/d/1yYwHorzkwXwIUGeG3n_K6Zo-07BVYowZJL7q2bAgVR8/edit?usp=sharing>
* Use NGFW in active-passive mode: <https://github.com/yandex-cloud/yc-solution-library-for-security/blob/master/network-sec/checkpoint-2VM_active-active/README.md>

### Security groups have no access rule that is too broad {#network-firewall-scope}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | high | network.network-firewall-scope ||
|#

#### Description

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

{% note warning %}

If no port range is set, it is considered that access is granted across all ports (0-65535).

{% endnote %}

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

#### Guides and solutions

* Delete the dangerous rule in each security group or edit it by specifying trusted IPs: <https://yandex.cloud/en/docs/vpc/operations/security-group-create>

### In Virtual Private Cloud, a security group is created; the default security group is not used {#network-firewall}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | medium | network.network-firewall ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for the presence of custom security groups in VPC networks.

{% endnote %}

A security group (SG) is a resource created at the [cloud network level](../../vpc/concepts/network.md#network). Once created, a [security group](../../vpc/concepts/security-groups.md) can be used in [Yandex Cloud services](../../vpc/concepts/security-groups.md#security-groups-apply) to control network access to an object it applies to.

A default security group (DSG) is created automatically while creating a new [cloud network](../../vpc/concepts/network.md#network). The default security group has the following properties:

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

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

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

We recommend you to [create](../../vpc/operations/security-group-create.md) a security group of your own with [rules](../../vpc/concepts/security-groups.md#security-groups-rules) explicitly allowing only the traffic you need (e.g., HTTP/HTTPS for web servers or SSH for administration) and assign this group to your [cloud objects](../../vpc/concepts/security-groups.md#security-groups-apply) [VMs](../../compute/concepts/vm.md), [Kubernetes clusters](../../managed-kubernetes/concepts/index.md#kubernetes-cluster), etc.) to override the DSG.

This is important because without your rules cloud resources remain open to all and any connections from the internet, whereas security groups of your own enable the principle of [least privilege](../../iam/best-practices/using-iam-securely.md#restrict-access), thus reducing the attack surface.

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

#### Guides and solutions

* [Create](../../vpc/operations/security-group-create.md) a security group in each Virtual Private Cloud with restricted access rules, so that it can be assigned to cloud objects.

### Serverless Containers/Cloud Functions uses the VPC internal network {#serverless-uses-vpc}

#|
|| **kind** | **severity** | **ID** ||
|| manual | information | network.serverless-uses-vpc ||
|#

#### Description

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.

#### Guides and solutions to use

1. In the [management console](https://console.yandex.cloud/), 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 YDB {#ydb-public}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | low | network.ydb-public ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for public access settings on YDB clusters.

{% endnote %}

When accessing the database in dedicated mode, we recommend that you use it inside VPC and disable public access to it from the internet. In serverless mode, the database can be accessed from the internet. You must therefore take this into account when modeling threats to your infrastructure. For more information about the operating modes, see the [Serverless and dedicated modes](../../ydb/concepts/serverless-and-dedicated.md) section in the Managed Service for YDB documentation.

When setting up database permissions, use the principle of least privilege.

#### Guides and solutions

* For more information about the operating modes, see the Serverless and dedicated modes section in the Managed Service for [YDB documentation](../../ydb/concepts/serverless-and-dedicated.md)
* When setting up database permissions, use the principle of least privilege.

### Yandex Audit Trails is enabled at the organization level {#audit-trails}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | high | o11y.audit-trails ||
|#

#### Description

{% note tip "**Automatic verification**" %}

This control automatically checks for Yandex Audit Trails service configuration at the organization level.

{% endnote %}

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

Audit Trails audit logs may contain two types of events: [management events](../../audit-trails/concepts/events.md) and [data events](../../audit-trails/concepts/events-data-plane.md).

[Management events](../../audit-trails/concepts/format.md) are actions you take to configure Yandex Cloud resources, such as creating, updating, or deleting infrastructure components, users, or policies. [Data events](../../audit-trails/concepts/format-data-plane.md) are updates and actions performed on data and resources within Yandex Cloud services. By default, Audit Trails does not log data events. You need to [enable](../../audit-trails/quickstart.md#the-trail-creation) collection of data event audit logs individually for each supported service.

To learn more, see [Comparing management and data event logs](../../audit-trails/concepts/control-plane-vs-data-plane.md).

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

You can also use Monitoring to monitor the health of the Audit Trails service itself and track security events. You can export metrics to a SIEM system via the API, see this [guide](../../monitoring/operations/metric/get.md).

Solution: Monitoring Audit Trails and security events using [Monitoring](https://github.com/yandex-cloud-examples/yc-audit-trails-monitoring)

You can export audit logs to [Cloud Logging](../../logging/index.md) or Data Streams log group and to a customer's SIEM system to analyze information about events and incidents.

List of important Yandex Cloud-level events to search for in audit logs:

Solution: Searching for important security events in [audit logs](https://github.com/yandex-cloud/yc-solution-library-for-security/tree/master/auditlogs/_use_cases_and_searches)

#### Guides and solutions

* You can enable Yandex Audit Trails at the folder, cloud, and organization level. We recommend enabling Yandex Audit Trails at the level of the entire organization. Thus you will be able to collect audit logs in a centralized manner, e.g., to a separate [security cloud](../../audit-trails/operations/index.md)

### Data events are monitored {#data-plane-events}

#|
|| **kind** | **severity** | **ID** ||
|| manual | medium | o11y.data-plane-events ||
|#

#### Description

A [data event audit log](../../audit-trails/concepts/format-data-plane.md) 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](../../storage/concepts/bucket.md).

You need to enable collection of data event audit logs individually for each [supported service](../../audit-trails/concepts/control-plane-vs-data-plane.md#data-plane-events).

#### Guides and solutions to use

We recommend to choose **Get all events** for [Yandex Identity and Access Management](../../audit-trails/concepts/events-data-plane.md#iam) and [Yandex Cloud DNS](../../audit-trails/concepts/events-data-plane.md#dns), as well as for the following services if used:

* [Yandex Certificate Manager](../../audit-trails/concepts/events-data-plane.md#certificate-manager)
* [Yandex Compute Cloud](../../audit-trails/concepts/events-data-plane.md#compute)
* [Yandex Key Management Service](../../audit-trails/concepts/events-data-plane.md#kms)
* [Yandex Lockbox](../../audit-trails/concepts/events-data-plane.md#lockbox)
* [Yandex Managed Service for ClickHouse®](../../audit-trails/concepts/events-data-plane.md#mch)
* [Yandex Managed Service for Kubernetes®](../../audit-trails/concepts/events-data-plane.md#managed-service-for-kubernetes)
* [Yandex StoreDoc](../../audit-trails/concepts/events-data-plane.md#mmg)
* [Yandex Managed Service for MySQL®](../../audit-trails/concepts/events-data-plane.md#mmy)
* [Yandex Managed Service for PostgreSQL](../../audit-trails/concepts/events-data-plane.md#mpg)
* [Yandex Managed Service for Valkey™](../../audit-trails/concepts/events-data-plane.md#mrd)
* [Yandex Object Storage](../../audit-trails/concepts/events-data-plane.md#objstorage)
* [Yandex Smart Web Security](../../audit-trails/concepts/events-data-plane.md#sws)
* [Yandex WebSQL](../../audit-trails/concepts/events-data-plane.md#websql)

### The Object lock feature is enabled in Object Storage {#used-object-lock}

#|
|| **kind** | **severity** | **ID** ||
|| manual | medium | s3.used-object-lock ||
|#

#### Description

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

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

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

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

#### Guides and solutions to use

For more information about setting up versioning, see [Bucket versioning](../../storage/concepts/versioning.md) in the Object Storage guide.

For more information about lifecycles, see [Bucket object lifecycles](../../storage/concepts/lifecycles.md) and [Bucket object lifecycle configuration](../../storage/s3/api-ref/lifecycles/xml-config.md) in the Object Storage guide.

In addition, to protect object versions against deletion, use [object locks](../../storage/concepts/object-lock.md). For more information about object lock types and how to enable them, refer to the guide.

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

### Access through control ports is only allowed for trusted IPs {#trusted-ip}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | medium | trusted-ip ||
|#

#### Description

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

This check displays a list of all [security groups](../../vpc/concepts/security-groups.md) 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).

#### Guides and solutions to use

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

**Guides and solutions to use**:

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

1. In the [management console](https://console.yandex.cloud/), select the folder where your security group resides.
2. [Go](../../console/operations/select-service.md#select-service) 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 IPs {#trusted-ip-k8s}

#|
|| **kind** | **severity** | **ID** ||
|| automatic | medium | trusted-ip-k8s ||
|#

#### Description

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

This check displays a list of all [security groups](../../vpc/concepts/security-groups.md) 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).

#### Guides and solutions to use

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

**Guides and solutions to use**:

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

1. In the [management console](https://console.yandex.cloud/), select the folder where your security group resides.
2. [Go](../../console/operations/select-service.md#select-service) 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.