As more healthcare organizations and software applications move to the cloud, each must discover the right use of resources, networking features, and security protections to protect ePHI and address HIPAA compliant hosting requirements.

However, the HIPAA Security Rule is not specific about the exact set of best practices and tools to protect data at rest; implementation specifics are left to the organizations that implement the solution. This is where AWS helps significantly by providing services to meet these requirements and standing behind their implementation legally with a Business Associates Agreement (BAA).

AWS lays the foundation of a secure environment with its Key Management System (KMS), which facilitates the creation and control of encryption keys usable by many AWS resources such as EBS, S3, Redshift, and Glacier. KMS leverages HSMs to protect the keys, and implements AES-GCM-256 with ECDSA signatures to meet both FIPS and NIST standards. In short, this is a very secure encryption method.

All applications in EC2 will need disks, whether for simple logs or transient data, and EBS is the most common use for AWS KMS encryption. Amazon makes it as simple as a GUI click, an API flag, or a CloudFormation attribute. By specifying an EBS volume as encrypted, all data on the disk gets encrypted at a block level by the hypervisor. This is completely transparent to the operating system of the virtual machine running.

Encrypting EBS volumes is both simple and free, and there is no greater performance hit than with any other encryption method. As an extra benefit, all disk snapshots of an encrypted EBS volume are also encrypted in the same manner, ensuring that backups performed are also compliant.

When encryption is enabled for an EBS volume, the user is given the choice of using the account master key or of selecting another previously uploaded key for specific purpose at creation time. While this provides further options for risk segmentation, most will find the master key default option sufficient.

It is important to note that AWS does not provide functionality to build EC2 instances with an encrypted root volume. Therefore, no sensitive data may be placed on the root volume and controls must be put in place to protect against security threats. While steps can be taken to encrypt the root volume, most will find that the threat of operational risk is far greater with root volume encryption. In the end, it is a fairly simple job to keep data off the root partition. A common best practice is to mount all files systems used by applications on encrypted EBS volumes and to redirect various /var directories there, either through symbolic links or simple mount points directly to the encrypted EBS volumes.

Data transfer repositories are another common resource where data sits at rest. In AWS, these are S3 buckets. AWS provides strong data protection controls here as well.

“Server-side encryption is about protecting data at rest. Server-side encryption with Amazon S3-managed encryption keys (SSE-S3) employs strong multi-factor encryption. Amazon S3 encrypts each object with a unique key. As an additional safeguard, it encrypts the key itself with a master key that it regularly rotates. Amazon S3 server-side encryption uses one of the strongest block ciphers available, 256-bit Advanced Encryption Standard (AES-256), to encrypt your data.” 

– AWS Documentation

With SSE, the user can set the attribute on upload/post and AWS does the rest, or the user can provide a key to use in the AES-256 encryption before data is stored in S3. Just note that with Customer-Provided Encryption Keys (SSE-C), Amazon does not store the encryption key provided. Instead it stores only a randomly salted HMAC value to validate future requests. It is the user’s responsibility to track which keys are used for which objects. If lost, no recovery will be possible. Most users will choose the default and, as with EBS, allow AWS to handle all the complexity of key management.

Just as EBS snapshots preserve encryption, so does Glacier preserve encryption from S3. Any object stored with SSE enabled and moved to Glacier will have encryption preserved so that even long-term archived data remains protected.

While an environment set up in this manner is HIPAA compliant, it is even better to ensure that these best practices are always utilized by leveraging IAM policies. For example, one can disallow the creation of any EBS volume unless it is encrypted. Similarly, S3 buckets that house anything remotely related to privacy data should have a bucket access policy denying any upload that did not request SSE on the object. These simple measures will make discussions with auditors simple; when one can demonstrate that it is not possible to deploy data repositories that are unencrypted, the proof discussion becomes much easier.

Not everything needs to be encrypted and not every Amazon resource needs to be covered by the BAA. If the engineers and users of the application are knowledgeable about how and when sensitive information should be accessed, where it flows and where it is at rest, then only those services need to be encrypted and covered by the BAA. That said, a far simpler approach is to consider everything private and to use Amazon services covered by the BAA and encrypt data everywhere.

Logicworks has been HIPAA, PCI, NIST 800-53, and SAS 70 certified for almost a decade. Learn more about Logicworks’ approach to HIPAA compliance or contact us to see how we can help your organization architect a secure, audit-ready infrastructure.