Alibaba Cloud Security Checklist: Score Your Account

The Alibaba Cloud account is used only for rare tasks, with its password and MFA device secured; daily work uses RAM identities.

Each person has their own RAM identity (or signs in through SSO); nobody shares a login.

MFA is required for console logon, with passkeys for high-risk users.

Staff federate through your identity provider using SAML 2.0 or OIDC where you have one.

Permissions are granted through RAM user groups by job function.

No AccessKey pair exists for the Alibaba Cloud account.

Applications and CI use RAM roles with STS tokens rather than long-term AccessKey pairs.

Where an AccessKey is unavoidable, each application has its own RAM user and key with least-privilege permissions.

The "Allow users to manage AccessKey" setting is off in production.

You can disable and delete a leaked AccessKey quickly and detect leaked or long-inactive keys.

Custom policies grant only the actions and resources each job needs, rather than broad administrator policies.

Sensitive actions use conditions such as source CIDR block or MFA.

Resource groups scope permissions to a project or environment.

Explicit Deny statements guard actions that must never happen, knowing Deny overrides Allow.

Permissions are reviewed with permission auditing or access analysis, and unused or over-privileged identities are trimmed.

A trail delivers management events to Simple Log Service or OSS, so history is kept beyond 90 days.

The trail records all management events including read events.

Data events are recorded for buckets that hold sensitive data.

Security Center is deployed on servers and its findings (vulnerabilities, misconfigurations, identity risks) have owners.

You treat Security Center as one layer and keep patching and least privilege.

Block Public Access is on at the account level.

No bucket uses public-read or public-read-write unless there is a documented reason.

Bucket policies use fixed principals, not "*", and you check them with GetBucketPolicyStatus.

Database passwords and API credentials live in KMS secrets, not in code or wikis.

Sensitive data uses server-side encryption where your requirements call for key control.

Security groups allow only the ports and sources needed; SSH and database ports are not open to 0.0.0.0/0.

Instances that do not need to talk to each other are isolated (internal communication policy or enterprise security groups).

Rule priorities are understood and redundant rules are cleaned up.

Public web applications sit behind WAF in enforcement mode after a monitor-mode tuning period.

The origin server cannot be reached directly, bypassing WAF.