Header image

#AWSreInforce: Getting to the Root of Managed Authentication

Why forcing MFA on root users is the best way to ensure security throughout an organisation.


This week, AWS announced its intention to push multi-factor authentication (MFA) out to users, with support added for FIDO2 passkeys.

Intended “to help customers align with their MFA requirements and enhance their default security posture,” this addition will help users - who already use passkeys on billions of computers and mobile devices, using only a security mechanism such as a fingerprint, facial scan, or PIN built in to their device.

User-Friendly Form Factor

Speaking to SC UK, Mark Ryland, director of Amazon Security says the intention is to provide a “somewhat more user-friendly convenient form factor” for users.

He explains that the concept is around using the passkey as a second factor when you're authenticating to an AWS console. “So still have a username and password, but you're very strongly encouraged to have an MFA factor, and now you can use a passkey approach,” he says.

“It's totally use case dependent: many banks and government agencies will prefer to use hardware tokens and we already support that, but to try to get to that middle tier and the small-medium sized business, and really get them to use MFA.”

Calling this “a very secure approach”, Ryland says passkeys are the best option in this case, as the ease of use combined with the cryptographic properties of FIDO2, make the MFA addition a stronger authentication process.

“If you can make the easy path also be a secure path, then you'll get much broader adoption and the features that people don't use are the ones that often get you in trouble,” Ryland says.

The Root Principal

Another addition in AWS’ authentication steps is now requiring MFA on root users, specifically “the powerful users that have overall control of an environment.” Ryland explains that this was being rolled out gradually, “as you don't want to do it all at once because you want to give people time to get accustomed to it.”

However there will be more warnings about setting up MFA for those users. “We start with these highly privileged environments - they're called the management account of an organization - so that allows the user to configure dozens or hundreds of accounts into a single security unit.

Ryland says: “The management account, which is like the root account, is very powerful because it can influence all those other accounts.” He explains that the most critical security principle is whoever is the owner of that root account has that MFA enabled, and that level of security “trickles down throughout the whole infrastructure.”

“Occasionally for very powerful actions you use that root principal, and that's the one we want to lock down first as we kind of march through the estate to lead by example,” Ryland says. “So if those credentials do leak, the most damage that could happen would be with that particular user.”

Ryland was quick to point out that many users are already using federated identity to log into their AWS accounts, but what is crucial is to ensure that the root principal user is set up. 

“Once you're in, you can create an account in Okta or Ping or one of the federation providers, and you can create a trust relationship between your AWS account and your identity provider,” he says. “Then your typical administrator or developer authenticates to that identity provider for example and then when they get a SAML token or an OIDC token from that company, they come to our environment and we authenticate them based on their identity that they have outside of AWS.”

Ryland says that scenario is very common, and most enterprise-level customers tend to use federated identity already as they want to enable single sign-on across multiple properties.

He admits that there is an element of forcing users into the more secure authentication, but “the combination of forcing and [using a] passkey is a much better story than forcing alone.” However there is a need to secure the highest priority users, and he believes that this is all part of increasing security as it is about “forcing them in a friendly way to adopt better technology.”


Dan Raywood Senior Editor SC Media UK

Dan Raywood is a seasoned B2B journalist with over 20 years of experience, specializing in cybersecurity for the past 15 years. He has extensively covered topics from Advanced Persistent Threats and nation-state hackers to major data breaches and regulatory changes. Outside work, Dan enjoys supporting Tottenham Hotspur, managing mischievous cats, and sampling craft beers.

Dan Raywood Senior Editor SC Media UK

Dan Raywood is a seasoned B2B journalist with over 20 years of experience, specializing in cybersecurity for the past 15 years. He has extensively covered topics from Advanced Persistent Threats and nation-state hackers to major data breaches and regulatory changes. Outside work, Dan enjoys supporting Tottenham Hotspur, managing mischievous cats, and sampling craft beers.

Upcoming Events

08
Aug
Webinar

How to Automate the Lifecycle of Joiners, Movers, and Leavers With No-Code Solutions

Streamlining the lifecycle of joiners, movers, and leavers using no-code automation

The process of onboarding new employees and quickly removing departing staff profiles can be both time-consuming and labour-intensive.
In this live webinar, we will look at how to streamline these processes to save time and resources, and providing a smooth experience for both admins and employees.

Key takeaways:
  • Understanding the importance of securing the joiners, movers and leavers process
  • Exploring successful attacks that occurred due to errors in managing these transitions
  • Discover which advanced controls can be utilized
image image image