IAM in layman's terms (2) -- managing internal user identities
sharing an engineer's view toward tractably and reliably managing internal users
“A picture is worth a thousand words”, and I found it’s true. After publishing the previous post, I found there are a lot of info that we did not get chance to express explicitly through the words for the last diagram in that post.
Now, let’s have one little appendix post before visiting the policy evaluation (which I think is the central topic about IAM).
Managing privileges policies at the group level instead of the user level
I remember when we were in school using the Solaris system, we belong to “graduate student” group, we belong to “computer engineering” group…
And the university IT staff defines what kind of NFS (Network File System) server and directories we can access to though defining the policy of those groups;
A student belongs to one or several groups;
And by belonging to the groups, a student get access to the right kind of access to the system. Most likely, IT staff won’t manage privilege policy at the user level.
Why? Because our IT staff can’t manage the individual needs of thousands of students (users), but they can easily track and reason about why a group exists and needs privilege XYZ. And by attaching a user to specific groups, the IT staff can grant privileges to users in a much more tractable way.
And this lends us the experience why a smart way to manage internal user’s AWS account access privilege should be a very similar way. Here we re-attache a diagram illustrating this point, but we did not explicitly speak out in our previous post:
To explicitly going through the principles illustrated by the red circle part in this diagram:
to manage internal users’ privilege easily yet tractably, we can have IAM policy attached to the IAM group level rather than at user level;
and then associate users to specific groups they belong to;
users holds their credentials (such as key pairs) to authenticate themselves;
Also, this echoes what AWS officially recommended us.
Use user groups to assign permissions to IAM users
Instead of defining permissions for individual IAM users, it's usually more convenient to create user groups that relate to job functions (administrators, developers, accounting, etc.). Next, define the relevant permissions for each user group. Finally, assign IAM users to those user groups. All the users in an IAM user group inherit the permissions assigned to the user group. That way, you can make changes for everyone in a user group in just one place. As people move around in your company, you can simply change what IAM user group their IAM user belongs to.
What does this apply to a small team?
This post is probably a good guidance to a small startup which does not have a full time security staff yet; or several engineers who have grouped together to pursue the passion of an SaaS start-up idea.
At this moment, you probably just want to focus on writing code. Why not? Cloud vendors like AWS have dramatically lowered the barrier for you to start delivering a non-trivial product — you don’t need to spend thousands of dollars to purchase servers and databases any more; and if your product is developed in a serverless paradigm, your AWS bill is probably $0 even after you have already acquired hundreds of customers.
But once you are a more than one person shop, you can (and should) do some basic yet very effective IAM practice to give you a lot of more runway from technical management perspective.
AWS IAM is an intimidating beast by all means to a non-security-experts, but we can do something basic and effective. If this tip applies to your friends, please share with them 😃 — this series of posts don’t plan to make you an IAM expert; but instead, we hope to give you “just enough” low hanging fruits so that you won’t get distracted to boring security issues too early.