Subsections:
- AWS Overview
- AWS Shared Responsibility Model
- AWS BAA
- AWS Security At Rest
- AWS Security In Transit
- AWS Network Security
Amazon Web Services (AWS) is a secure cloud service provider. It offers vast selection of services including computing power, storage, content delivery and others to help businesses scale and grow efficiently.
AWS is HIPAA compliant and can be used to process, store and transmit ePHI. This however apply certain restrictions on used services and requires specific measures aimed to secure your infrastucture. Usage of AWS does not automatically make your cloud infrastructure HIPAA compliant.
AWS offers subset of their services as HIPAA eligible. Usage of other services outside of this list is not allowed. Full list is available on their HIPAA Eligible Services Reference page. This list is changing over time as AWS adds HIPAA eligibility for more services, check AWS reference page to get latest details.
Currently (updated Sep 7, 2017) following services are HIPAA eligible:
- Amazon API Gateway excluding the use of Amazon API Gateway caching
- Amazon Aurora [MySQL-compatible edition only]
- AWS Batch
- Amazon CloudFront [including Lambda@Edge]
- Amazon Cognito
- Amazon Connect
- AWS Database Migration Service
- AWS Direct Connect
- AWS Directory Services excluding Simple AD and AD Connector
- Amazon DynamoDB
- Amazon EC2 Container Service (ECS)
- Amazon EC2 Systems Manager
- Amazon Elastic Block Store (Amazon EBS)
- Amazon Elastic Compute Cloud (Amazon EC2)
- Elastic Load Balancing
- Amazon Elastic MapReduce (Amazon EMR)
- Amazon Glacier
- Amazon Inspector
- Amazon Kinesis Streams
- AWS Lambda
- Amazon Redshift
- Amazon Relational Database Service (Amazon RDS) [SQL Server, MySQL, Oracle, and PostgreSQL, MariaDB engines only]
- AWS Shield [Standard and Advanced]
- Amazon Simple Notification Service (SNS)
- Amazon Simple Queue Service (SQS)
- Amazon Simple Storage Service (Amazon S3) [including S3 Transfer Acceleration]
- AWS Snowball
- AWS Snowball Edge
- Amazon Virtual Private Cloud (VPC)
- AWS Web Application Firewall (WAF)
- Amazon WorkDocs
- Amazon WorkSpaces
Business Associate Agreement (BAA), or Business Associate Addendum (as AWS reference it) need to be signed before you can start usage of AWS for your HIPAA compliant workloads.
AWS implements shared responsibility model where AWS manages security "of the cloud" and leave security "in the cloud" to be managed by the customer.
AWS offers a HIPAA-focused Whitepaper Architecting for HIPAA Security and Compliance on Amazon Web Services: it has good overview of all HIPAA eligible services and explains how they can be used for building systems processing health information.
As a summary, here is a list of steps to HIPAA compliant AWS infrastructure:
- Understand shared responsibility model
- Sign BAA (Business Associate Addendum)
- Use HIPAA eligible services to build your infrastructure
- Make sure your AWS services configuration is HIPAA compliant (this is customer's part of the shared responsity model)
AWS implements shared responsibility model where AWS manages security "of the cloud" and leaves security "in the cloud" to be managed by the customer. It means there are two categories of security measures applied.
-
Security of the cloud: security measures that the cloud service provider (AWS) implements and operates
-
Security in the cloud: security measures that the customer implements and operates, related to the security of customer content and applications that make use of AWS services
Basically AWS provides infrastrucuture for your applications that can be used in HIPAA compliant way. But it's your (AWS customer) responsibility to configure cloud infrastructure to ensure confidentiality, integrity and availability of ePHI. You are also responsible for security of the application(s) deployed on top of this HIPAA compliant cloud infrastructure.
Following diagram demostrates this partitioning of responsibility.
AWS as a cloud service provider manages physical security of the following components.
- Regions and availability zones
- Edge locations
- Compute resources
- Storage resources
- Databases
- Networks
You as a customer manage security of the following areas.
- Network traffic protection
- Server-side encryption (for storage and databases)
- Data transmission integrity and encryption
- Data availability
- Disaster recovery
- Access management
All these areas are typically covered by the cloud service provider (AWS) offerings but require proper cloud architecture and configuration to be implemented by the customer.
Additionally you are responsible for security of components deployed on top of your AWS cloud infrastructure.
- Operating systems
- Platforms
- Applications
Understanding of the shared responsibility model is an important step towards running your HIPAA application in AWS cloud. You can clearly see the boundaries of AWS offering in terms of security and plan your cloud architecture accordingly.
AWS requires Business Associate Addendum (BAA) to be signed before you can start usage of AWS for your HIPAA compliant workloads.
AWS offers AWS Artifact service as self-service portal for on-demand access to security compliance reports and agreement (only BAA and NDA for now).
Step 1: Accept AWS Artifact NDA.
- Sign in and open AWS Artifact console
- Open Agreements section
- Open AWS Artifact Nondisclosure Agreement subsection
- Click on Download and review AWS Artifact NDA link and read NDA
- Check "I have downloaded, read and agree ..." box
- Click on "Accept ..." button
Final state before clicking the button is shown on the picture below.
Step 2: Accept AWS BAA.
- Open AWS Business Associate Addendum subsection
- Click on Download and review AWS BAA link and review BAA
- Check all 3 boxes
- Click on "Accept ..." button
Final state before clicking the button is shown on the picture below.
Now you can start usage of your AWS account for HIPAA compliant workloads. AWS requires that when you include PHI in this account, YOU MUST:
- Use only HIPAA Eligible Services in connection with PHI, and
- Encrypt all PHI in-transit and at-rest.
This does not restrict usage of this AWS account for data and application not covered by HIPAA requirements. However this usually requires specific cloud architecture where PHI is strictly separated from non-PHI resources.
AWS BAA can be terminated at any time using AWS Artifact service. This means you have to delete all PHI under this account prior to termination, and stop further usage of this account in connection with any PHI.
AWS requires customers to encrypt PHI stored using HIPAA eligible services. Encryption guarantees that data will be unusable to unauthorized individuals in case of storage breach (like physical access to a disk with PHI). Assuming decryption key was not breached.
Data encryption in the storage ("at-rest") can be implemented using the following appoaches (or combination in some cases).
- SSE (server-side encryption): mechanism provided by AWS services, uses AES-256 GCM algorithm. The easiest way to utilize storage encryption on AWS platform.
- Application level encryption: implemented using application framework or by intergating third-party solutions. Gives more flexibility in terms of authorization model and encryption algorithms.
AWS Key Management Service (AWS KMS) is a managed service that makes it easy to manage and control encryption keys used to encrypt your PHI. It's integrated with other AWS services that provide SSE capabilities. Also you can use it as a centralized key store for all your applications.
AWS KMS does not need to be HIPAA eligible service if it's used to manage keys for applications running on top of other HIPAA eligible services. Essentially PHI never reaches AWS KMS service itself because it stores only encryption keys. However AWS KMS has strong security and quality controls, built-in highly availability, durability and scalability. Therefore AWS KMS is highly recommended for deployments having HIPAA security compliance requirements.
SSE (server-side encryption) using AWS KMS outlined on the following diagram:
Yellow color means that data stored there will be encrypted. AWS KMS is used for encryption keys generation and distribution to services. Currently SSE (server-side encryption) available for:
- Amazon Elastic Block Store (Amazon EBS)
- Amazon Simple Storage Service (Amazon S3)
- Amazon Glacier
- Amazon Simple Queue Service (SQS)
- Amazon Relational Database Service (Amazon RDS) [MySQL, Oracle, PostgreSQL]
- Amazon Aurora
- Amazon DynamoDB
- Amazon Redshift
- Amazon Elastic MapReduce (Amazon EMR)
- AWS Snowball
- AWS Directory Services
- Amazon WorkDocs
- Amazon WorkSpaces
Application level encryption using AWS KMS outlined on the following diagram:
Again yellow color shows where data will be encrypted. In this scenario application uses AWS KMS to get encryption key and performs encryption. Then encrypted data is sent to EBS volume for storage. Here standard encryption available for EBS (and other services) may not be used because data is already unreadable upon leaving the application.
Application level encryption requires more effort if compared to standard SSE implementation. But it has more flexibility, for example you may want to have encryption performed for each user of your application using separate keys. If this level of granularity is not required, then standard SSE provided by AWS will be enough.
All PHI transferred through network connections ("in-transit") must be encrypted. This applies to all types of connections to/from processing or storage resources involved into dealing with PHI. Encryption methods, configurtions and procedures are different for various connection types and architectures.
Typical AWS deployment has two types of data transfer paths (or connections): external and internal.
-
External data transfer: from the customer (real user or other software if your application has an API) to AWS infrastructure. In this case PHI is transferred through multiple networks from the customer location to AWS data center. These networks are controlled by third-party providers that's why unencrypted transfer of PHI is highly unsafe.
-
Internal data transfer: happens between AWS services. This is happening inside the network controlled by AWS. Depending on your infrastructure PHI can be transferred within availability zone, between availability zones or between data centers. Even though PHI is not leaving networks controlled by AWS these networks are shared between multiple AWS's customers and can not be considered highly secure.
Described AWS infrastructure (in a bit simplified form) is outlined on the following diagram. Red arrow shows external data transfer, yellow arrows show internal data transfer.
Consumer to ELB is an external data transfer path in this schema. Elastic Load Balancer or ELB is the only Internet-facing component in this architecture. To protect the confidential PHI data your ELB must be configured to allow only TLS encrypted communication.
This requires a SSL/TLS certificate to be deployed at the ELB, this certificate must be signed by CA (certificate authority). You can use AWS Certificate Manager which is free and integrated with various AWS services (including ELB), or you can use any other CA and then just upload a certificate.
ELB load balancer can be configured to use TCP pass-through mode, in this case your application servers should have a certificate and will be responsible for traffic encryption and decryption. See more about that in ELB documentation.
Further explanation is for internal data transfer paths.
ELB to EC2. ELB forwards traffic to one or more EC2 instances which run your
application and responsible for actual handling of your consumers' requests.
Since external traffic is decrypted at ELB using CA signed certificate it must
be encrypted again before transmission to the EC2 instance(s).
This can be achieved using the following measures.
- Configure EC2 instance to accept connection through TLS encrypted connection only (for HTTPS use port 443).
- Generate and install self-signed TLS/SSL certificate to the EC2 instance.
Details of this step heavily depend on used OS and software chosen to handle requests on EC2 side. - Point ELB to these secured EC2 endpoints.
EC2 to EC2. Your application servers may have a need to interact with other EC2 instances. For example, this is necessary if you use microservices design pattern to build your system. Another example (which does not fit into this simplified architecture but still often used) is a database cluster deployed over AWS EC2 nodes. Databases like Cassandra or MongoDB are not available as managed AWS services, so you'll have to use EC2 if you want to use them.
In either case interaction between EC2 instances must be allowed through TLS encrypted connections only. If that's part of your application, then you need to use available frameworks to add encryption functionality. If you need it for other application (like database cluster), then this software need to be configured to use TLS connections.
This usually requires a self-signed TLS/SSL certificates. Details of configuration and ceritificate(s) deployment depend on the application or framework used for handling these connections.
EC2 to AWS services (RDS, S3, SQS, etc). Most likely your application utilizes one or more AWS services. We are not covering details of each service here but typically application's needs fall into one of the following categories:
- database,
- file storage,
- message queue.
For all these services you must ensure that only encrypted connection is used to transfer PHI to/from AWS service. This can be achieved by usage of:
- HTTPS endpoints if there is an API, or
- TLS based encrypted network connection.
These recommendations cover the typical AWS infrastructure, it can be different for your application but basic principles of handling PHI in-trasit remain the same.
AWS Virtual Private Cloud (VPC) is the networking
layer for AWS cloud infrastructure. It enables you to deploy AWS resources into
a virtual network that you've defined. This virtual network closely resembles
traditional network that you'd operate in a data center. However AWS network
uses Software Defined Network
(SDN) technology.
This approach allows you to initialize and manage scalable AWS network
infrastructure dynamically via API or using other software interfaces and tools.
VPCs are created using following main building blocks (this is not a complete list, see VPC documentation for more details).
-
Subnet: this is a range of IP addresses in your VPC. Subnet has a route table and security policies associated with the subnet that allow change of network behavior of resources placed into subnet according to specific needs.
-
Internet Gateway: enables resources inside the VPC to connect to the Internet. This behavior is configured through subnet route tables. Subnet that allows traffic flow to/from Internet Gateway is a public subnet, otherwise it is a private subnet.
-
NAT Gateway: allows connections from resources inside VPC to the Internet, but prevents unsolicited inbound connections to protected resources. Must be used by private subnets as a method of accessing the Internet, if that's necessary.
-
Network ACL: act as a firewall for associated subnets, controlling both inbound and outbound traffic at the subnet level.
-
Security Group: act as a firewall for associated resources, controlling both inbound and outbound traffic at the instance level.
Each modern AWS account has a default VPC, also customers can create additional nondefault or custom VPCs. For HIPAA compliant workloads usage of default VPC is not recommended. You have to create custom VPC is order to make your network more secure by configuring and controlling it top-to-bottom.
AWS VPC supports multiple network configuration scenarios. If you want to design cloud network architecture optimized for your system and organization needs, then it makes sense to use help of professionals. In this guide we'll outline one possible scenario suitable for public-facing web applications or APIs that use multi-tier software architecture.
Some comments about this scenario.
- Public subnet: used for resource that require direct connection to/from the Internet
- Private subnet: used for application and database resources, they must be protected and can not access the Internet directly
- IGW (Internet Gateway): entry point for the Internet traffic
- ELB (Elastic Load Balancer): receives incoming requests and forward them to app/web server(s)
- NAT (NAT Gateway): allows resources in private subnet access the Internet
- AZ1, AZ2: shows different Availability Zones, the same subnets need to be replicated across AZs to improve appications availability
This architecture requires additional component that allow you perform various administrative tasks on your resources such as server configuration, maintenance and software upgrades. Depending on your organization need to choose one of recommended approaches.
- AWS Hardware VPN: create an IPsec, hardware VPN connection between your VPC and your remote network. In this case AWS VPC becomes an extension of existing organization framework.
- Software VPN (OpenVPN): create a VPN connection by using an Amazon EC2
instance in your VPC that's running a software VPN appliance.
OpenVPN is a commonly used package that provide VPN functionality. This approach allows to access VPC from any computer assuming it has properly configured OpenVPN client software.
Network monitoring and audit can be performed using VPC Flow Logs feature. It enables you to capture information about the IP traffic going to and from network interfaces in your VPC. Flow log data is stored using Amazon CloudWatch Logs.
Coming soon...
Coming soon...
Coming soon...