AWS IAM Security Terminology Primer
AWS naming can be a bit strange, and there are a lot of components within their security infrastructure, known as IAM. This page will introduce you to the various components are and what they’re used for. Keep in mind this is just a primer; there’s a lot more nuance to many of these areas than we’re going to talk about. But this should get you going.
What is IAM?
First, IAM stands for Identity Access Management, and it’s pronounced, "I am." It manages both authentication, i.e. ensuring people are who they say they are, and authorization, i.e., ensuring entities are allowed to do what they’re asking to do.
IAM Users
IAM Users are not separate AWS accounts—they’re users within your account. You have your primary AWS account, which is your email and password to get into the AWS Console, and those credentials can function as root on any system within your account. So be careful with it, and don’t use it to administer your infrastructure.
IAM Users are what you should use instead, both for yourself and for any other function you need to give access to. This can include people, applications, etc. Each user can have their own password and their own access keys (see below).
Best practice per Amazon is to create an IAM User for yourself, give it admin permissions, and use it to do all your administration, including creating other users. You should also lock down both the root user and any administrative users using 2FA, which now supports authenticator apps such as Google Authenticator, OKTA Verify, etc.
IAM Roles
IAM Roles are like user skin suits. They have permissions assigned to them, but they don’t have credentials because you’re assuming that role with an existing user. They’re good for when a given role is done by different people at different times.
Access Keys
IAM Access Keys are basically SSH keys. It’s a bit more complicated than that because there are other types of keys, but for getting started you can think of Access Keys and SSH Keys as synonymous.
Policies
Get a weekly breakdown of what's happening in security and tech—and why it matters.
IAM Policies are fairly straightforward—they’re documents that encompass one or more permissions and let you define actions, resources, and effects (allow or deny). You can assign them directly to users, but it’s recommended that you assign them to groups instead, and then assign users to those groups.
Security Groups
Security Groups are strangely named. If you’ve been in security for a while and are hearing the term for the first time you’d probably assume they’re similar to…well, groups.
Nope. They’re basically firewall rules.
You define the protocol, port, and what source IP can access that port. And there are some presets for common ports, e.g., HTTPS, SSH, ICMP, etc. One cool feature, though, is that you can share the rules across different boxes without recreating them, almost like policies, except for network traffic.
Summary
Ok, here they are again in quick form.
The default user within AWS is your email/password you logged in with. You don’t want to use that to manage any boxen. Create a new user to do that.
IAM Users are what they sound like, and you can use them for apps as well as people.
It’s best to enable 2FA on any admin level account.
Roles are user skin suits. They’re for temporary functions, like "Backup Administrator" or something, which might have different people doing it.
Access Keys are basically SSH Keys. They’re how you authenticate to your infrastructure.
Policies are collections of permissions that can be assigned to users (not preferred) or groups (preferred).
Security Groups are essentially firewall rules that you can use across different boxes.
I hope this helps someone get up and running in AWS faster than they would have going through the documentation themselves.
Notes
If you spot any egregious errors in my simplifications, do let me know so I can fix them.