Well-Architected: Securing Human & Application Identity in AWS

Introduction

Identity management is central to every workload running in AWS. Every time a page in the AWS console is visited, dozens of checks are being made via the Identity and Access Management (IAM) service to ensure the person behind the keyboard is both authenticated and authorised to view the information they’re requesting. The same goes for using the AWS Command Line Interface (CLI) tool, or Software Development Kits (SDKs) – IAM is involved every single time.

You’d be right in assuming that this means it’s an incredibly important part of using AWS. IAM handles in excess of 400 million requests per second, underpinning all activities.

Whilst AWS has built an incredibly powerful and secure way to manage authentication and authorisation of identities in the cloud, the responsibility of making sure that the access granted is appropriate and in line with best practice falls to those using AWS. This is part of the Shared Responsibility Model, where AWS is responsible for security of the cloud and customers are responsible for security in the cloud.

This article aims to serve as a guide to best practice, not just listing the things that you should be doing but also providing actionable advice on how to migrate from existing methods to the best practice way of operating.

What does bad identity management look like?

Managing identity securely is a multi-faceted problem. So we’re all on the same page, authentication is the process of determining the validity of credentials, and authorisation is making sure that they have permission to carry out that particular action. As an example: if I make a request to the AWS S3 API using some temporary credentials, authentication is verifying that the credentials supplied are valid, and authorisation is checking that I’m allowed to carry out the s3:GetObject action.

To start with, let’s talk about what bad looks like. Acknowledging and identifying problems in security posture is the first step to remediating them. Remediation of these issues against best practice will be covered later in this article.

In any system, humans are one of the weakest links when it comes to security. Social engineering attacks are only increasing. This is why it’s so important to make sure that human access is controlled, sensible and limited.

There are a number of key signals that indicate the need for improvements in security posture of identity. If any of these are present, then alarm bells should be sounding:

Long-lived access keys

IAM access keys and secret keys are designed to be long-lived credentials. There’s nothing inherently insecure about using these, but the longer that they are active for, the longer an attacker could potentially use them.

Weak or old passwords

Weak passwords being a security risk shouldn’t be news to anyone. Additionally, the age of passwords can put you at greater risk. If passwords were to be exposed, old passwords have a greater chance of being present in data breaches.

No multi-factor authentication

A lack of multi-factor authentication (MFA), whether virtual or hardware, increases the attack surface significantly. Subsequently, not enforcing the use of MFA is also a risk.

Regular use of root account

The AWS root account has permission to do absolutely anything and is not affected by IAM policies. If this is being used regularly, there is a greater chance of mistakes being made, or passwords and access keys being exposed.

Overly permissive policies

Granting more permissions than are necessary presents a two-fold risk. If credentials are exposed and a malicious attacker gains access to your account, their ability to cause damage is far greater. For authorised users, more permissions than required increases the risk of accidental actions being taken.

Access to the AWS console

Granting AWS console access to IAM users that don’t need it doesn’t explicitly give them more permissions against resources. What it does do however, is increase the ease of an attacker discovering the resources available in the account.

What do we recommend?

At Ubertas Consulting, we base our recommendations on the AWS Well-Architected Framework. This is a set of principles defined by AWS, split into 6 separate pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimisation, and Sustainability. Most of the principles around identity management fall into the Security pillar.

Establishing a strong security posture around identity management doesn’t require a great deal of effort. The three recommendations below will go a long way to aligning you with the Well-Architected Framework and remediating your highest risk security issues.

Centralised identity management with single sign-on

Identity management is significantly easier when it’s centralised. It’s even better when you can make use of existing identity providers (IdP) in your organisation. When someone leaves your organisation, there’s enough to think about without having to worry about removing access in lots of different systems. If you can remove them from one central IdP, great. When it comes to managing permissions, centralising this also yields benefits. It encourages you to grant standard permissions based on job roles, rather than individual people.

Only use root account for break-glass scenarios

The root account should never be used in day-to-day working. Its extra privileged nature makes it perfect for break-glass access, where other access mechanisms have malfunctioned. Some actions in an AWS account require the use of the root account, in these cases highly controlled access to the root account is acceptable.

Regular rotation of credentials or use of temporary credentials

The best way to remove the security concerns around long-lived credentials is not to use them. I can hear you saying, “But Alex, that’s like saying the only way not to have a car crash is never to get in a car”. Hear me out; what you should do is replace the use of long-lived credentials with temporary credentials. In some cases, temporary credentials aren’t going to be technically possible. In these cases, regular rotation of long-lived credentials is the route to take.

What are the next steps?

So, you know what best practice looks like conceptually; let’s now look at how this can be applied within the context of AWS.

AWS Identity Center

Formerly known as AWS SSO, AWS Identity Center enables centralised management of permissions across a multi-account organisation. Offering single sign-on from sources such as Active Directory and SAML compatible identity providers, it is the easiest way to manage identity at scale in AWS. Standardised Permission Sets can be created to specify what users are authorised to do and can be applied to many users across many accounts.

In addition to privilege management, multi-factor authentication can be enforced to ensure that users are authenticating in the most secure manner.

Secure and monitor AWS root account

We now know that any use of the AWS root account outside of very specific scenarios is a key indication of poor security hygiene. To secure it, there are a number of steps that you should take.

The password should be randomly generated and stored in a password manager. Storing it in a password manager means that it can be shared with other authorised members of an organisation to increase resiliency in the event of needing to use it.

MFA is an absolute must-have. You can assign multiple devices, enabling the pattern of using hardware MFA devices and storing them in secure locations distributed across various offices. Virtual MFA is still significantly better than no MFA, so don’t worry if you can’t use hardware MFA.

Monitor root account usage. It’s all well and good knowing not to use it, but we need to know if anyone else is. You can use CloudTrail to create an audit log of all IAM activity in an AWS account (or organisation) and construct alerting around that to notify someone when the root account is used. Ideally this should go to a security team, who are forewarned if someone is using the account for valid reasons.

Utilise IAM Roles for applications running in AWS

Use of long-lived credentials is sometimes the best option, but in a lot of cases it isn’t. For applications running in AWS on services such as EC2, ECS and Lambda, there’s another choice.

IAM Roles are designed exactly for this purpose – short-lived credentials where AWS can manage the obtaining and refreshing of the secrets when required transparently. Like IAM Users, you attach policies to IAM Roles to specify what permissions the principal assuming that role has; keep in mind that you can’t place a role in an IAM Group however.

The general rule of thumb should be that if your application is running inside of AWS on AWS hardware, 99% of the time you could use a role rather than long-lived credentials via an IAM User with access keys.

IAM Roles Anywhere

For a long time, there was a big caveat to the ‘use IAM Roles almost all the time’ advice; this caveat was for applications running outside of AWS. This isn’t the case now. AWS has a service under the IAM umbrella called AWS IAM Roles Anywhere. At a high level, it does what it says on the tin; it allows you to use IAM Roles anywhere, including non-AWS hardware.

To authenticate your application to IAM in order to be issued temporary credentials, it uses certificate-based authentication. Your certificate authority is linked to IAM Roles Anywhere to establish what’s termed as a ‘Trust Anchor’. The CA then issues X.509 certificates for clients and these certificates are used to retrieve temporary credentials.

For more details on this new feature, take a look at the AWS documentation:

https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html

Automatically rotate IAM User access keys

At this late stage in the article hopefully you know that we don’t like long-lived credentials, but accept that sometimes they have to be used. Let’s talk about how to be secure when we do have to use them.

Whilst we may not have control over the decision to use long-lived IAM User access keys, we do have control over how long to keep them alive for. There isn’t a built-in way that AWS rotates access keys, but it can be built fairly simply. You don’t necessarily need to rotate them as often as temporary credentials (hours), but could choose a sensible standard like 30/60/90 days.

Let’s consider a case where we’ve got an on-premises application running across a number of servers that uses an access key and secret key to perform actions against AWS resources. In this scenario, we want to rotate our credentials every 30 days. The following actions can be carried out to rotate access credentials. These can be carried out entirely programmatically to make sure that the process happens regularly without reliance on humans:

1. Generate a new access key for the IAM User
2. Roll the new credentials out to each of the servers
3. After verifying that all servers have the new credentials and are still operating correctly, disable the old access key
4. To ensure easy rollback in the short-term, wait an appropriate time (e.g. 7 days) before deleting the old key

For a practical example of how to use the AWS CLI, take a look at this blog:

https://aws.amazon.com/blogs/security/how-to-rotate-access-keys-for-iam-users/

Summary

Hopefully you’ve learnt from this article the key signals of a bad security posture for identity management in AWS, what the best practice looks like as well as how to progress with getting up to standard.

If you’d like some practical help with this or an overall evaluation of your AWS workload against the Well-Architected Framework, get in touch to book in a Well-Architected Framework Review! These are cost-neutral to you, whilst giving you access to an Ubertas Consulting Solutions Architect over the course of a few days to review and remediate the highest risk findings.

Alex Kearns
Principal Solutions Architect, Ubertas Consulting

LinkedIn