Resource Access Management:Govern permissions with Access Analyzer

Investigate before acting

Remediation advice is generated based on algorithms and access data, and cannot fully understand your business context. Before applying any recommendation, confirm that the target identity or resource no longer requires the permissions in question.

• For production-critical identities (such as operations roles, CI/CD roles, or RAM roles used by core applications), contact the responsible business owner for confirmation.

• For policy removal recommendations, check the Accessed services, Granted services, and Last accessed time on the finding details page to determine whether the permission is truly unused.

• For external access findings, check the specific external principal on the details page to confirm whether the access relationship is required by your business.

Choose an appropriate change window

Permission convergence may affect running workloads. We recommend:

• Avoid making permission changes during peak business hours or important release windows.

• For RAM identities used by online production applications, verify the impact of equivalent permission changes in a test environment first.

• For cross-account resources (resource directory scenarios), coordinate the change window with the administrator of the target account in advance.

Prepare rollback procedures

Before performing any permission convergence operation, ensure you have the ability to quickly roll back. Specific measures include:

• Record the pre-change state: Before removing a policy, record all policies currently attached to the target identity, including the policy name and type (system or custom).

• Keep a copy of custom policies: Before removing a custom policy, export and back up the policy content to prevent re-authorization failure if the policy definition is accidentally deleted.

• Avoid deleting identities immediately: For inactive RAM users, disable console logon and AccessKeys first. Observe for a period before deciding whether to delete, so you can quickly restore access if errors occur.

• Know the rollback commands: For de-authorization operations performed in the console, you can use RAM OpenAPI (AttachPolicyToUser, AttachPolicyToRole) to quickly restore permissions when needed. For details, see the Rollback and recovery section in this topic.

Finding

A finding is a data object generated by Access Analyzer that contains:

• Finding type: The category of the finding. Examples:

  • super user/role

  • privileged user/role

  • inactive user/role

  • over-privileged user/role

• Status: The status of the finding. Valid values: Active, Resolved, and Archived.

• Resource information: The name, type, and owner of the target resource.

• Timestamps: Created At, Analysis Time, and Updated At.

• Finding ID: The unique identifier of the finding.

Remediation advice

Remediation advice is the solution that Access Analyzer generates for a finding:

• Permission replacement: Replace a policy that grants broad permissions with a more restrictive policy. For example, you can replace the super administrator permission (AdministratorAccess) with the system administrator permission (PowerUserAccess).

• Permission removal: Remove an unused policy.

• Identity management: Disable or delete an inactive identity.

• Finding archival: Archive findings that are associated with intended authorization behaviors.

Decision logic

Access Analyzer classifies over-privileged access by the following priority. If a RAM identity matches multiple conditions, the highest-priority type applies.

Prerequisites

Ensure the following requirements are met:

• An analyzer of the Over-privileged Access type exists in the Access Analyzer console.

• You have the required permissions. We recommend that you grant the AliyunRAMAccessAnalyzerFullAccess and AliyunRAMFullAccess policies to the operator.

Procedure

1. Locate a finding

   1. Log on to the RAM console.

   2. In the left-side navigation pane, choose Access Analysis > Findings.

   3. In the top navigation bar, select the region where the analyzer is located.

   4. On the Findings > Overview tab, find an Active finding of the Inactive User type and click the number.
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      

2. View and apply remediation advice

   1. In the Findings list, select a RAM user that you have confirmed is no longer needed, and click the corresponding Finding ID.

   2. On the Findings details page, click the Advices tab in the Actions column. After a short wait, the system displays the Remove unused identities suggestion. Click Go for Governance.

3. You are redirected to the user details page in the RAM console. You can disable console logon, disable an AccessKey, or delete the user based on your business requirements.

4. Verify the result. Return to the Access Analyzer console. You can archive the finding. Otherwise, its status automatically changes to Resolved after the next analysis cycle.

Remediate privileged users/roles: Remove unused high-risk policies

For a privileged user/role, the remediation advice is to remove unused high-risk permission policies. The procedure is the same as for Remediate super users/roles: Remove unused permission policies.

Remediate inactive users/roles: Disable or delete identities

Inactive identities have had no access activity within the specified unused access period. Long-idle identities with valid credentials are a potential security risk.

Before taking action, confirm: whether the identity is used seasonally or periodically (such as for month-end financial settlements or quarterly audits); whether it is a standby or disaster recovery account (which is typically inactive but critical during failover); for RAM roles, whether a backend service only invokes the role under exceptional conditions (such as emergency operations or alert-handling roles). If any of these apply, archive the finding instead of deleting the identity.

If you confirm the identity is no longer needed, the best practice is to disable first, observe, then delete:

1. On the Findings > Overview or Findings > Findings tab, find an entry of the inactive user/role type and click the specific Finding ID.

2. On the Findings details page, click the Advices tab in the Actions column.

3. On the Advices panel, find the advice to Remove Unused Principals.

4. Perform the appropriate operation based on the resource owner:

   • Current account: Click Go for Governance. You are redirected to the user or role details page in the RAM console. You can clear logon settings, disable or delete an AccessKey, or delete the identity.

     

   • Cross-account: Click Copy Resource URL. Log on to the target account and access the URL to process the request.

     

5. (Optional) If the analyzer does not provide remediation advice, see Why is there no remediation advice for my finding?

Remediate over-privileged users/roles: Remove unused policies

For an over-privileged user/role, the remediation advice is to remove unused permission policies. The procedure is the same as for Remediate super users/roles: Remove unused permission policies.

Investigation workflow

Before remediating external access findings, follow these investigation steps:

1. Identify the external principal: On the finding details page, check the specific external principal. For OSS Buckets, check whether it includes anonymous users (AllUsers) or specific Alibaba Cloud accounts. For RAM roles, review the trusted entities in the trust policy.

2. Determine whether the access is business-required: Check if the external access is part of normal business collaboration (such as partner account access, cross-department resource sharing within a group, or cross-account deployment in a multi-cloud architecture).

3. Verify the permission scope is appropriate: Even if external access is expected, check that the granted permissions follow the least privilege principle. For example, whether a partner has been granted overly broad operation permissions.

4. Coordinate across accounts: If the external access involves other Alibaba Cloud accounts, confirm the business dependency with both the accessing party and the resource owner before tightening policies, to avoid disrupting partner business.

Remediate OSS Bucket external access

External access to OSS Buckets typically results from Bucket Policy, Bucket ACL configurations, or the absence of the "Block Public Access" setting.

If the external access is expected (for example, a partner needs to read a specific Bucket):

1. Check that the current authorization follows the least privilege principle. For example, verify that only necessary Object-level operations (such as GetObject) are granted, rather than full Bucket-level permissions.

2. Narrow the authorization scope in the Bucket Policy from wildcards (*) to specific account IDs or RAM role ARNs.

3. Archive the finding to prevent repeated alerts.

If the external access is unexpected (for example, the Bucket is configured for public access):

1. Go to the OSS console and enable the Bucket-level "Block Public Access" feature. This globally prevents public access to the Bucket and is the quickest remediation measure.

2. Review the Bucket Policy and remove any unintended cross-account authorization or anonymous access (Principal set to *) configurations.

3. Check the Bucket ACL to ensure it is not set to "Public Read" or "Public Read/Write".

4. After making changes, wait for the external access analyzer to re-analyze (typically 3-5 minutes after a policy change) and confirm that the finding status changes to "Resolved".

Remediate RAM role cross-account trust

A RAM role's trust policy determines which external identities can assume the role. An overly permissive trust policy creates cross-account privilege escalation risks.

If the cross-account trust is expected (such as cross-account authorization in a multi-cloud architecture):

1. Review the Condition elements in the trust policy. Add constraints where possible (such as specifying source IP ranges or requiring MFA) to reduce the blast radius of a credential leak.

2. Review the permissions policies attached to the role and ensure they follow the least privilege principle.

3. Archive the finding.

If the cross-account trust is unexpected:

1. Go to the RAM console, open the role details page, and edit the trust policy.

2. Narrow the Principal scope in the trust policy to include only the necessary account IDs or service identifiers.

3. Remove any unnecessary wildcard authorizations or authorizations for expired accounts.

4. After making changes, monitor the dependent business systems. Pay special attention to applications that assume this role from other accounts — if the tightened trust policy causes STS AssumeRole failures, restore the policy immediately.

Restore detached permission policies

If you detached a policy using the Access Analyzer console, use the following OpenAPI commands to re-attach it:

• RAM user: aliyun ram AttachPolicyToUser --PolicyType <System|Custom> --PolicyName <PolicyName> --UserName <UserName>

• RAM role: aliyun ram AttachPolicyToRole --PolicyType <System|Custom> --PolicyName <PolicyName> --RoleName <RoleName>

• User group: aliyun ram AttachPolicyToGroup --PolicyType <System|Custom> --PolicyName <PolicyName> --GroupName <GroupName>

Restore disabled identities

• RAM user: If you only disabled console logon and AccessKeys, re-create the logon configuration (CreateLoginProfile) and re-enable AccessKeys (UpdateAccessKey --Status Active).

• RAM role: If you deleted the role without backing up the trust policy and attached policy information, you must manually re-create and configure it.

Restore a modified RAM role trust policy

If modifying a trust policy caused cross-account business issues, restore the original trust policy immediately:

1. Go to the RAM console and open the Trust Policy tab on the role details page.

2. If you backed up the original trust policy, paste it back directly.

3. If you did not back up, manually re-add the mistakenly removed trusted entities. For uncertain account IDs, query recent AssumeRole call records in ActionTrail to identify which external identities have legitimately assumed the role recently.

Restore archived findings

If a finding was archived by mistake, filter the finding list by Archived status, locate the entry, and click Unarchive. The finding returns to Active status.

• Analyzer type: This feature supports only analyzers of the Over-privileged Access type and does not support analyzers of the External Access type.

• Supported granularity: The over-privileged access analyzer analyzes the permissions of all RAM identities except service-linked roles in a resource directory or the current account based on permission audit information. The supported policy types, cloud services, and granularity are the same as for permission auditing, as listed in Services that work with the permission audit feature. If a policy contains permissions for unsupported services, the analyzer cannot provide remediation advice for removing permissions.

• Policy type (for super administrator replacement only): The remediation advice for replacing permissions of super administrators supports only the AdministratorAccess system policy. Custom administrator policies are not supported.

• Policy content: If a policy contains a Deny or NotAction statement, the analyzer cannot provide remediation advice for removing permissions.

• Authorization scope: If the authorization scope of an administrator permission is a Resource Group instead of an Account, the identity is not identified as a super administrator.

• Authorization method: Permissions can be granted directly to a user or role, or inherited through a user group. The analyzer can identify both authorization methods but does not provide automatic remediation advice for permissions inherited from a user group. You must remediate these findings manually.

• Data latency : Remediation advice is generated from findings, which may have a data latency of up to 24 hours. If the timeliness of the advice is critical, you can manually trigger a rescan by clicking Rescan on the finding details page and then check the advice again.

  

FAQ