Contact UsGet started
© 2024 Iron Hive LLC Belgrade

1. Authentication and access management

Written by
Improved by
Updated at November 20, 2024

In Yandex Cloud, identification, authentication, and access control is performed by Yandex Identity and Access Management (IAM) and Yandex Cloud Organization.

The platform works with three categories of users:

Yandex ID and federated accounts are authenticated in their own systems. Yandex Cloud has no access to the passwords of these account users and only authenticates service accounts using IAM.

User access to cloud resources is regulated by roles. Yandex Cloud services may provide different levels of granularity while granting permissions: in some cases, a role can be assigned directly to a service resource, in other cases, permissions are only granted at the level of the folder or cloud where the service resource is located.

This ensures interaction of different categories of resources, roles, and users in the Yandex Cloud infrastructure. Access to resources is managed by IAM. IAM controls each request and makes sure that all operations with resources are only run by users who have the appropriate permissions.

1.1 An identity federation (single sign-on, SSO) is configured

Yandex Cloud Organization is a single service for managing the organizational structure, setting up integration with the employee catalog, and differentiating user access to the organization's cloud resources.

For the purpose of centralized account management, use SAML-compatible identity federations. By using identity federations, a company can set up Single Sign-On, which is authentication in Yandex Cloud via their IdP server. With this approach, employees can use their corporate accounts that are subject to the company's security policies, such as:

  • Revoking and blocking accounts.
  • Password policies.
  • Limiting the number of unsuccessful login attempts.
  • Blocking access sessions upon expiry of a preset user's idle time.
  • Two-factor authentication.

Tip

Use federated accounts instead of Yandex ID accounts whenever possible. Keep in mind that there is a separate role, organization-manager.federations.admin, you can use to manage a federation.

To make sure all authentication requests from Yandex Cloud contain a digital signature, enable the Sign authentication requests option. To complete the configuration, download and install a Yandex Cloud certificate. You can download the certificate in the Sign authentication requests field immediately after creating a federation.

  1. Open the Yandex Cloud console in your browser.
  2. Go to All services → Yandex Cloud Organization → Federations.
  3. Make sure the list contains at least one identity federation configured. Otherwise, proceed to the Guides and solutions to use.

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. View information about the federations configured:

    yc organization-manager federation saml list \
  --organization-id=<organization ID>

  3. Make sure the list contains at least one identity federation configured. Otherwise, proceed to the Guides and solutions to use.

Guides and solutions to use:

1.1.1 User group mapping is set up in an identity federation

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

If you have configured user groups in your identity provider or plan to do so, set up user group mapping between the identity provider and Cloud Organization. Users in the identity provider's groups will be granted the same access permissions to Yandex Cloud resources as their respective groups in Cloud Organization.

1.2 Yandex ID accounts are only used in exceptional cases

The best approach to account management, in terms of security, is using identity federations (for more information, see recommendation 1.1). Therefore, you should do your best to ensure that your organization's list of users only contains federated users (those with the FEDERATION ID attribute) and there are as few Yandex ID accounts on the list as possible. The following exceptions are allowed:

  • Account with the billing.accounts.owner permissions (technically, only a Yandex ID account can have this role at the moment).
  • Account with the organization-manager.organizations.owner and resource-manager.clouds.owner permissions, if used in emergencies only, e.g., when configuration of your federation fails. If necessary, you can delete a privileged passport account with the organization-manager.organizations.owner role from an organization.
  • External accounts, such as those of your contract partners or contractors, which, for some reason, you cannot register in your IdP.
  1. Open the Yandex Cloud console in your browser.
  2. Go to All services → Yandex Cloud Organization → Users.
  3. If the Federation column is set to federation for all the accounts (but for those on the above list of exceptions allowed), the recommendation is fulfilled. Otherwise, proceed to the Guides and solutions to use.

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. Run the command below to search for non-federated accounts in your organization, but for the ID of the account included in the list of valid exceptions:

    yc organization-manager user list --organization-id=<organization ID> \
  --format=json | jq -r '.[] | select(.subject_claims.sub!="<ID of account from list of allowed exceptions>")' | jq -r 'select(.subject_claims.federation | not)'

  3. If there are no accounts in the list, the recommendation is fulfilled. Otherwise, proceed to the Guides and solutions to use.

Guides and solutions to use:

Remove all the accounts that have a Yandex ID from your organization, except those on the list of allowed exceptions.

1.3 Only appropriate administrators can manage IAM group membership

You can conveniently control access to resources via user groups. Make sure to control access to a group as a resource. Users with access permissions for a group can manage other users' membership in that group. Users get these permissions in the following cases:

  • User has the organization-manager.groups.memberAdmin role for the organization.
  • User has the organization-manager.groups.memberAdmin role for a specific group as a resource.
  • User has the organization-manager.organizations.owner 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).
  1. Open the Yandex Cloud console in your browser.
  2. Go to All services → Yandex Cloud Organization → Groups → Select a group → Group access permissions.
  3. Toggle the Inherited roles switch.
  4. If the list does not contain any accounts that must have no permission to manage group membership, the recommendation is fulfilled. Otherwise, proceed to the Guides and solutions to use.

Guides and solutions to use:

Remove the group access permissions from the accounts that do not require them.

1.4 Service roles are used instead of primitive roles: admin, editor, viewer, and auditor

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

Use the auditor role without data access wherever possible.

  1. Open the Yandex Cloud console in your browser.
  2. Go to All services → Yandex Cloud Organization → Users.
  3. Make sure no accounts in the Access permissions column have these primitive roles: admin, editor, or viewer. Otherwise, proceed to the Guides and solutions to use.
  4. Next, go to the global cloud menu (click the cloud in the initial cloud menu). Select the Access permissions tab.
  5. Make sure no accounts in the Roles column have these primitive roles: admin, editor, or viewer. Otherwise, proceed to the Guides and solutions to use.
  6. Next, go to each folder of each cloud and, similarly, navigate to the Access permissions tab.
  7. Make sure no accounts in the Roles column have these primitive roles: admin, editor, or viewer. Otherwise, proceed to the Guides and solutions to use.

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. Run the command below to search for accounts with primitive roles assigned at the organization level:

    export ORG_ID=<organization ID>
yc organization-manager organization list-access-bindings \
  --id=${ORG_ID} \
  --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="editor" or .role_id=="viewer")'

  3. If there are no accounts in the list, the recommendation is fulfilled. Otherwise, proceed to the Guides and solutions to use.

  4. Run the command below to search for accounts with primitive roles assigned at the cloud level:

    export ORG_ID=<organization ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="editor" or .role_id=="viewer")'
done

  5. If there are no accounts in the list, the recommendation is fulfilled. Otherwise, proceed to the Guides and solutions to use.

  6. Run the command below to search for accounts with primitive roles assigned at the level of all folders in your clouds:

    export ORG_ID=<organization ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); \
do yc resource-manager folder list-access-bindings --id=$FOLDER_ID --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="editor" or .role_id=="viewer")'
done;
done

  7. If there are no accounts in the list, the recommendation is fulfilled. Otherwise, proceed to the Guides and solutions to use.

Guides and solutions to use:

Analyze the accounts found with the admin, editor, and viewer primitive roles assigned and replace them with service granular roles based on your role matrix.

1.5 Cloud entities with service accounts are registered and limited

A service account is an account that can be used by a program to manage resources in Yandex Cloud. A service account is used to make requests as an application.

  • Do not use employee accounts instead of service accounts. If, for example, an employee quits or moves to a different department, their account permissions are disabled, which may lead to an application failure.
  • Do not write service account keys directly to your application's code, configuration files, or environment variables.

When using service accounts:

  • Assign the service account to the VM and get the token via the metadata service.

  • Additionally, set up the local firewall on the VM to allow access to the metadata service (IP address: 169.254.169.254) only to the appropriate processes and system users.

    Example of denying access to all users except the specified one (in this case, root):

    sudo iptables --append OUTPUT --proto tcp \
--destination 169.254.169.254 --match owner ! --uid-owner root \
--jump REJECT

The cloud entities with service accounts assigned must be registered and limited, because, for example, if a service account is assigned to a VM, a hacker may get the service account's token from the metadata service from within the VM.

  1. Open the Yandex Cloud console in your browser.
  2. Go to the appropriate folder and open the settings of the VM you need.
  3. Click Edit.
  4. The service account data is displayed.
  5. Repeat the steps for all VMs in all folders.

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. Run the command below to search for VMs with assigned service accounts in your organization:

    export ORG_ID=<organization ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id');
do for VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \
do yc compute instance get --id=$VM_ID --format=json | jq -r '. | select(.service_account_id)' | jq -r '.id'
done;
done;
done

  3. If there are no lines in the list or only accounted entities are output, the recommendation is fulfilled. Otherwise, proceed to the Guides and solutions to use.

Guides and solutions to use:

Remove the service accounts from the cloud entities that do not require them.

1.6 There are no cloud keys represented as plaintext in the VM metadata service

Do not write service account keys and other keys to the VM metadata directly. Assign a service account to a VM instance and get a token using the metadata service. You can store sensitive data in any metadata field. However, the most common one is user-data (due to its use in the cloud-init utility).

See the list of all regular expressions used to search for cloud accounts' credential secrets:

  • yandex_cloud_iam_cookie_v1 : c1.[A-Z0-9a-z_-]+[=]{0,2}.[A-Z0-9a-z_-]{86}[=]{0,2}
    Yandex.Cloud Session Cookie
  • yandex_cloud_iam_token_v1 : t1.[A-Z0-9a-z_-]+[=]{0,2}.[A-Z0-9a-z_-]{86}[=]{0,2}
    Yandex.Cloud IAM token
  • yandex_cloud_iam_api_key_v1 : AQVN[A-Za-z0-9_-]{35,38}
    Yandex.Cloud API Keys (Speechkit, Vision, Translate)
  • yandex_passport_oauth_token : y[0-6]_[-_A-Za-z0-9]{55}
    Yandex Passport OAuth token
  • yandex_cloud_iam_access_secret : YC[a-zA-Z0-9_-]{38}
    Yandex.Cloud AWS API compatible Access Secret

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. Run the command below to search for cloud keys in the metadata service represented as plaintext, using the example of Yandex Cloud AWS API Compatible Access Secret:

    export ORG_ID=<organization ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id');
do for VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \
do yc compute instance get --id=$VM_ID --full --format=json | jq -r '. | select(.metadata."user-data")| .metadata."user-data" | match("YC[a-zA-Z0-9_\\-]{38}") | .string' && echo $VM_ID
done;
done;
done

  3. If there are no lines in the list, the recommendation is fulfilled. Otherwise, proceed to the Guides and solutions to use.

  4. Run the command below to search for plaintext cloud keys in the metadata service. Here we use a Yandex Cloud IAM token as an example:

    export ORG_ID=<organization ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id');
do for VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \
do yc compute instance get --id fhm2i4a72v44kdqaqhid --full --format=json | jq -r '. | select(.metadata."user-data")| .metadata."user-data" | match("t1\\.[A-Z0-9a-z_-]+[=]{0,2}\\.[A-Z0-9a-z_-]{86}[=]{0,2}") | .string'
done;
done;
done

  5. If there are no lines in the list, the recommendation is fulfilled. Otherwise, proceed to the Guides and solutions to use.

Guides and solutions to use:

Remove the keys from the metadata of the VMs with deviations found:

  1. In the management console, select the folder the VM belongs to.
  2. Select Compute Cloud.
  3. Click the VM name.
  4. In the top-right corner of the page, click Edit VM.
  5. Open the Metadata menu and remove the keys by clicking .

If you do not have the Yandex Cloud command line interface yet, install and initialize it.

The folder specified in the CLI profile is used by default. You can specify a different folder using the --folder-name or --folder-id parameter.

  1. View a description of the CLI command to remove metadata:

    yc compute instance remove-metadata --help

  2. Remove the keys:

    yc compute instance remove-metadata <VM_ID> --keys <SSH_key_name>

To remove SSH keys from the VM metadata, use the updateMetadata REST API method for the Instance resource or the InstanceService/UpdateMetadata gRPC API call.

In your request, provide the delete parameter with the SSH key.

REST API request example

curl \
  --request POST \
  --header "Authorization: Bearer <IAM_token>" \
  --data '{"delete":["<SSH_key_name>"]}' \
  https://compute.api.cloud.yandex.net/compute/v1/instances/<VM_ID>/updateMetadata

1.7 Getting a token via AWS IMDSv1 is disabled on the VM

The cloud has a metadata service that provides information about VM performance.

From inside a VM, metadata is available in the following formats:

  • Google Compute Engine (some fields are not supported).
  • Amazon EC2 (some fields are not supported).

Amazon EC2 Instance Metadata Service version 1 (IMDSv1) has a number of drawbacks. The most critical of them is that there is a risk of compromising a service account token via the metadata service using a Server-Side Request Forgery (SSRF) attack. For more information, see the official AWS blog. Therefore, AWS has released IMDSv2, the second version of the metadata service.

So far, Yandex Cloud does not support version 2, so it is strongly recommended to technically disable getting a service account token via the Amazon EC2 metadata service.

The Google Compute Engine metadata service uses an additional header to protect against SSRF and enhance security.

You can disable getting a service account token via Amazon EC2 using the aws_v1_http_token:DISABLED VM parameter.

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. Run the command below to search for VMs with IMDSv1 enabled for getting a token:

    export ORG_ID=<organization ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id');
do for VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc compute instance get --id=$VM_ID --format=json | jq -r '. | select(.metadata_options.aws_v1_http_token=="ENABLED")' | jq -r '.id'
done;
done;
done

  3. If there are no lines in the list, the recommendation is fulfilled. Otherwise, proceed to the Guides and solutions to use.

Guides and solutions to use:

Under metadata_options, set the aws_v1_http_token parameter to DISABLED for the found VMs:

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

1.8 Service accounts have minimum privileges granted

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

  1. Open the Yandex Cloud console in your browser.
  2. Go to the appropriate folder.
  3. In the list of services, select Identity and Access Management.
  4. In the left-hand panel, select Service accounts.
  5. Check the list of service accounts.
  6. Repeat the steps for other folders.
  7. Go to the Access permissions tab at the cloud and folder levels.

To view organization-level access permissions, you need to use the YC CLI.

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. Run the command below to output all the service accounts of the organization in <service_account_ID>:<service_account_name> format:

    export ORG_ID=<organization ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id');
do for SA in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc iam service-account list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id + ":" + .[].name'
done;
done;
done

  3. Run the command below to output all the access permissions of a given service account assigned for the organization:

    export ORG_ID=<organization ID>
yc organization-manager organization list-access-bindings \
  --id=${ORG_ID} \
  --format=json | jq -r '.[] | select(.subject.type=="serviceAccount")'

  4. View the service account's access permissions in all clouds:

    export ORG_ID=<organization ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.subject.type=="serviceAccount")' && echo $CLOUD_ID
done;

  5. View the service account's access permissions in all folders:

    export ORG_ID=<organization ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id');
do yc resource-manager folder list-access-bindings --id=$FOLDER_ID --format=json | jq -r '.[] | select(.subject.type=="serviceAccount")' && echo $FOLDER_ID
done;
done

  6. Make sure the lists indicate no excessive permissions. Otherwise, proceed to the Guides and solutions to use.

Guides and solutions to use:

Remove the excessive permissions from the service account using IAM.

1.9 Only trusted administrators have access to service accounts

You can grant permissions to use a service account under another user or service account.
Follow the principle of least privilege when granting access to a service account as a resource: if the user has service account permissions, they also have access to all of its permissions. Assign roles that allow using and managing service accounts to a minimum number of users.
Each service account with extended permissions should be placed as a resource in a separate folder. It prevents accidental granting of permissions for this account along with the permissions for the folder with the respective service component.

  1. Open the Yandex Cloud console in your browser.
  2. Go to the appropriate folder.
  3. In the list of services, select Identity and Access Management.
  4. In the left-hand panel, select Service accounts.
  5. Click the service account you need and go to the Access permissions tab.
  6. Check the access permissions assigned to the service account.
  7. Make sure the list only contains valid administrators. Otherwise, proceed to the Guides and solutions to use.

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. Run the command below to output all the service accounts in the clouds:

    export ORG_ID=<organization ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.subject.type=="serviceAccount")' && echo $CLOUD_ID
done;

  3. Run the command below to output all the access permissions for a specific service account as a resource:

    yc iam service-account list-access-bindings \
  --id <service_account_ID>

  4. Make sure the list only contains valid administrators. Otherwise, proceed to the Guides and solutions to use.

Guides and solutions to use:

Remove the unnecessary service account permissions using IAM.

1.10 Service account keys are rotated on a regular basis

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

You need to rotate keys with unlimited validity yourself: delete and generate new ones. You can check out the date when a key was created in its properties. Perform key rotation at least once in 90 days as recommended in the information security standards, such as PCI DSS.

  1. Open the Yandex Cloud console in your browser.
  2. Go to the appropriate folder.
  3. In the list of services, select Identity and Access Management.
  4. In the left-hand panel, select Service accounts.
  5. Click the service account you need and see the date of each key's generation under Access key properties.
  6. Repeat the steps for each of your folders.
  7. Make sure the keys were created less than 90 days ago. Otherwise, proceed to the Guides and solutions to use.

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. Check when static access keys were created:

    export ORG_ID=<organization ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id');
do for SA in $(yc iam service-account list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id');
do yc iam access-key list --service-account-id=$SA --format=json | jq -r '.[] | "key_id" + ":" + .id + "," + "sa_id" + ":" + .service_account_id + "," + "created_at" + ":" + .created_at '
done;
done;
done

  3. Check when authorized keys were created:

    export ORG_ID=<organization ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id');
do for SA in $(yc iam service-account list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id');
do yc iam key list --service-account-id=$SA --format=json | jq -r '.[] | "key_id" + ":" + .id + "," + "sa_id" + ":" + .service_account_id + "," + "created_at" + ":" + .created_at '
done;
done;
done

  4. Check when API access keys were created:

    export ORG_ID=<organization ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id');
do for SA in $(yc iam service-account list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id');
do yc iam api-key list --service-account-id=$SA --format=json | jq -r '.[] | "key_id" + ":" + .id + "," + "sa_id" + ":" + .service_account_id + "," + "created_at" + ":" + .created_at '
done;
done;
done

  5. Make sure no list of keys of any type contains keys with the created_at value older than 90 days. Otherwise, proceed to the Guides and solutions to use.

Guides and solutions to use:

Follow the guide for rotating keys depending on their type.

1.11 Two-factor authentication is set up for privileged accounts

We recommend using two-factor authentication (2FA) for cloud infrastructure access control to avoid the risk of compromising user accounts. Access to the Yandex Cloud management console can be based on 2FA.

To enable two-factor authentication, contact an identity provider that supports 2FA and set up a SAML-compliant identity federation. Yandex Cloud has no IdP of its own and user identification is done using external services, such as Yandex ID or corporate systems integrated via identity federations. For example, if you are using an IdP of Active Directory or Keycloak, set up 2FA in these systems. Make sure to set up 2FA at least for privileged cloud accounts.

For a Yandex ID, set up 2FA using this guide.

  1. Open the Yandex ID UI in your browser.
  2. Go to the Security tab.
  3. Make sure login with an additional key is selected as the login option.
  4. You should have key-based login configured. Otherwise, proceed to the Guides and solutions to use.
  5. If you are using external IdPs, follow the guides to check the settings.

Guides and solutions to use:

1.12 Privileged roles are only granted to trusted administrators

Yandex Cloud privileged users include accounts with the following roles:

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

The billing.accounts.owner role is granted automatically when creating a billing account and cannot be reassigned to another user. The role allows you to perform any action with the billing account.

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

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

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

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

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

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

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

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

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

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

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

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

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

Checking roles for the Yandex Cloud Billing service:

  1. Open the Yandex Cloud management console in your browser.
  2. Go to Yandex Cloud Billing.
  3. Check who is granted the roles: billing.accounts.owner and admin.

Checking roles for an organization:

  1. Open the Yandex Cloud management console in your browser.
  2. Go to All services → Yandex Cloud Organization → Users.
  3. Check which users have the admin, organization-manager.organizations.owner, organization-manager.admin, and resource-manager.clouds.owner roles.

Checking roles for a cloud:

  1. Open the Yandex Cloud management console in your browser.
  2. Go to the global cloud menu: click the cloud in the initial cloud menu. Select the Access permissions tab.
  3. Check which users have the admin, editor, and resource-manager.clouds.owner roles.

To check roles for a folder:

  1. Open the Yandex Cloud management console in your browser.
  2. Next, go to each folder of each cloud and, similarly, select the Access permissions tab.
  3. Check to whom the admin role is granted.
  4. Make sure all the privileged roles are granted to trusted administrators. Otherwise, proceed to the "Guides and solutions to use".

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. Find organization-level privileged permissions:

    export ORG_ID=<organization ID>
yc organization-manager organization list-access-bindings
  --id=${ORG_ID} \
  --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="organization-manager.organizations.owner" or .role_id=="organization-manager.admin" or .role_id=="resource-manager.clouds.owner" or role_id=="resource-manager.clouds.editor")'

  3. Find cloud-level privileged permissions:

    export ORG_ID=<organization ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="resource-manager.clouds.owner" or role_id=="resource-manager.clouds.editor")' && echo $CLOUD_ID
done

  4. Run the command below to search for privileged permissions at the level of all folders in your clouds:

    export ORG_ID=<organization ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id');
do yc resource-manager folder list-access-bindings --id=$FOLDER_ID --format=json | jq -r '.[] | select(.role_id=="admin")' && echo $FOLDER_ID
done;
done

  5. Make sure all the privileged roles are granted to trusted administrators. Otherwise, proceed to the Guides and solutions to use.

Guides and solutions to use:

If any roles granted to untrusted administrators are found, investigate why and remove the respective permissions.

1.13 Strong passwords are set for local users of managed DBs

To use a database at the application level, in addition to IAM service roles, a separate local user is created: the database owner. The following password policy applies to this user:

  • The password must contain numbers, uppercase letters, lowercase letters, and special characters.
  • It must be at least 8 characters long.

Make sure the password is regularly rotated in manual mode and meets your company password policies. The password is stored on the client side and cannot be viewed in the management console, CLI, and API.

1.14 Contractor and third-party access control is enabled

If you grant third-party contractors access to your clouds, make sure to follow these security measures:

  • Assign permissions to contractor employees based on the principle of least privilege.
  • Where possible, create a separate account for third-party employees in your corporate IdP and assign the relevant policies to this account.
  • Require them to handle their account secrets with care.
  • Review the relevance of external user access to your cloud infrastructure.
  • Use the auditor role without data access wherever possible.

Check all accounts in your organization and make sure you are aware of all contractor and third-party accounts and follow the recommendations above.

1.15 The proper resource model is used

When developing an access model for your infrastructure, we recommend the following approach:

  • At least one organization per company.
  • Group resources by purpose and store them in separate folders. To ensure the strictest isolation, place them in a separate cloud.
  • Place any critical resources in a separate folder or cloud. These include resources related to the processing of payment data, personal data, and trade secret data.
  • Host the resource groups that require different administrative permissions in different folders or clouds (DMZ, CDE, security, backoffice, and so on).
  • When developing apps, make sure to isolate test and production environments.
  • Put shared resources (e.g., network and security groups) into a separate shared resource folder (if you separate components into folders).

Analyze your resource model and make sure it follows the recommendations given above.

1.16 There is no public access to your organization resources

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

Public group details:

  • All authenticated users: All authenticated users. These are all registered users or Yandex Cloud service accounts: both from your clouds and other users' clouds.
  • All users: Any user. No authentication is required.

Warning

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

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

Checking roles in a cloud:

  1. Open the Yandex Cloud management console in your browser.
  2. Next, go to the global cloud menu (click the cloud in the initial cloud menu). Select the Access permissions tab.
  3. Check whether there are All users and All authenticated users among users.

Checking roles in a folder:

  1. Open the Yandex Cloud management console in your browser.
  2. Go to the appropriate folder of the cloud you need and open the Access permissions tab.
  3. Check whether there are All users and All authenticated users among users.
  4. Repeat the steps for all folders in all your clouds.

Checking roles in Object Storage:

  1. Open the Yandex Cloud management console in your browser.
  2. Go to the desired cloud and find Object Storage.
  3. Click the three dots next to the bucket and check its ACL for allUsers, allAuthenticatedUsers.
  4. Open the bucket and check the ACLs of each of its objects for allUsers, allAuthenticatedUsers.
  5. Open the bucket's global settings, select Object read access, and make sure the Public parameter is disabled.
  6. Repeat the steps for all the buckets and objects in all of your clouds.

Checking roles in Container Registry:

  1. Open the Yandex Cloud management console in your browser.
  2. Next, go to each cloud and find Container Registry.
  3. Open the appropriate registry and click Access permissions on the left.
  4. Check whether there are All users and All authenticated users among users.
  5. Repeat the steps for all your clouds.

Checking roles in Cloud Functions:

  1. Open the Yandex Cloud management console in your browser.
  2. Next, go to each cloud and find Cloud Functions.
  3. Open all cloud functions and make sure the Public access parameter is disabled.
  4. Make sure none of the specified resources contain All users or All authenticated users. Otherwise, proceed to the Guides and solutions to use.

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. Run the command below to search for accounts with primitive roles assigned at the organization level:

    export ORG_ID=<organization ID>
yc organization-manager organization list-access-bindings \
  --id=${ORG_ID} \
  --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="organization-manager.organizations.owner" or .role_id=="organization-manager.admin" or .role_id=="resource-manager.clouds.owner")'

  3. Run the command below to search for cloud-level access permissions such as allUsers and allAuthenticatedUsers:

    export ORG_ID=<organization ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.subject.id=="allAuthenticatedUsers" or .subject.id=="allUsers")' && echo $CLOUD_ID
done

  4. Run the command below to search for folder-level access permissions such as allUsers and allAuthenticatedUsers:

    export ORG_ID=<organization ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id');
do yc resource-manager folder list-access-bindings --id=$FOLDER_ID --format=json | jq -r '.[] | select(.subject.id=="allAuthenticatedUsers" or .subject.id=="allUsers")' && echo $FOLDER_ID
done;
done

  5. Run the command below to search for the allUsers and allAuthenticatedUsers access permissions at the Container Registry level in all folders:

    export ORG_ID=<organization ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id');
do for CR in $(yc container registry list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id');
do yc container registry list-access-bindings --id $CR --format=json | jq -r '.[] | select(.subject.id=="allAuthenticatedUsers" or .subject.id=="allUsers")' && echo $CR
done;
done;
done

  6. Run the command below to search for the allUsers and allAuthenticatedUsers access permissions at the Cloud Functions level in all folders:

    export ORG_ID=<organization ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id');
do for FUN in $(yc serverless function list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \
do yc serverless function list-access-bindings --id $FUN --format=json | jq -r '.[] | select(.subject.id=="allAuthenticatedUsers" or .subject.id=="allUsers")' && echo $FUN
done;
done;
done

  7. Make sure none of the specified resources contain allUsers or allAuthenticatedUsers. Otherwise, proceed to the Guides and solutions to use.

Guides and solutions to use:

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

1.17 Contact information of the person in charge of an organization is valid

When registering a cloud in Yandex Cloud, customers enter their contact information. For example, an email address is used for notifications about incidents, scheduled maintenance activities, and so on.

For instance, if abnormal activities in the customer's organization are detected on the cloud side or the IAM cloud keys get available in external GitHub repositories, the customer receives a notification. This feature is implemented thanks to Yandex Cloud participating in the Github Secret scanning partner program and analyzing secrets in Yandex search. If any keys are compromised in a public repository, delete the secret from the repository and its history, as well as revoke the keys.

Make sure the contact information is valid and messages are sent to multiple persons in charge from the specified email address.

  1. Open the Yandex Cloud management console in your browser.
  2. Go to Yandex Cloud Billing.
  3. Go to the Account data tab.
  4. At the bottom, click Edit data in Yandex Balance.
  5. Verify the specified contact information.
  6. Make sure the contact details are valid. Otherwise, proceed to the Guides and solutions to use.

Guides and solutions to use:

Specify up-to-date contact information using the guide.

In the identity federation settings, make sure the Cookie lifetime parameter value is less than or equal to 6 hours. Thus you minimize the risk of compromising cloud users' workstations.

  1. Open the Yandex Cloud management console in your browser.
  2. Go to the Organizations tab.
  3. Next, open the Federations tab and select your federation.
  4. Find the Cookie lifetime parameter.
  5. Make sure its value is less than or equal to 6 hours. Otherwise, proceed to the Guides and solutions to use.

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. Run the command below to search for accounts with primitive roles assigned at the organization level:

    export ORG_ID=<organization ID>
for FED in $(yc organization-manager federation saml list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do yc organization-manager federation saml get --id bpfdshe1skaqcjp6uc50 --format=json | jq -r '. | select(.cookie_max_age>"21600s")'
done

  3. The output should return an empty string. If the result with the current federation's settings is output, where cookie_max_age > 21600s, proceed to the Guides and solutions to use.

Guides and solutions to use:

Set the Cookie lifetime to 6 hours (21600 seconds) or less.

1.19 Tokens for cloud functions and VMs are issued via service accounts

To get an IAM token when executing a function, assign a service account to the function. In this case, the function will get an IAM token by means of built-in Yandex Cloud tools so that you do not have to provide any secrets to the function externally. Do the same for your VMs.

Analyze all of your VMs and cloud functions in terms of manually created service account tokens. Tokens are used properly if you assign a service account to an entity and use the account's token from within via the metadata service.

1.20 Impersonation is used wherever possible

Impersonation allows a user to perform actions under a service account and to temporarily extend user permissions without generating static credentials for the user. It may be useful for use cases such as duty, local development, or permission verification.

  1. In the management console, click the name of the cloud you need in the left-hand panel.
  2. Go to the Access permissions tab and check if the iam.serviceAccounts.tokenCreator role is there.

Guides and solutions to use:

If the iam.serviceAccounts.tokenCreator role is missing, set up impersonation for service accounts to provide temporary access to critical data by following this guide.

1.21 Resource labels are used

Labels are required to monitor data streams and tag critical resources for privilege management.
For example, to tag resources which handle personal data under Federal Law No. FZ-152 of the Russian Federation on Personal Data, select the 152-fz:true label for:

  • Folder
  • Yandex Object Storage bucket
  • Yandex Lockbox secret
  • Managed DB clusters

The example below shows how to check if there is a label to a Yandex Virtual Private Cloud cloud network. You can perform similar checks for other resource labels.

  1. In the management console, select the folder.
  2. Select Virtual Private Cloud.
  3. Check it for labels.

Guides and solutions to use:

Guide on managing labels

1.22 Yandex Cloud security notifications are enabled

To get notifications of security-related events, such as vulnerability detection and elimination, we recommend selecting security notifications in the management console.

  1. In the management console, click Settings.
  2. Go to the Notifications section.
  3. In the notification settings, enable the Security option.

Guides and solutions to use:

  1. Make sure that notifications are set up.
  2. Enable the Security option in the notification settings in the management console.

1.23 The auditor role is used to prevent access to user data

Assign the auditor role to users who do not need access to data, e.g., external contractors or auditors.
auditor is a role with least privilege without access to service data. It grants permission to read service configurations and metadata.
The auditor role allows you to perform the following operations:

  • View information about a resource.
  • View resource metadata.
  • View a list of operations with a resource.

To control access more selectively and implement the principle of least privilege, use the auditor role by default.

  1. In the management console, go to the relevant folder.
  2. Click the Access permissions tab.
  3. Click Assign roles.
  4. In the Configure access bindings window, click Select user.
  5. Select a user from the list or search by user.
  6. Click Add role.
  7. Select the auditor role in the folder.
  8. Click Save.

  1. See what organizations are available to you and write down the ID you need:

    yc organization-manager organization list

  2. Run the command below to search for accounts with the auditor role assigned at the organization level:

    export ORG_ID=<organization_ID>
yc organization-manager organization list-access-bindings \
--id=${ORG_ID} \
--format=json | jq -r '.[] | select(.role_id=="auditor")'

    If the list of accounts is empty, go to the Guides and solutions to use.

  3. Run the command below to search for accounts with the auditor role assigned at the cloud level:

    export ORG_ID=<organization_ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.role_id=="auditor")'
done

    If the list of accounts is empty, go to the Guides and solutions to use.

  4. Run the command below to search for accounts with the auditor role assigned at the level of all folders in your clouds:

    export ORG_ID=<organization_ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); \
do yc resource-manager folder list-access-bindings --id=$FOLDER_ID --format=json | jq -r '.[] | select(.role_id=="auditor")'
done;
done

    If the list of accounts is empty, go to the Guides and solutions to use.

Guides and solutions to use:

  1. Assign the auditor role to users requiring no data access.
  2. Remove the excessive account permissions using IAM.

1.24 Tracking the date of last access key use in Yandex Identity and Access Management

To ensure security and control over access to resources, monitor cases of unauthorized use of keys, and delete unused keys without the risk of disrupting Yandex Cloud services, you can track the dates of last use of service account access keys. You can find this info on the service account page in the management console or in the last_used_at field when using the API to invoke access key management methods.

For more information, see Service account keys.

  1. In the management console, navigate to the folder the service account with access keys belongs to.
  2. In the list of services, select Identity and Access Management.
  3. In the left-hand panel, select Service accounts.
  4. In the list that opens, select the service account you need.
  5. You can see the time of the last key use in the table with key info under Date of last use.
Previous
Introduction
Next
Network security