In sophisticated enterprise AWS deployments, Amazon’s Identity Access Management (IAM) service controls access, enforces protections, and provides granular control over hundreds or even thousands of account users. IAM policies are the bedrock of security in any AWS environment.

In HIPAA-compliant cloud environments, the use of IAM security is essential. HIPAA required central identity management and necessitates the close control of access to data. IAM policies are key in managing control to resources and data they they hold.

Here are seven best practices for implementing IAM policies in a HIPAA-compliant environment:

1. Create and use IAM roles instead of the root account

When a new AWS account is set up, the IT team or Managed Service Provider will create an Admin role, institute MFA on the root account, and lock away the account token in a high security safe. Admin roles are usually restricted to no less than two and no more than three accounts.

Choosing not to use the root account improves security in a number of ways. First, every user is restricted under IAM policies, so that if account keys are inadvertently shared or stolen, damage is limited to some degree and can be disabled quickly. Secondly, IAM roles ensure non-repudiation; no team member can claim to have or have not done something to affect the environment. IAM users “sign” each action, so every individual is personally accountable for the work that they do.

2. Grant least privileges

In a large organization, users often require access to only a small portion of an AWS environment. However, many businesses overlook the process of investigating the minimum functions required by staff members and 3rd party consultants, which means that excessive IAM privileges are granted out of lack of knowledge or laziness.

IAM administrators with this mindset introduce a significant degree of risk into an organization’s security policy. Greater entitlement than necessary opens the door for human error and introduces the need for more complex audits; IAM policies greatly simplify an auditor’s investigation into who has access to which resources.

Best practice is to grant least privilege — and then grant more privileges on a granular level if needed. For example, an auditor or auditing department might need to view log files in a single S3 bucket. It might be tempting to grant full access to that bucket, but as an auditing team they just need read-only access. So that specific action should be granted and nothing more.

It is useful to note that S3 is a special service in that one can restrict access both through IAM and through S3 Bucket Policies; one can further lock down access to an S3 bucket by stipulating the actions the user can take in that bucket. For example, a user can be granted IAM access to the bucket, but be denied if they are accessing it from an IP address outside of an IP range set out in a bucket policy.

In a complex healthcare enterprise, the ongoing investigation that entitlement definition requires often necessitates that one or several IT staff with the task of constantly updating, removing, and re-auditing IAM policies. What are the requirements of each application? What S3 buckets need to be accessed by which teams? Who got fired and who hired? These new permissions and the reason for them must be well documented; this is one form of administrative work that is well worth the red tape.

Work done proactively here will save hours of forensic time if something goes wrong and if auditors come in, there is much less that needs to be gathered. The organization has to prove that the function can only be performed by certain people in a central location, so auditing is fairly simple.

3. MFA everywhere + federated access

Multi-Factor Authentication provides an important level of security in any environment. Even if a password is shared or gets inadvertently released, malicious users still cannot access the account. This is particularly important in HIPAA-compliant environments.

However, in all but the smallest environment, requiring MFA access to every resource would be burdensome. Instead it is best to configure a few entry points such as Bastion hosts or a jump box, where access is limited and sessions can be logged. Accounts are often established in Microsoft’s Active Directory (AD) and AWS is configured to respect identity tokens from the AD server. Then Active Directory Federation Services (ADFS) issues an identity token. When logging into AD, users get prompted for an MFA token. Once authenticated to central authentication, it is respected by AWS. MFA access is required for these entry points, and this ID token can be provided by a hardware FOB or by a software token installed on a user’s phone, whether it be DUO or a free product like Google Authenticator.

Federation enables healthcare organizations to centrally manage its users, a requirement under HIPAA’s Security Rule. It is a single place to go to revoke or grant entitlements as necessary.

4. Rotate credentials regularly

AWS recommends as a best practice that all credentials, API access keys, and passwords are rotated regularly. Any credential left active for too long increases the risk of compromise.

There are a few ways to do this. AWS outlines a manual process using the AWS CLI to create a second set of credentials, programmatically create and distribute the access key, and disable the old key. One could also do this by creating two keys and having them overlap (the first is active from the 1st to the 16th, the other from the 15th to the 30th of the month), then programmatically disabling old keys.

Creating system roles will simplify the process, as the SDKs for Python, Boto, and CLI will automatically return keys from AWS metadata. However Some key rotation needs to be maintained.

5. Maintain audit logs with CloudTrail and Config

CloudTrail logs every action taken by any IAM user or resource in your AWS environment. AWS Config is also useful in that it tracks and reports on changes to your AWS environment itself. Ensuring that these logs are kept is high on every auditor’s checklist.

Of course, it is not enough merely to enable logs; engineers must also protect the logs themselves. One key role of IAM is to lock down those logs. In HIPAA-compliant environments, logs are usually hosted in an S3 bucket that only Admins have write access to. Logs are further protected by requiring MFA  – even for Admin access. It is also wise to set alarms in CloudWatch for when CloudTrail is disabled and enable SNS notifications of CloudTrail log delivery. Logicworks uses Cloudcheckr to set up sophisticated alerts with CloudTrail and Config. Another option is to set up a separate AWS account solely for logs.

6. Regularly re-certify employees

IAM can provide scheduled and ad-hoc compliance reports, including automated violation notifications, audit assessments, role changes, and hierarchies. Along with ongoing IAM policy changes, team leaders should perform monthly or quarterly reviews of IAM roles within each environment. Managers should re-approve their direct reports’ access to resources and applications. With IAM, this is a fairly straightforward process, where IAM can create a report that outlines each employee’s access rights. As long as these roles are meaningful and specific, and business leaders are given appropriate business context, they can accurately audit and restrict or expand these roles.

7. Set up and lock down automation tools

Tools like CloudFormation can automate the implementation and configuration of certain security policies as well as infrastructure. This can act like configuration management for IAM policies much like Puppet or Chef provides configuration management for Operating Systems.

Since CloudFormation is made to create and destroy infrastructure, it is that much more important that IAM policies are managed effectively. CloudFormation only runs under the context of the user running it, or else this powerful tool could become a powerful weapon. CloudFormation will fail if a user tries to automate a function beyond its IAM role.

IAM puts you in a position of always having control over your environment. This is essential not only in HIPAA-compliant environments, but in any environment that hosts sensitive or proprietary data. Through the correct implementation of IAM policies, AWS is fully capable of hosting sensitive data and may even provide a more granular level of user management security than a traditional hosting environment.

To learn more about IAM and security on AWS, contact Logicworks.