AWS HIPAA Compliance: Best Practices Checklist
- Companies that decide to build HIPAA compliant apps on AWS, should know the following:
- Is AWS cloud HIPAA compliant?
- Is it compulsory to sign a Business Partner Agreement with AWS?
- What is Shared Responsibility?
- How to use AWS tools correctly to make the app HIPAA compliant?
- What requirements and controls are recommended to be implemented?
-
This checklist will assist you in building a scalable, reliable and secure HIPAA compliant solution on AWS.
Table of Contents
The healthcare industry is facing a new evolutionary wave of digital IT technologies that usher in a new era of global computing. In the previous blog entry, we talked about how digital technology is transforming the healthcare industry and how patients are receiving care.
This new wave of transformation and innovation requires other approaches to creating healthcare solutions. To drive the innovations and build groundbreaking solutions, we need to abandon the traditional (on-premises) approach and move to cloud-based architecture. Every industry is now using cloud technology in one form or another. Currently, most healthcare companies see the benefits of Cloud technology and consider it as a way to improve the convenience and quality of care they provide to patients This gradually shifts operations toward the cloud. Healthcare organizations that are struggling to deliver high-quality patient outcomes are focused on data-driven decision making and improving precision medicine by taking advantage of innovative technologies such as mobility, Internet of Things (IoT), Artificial Intelligence (AI), Big Data and Cloud Computing.
But when we talk about security and compliance requirements, the approach to ensuring this in the cloud is much different than on-premise. Lack of security and privacy are two major concerns that healthcare organizations face when choosing a cloud solution. To overcome these concerns, healthcare organizations must choose a reliable cloud provider who operates in full compliance with the provisions of the Health Insurance Portability and Accountability Act (HIPAA) of 1996.
Amazon Web Services (AWS) is a cloud secure platform on which healthcare organizations can innovate. AWS offers an extensive AWS HIPAA services list to develop a highly scalable, secure, and fault tolerance solutions that can serve an unlimited number of healthcare use cases.
In this article, we’re going to discuss the technical implementation of AWS HIPAA Compliance Requirements Checklist.
So let’s dig in how to meet AWS HIPAA compliance.
Table of Contents
Is AWS Cloud HIPAA Сompliant?
Yes, in general, AWS is HIPAA compliant and can be used to build cloud-based systems that process, store and transmit electronic personal health information (ePHI). But just using AWS services doesn’t make your solutionit HIPAPA compliant directly. When your AWS-based system deals with ePHI, you must adhere to the AWS HIPAA security requirements and regulations.
The AWS HIPAA compliance is rather how well we know how to implement it in AWS than just use services offered by the platform. The AWS helps to build high-load systems that process vast amounts of ePHI in accordance with HIPAA. But first of all, you need to accept the AWS Business Associate Addendum (AWS BAA).
Sign a Business Partner Agreement with AWS
In accordance with HIPAA regulations, any company that wants to do business that falls under HIPAA compliance have to be prepared to sign a business associate contract with its customers.
For organizations who deal with ePHI, and as a result, must comply with HIPAA regulations, Amazon a AWS Business Associate Agreements for HIPAA-eligible Services to confirm that AWS properly protects ePHI. It includes the unique (“HIPAA-eligible”) AWS services and introduces the AWS Shared Responsibility Model where security and compliance are a shared responsibility of Amazon and customers. Amazon is responsible for the security of the cloud while the administrative and technical safeguards in the cloud are managed by customers exclusively using HIPAA-eligible services. Using these services for storing, processing, and transmitting ePHI allows customers and AWS to meet HIPAA requirements.
You can manage BAA directly in your account via the AWS Artifact in the AWS Management Console.
Make sure you understand what a Shared Responsibility is
Understanding how to build HIPAA compliant solution using AWS services means understanding the shared responsibility model. In the AWS Cloud, security is shared between Amazon and customers. This means that Amazon is responsible for managing the infrastructure components and physical security of the AWS data centers and customers are responsible for other aspects (e.g. security and configuration of AWS services). With all this in mind, the only way to make sure that you are keeping up your end of the bargain is to understand which parts of the model you are responsible for. Many companies believe that if they host an application on AWS, it’s Amazon’s ultimately responsible for ensuring compliance. But it’s NOT quite true.
Amazon is responsible for “Security of the AWS Cloud”:
Amazon is responsible for maintaining and protecting its global infrastructure which is used by AWS service. Amazon manages the physical security of the following areas:
- Computing
- Storage
- Databases
- Networking
- Region
- Availability Zone
- Edge location
Customer’s responsibility is “Security in the AWS Cloud”:
Customers are responsible for the security of their chosen AWS services. Customers manage security in the following areas:
- Platforms
- Applications
- Identity and access management tools and processes (IAM)
- Operating systems
- Networking traffic protection
- Firewall configurations
- Client and Server side encryption
As you can see from the above, AWS provides you with the infrastructure to build cloud-based healthtech solutions in accordance with HIPAA, but it’s completely your responsibility for choosing and properly configuring services that ensure the security and integrity of ePHI.
Don’t assume that AWS services are instantly compliant with HIPAA rules.
AWS HIPAA-eligible services are secure by default. But the settings can be changed and as a result stored ePHI will be vulnerable. Improperly configured AWS services may lead to a situation that your ePHI data will be accessible to anyone who knows where to look at. Unfortunately, since there are several ways to grant permissions, there are also several points that mistakes can occur. And as we know, simple mistakes can lead to serious consequences.
It’s important to know how each AWS tools/features can be correctly used towards HIPAA compliance, even if Amazon says that these services are HIPAA-eligible.
Here are a few suggested strategies you can follow when using AWS for HIPAA-compliant solutions:
- Turn off public access.
- Configure AWS Identity and Access Management (IAM) with custom IAM policies,associated groups, roles, and instance profiles.
- Identify and separate processes that deal with ePHI from orchestration processes. Performing automation to trace the flow of ePHI
- Set-up logging, monitoring, and alerts using AWS CloudTrail, Amazon CloudWatch, and AWS Config rules.
- Enable encryption for storage services such as Amazon Redshift, Amazon RDS, and Amazon Elastic Block Store (Amazon EBS) to ensure HIPAA compliance and security requirements.
- Configure logical boundaries between ePHI and general data.
- Segregate your network. Create external-facing Amazon Virtual Private Cloud (Amazon VPC) Multi-AZ architecture with separate subnets for different application layers and private (back-end) subnets for application and database layer.
- Schedule patching.
Implement “Access Control” requirements
This goes without saying, but let’s just say it that providing public, unauthorized access to ePHI (directly or indirectly) is a violation of HIPAA rules. HIPAA requires central identity management and necessitates the close control of access to data. Here are several best practices for implementing “Access Control” requirements in an AWS HIPAA-compliant environment:
Create and use IAM roles instead of the root account
When a new AWS account is being set-up, it’s important to enable MFA for your root account, create an Admin role, and lock away the root account token in a high secure box (or better yet don’t create a token for your root account at all). The decision not to use the root account improves overall security because every user is restricted by IAM policies. So, if the account keys are inadvertently shared or stolen, the damage is limited to some degree and can be quickly disabled.
Grant least privileges
More privileges than necessary opens the door for human errors and introduces the need for more complex audits. In healthcare organizations IAM users often need access to only a small portion of the AWS environment. IAM policies greatly simplify an investigation of who has access to what resources.
Best practice is to grant least privilege — and then grant more privileges in each specific case, if necessary.
Enable MFA everywhere
Multi-Factor Authentication provides an important level of security in any environment. Even if the password is shared or unintentionally issued, malicious users will not be able to access the account. This is critically important in HIPAA-compliant environments.
Rotate credentials regularly
Any credentials that remain active for too long increases the risk of being compromised. AWS recommends that it’s best practice to regularly rotate all credentials, API access keys, and passwords. AWS outlines a manual process using the AWS CLI to create a second set of credentials, programmatically create and distribute the access keys.
Implement “Person or Entity Authentication” requirements
The authentication and authorization component is critical for every healthcare system that aims to meet HIPAA requirements in AWS. Such systems should have bulletproof rules that will identify the application’s persons or entities and determine what they can do in it.
When developing person and entity authentication procedures for AWS-based system, it’s important to remember that IAM is mainly focused on managing access to your AWS services and resources. In most cases, in addition to IAM, you will most likely need to set up an additional level of authentication and authorization control in your healthcare application. To achieve this, you can use an existing and proven authentication protocols, such as SAML 2.0 or OAuth.
You can also add a simple way to sign-up, sign-in, and access control to your web or mobile application by using Amazon Cognito service. This new feature eliminates the need for a separate username, and you are able to use the built-in features of Cognito User Pools to verify these email addresses or phone numbers.
The Data Backup and Disaster Recovery Implementation
Every entity that falls under HIPAA regulations must have developed an emergency plan how to protect ePHI data in case of a disaster. To avoid losing private and critical patients’ information you have to ensure that the ePHIs which are collected, stored, and used within your system are backuped and the backup and recovery processes are configured properly. Most AWS services allow you to configure backup and recovery processes, so you can restore the last stable state of ePHI if some information is lost. By using features such as EC2 AMI snapshots (in the Amazon EBS, Amazon RDS, and Amazon Redshift services) you will be able to meet most of the data backup requirements.
Amazon S3 is HIPAA compliant and is the most popular options for securely managing scalable and durable backups of your data. With Amazon S3 you have several options on how to ensure the privacy and security of ePHI records. Amazon S3 provides client-side encryption to protect data in transit and additional server-side encryption to protect your data at rest.
Disaster recovery is a set of tools and procedures that aim to protect an organization’s data and critical IT infrastructure in times of disaster. This is usually one of the most expensive HIPAA requirements to comply with. In AWS you can use global infrastructures (regions and multiple Availability Zones) to build fault-tolerant solutions that are highly resilient in case of network failures, system downtime and natural or human-induced disaster.
Implement Encryption and Decryption of PHI in AWS
In accordance with the HIPAA compliance guidelines, ePHI must be encrypted both in transmission (“in transit”) and in storage (“at rest”). While HIPAA addresses the security and privacy of ePHI as a policy and procedural approach with no strict parameters, AWS requires customers to encrypt transmitted and stored ePHI records using HIPAA-eligible services
AWS offers a wide range of features and services to make key management and encryption of ePHI easy to manage including the AWS Key Management Service.
Implement the “Transmission Security” requirements
As detailed in the AWS BAA, you must to encrypt all ePHI in transit. To secure data during transit, you should always use Secure Socket Layer (SSL) endpoints for all services.
Using SSL certificates with very strong SSL termination policies can help you protect your stored ePHI. You need to have SSL certificate installed to encrypt the traffic between the client and the server. You can use AWS Certificate Manager (ACM) to create an SSL certificate.
Implement Audit Logging & Monitoring Controls
Auditing and monitoring controls are a Technical Safeguard that must be addressed when architecting for HIPAA compliance on AWS using technical controls by anyone who wishes to store, process, or transmit electronic patient data.
In order to address this safe ground in AWS, you need to launch AWS CloudTrail that allows you immediately begin recording all AWS API calls. You can also enable CloudTrail log file validation. If logfile scanning is enabled, any changes made to the log file itself after its delivery to the S3 bucket will be identifiable. It’s important to launch the AWS Config service that gives you the tool to audit and inventory the AWS resources, evaluate the configurations of history and change notifications.
Organizations covered by HIPAA are required to track, log and store (over a period of time) all operations with ePHI records. In addition, such organizations should have policies and processes for regularly reviewing and running analytics of log records. In AWS you can do this by launching an AWS CloudWatch service that allows you to collect and monitor the activities on your AWS resources (e.g. Amazon EC2, Amazon RDS, Elastic Load Balancer (ELB) instances, and Amazon EBS volumes). Also you can use CloudWatch agent that enables you to develop and publish your own metrics to get specific information from your resources.
When using these logging and monitoring tools you should definitely be sure that logs do not actually store any ePHI. You should carefully check everything that is logged. For example, in most situations if a username and/or IP address is coming in the logs, would be considered as a violation of HIPAA rules. Therefore, you will need to catch such specific cases to make sure that private information is not mentioned in the logs. If in some cases you still need to have private information in logs, you will need to encrypt it before sending it to AWS CloudTrail.
AWS Artifact for HIPAA Compliance on AWS
One of the key tools that AWS provides for managing HIPAA compliance is AWS Artifact. This self-service portal allows AWS customers to access AWS’ security and compliance reports, which can be crucial for performing security and compliance assessments. AWS Artifact provides on-demand access to AWS’s attestations, audits, and certifications, demonstrating the robust security measures in place for HIPAA compliance on AWS.
By using AWS Artifact, healthcare organizations can easily retrieve necessary audit artifacts to validate that AWS security and compliance controls are in place and operating effectively. This can be particularly useful when demonstrating HIPAA compliance to auditors or stakeholders.
Avoiding Common Misconfigurations for HIPAA Compliance on AWS
While AWS provides a robust platform for building HIPAA-compliant applications, it’s crucial to be aware of common misconfigurations that could potentially lead to HIPAA violations. For instance, one of the most common misconfigurations is improperly configured S3 buckets. Amazon S3 is one of the AWS HIPAA eligible services, but if not correctly configured, it can lead to unauthorized access to protected health information (PHI), violating HIPAA rules.
To ensure S3 HIPAA compliance, it’s essential to:
- Ensure that all S3 buckets containing PHI are not publicly accessible.
- Enable server-side encryption for S3 buckets to protect data at rest.
- Use AWS Identity and Access Management (IAM) policies to control access to S3 resources.
By understanding and avoiding these common misconfigurations, healthcare organizations can better ensure their HIPAA compliance on AWS.
Summarizing all of the above, we can say that the number of healthcare organizations that use AWS to ensure a high level of delivered healthcare services are growing every day. AWS has made significant efforts to align itself with the HIPAA to promise its customers that storing, maintenance and processing ePHI can be performed without errors or possibilities of vulnerabilities. This way you can be sure of HIPAA compliance while using AWS.
Romexsoft team of AWS certified engineers have extensive experience in implementing HIPAA in EMR/EHR software and creating reliable and scalable environments in compliance with standards such as HIPAA. We can guide you through the design, development and operational stages of HIPAA-compliant systems to help you get the most out of the elasticity, efficiency, and resilience of the AWS cloud.
Interested in creating a HIPAA-compliant AWS solution? We will be glad to help!
AWS HIPAA Compliance FAQ
While AWS is HIPAA compliant, merely using AWS services doesn't automatically make a solution HIPAA compliant. When systems on AWS handle electronic personal health information (ePHI), they must adhere to AWS HIPAA security requirements and regulations. AWS provides the infrastructure and tools, but the correct implementation and configuration are essential to ensure compliance.
The Shared Responsibility Model in AWS divides security responsibilities between Amazon and the customer. Amazon is responsible for the security of the AWS Cloud, which includes the global infrastructure and physical security of AWS data centers. In contrast, customers are responsible for security within the AWS Cloud, including the security and configuration of AWS services, applications, identity and access management, and more. Understanding this model is crucial as both parties have distinct roles to play in ensuring HIPAA compliance.
While AWS HIPAA-eligible services are secure by default, configurations can be changed, potentially making stored ePHI vulnerable. It's essential to understand how each AWS tool or feature can be used towards HIPAA compliance. Some strategies include turning off public access, configuring AWS Identity and Access Management (IAM) appropriately, segregating network, enabling encryption for storage services, and setting up logging, monitoring, and alerts using AWS CloudTrail, Amazon CloudWatch, and AWS Config rules.
AWS Artifact is a key tool provided by AWS for managing HIPAA compliance. It's a self-service portal that allows AWS customers to access AWS’ security and compliance reports, which can be vital for performing security and compliance assessments. AWS Artifact provides on-demand access to AWS’s attestations, audits, and certifications, showcasing the robust security measures in place for HIPAA compliance on AWS.