How to hit the ever-moving target of Least Privilege access

How many users and roles have way too much access, out of  convenience? When is the last time you checked to make sure access  levels were consistent with the business need? And when is the last time  you reduced someone’s access?

If you can’t remember, you’re not alone and you should read on,  because we have steps you can take to crank down access so that you are  less exposed.

It’s a well-known security principle to make sure people and  computers have the least access necessary to perform their legitimate  work. That means, you would not give a business analyst “administrator  access” in order for them just to explore data and make reports.

You also wouldn’t give a developer “write” access to sensitive  production data. You want developers creating code and the  infrastructure to support it – but not the ability to modify your  customers’ data.

This all makes perfect sense in theory. But things get hard in real  life. Think about that developer. Should she be able to create  infrastructure in a development environment? Sure. Should she be able to  spin up huge EC2 instances, or just small ones for testing? Should she  be able to modify bucket policies for your code repositories, or just  put data there?

The more questions you ask about scenarios, the deeper it gets. And  when you realize you can write an infinite number of conditions (you’re  just limited by your willingness to craft custom JSON statements), you  start getting a little overwhelmed

In fact, that is why many AWS customers think about detailed,  fine-tuned least privilege the same way they think about flossing after  every meal… the right thing to but practically difficult and a bit  fussy.

We at CloudSheriff are aware of this tension – least privilege is  essential but time-consuming to achieve – and we want to share with you  some best practices that should clarify your thinking about it.

Best practices for implementing and keeping least privilege

• Use aws managed roles by job description
• Use Groups  instead of assigning roles directly to users. Because users come and go.   https://aws.amazon.com/blogs/security/adhere-to-iam-best-practices-in-2016/
• Don’t use inline policies
• Do  an audit to find unused roles. Retire roles that are > 90 days  unused. You will need to use something like CloudCustodian (which comes  out of the box with CloudSheriff)
• Use service control policies  to simplify access rules down through all your accounts. Need to keep  all your accounts in the “Organizations” structure for this.
• Revisit privilege when new projects spring up.
• Know when people’s jobs change.
• Use roles exclusively with contractors. It is a mistake to create a dedicated User for them.
• Monitor access with Cloudtrail.
• Get  to know the IAM console to learn what is up with last used roles.  https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html
• Map  IAM policies to corporate policy. You need someone cross-functional to  do this. Often there is a disconnect between a written corporate policy  and whatever is actually implemented in AWS. So, you need to assign  someone to research the corporate policies and transform them into JSON.  This takes focus, double-checking, and skill.
• Use date/time  conditions to limit access to resources such that IAM users are only  able to access a resource during weekdays for the duration of their  workday/shift.
• Date conditions to automatically prohibit activity after 3 months or something, for a contractor.
• Set  up conditions that whitelists IP addresses that are allowed to access  AWS resources to ensure only trusted IP addresses are able to gain  access to an AWS resource. BONUS: Get IP addresses especially for SSH  into an EC2 instance, since once you’re in, you can GET the instance  metadata which will reveal the access tokens.
• Find and retire  users, groups, or roles with no policies attached. This will prevent  confusion down the road if that entity attempts something and is  completely blocked. This also is easier with something like  Cloudcustodian.
• Look at Access Levels, to simplify how you think  about access. Access levels are things like “read”, “list”, “write”  permissions which at a high level dictate whether you can change  infrastructure or just look at it. Sometimes, especially with sensitive  data, “list” or “read” is a very sensitive operation which requires  close study.
• For contract employees/partners, set up date  conditions that block access to AWS resources after the termination date  of the contract.
  https://www.skyhighnetworks.com/cloud-security-blog/13-aws-iam-best-practices-for-security-and-compliance/
• From  AWS: Start with a minimum set of permissions and grant additional  permissions as necessary. Doing so is more secure than starting with  permissions that are too lenient and then trying to tighten them later.  https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege  (however, this requires a very surgical focus with a deep understanding  of AWS, to even know what actions will be taken).

You know that Least Privilege access is the right principle to  pursue. In reality, it’s just hard to take the time to not only think  through what each user should be doing, but also to write up an accurate  policy that neatly captures the permissions limits. Add to it the fact  that in today’s dynamic environment, job responsibilities change  constantly, and you are signing up for a lot of policy management.

CloudSheriff’s solution is to take care of all those best practices  for you. When you hire us, not only do you get an experience team on  your side to confidently recommend actions to achieve least privilege,  but we actually code the policies and monitor them to make sure they are  not too tight nor too bloated. Contact us now for a demo.