AWS Identity Access Management (IAM) is the tool within Amazon Web Services (AWS) that securely controls accessto resources within, using a friendly interface and, once we spend some time learning the lingo and methodology, a logical system. IAM is the gatekeeper that manages access controls and authentication for users and also the “how” as it manages authorization tools (like key management), protocols and schemas of permissions that manage access to resources within AWS accounts and services.
Managing who has access to what and to what degree is important for many reasons, least of which is certainly not minimizing risk. From a Cyber Resilience perspective, delineating access and control across multiple accounts can be a good strategy to manage risk. When an account is compromised, it won’t have keys to the entire castle.
Rarely should there be only one account to manage everything, or every client, which means IAM is key to helping us manage multiple accounts.
If you are using one account to manage everything, you may consider how access to “everything” might be more segregated in order to better abstract it, i.e. create better layers of security to protect it.
In the same manner we delineate permissions on web, file and database servers (or should be), there should be different type of accounts: ones that can read only, ones that can write to only specific resources, etc.
No single account should ever have access to everything because when it is compromised it will have access to everything. The rule of least privilege should always be applied.
Configuration by Account
By default, IAM operates in isolation of a single AWS account, typically the first or primary account used to set up all other AWS tools and services. This means there is no requirement or need to use the original account for everything. Authorization to perform tasks is provided initially only within the boundaries of the account where it has been configured. In other words, accounts can do whatever we set them up to do. We can do this on an account by account basis, to start.
This is the most straightforward configuration. It effectively limits the scope of control to whatever resources are available to an account. While this is quick and easy for the average bear to set up initially, this method doesn’t scale well beyond two or three accounts because it gets time consuming. As one might imagine, as needs change the addition of deeper configuration can add complexity to managing accounts individually, without using templates, especially where there are more than two or three.
It’s also worth mentioning that as this complexity and overhead increases, it does so in direct proportion to the likelihoodthat we will make human mistakes in manually configuring these accounts, opening ourselves up to more than just errors. Such errors mean more vulnerability and risk of all kinds, including compliance and governance issues.
SAML-based Authentication, Federation + Single-Sign On
Another method for managing accounts is using an Identity Provider (IdP). IdPs offer two approaches to an authentication strategy (or federation) that makes managing multiple accounts simpler. By making changes to IAM templates and authenticating those users using one of these strategies, the overall management is both friendlier from a configuration perspective and far more consistent with less effort.
The first of these two approaches includes SAML-based authentication against locally hosted and/or remote Directory Services. The second is Web Identity Federation, using a third party provider, also called Cloud Access Security Broker(CASB) to provide and/or integrate with existing Directory Services.
Each approach allows use of identity management directories hosted externally. This could mean an Active Directoryschema or other LDAP directory service. It makes things friendlier for users through a single-sign-on (SSO) approach to access management – they only have to manage/remember one login and password to access an organization’s resources. Federation of this kind effectively leverages an existing single directory of usernames and vastly diminishes the overhead otherwise involved in managing multiple accounts.
Upfront and thoughtful configuration is still required in order to design, build, establish and document the build (or trust) between an AWS IdP and the directory source, or CASB as the case may be, but it doing so is worthwhile because it simplifies ongoing management of accounts going forward. It may not reduce the complexity in the overall administration of IAM roles and policies, but the creation of additional accounts won’t require the same amount of time and attention while eliminating opportunities for any fat-fingered errors.
IAM roles are collections of permissions granting access to resources. They define the types and scopes of actions available to users within those resources. These are granted to roles rather than individual users or groups.
Cross-Account IAM roles have two policies assigned to them: one is permissions and the other is trust. The permissions policy defines resources and accessible actions. The trust policy defines users that can take actions within those permissions. Both trusting and trusted assets can exist in a single account, or two accounts under a single organization’s control, or two separate accounts controlled by separate organizations.
Obviously it is easy for things to get complex but some good practices can help make managing these faster and friendlier (especially where documentation, compliance and governance are concerned).
Keep it Simple
In spite of any recommendations, many organizations are still using a single AWS account for everything and, even so, some elements of managing them will still remain challenging. Setting up and continuing to manually manage accounts, while time consuming and confusing if you don’t do it every day, is prone to mistakes like misconfiguration. Choosing to set up cross-account IAM roles or IdP federation, while they bring their own complexities, can be worth it over the long-term. Please consider that, in addition to minimizing your organization’s risk, these methods can add to your productivity, too.
Thanks for reading. This post has also been featured by the good folks over on Peerlyst.
The official AWS IAM documentation lives here: http://docs.aws.amazon.com/IAM/latest/ UserGuide/introduction.html
This is good stuff, too: http://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html
If your eyes are not crossed and your curiosity is piqued, you can learn more detail here: http://docs.aws. amazon.com/IAM/latest/UserGuide/id_roles.html