Per-Tenant Encryption and a Scoped Vendor Share
A fintech stores cardholder data in 300 S3 buckets and an unencrypted RDS PostgreSQL instance. Auditors require encryption at rest with customer-managed KMS keys and per-tenant attribution of key use. Today a single AWS-managed key (aws/s3) covers the buckets. A third-party analytics vendor in another AWS account needs read access for 90 days to only the analytics/ prefix of one bucket; it must not list the bucket root or read any other prefix. Four application IAM roles currently hold s3:* on *. CloudTrail records management events only.
1. Design the encryption key structure. Is one CMK per tenant the right call?
Read the worked answer
Per-tenant CMKs buy clean attribution: every kms:Decrypt in CloudTrail carries the key ID, so you can map key use to a tenant without relying on object paths. The costs are real:
- Cost and quota: 300 CMKs means ongoing monthly key cost, plus KMS request charges. Key counts are manageable; request rate under load is the more likely limit, so monitor for throttling.
- Operational overhead: every new tenant requires key creation, key policy review, and rotation policy.
- Blast radius: separate keys mean separate key policies, but also more places to get a policy wrong.
A defensible hybrid: per-tenant CMKs for tenants with contractual or regulatory attribution requirements, and a shared bucket-level CMK plus encryption context for the rest. Note that S3 Bucket Keys reduce KMS calls substantially, but they also reduce per-object attribution granularity, which may conflict with the audit requirement.
For RDS, you cannot encrypt an existing instance in place: snapshot it, restore the snapshot with the chosen CMK, and cut over. Budget the outage or use a blue/green swap.
2. Specify the vendor access so it can read only analytics/ and cannot list the bucket root.
Read the worked answer
Three policy surfaces must all agree: the bucket policy, the KMS key policy, and the vendor's IAM role.
Bucket policy (in the owning account):
- Allow
s3:GetObjectonarn:aws:s3:::the-bucket/analytics/*only. - Allow
s3:ListBucketon the bucket ARN with conditions3:prefixequal toanalytics/(andanalytics/*if the SDK lists recursively). Without this, the vendor cannot navigate; with it, root listing is denied. - Add a deny for non-TLS requests and keep S3 Block Public Access on.
KMS key policy: cross-account access is not granted by the vendor's IAM policy alone. The CMK key policy must allow the vendor role kms:Decrypt and kms:DescribeKey, ideally conditioned on kms:ViaService for S3 in that region.
Vendor IAM role: grant only the corresponding S3 and KMS actions. Do not attach broad S3 managed policies.
Consider an S3 Access Point scoped to the prefix if you want a single policy surface, but key policy remains mandatory. Set a calendar reminder or EventBridge schedule to remove the grant at day 90, and verify with Access Analyzer that no other principal gained access.
3. How do you fix the four s3:* roles and detect misuse afterward?
Read the worked answer
Start with evidence, not guesswork:
- IAM Access Advisor shows which S3 actions each role actually used and when; use it to draft scoped policies.
- Access Analyzer identifies resources shared externally and unused permissions.
- Replace s3: with explicit actions* on specific bucket and prefix ARNs, and add a permissions boundary so a future policy edit cannot re-expand access silently.
Detection requires data-plane visibility:
- CloudTrail management events will not show
GetObject. Enable S3 data events for the sensitive buckets, or rely on S3 server access logs where data-event volume is too high. - Macie on the cardholder buckets to find unexpected PII exposure or unusual access patterns.
- Alarms on denied-access spikes and on access from new principal ARNs.
Review the data-event trail after the vendor engagement ends to confirm the vendor read only the analytics prefix.