HIPAA Cloud Compliance Audit: Securing Healthcare Data in AWS

When healthcare organizations migrate Protected Health Information (PHI) to the cloud, compliance isn't optional—it's a legal and ethical imperative. In this project, I conducted a comprehensive HIPAA risk assessment for Terrapin Health Systems, a mid-sized healthcare provider transitioning sensitive patient data to AWS.

14/16

Controls Non-Compliant

HIGH

Risk Posture

100%

Remediation Path

The Challenge: HIPAA in the Cloud

HIPAA's Security Rule mandates administrative, physical, and technical safeguards to protect PHI. When moving to AWS, organizations must ensure their cloud configurations meet these requirements—or face significant penalties, legal exposure, and loss of patient trust.

Project Scope: Analyze an AWS CloudFormation template for Terrapin Health Systems using a custom HIPAA-focused CIS benchmark checklist. Document configuration gaps, assess risk to PHI, and provide actionable remediations before deployment.

Methodology: CIS Benchmark + HIPAA Mapping

I evaluated the CloudFormation template against 16 critical security controls, mapping each to both CIS AWS Foundations Benchmark recommendations and HIPAA Technical Safeguards (45 CFR § 164.312).

Assessment Framework

Control	Status	HIPAA Safeguard
`CIS 2.1.4` S3 Block Public Access	✗ Non-Compliant	Access Control (§164.312(a)(1))
`CIS 2.2.1` RDS Encryption at Rest	✗ Non-Compliant	Encryption (§164.312(e)(2)(ii))
`CIS 2.2.3` RDS Public Accessibility	✗ Non-Compliant	Transmission Security (§164.312(e)(1))
`CIS 1.16` IAM Least Privilege	✗ Non-Compliant	Access Control (§164.312(a)(1))
`CIS 3.1` CloudTrail Logging Enabled	✓ Compliant	Audit Controls (§164.312(b))

Critical Findings: The 3 High-Risk Gaps

While 14 of 16 controls were non-compliant, three issues represented immediate, severe risks to PHI confidentiality and integrity.

Public Exposure of PHI Storage

Controls: CIS 2.1.4 (S3 Public Access), CIS 2.2.3 (RDS Public)

The S3 bucket had BlockPublicAccess disabled and a policy granting Principal: "*". The RDS instance was publicly accessible with CidrIp: 0.0.0.0/0.

HIPAA Impact: Direct path for unauthorized public disclosure of PHI; potential data breach under §164.402.

Missing Encryption at Rest

Controls: CIS 2.2.1 (RDS), CIS 2.3.1 (EFS), CIS 5.1.1 (EBS)

All critical data stores—RDS database, EFS file system, and EC2 EBS volumes—had Encrypted: false in the CloudFormation template.

HIPAA Impact: Violates §164.312(e)(2)(ii) Encryption standard; PHI exposed if storage media is accessed or exfiltrated.

Over-Privileged IAM Role

Control: CIS 1.16 (IAM Wildcard Permissions)

The EC2 instance role had Action: "*" and Resource: "*"—full administrative access to the entire AWS account.

HIPAA Impact: Violates Least Privilege principle (§164.312(a)(1)); single compromised role grants attacker total control over all PHI.

CloudFormation Evidence: What Was Wrong

Below are excerpts from the assessed CloudFormation template showing the specific configuration issues.

❌ S3 Bucket: Public Access Enabled

# PublicAccessBlock disabled
PublicAccessBlockConfiguration:
  BlockPublicAcls: false
  IgnorePublicAcls: false
  BlockPublicPolicy: false
  RestrictPublicBuckets: false

# Bucket policy allows public access
PolicyDocument:
  Statement:
    - Principal: "*"  # ← Anyone on internet
      Action: ["s3:GetObject", "s3:PutObject"]
      Resource: !GetAtt AssessmentS3Bucket.Arn

❌ RDS Instance: Unencrypted & Public

AssessmentRDSInstance:
  Type: AWS::RDS::DBInstance
  Properties:
    StorageEncrypted: false      # ← No encryption at rest
    PubliclyAccessible: true     # ← Exposed to internet
    # Security group allows 0.0.0.0/0
    VPCSecurityGroups:
      - !Ref AssessmentRDSSecurityGroup

❌ IAM Policy: Wildcard Permissions

AssessmentIAMPolicy:
  Type: AWS::IAM::Policy
  Properties:
    PolicyDocument:
      Statement:
        - Effect: Allow
          Action: "*"           # ← Full admin access
          Resource: "*"         # ← All resources
          # Violates Least Privilege

Remediation Roadmap: From Non-Compliant to HIPAA-Ready

For each non-compliant control, I developed actionable CloudFormation fixes that align with both CIS benchmarks and HIPAA requirements.

Fix Public S3 Exposure

Set all PublicAccessBlockConfiguration values to true
Add bucket policy statement denying non-HTTPS requests
Remove Principal: "*"; restrict to specific IAM roles

# Add to S3 bucket policy
- Sid: DenyNonSSLRequests
  Effect: Deny
  Principal: "*"
  Action: "s3:*"
  Resource: [!GetAtt AssessmentS3Bucket.Arn, ...]
  Condition:
    Bool:
      aws:SecureTransport: false

Enable Encryption Everywhere

RDS: Set StorageEncrypted: true + specify KMS key
EFS: Set Encrypted: true in file system resource
EBS: Set Encrypted: true in EC2 BlockDeviceMapping
CloudTrail: Add KMSKeyId property for log encryption

Apply Least Privilege to IAM

Replace Action: "*" with specific required actions
Scope Resource to exact ARNs needed by the EC2 role
Use AWS managed policies (e.g., AmazonEC2ReadOnlyAccess) where appropriate
Implement permission boundaries for additional guardrails

Additional Critical Fixes

🔐 Enforce MFA Delete

Enable S3 versioning + MFA delete to prevent accidental/malicious PHI deletion

🛡️ Require IMDSv2

Set HttpTokens: required on EC2 to block SSRF credential theft

🔑 Enable KMS Key Rotation

Set EnableKeyRotation: true to limit exposure window if keys are compromised

🔒 Strengthen Password Policy

Minimum 14 chars, prevent reuse, require complexity per HIPAA auth standards

Risk Analysis: What Could Go Wrong?

Each non-compliant control represents a potential HIPAA violation with real-world consequences:

Public S3/RDS: Unauthorized actors could directly access PHI, triggering mandatory breach notification under §164.402 and potential fines up to $1.5M/year.
Unencrypted storage: If underlying disks are stolen or snapshots leaked, PHI is exposed in plaintext—violating the Encryption standard.
Over-privileged IAM: A single compromised EC2 instance could grant attackers full account takeover, enabling mass PHI exfiltration.
Weak password policy: Short passwords + no reuse prevention enable credential stuffing attacks against administrative accounts.
IMDSv1 allowed: SSRF attacks could steal temporary credentials, bypassing network controls to access PHI in other services.

Key Insight: Compliance isn't a checklist—it's a continuous process. Even "compliant" controls like CloudTrail logging require proper configuration (KMS encryption, log validation) to be truly effective for HIPAA audit requirements.

Lessons Learned

1. Infrastructure as Code Requires Security as Code

CloudFormation templates are powerful but dangerous. Security controls must be baked into the template itself—not added as an afterthought.

2. HIPAA Is More Than Encryption

While encryption is critical, HIPAA also requires audit controls, access management, integrity controls, and transmission security. A holistic view is essential.

3. Defaults Are Dangerous

AWS defaults (like IMDSv1, unencrypted volumes) are convenient but rarely compliant. Explicitly configuring security is non-negotiable for regulated workloads.

4. Documentation Is a Control

The ability to demonstrate due diligence through risk assessments, remediation plans, and evidence is itself a HIPAA requirement (§164.308(a)(1)(ii)(D)).

Technical Skills Demonstrated

AWS

CloudFormation

Compliance

HIPAA / CIS

Risk

Assessment

Security

Architecture

📚 Educational Context

This HIPAA risk assessment was completed as part of ENPM665: Cloud Security at the University of Maryland. The scenario, organization, and CloudFormation template were created for educational purposes to develop practical skills in cloud compliance, risk analysis, and healthcare data protection.