Least-Privilege Access for a Cross-Team Data Platform
A company runs a shared data platform on Alibaba Cloud. Three teams need access: analysts need read-only access to OSS buckets holding processed data; an ETL service running on ECS needs to read raw buckets and write processed buckets; a contractor needs temporary access to one specific bucket for two weeks. Currently, a single RAM user with broad permissions and a long-lived AccessKey is shared by all three, and the key is embedded in application config. A security review flagged this. The company uses RAM and wants to move to role-based access. Constraints: the ETL service must not store long-lived credentials; the contractor's access must expire automatically; analysts must not be able to read raw data; audit must show who did what.
1. Design the access model using RAM concepts. Explain how each of the three teams is handled and why the shared long-lived key must be eliminated.
Read the worked answer
Use RAM users, RAM roles, and policies, with the shared key retired.
- ETL service: attach a RAM role to the ECS instance (instance RAM role) so the application obtains temporary STS credentials automatically. No long-lived AccessKey is stored in config; credentials rotate. Grant a custom policy scoped to read the raw bucket and write the processed bucket only.
- Analysts: individual RAM users (or federated identities) in a group with a read-only policy limited to the processed buckets. Explicitly exclude raw buckets so the policy cannot read them; deny-by-default means anything not granted is refused.
- Contractor: a RAM role or RAM user with a time-bounded permission. Use an STS token with a defined expiration (e.g., 14 days) or a role with a scheduled de-provisioning date, scoped to the single bucket. Access expires automatically without manual cleanup.
Why the shared key must go: a single broad-permission key shared by three parties cannot be attributed in audit logs, cannot be scoped per team, and if leaked grants everything. It also never expires. Replacing it with per-identity roles/users gives least privilege and attributable actions.
2. How do you satisfy the audit requirement, and what would you check to confirm analysts cannot reach raw data?
Read the worked answer
Audit: enable ActionTrail to record API calls with the identity that made them. Because each team now has a distinct RAM user or role, log entries map to a specific principal rather than one shared key. For data-plane access to OSS, enable OSS access logging (and, where relevant, bucket logging) so object-level reads/writes are attributable. Centralize logs in a protected account/bucket that the teams cannot modify.
Verification that analysts cannot read raw data: do not rely on the policy text alone. Test with an analyst identity: attempt to list and get an object in a raw bucket and confirm AccessDenied. Check for policy overlap: group policies, any attached managed policies, and bucket policies that might grant broader access than intended. Confirm there is no wildcard resource or action in the analyst policy that accidentally covers raw buckets. Also confirm the ETL role cannot read buckets outside its scope and that the contractor's token actually expires at the expected time. Periodically re-run these checks, since permissions drift.