Alibaba Cloud

Audits a client's Alibaba Cloud account: RAM user identity posture, root account MFA and AccessKey state, ActionTrail audit logging, and ECS security group exposure across every region the account can reach.

Setup

1. In the client's Alibaba Cloud console, go to RAM → Identities → Users and create a user for Graften. Give it OpenAPI access only — no console password. Graften never signs in interactively, and a console password on a service identity is a finding waiting to happen.
2. Attach these read-only system policies:
   • AliyunRAMReadOnlyAccess — RAM users, MFA devices, AccessKeys, password policy, and the account security report
   • AliyunActionTrailReadOnlyAccess — trail configuration
   • AliyunECSReadOnlyAccess — security groups, their rules, and the region list
3. Save the AccessKey ID and Secret shown at creation. The secret is displayed once and cannot be retrieved afterwards.
4. In Graften: Connections → Add Connection → Alibaba Cloud, pick the client's primary region, and paste both values. Hit Test.

The region you choose is where region-scoped calls are addressed from. It does not limit the audit — see below.

The audit is account-wide, not region-scoped

The security group sweep enumerates every region the account can use and scans all of them. A single-region sweep would report "no rules open to 0.0.0.0/0" for regions it never queried, which is a clean bill of health over ground nobody looked at. An account with workloads in ap-southeast-1 and a trail in cn-zhangjiakou is not unusual — it is the normal shape of a business operating in more than one place.

The same asymmetry governs how results are reported. An open rule found anywhere is conclusive, and the scope of the search does not weaken it. Finding none is only ever as strong as the search was wide — so if any region could not be read, the control is recorded as unassessed rather than as a pass.

About the request signer

Alibaba's RPC signature is unforgiving and a wrong implementation fails in ways that look like a permissions problem. Graften's signer is checked at startup against Alibaba's own published test vector, and refuses to run audits if that check fails. This is why the connector will not produce a number it cannot stand behind.

Reading the result

The score is reported alongside a coverage figure and the two must be read together: 83/100 assessed over 71% of applicable controls is a different fact from 83/100 over all of them. Anything Graften could not collect is listed explicitly in an Assessment Coverage finding and excluded from the score rather than counted as passing. The E8 maturity level is withheld entirely until coverage is complete.

Rules open to 0.0.0.0/0 on ports 80 and 443 are counted but not reported as exposures — that is how a public web server works. Sensitive ports are named individually: SSH, RDP, database engines, container and orchestrator APIs.

A known Alibaba-side quirk: the stale security report

Root account MFA and root AccessKey state come from Alibaba's GetAccountSecurityPracticeReport, and that report is not always current. It can report a RAM user count that contradicts what the same audit enumerated seconds earlier. When Graften detects that contradiction it records both root controls as unassessed, with the discrepancy stated, instead of publishing figures that describe an earlier state of the account.

If you see this, verify root MFA directly in the console under Security Settings. The report catches up on its own schedule; there is nothing to fix on the Graften side and nothing to fix in the permissions.

If controls come back unassessed

The finding text carries the reason. Alibaba's own NoPermission errors name the exact action that was denied, which maps directly to one of the policies in step 2 — so read which action is named before changing anything.