AWS HIPPA Compliance is a very common topic these days, HIPAA was expanded in 2009 by the Health Information Technology for Economic and Clinical Health (HITECH) Act. HIPAA and HITECH establish a set of federal standards intended to protect the security and privacy of PHI. HIPAA and HITECH impose requirements related to the use and disclosure of PHI, appropriate safeguards to protect PHI, individual rights, and administrative responsibilities.
AWS offers a standardized Business Associate Addendum (BAA) for such customers. Customers who execute an AWS BAA may use any AWS service in an account designated as a HIPAA Account, but they may only process, store and transmit PHI using the HIPAA-eligible services defined in the AWS BAA. For a complete list of these services, see the HIPAA Eligible Services Reference page.
AWS maintains a standards-based risk management program to ensure that the HIPAA-eligible services specifically support the administrative, technical, and physical safeguards required under HIPAA. Using these services to store, process, and transmit PHI allows our customers and AWS to address the HIPAA requirements applicable to the AWS utility-based operating model.
AWS offers a comprehensive set of features and services to make key management and encryption of PHI easy to manage and simpler to audit, including the AWS Key Management Service (AWS KMS). Customers with HIPAA compliance requirements have a great deal of flexibility in how they meet encryption requirements for PHI. and you need to be careful when configuring these service to achieve AWS HIPPA Compliance solution.
Amazon EC2 is a scalable, user-configurable compute service that supports multiple methods for encrypting data at rest. For example, customers might elect to perform application- or field-level encryption of PHI as it is processed within an application or database platform hosted in an Amazon EC2 instance. Approaches range from encrypting data using standard libraries.
Systems Manager provides a complete view of a customer’s infrastructure performance and configuration. simplifies resource and application management, and makes it easy to operate and manage their infrastructure at scale.
Amazon Virtual Private Cloud (VPC) offers a set of network security features well-aligned to architecting for AWS HIPPA Compliance. Amazon VPC allows customers to extend their own network address space into AWS, as well as providing a number of ways to connect their data centers to AWS. VPC Flow Logs provide an audit trail of accepted and rejected connections to instances processing, transmitting or storing PHI.
With Amazon EBS encryption, a unique volume encryption key is generated for each EBS volume; customers have the flexibility to choose which master key from the AWS Key Management Service is used to encrypt each volume key.
Amazon Redshift provides database encryption for its clusters to help protect data at rest. When customers enable encryption for a cluster, Amazon Redshift encrypts all data, including backups, by using hardware-accelerated Advanced Encryption Standard (AES)-256 symmetric keys.
Customers have several options for encryption of data at rest when using Amazon S3, including both server-side and client-side encryption and several methods of managing keys. Connections to Amazon S3 containing PHI must use endpoints that accept encrypted transport (HTTPS). For a list of regional endpoints.
Amazon SQS supports server-side encryption integrated with the AWS Key Management Service (AWS KMS) to protect data at rest. Communication with the Amazon SQS Queue via the Query Request must be encrypted with HTTPS. Amazon SQS is integrated with CloudTrail, a service that logs API calls made by or on behalf of Amazon SQS in your AWS account and delivers the log files to the specified Amazon S3 bucket, so if we configure SQS based on these recommendations then we can obtain an AWS HIPPA Compliance service.
Amazon Glacier automatically encrypts data at rest using AES 256-bit symmetric keys and supports secure transfer of customer data over secure protocols.
Connections to Amazon Glacier containing PHI must use endpoints that accept encrypted transport (HTTPS)
Amazon RDS allows customers to encrypt databases using keys that customers manage through AWS KMS. On a database, instance running with Amazon RDS encryption.
data stored at rest in the underlying storage is encrypted consistent as are automated backups, read replicas.
Connections to RDS for MySQL containing PHI must use transport encryption.
To ensure encryption of PHI while in transit with CloudFront, customers must configure CloudFront to use HTTPS end-to-end from the origin to the viewer. This includes traffic between CloudFront and the viewer, CloudFront re-distributing from a custom origin, and CloudFront distributing from an S3 origin.
Customers should also ensure the data is encrypted at the origin to ensure it remains encrypted at rest while cached in CloudFront. If utilizing S3 as an origin, customers can make use of S3 server-side encryption features. If customers distribute from a custom origin, they need to ensure the data is encrypted at the origin.
Customers may use Elastic Load Balancing to terminate and process sessions containing PHI. Customers may choose either the Classic Load balancer or the Application Load Balancer. Because all network traffic containing PHI must be encrypted in transit end-to-end, customers have the flexibility to implement two different architectures:
customers should implement a level of logging that they determine to be consistent with HIPAA and HITECH requirements.
Using ECS with workloads that process PHI requires no additional configuration. ECS acts as an orchestration service that coordinates the launch of containers (images for which are stored in S3) on EC2, and it does not operate with or upon data within the workload being orchestrated. Consistent with HIPAA regulations and the AWS Business Associate Addendum, PHI should be encrypted in transit and at rest when accessed by containers launched with ECS. Various mechanisms for encrypting at rest are available with each AWS storage option (for example, S3, EBS, and KMS). Ensuring complete encryption of PHI sent between containers may also lead a customer to deploy an overlay network (such as VNS3, Weave Net or similar), in order to provide a redundant layer of encryption. Nevertheless, complete logging should also be enabled (e.g. through CloudTrail), and all container instance logs should be directed to CloudWatch, making it a perfect service for AWS HIPPA Compliance program.
Connections to Amazon DynamoDB containing PHI must use endpoints that accept encrypted transport (HTTPS).
Amazon DynamoDB offers DynamoDB encryption, which allows customers to encrypt databases using keys that customers manage through AWS KMS
Customers may use Amazon API Gateway to process and transmit PHI. While Amazon API Gateway automatically uses HTTPS endpoints for encryption in-flight, customers may also choose to encrypt payloads client-side.
Customers can use AWS CloudTrail and Amazon CloudWatch to enable logging that is consistent with their logging requirements. Customers should ensure that any PHI sent through API Gateway (such as in headers, URLs, and request/response) is only captured by HIPAA-eligible services that have been configured to be consistent with the Guidance.
All AWS customers benefit from the automatic protections of AWS Shield Standard, at no additional charge. AWS Shield Standard defends against most common, frequently occurring network and transport layer DDoS attacks that target your website or applications. For higher levels of protection against attacks targeting your web applications running on Elastic Load Balancing (ELB), Amazon CloudFront, and Amazon Route 53 resources, you can subscribe to AWS Shield Advanced.
AWS WAF is a web application firewall that helps protect customer web applications from common web exploits that could affect application availability, compromise security, or consume excessive resources.
Customers may place AWS WAF between their web applications hosted on AWS that operate with or exchange PHI, and their end-users. As with the transmission of any PHI while on AWS, data containing PHI must be encrypted while in transit. Refer to the guidance for Amazon EC2 to better understand the available encryption options.
Amazon Inspector is an automated security assessment service for customers seeking to improve their security and compliance of applications deployed on AWS. Amazon Inspector automatically assesses applications for vulnerabilities or deviations from best practices. After performing an assessment, Amazon Inspector produces a detailed list of security findings prioritized by level of severity.
To ensure that PHI remains encrypted while using AWS Lambda, connections to external resources should use an encrypted protocol such as HTTPS or SSL/TLS. For example, when S3 is accessed from a Lambda procedure, it should be addressed with https://bucket.s3-aws-region.amazonaws.com. If any PHI is placed at rest or idled within a running procedure, it should be encrypted client-side or server-side with keys obtained from AWS KMS or AWS CloudHSM. Follow the related guidance for AWS API Gateway when triggering AWS Lambda functions through the service. When using events from other AWS services to trigger AWS Lambda functions, the event data should not contain (in and of itself) PHI. For example, when a Lambda procedure is triggered from an S3 event, such as the arrival of an object on S3, the object name which is relayed to Lambda should not have any PHI, although the object itself can contain such data.
While Amazon Route 53 is an AWS HIPPA Compliance Eligible Service, no PHI should be stored in any resource names or tags within Amazon Route 53 as there is no support for encrypting such data. Instead, Amazon Route 53 can be used to provide access to customer domain resources that transmit or store PHI such as web servers running on Amazon EC2 or storage such as Amazon S3.
In order to store PHI, customers must ensure that they are running the latest Compliance-eligible ElastiCache for Redis engine version. Customers must also ensure that the cluster and nodes within the cluster are configured to encrypt data at rest, enable transport encryption and enable authentication of Redis commands.
Log data is encrypted while in transit and while it is at rest. As a result, it is not necessary to re-encrypt PHI emitted by any other service and delivered to CloudWatch Logs.
CloudTrail encrypts all traffic while in transit and at rest when an encrypted Trail is created. An encrypted trail should be created when the potential exists to log PHI. By default, an encrypted Trail store entries in Amazon S3 using Server-Side Encryption with Amazon S3 (SSE-S3) managed keys. If additional management over keys is desired, it can also be configured with AWS KMS managed keys (SSE-KMS). As CloudTrail is the final destination for AWS log entries, and thus, a critical component of any architecture that handles PHI, CloudTrail log file integrity validation should be enabled and the associated CloudTrail digest files should be periodically reviewed. Once enabled, a positive assertion that the log files have not been changed or altered can be established.
To satisfy the requirement that PHI is encrypted at rest, two paths are available on EFS. EFS supports encryption at rest when a new file system is created. During creation, the option for “Enable encryption of data at rest” should be selected. Selecting this option will ensure that all data placed on the EFS file system will be encrypted using AES-256 encryption and AWS KMS managed keys. Customers may alternatively choose to encrypt data before it is placed on EFS, but they are then responsible for managing the encryption process and key management.
AWS Certificate Manager is a service that lets customers easily provision, manage, and deploy public and private SSL/TLS certificates for use with AWS services and their internal connected resources. AWS Certificate Manager should not be used to store data containing PHI. AWS Certificate Manager is integrated with CloudTrail to log all API calls.
HIPAA’s Security Rule also requires in-depth auditing capabilities, data back-up procedures, and disaster recovery mechanisms. The services in AWS contain many features that help customers address these requirements.
In designing an information system that is consistent with HIPAA and HITECH requirements, customers should put auditing capabilities in place to allow security analysts to examine detailed activity logs or reports to see who had access, IP address entry, what data was accessed, etc. This data should be tracked, logged, and stored in a central location for extended periods of time, in case of an audit. Using Amazon EC2, customers can run activity log files and audits down to the packet layer on their virtual servers, just as they do on traditional hardware. They also can track any IP traffic that reaches their virtual server instance. A customer’s administrators can back up the log files into Amazon S3 for long-term reliable storage.
Under HIPAA, covered entities must have a contingency plan to protect data in case of an emergency and must create and maintain retrievable exact copies of electronic PHI. To implement a data back-up plan on AWS, Amazon EBS offers persistent storage for Amazon EC2 virtual server instances. These volumes can be exposed as standard block devices, and they offer off-instance storage that persists independently from the life of an instance. To align with HIPAA guidelines, customers can create point-in-time snapshots of Amazon EBS volumes that automatically are stored in Amazon S3 and are replicated across multiple Availability Zones, which are distinct locations engineered to be insulated from failures in other Availability Zones. These snapshots can be accessed at any time and can protect data for long-term durability. Amazon S3 also provides a highly available solution for data storage and automated back-ups. By simply loading a file or image into Amazon S3, multiple redundant copies are automatically created and stored in separate data centers. These files can be accessed at any time, from anywhere (based on permissions), and are stored until intentionally deleted.
Disaster recovery, the process of protecting an organization’s data and IT infrastructure in times of disaster, is typically one of the more expensive HIPAA requirements to comply with. This involves maintaining highly available systems, keeping both the data and system replicated off-site, and enabling continuous access to both. AWS inherently offers a variety of disaster recovery mechanisms.
To Achieve AWS HIPPA Compliance Disaster recovery With Amazon EC2, administrators can start server instances very quickly and can use an Elastic IP address (a static IP address for the cloud computing environment) for graceful failover from one machine to another. Amazon EC2 also offers Availability Zones. Administrators can launch Amazon EC2 instances in multiple Availability Zones to create geographically diverse, fault-tolerant systems that are highly resilient in the event of network failures, natural disasters, and most other probable sources of downtime. Using Amazon S3, a customer’s data is replicated and automatically stored in separate data centers to provide reliable data storage designed to provide 99.99% availability.
AWS PS has successfully implemented many HIPPA Infrastructures to satisfy the needs of our client’s applications for AWS HIPPA Compliance, in cooperation with Laraship who had achieved a fantastic job in making adjustments to applications to align with PHI standards.
We are a Professional AWS Managed company of experienced talented engineers. We are top skilled in AWS Architecture, DevOps, Monitoring and Security Solutions.