Permission Management
Permission management controls which operations an identity can perform on specific resources. Applying least privilege from the start reduces your attack surface and limits blast radius if credentials are compromised.
Alibaba Cloud supports four authorization methods:
Identity-based authorization: Grant permissions directly to RAM users, user groups, or roles.
Resource-based authorization: Attach permissions directly to specific resources. For example, an OSS bucket policy lets you grant access to RAM users from other accounts or to anonymous users with IP address restrictions.
Control policy: A control policy sets permission boundaries for multi-account organizations that have enabled Resource Directory (RD). It applies uniformly across resource folders and member accounts to establish enterprise-wide or scope-specific access principles. Control policies define boundaries only — they do not grant permissions.
Session policy: During role assumption, a session policy further narrows the permissions available in that session. Like control policies, session policies restrict permissions without granting them.
Regardless of which method you use, the governing principle is least privilege: grant only the permissions an identity needs, and no more.
The following sections describe best practices for applying this principle to human identities, program identities, and multi-account organizations.
Permission management for human identities
Function-based authorization
Different roles in your organization need access to different resource categories. Security administrators typically work with products like Security Center and Cloud Firewall; database administrators work with products like ApsaraDB RDS. Because the resource scope for a given function is consistent across personnel, abstract permissions by job function rather than by individual.
Group users with the same function into a dedicated user group and attach the function's permission policies to the group. When an employee changes roles, update group membership — not individual policies. This approach reduces policy sprawl and keeps authorization consistent.
Resource scope-based authorization
Writing a unique policy for every individual in a large organization is impractical. Authorizing by resource scope lets you reuse policies, simplify audits, and maintain tight boundaries.
Organize resources to match your authorization model:
Multiple Alibaba Cloud accounts: Use Resource Directory to build an enterprise organizational structure. Each account maps to a business application, and you authorize at the account level.
Single Alibaba Cloud account: Use resource groups as isolation boundaries for each project team. Authorize by resource group rather than by individual resource.
Aligning resource structure with authorization scope reduces per-identity policy complexity and keeps permission reviews manageable as the organization grows.
Permission management for program identities
Fine-grained authorization
Application access patterns are predictable — use that predictability to define the minimum required permissions in a custom policy.
For example, an application that displays and accepts user profile pictures needs only GetObject and PutObject on specific OSS buckets. Granting AliyunOSSFullAccess instead gives the application — and any attacker who compromises its credentials — full access to every OSS bucket under the account.
You can start with broader permissions while you learn what your application actually calls. Once your access patterns stabilize, use ActionTrail last-accessed data to identify which permissions are exercised, then tighten the policy to match actual usage. Iterating toward least privilege is more practical than defining the minimal set from scratch.
General best practices
Regular permission reviews
Permissions drift over time — roles change, projects end, and access granted for a short-term task remains indefinitely. Establish a recurring review cycle to ensure every identity's permissions still reflect its current needs.
Focus your reviews on two categories:
Privileged identities: Administrators with broad access to all products, and identities with full access to management and governance products such as RAM, are your highest-risk targets. Confirm that each privileged identity still requires those permissions and that the privilege is held by the minimum number of identities necessary.
Idle permissions: Use ActionTrail operation logs to identify permissions that have not been exercised within your review period. Permissions that show no recent activity are candidates for removal.
For privileged identities, also consider time-bounding access: rather than granting standing admin rights, issue temporary elevated permissions only when a specific task requires them, then revoke them afterward. This just-in-time approach limits the window of exposure even when the permission scope is legitimate.
Setting permission boundaries
For organizations with multiple Alibaba Cloud accounts, use Resource Directory control policies to cap what RAM identities within member accounts can do — regardless of the identity-based policies attached to them. This creates a guardrail layer: member accounts can self-administer within their scope, but cannot exceed the boundaries the central team defines.
Common use cases include prohibiting members from deleting domain names, modifying DNS resolution records, or deleting log records.
Before attaching a control policy to all target nodes (resource folders or member accounts), test it on a small scope first to confirm the policy behaves as intended. Then expand to the full target set.