How to Achieve HIPAA Compliance in AWS

Security BG

When trying to achieve HIPAA compliance in any environment, there are some basics that an organization should implement to comply with regulations. This article will offer some suggestions and best practices on how to achieve and maintain HIPAA compliance in AWS (Amazon Web Services.)

A few key points on HIPAA compliance in AWS:

  • Encrypt whenever possible
  • Log everything
  • Audit everything
  • Understand your data
  • Enforce general security policies

Encrypt Whenever Possible:

AWS services such as Elastic Block Storage (EBS), Simple Storage Service (S3), Relational Database Service (RDS), and many others allow you to encrypt the data at-rest. It is important to encrypt whenever possible, whether you expect a system to have Protected Health Information (PHI) or not. At times, developers will create duplicate databases or data sets to test with and these could possibly contain PHI. For the low cost of Key Management System (KMS), it is worth the peace of mind to encrypt anything and everything (learn more here).

Elastic Compute Cloud (EC2) uses EBS on the back end, attach a secondary volume to the EC2 instance and mark the new volume as “encrypted,” once the volume is created, attach it to your EC2 instance. Draft and enforce a policy that requires developers to only use the secondary drive as it is encrypted.

S3 allows you to encrypt the data in-transit and at-rest. To do so, modify the S3 bucket policy with the appropriate policy (an example can be found here). By doing so, any data that is being pushed to S3 will expected to be encrypted. If the data being pushed is coming in unencrypted, S3 will deny the transfer. You can see how to force encryption while pushing data to S3 here.

Key Management System (KMS) is the system that is being utilized to encrypt the data at-rest for EBS, S3 and many other services within AWS. This service charges a very minimal fee per get request, you can see the pricing page here.

Log Everything:

When a user makes a change on a system, you want it to be recorded within the logs. If logging is not enabled many changes can go by unnoticed and untracked. When an audit for HIPAA compliancy takes place, they will request samples of the logging that your organization has in place. If the logs don’t exist, it can be a monumentous mistake that could cost your organization its compliancy. To achieve logging within the AWS infrastructure, take a look at AWS Config here. AWS also offers a service to store your logs in a centralized place through Cloudwatch, check out Cloudwatch Logs for this feature here.

Logs should be treated like an ancient museum artifact, no one should be able to modify or touch it and only certain people should be able to view it. You can achieve this via IAM policies if storing logs within Cloudwatch Logs.

Audit Everything:

Auditing is one of the most important pieces of HIPAA compliance in AWS. If a user makes a modification to your system and there is no auditing in place, the changes can go unnoticed but recorded. A user could open up sensitive ports to the internet allowing for external attacks, and the security department would never know. Having logging in place is a good start, but auditing those logs and alerting on sensitive actions is just as important as the logging itself. If the logs are there, but no audits are being done, then what use are the logs?

For changes to your AWS environment, you can utilize AWS Config with Lambda to notify you on events that your security department would be interested in. AWS Config has a pre-built rule that will notify an SNS topic (if configured) of any changes made to any security group.

Understand Your Data:

Having your log data is useful. Understanding your log data is just as important if not more important. If your logs are there, but no one knows what’s in the logs or what log records what actions, how will auditing actually take place? How will your security department know what logs to monitor for specific actions? Log everything, but carefully. Carefully identify what you want and need to log. For example, you might not need to know every time a file is written to /tmp/ by an application, but you would definitely want to know when someone installs a new package.

Enforce General Policies:

In the number of audits done, we have noticed that many customers were not utilizing password policies or enforcing IAM access key rotation. AWS IAM has a built-in feature for requiring all user passwords to be a certain length of characters, require a number, special character, and upper-case character, when created. Configure the AWS IAM password policies to keep your passwords in compliance with HIPAA regulations.

It is also good practice to enforce a policy to rotate AWS IAM access keys every 365 days. There is no automated AWS way to do this, but writing your own Lambda script to scan your IAM access keys nightly and alert you on expired ones is a good start.

Related AWS posts:

Learn more about our security and HIPAA compliance in AWS services, read a few of our related case studies for HealthRise Solutions and Health Advocates.

Hidden layer

Share on linkedin
Share on twitter
Share on facebook
Share on email

Onica Insights

Stay up to date with the latest perspectives, tips, and news directly to your inbox.

Explore More Cloud Insights from Onica

Blogs

The latest perspectives on navigating an ever-changing cloud landscape

Case Studies

Explore how our customers are driving cloud innovation in their industries

Videos

Watch an on-demand library of cloud tutorials, tips and tricks

Publications

Learn how to succeed in the cloud with deep-dives into pressing cloud topics

Subscribe to Onica Insights