Alibaba Cloud environments are often run by teams whose cloud playbooks were written for AWS, Azure or Google Cloud, and the gaps show up in identity: Alibaba Cloud account AccessKeys in scripts, RAM users shared between people, and ActionTrail never configured beyond its 90-day default. The building blocks are familiar (an account root, users, groups, roles, temporary credentials, an audit trail, a security posture service), but the names, defaults and limits differ. This guide maps them: how Resource Access Management (RAM) works, which identities are privileged, how applications should get credentials, what ActionTrail and Security Center record, and a hardening baseline aligned with the CIS Alibaba Cloud Foundation Benchmark. It is for security and platform teams running workloads in Alibaba Cloud international regions or mainland China, and for multi-cloud teams adding it to an existing programme. Regulation in mainland China is covered in the China MLPS 2.0 Guide and China Cybersecurity Law Guide.
Key takeaways
- Do not create AccessKeys for the Alibaba Cloud account. Alibaba Cloud says an account-level AccessKey has full permissions on all resources and that the risk if it leaks is extremely high.
- Prefer RAM roles and STS tokens. RAM roles have no password or AccessKey; an entity assumes them and receives a temporary STS token. Use instance RAM roles on ECS and role-based SSO for people.
- Harden the metadata service. ECS instance credentials come from
100.100.100.200; enforce the token-based security hardening mode so a server-side request forgery cannot simply read them. - ActionTrail needs a trail. Management events are kept for 90 days by default; data events are not collected at all until you create a trail that records them and delivers to Simple Log Service (SLS) or OSS.
- Block public OSS access at account level. OSS Block Public Access at the account level overrides public ACLs and public bucket policies on every bucket.
How identity and access work in Alibaba Cloud
Every Alibaba Cloud estate starts with an Alibaba Cloud account, which owns resources and billing and has full permissions, equivalent to a root user. Resource Access Management (RAM) provides the identities that should do the actual work. Multi-account estates group accounts under Resource Directory, which provides folders, member accounts and preventive guardrails (control policies) applied from the management account.
| Alibaba Cloud concept | What it is | Closest AWS equivalent | Security note |
|---|---|---|---|
| Alibaba Cloud account | Account owner with full permissions | Root user | Use only for authorization, payment and account management; MFA; no AccessKey |
| RAM user | A person or application with console password and/or AccessKey pairs | IAM user | One per person or application; never shared |
| RAM user group | Collection of RAM users that inherit the group's policies | IAM group | Attach policies to groups, not users |
| RAM role | Virtual identity with no password or AccessKey, assumed to obtain an STS token | IAM role | Preferred for workloads, cross-account access and SSO |
| STS token | Temporary AccessKey pair plus SecurityToken with a preset validity | STS session credentials | Expires automatically; the recommended credential type |
| System policy, custom policy | Managed by Alibaba Cloud (cannot be edited) or written by you in JSON | AWS managed and customer managed policies | Conditions (for example source IP) require custom policies |
| Resource Directory, control policies | Multi-account structure and account-level guardrails | AWS Organizations, SCPs | Use to stop member accounts disabling logging or creating risky resources |
- Authentication for people: RAM users sign in to the console with a password; enforce MFA for every RAM user that keeps a console password. Federated sign-in is available as user-based SSO (identity provider users mapped to RAM users) or role-based SSO (users assume a RAM role and get an STS token). Alibaba Cloud recommends role-based SSO, which also avoids keeping RAM user passwords at all.
- Authentication for programs: AccessKey pairs (AccessKey ID and AccessKey secret) are long-term credentials valid until disabled or deleted. Each RAM user can hold at most two, one in use and one for rotation; the secret is shown only at creation.
- Authorisation: policies attached to users, groups and roles. Write custom JSON policies for anything beyond broad system policies such as AdministratorAccess.
Admin roles and privileged access
- The Alibaba Cloud account: enable MFA, keep the password in a break-glass process, create no AccessKey, and delete any that exist after migrating their users. Monitor its sign-ins in ActionTrail (console sign-in events).
- Administrators: Alibaba Cloud recommends a RAM user with administrator permissions for day-to-day management rather than the account itself. Better still, give administrators a RAM role assumed through role-based SSO, so administrative access is temporary and tied to your identity provider's MFA and joiner-mover-leaver process.
- Who can change RAM: any principal with RAM write permissions (creating users, AccessKeys, policies or role trust policies) can grant itself more access. Treat these permissions as tier 0 and limit them to a small group.
- Role trust policies: the trust policy decides which accounts, services or identity providers can assume a role. Review cross-account trusts and avoid trusting a whole external account where a specific RAM role can be named.
- Separation of duties: keep security functions (ActionTrail configuration, Security Center, KMS key administration) in a dedicated security or log archive account under Resource Directory, administered by different people from the workload accounts.
- Source IP restriction: custom policies can restrict actions to approved corporate egress ranges, and Alibaba Cloud recommends network ACL policies that restrict where an AccessKey can be used from.
| Privileged capability | Why it matters | Control |
|---|---|---|
| Creating AccessKeys for other RAM users | Persistent credential an attacker can take away (MITRE ATT&CK T1098.001 Additional Cloud Credentials) | Restrict RAM write permissions; alert on CreateAccessKey |
| Attaching policies or editing role trust | Privilege escalation to administrator | Small RAM admin group; alert on policy attachment events |
| Changing or deleting ActionTrail trails | Removes the audit trail (T1685 Disable or Modify Tools) | Control policy in Resource Directory to deny trail changes outside the security account |
| Changing OSS Block Public Access or bucket ACLs | Data exposure (T1530 Data from Cloud Storage) | Account-level Block Public Access; alert on changes |
| Disabling Security Center agents or features | Blinds host detection | Restrict Security Center admin to the security team |
Integrations, API tokens and service accounts
AccessKeys are the most common way Alibaba Cloud credentials leak, through code repositories, container images, CI variables and configuration files (T1552.001 Credentials In Files). The goal is to make long-term AccessKeys the exception.
| Workload | Credential to use | Avoid |
|---|---|---|
| Application on ECS | Instance RAM role (one per instance) with security hardening mode for metadata | AccessKey in a configuration file |
| Containers on ACK | RAM role mapped to the workload through the cluster's workload identity feature, scoped per service account | Node-level role shared by every pod |
| Cross-account automation | Assume a RAM role in the target account with STS | RAM user AccessKeys created in each account |
| CI/CD outside Alibaba Cloud | OIDC-based role assumption where the pipeline supports it; otherwise a dedicated RAM user with a narrow policy and source IP condition | Administrator AccessKey in pipeline variables |
| Third-party SaaS integration | RAM role the vendor assumes, with a narrow policy | Sharing an AccessKey with the vendor |
- Instance metadata hardening: security hardening mode requires a session token obtained with a
PUTto/latest/api/token(headerX-aliyun-ecs-metadata-token-ttl-seconds, 1 to 21600 seconds) and sent asX-aliyun-ecs-metadata-tokenon metadata requests. Configure SDKs to disable the fallback to normal mode so an SSRF flaw cannot read role credentials with a plain GET (T1552.005 Cloud Instance Metadata API). Older SDK and CLI versions do not support hardening mode, so check versions before enforcing it. - Where AccessKeys remain: one RAM user per application, least-privilege policy, source IP restriction, storage in a secrets manager rather than files, rotation using the second AccessKey slot, and auto-disable after 90 days idle as Alibaba Cloud recommends. Use
GetAccessKeyLastUsedto find dormant keys. - Inventory: record every RAM user with an AccessKey, its owner, purpose and last use. See the API Key Management Guide and the Non-Human Identity (NHI) Guide.
Logging and detection
ActionTrail
ActionTrail records operations from the console, OpenAPI and developer tools as events: who acted, on which resource, when, from which source IP, through the API or console, and whether the call succeeded. Two event types matter:
- Management events (control plane): creating, changing and deleting resources, plus console sign-ins. Kept for 90 days by default and queryable in the console.
- Data events (data plane): reads and writes of data inside resources, such as reading an OSS object. Not collected by default; you must create a trail with data events enabled.
Create a trail that delivers to Simple Log Service for querying and alerting, and to OSS for long-term retention in a separate log archive account. Alibaba Cloud allows up to five trails per region and typically delivers events within about ten minutes. Use a multi-account trail so member accounts in Resource Directory cannot opt out. Protect the destination: write-only delivery, Block Public Access, and a retention period that meets your policy and any MLPS obligations. See the Cloud Logging and Audit Trail Guide.
Security Center
Security Center (also called Cloud Security Center) combines host and container threat detection, vulnerability management, baseline checks (including checks aligned with MLPS 2.0), cloud configuration checks across Alibaba Cloud products, AccessKey leak detection and anti-ransomware backup. It is sold in editions (Basic, Anti-virus, Advanced, Enterprise, Ultimate, with pay-as-you-go options) and needs its agent installed on servers for host features. Confirm which edition covers the features you rely on, because the Basic edition is limited.
Detections to build
| Event or signal | Why |
|---|---|
| Console sign-in by the Alibaba Cloud account | Root use should be rare and planned |
CreateAccessKey, especially for the account or an administrator | New persistent credential |
| Policy attachments granting AdministratorAccess, or role trust policy changes | Privilege escalation |
| Trail stopped, deleted or changed | Audit tampering |
| Security Center AccessKey leak alert | Credential found exposed; rotate and investigate use |
| OSS Block Public Access disabled or ACL changed to public-read | Data exposure |
| API calls from an AccessKey outside its normal source IPs or regions | Stolen key in use (T1078.004 Cloud Accounts) |
Metrics
- Number of AccessKeys on the Alibaba Cloud account (target: zero).
- Percentage of human access through role-based SSO rather than RAM user passwords.
- Number of RAM users with AccessKeys unused for more than 90 days.
- Percentage of accounts covered by a multi-account trail with data events on sensitive buckets.
- CIS Alibaba Cloud Foundation Benchmark pass rate per account, tracked over time.
Hardening baseline
The Center for Internet Security publishes the CIS Alibaba Cloud Foundation Benchmark (version 2.0.1 was the latest listed on the CIS site when checked in October 2026). Use it as the detailed checklist; the baseline below summarises the controls with the most impact.
| Area | Baseline |
|---|---|
| Account owner | MFA on the Alibaba Cloud account; no AccessKey; contact details current; used only for account-level tasks |
| Human access | Role-based SSO from the corporate identity provider; MFA; no shared RAM users; password policy for any remaining RAM users |
| Workload access | Instance RAM roles and STS; metadata security hardening mode enforced; AccessKeys only by exception with owner and expiry |
| Least privilege | Custom policies scoped to resources; no AdministratorAccess for applications; source IP conditions for AccessKey users |
| Multi-account | Resource Directory with separate security, log archive and workload accounts; control policies preventing trail deletion and risky changes |
| Audit | Multi-account ActionTrail trail to SLS and OSS in the log archive account; data events for sensitive OSS buckets |
| Storage | OSS Block Public Access at account level; server-side encryption; versioning or retention for critical data |
| Network | Security groups without 0.0.0.0/0 on administrative ports (22, 3389); private access to databases |
| Posture and detection | Security Center agents on all servers; configuration checks enabled; alerts routed to the SOC |
| Secrets and keys | Secrets in a managed secrets service; encryption keys in KMS with key administrators separate from key users |
Rollout
- Assess: run Security Center configuration checks and a CIS benchmark assessment on every account; list RAM users, AccessKeys and their last use.
- Secure the account owner: MFA, remove account AccessKeys (after moving their callers to RAM identities), document break-glass.
- Turn on the trail: create the multi-account trail before making identity changes, so the migration itself is logged.
- Move people to SSO: configure role-based SSO, migrate administrators, then disable console passwords on RAM users that no longer need them.
- Move workloads to roles: instance RAM roles first, then cross-account roles; test metadata hardening mode in a pilot group of instances before enforcing it.
- Apply guardrails: account-level OSS Block Public Access and Resource Directory control policies, tested on a sandbox folder first.
- Rollback: keep the previous AccessKey disabled rather than deleted for a short period during each migration, so a missed dependency can be restored quickly; delete it once the trail shows no use.
Small team or large estate
- Single account, small team: account MFA and no account AccessKey, RAM users per person with MFA (or SSO if you have an identity provider), instance RAM roles, a trail to OSS, Block Public Access and the Basic Security Center features.
- Multi-account or regulated estate: Resource Directory with control policies, role-based SSO only, a central log archive with long retention, a paid Security Center edition, and MLPS baseline checks for systems in mainland China.
Common misconfigurations
- AccessKey on the Alibaba Cloud account used by scripts: a single leaked key gives full control of every resource and cannot be scoped down.
- One RAM user shared by a team: no accountability in ActionTrail, and the password survives every leaver.
- AdministratorAccess attached to application RAM users: the application's AccessKey becomes an administrator credential.
- Relying on the 90-day event history: incidents are often found later than that, and data events were never recorded.
- Metadata in normal mode: any SSRF in an application on ECS can read the instance role's STS credentials.
- OSS buckets set to public-read for convenience: without account-level Block Public Access, one bucket ACL exposes the data.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | MITRE ATT&CK addressed |
|---|---|---|---|
| RAM identities, SSO, MFA | IA-2, AC-2 | PR.AA-01 | T1078.004 |
| AccessKey and STS credential management | IA-5 | PR.AA-01 | T1552.001, T1552.005, T1098.001 |
| Policies and least privilege | AC-6 | PR.AA-05 | T1530 |
| ActionTrail and log protection | AU-2, AU-9 | DE.CM-09 | T1685 |
| Security Center baseline and configuration checks | CM-6, RA-5 | PR.PS-01, ID.RA-01 | n/a |
Practitioner checklist
- Enable MFA on the Alibaba Cloud account and delete its AccessKeys.
- Move administrators to role-based SSO and remove shared RAM users.
- Attach instance RAM roles to ECS workloads and enforce metadata security hardening mode.
- Restrict remaining AccessKeys by source IP, rotate them and disable any idle for 90 days.
- Create a multi-account ActionTrail trail to SLS and OSS in a separate log archive account, with data events on sensitive buckets.
- Enable OSS Block Public Access at account level.
- Deploy Security Center agents and route AccessKey leak and configuration alerts to the SOC.
- Assess every account against the CIS Alibaba Cloud Foundation Benchmark and track the pass rate.
Standards and references
- CIS: Alibaba Cloud Benchmarks (Alibaba Cloud Foundation)
- Alibaba Cloud: What is RAM?
- Alibaba Cloud: Create an AccessKey pair
- Alibaba Cloud: Instance RAM roles
- Alibaba Cloud: What is ActionTrail?
- Alibaba Cloud: What is Security Center?
- Alibaba Cloud: OSS Block Public Access
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Cloud Security Guide · China MLPS 2.0 Guide · API Key Management Guide · Cloud Logging and Audit Trail Guide