Identity and Access Management in Amazon Web Services (AWS)

Amazon Web Services (AWS): Most Popular Public Cloud Infrastructure

Amazon Web Services (AWS) consistently remains the most popular provider of public cloud infrastructure and for good reason.

It’s a robust, reliable platform that enables businesses to deploy and operate their applications and corporate computer infrastructure with significantly less effort than traditional in-house hosting.

The downside is the public visibility of AWS and similar cloud services can make your environments a bigger target for cybercriminals.

Amazon has done a good job in securing their platform and passing those capabilities down to the customer to help secure themselves.

However, an understanding of the security capabilities of AWS and the best practice guidelines must be understood by customers to protect their environments and data.

A Few Facts About Identity and Access Management

According to a 2018 Verizon report, use of stolen credentials remains the number one action in cybersecurity breaches.

Given the rich set of controls in which AWS customers can secure and harden their infrastructure in the cloud, it is no surprise that simple credential theft is the major attack vector for AWS as well.

Needless to say, the potential for business disruption or worse is a real possibility if any AWS credential is compromised.

One of the most famous incidents involving AWS credential theft is the case of CodeSpaces, a developer service company that was forced out of business in 2014 because the attacker deleted the vast majority of the company’s cloud environment after obtaining AWS account credentials.

In 2017, Uber had its AWS credentials stolen from another repository used to gain access to private information for 57 million customers and drivers.

Utilizing multi-factor authentication in AWS would have prevented the incident even when the credentials were already stolen.

More recently we’ve seen an increase in credential theft for the purpose of setting up Crypto-mining.  Even large corporations like Tesla are not immune.

Identity and Access Management in AWS

So where do we start?  To be clear we are discussing credentials used to manage your company’s AWS environment for the purpose of provisioning and maintaining cloud resources.

These are managed by AWS’s Identity and Access Management service (IAM).  The good news is IAM gives you a one-stop shop for provisioning and assigning credentials across your AWS account, but it must be used correctly.

However, before talking too much about IAM credentials, we must mention one special credential associated with every AWS account: the root access account.  This is an email address and is used to create the AWS account in the first place.

It is used to set up the account billing with Amazon, join the account to an organization if your company has more than one account, and to set up the initial IAM credentials within the account.

Once established, the root should be locked away and no longer used.  All management on the account should be performed with IAM credentials. However, before you lock the root away, you should do two things:

1. Setup multi-factor authentication (MFA) for root.
This is non-negotiable.  Best practice is to use a hardware MFA device, but if that is not available, then a virtual device (Google Authenticator, etc) will have to suffice.

2. Remove any access keys associated with root.
Because the root cannot be limited by other permissions, programmatic access keys should never be assigned on root.  If you have, remove them and use IAM credentials instead.

IAM Credentials

Okay, root is secure.  What about the IAM credentials?

The first step is obvious, limit exposure by creating and assigning only credentials as they are needed.  Review allocated credentials often and revoke them when no longer needed.

In addition to limiting the credentials created, separate your IAM credentials into logical user and service accounts.  Users will have passwords enabled and be able to login into the AWS console.  Service accounts will not have passwords enabled but will have programmatic access keys.

Access keys allow for a program or automated process to access AWS resources with the permissions defined for the service account.  Given that, let’s look at best practices for each type of logical IAM credential:

Users

1. Enable IAMs password strength rules.
IAM provides controls to enforce minimum password strength.  Enable them for your AWS account and all IAM credentials with passwords enabled will follow.

2. Enable multi-factor authentication (MFA).
For this, a virtual MFA is sufficient and provides an extra layer of protection in case the credentials (username and password) are stolen.

3. Limit the use of access keys.
Access keys can be enabled for user accounts and a common use case is when utilizing an application to access an AWS resource interactively (ex: S3 bucket reader).  Any access key assigned to a user account should be rotated every 90 days and revoked once the use cases are no longer valid.

PROTIP – Identity System Integration

Integrate your company’s federated identity system with AWS.  Most of today’s options for federated identity can be integrated with AWS as an identity provider.  This allows for you to provide console access to employees through your existing identity system and reduces the number of user credentials you have to create directly in AWS.

Service

1. Don’t mix credential usage.
Often, we see service accounts created with passwords enabled even though there is never a reason to log in to the AWS console with that account.  Don’t do it.

2. Rotate your access keys.
This means to change them (often).  The good news is AWS can do this for you. However, you must replace the keys in your automated processes.  Best practice for key rotation is to rotate every 90 days with the rationale that if any key is compromised, there is only a finite window in which the key will ‘function’.  Once you solve changing keys in your automated processes, the rotation period can be shorter, further reducing the exposure window.

PROTIP – AWS Secrets Manager

There are solutions now that help you manage to change keys in your own process by eliminating the new to hard-code access keys.  As of April 2018, AWS introduced their own solution to this problem:  AWS Secrets Manager.

Account Privileges

Okay, we’ve lowered the risk of unauthorized access, but how can we be sure the right people and process are the only ones access my resources?  Another way to limit your exposure if any of your AWS credentials are stolen is through utilizing the principle of least privilege.  Following this principle means any user is only assigned privileges needed to perform their job function.  This applies to programmatic credentials as well.

Of course, that is system administrator 101 and not new news, but understanding how AWS policies stack and privileges they apply is often not obvious when first working with AWS IAM.  Often, we see the over-privileging of accounts for company operations personnel (Network Ops, DevOps, etc).

The more high-privilege user accounts floating around, the higher the risk of compromise.  In traditional environments these roles have often had full admin privileges for all aspects of the environment.  In AWS, privileges are much more granular allowing control over individual actions within each AWS service.

Privileges are commonly defined through Policies in IAM, and as of today there are 413 predefined policies available.  On top of that, you can define your own customer managed policies in case one of the built-in ones doesn’t work.

Because of this high-level of granularity, it is possible to define a privilege scheme which allows for different types of admins that can manage different parts of the AWS environment.

Some best practices to follow:

1. Limit the use of the administrator access policy.
This is the functional equivalent of root and can do everything to an AWS account except delete the account itself.  Too often operations staff is just assigned this as a single privilege to allow them to access all services.  Instead, use the principle of least privilege and assign based on what your different admins actually need to do.

2. Limit the use of the IAMFullAccess privilege.
This allows the user to do anything in IAM including giving themselves Administrator Access.

3. Define privileges through your own customer managed policies.
Do not directly attach privileges to users, and if possible, avoid direct attachment to roles or groups.

4. Attach policies to role and groups, not to users.
Directly attached policies, as well as inline defined policies attached directly to users, are difficult to maintain and lead to situations where visibility of permissions is difficult.  Often, we see a user has an urgent need to access a service, so an admin takes a shortcut and directly assigns a policy or privilege directly to the user.  This action is often forgotten about, and a user may keep an elevated privilege long after the need.

Amazon Web Services provides a rich environment for managing credentials and privileges that allow customers to control who has accessed their resources on both a macro and granular scale.  However, because of public nature of AWS, it remains a target for credential theft, and if some simple best practices are not followed, customers could be at risk.

VerSprite Security Operations

VerSprite encourages you to take the time to review your IAM setup today and ensure you are following the guidelines discussed in this post. Interested in learning more about SecOps?

The focus of SecOps services revolves around security engineering for Cloud and On-Prem environments (which includes Managed Hosting or CoLo environments).

VerSprite offers a range of managed security services aimed at providing a service that addresses client challenges across vulnerability management, threat analysis, technical remediation, system auditing/ hardening, and more. VerSprite’s SecOps →

Security Operations

We solve unique problems for clients plagued with security noise, limited resources, or costly 3rd party tools that under-deliver. Learn More →