How to achieve HIPAA compliance on AWS: A guide
Healthcare companies that are accustomed to complete control over physical systems often struggle to understand their responsibilities in a cloud environment. Who is responsible for which aspects of compliance? Can healthcare companies trust Amazon with their mission-critical apps and sensitive data? What are the rules and boundaries for AWS compliance?
Mastering these intricacies can help you create compliance-ready systems on AWS. In this article, we will cover the basics, but for a deeper dive, download our eBook on Compliance on AWS.
Shared compliance responsibility on AWS (the short version)
By migrating to AWS, you have a shared compliance responsibility. This shared model means that AWS manages the infrastructure components from the host operating system (virtualisation layer) down to the physical security of AWS’ data centres. It is the customer’s responsibility to configure and secure AWS-provided services. In other words, AWS controls physical components; the customer owns and controls everything else. As AWS states repeatedly, “AWS manages security of the cloud, security in the cloud is the customer’s responsibility.”
Bottom line: Think of operating a compliant environment in AWS as similar to operating in a rented data centre. The data centre is responsible for controlling access to the data centre, locking the cages, and the physical security of the network — but you are responsible for everything else.
The AWS Shared Responsibility Model. Includes tasks performed by Logicworks. If you are managing your own environment, the tasks in blue would be your responsibility.
The same line of demarcation applies to IT controls. Customers in AWS shift the management of some IT controls to AWS, which results in a shared control environment. AWS manages controls associated with the physical and architectural infrastructure deployed in the AWS environment; the customer is responsible for network controls (Security Group configurations), access controls, encryption, and any control not directly managed by AWS.
For example, AWS provides the Identity and Access Management (IAM) tool and is responsible the IT controls in place that govern access to the physical infrastructure that holds your access policies, and customers are responsible for the setting up and maintaining roles and users in IAM. Inappropriate or unauthorised usage of an AWS resource as a result of inadequate IAM controls is the customer responsibility.
Physical security and environmental controls
Any customer can access a copy of AWS’ SOC 1 Type II report, which provides significant detail about physical security and environment controls. The report can be accessed through AWS Artifact, a repository of audit artifacts. This means that if an auditor requests specifics regarding the physical controls of a customer’s system, they can reference the AWS SOC 1 Type II report. AWS does not allow data centre tours, as independent reviews of data centre security are also part of the SOC, ISO 27001, and other audits.
AWS customers retain control and ownership of their data, and customers can move data on and off of AWS storage as required. AWS does not leverage any third-party providers to deliver services to customers and therefore does not provide any customer information or access to data to any other provider. Customers must control access to applications and data through the AWS Identity and Access Management service.
Client environments on AWS infrastructure are by default logically segregated from each other and have been designed to prevent customers from accessing instances not assigned to them. AWS has both instances that are dedicated to a single customer (Dedicated Instances) and instances hosted on shared infrastructure. AWS is responsible for patching the hypervisor and networking services, while customers patch their own guest operating systems, software, and applications.
AWS provides services to help customers perform their own backups. Amazon S3 and Glacier are the most popular options, and AWS provides data durability and redundancy guarantees. In this way, AWS provides services to enable disaster recovery and resiliency but does not automatically provide backups.
HIPAA in AWS
New AWS customers often ask: Is AWS compliant with HIPAA? The answer to this question is complex. The short answer is that AWS is not “HIPAA compliant”, but it provides services that facilitate HIPAA compliance.
The U.S. Health Insurance Portability and Accountability Act (HIPAA) Privacy and Security Rules for protecting Protected Health Information (PHI) does not provide a certification or Attestation of Compliance to cloud providers or to healthcare companies. HIPAA is a set of federal regulations, not a security standard. A company and its business associates can be periodically audited for compliance with HIPAA regulations by the HHS Office for Civil Rights (OCR), and in the course of that audit it can meet or fail to meet those requirements, but it cannot be “Certified HIPAA Compliant”.
In order to process, store, or transmit PHI in AWS, a healthcare company (the “covered entity”) must sign a Business Associate Agreement (BAA) with AWS, meaning that AWS is performing function or activities on behalf of the covered entity.
However, signing a BAA with AWS does not mean that the customer is “HIPAA compliant”. The customer can maintain compliance with HIPAA regulations through its own efforts to use cloud tools, architect applications, control access, etc. in a manner that complies with those regulations. AWS only assumes responsibility for physical hardware security controls of a limited number of covered services.
For each compliance standard, there is a subset of AWS services/programs that are “in scope” of either the Attestation of Compliance, report, or contract. This means that these services have been audited by a third party for that specific compliance standard.
Customers may use any AWS service in an account designated as a HIPAA account, but they should only process, store and transmit PHI in the HIPAA-eligible services defined in the BAA. There are nine HIPAA-eligible services today, including:
- Amazon DynamoDB
- Amazon EBS
- Amazon EC2
- Amazon Elastic MapReduce (EMR)
- Amazon Elastic Load Balancer (ELB)
- Amazon Glacier
- Amazon Relational Database Service (RDS) [MySQL and Oracle engines]
- Amazon Redshift
- Amazon S3
Again, this does not preclude customers from using services that are not in scope. For example, AWS CloudFormation, an infrastructure as code service that we discuss in-depth in our eBook, is not included in the list of services in scope for a HIPAA BAA. But as long as no PHI is stored, processed or transmitted in AWS CloudFormation, a covered entity may use it. AWS CloudFormation is a templating service that can build out the core components of AWS architecture (networks, instances, etc) and therefore rarely if ever touches customer data in any use case, even in non-HIPAA regulated environments. Similarly, customers can use a service like AWS CloudWatch Logs, a logging service, if logs are scrubbed of customer information.
Compliance responsibility: Insource vs. outsource
Compliance management is a complex set of tasks with many interrelated components. By outsourcing to AWS, you are already removing some of the risk and cost of compliance, particularly as it relates to physical infrastructure security. Outsourcing infrastructure management to a third party Managed Services Provider further reduces your compliance burden.
Most companies that have compliance obligations and are new to AWS choose to work with a partner to plan, build, deploy, and operate their AWS environment in order to minimise risk, rapidly build out a compliance-ready environment, and minimise the time and effort of ongoing compliance maintenance.
Below is an example of a compliance responsibility matrix when you work with Logicworks:
AWS has published extensively on the topic of shared compliance responsibility. If you are considering hosting regulated data in AWS, we highly recommend that you utilise these resources:
General compliance information:
- Continuous Compliance on AWS: http://go.logicworks.net/aws-continuous-compliance
- AWS Compliance: https://aws.amazon.com/compliance/
- AWS Risk and Compliance Whitepaper: https://d0.awsstatic.com/whitepapers/compliance/AWS_Risk_and_Compliance_Whitepaper.pdf
- Frequently Asked Questions About Compliance in the AWS Cloud: https://aws.amazon.com/blogs/security/frequently-asked-questions-about-compliance-in-the-aws-cloud/
- AWS Services in Scope by Compliance Program: https://aws.amazon.com/compliance/services-in-scope/
- AWS Security Whitepaper: https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf
- Architecting for HIPAA Security and Compliance on AWS: https://d0.awsstatic.com/whitepapers/compliance/AWS_HIPAA_Compliance_Whitepaper.pdf
- Frequently Asked Questions About HIPAA Compliance in the AWS Cloud: https://aws.amazon.com/blogs/security/frequently-asked-questions-about-hipaa-compliance-in-the-aws-cloud/
- How to Automate HIPAA Compliance (Part 1): Use the Cloud to Protect the Cloud: https://aws.amazon.com/blogs/security/how-to-automate-hipaa-compliance-part-1-use-the-cloud-to-protect-the-cloud/
Interested in hearing industry leaders discuss subjects like this and sharing their Cyber Security & Cloud use-cases? Attend the Cyber Security & Cloud Expo World Series events with upcoming shows in Silicon Valley, London and Amsterdam to learn more.
- » Google achieves ‘quantum supremacy’ with new experiment – reports
- » Eradicate human error and make your cloud implementation a picnic
- » Kubernetes and multi-cloud: How to monitor your modern applications effectively
- » Is performance engineering still needed when it comes to cloud?
- » Moving from DevOps to modern ops: Why there is no room for silos when it comes to cloud security