I have written a few posts now on Amazon Web Services (AWS) and some of the very cool things that it is possible to do within AWS. However, one thing that I feel that I need to cover before I go any further is probably one of the most important aspects of AWS even though it does not actually deliver any services, that aspect is Identity Access Management (IAM).
What IAM provides is user, group and permissions management. In short, it is the authentication source of the AWS world. If you are more of an Azure or Google Compute person then there is a lot here that will be familiar because both of those platforms also use IAM to control access to resources.
When you first create an account with AWS, you will be asked for a username and password to set up the account. This account is the AWS root account and it contains one important right that no other account created under IAM will have – the right to delete the entire AWS account including all storage, all EC2 instances, containers and everything else. If you backup your machines using AWS snapshots well, those will be gone as well. The delete account option really is akin to an execution of the account and everything it contains. If this happens maliciously and you do not have any of the data offsite then there is no recovery. It is for these reasons that the very first thing you should do after creating an AWS account is to enable IAM and to create user account that you will be using all the time. This account can be an admin but be careful here as an admin level account may not be able to delete the account as a whole but it can delete the resources contained in an account.
When setting up IAM, you will be given a unique logon URL that is the account number and a sign in link. You can change this to be a company name but be careful with the choice of name otherwise it might become easy for a malicious person to guess the unique sign in URL for your company and try credential-stuffing attacks to gain access.
As you can see from the screenshot above, my lab account has a custom IAM sign in link that is easier to remember than using the default URL that would have the account number included in it.
Whenever you logon to AWS and go to the IAM page, you will get a quick security check of the setup. This check is not that thorough as it just checks that there is one additional IAM account and that root has had its access keys rotated and secured with a second factor.
Once you have secured the root account, the next step should be to create an account that you will use day to day for administration functions. Even if you give this account admin access it still will not have the ability to delete the account itself, however, it will have the ability to delete individual resources so an admin account could, if used maliciously, cause quite a bit of havoc an so, like the root account, it should be secured with a second factor.
To do this, click on IAM -> users -> [your new account] -> security credentials -> assigned MFA devices and enrol using your chosen MFA device. I use Google Authenticator and that works very well for me but can become a little cumbersome trying to find the right token set to use when the app lists multiple sites.
Once you have your user admin accounts up and running, the next thing to look at is delegated access and pragmatic access accounts.
When creating an IAM based account, there are two ways for the account to access AWS resources. The first is directly – via the AWS website and the second is programmatically via the AWS cli for example.
Programmatic requires an access key and a secret key, both generated by Amazon. The secret key is only shown once during creation and never shown again so it is important to add it to your password management system when the key is displayed because it is only displayed once.
In many ways, these programmatic access accounts can be thought of as non-interactive service accounts that you would use in windows – they cannot be used to access desktop but can run services, access resources and so on.
Ideally, a programmatic account will have very limited rights, as it is not possible to use a second factor with these accounts. They are secured using just the access ID and secret Key.
All of these features in IAM are free. There is no charge for creating users, groups and so on. There is also no charge for adding a second factor to an account. Amazon do not force this on you but moving to such a model makes sense from a security standpoint and the price of free just cannot be argued with!
One interesting feature I noticed when I first started to try out IAM was that an account administrator did not get access to billing data. That access required an additional step of logging on as root, going to the billing section and ticking the box labelled “Active IAM access”, Billing permissions still need to be granted to the account but once that is done the account will have access to the billing data.
Permissions in IAM and controlled by policies which are assigned to groups. Users added to those groups will inherit the permission policy attached to the groups. IAM comes with over 500 pre-defined permissions policies and it you can create your own although at first, it is best to stick with what IAM gives you until you get familiar with how IAM permissions and policies work.
In this example, I have a group called “S3-admin” that has the policy “AmazonS3FullAccess” allocated to it. This permission is an Amazon default and as it says, allows full access to S3 buckets. Users in the group “S3-Admin” will gain the right to access, modify, create and delete anything under S3. They will not have access to anything else. Every section in AWS has an Amazon created policy like this and there are many others that provide different levels of access to AWS functionality.
In summary, like many things in AWS, IAM has an extensive range of functions that allow it to be configured to suit your organisations needs but it will take up some time to get right. However, it is worth doing and the granular permissions approach is the best way to secure and delegate access to AWS and ensure that your account is as safe as possible.
