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. To combat this issue, security-minded organizations need to lock down access management in AWS.

Amazon has done an excellent job in securing its 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, using 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 also the major attack vector for AWS.

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. This developer service company 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 and other best access management practices would have prevented the incident even when the credentials were already stolen.

More recently, we’ve seen an increase in credential theft to set 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 to provision and maintain 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 email address is used to create the AWS account in the first place.

It is used to set up the account billing with Amazon, join an organization if your company has more than one account, and 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. Set up multi-factor authentication (MFA) for root.
This is non-negotiable.  The 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 the root.
Because the root cannot be limited by other permissions, programmatic access keys should never be assigned to root.  If you have, remove them and use IAM credentials instead.

Identity and Access Management Credentials

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

The first step is to limit exposure by creating and assigning only credentials as 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 can log into the AWS console.  Service accounts will not have passwords enabled but will have programmatic access keys.

Access keys allow 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 IAM’s 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 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 that AWS can do this for you. However, you must replace the keys in your automated processes.  The 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, reducing the exposure window.

PROTIP – AWS Secrets Manager

Some solutions now help you manage to change keys in your process by eliminating the new hard-code access keys.  As of April 2018, AWS introduced its 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 processes are the only ones accessing my resources?  Another way to limit your exposure if any of your AWS credentials are stolen is by utilizing the least privilege principle.  Following this principle means any user is only assigned rights 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 the privileges they apply is often not apparent 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 domain.  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 customer managed policies in case one of the built-in ones doesn’t work.

Because of this high-level granularity, it is possible to define a privilege scheme that allows for different admins to 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 root equivalent 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 set based on what your different admins 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 customer managed policies.
Do not directly attach privileges to users; if possible, avoid direct attachment to roles or groups.

4. Attach policies to roles 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, a user has an urgent need to access a service, so an admin takes a shortcut and directly assigns a policy or privilege to the user.  This action is often forgotten, 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 About DevSecOps Security →