1. Authentication and access control
In Yandex Cloud, identification, authentication, and access control is performed by Yandex Identity and Access Management (IAM) and Yandex Cloud Organization.
The platform works with three categories of users:
- Yandex accounts: Accounts in Yandex ID.
- Federated accounts: Accounts in a corporate SAML-compatible identity federation, such as Active Directory.
- Service accounts: Accounts that can be used by programs to manage resources.
Yandex ID accounts and federated accounts are authenticated in their own systems. Yandex Cloud has no access to these users' passwords and only authenticates service accounts via IAM.
User access to cloud resources is regulated by roles. Yandex Cloud services may provide different levels of granularity while granting permissions: in some cases, a role can be assigned directly to a service resource, in other cases, permissions are only granted at the level of the folder or cloud where the service resource is located.
This ensures interaction of different categories of resources, roles, and users in the Yandex Cloud infrastructure. Access to resources is managed by IAM. IAM controls each request and makes sure that all operations with resources are only run by users who have the appropriate permissions.
1.1 An identity federation (Single Sign-On, SSO) is configured
Yandex Cloud Organization is a single service for managing the organizational structure, setting up integration with the employee catalog, and differentiating user access to the organization's cloud resources.
For the purpose of centralized account management, use SAML-compatible identity federations. By using identity federations, a company can set up Single Sign-On, which is authentication in Yandex Cloud via their IdP server. With this approach, employees can use their corporate accounts that are subject to the company's security policies, such as:
- Revoking and blocking accounts.
- Password policies.
- Limiting the number of unsuccessful login attempts.
- Blocking access sessions upon expiry of a preset user's idle time.
- Two-factor authentication.
Tip
Use federated accounts instead of Yandex ID accounts whenever possible. Keep in mind that there is a separate role, organization-manager.federations.admin
, that is used for federation management.
To make sure that all authentication requests from Yandex Cloud contain a digital signature, enable the Sign authentication requests option. To complete the configuration, download and install a Yandex Cloud certificate. You can download the certificate in the Sign authentication requests field immediately after creating a federation.
- Open the Yandex Cloud console in your browser.
- Go to All services → Yandex Cloud Organization → Federations.
- If the list contains at least one identity federation configured, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
View information about the federations configured:
yc organization-manager federation saml list \ --organization-id=<organization ID>
-
If the list contains at least one identity federation configured, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
Guides and solutions to use:
- Guide on setting up SAML-based identity federations.
- Guide on configuring a SAML-based federation with KeyCloak
.
1.2 Yandex ID accounts are only used in exceptional cases
The best approach to account management, in terms of security, is using identity federations (for more information, see recommendation 1.1). Therefore, you should do your best to ensure that your organization's list of users only contains federated users (those with the FEDERATION ID
attribute) and there are as few Yandex ID accounts on the list as possible. The following exceptions are allowed:
- Account with the
billing.accounts.owner
permissions (technically, this role can now be granted to a Yandex ID account only). - Account with the
organization-manager.organizations.owner
andresource-manager.clouds.owner
permissions, only if you use it in case of emergency, such as when a federation's setup failed. If necessary, you can delete a privileged passport account with theorganization-manager.organizations.owner
role from an organization. - External accounts, such as those of your contract partners or contractors, which, for some reason, you cannot register in your IdP.
- Open the Yandex Cloud console in your browser.
- Go to All services → Yandex Cloud Organization → Users.
- If the Federation column is set to federation for all the accounts (but for those on the above list of exceptions allowed), the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for non-federated accounts in your organization, but for the ID of the account included in the list of valid exceptions:
yc organization-manager user list --organization-id=<organization ID> \ --format=json | jq -r '.[] | select(.subject_claims.sub!="<ID of the account on the list of valid exceptions>")' | jq -r 'select(.subject_claims.federation | not)'
-
If there are no accounts in the list, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
Guides and solutions to use:
Remove all the accounts that have a Yandex ID from your organization, except those on the list of allowed exceptions.
1.3 Only appropriate administrators can manage IAM group membership
You can conveniently control access to resources via user groups. Make sure to control access to a group as a resource. Users with access permissions to the group can manage other users' membership in the group. Users are granted these permissions in the following cases:
- The user is assigned the
organization-manager.groups.memberAdmin
role for an organization. - The user is assigned the
organization-manager.groups.memberAdmin
role for a specific group as a resource. - The user is assigned the
organization-manager.organizations.owner
oradmin
role or another privileged role for the entire organization. - The user is assigned the
admin
oreditor
role for a specific group as a resource (this is not recommended).
- Open the Yandex Cloud console in your browser.
- Go to All services → Yandex Cloud Organization → Groups → Select the desired group → Group access rights.
- Toggle the Inherited roles switch.
- If the list does not contain any accounts that must have no permission to manage group membership, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
Guides and solutions to use:
Remove the group access rights from the accounts that do not require them.
1.4 Service roles are used instead of primitive roles: admin, editor, viewer, and auditor
The principle of least privilege requires assigning users the minimum required roles. We do not recommend using primitive roles, such as admin
, editor
, viewer
, and auditor
that are valid for all services, because this contradicts the principle of least privilege. To ensure more selective access control and implementation of the principle of least privilege, use service roles that only contain permissions for a certain type of resources in the specified service. You can see the list of all service roles in the Yandex Cloud roll reference.
Use the auditor role without data access wherever possible.
- Open the Yandex Cloud console in your browser.
- Go to All services → Yandex Cloud Organization → Users.
- If no accounts in the Access rights column have such primitive roles as
admin
,editor
, andviewer
, the recommendation is fulfilled. Otherwise, proceed to theGuides and solutions to use
. - Next, go to the global cloud menu (click the cloud in the initial cloud menu). Select the Access rights tab.
- If no accounts in the Roles column have such primitive roles as
admin
,editor
, andviewer
, the recommendation is fulfilled. Otherwise, proceed to theGuides and solutions to use
. - Next, go to each folder of each cloud and, similarly, select the Access rights tab.
- If no accounts in the Roles column have such primitive roles as
admin
,editor
, andviewer
, the recommendation is fulfilled. Otherwise, proceed to theGuides and solutions to use
.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for accounts with primitive roles assigned at the organization level:
export ORG_ID=<organization ID> yc organization-manager organization list-access-bindings \ --id=${ORG_ID} \ --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="editor" or .role_id=="viewer")'
-
If there are no accounts in the list, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
. -
Run the command below to search for accounts with primitive roles assigned at the cloud level:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="editor" or .role_id=="viewer")' done
-
If there are no accounts in the list, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
. -
Run the command below to search for accounts with primitive roles assigned at the level of all folders in your clouds:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); \ do yc resource-manager folder list-access-bindings --id=$FOLDER_ID --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="editor" or .role_id=="viewer")' done; done
-
If there are no accounts in the list, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
Guides and solutions to use:
Analyze the accounts found with the admin
, editor
, and viewer
primitive roles assigned and replace them with service granular roles based on your role matrix.
1.5 Cloud entities with service accounts are registered and limited
A service account is an account that can be used by a program to manage resources in Yandex Cloud. A service account is used to make requests as an application.
- Do not use employee accounts instead of service accounts. If, for example, an employee quits or moves to a different department, their account permissions are disabled, which may lead to an application failure.
- Do not write service account keys directly to your application's code, configuration files, or environment variables.
When using service accounts:
-
Assign a service account to a VM instance and get a token using the metadata service.
-
In addition, set up a local firewall on the VM instance so that only the necessary processes and system users have access to the metadata service (IP address:
169.254.169.254
).Example of blocking access for all users except the specified one (in this case,
root
):sudo iptables --append OUTPUT --proto tcp \ --destination 169.254.169.254 --match owner ! --uid-owner root \ --jump REJECT
The cloud entities with service accounts assigned must be registered and limited, because, for example, if a service account is assigned to a VM, a hacker may get the service account's token from the metadata service from within the VM.
- Open the Yandex Cloud console in your browser.
- Go to the appropriate folder and open the settings of the VM you need.
- Click Edit.
- The service account data is displayed.
- Repeat the steps for all VMs in all folders.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for VMs with assigned service accounts in your organization:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc compute instance get --id=$VM_ID --format=json | jq -r '. | select(.service_account_id)' | jq -r '.id' done; done; done
-
If there are no lines in the list or only accounted entities are output, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
Guides and solutions to use:
Remove the service accounts from the cloud entities that do not require them.
1.6 There are no cloud keys represented as plaintext in the VM metadata service
Do not write service account keys and other keys to the VM metadata directly. Assign a service account to a VM instance and get a token using the metadata service. Sensitive data may be stored in any metadata field. However, the most common one is user-data
(due to its use in the cloud-init utility).
See the list of all regular expressions used to search for cloud accounts' credential secrets:
- yandex_cloud_iam_cookie_v1 : c1.[A-Z0-9a-z_-]+[=]{0,2}.[A-Z0-9a-z_-]{86}[=]{0,2}
Yandex.Cloud Session Cookie - yandex_cloud_iam_token_v1 : t1.[A-Z0-9a-z_-]+[=]{0,2}.[A-Z0-9a-z_-]{86}[=]{0,2}
Yandex.Cloud IAM token - yandex_cloud_iam_api_key_v1 : AQVN[A-Za-z0-9_-]{35,38}
Yandex.Cloud API Keys (Speechkit, Vision, Translate) - yandex_passport_oauth_token : y[0-6]_[-_A-Za-z0-9]{55}
Yandex Passport OAuth token - yandex_cloud_iam_access_secret : YC[a-zA-Z0-9_-]{38}
Yandex.Cloud AWS API compatible Access Secret
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for cloud keys in the metadata service represented as plaintext, using the example of Yandex Cloud AWS API Compatible Access Secret:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc compute instance get --id=$VM_ID --full --format=json | jq -r '. | select(.metadata."user-data")| .metadata."user-data" | match("YC[a-zA-Z0-9_\\-]{38}") | .string' && echo $VM_ID done; done; done
-
If there are no lines in the list, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
. -
Run the command below to search for cloud keys in the metadata service represented as plaintext, using the example of a Yandex Cloud IAM token:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc compute instance get --id fhm2i4a72v44kdqaqhid --full --format=json | jq -r '. | select(.metadata."user-data")| .metadata."user-data" | match("t1\\.[A-Z0-9a-z_-]+[=]{0,2}\\.[A-Z0-9a-z_-]{86}[=]{0,2}") | .string' done; done; done
-
If there are no lines in the list, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
Guides and solutions to use:
Remove the keys from the metadata of the VMs with deviations found:
- In the management console
, select the folder the VM belongs to. - Select Compute Cloud.
- Click the VM name.
- Click
Edit VM in the top-right corner of the page. - Open the Metadata menu and remove the keys by clicking
.
If you do not have the Yandex Cloud command line interface yet, install and initialize it.
The folder specified in the CLI profile is used by default. You can specify a different folder using the --folder-name
or --folder-id
parameter.
-
View a description of the CLI command to remove metadata:
yc compute instance remove-metadata --help
-
Remove the keys:
yc compute instance remove-metadata <VM_ID> --keys <SSH_key_name>
To remove SSH keys from the VM metadata, use the updateMetadata REST API method for the Instance resource or the InstanceService/UpdateMetadata gRPC API call.
In your request, provide the delete
parameter with the SSH key.
Sample REST API request
curl -X POST -H "Authorization: Bearer <IAM_token>" \
-d '{"delete":["<SSH_key_name>"]}' https://compute.api.cloud.yandex.net/compute/v1/instances/<VM_ID>/updateMetadata
1.7 Getting a token via AWS IMDSv1 is disabled on the VM
The cloud has a metadata service that provides information about VM performance.
From inside a VM, metadata is available in the following formats:
- Google Compute Engine (some fields are not supported).
- Amazon EC2 (some fields are not supported).
Amazon EC2 Instance Metadata Service version 1 (IMDSv1) has a number of drawbacks. The most critical of them is that there is a risk of compromising a service account token via the metadata service using a Server-Side Request Forgery (SSRF) attack. For more information, see the official AWS blog
So far, Yandex Cloud does not support version 2, so it is strongly recommended to technically disable getting a service account token via the Amazon EC2 metadata service.
The Google Compute Engine metadata service uses an additional header to protect against SSRF and enhance security.
You can disable getting a service account token via Amazon EC2 using the aws_v1_http_token:DISABLED VM parameter.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for VMs with IMDSv1 enabled for getting a token:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc compute instance get --id=$VM_ID --format=json | jq -r '. | select(.metadata_options.aws_v1_http_token=="ENABLED")' | jq -r '.id' done; done; done
-
If there are no lines in the list, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
Guides and solutions to use:
Under metadata_options, set the aws_v1_http_token parameter to DISABLED
for the found VMs:
yc compute instance update <VM_ID> \
--metadata-options aws-v1-http-token=DISABLED
1.8 Service accounts have minimum privileges granted
Follow the principle of least privilege and assign to the service account only the roles necessary to run the application.
- Open the Yandex Cloud console in your browser.
- Go to the appropriate folder.
- At the top of the screen, go to the Service accounts tab.
- Check the list of service accounts.
- Repeat the steps for other folders.
- Go to the Access rights tab at the cloud and folder levels.
You can only view the organization-level access rights in the YC CLI.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to output all the service accounts of the organization in
<service_account_ID>:<service_account_name>
format:export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for SA in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc iam service-account list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id + ":" + .[].name' done; done; done
-
Run the command below to output all the access rights of a specific service account to the organization:
export ORG_ID=<organization ID> yc organization-manager organization list-access-bindings \ --id=${ORG_ID} \ --format=json | jq -r '.[] | select(.subject.type=="serviceAccount")'
-
View the service account's access rights in all clouds:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.subject.type=="serviceAccount")' && echo $CLOUD_ID done;
-
View the service account's access rights in all folders:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do yc resource-manager folder list-access-bindings --id=$FOLDER_ID --format=json | jq -r '.[] | select(.subject.type=="serviceAccount")' && echo $FOLDER_ID done; done
-
If the lists do not contain any rights that are not required, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
Guides and solutions to use:
Remove the unnecessary rights from the service account using IAM.
1.9 Only trusted administrators have access to service accounts
You can grant permissions to use a service account under another user or service account.
Follow the principle of least privilege when granting access to a service account as a resource: if the user has service account permissions, they also have access to all of its permissions. Assign roles that allow using and managing service accounts to a minimum number of users.
Each service account with extended rights should be placed as a resource in a separate folder. It prevents accidental granting of rights to this account along with the rights to the folder with the respective service component.
- Open the Yandex Cloud console in your browser.
- Go to the appropriate folder.
- At the top of the screen, go to the Service accounts tab.
- Click the service account you need and go to the Access rights tab.
- Check the access rights assigned to the service account.
- If the list only contains valid administrators, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to output all the service accounts in the clouds:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.subject.type=="serviceAccount")' && echo $CLOUD_ID done;
-
Run the command below to output all the access rights to a specific service account as a resource:
yc iam service-account list-access-bindings \ --id <service_account_ID>
-
If the list only contains valid administrators, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
Guides and solutions to use:
Remove the unnecessary service account rights using IAM.
1.10 Service account keys are rotated on a regular basis
Yandex Cloud lets you create the following access keys for service accounts:
- IAM tokens that are valid for 12 hours.
- API keys with unlimited validity.
- Authorized keys with unlimited validity.
- AWS API-compatible static access keys with unlimited validity.
You need to rotate keys with unlimited validity yourself: delete and generate new ones. You can check out the date when a key was created in its properties. Perform key rotation at least once in 90 days as recommended in the information security standards, such as PCI DSS.
- Open the Yandex Cloud console in your browser.
- Go to the appropriate folder.
- At the top of the screen, go to the Service accounts tab.
- Click the service account and see the date of each key's generation under Access key properties.
- Repeat the steps for each of your folders.
- If the keys were created less than 90 keys ago, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Check when static access keys were created:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for SA in $(yc iam service-account list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc iam access-key list --service-account-id=$SA --format=json | jq -r '.[] | "key_id" + ":" + .id + "," + "sa_id" + ":" + .service_account_id + "," + "created_at" + ":" + .created_at ' done; done; done
-
Check when authorized keys were created:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for SA in $(yc iam service-account list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc iam key list --service-account-id=$SA --format=json | jq -r '.[] | "key_id" + ":" + .id + "," + "sa_id" + ":" + .service_account_id + "," + "created_at" + ":" + .created_at ' done; done; done
-
Check when API access keys were created:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for SA in $(yc iam service-account list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc iam api-key list --service-account-id=$SA --format=json | jq -r '.[] | "key_id" + ":" + .id + "," + "sa_id" + ":" + .service_account_id + "," + "created_at" + ":" + .created_at ' done; done; done
-
If the list of keys of any type contains no keys with the date in the
created_at
field greater than 90 days, the recommendation is fulfilled. Otherwise, proceed to theGuides and solutions to use
.
Guides and solutions to use:
Follow the guide for rotating keys depending on their type.
1.11 Two-factor authentication is set up for privileged accounts
We recommend using two-factor authentication (2FA) for cloud infrastructure access control to avoid the risk of compromising user accounts. Access to the Yandex Cloud management console can be based on 2FA.
To enable two-factor authentication, contact an identity provider that supports 2FA and set up a SAML-compliant identity federation. Yandex Cloud has no IdP of its own and user identification is done using external services, such as Yandex ID or corporate systems integrated via identity federations. For example, if you are using an IdP of Active Directory or Keycloak, set up 2FA in these systems. Make sure to set up 2FA at least for privileged cloud accounts.
For a Yandex ID account, set up 2FA using this guide
- Open the Yandex ID UI in your browser.
- Go to the Security
tab. - Make sure that the login method using an additional key is specified.
- If this method is set up, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
. - If you are using external IdPs, follow the guides to check the settings.
Guides and solutions to use:
- Two-factor authentication: Yandex ID
. - KeyCloak: Creating other credentials
. - Configure Additional Authentication Methods for AD FS
.
1.12 Privileged roles are only granted to trusted administrators
Yandex Cloud privileged users include accounts with the following roles:
billing.accounts.owner
.admin
assigned for a billing account.organization-manager.organizations.owner
.organization-manager.admin
.resource-manager.clouds.owner
.admin
andeditor
assigned for an organization.admin
andeditor
assigned for a cloud.admin
andeditor
assigned for a folder.
The billing.accounts.owner
role is granted automatically when creating a billing account and cannot be reassigned to another user. The role allows you to perform any action with the billing account.
The billing.accounts.owner
role can only be assigned to a Yandex ID account. An account with the billing.accounts.owner
role is used when setting up payment methods and adding clouds.
Make sure to properly secure this account: it offers significant privileges and cannot be federated with a corporate account.
The most appropriate approach would be to not use this account on a regular basis:
- Only use it for initial setup and updates.
- When actively using this account, enable two-factor authentication (2FA) in Yandex ID.
- After that, if you do not use the bank card payment method (only available for this role), set a strong password for this account (generated using specialized software), disable 2FA, and refrain from using this account unnecessarily.
- Change the password to a newly generated one each time you use the account.
We recommend disabling 2FA only for this account and if it is not assigned to a specific employee. Thus you can avoid linking this critical account to a personal device.
To manage a billing account, assign the admin
or editor
role for the billing account to a dedicated employee with a federated account.
To view billing data, assign the viewer
role for the billing account to a dedicated employee with a federated account.
By default, the organization-manager.organizations.owner
role is granted to the user who creates an organization: the organization owner. The role allows you to appoint organization owners as well as use all the administrator privileges.
The resource-manager.clouds.owner
role is assigned automatically when you create your first cloud in the organization. A user with this role can perform any operation with the cloud or its resources and grant cloud access to other users: assign roles and revoke them.
Assign the resource-manager.clouds.owner
and organization-manager.organizations.owner
roles to one or more employees with a federated account. Set a strong password for the Yandex ID account that was used to create the cloud, and use it only when absolutely necessary (for example, if the federated access fails).
Make sure to fully protect your federated account that is granted one of the privileged roles listed above:
- Enable two-factor authentication.
- Disable authentication from devices beyond the company's control.
- Configure login attempt monitoring and set alert thresholds.
Assign federated accounts the admin
roles for clouds, folders, and billing accounts. Minimize the number of accounts with these roles and regularly review the expedience of these roles for the accounts they are assigned to.
Checking roles for the Yandex Cloud Billing service:
- Open the Yandex Cloud management console in your browser.
- Go to Yandex Cloud Billing
. - Check to whom the
billing.accounts.owner
andadmin
roles are granted.
Checking roles for an organization:
- Open the Yandex Cloud management console in your browser.
- Go to All services → Yandex Cloud Organization → Users.
- Check to whom the
admin
,organization-manager.organizations.owner
,organization-manager.admin
, andresource-manager.clouds.owner
roles are granted.
Checking roles for a cloud:
- Open the Yandex Cloud management console in your browser.
- Go to the global cloud menu: click the cloud in the initial cloud menu. Select the Access rights tab.
- Check to whom the
admin
,editor
, andresource-manager.clouds.owner
roles are granted.
To check roles for a folder:
- Open the Yandex Cloud management console in your browser.
- Next, go to each folder of each cloud and, similarly, select the Access rights tab.
- Check to whom the
admin
role is granted. - If all the privileged roles are granted to trusted administrators, the recommendation is fulfilled. Otherwise, proceed to the Guides and solutions to use.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Find organization-level privileged rights:
export ORG_ID=<organization ID> yc organization-manager organization list-access-bindings --id=${ORG_ID} \ --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="organization-manager.organizations.owner" or .role_id=="organization-manager.admin" or .role_id=="resource-manager.clouds.owner" or role_id=="resource-manager.clouds.editor")'
-
Find cloud-level privileged rights:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="resource-manager.clouds.owner" or role_id=="resource-manager.clouds.editor")' && echo $CLOUD_ID done
-
Run the command below to search for privileged rights at the level of all folders in your clouds:
export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do yc resource-manager folder list-access-bindings --id=$FOLDER_ID --format=json | jq -r '.[] | select(.role_id=="admin")' && echo $FOLDER_ID done; done
-
If all the privileged roles are granted to trusted administrators, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
Guides and solutions to use:
If any roles granted to untrusted administrators are found, investigate why and remove the respective rights.
1.13 Strong passwords are set for local users of managed DBs
To use a database at the application level, in addition to IAM service roles, a separate local user is created: the database owner. The following password policy applies to this user:
- The password must include numbers, uppercase letters, lowercase letters, and special characters.
- It must be at least 8 characters long.
Make sure the password is regularly rotated in manual mode and meets your company password policies. The password is stored on the client side and cannot be viewed in the management console, CLI, and API.
1.14 Contractor and third-party access control is enabled
If you grant third-party contractors access to your clouds, make sure to follow these security measures:
- Assign permissions to contractor employees based on the principle of least privilege.
- If possible, create a separate account for third-party employees in your corporate IdP and assign the required policies to this account.
- Require them to handle their account secrets with care.
- Review the relevance of external user access to your cloud infrastructure.
- Use the auditor role without data access wherever possible.
Check all accounts in your organization and make sure you are aware of all contractor and third-party accounts and follow the recommendations above.
1.15 The proper resource model is used
When developing an access model for your infrastructure, we recommend the following approach:
- At least one organization per company.
- Group resources by purpose and store them in separate folders. To ensure the strictest isolation, place them in a separate cloud.
- Place any critical resources in a separate folder or cloud. These include resources related to the processing of payment data, personal data, and trade secret data.
- Host the resource groups that require different administrative permissions in different folders or clouds (DMZ, CDE, security, backoffice, and so on).
- When developing apps, make sure to isolate test and production environments.
- Put shared resources (e.g., network and security groups) into a separate shared resource folder (if you separate components into folders).
Analyze your resource model and make sure it follows the recommendations given above.
public access
to your organization resources
1.16 There is no Yandex Cloud allows you to grant public access to your resources. You can grant public access by assigning access permissions to public groups (All authenticated users
, All users
).
Public group details:
All authenticated users
: All users who have authenticated. These are all registered users or Yandex Cloud service accounts: both from your clouds and other users' clouds.All users
: Any user. No authentication is required.
Warning
Currently, All users
is only supported for the following services: Object Storage (when using ACL-based access management), Container Registry, and Cloud Functions. For other services, assigning a role to the All users
group is the same as doing so to All authenticated users
.
Make sure that these groups have no public access to your resources: clouds, folder, buckets, and more.
Checking roles in a cloud:
- Open the Yandex Cloud management console in your browser.
- Next, go to the global cloud menu (click the cloud in the initial cloud menu). Select the Access rights tab.
- Check whether there are
All users
andAll authenticated users
among the users.
Checking roles in a folder:
- Open the Yandex Cloud management console in your browser.
- Go to the appropriate folder of the appropriate cloud and open the Access rights tab.
- Check whether there are
All users
andAll authenticated users
among the users. - Repeat the steps for all folders in all your clouds.
Checking roles in Object Storage:
- Open the Yandex Cloud management console in your browser.
- Go to the desired cloud and find Object Storage.
- Click the three dots next to the bucket and check its ACL for
allUsers
andallAuthenticatedUsers
. - Open the bucket and check the ACL of each of its objects for
allUsers
andallAuthenticatedUsers
. - Open the bucket's global settings, select Object read access, and make sure the Public parameter is disabled.
- Repeat the steps for all the buckets and objects in all of your clouds.
Checking roles in Container Registry:
- Open the Yandex Cloud management console in your browser.
- Next, go to each cloud and find Container Registry.
- Open the appropriate registry and click Access rights on the left.
- Check whether there are
All users
andAll authenticated users
among the users. - Repeat the steps for all your clouds.
Checking roles in Cloud Functions:
- Open the Yandex Cloud management console in your browser.
- Next, go to each cloud and find Cloud Functions.
- Open all cloud functions and make sure the Public access parameter is disabled.
- If there are no
All users
andAll authenticated users
subjects in each specified resource, the recommendation is fulfilled. Otherwise, proceed to theGuides and solutions to use
.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for accounts with primitive roles assigned at the organization level:
export ORG_ID=<organization ID> yc organization-manager organization list-access-bindings \ --id=${ORG_ID} \ --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="organization-manager.organizations.owner" or .role_id=="organization-manager.admin" or .role_id=="resource-manager.clouds.owner")'
-
To search for
allUsers
andallAuthenticatedUsers
access permissions at the cloud level, run the following command:export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.subject.id=="allAuthenticatedUsers" or .subject.id=="allUsers")' && echo $CLOUD_ID done
-
To search for
allUsers
andallAuthenticatedUsers
access permissions at the folder level, run the following command:export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do yc resource-manager folder list-access-bindings --id=$FOLDER_ID --format=json | jq -r '.[] | select(.subject.id=="allAuthenticatedUsers" or .subject.id=="allUsers")' && echo $FOLDER_ID done; done
-
To search for
allUsers
andallAuthenticatedUsers
access permissions at the Container Registry level in all folders, run the following command:export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for CR in $(yc container registry list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc container registry list-access-bindings --id $CR --format=json | jq -r '.[] | select(.subject.id=="allAuthenticatedUsers" or .subject.id=="allUsers")' && echo $CR done; done; done
-
To search for
allUsers
andallAuthenticatedUsers
access permissions at the Cloud Functions level in all folders, run the following command:export ORG_ID=<organization ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); do for FUN in $(yc serverless function list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \ do yc serverless function list-access-bindings --id $FUN --format=json | jq -r '.[] | select(.subject.id=="allAuthenticatedUsers" or .subject.id=="allUsers")' && echo $FUN done; done; done
-
If none of the specified resources contains
allUsers
andallAuthenticatedUsers
, the recommendation is fulfilled. Otherwise, proceed to theGuides and solutions to use
.
Guides and solutions to use:
If All users
and All authenticated users
have access permissions, you need to delete these permissions.
1.17 Contact information of the person in charge of an organization is valid
When registering a cloud in Yandex Cloud, customers enter their contact information. For example, an email address is used for notifications about incidents, scheduled maintenance activities, and so on.
For instance, if abnormal activities in the customer's organization are detected on the cloud side or the IAM cloud keys get available in external GitHub repositories, the customer receives a notification. This feature is implemented thanks to Yandex Cloud participating in the Github Secret scanning partner program
Make sure the contact information is valid and messages are sent to multiple persons in charge from the specified email address.
- Open the Yandex Cloud management console in your browser.
- Go to Yandex Cloud Billing
. - Go to the Account data tab.
- At the bottom, click Edit data in Yandex Balance.
- Verify the specified contact information.
- If it is valid, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
Guides and solutions to use:
Specify up-to-date contact information using the guide.
1.18 The cookie lifetime in a federation is less than 6 hours
In the identity federation settings, make sure the Cookie lifetime parameter value is less than or equal to 6 hours. Thus you minimize the risk of compromising cloud users' workstations.
- Open the Yandex Cloud management console in your browser.
- Go to the Organizations tab.
- Next, open the Federations tab and select your federation.
- Find the Cookie lifetime parameter.
- If its value is less than or equal to 6 hours, the recommendation is fulfilled. Otherwise, proceed to the
Guides and solutions to use
.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for accounts with primitive roles assigned at the organization level:
export ORG_ID=<organization ID> for FED in $(yc organization-manager federation saml list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do yc organization-manager federation saml get --id bpfdshe1skaqcjp6uc50 --format=json | jq -r '. | select(.cookie_max_age>"21600s")' done
-
If an empty string is output, the recommendation is fulfilled. If the result with the current federation's settings is output, where
cookie_max_age
> 21600s, proceed to theGuides and solutions to use
.
Guides and solutions to use:
Set the Cookie lifetime to 6 hours (21600 seconds) or less.
1.19 Tokens for cloud functions and VMs are issued via service accounts
To get an IAM token when executing a function, assign a service account to the function. In this case, the function receives an IAM token using built-in Yandex Cloud mechanisms without having to transfer any secrets to the function from outside. Do the same for your VMs.
Analyze all of your VMs and cloud functions in terms of manually created service account tokens. Tokens are used properly if you assign a service account to an entity and use the account's token from within via the metadata service.
1.20 Impersonation is used wherever possible
Impersonation allows a user to perform actions under a service account and to temporarily extend user permissions without generating static credentials for the user. It may be useful for use cases such as duty, local development, or permission verification.
- In the management console
, click the name of the cloud you need in the left-hand panel. - Go to the Access bindings tab and check if the
iam.serviceAccounts.tokenCreator
role is there.
Guides and solutions to use:
If the iam.serviceAccounts.tokenCreator
role is missing, set up impersonation for service accounts to provide temporary access to critical data by following this guide.
1.21 Resource labels are used
Labels are required to monitor data streams and tag critical resources for privilege management.
For example, for tagging resources involved in processing personal data under Federal Law No. FZ-152 of the Russian Federation on Personal Data, select the 152-fz:true
label for:
The example below shows how to check if there is a label to a Yandex Virtual Private Cloud cloud network. You can perform similar checks for other resource labels.
- In the management console
, select the folder. - Select Virtual Private Cloud.
- Check it for labels.
Guides and solutions to use:
1.22 Yandex Cloud security notifications are enabled
To get notifications of security-related events, such as vulnerability detection and elimination, we recommend selecting security notifications in the management console.
- In the management console
, click Settings . - Go to the Notifications section.
- In the notification settings, enable the Security option.
Guides and solutions to use:
- Make sure that notifications are set up.
- Enable the Security option in the notification settings in the management console.
1.23 The auditor role is used to prevent access to user data
Assign the auditor
role to users that do not require data access, such as external contractors or auditors.
auditor
is a role with least privilege without access to service data. It grants permission to read service configurations and metadata.
The auditor
role allows you to perform the following operations:
- View information about a resource.
- View resource metadata.
- View a list of operations with a resource.
To control access more selectively and implement the principle of least privilege, use the auditor
role by default.
- In the management console
, go to the appropriate folder. - Click the Access bindings tab.
- Click Assign roles.
- In the Configure access bindings window, click Select user.
- Select a user from the list or search by user.
- Click Add role.
- Select the
auditor
role in the folder. - Click Save.
-
See what organizations are available to you and write down the ID you need:
yc organization-manager organization list
-
Run the command below to search for accounts with the
auditor
role assigned at the organization level:export ORG_ID=<organization_ID> yc organization-manager organization list-access-bindings \ --id=${ORG_ID} \ --format=json | jq -r '.[] | select(.role_id=="auditor")'
If the list of accounts is empty, go to the
Guides and solutions to use
. -
Run the command below to search for accounts with the
auditor
role assigned at the cloud level:export ORG_ID=<organization_ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.role_id=="auditor")' done
If the list of accounts is empty, go to the
Guides and solutions to use
. -
Run the command below to search for accounts with the
auditor
role assigned at the level of all folders in your clouds:export ORG_ID=<organization_ID> for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id'); do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); \ do yc resource-manager folder list-access-bindings --id=$FOLDER_ID --format=json | jq -r '.[] | select(.role_id=="auditor")' done; done
If the list of accounts is empty, go to the
Guides and solutions to use
.
Guides and solutions to use:
- Assign the
auditor
role to users requiring no data access. - Remove the unnecessary account rights using IAM.