This document introduces some best practices of using RAM from the following aspects: logon verification, account authorization, and permission assignment. These suggestions help you make full use of RAM to deploy a secure and controllable environment.
We recommend that you enable account protection for your root account (for example Time-based One-time Password, that is, TOTP verification) so that TOTP is performed each time the root account is used.
If you have created a RAM user and granted high-risk permissions to the user (such as stopping instances and deleting buckets), you are advised to enable multi-factor authentication (MFA) for the RAM user.
If you allow a RAM user to change his or her logon password, you should require the user to create a strong logon password and encourage frequent password rotation.
You can create password policies, such as the minimum length, whether non-letter characters are required, and the rotation cycle, for RAM users on the RAM console.
We recommend that you or the RAM users regularly rotate logon passwords or AccessKeys. If a credential is disclosed without your knowledge, the validity of the credential is restricted.
You can set a password policy to force the RAM users to rotate their logon passwords or AccessKeys in a regular cycle.
The minimum authorization rule is a primary rule for security design. When you need to grant permissions to a user, grant the user only the permissions that are required for his work.
For example, in your organization, if the responsibilities of the developers group (or an application system) only require reading data stored in the OSS buckets, grant the group (or the application system) read-only permission. All permissions for OSS resources, or the permission to access resources of all products are not required.
We recommend that you set policy conditions when you grant permissions to a user to enhance the security.
For example, you grant a user the permission to stop ECS instances with the condition that the user enacts the stop at a specified time on the company network.
This can help minimize any security risk caused by disclosure of the access credential of the user without your knowledge.
We recommend that you do not create an AccessKey for the root account, as the root account has full permissions for all resources under it.
Normally, you do not need to attach an authorization policy to a RAM user. It is more convenient to create a group (such as admin, developer, and accounting groups) related to the role and responsibilities of the user. Attach an appropriate authorization policy to the group, and then add users to the group. All users in a group share the same permissions.
Therefore, you can modify the permissions of all users in the group with one operation. When a user is transferred in your organization, you only need to change the group to which the user belongs.
A secure authority-based management system supports checks and balances to minimize security risks. When using RAM, create separate RAM users responsible for RAM user management, RAM permission management, and the management of resource operations under various products.
We recommend that you create only logon passwords for employees and create only AccessKeys for systems and applications. It is not recommended that you create both a logon password for console operations and an AccessKey for API operations for one RAM user.