Rule number one in cloud security is, “thou shalt use MFA at all times”. Why? Well, when you move to public cloud computing you essentially take all your administrative interfaces, consolidate them into a single portal or API, and then… put them on the Internet protected with a username, password, and (maybe) MFA. Even when you use a federation.

But it turns out, even MFA isn’t always enough as seen in multiple major breaches, including over at Uber.

This is one of the most critical differences to understand between cloud and traditional infrastructure, and it’s why you keep hearing the phrase “identity is the new perimeter”. Before cloud we managed our datacenter from inside private networks (or through controlled access points like VPNs and jump boxes). With cloud all that’s on the Internet by default and it is tough to lock it down, especially now that we more-often support remote employees and administrators.

MFA is an effective ways to protect user/administrator authentication. We have ton of options ranging from a bit more secure (messaging-based MFA) to really darn secure (hardware keys). But the problem even with MFA is that users have persistent access with persistent privileges. If you give a user a role, they can use those permissions anytime after authenticating. Attackers know this and have developed a range of techniques to gain authenticated access. They:

• abuse static credentials, especially if there is no MFA in use.
• break past some MFA. For example, they SIM swap to intercept text messages headed to phones.
• socially engineer administrators to disable MFA or reset to a device under their control.
• socially engineer users to snag an MFA code.
• steal session credentials from a user’s system after they have already authenticated, then use them from a system under the attacker’s control.

Once an attacker obtains access, they then start exploring privileges and eventually use those for malicious activity.

Least Privilege is a Lie

The core problem is we provide permissions not based on what someone needs to do at a point in time, but what they might need to do in the future. Users, especially administrators, have the maximum set of permissions for all possible actions. Every security standard on the planet says IAM should be default deny and least privilege, but that’s kind of a lie since the set of “least privileges” is defined by the maximal set of privileges they will need at some time, not all the time.

Even when we allow users to switch roles and use different permissions for different sessions, they still nearly always have access to those roles whenever they want. In reality least privilege should be time-bound, not just user-bound. Historically we manage permissions by assigning roles, and roles have permissions at a scope. “You are an admin on these 5 accounts and a regular user on the other 98”. Often we even assign a user multiple roles; which either combine permissions or they can swap around roles when doing different things.

Imagine how much harder it would be for an attacker if we eliminate persistent privileges. Instead of a user authenticating and having access to all their permissions, they instead have access with a really small set of permissions and have to escalate for anything potentially harmful.

Add Security with Dynamic Authorizations

I’m not proposing we do away with MFA or other authentication-level security. Those are still vitally important, but sometimes they aren’t enough. This is especially true in cloud security due to the greater degree of inherent Internet exposure. but cloud also has advantages, and those include session-based federation and fine-grained authorizations (down to individual API calls).

Instead of providing users with persistent access to all the permissions they might ever need, we provide them with more-limited access and they then request access to escalated privileges. This isn’t a new concept; it’s what privileged user management products have used for years. But those products have often still relies on clunky techniques like proxied sessions and rotating temporary passwords. Cloud is inherently more flexible since the native IAM models are session-based by their nature and privileges are defined in policy documents (typically written in JSON).

This is how tools like our FireMon Authorization Control work. Or take a look at Netflix ConsoleMe for an open source example. Users request access when they need it, and then the platforms use policies to determine what’s needed for approval. When those conditions are met, such as sign-offs from a manager or coworker, the user is authorized to use a role for a session. The platforms can even insert conditions, such as “only allow this session from the IP address that requested it”. These requests are typically out-of-band and use side channels like ChatOps for approvals, making the process purposely noisy, especially for sensitive production access.

Authorization-level security actually makes life easier for everyone, from developers and users to security administrators. You don’t need to know the full set of potential permissions ahead of time. Instead, users ask for what they need when they need it. Policies determine the lowest-friction path to providing that access without compromising security. Tools like ChatOps mean a developer can request access to a new account and get an answer back within seconds, as opposed to having submit a request into a ticketing system that could take days or weeks.

By adding security to authorization we reduce the impact of stolen credentials and hacked authentications, all while reducing friction and overhead.