DEV Community

Joe Gellatly
Joe Gellatly

Posted on

Running HIPAA-Compliant Workloads in the Cloud: An Infrastructure Engineer's Guide

#hipaa #cloud #devops #security

Every major cloud provider will sign a Business Associate Agreement. That's the easy part. The hard part is configuring your cloud environment so it actually meets HIPAA requirements -- because the BAA doesn't make your misconfigured S3 bucket compliant.

The shared responsibility model means your cloud provider secures the infrastructure. You secure everything you build on top of it. Most HIPAA violations in cloud environments are configuration errors, not infrastructure failures.

The Shared Responsibility Reality

Here's what the cloud provider's BAA actually covers versus what's your responsibility:

Cloud Provider Responsibility (covered by their BAA)
-- Physical security of data centers
-- Hardware maintenance and patching
-- Network infrastructure security
-- Hypervisor security
-- Service availability (per SLA)

Your Responsibility (NOT covered by their BAA)
-- Data encryption configuration
-- Access control policies
-- Network security groups and firewall rules
-- Application-level security
-- Audit logging configuration
-- Backup policies and testing
-- Incident response
-- Identity and access management
-- Patch management for your OS and applications
Enter fullscreen mode Exit fullscreen mode

A covered entity can't point to AWS's BAA when OCR asks why their RDS instance was publicly accessible. The BAA establishes that AWS will protect the infrastructure -- but you chose to make the database public.

Encryption Configuration

Data at Rest

Every storage service that holds ePHI needs encryption enabled:

  • Object storage (S3, GCS, Azure Blob) -- Enable server-side encryption with KMS-managed keys. Default encryption should be enforced at the bucket/container policy level so it's impossible to store unencrypted ePHI.
  • Block storage (EBS, Persistent Disks, Azure Disks) -- Enable encryption for all volumes. In AWS, you can set account-level defaults to encrypt all new EBS volumes automatically.
  • Databases (RDS, Cloud SQL, Azure SQL) -- Enable encryption at rest. For RDS, this must be set at instance creation -- you can't encrypt an existing unencrypted instance in place.
  • File systems (EFS, Filestore, Azure Files) -- Enable encryption. Often overlooked for shared storage used by legacy applications.
  • Backups and snapshots -- Encrypted automatically if the source is encrypted, but verify this. Cross-region snapshot copies need explicit encryption configuration.

Data in Transit

  • TLS 1.2 minimum for all connections to ePHI services. Disable TLS 1.0 and 1.1 explicitly.
  • Internal service communication -- Use service mesh encryption or VPC-internal TLS. Just because traffic stays within your VPC doesn't mean it can be unencrypted.
  • Database connections -- Enforce SSL/TLS for all database connections. In RDS, use the rds.force_ssl\ parameter.
  • API Gateway -- Terminate TLS at the gateway and re-encrypt to backend services. Don't leave the backend leg unencrypted.

Key Management

  • Use cloud KMS (AWS KMS, GCP KMS, Azure Key Vault) for all encryption keys
  • Implement key rotation policies -- annual rotation minimum
  • Separate keys by environment (dev, staging, production)
  • Restrict key access policies to specific IAM roles
  • Log all key usage for audit trails

Network Security

VPC Architecture

Design your VPC with ePHI isolation in mind:

  • Private subnets for ePHI workloads -- Databases, application servers processing PHI, and storage should never be in public subnets
  • NAT gateways for outbound access -- ePHI workloads that need internet access should route through NAT, never have public IPs
  • VPC endpoints for AWS services -- Use interface and gateway endpoints so traffic to S3, KMS, and other services stays within the AWS network
  • Network ACLs and security groups -- Implement both. Security groups for instance-level control, NACLs for subnet-level defense in depth

Segmentation

Separate ePHI workloads from non-ePHI workloads:

  • Separate VPCs or accounts for HIPAA workloads (AWS Organizations and SCPs are your friend here)
  • Micro-segmentation -- Security groups that allow only the specific ports and protocols needed between services
  • No direct database access from the internet -- Ever. Use bastion hosts or AWS Systems Manager Session Manager for administrative access

Access Control and IAM

Principle of Least Privilege

  • No broad IAM policies -- Action: "*"\ and Resource: "*"\ on ePHI resources is a finding waiting to happen
  • Role-based access -- Define IAM roles for specific functions (application role, DBA role, audit role) with minimum necessary permissions
  • No long-lived access keys -- Use IAM roles and temporary credentials wherever possible. If access keys are required, rotate them every 90 days maximum.
  • MFA on all human access -- Console access, CLI access through assumed roles, and any direct access to ePHI systems

Service Accounts

  • Dedicated service accounts per application -- Don't share service accounts across applications
  • Scoped permissions -- A service account for your patient portal shouldn't have access to your billing system's ePHI
  • Rotate credentials -- Automate credential rotation for service accounts

Audit Logging

What to Log

  • CloudTrail (AWS) / Cloud Audit Logs (GCP) / Azure Activity Log -- Enable for all regions, all services. Send to a centralized, immutable log store.
  • VPC Flow Logs -- Enable for all VPCs containing ePHI workloads. These show network traffic patterns and are critical for breach investigation.
  • Database audit logs -- Enable query logging for databases containing ePHI. Know who ran what queries and when.
  • Application-level audit logs -- Your application should log PHI access at the record level, not just authentication events.

Log Protection

  • Immutable storage -- Send logs to an S3 bucket with object lock or equivalent. Attackers covering their tracks shouldn't be able to delete audit evidence.
  • Cross-account log storage -- Store audit logs in a separate AWS account with restricted access
  • 6-year retention -- HIPAA requires documentation retention for 6 years. Configure lifecycle policies accordingly.
  • Alerting -- Set up CloudWatch alarms or equivalent for suspicious patterns (failed auth attempts, unusual data access, configuration changes to security controls)

Backup and Disaster Recovery

  • Automated backups with documented RPO and RTO for every ePHI system
  • Cross-region replication for critical ePHI stores
  • Regular restore testing -- Quarterly at minimum. Document the results.
  • Backup encryption -- Verify backups are encrypted, especially cross-region copies
  • Backup access controls -- Separate IAM policies for backup operations. The application role shouldn't be able to delete backups.

Infrastructure as Code

Treat your HIPAA-compliant configuration as code:

  • Terraform/CloudFormation/Pulumi for all infrastructure -- No manual console configurations for ePHI resources
  • Policy as code -- Use tools like OPA, Sentinel, or AWS Config Rules to enforce HIPAA-required configurations automatically
  • Drift detection -- Alert when infrastructure drifts from the compliant baseline
  • Code review -- All infrastructure changes go through pull request review, just like application code

The Compliance Connection

Every cloud configuration decision should trace back to your Security Risk Analysis. The SRA identifies which systems contain ePHI, what controls are needed, and what residual risk exists. Your cloud architecture should implement the controls your SRA identifies.

For organizations managing HIPAA compliance across cloud and on-premise environments: HIPAA Compliance Solutions

And the risk analysis foundation that drives your cloud security decisions: HIPAA Risk Analysis Tools

Joe Gellatly is CEO of Medcurity, a HIPAA compliance platform that helps healthcare organizations manage risk assessments, compliance tracking, and security programs across cloud and on-premise environments.

Top comments (0)