Authentication and authorization security checklist
This section provides recommendations on how to make the best use of Yandex Cloud services for secure authentication, authorization, and resource access control.
Accounts
✓ Yandex account protection:
- Enable two-factor authentication
for your Yandex ID and for user accounts within your organization. - Keep your OAuth token confidential. If someone might have discovered your OAuth token, invalidate it
and issue a new one. Avoid using your OAuth token for authentication if you can use an IAM token. OAuth tokens are valid for 1 year while IAM tokens are valid for 12 hours.
✓ Identity federation (Single Sign-On, SSO): For the purpose of centralized account management, use SAML-compatible identity federations. By using identity federations, a business can set up Single Sign-On to Yandex Cloud via their IdP server. This will allow your employees to use their corporate accounts for accessing Yandex Cloud services and enable you to manage users via the Yandex Cloud management console. Configure two-factor authentication on the identity provider side.
Roles and resources
✓ Least privilege principle: [Assign service roles (e.g., compute.images.user
) instead of primitive ones (e.g., auditor
, viewer
, editor
, or admin
). See the list of all roles for details.
- Assign only roles you need right now. Do not assign roles you may only need in the future.
- Note that when you assign a role for a folder, cloud, or organization, all the nested resources will inherit this role's permissions.
- Assign the admin role only to users whose duties involve managing access to resources.
- Assign the cloud or organization owner role only to users whose duties involve performing any actions with resources. An administrator can take away another administrator's access permissions, and an owner can revoke another owner's role.
- Assign users service and primitive level
editor
roles to enable them to create and delete resources. - Use impersonation to allow users to manage cloud resources on behalf of a service account. Use service accounts with the required roles rather than assigning roles to specific users. This approach temporarily expands user permissions without generating static credentials for the user.
✓ Using the auditor role to prevent access to user data: Assign the auditor
role (the role with least privilege and without access to service data) to users who need no access to data, such as external contractors or auditors. To control access more selectively and implement the principle of least privilege, use the auditor
role by default.
✓ billing.accounts.owner protection: After performing the initial operations, do not use an account with this role. To manage a billing account, assign the admin
, editor
, or viewer
role for the billing account to a dedicated employee with a federated account.
✓ organization-manager.organizations.owner protection: Grant the organization-manager.organizations.owner
role to a federated account and then delete the passport account with this role from your organization. To mitigate the risks of possible federation failures, follow the steps described in Deleting a passport account from an organization.
✓ Using a correct resource model: When developing an access model for your infrastructure, use the following approach:
- 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.
- Put shared resources (e.g., network and security groups) into a separate shared resource folder (if you separate components into folders).
Service accounts
✓ Using impersonation where feasible: Impersonation allows a user to perform actions under a service account and to temporarily extend user permissions without generating static credentials for the user.
✓ Using a service account for operations from within a virtual machine: Link a service account to the VM. Thus, you will no longer need to store your service account keys on the VM for authentication: your IAM token will be available via a metadata service link.
✓ Using an IAM token for authentication: If you need to use static credentials, consider using an IAM token. Keys have an unlimited lifetime, while IAM tokens are valid for 12 hours. If the IAM token has been compromised or you no longer plan to use it, revoke it.
✓ Using service accounts: Use service accounts to automate your work with Yandex Cloud. You can check the date and time of the last authentication on the service account information page in the management console: this information allows you to track cases of unauthorized use of service accounts.
✓ Dedicated service accounts for different tasks: This will enable you to assign to service accounts only the roles you really need. You can revoke roles from a service account or delete it without affecting other service accounts.
✓ Key usage monitoring: In the management console
✓ Storing service account keys in secrets: If using static keys, store them in Yandex Lockbox secrets.
✓ Periodic rotation of service account keys: Keys with no expiration date (authorized keys and static keys) require manual rotation. You can check out the date when a key was created in its properties. Perform key rotation at least once in 90 days.
Secrets
✓ Scanning for Yandex Cloud secrets in public sources: Yandex Cloud can scan open sources for multiple types of secrets: API keys, IAM cookies, IAM tokens, static access keys, OAuth tokens and SmartCaptcha server keys. You can learn more about scanning for various types of secrets here.
✓ Handling compromised secrets: If secrets were compromised, revoke them and issue new ones; check for unauthorized actions and delete unauthorized resources. Report the incident to the support
✓ Using Yandex Lockbox secrets for storing access keys and tokens: Store keys and tokens in Yandex Lockbox secrets and use their payload when you need to apply a key or token.
✓ Using API keys with limited access: create API keys with limited scope and validity period for working with the list of required services to lower the risk of unauthorized use of the keys.
Alert
If you do not select a scope, the API key will allow authentication in all services except those that support scope restriction. In the future, all services supporting API key authentication will have scopes of their own.