MediTrust Health: A Public S3 Bucket and Six Years of Audit Records
MediTrust Health runs a patient-intake SaaS for 60 small clinics. The stack is a two-tier web application: EC2 instances behind an Application Load Balancer, RDS for MySQL, and scanned intake forms stored in S3. The company has 12 employees, one of whom is a part-time IT administrator with no formal security training; there is no security team. Last month a developer debugging an upload problem removed S3 Block Public Access on the forms bucket for four hours. Nobody noticed until a clinic's compliance officer found the bucket indexed by a search engine three days later. MediTrust has signed a Business Associate Addendum with AWS and must keep protected health information encrypted at rest and in transit, and must be able to show who accessed which object and when for six years. The CEO wants a list of changes that would have prevented the exposure and would have detected it within minutes.
1. Which parts of this incident fall on the customer rather than on AWS under the shared responsibility model? Be specific about each control.
Read the worked answer
AWS is responsible for security of the cloud: physical security of the data centres, the S3 service software itself, and the underlying infrastructure. Everything that actually caused this exposure sits on MediTrust's side of the line - the account-level and bucket-level Block Public Access settings, the bucket policy and object ACLs, the IAM permissions that allowed a developer to change them, and the absence of a bucket policy denying unencrypted or non-TLS requests.
AWS cannot know that a bucket contains protected health information. Classifying the data and choosing the controls is entirely the customer's job, which is exactly why the BAA matters: it makes AWS contractually accountable for its share and does not transfer configuration responsibility.
A useful test: if the control is a checkbox, a policy statement or a permission inside your own account, it is yours. If it is concrete, a hypervisor or the service's own code, it is AWS's. The developer's action was legitimate-looking permission drift; the real failure was that a 12-person company with no security staff had no guardrail that made that action impossible or instantly visible.
2. Design detective controls that would have flagged this within minutes and preserved six years of access records.
Read the worked answer
CloudTrail logs management events by default, but S3 object-level actions require data events to be enabled explicitly. So the first step is a trail with data events on the forms bucket, delivered to a bucket in a separate, locked-down log-archive account so nobody in the workload account can delete it. Default event history is only 90 days; a six-year requirement means a trail to S3 with lifecycle transition to Glacier and Object Lock in compliance mode.
For minutes-level detection: CloudWatch Logs metric filters on DeletePublicAccessBlock and PutBucketPolicy feeding CloudWatch alarms to the on-call channel; AWS Config managed rules s3-bucket-public-read-prohibited and s3-bucket-public-write-prohibited with automatic remediation through Systems Manager Automation; Security Hub aggregating findings; GuardDuty S3 protection for anomalous access patterns; Macie to discover which buckets actually hold sensitive data, since nobody currently knows.
Add two preventive controls: account-level Block Public Access enforced through AWS Organizations, and a service control policy that denies s3:PutBucketPublicAccessBlock to every principal except a documented break-glass role.
3. The part-time administrator needs production access but should not be able to disable logging. What identity design do you recommend?
Read the worked answer
Give the administrator federated access rather than an IAM user with a long-lived access key. IAM Identity Center, connected to an identity provider, with permission sets granting time-bound, role-based access; MFA enforced both at the provider and in the permission set; separate roles for read-only production debugging and for change deployment, so routine investigation never carries write rights.
Place the log-archive account in its own organizational unit with a service control policy denying cloudtrail:StopLogging, cloudtrail:DeleteTrail, and s3:DeleteBucketPolicy or s3:PutBucketPolicy on the archive. SCPs apply to every principal in member accounts, including the root user, which is what makes them different from an IAM policy an administrator could edit. Keep one break-glass role protected by a hardware MFA token and alarm whenever it is assumed.
Close the loop operationally with quarterly access reviews and alerts on any IAM policy change. The governing principle is separation of duties: the person who can change production should not be the person who can erase the record of having done so.