Identify and reduce over-authorization using access analytics-Well-Architected Framework(WAF)-阿里云帮助中心

Overview

Proper permission settings are essential to prevent unauthorized access and protect your cloud assets and data. The core principle of permission management is the Principle of Least Privilege (PoLP), which states that you should grant only the minimum permissions required for an identity to perform its tasks. This solution uses Resource Access Management (RAM) access analytics to help you identify over-authorized identities in the cloud. You can then reduce unused permissions to mitigate security risks that arise from over-authorization.

Advantages

Continuously analyze and identify over-authorization

The over-authorization analyzer in Access Analyzer helps you identify over-authorized identities within your resource directory or current account. The analyzer continuously monitors all RAM identities, including RAM users and RAM roles, and generates findings for over-authorized identities.

Unified analysis across multiple accounts

Access Analyzer supports unified access analysis in a multi-account environment that is based on a resource directory. This simplifies unified auditing and administration for enterprises.

Real-time notifications for analysis findings

You can use EventBridge to listen for and consume findings from Access Analyzer. This lets you notify your operations and maintenance (O&M) and security teams through channels such as text messages and emails, which ensures that you can manage permissions in a timely manner.

Customer scenarios

Unified monitoring and reduction of identity permissions

Scenario description

During the daily use of Alibaba Cloud accounts, enterprises may manage permissions without strict controls, which can lead to over-authorization. This gives cloud identities permissions beyond their job responsibilities, especially privileged permissions. Enterprises want to consistently identify these over-authorized identities and reduce their permissions to mitigate security risks to cloud assets and data.

Applicable customers

Enterprise customers with central O&M or audit teams.
Enterprise customers with independent compliance teams.
Enterprises that have loose permission management and want to implement fine-grained permission controls.

Architecture

This solution uses RAM access analytics to help you identify over-authorized identities in your resource directory or current account. The analyzer continuously monitors all RAM identities, including RAM users and RAM roles, and generates findings for any that are over-authorized. First, you can use RAM access analytics in your management account to create an over-authorization analyzer. This analyzer scans the permissions of all RAM users and roles across all accounts in your organization to check for unused permissions, privileged permissions, and other issues (Step 1 in the diagram). Then, you can use EventBridge to listen for and consume the analysis findings. You can notify your O&M and security teams through channels such as text messages and emails (Steps 2 and 3). Based on the findings, you can reduce permissions. For example, you can deny privileged permissions or remove unused permissions to lower enterprise security risks (Step 4).

Product billing and terms

Product Fees

Product Name	Product Description	Product Fees
Resource Directory (RD)	Resource Directory (RD) is a service that provides multi-level account and resource relationship management for enterprise customers.	Free
EventBridge	EventBridge is a serverless event bus service provided by Alibaba Cloud. It routes events between applications using the standard CloudEvents 1.0 protocol, helping you easily build loosely coupled, distributed, event-driven architectures.	Free during public preview. For more information, see Billing.
Resource Access Management (RAM)	Resource Access Management (RAM) is a service provided by Alibaba Cloud for managing user identities and resource access permissions.	Free

Glossary

Name	Description
Management account	When an enterprise has multiple Alibaba Cloud accounts, this refers to the administrator account that has permission to manage resources in other accounts. It is used to manage multiple accounts, uniformly configure identity permissions, view bills for all member accounts, and configure and apply audit rules to member accounts.
Access policy	A mechanism used to define and control the operations that RAM identities can perform and the resources they can access. Access policies are categorized as system policies and custom policies.
Access analytics - over-authorization analyzer	The over-authorization analyzer helps you identify and view over-authorized identities within your resource directory or current account. The analyzer continuously monitors all RAM identities (RAM users and RAM roles) in your resource directory or current account and generates findings for those that are over-authorized. The findings include superusers/roles, privileged users/roles, inactive users/roles, and over-privileged users/roles. Each finding also provides details about the permissions the identity has and the last time those permissions were accessed.
Permission audit	The permission audit feature helps you identify the permissions that a RAM identity has and the last time those permissions were accessed. You can use this information to identify unused permissions and safely remove them to follow the Principle of Least Privilege (PoLP) for RAM identities.
Superuser/role	A RAM identity (RAM user or RAM role) that has permission to manage all resources within an account. For example, a RAM user or RAM role that is granted the AdministratorAccess policy.
Privileged user/role	A RAM identity (RAM user or RAM role) that has important privileged permissions. RAM identities with these privileges can often escalate their own permissions or those of other RAM identities, allowing them to gain higher access permissions. For a detailed list of privileges, see Privilege list.
Inactive user/role	A RAM identity (RAM user or RAM role) that has not accessed any permissions within the specified idle access period.
Over-privileged user/role	A RAM identity (RAM user or RAM role) that has unused service-level and action-level permissions within the specified idle access period.
Standard role	Standard roles allow customers to create and manage them independently. Customers need to define a role name, select a trusted entity, and customize access policies. Standard roles can be divided into the following two types. Standard user role: A type of standard role, typically created by customers and trusted by users or identity providers. It is used for role assumption by the customer or IdP, for example, to implement role-based single sign-on (SSO). Standard service role: A type of standard role where the customer must define the role name, select a cloud service as the trusted entity, and customize the access policy. This role is trusted by a cloud service and assumed by it to perform a specific function. Examples include the `AliyunCSDefaultRole` and `AliyunCSKubernetesAuditRole` roles used by Container Service for Kubernetes.
Service-reserved role	This role has the `AliyunReserved` prefix. Its lifecycle is managed by the corresponding cloud service. Customers must perform operations on the role within the corresponding cloud service. Management operations are not allowed in the RAM console or through RAM APIs.

Security

Access analytics security

Access analytics does not modify your existing RAM identities or policies and does not affect your RAM authorization behavior. This ensures that the analysis process is non-intrusive and does not interfere with your existing configurations.

Notes

Support scope of the access analytics over-authorization analyzer

The over-authorization analyzer for access analytics reviews permission audit information for all RAM identities (except service-linked roles) in the resource directory or current account. It then uses this information to generate findings. The permission audit feature provides information about the permissions a RAM identity has and the last time those permissions were accessed. Therefore, the policy types, Alibaba Cloud services, and audit granularities supported by the over-authorization analyzer are the same as those for permission auditing. For more information, see Overview of permission auditing.

Notes on permission auditing

Read the following notes carefully when you use the permission audit feature of access analytics to analyze and manage RAM identity permissions. For more information, see Overview of permission auditing.

Permission audit tracking period

The access tracking period began on February 1, 2024. Access attempts before this date are not recorded. Data for the last access time has a latency of no more than 24 hours.

Supported policy types for permission auditing

Permission auditing analyzes only identity-based policies, which are access policies granted to RAM users, RAM user groups, and RAM roles. Permission auditing does not analyze other types of access policies, including resource-based policies (such as OSS bucket policies), control policies in a resource directory, or session policies.

Supported audit granularities for permission auditing

Service level: Analyzes the permissions and access of a RAM identity at the Alibaba Cloud service dimension. You can view the Alibaba Cloud service permissions granted to a RAM identity, the services it has accessed, and the last time it accessed them. You can use this information to revoke unused system policies or to reduce administrator permissions to management permissions for specific Alibaba Cloud services. For a list of Alibaba Cloud services that support service-level auditing, see Alibaba Cloud services that support permission auditing.
Action level: Extends the service-level analysis to specific API actions. It analyzes the permissions and access of a RAM identity at the action dimension. You can view the specific API action permissions granted to a RAM identity, the API actions it has accessed, and the last time it accessed them. You can use this information for fine-grained access control for applications or to revoke critical permissions. For a list of Alibaba Cloud services that support action-level auditing, see the services marked as Action level in the Audit Granularity column in Alibaba Cloud services that support permission auditing.

Permission auditing supports only control plane operations that are integrated with ActionTrail. It does not support data plane operations on data stored in Alibaba Cloud services, such as GetObject for OSS.

Procedure

Preparations

If you want to perform multi-account access analysis based on a resource directory, you must enable Resource Directory and set up a multi-account architecture. For more information, see Enable a resource directory.
To use EventBridge to notify your O&M team of access analysis findings, you must enable EventBridge. For more information, see Activate EventBridge and grant permissions.

Implementation time

After you complete the preparations, the estimated implementation time for this solution is 60 minutes.

Procedure

Create an over-authorization analyzer

You can create an over-authorization analyzer in any region. Centralized resources such as RAM roles and RAM users can be monitored and analyzed by an analyzer in any region. Analysis findings are not affected by the region.

Log on to the management account as a RAM administrator and go to the RAM console. In the navigation pane on the left, choose Access Analytics > Analyzers.
In the top menu bar, select a region.
Click Create Analyzer. Enter an analyzer name, set Analyzer Type to Over-authorization, and set the idle access period and analysis scope. The Idle Access Period determines the threshold for identifying idle permissions. The value can be from 1 to 365 days. The default value is 90 days. For example, if you set the Idle Access Period to 90, permissions that have not been used for more than 90 days are considered idle. Set Analysis Scope to Resource Directory. You can also select Current Account to analyze access only for the current account. Finally, click Create Analyzer.

After you create the analyzer, it starts to detect RAM identities and permissions. You must wait for some time before you can view the analysis findings.

Configure EventBridge notifications (Optional)

You can use EventBridge to send access analysis findings to your O&M and security teams through channels such as text messages and emails. This lets you detect unexpected over-authorization in a timely manner and reduce enterprise security risks.

Log on to the management account and go to the EventBridge console. In the navigation pane on the left, click Event Buses.
In the top menu bar, select a region. This region must be the same as the region where you created the over-authorization analyzer in the previous step.
In the Alibaba Cloud service event bus, click Create Rule.
Enter a rule name to configure basic information, and then click Next to configure the event pattern. The parameters are as follows:
1. Event Source Type: Select Alibaba Cloud service event source.
2. Event Source: Select acs.accessanalyzer for access analytics.
3. Event Type: Different analysis findings correspond to different event types. Select the event types as needed. We recommend that you select all the following types.
accessanalyzer:InactiveRole:Finding/accessanalyzer:InactiveUser:Finding: Inactive role/user.
accessanalyzer:OverPrivilegedRole:Finding/accessanalyzer:OverPrivilegedUser:Finding: Over-privileged role/user.
accessanalyzer:PrivilegeEscalationRole:Finding/accessanalyzer:PrivilegeEscalationUser:Finding: Privileged role/user.

accessanalyzer:SuperRole:Finding/accessanalyzer:SuperUser:Finding: Superuser role/user.

Pattern Content: You can further filter events using the pattern content. For example, the following pattern filters for valid access analysis events (events that are not archived or deleted).

{
  "source": [
    "acs.accessanalyzer"
  ],
  "type": [
    "accessanalyzer:InactiveRole:Finding",
    "accessanalyzer:InactiveUser:Finding",
    "accessanalyzer:OverPrivilegedRole:Finding",
    "accessanalyzer:OverPrivilegedUser:Finding",
    "accessanalyzer:PrivilegeEscalationRole:Finding",
    "accessanalyzer:PrivilegeEscalationUser:Finding",
    "accessanalyzer:SuperRole:Finding",
    "accessanalyzer:SuperUser:Finding"
  ],
  "data": {
    "status": [
      "Active"
    ],
    "isDeleted": [
      false
    ]
  }
}

Click Next to configure the event target. You can use channels such as email or DingTalk to receive notifications about over-authorization risk events.

View analysis findings

The analyzer generates findings for four types of over-authorization scenarios:

Superuser/role: A RAM identity (RAM user or RAM role) that has permission to manage all resources within an account. For example, a RAM user or RAM role that is granted the AdministratorAccess policy.
Privileged user/role: A RAM identity (RAM user or RAM role) that has important privileged permissions. RAM identities with these privileges can often escalate their own permissions or those of other RAM identities, allowing them to gain higher access permissions. For a detailed list of privileges, see Privilege list.
Inactive user/role: A RAM identity (RAM user or RAM role) that has not accessed any permissions within the specified idle access period.
Over-privileged user/role: A RAM identity (RAM user or RAM role) that has unused service-level and action-level permissions within the specified idle access period.

You can view the analysis findings in two ways. First, you can view them on the Analyzers page.

Log on to the management account as a RAM administrator and go to the RAM console. In the navigation pane on the left, choose Access Analytics > Analyzers.
Select the over-authorization analyzer that you created in the "Create an over-authorization analyzer" section and click its name to go to the analyzer details page.
On the Analysis Findings tab, view the findings.

Second, you can view the analysis findings on the Analysis Findings page.

Log on to the management account as a RAM administrator and go to the RAM console. In the navigation pane on the left, choose Access Analytics > Analysis Findings.
Select the over-authorization analyzer that you created in the "Create an over-authorization analyzer" section and click its name.
On the Findings List tab, view the findings.
The Analysis Findings page also provides a graphical data overview. Click the Data Overview tab to view the graphical display of the findings.

Analyze and handle over-authorization

For resources, such as RAM users and roles, that require action based on the analysis findings, go to the details page of a finding. On this page, you can check the access records to confirm whether the authorization behavior for the RAM identity is expected.

Go to the analysis findings page described in the "View analysis findings" section.
In the list of findings, click a Finding ID to view the details for the corresponding resource (RAM user/role).

Using the access records on the Details tab, you can analyze privileged grants and unused permissions to determine if the authorization behavior is expected. In the access records list, pay close attention to the following:

If the last access time is No access, the permission for that Alibaba Cloud service is likely unused. Evaluate whether this is expected based on the role of the RAM user or role user. Note that the access tracking period for access analytics began on February 1, 2024. Access attempts before this date are not recorded.
If a Privileged tag appears after the Alibaba Cloud service name, it means you have granted privileged permissions to the RAM identity. In this case, click View Authenticated Actions in the Actions column to view the call history of specific operations for the service. Focus on operations with the Privileged tag in the authenticated actions list and, combined with the last access time, evaluate whether it is expected for the RAM identity to have this privileged permission.

Based on the analysis findings, you can:

For authorization behavior that meets your expectations, click Archive Finding to archive it.
For authorization behavior that does not meet your expectations, click Go to Governance (for resources in the current account) or Copy Resource URL (for resources in other accounts) to navigate to the corresponding page for remediation.

The handling method varies for different types of findings. You need to process different over-authorization scenarios based on the findings and your enterprise's actual usage using ActionTrail information. You can follow the order below to handle different over-authorization scenarios.

Preparations

Confirm RAM user activity

When you handle over-authorization for a RAM user, you must first verify the user's activity to help you make decisions. This includes the following information:

Whether the RAM user has logged on to the console. Go to the RAM user's details page and, on the Authentication Management tab, check the Last Console Logon Time. If a time is displayed, the RAM user has logged on to the console.
Whether the RAM user has an AccessKey. Go to the RAM user's details page and, on the Authentication Management tab, check if an AccessKey has been created in the AccessKey list.
If the RAM user has an AccessKey, you need to further confirm whether it has been used. In the AccessKey list, check the Last Used Service / Time. If a service and time are displayed, the RAM user's AccessKey has been used.

Processing path for RAM roles

Access analytics analyzes the following two types of roles.

Standard role: Standard roles allow customers to create them independently. Customers need to define a role name, select a trusted entity, and customize access policies. Standard roles can be divided into the following two types.
- Standard user role: A type of standard role, typically created by customers and trusted by users or identity providers. It is used for role assumption by the customer or IdP, for example, to implement role-based SSO.
- Standard service role: A type of standard role where the customer must define the role name, select a cloud service as the trusted entity, and customize the access policy. This role is trusted by a cloud service and assumed by it to perform a specific function. Examples include the AliyunCSDefaultRole and AliyunCSKubernetesAuditRole roles used by Container Service for Kubernetes.
Service-reserved role: This role has the AliyunReserved prefix. Its lifecycle is managed by the corresponding cloud service. Customers must perform operations on the role within the corresponding cloud service. Management operations are not allowed in the RAM console or through RAM APIs.

The processing path differs for different types of roles:

Standard user role: Customers can manage the lifecycle of these roles in the RAM console. Over-authorization for these roles can be handled and optimized directly in the RAM console or through RAM APIs. For detailed optimization operations, see the sections below.
Standard service role: Unless you are certain that you will no longer use the corresponding cloud service, do not make any modifications or deletions to avoid affecting the service. For findings related to these roles, you can directly archive them.
Service-reserved role: Over-authorization for these roles must be handled and optimized within the corresponding cloud service. Decide whether to handle these roles based on the service's functionality. This is especially true for CloudSSO access configurations. When you deploy an access configuration in CloudSSO, a RAM role named AliyunReservedSSO-<Access Configuration Name> is created in all accounts where it is deployed. These roles with the same name in different accounts also have the same permission configuration. Therefore, you cannot determine the overall usage of the CloudSSO access configuration from the analysis findings of a single account. For findings related to these roles, you can directly archive them. You can also perform aggregate analysis across multiple accounts based on the role name. If you identify over-authorization and need to handle it, you must adjust the permission settings of the corresponding access configuration in CloudSSO. For more information, see Overview of access configurations.

Additionally, if you decide not to handle or optimize standard service roles and service-reserved roles in the future, you can ignore them in the analysis findings. You can use an archive rule to automatically archive findings for these roles.

On the Analysis Findings page, add the following two filter conditions to filter the results.
1. Filter condition: Resource, Match by: Contains, Filter value: aliyun
2. Filter condition: Resource Type, Match by: Equals, Filter value: RAM - Role
Click Save as Archive Rule. After you set the rule, new findings that match the rule will be automatically archived.
However, findings generated before the rule was set will not be automatically archived. If needed, you can click Apply Archive Rules on the analyzer details page to archive them.

Superuser/role

If the finding type in the analysis findings list is Superuser/role, it means the RAM user or role has permission to manage all resources in the account. For example, a RAM user or RAM role that is granted the AdministratorAccess policy.

For this type of finding, your O&M team must first confirm whether the RAM identity needs Administrator permissions. Generally, only a few identities in an enterprise, such as the head of O&M, should be granted permission to manage all resources in an account. Keep the number of RAM identities with Administrator permissions to three or fewer to avoid business impact from identity compromise.

If you confirm that the superuser/role is expected, you can click Archive Finding in the analysis findings to archive it.
If it is not expected, handle the RAM user and RAM role separately as described below. Your modifications to the RAM user and role will trigger a re-run of the access analysis, usually with a 3-5 minute delay. After you make the changes, you can check the analysis findings later to see if the over-authorization issue for the RAM identity has been resolved.

RAM user

For RAM users with different usage patterns, take the following steps for targeted handling.

1. The RAM user has logged on to the console

The employee using this RAM user is typically responsible for cloud O&M. You can reduce their permissions using a permission template. You can use the superuser permission template, which allows them to create, view, and operate all Alibaba Cloud services but not manage identity permissions, account architecture, or financial linking.

Create a new custom policy. On the Create Policy page, click Import Policy, and select and import the appropriate permission template based on the employee's role. For more information, see Create a custom policy.In addition to the superuser template, Alibaba Cloud also provides the following common permission templates for employee roles. If the employee who uses the RAM user has a clear job function, you can grant permissions based on their role using a template:
1. Superuser: Responsible for cloud O&M. Can create, view, and operate all Alibaba Cloud services, but cannot manage identity permissions, account architecture, or financial linking.
2. Financial staff: Responsible for enterprise finance. Can view bills, make payments, issue invoices, and use financial analysis features. Has full permissions for the finance and billing system.
3. Network administrator: Responsible for building and managing the enterprise's network architecture. Can enable, purchase, and create network services. Has full permissions for network services and ECS security groups.
4. Database administrator: Responsible for enterprise database O&M. Can enable, purchase, and create database services. Has full permissions for database services.
5. Security administrator: Responsible for enterprise cloud security. Can enable and purchase cloud security services, and create and implement security rules. Has full permissions for security services.
6. Audit administrator: Has full permissions for Cloud Config, ActionTrail, and Log Management. Can also query the status of all Alibaba Cloud resources.
Grant the new custom policy to the RAM user and detach any policies with Administrator permissions (including the AdministratorAccess system policy and any custom policies with Administrator semantics). For more information, see Grant permissions to a RAM user and Revoke permissions from a RAM user.
If the RAM user also has an AccessKey, this violates the principle of single responsibility. You should separate these functions as soon as possible to ensure that a RAM user is used for either console logon or programmatic access with an AccessKey, but not both.

2. The RAM user has not logged on to the console but has an AccessKey.

If the AccessKey has never been used. This type of RAM user is likely idle and should be removed.
1. Disable console logon. On the RAM user details page, in the Console Logon Management section of the Authentication Management tab, click Modify Logon Settings and set Console Access to Disabled. For more information, see Manage console logon settings for a RAM user.
2. Disable the AccessKey. You should disable the AccessKey first to prevent security risks from compromise. If your business team needs to use the AccessKey later, you can enable it with one click in the console. For more information, see Disable an AccessKey of a RAM user.
3. After a period of observation, if you confirm the AccessKey is not needed, delete the AccessKey and then delete the RAM user. For more information, see Delete an AccessKey of a RAM user and Delete a RAM user.
Otherwise (the AccessKey has been used), reduce the permissions as follows.
1. Disable console logon. On the RAM user details page, in the Console Logon Management section of the Authentication Management tab, click Modify Logon Settings and set Console Access to Disabled. For more information, see Manage console logon settings for a RAM user.
2. Reduce unused permissions. Alibaba Cloud provides a permission audit feature to help you identify the permissions a RAM identity has and the last time they were accessed. Note that the access tracking period for permission auditing began on February 1, 2024. If the AccessKey was last used before this date, it will not be recorded in the permission audit. Therefore, regardless of whether the RAM user has permission access activity in the permission audit, your O&M and business teams need to work together to confirm the operational permissions required by the AccessKey in specific business scenarios. Safely remove unused or unneeded permissions to follow the Principle of Least Privilege (PoLP) for RAM identities.
On the over-authorization analyzer's findings page, click Go to Governance (for resources in the current account) or Copy Resource URL (for resources in other accounts) to go to the permission audit page for the RAM user. Use the permission audit to confirm which Alibaba Cloud services have been accessed. For services that support action-level auditing, click View Authenticated Actions in the Actions column to see which API actions have been called.
Your O&M and business teams should work together to confirm the Alibaba Cloud services and APIs actually called by the AccessKey in your business. Combined with the permission audit results from the previous step, determine the true minimum required permissions for the AccessKey.
Create a new custom policy with the reduced permissions confirmed in the previous step. Then, grant the custom policy to the RAM user and detach any policies with Administrator permissions (including the AdministratorAccess system policy and any custom policies with Administrator semantics). For more information, see Create a custom policy, Grant permissions to a RAM user, and Revoke permissions from a RAM user. Reduce permissions gradually. First, reduce to the service level by granting FullAccess permissions for the Alibaba Cloud services actually called by the AccessKey. After observing no impact on your business, further reduce permissions to the API action level. During this process, closely monitor your business. If it is affected, immediately roll back using the policy version feature (for more information, see Manage custom policy versions) or reattach the original policy with Administrator permissions to the RAM user.

3. The RAM user has not logged on to the console and has not created an AccessKey.

These RAM users appear to be inactive. We recommend removing them promptly.

Disable console logon. On the RAM user details page, in the Console Logon Management section of the Authentication Management tab, click Modify Logon Settings and set Console Access to Disabled. For more information, see Manage console logon settings for a RAM user.
Delete the RAM user. If you confirm the RAM user is not actually used, delete it directly. For more information, see Delete a RAM user.

RAM role

Currently, Alibaba Cloud cannot identify the last time a RAM role was assumed, which makes it difficult to accurately determine its usage. Therefore, optimizing over-authorized RAM roles depends on your own decisions. On the over-authorization analyzer's findings page, click Go to Governance (for resources in the current account) or Copy Resource URL (for resources in other accounts) to go to the permission audit page for the RAM role. You can use the permission audit to confirm if the RAM role has accessed any Alibaba Cloud services to help you make a decision.

If the RAM role is a standard service role or a service-reserved role, do not make any modifications unless you are certain of its usage. You can directly archive the analysis finding. You can use an archive rule to automatically archive findings for these roles as described in the "Preparations - Processing path for RAM roles" section.
For other standard user roles, if you confirm the RAM role is not actually used or will not be used in the future, delete it directly. For more information, see Delete a RAM role.
Otherwise, reduce unused permissions as soon as possible.
- Your O&M and business teams should work together to confirm the Alibaba Cloud services and APIs actually called by the RAM role in your business. Combined with the permission audit results, determine the true minimum required permissions for the RAM role.
- For standard user roles, create a new permission policy in the RAM console with the reduced permissions, attach it to the RAM role, and detach any policies with Administrator permissions (including the AdministratorAccess system policy and any custom policies with Administrator semantics). For more information, see Create a custom policy, Grant permissions to a RAM role, and Remove permissions from a RAM role.

Reduce permissions gradually. First, reduce to the service level by granting FullAccess permissions for the Alibaba Cloud services actually used by the RAM role. After observing no impact on your business, further reduce permissions to the API action level. During this process, closely monitor your business. If it is affected, immediately roll back or reattach the original policy with Administrator permissions.

Privileged user/role

Go to the finding details page. Using the access records on the Details tab, you can analyze the privileged grants in detail. If a Privileged tag appears after the Alibaba Cloud service name, it means the permissions granted to the RAM identity include privileged permissions. For a detailed list of privileges, see Privilege list.

In this case, click View Authenticated Actions in the Actions column to view the call history of specific operations for the service.

Focus on operations with the Privileged tag in the authenticated actions list and, combined with the last access time, evaluate whether it is expected for the RAM identity to have this privileged permission. When you handle the finding, on the over-authorization analyzer's findings page, click Go to Governance (for resources in the current account) or Copy Resource URL (for resources in other accounts) to go to the permission audit page for the RAM identity. You can use the Policy Granting Permission information in the permission audit list to confirm which access policy defines the privileged permission. This information will help you with optimization.

The handling method varies slightly for different RAM identities. For detailed handling operations, see the sections below. During the process, closely monitor your business. If it is affected, roll back immediately.

RAM user

If the last access time for the privileged action is No access, the action has not been called since February 1, 2024. You should reduce the permission.
- First, on the finding details page, switch to the Governance Suggestions tab. Access analytics provides governance suggestions based on the findings. For access policies that have not been used within the idle access period, it provides a one-click detach capability to help you quickly reduce unused permissions. Note that only the resource owner of the finding can perform governance operations.
- If the permission for the privileged action is not defined in the unused access policy from the previous step, which means the access policy that contains the privileged action has been used within the idle access period, you need to further detach or deny the privileged action.
If the policy that grants the privileged permission is a custom policy and the permission is explicitly defined, such as in the following policy example which explicitly grants the ram:UpdateAccessKey permission, you can directly modify the custom policy to remove the privileged permission from the policy content.
```
{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ram:UpdateAccessKey"
      ],
      "Resource": "*"
    }
  ]
}
```

If the policy that grants the privileged permission is a custom policy but the permission is not explicitly specified and uses a wildcard character, you can deny the privileged permission using a Deny statement, as shown in the following example.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ram:*"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "ram:UpdateAccessKey"
      ],
      "Resource": "*"
    }
  ]
}

If the policy that grants the privileged permission is a system policy, you can create a new custom policy that denies the privileged permission using a Deny statement. Then, attach the custom policy to the RAM user. For more information, see Create a custom policy, Grant permissions to a RAM user, and Revoke permissions from a RAM user.
If the privileged action has a recent access time, which means it was recently called, you need to confirm if this privileged permission is expected.
If the RAM user has console access, confirm whether the employee who uses the RAM user truly needs this privileged permission for their job function.
If the RAM user has an AccessKey, confirm whether the business scenario and application that use the AccessKey truly need to call this privileged action.

The confirmation process requires joint decision-making from your O&M and business teams.

If you confirm that the privileged action needs to be retained, you can directly archive the analysis finding.
If you confirm that the privileged action is no longer needed, you should reduce it. For specific operations, refer to the handling method for privileged actions that have not been called.

RAM role

If the RAM role is a standard service role or a service-reserved role, do not make any modifications unless you are certain of its usage. You can directly archive the analysis finding. You can use an archive rule to automatically archive findings for these roles as described in the "Preparations - Processing path for RAM roles" section.
For other types of RAM roles (standard user roles), follow the handling method for RAM users described earlier. You can perform optimization directly in the RAM console or through RAM APIs.

Inactive user/role

If the finding type in the analysis findings list is Inactive user/role, it means the RAM user or role has not had any permission access activity within the specified idle access period. This does not necessarily mean the RAM identity is idle. You need to further confirm the identity's usage to handle it accordingly.

The handling method varies slightly for different RAM identities. For detailed handling operations, see the sections below.

RAM user

For RAM users with different usage patterns, take the following steps for targeted handling.

1. The RAM user has an AccessKey

If the AccessKey has never been used. This type of RAM user is likely idle and should be removed.
1. Disable console logon. On the RAM user details page, in the Console Logon Management section of the Authentication Management tab, click Modify Logon Settings and set Console Access to Disabled. For more information, see Manage console logon settings for a RAM user.
2. Disable the AccessKey. You should disable the AccessKey first to prevent security risks from compromise. If your business team needs to use the AccessKey later, you can enable it with one click in the console. For more information, see Disable an AccessKey of a RAM user.
3. After a period of observation, if you confirm the AccessKey is not needed, delete the AccessKey and then delete the RAM user. For more information, see Delete an AccessKey of a RAM user and Delete a RAM user.
Otherwise (the AccessKey has been used), reduce the permissions as follows.
1. Disable console logon. On the RAM user details page, in the Console Logon Management section of the Authentication Management tab, click Modify Logon Settings and set Console Access to Disabled. For more information, see Manage console logon settings for a RAM user.
2. Reduce unused permissions. Alibaba Cloud provides a permission audit feature to help you identify the permissions a RAM identity has and the last time they were accessed. Note that the access tracking period for permission auditing began on February 1, 2024. If the AccessKey was last used before this date, it will not be recorded in the permission audit. Therefore, regardless of whether the RAM user has permission access activity in the permission audit, your O&M and business teams need to work together to confirm the operational permissions required by the AccessKey in specific business scenarios. Safely remove unused or unneeded permissions to follow the Principle of Least Privilege (PoLP) for RAM identities.
If the RAM user has a custom policy attached, you can directly modify that policy with the reduced permissions. Also, detach any other system policies from the RAM user. During this process, closely monitor your business. If it is affected, immediately roll back using the policy version feature (for more information, see Manage custom policy versions) and reattach the detached system policies.
If the RAM user only has system policies attached, create a new custom policy with the reduced permissions. Then, grant the custom policy to the RAM user and detach the system policies. For more information, see Create a custom policy, Grant permissions to a RAM user, and Revoke permissions from a RAM user. During this process, closely monitor your business. If it is affected, immediately reattach the original system policies to the RAM user.

2. The RAM user has not created an AccessKey

The RAM user has logged on to the console. Disable console logon. On the RAM user details page, in the Console Logon Management section of the Authentication Management tab, click Modify Logon Settings and set Console Access to Disabled. For more information, see Manage console logon settings for a RAM user.
The RAM user has not logged on to the console. This type of RAM user is likely idle and should be removed.
1. Disable console logon. On the RAM user details page, in the Console Logon Management section of the Authentication Management tab, click Modify Logon Settings and set Console Access to Disabled. For more information, see Manage console logon settings for a RAM user.
2. Delete the RAM user. If you confirm the RAM user is not actually used, delete it directly. For more information, see Delete a RAM user.

RAM role

Currently, Alibaba Cloud cannot identify the last time a RAM role was assumed, which makes it difficult to accurately determine its usage. Therefore, optimizing inactive RAM roles depends on your own decisions.

If the RAM role is a standard service role or a service-reserved role, do not make any modifications unless you are certain of its usage. You can directly archive the analysis finding. You can use an archive rule to automatically archive findings for these roles as described in the "Preparations - Processing path for RAM roles" section.
For other types of RAM roles (standard user roles), follow the permission reduction method for RAM users with an AccessKey described earlier. You can perform optimization directly in the RAM console or through RAM APIs.

Over-privileged user/role

If the finding type in the analysis findings list is Over-privileged user/role, it means the RAM user or role has unused service-level and action-level permissions within the specified idle access period. On the over-authorization analyzer's findings page, click Go to Governance (for resources in the current account) or Copy Resource URL (for resources in other accounts) to go to the permission audit page for the RAM identity. You can use the permission audit to confirm the unused permissions.

In the audit list, pay attention to the following:

Last access time. If the last access time is No access, it means the RAM identity has not had any permission access activity for that Alibaba Cloud service since February 1, 2024.
Policy granting permission. You can use the policy granting permission information to confirm which access policy defines the permission for the Alibaba Cloud service. This helps you locate and optimize it.
For services that support action-level auditing, click View Authenticated Actions in the Actions column to view the access status of specific APIs under that service. This helps you make decisions for further reducing permissions to specific API actions.

Based on the permission access information provided by the permission audit, your O&M and business teams need to work together to confirm the operational permissions required by the RAM identity in specific business scenarios. Safely remove unused or unneeded permissions to follow the Principle of Least Privilege (PoLP) for RAM identities.

First, on the finding details page, switch to the Governance Suggestions tab. Access analytics provides governance suggestions based on the findings. For access policies that have not been used within the idle access period, it provides a one-click detach capability to help you quickly reduce unused permissions. Note that only the resource owner of the finding can perform governance operations.
Then, you can further reduce permissions to the action level.
1. If the RAM identity has a custom policy attached, you can directly modify that policy with the reduced permissions. Also, detach any other system policies from the RAM identity. During this process, closely monitor your business. If it is affected, immediately roll back using the policy version feature (for more information, see Manage custom policy versions) and reattach the original system policies to the RAM user.
2. If the RAM identity only has system policies attached, create a new custom policy with the reduced permissions. Then, grant the custom policy to the RAM identity and detach the system policies. For more information, see Create a custom policy, Grant permissions to a RAM user, Revoke permissions from a RAM user, Grant permissions to a RAM role, and Remove permissions from a RAM role. During this process, closely monitor your business. If it is affected, immediately reattach the original system policies to the RAM identity.

For RAM roles, the handling method has the following slight differences:

If the RAM role is a standard service role or a service-reserved role, do not make any modifications unless you are certain of its usage. You can directly archive the analysis finding. You can use an archive rule to automatically archive findings for these roles as described in the "Preparations - Processing path for RAM roles" section.
For other types of RAM roles (standard user roles), the handling method is the same as described above. You can perform optimization directly in the RAM console or through RAM APIs.

Troubleshooting

Why do I get the 'NotSupport.AliyunReservedRole' error when modifying a RAM role?

This type of role is a service-reserved role. It has the AliyunReserved prefix. You must manage the role in the corresponding cloud service. Management is not allowed in the RAM console or through RAM APIs. For example, for CloudSSO access configurations, when you deploy an access configuration in CloudSSO, a RAM role named AliyunReservedSSO-<Access Configuration Name> is created in the corresponding account. This role cannot be modified or deleted from the RAM console, including the access policies attached to it. To make changes, you must modify the corresponding access configuration in CloudSSO. For more information, see Overview of access configurations.

Why is an access attempt recorded in access analytics even if it was not successful?

The last access information in permission auditing includes all access requests to an Alibaba Cloud service API, not just successful ones. It includes all attempts made through the Alibaba Cloud console, CLI, SDK, or direct API access. An unexpected access attempt in permission auditing does not mean your account has been compromised, because the request may have been denied. For detailed information about the request, you can check your ActionTrail logs.