How ClearDATA Enforces Data Locality with AWS IAM Permission Boundaries
By Conor Colgan, Technical Product Manager at ClearDATA
For healthcare organizations bound by regulations that require privacy, security, and compliance protections for sensitive healthcare data, ClearDATA provides the peace of mind of automation-forward technology and industry-leading, HITRUST-certified, healthcare-exclusive expertise.
As the catalyst for change driving healthcare organizations to secure cloud environments where they can fully benefit from all the cloud as to offer, ClearDATA focuses on protecting sensitive data so companies can focus on innovating and improving healthcare outcomes.
In an increasingly global marketplace, healthcare organizations often find themselves forced to comply with more regulations and standards than just HIPAA. GDPR (General Data Protection Regulation) and specific data locality requirements that apply to the protection of sensitive personal data, such as personal identifiable information (PII), are becoming more common.
Under GDPR, companies can hold and process only the minimum amount of data needed to achieve their objectives, and only as long as is absolutely necessary. In addition to GDPR, many countries have now implemented their own additional privacy frameworks and regulations.
Fortunately, ClearDATA—an AWS Premier Consulting Partner with AWS Competencies in DevOps, Healthcare, and Life Sciences—works internationally and understands data locality requirements.
Furthermore, Amazon Web Services (AWS) offers a global selection of AWS Regions so customers can take advantage of services where they are needed. This allows companies to proactively restrict access to other AWS services where they either don’t need that specific service due to regional regulations, or where they prefer to store and transmit data.
Beyond region selection, how can healthcare organizations ensure they are adhering to regional data locality requirements? The ClearDATA Comply software uses a feature of AWS Identity and Access Management (IAM) called “permission boundary” that can be used to prevent access to certain AWS API calls, entire services, or even regions.
In this post, I will show you how Comply uses the IAM permission boundary feature to automate restricting access to specific regions through our compliance platform, and how you can use the permission boundary feature yourself to implement a similar solution.
ClearDATA Comply is a healthcare security and compliance software that provides powerful DevOps automation called Automated Safeguards. These remove the need for manual configuration and enforce the appropriate technical controls to handle sensitive data like PHI and PII, while still enabling users to access the AWS console directly.
Within ClearDATA Comply, Automated Safeguards for IAM provide admin users the ability to select only the appropriate regions in which they are operating and storing or transmitting data, thereby limiting access to regions where data should not be saved.
Implementing enforced permission boundaries frees development teams from having to remember one more nuance, such as only choose the us-west-2 region for this particular workload, and eliminate the risk of human error from hosting data in a region that may violate compliance. This compliance violation potentially puts the organization at risk for hosting data in an area that could expose sensitive data.
With ClearDATA Comply, development teams can access the cloud directly and focus on their application, while Comply enforces the appropriate compliant actions in the background. Given GDPR’s fines for non-compliance can range up to $20 million or four percent of an organization’s annual global revenue, that matters.
ClearDATA Comply includes a dashboard for customers to view their compliance status within their AWS accounts. Customers can also access, print, and share customizable reports that show compliance status of a single environment as well as trend data over time, which can be used as auditable proof.
Within this interface, users with the Administrator role can enable Automated Safeguards for IAM by selecting which regions can be used per AWS account.
Figure 1 – ClearDATA Comply view of compliance status.
The Admin user clicks the Edit Regions button and then selects the regions that are appropriate for their account. In this example, all of the data needs to be stored and processed in the United States, so the admin user would only select regions located within the U.S.
Figure 2 – Region selection screen.
Once the regions are updated and saved, the Automated Safeguards for IAM go to work by only allowing access to the specified regions. Using the AWS permission boundary for IAM Entities, ClearDATA Comply enforces which regions can and cannot be used based on the selection in the Dashboard.
ClearDATA Comply’s automation responds to the user’s region selection by recording it in an Amazon DynamoDB table. That record update triggers an AWS Lambda function that notifies the permission boundary requirements specific to that AWS account, which also lives in DynamoDB.
A second Lambda function is executed and updates the IAM policy in the customer’s AWS account with the new region selection, which results in a nearly immediate update to the regions which can or cannot be used by their users. The IAM policy that is constructed includes a condition that’s aligned with the regions selected above.
Figure 3 – Comply automation architecture for updating regions.
A sample of the IAM policy is listed below. The conditional statement used has a list of
aws:RequestedRegion that matches the regions selected by the user in the Comply portal. This condition ensures actions are allowed when a user selects one of the regions in the list but prevents actions when trying to use a region that is not listed.
This ensures any requests made to a region that is not included in the list are not allowed. ClearDATA Comply goes further, using Automated Safeguards to respond when a new IAM principal is created and automatically attach the above boundary policy to the new user or role.
All IAM principals get the boundary without creating a more complex IAM policy to control the available regions.
Now that you see how ClearDATA helps customers control access to regions, let’s walk through how you can implement this for yourself.
Permission boundaries can be used in any AWS account to provide a maximum set of permissions that users can utilize. It’s not the same as using Deny statements in IAM polices because it works on a higher level. You set the boundary, and your users remain inside of it no matter what.
It’s important to remember that a permission boundary does not grant any permissions in itself. It only sets the maximum permissions your users can execute. AWS gives an excellent explanation and example in the permissions boundaries for IAM Entities documentation.
Creating the boundary policy itself is not complex. As shown above, there is a statement block that allows all resources but only in certain regions. Next, you need a mechanism to enforce the boundary, so when new users or roles are created they will receive the same boundary.
There is a design that can be used with permission boundary policies that allows you to enforce it upon the creation of new roles or users. Please keep in mind you should have an Administrative role or user that does not have the boundary, to be sure you can still modify the boundary if necessary.
Within the boundary policy itself, you can use a condition statement that requires the use of your boundary when creating new principals. In the statement below, you can see how the boundary limits the creation unless you attach a specific policy,
boundary-policy in this example, as a permission boundary.
If your account has the permission boundary attached and you try to create a user or a role and do not attach the policy as a permission boundary, such as
aws iam create-role --role-name MyRole, you will receive an error that you do not have permission.
To successfully create the role, attach the permission boundary using the command:
aws iam create-role --role-name MyRole --permissions-boundary arn:aws:iam::*:policy/boundary-policy
With the boundary in this state, users can still modify the boundary policy, rendering it ineffective. To close that gap, we combine both the permission boundary condition with the AWS region restriction and add a couple of simple Deny statements to prevent users from deleting or modifying the policy.
Once those pieces are assembled, you have a fully functioning region restriction IAM permission boundary.
Once the policy is created, you can assign it to all of the required users and roles, and they will be limited to the regions chosen.
The end result of using a permission boundary for regional restriction is your developers can do their job without concern about where your data or infrastructure is running within AWS. One advantage to using ClearDATA Comply is that our Compliance Dashboard provides visibility into the region selection in a more user-friendly manner, and our automation goes a step beyond the permission boundary condition shown in this post.
ClearDATA Comply uses Automated Safeguards for IAM to ensure permission boundaries are always enforced, even if the conditions are not properly set, and compliance status is viewable and reportable to all stakeholders.
In addition to relieving tremendous manual resources, the automation also reduces the likelihood of human error and provides peace of mind in an increasingly complex global marketplace.
To learn more about ClearDATA Comply for AWS and how it can help protect your organization’s sensitive data anywhere in the world, contact ClearDATA for a demo.
The content and opinions in this blog are those of the third party author and AWS is not responsible for the content or accuracy of this post.
ClearDATA – AWS Partner Spotlight
ClearDATA is an AWS Premier Consulting Partner and leader in HIPAA compliant, AWS managed services for healthcare providers, payers, and tech companies that support them.
*Already worked with ClearDATA? Rate the Partner
*To review an AWS Partner, you must be a customer that has worked with them directly on a project.