Access auditing helps you achieve the principle of least privilege by providing information about when your Resource Access Management (RAM) identities last accessed specific services and actions. You can use this information to analyze permissions, identify unused access, and confidently remove unnecessary policies from your RAM users and roles.
Key concepts and considerations
Before using access auditing to refine permissions, review the following key considerations.
Tracking period and data latency
Access tracking began on February 1, 2024. Any access attempts made before this date are not included in auditing reports. Last-accessed data may have a latency of up to 24 hours.
Access attempts vs. Successful access
Access auditing records all API access attempts, including both successful and denied requests made through the Alibaba Cloud Management Console, CLI, or SDKs. An access event in a report does not necessarily mean an action was successful or that your account was compromised. For detailed information about specific API calls, including their success or failure status, review your ActionTrail logs.
Report generation and ownership
An access auditing report is generated on demand for a specific RAM identity. Only the identity that requests the report can view its details. For example, if you use an STS token from a RAM role to generate a report via the API, you must use an STS token from the same role to view the report's details.
Supported policy types
Access auditing analyzes only identity-based policies attached to RAM users, user groups, and roles. It does not analyze other policy types, such as resource-based policies (such as an OSS bucket policy), control policies in a resource directory, or session policies.
Auditing granularity
Service level
This level of auditing shows which cloud services a RAM identity has permission to access and when each service was last accessed. You can use this high-level view to identify and remove entire system policies that are no longer needed.
Action level
For supported services, this level provides a more detailed analysis of individual API actions. You can see which specific actions a RAM identity has permission to use and when each action was last accessed. This is useful for refining custom policies and restricting high-risk permissions.
Action-level auditing tracks control plane operations recorded by ActionTrail. It does not track data plane operations, such as
oss:GetObject.It does not track permissions that are not associated with a specific API action, such as
ram:PassRole.
For a list of supported services and their auditing granularity, see Services that work with Access Auditing.
Unsupported use cases
In some cases, an Alibaba Cloud service performs a permission check on your behalf when calling another service's API. For example, when you use Resource Center to search for resources, it checks your permissions for other services to filter the results. These indirect permission checks are not recorded by access audit. APIs that involve such checks include:
Cloud service | Service code | API |
Resource Center | resourcecenter | SearchResources |
GetResourceCounts | ||
GetResourceConfiguration | ||
ListResourceTypes | ||
ExecuteSQLQuery | ||
Resource Management | resourcemanager | ListResources |
Tag | tag | ListTagResources |
ListTagKeys | ||
ListTagValues |
View access auditing reports
You can view access auditing reports for RAM users and RAM roles directly in the RAM console.
Log on to the RAM console as a RAM administrator.
In the left-side navigation pane, choose Identities and then select either Users or Roles.
Click the name of the user or role you want to audit.
On the details page, select the Access Audit tab. The system will generate a new report.
Once the report is ready, you can review the last-accessed information for each service and, where supported, drill down to view action-level details by clicking View Actions.
Troubleshoot common errors
Why is my access auditing report empty?
An empty report can occur if the RAM identity has no identity-based policies attached, the attached policies grant no permissions, or the granted permissions are for services not yet supported by access auditing.
"InvalidParameter.Policy.Statement" error
This error indicates a syntax or formatting issue in an attached policy. The error message will specify the policy name. Review the policy's JSON structure, correct the error, and generate the report again.
"InvalidParameter.Policy.NotAction" error
This error means a NotAction element in a policy contains an invalid or unrecognized action. Correct the specified policy and generate the report again.
"LengthExceedLimit.Policy" error
This error occurs when an attached policy is too large for the system to analyze. To resolve this, split the large policy into smaller, more focused policies and attach them to the identity, then generate the report again.