AWS Documentation
Is Amazon EC2 HIPAA Eligible?
This cloud service is HIPAA-eligible
Amazon EC2 is listed on the AWS HIPAA Eligible Services List. This means that organizations that sign Amazon’s Business Associates Agreement (BAA) and fulfill the AWS shared responsibility model may use EC2 with protected health information (PHI). In order to utilize EC2, you must implement administrative and technical requirements of shared responsibilities.
What is Amazon EC2?
Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides resizable computing resources. EC2 provides users with on-demand servers or virtual machines (VM). EC2 virtual machines can be configured with almost any operating system and application. Cloud users only pay for the EC2 computing power needed. EC2 can be configured in auto-scaling groups and EC2 services can be scaled up and down as computing requirements change. EC2 services can be configured across multiple availability zones (AZ) and regions to increase availability and service reliability.
Amazon EC2 Compliance Requirements
In order to utilize Amazon EC2 in a HIPAA compliant manner, organization’s account for all technical safeguards regarded EC2 access, data storage, transmission. This means that EC2 instances, their associated EBS volumes, and Security Groups should be configured to follow the principle of least privilege. Administrative policies must be in place to dictate who can access EC2 instances, how they are deployed, and how they are operated. For EC2 instances containing PHI, access via AWS console and as well as SSH (shell) should be limited to only necessary users.
Amazon EC2 Dedicated Instance Requirement
Previously, only dedicated EC2 instances HIPAA eligible. AWS has recently clarified, that organizations that sign the AWS BAA are no longer required to utilize Amazon EC2 dedicated instances or dedicated hosts to process protected health information (PHI). This means organizations may use any size EC2 instance with PHI. The removal of this requirement makes it easier for startups and small AWS customers to build and scale HIPAA compliant workloads using EC2.
You can read Amazon Web Services’ announcement about the removal of the dedicated instance requirement here.
Encryption and Amazon EC2
HIPAA requires that organization implement “all necessary” security requirements for encrypting PHI at-rest and in-transit. For Amazon EC2, any EC2 instances that will contain PHI, must use encrypted EBS volumes for storing data. External access to EC2 should be over a SSL/TLS connection.
System Access and Amazon EC2
HIPAA follows the principle of “Granting Least Privilege”, meaning that only necessary staff members should have access to PHI. Organizations should follow this principle when providing users with access to EC2. Only the minimal necessary staff should have access to production EC2 services. Organizations should use separate development environments and avoid storing PHI inside development environments.
- Teams should consider isolating EC2 environments using different AWS Virtual Private Clouds (VPCs) to separate EC2 instances.
Availability and Amazon EC2
HIPAA requires that PHI must account for potential service outages and must be available in case of emergency. This means that organizations should have a disaster recovery policy and plan for incidents leading to EC2 unavailability.
- Security teams should create backups of EC2 instance data/EBS volumes containing PHI or production data.
- EC2 instances should be configured for high availability across multiple availability zones (AZs) to minimize the impact of a potential service outage.
Audit Logging and Amazon EC2
HIPAA requires that organizations collect and analyze audit logs related to PHI access. For EC2 instances containing PHI, organizations must collect access logs. Collecting these logs allows security teams the ability to detect suspicious activity and respond to potential security threats. Audit logging should be dictated alongside an Audit Logging Policy, with logs being reviewed periodically to analyze compliance issues.
- Security teams should collect EC2 instance logs using Cloudwatch or an appropriate 3rd party solution
- Audit logs should be reviewed quarterly to analyze suspicious activity.
Potential Threats to Compliance
- Security Groups that allow public access, or large port ranges of access may allow unauthorized users to access the instance and result in a breach.
- Production EC2 instances that do not have restricted staff access are vulnerable to insider threats and unauthorized modification of PHI.
- EBS Volumes that are unencrypted are vulnerable to 3rd parties and security breaches.
- Unencrypted data that is sent and received from EC2 instances may be intercepted and result in a breach
- EC2 Instances with operating systems (OS) that are not properly updated and patched, may be vulnerable to unauthorized user access.
Security and HIPAA Compliance Controls
Dash simplifies HIPAA compliance in Amazon EC2. Dash enables healthcare organizations to define custom administrative policies and controls for EC2 including the System Access Policy, Configuration Management Policy, and Disaster Recovery Policy. Dash Continuous Compliance Monitoring scans EC2 security groups, EBS volumes and related AWS services including Amazon S3 and Amazon IAM for security and compliance issues, so security teams can monitor and maintain HIPAA compliance in EC2 and AWS.
Dash Compliance Automation – EC2 Security Controls
HIPAA Safeguards
164.308(a)(4)(ii)(A) – Isolation Health Clearinghouse Functions
164.308(a)(5)(ii)(B) – Protection from Malicious Software
164.312(b) – Audit Controls
164.312(c)(1) – Integrity
Dash Administrative Controls
System Access Policy
Configuration Management Policy
Auditing Policy
Dash Technical Controls
Security Group: All ports open to all
Security Group: Unrestricted network traffic within security group
Security Group: DB ports open to all
Security Group: Large port range(s) open to all
Security Group: Default security groups in use
EBS volume is unencrypted
VPC Network ACLs allow all egress
VPC Network ACLs allow all ingress
Subnet does not have a flow log