Leverage Enterprise Identity Management when Adopting Cloud

Access control is key to building a secure cloud offering. In the rapidly developing world of cloud computing, user and group creation can quickly get out of hand and become unmanageable. Locking down standards and patterns early in your cloud journey will help you avoid this pitfall down the road.

Over the years at Vibrato, we’ve worked with a plethora of clients ranging from aspiring startups to multi-continental enterprises, which has positioned us really well to design patterns around identity and access management on cloud environments in line with all stages of business maturity. While complexity levels will differ, the most important aspects of approaches to identity management are definability, scalability and consistency. This post is targeted towards AWS with ADFS as a SAML provider specifically, but these principles apply across all cloud providers.

While many companies will want to just punch their credit card details into AWS and hit “Launch Instance” in the EC2 console, it is always advisable to slow down, go to the whiteboard, and start mapping out some concepts.

For a smaller environment, creating separation of responsibilities might be as simple as defining a multi-account strategy for your AWS accounts, which is becoming easier than ever with the release ofAWS Organizations, but how do you approach identity management if you are an established enterprise with many existing applications which will have many different teams working on them, and require your on-premises environments to integrate with your Cloud environment (meaning Direct Connects and VPNs everywhere)? Federated access using a SAML provider is definitely one of the better approaches.

While many companies will want to just punch their credit card details into AWS and hit “Launch Instance” in the EC2 console, it is always advisable to slow down, go to the whiteboard, and start mapping out some concepts.

For a smaller environment, creating separation of responsibilities might be as simple as defining a multi-account strategy for your AWS accounts, which is becoming easier than ever with the release of AWS Organizations, but how do you approach identity management if you are an established enterprise with many existing applications which will have many different teams working on them, and require your on-premises environments to integrate with your cloud environment (meaning Direct Connects and VPNs everywhere)? Federated access using a SAML provider is definitely one of the better approaches.

Amazon has some great posts around getting started with SAML based federated access, but we’re more so going to focus on some of the practices which should apply across them.

AWS IAM is very powerful, and facilitates refinement of access to resources while at the same time making management of the environment more complex. At Vibrato, we leverage the granularity of IAM, and use it to take a layered and iterative approach to access on AWS. The layers can be defined as your Active Directory groups, IAM Roles which map to Active Directory groups, and IAM Roles for CloudFormation to assume upon deploy.

Active Directory groups should map directly to roles within your AWS accounts, which is a simple enough approach to take, and a lot of the documentation which Amazon provides will tell you how to do that, but what they don’t tell you are best practices around designing your group structure and how this will define access for users in the environment.

While there is never a perfect one-size-fits-all approach, ideally you will want to standardise your IAM Roles and abstract away from granular IAM permissions by using Active Directory groups. While there is some more up-front design and implementation, an ideal approach is to define your administrative boundaries based on environment and project. You could further define your boundaries based on region and function, but be warned that this will come with much more administrative overhead, and requires careful tooling considerations around it.

A role and group is made for each combination of your administrative boundaries, enabling your identity administrators to provide consistent and controlled access to your environments in a clearly defined manner. If you’ve elected to break down your administrative boundaries to the function based level, it’s a good practice to (generally) base them off of Amazon’s definitions in their console (see the below image), as these will often define your functional areas of administration; there will occasionally be some overlap between them, of course.

This style of implementation means that users cannot manage anything outside of the bounds which have been defined for the roles which they are allowed to assume. Limited access is given to users outside of View-Only access to AWS and usage of resources which belong to their project. This is enforced by naming standards, which are enforced by the automated tooling in an environment. Users administering resources within your AWS environment will not be able to create new resources directly, but will be able to utilise resources which are within their administrative boundaries. Resources should only be deployed by your environment’s automated tooling which should leverage CloudFormation or Terraform to maintain your code in a version control system such as Git. This means that your environments will be tightly controlled, clearly defined in code, and will be subject to good development practices such as pull requests and staged deployments.

When you have all of your users being managed within Active Directory, this now brings a few benefits:

Users are being managed consistently from one central location

Granular IAM policies are abstracted away and standardised

AWS session tokens cannot be generated without access to ADFS; this is commonly limited to your on-premises environment

IAM user access keys are no longer required in your environment and can be replaced by short-lived secure session tokens provided by AWS STS via ADFS. IAM user access can now be treated as privileged user access and proactively monitored and alerted on.

To sum it all up, while with some technologies it is feasible enough to ask for forgiveness rather than permission, this mantra definitely doesn’t apply to AWS, and you want to ensure that the right permission and user management strategy is in place from the start because if that’s not there, it can be a nightmare to clean up, standardise and manage the environment.

I’ve only scratched the surface in regards to securing your environment while still creating a robust and scalable platform, if you have any questions around anything cloud or automation (not limited to AWS), feel free to reach out and we’ll see how we can help you overcome any limitations which you might be facing.