Avoid using your Alibaba Cloud account (root account) to access Simple Application Server resources. If your Alibaba Cloud account credentials are compromised, all resources in your account are at risk. Instead, create Resource Access Management (RAM) users or RAM roles with only the permissions they need.
The table below summarizes the three identity types and when to use each:
| Identity type | Best for | Has permanent credentials | Grants permissions via |
|---|---|---|---|
| RAM user | Individual people or programs that need long-term access | Yes (password or AccessKey pair) | Attaching policies directly or through a user group |
| RAM user group | Managing permissions for multiple RAM users with the same job function | No | Attaching policies to the group |
| RAM role | Temporary access | No (uses STS tokens) | Assuming the role to get a temporary STS token |
RAM users
A RAM user can be created by an Alibaba Cloud account or by a RAM user or RAM role that has administrative rights. Once granted permissions, a RAM user can access resources through the Alibaba Cloud Management Console or by calling API operations.
When creating a RAM user, set the Access Mode to one of the following:
Console Access — the user logs on to the console with a username and password. Enable multi-factor authentication (MFA) for these users.
Using permanent AccessKey to access — the user makes API calls using an AccessKey pair. Use this mode for programs, not people.
Both — only if the same identity genuinely needs both.
Separating console users from programmatic users limits the blast radius if credentials are compromised.
Security best practices
Use your Alibaba Cloud account only to bootstrap. Create one RAM user with administrative rights, then use that RAM user to create and manage all other RAM users.
Apply least privilege. Grant only the permissions required for the task. For available permission policies, see System policies of Simple Application Server. To define more granular access, see Custom policies for simple application servers.
Enable MFA for console users. Require MFA on all RAM users that log on to the console.
Keep AccessKey pairs out of code. Embedding an AccessKey ID or AccessKey secret in source code exposes all resources in your account if the code is leaked. Use Security Token Service (STS) tokens or environment variables instead. See Credential security solutions.
Enable SSO if your organization uses an identity provider. Single sign-on (SSO) lets RAM users log on from your enterprise identity management system. See Overview of user-based SSO.
Related topics
RAM user groups
Group RAM users that share the same job function so you can manage their permissions in one place rather than updating each user individually.
Security best practices
Apply least privilege to groups. Grant only the permissions required for the group's function.
Keep group membership current. Remove a RAM user from a group when their job duties change.
Revoke unused group permissions. Remove policies from a group as soon as the group no longer needs them.
Related topics
RAM roles
A RAM role is a virtual identity with attached policies but no permanent credentials — no logon password and no AccessKey pair. To use a RAM role, a trusted entity assumes it by calling the AssumeRole API operation, which returns a temporary STS token. The trusted entity then uses that token to access resources as the role.
Because STS tokens expire, RAM roles are well-suited for granting temporary or scoped access without issuing long-term credentials.
Security best practices
Do not frequently change the trusted entity after creation. Changing a role's trusted entity can cause permission loss that affects running workloads. If you add a trusted entity, security risks may arise due to privilege escalation. If you must change it, fully test the change before applying it.
Set the STS token validity period to an appropriate value. STS tokens are valid only until the maximum session duration you configure for the role. We recommend that you set the validity period to an appropriate value to reduce security risks. See Specify the maximum session duration for a RAM role.
Enable SSO if your organization uses an identity provider. SSO lets RAM roles be assumed from your enterprise identity management system. See Role-based SSO.
The maximum validity period of an STS token equals the maximum session duration set for the RAM role. We recommend that you set the maximum session duration for a RAM role to an appropriate value to reduce security risks.