CareFirst Virtual Care: Thirty Days to a Partner Security Review
CareFirst Virtual Care is a 40-person telehealth startup running in a single AWS account in us-east-1. Twelve engineers share one IAM user with AdministratorAccess because roles slow us down. Patient intake documents sit in S3 buckets created with ACLs; one bucket was made public for a marketing site and never reverted. CloudTrail was never enabled, and the security lead found a GitHub commit containing an access key. The company has signed a business associate agreement and must protect protected health information. A hospital partner will send a security questionnaire in 30 days asking for encryption evidence, access reviews, and audit logs. The CTO wants to know what to fix first and whether moving to managed services reduces the compliance burden.
1. Prioritize three remediations for the next 30 days and explain how the shared responsibility model shapes them.
Read the worked answer
1. Contain the exposed credential and establish visibility. Deactivate and rotate the leaked access key, review what it did in billing and resource changes, enable CloudTrail in all Regions with log-file validation, enable MFA on the root user, and delete any root access keys. Without logs you cannot answer the partner or investigate the leak, so visibility comes first.
2. Close the data exposure. Turn on S3 Block Public Access at the account level, inventory every bucket policy and ACL, and remove public access from anything holding patient data. Enable default encryption with SSE-KMS for buckets containing PHI, and use Macie to find unprotected sensitive data.
3. Fix identity. Replace the shared administrator IAM user with IAM Identity Center, individual users, MFA, and permission sets; give EC2 instances roles instead of keys.
Shared responsibility: AWS secures the physical facilities, hypervisor, and the patching of managed services. CareFirst remains responsible for its data classification, identities, bucket policies, encryption configuration, and logging. Moving to RDS or S3 does not transfer the misconfiguration risk; it changes who patches the operating system, not who owns access decisions.
2. Which AWS services and artifacts would you use to answer the partner questionnaire, and what is the limit of each?
Read the worked answer
Audit logs: CloudTrail organization trail with log-file validation and storage in a locked-down bucket, plus CloudWatch Logs for alerting on sensitive API calls.
Configuration evidence: AWS Config rules and a conformance pack to show encryption enabled, public access blocked, and MFA required. AWS Security Hub aggregates findings into a reviewable score.
Encryption evidence: KMS key policies, key rotation settings, and bucket default-encryption settings, exported as configuration snapshots.
Access review evidence: IAM credential report, IAM Access Analyzer findings for externally accessible resources, and Identity Center permission sets showing who can do what.
Third-party reports: AWS Artifact supplies AWS's own SOC 2, ISO 27001, and similar reports and the signed business associate agreement. Explain clearly to the partner that Artifact proves AWS's controls, not CareFirst's. The questionnaire asks both questions. You need the inherited controls from Artifact plus your own configuration evidence from Config, CloudTrail, and IAM. Presenting only Artifact will fail the review.
3. A data analytics contractor needs to read de-identified intake documents for 60 days. Design least-privilege access and the review process.
Read the worked answer
Create a dedicated permission set in IAM Identity Center rather than a shared user or long-term access key. The policy grants read-only access to a specific S3 prefix holding de-identified documents, for example s3:GetObject and s3:ListBucket scoped to that prefix, and nothing else. Deny access to the PHI buckets by omission and by an explicit deny if the account structure allows it.
Require MFA, set a 60-day expiry through group membership, and use temporary credentials from Identity Center. If analytics runs on compute, use an IAM role attached to that compute, not keys.
Enable S3 server access logging or CloudTrail data events on that prefix so reads are attributable. Before access starts, confirm the data is genuinely de-identified and document that determination. After 30 days, review IAM Access Analyzer and access logs to right-size the policy. At 60 days, remove the permission set and verify no residual keys exist.
Why this matters: a broad read-only policy over all buckets would let the contractor see PHI and would violate minimum necessary access under the agreement, even though it is read-only.