In a recent webinar, we discussed architectural principles to keep your AWS environments secure and compliant as well as the role of the Health Information Trust Alliance (HITRUST) certification. HITRUST typically focuses on customers in the healthcare space with the primary concern focused on maintaining compliance with HIPAA/HITECH security standards for the storage of Protected Health Information (PHI).

I work with the Connectria cloud managed services teams and directly with customers coming over in AWS, who are looking at achieving their HIPAA or HITRUST certifications. Connectria achieved HITRUST certification early last year and we previously discussed its value in comparison to HIPAA/HITECH. While the latter serves as the leading compliance measure, HITRUST is a more comprehensive option for both achieving and maintaining compliance.

In my experience, I have found a few key architectural considerations for designing compliant AWS environments. The first of which is resource segregation which limits the scope of PHI and prevents leaks while developing. Before I go into further detail, let’s take a closer look at HITRUST.

HITRUST at a High Level

The HITRUST alliance was formed in 2007 with the primary mission of providing a set of prescriptive controls to meet the HIPAA security privacy rule. HITRUST is one of the more difficult certifications to obtain. It can be time-consuming, expensive, and complicated but its rigorous process is why it has become a high bar of trust in the security, risk, and compliance industry.

Working with a HITRUST certified MSP like Connectria will make the process easier for you because we can ensure AWS environments are designed for security and compliance upfront. We make sure you have the SIEM, logging, automation, and security tooling in place in order to achieve and maintain your compliance goals.

Compliance Concerns

An AWS account provides inherent access and security boundaries for your AWS resources which helps you achieve resource independence and isolation. While many users begin an AWS journey with a single account, AWS recommends setting up multiple accounts as your workloads grow in both size and complexity.

Other best practices that I like to leverage include architectural considerations when designing compliant AWS environments. Customers working with Connectria towards their compliance goals have a few main concerns. These typically revolve around resource segregation, resources that are not appropriately locked down or restricted, and interest in different tools within AWS for logging and configuration.

Separating Your Resources

One of the main considerations around resource segregation is to make sure that you’re separating your resources between nonproduction and production environments. Part of HIPAA and HITRUST certifications are that you cannot have overlapping resources between production and non-production. There are several different ways to achieve that.

This can be done through network segregation within a single account or via different accounts for production and non-production environments. The example above shows how resource segregation can be done by using the VPC peers and speaking back and forth between a management VPC to ensure that your security and logging are centralized but your actual communication between your resources is separated out.

Separating resources can also be done at the account level. This ensures that none of your resources are overlapped including down to the IAM level. This is ultimately designed to make your life easier as you’re talking to an auditor. If there is no overlap between IAM resources or between security groups because your resources for production and non-production are separated in different accounts, you will have fewer resources in scope for potential questions.

PHI Data

It’s important to ensure that you don’t have any risk of leaking your PHI data from your production environment to your development environment. As soon as that PHI information goes into the development environment, those resources, security groups, VPCs, all of that now fall within scope for what an auditor is going to look at.

“This is a good example. At AWS, we see customers very frequently using a multi-account architecture to reduce their scope. This makes an auditor ask you fewer questions, makes your audit go more smoothly, and have fewer findings,” said Jonathon Harbin, AWS Sr. Security Assurance Consultant.

Compliance and the Cloud

This article is the first in a 3-part series. Click here to read the next article.

Contact Connectria today to learn more about how we can help your organization with HITRUST and compliance in AWS. Connectria is a leading AWS Advanced Consulting Partner & audited managed service provider. Our comprehensive suite of AWS services has helped hundreds of organizations successfully move to the cloud and free up IT resources to focus on more strategic initiatives.