To recap, in the first article I covered what steps you needed to take to increase security on your root account. As a follow on to that, I want to move into a more complex topic – IAM policies and users. I’m not looking to try and teach you how to create IAM policies in this post, AWS has plenty of guides on achieving that. The aim for this post is to make you aware of them and have a high level understanding of them.
IAM stands for Identity and Access Management, its AWSs service for creating and managing users, groups and permissions within the context of an AWS account. As a general rule the objects you create, are specific to that account. The exception to the objects being specific to accounts, is IAM delegation and federation capabilities. IAM delegation and federation exists to provide account access into any external or additional AWS accounts you have. The accounts might exist either in another AWS account, or they might exist in an external directory that is SAML 2.0 compliant, such as Active Directory (AD) with Active Directory Federation Services (ADFS). As an aside, there’s an AWS blog post about configuring AD with ADFS for AWS integration, which you can read here.
As a general rule I try to avoid using delegation and/or federation, as it creates unnecessary complexity and can potentially weaken your security posture if not properly configured. In the case of delegation, there is too much scope for an accidental action as a result of being confused about which account is currently active. This isn’t to say that it is without merit, it’s just not suitable for smaller environments.
With AWS, you need to use IAM users in order to have an account for each individual. You can then extend these accounts by implementing IAM policies, which enable you to establish granular permissions with relative simplicity. AWS offer a raft of pre-built policies which allow you to provide that granularity. If they don’t work for you, which they probably won’t, you can create your own policies with the specific permission set you need.
As discussed in the previous article, these are the topics I’m going to cover:
- Root Account Management
- IAM Policies and Users (this page)
- Establishing an account hierarchy
- Setting up CloudTrail and Billing Alerts
- SumoLogic (optional)
IAM Policies and Users
Starting with a quick overview, IAM policies are JSON documents that list of statements to define the permissions. Each statement will define permissions in the form of the actions to be performed, the resources to which these apply and finally if the effect of the statement is to allow or deny access. You can read more about IAM policies here, which I strongly suggest if this is a new concept for you. With IAM, there’s a set of limits that will have relevance to the structure I’ll be suggesting. Key limits to know are:
- 100 Groups per AWS account
- 10 Groups per IAM user
- 2 Policies per group
With IAM policies, you should also have a firm grasp on IAM Policy Evaluation Logic. There are two concepts that you absolutely need to know:
- Implicit deny and explicit allow/deny
- Deny precedence
Implicit deny means that it’s denied by default without a specific policy in place. Generally, there is no implicit allow as that would be insecure. Explicit allow/deny means that it’s allowed or denied because there is a policy specifically allowing or denying the task.
IAM works off an implicit deny basis, in that everything is implicitly denied by default. You need to specifically allow something to have access to it. Additionally, an explicit deny takes priority over anything else.
Let’s say I have a policy, Policy A, that explicitly grants access to an EC2 instance. I have another policy, Policy B, that explicitly denies access to the EC2 service. I attach these both to the same group and add it to my user account. IAM policy logic will specify that I do not have access to either the EC2 instance or the EC2 service. This is how deny precedence will affect access.
Using that knowledge, I do recommend the following:
- Assign policies to groups, not users
- Manage everything through groups
- Try to focus on role based grouping, not creating a group for every person
- Regularly review which policies are needed
- Apply the “Full Administrator” or per-service “Administrator” policies sparingly (I cannot stress this enough)
Just on the last point, you don’t want to give all your users Full Administrative access or even Service Administrative access, as that becomes a significant issue. Where possible, limit people to specific resources or services, giving them the permissions they need.
IAM Policy Setup and Structure
In a new account, the one of the first steps is to set up a group called “UserSelfService” (or something similar) and attach an appropriate policy to it. All users should be added to this account, even your administrative users. You never know when you might need to remove administrative access.
The policy I use for user self service is this:
Before using this, find and replace “PUT-YOUR-AWS-ID-HERE” with your AWS Account ID. What this policy will do, is allow users to modify their own IAM account (including their MFA token), but not be able to modify anything else. They will be able to list all other items in the account such as Groups, Roles and Policies without any permissions to modify them. The aim is to allow people to work on their own account as required, but not to grant them unnecessary access to other accounts.
Your next steps should be to create your required policies for the various services. By assigning policies to groups, it will make management much easier since you can name groups according to their role. This will make auditing and administering accounts easier. Descriptive naming conventions are your friend.
If you have a reasonably sized team with segregated duties, you might find that you will hit the IAM limits. Judicious use of groups can resolve that, but you may end up having to do more user management if you’re not careful. This may only apply if you’re configuring a single role per group, a single role per policy and not combining roles in the policies themselves. As listed above in the UserSelfService policy, it actually combines access to IAM and MFA within a single policy. You can, if you choose, combine access to EC2, RDS and many other services within a single policy.
Just remember though, if you add multiple statements to a policy, you’re going to need to remember what each policy does and confirm its what your user requires. This can be an administrative nightmare, if you don’t plan out your policy structure. Planning for security is, however, a massive topic on its own – with no real end to it.
Another way is to utilise the dual policy capability of a group and use that to segment permissions. A good visual representation of this structure would be something like this:
As you can see, a group can have up to two policies in place. Users are assigned to the group to gain permissions. This makes it easy to add and remove permissions based on evolving needs, by adding and removing users from groups.
As an example, you might have users who are responsible for EC2 instances and RDS instances. You can create a group that has policies for EC2 and RDS assigned to it, allowing your dual role users to gain access. You might also have a DBA who needs RDS access, but not EC2 access – a group with the RDS policy gives them that permission.
Create IAM Users and enable MFA
As a result of using groups to assign policies, it greatly simplifies provisioning of your users. In IAM, you simply need to create the user account and assign it to the relevant groups. As discussed previously, ensure that the UserSelfService group (or whatever you’ve called it) is the first group you add. At this stage, you should direct the user to implement MFA. The self service functionality, granted in the policy discussed previously, will allow them that capability. Enabling MFA is pretty simple, I linked this in the previous article but it’s worth linking again – Configure and Enable a Virtual MFA Device for a User.
Once all the users are created and setup, you should periodically review your credential report to ascertain that everyone has MFA enabled. This will allow you to identify the accounts without it and take appropriate action.
By now, you should have a high level understanding how IAM policies dictate access within an AWS account. You should also be able to see the value in implementing fine grained control over what your users can and can’t do in the account. The combination of root security (in the first post) and IAM policies will allow you to improve the security of your AWS account.
However, there’s still a few more things you can do in order to improve your security and the next article will cover that. In the next article, I’ll be covering how you can setup your AWS accounts (yes, accounts, you need multiple accounts) in order to further enhance your security. This is based on advice provided by AWSs own solutions architects, where they encourage you to structure your accounts to mitigate the effect of someone breaking in. It’s no panacea, but it does go a long way to allowing you to making it harder to be hurt by a malicious attacker.