Identity and access management with AWS
Introduction
Having a secure AWS environment requires having control and visibility of your users and resources. AWS Identity and Access Management (IAM) is the main method of controlling access and permissions within AWS.
AWS Solutions Architect
AWS IAM Fundamentals
In order to control access to your AWS resources, IAM allows you to create users, groups and roles. A user is an account for a specific developer, engineer or other person who requires access to your AWS account. Each user can be allowed access to any or all AWS services, and each user can be given different access compared to any other user. This said, it is not advisable to grant different access to each and every user in your environment. This is where groups come in.
An IAM Group is a collection of users which all have the same access. For example, you could create a group called “Admin” which is granted full control over your AWS environment, while your “Developer” group only has access to specific S3 buckets, Lambda and or other resources. Groups should be used instead of giving each user individual access, as the chance of either giving a user too much access or forgetting to give them something they need rises for each user you create. This causes potential security risks or causes delays as the user needs to come back for more access.
IAM Roles are similar to Groups in that they grant specific types of access, but unlike a Group a Role may be applied to resources within your AWS account. This may sound confusing, but let’s show a case where you would want to use Roles. Let’s say you have a development environment where you are building your new application and a production environment where your customer’s data is stored. You could attach the “Development” Role to your development EC2 instance and restrict access to all “Production” S3 buckets and other resources. IAM Roles can also be granted to users in a different AWS account, as well as to users outside of AWS such as an Active Directory user.
Root User
When creating a new AWS account a user account is created at the same time. This account is known as the Root User which has permissions to all AWS services and billing access for the account. If access to your AWS account is compromised by hackers, it is necessary to have access to the Root User account for recovery. Because of this it is best practice to secure the account with a strong password and two factor authentication. The Root User should not be used for day to day administration, other user accounts should be created for these tasks and the Root User should only be used in emergency situations.
Authentication
There are two ways for an IAM user to authenticate with AWS. The first is signing into the AWS console. Second using an IAM access key to make programmatic requests through the AWS Command Line Interface or API. When creating an AWS User, you may choose to limit that user to AWS Console access, programmatic access or both.
AWS Console access will allow the user to create and manage the AWS resources assigned to them through Policies and Permissions. Programmatic access, on the other hand, will allow the user to send API calls directly to AWS services. It is important to note that anyone who has your IAM access key will have the same access as you. This is why it is crucial that you never use your root account’s access key, if this key were to leave your control whoever had it would have complete control of your AWS account.
IAM Key Management
In order to ensure that your AWS account remains secure, proper management of access keys is necessary. Amazon offers other services, such as Key Management Service, which allows you to create and store keys for other AWS products. Here we will only be discussing IAM Key Management.
One basic method for ensuring security is to regularly rotate, or change, IAM user access keys. Users can be granted the permission to change their own access key, but it is still best practice to audit and ensure that this occurs. Also, do not embed access keys within your code, this is a main reason for access keys to be compromised. Instead, place access keys within the AWS credentials file when using the AWS CLI or SDKs. Finally, make sure to use different access keys across your AWS account, do not use a single key with wide ranging permissions. If you use a single key and you lose control the damage could be much greater. Additionally, if you use separate keys, you have the ability to revoke only the compromised key, speeding up recovery time.
Authorization Policies and Permissions
Access to Amazon resources is controlled through policies attached to IAM Users, Groups, Roles or Resources. These policies are generally JSON documents which are evaluated when an IAM user or role makes a request. The most common types of policies are identity-based policies and resource-based policies. AWS will evaluate both the user’s IAM identity-based policy and the resource’s resource-based policy for an explicit Deny policy, then will evaluate for an explicit Allow policy for the user and only after both steps have been determined to be true will the request be allowed to process.
AWS Solutions Architect
Conclusion
Today, security is a top concern for all cloud-based applications. Through careful provisioning and monitoring of IAM users, groups and roles you can be sure that access to your applications and resources are secure.
