EN 
It’s become common knowledge that in cloud, “identity is the new perimeter”. It’s a nice phrase that’s easy to toss into a presentation or an article, but turning it into actionable guidance is a little tougher. Today, I want to focus on just one aspect of cloud IAM I call the “AuthN/AuthZ Gap”. It’s actually an issue anytime you use federation, but the stakes in cloud are higher since the cloud management plane is always internet facing.
First, a short primer on AuthN vs. AuthZ:
- AuthN is authentication. The act of proving you are an entity. For us mere mortals this is usually a username, password, and maybe MFA.
- AuthZ is authorization. The act of seeing if an action is allowed. For IaaS cloud this nearly always maps back to an API call, even when you use the web console/portal.
Authentication and Authorization are different tasks, with different flows. When we log into a website we authenticate and that typically creates a session. We don’t have to re-enter our credentials every time we click on something, our browser just sends along a token that’s valid for a time period. Authorizations are typically checked every time we try to do something to make sure we have the right permissions.
If you think about it, once you have that session token it isn’t checked again unless something in the code forces a new check. Your authentication is valid for the session, and thus you can do whatever is within scope of your authorizations. Depending on the platform/system those temporary credentials will still work even if they are revoked or the account is totally deleted. This is the AuthN/AuthZ Gap.
I spend a lot of time on this topic when I teach Cloud Incident Response since I’ve found that even experienced security responders don’t always understand the implications. Imagine the case of some stolen cloud credentials: you revoke or delete the credentials, but the attacker has an active open session and can potentially still execute authorized actions. This is… bad.
How do you resolve it?
Depending on how you are using those credentials the easiest option is usually to change the authorization. Just put a deny policy on the entity (or remove allowed actions), since that is evaluated for every API call made by the attacker. While this is the simplest option, it isn’t always the best since it can break running tasks (stolen credentials aren’t always just tied to users). Some other options, depending on the support from your cloud provider, include:
- Adding conditionals to restrict the originating IP for the API calls.
- Denying all sessions created before a particular date/time.
You are more likely to run into this issue when federating into a cloud provider than within the provider. I just ran a test in AWS and I lost access on open sessions pretty quickly after deleting an IAM user. However, the same isn’t necessarily true when federating in from an external identity provider, and even within AWS some services won’t check credentials again during active sessions (e.g. my Session Manager session stayed alive for about 15+ minutes after deleting the role that allowed access).
This isn’t some big unknown vulnerability, it’s something to keep in mind when developing your cloud security controls and incident response playbooks. Different kinds of credentials have different lifespans both between and within cloud providers. Your identity provider will also be a factor, plus where you try and revoke credentials. For example, if you have a user in Active Directory that you then federate into AWS, and that user assumes a role in AWS and retrieves session credentials for that role, you need to revoke or restrict the assumed role credentials even if you restrict the user in AD. AWS will have no idea the user’s session from AD is no longer valid until the end of the session when it goes to revalidate the authentication.
Internally we switched to using our Authorization Control tool which supports session creation with restrictions via ChatOps without adding any friction that might slow our developers down. While it isn’t in general release yet, if you are interested in kicking the tires during early access just email me directly at rich.mogull@firemon.com.