Cloud 101CircleEventsBlog
Join top cybersecurity experts at the Raleigh, NC LevelBlue's cyber networking event June 20th!

Avoid IAM Drifts Using Explicit-Deny

Avoid IAM Drifts Using Explicit-Deny

Blog Article Published: 03/15/2024

Written by Israel Chorzevsk.


Background

Over the last decade, cloud providers advanced their authorization mechanism, and added more and more ways to grant access to resources. Having multiple ways to grant access may lead to authorization drifts. This post describes several authorization features that may lead to such drift and proposes to use explicit-deny over implicit-deny whenever possible.

Note that cloud service providers implement their IAM model differently and use different terms for similar concepts. This post articulates it in general terms.


Granting access to a group of resources

Policies may grant access to a specific resource, or a resource group/folder and most cloud service providers support nested groups. The result of this feature is that to know if a user has access to a specific resource, all levels of groups must be checked.

The following diagram shows how access can be granted to different levels. Access of user U1 to resource R2 can be granted by a policy that grants access directly to R2 and/or to resource group 2 and/or to resource group 1:


Granting access to a group of users

Roles may be assigned to a specific user or a user group. The result of this feature is that to know if a user has access to a specific resource, all groups that the user is a member of have to be checked.

The following diagram shows how access can be granted by different levels. Access of user U1 to resource R2 can be granted by a policy that grants access directly from U1 and/or from user group 2 and/or from user group 1:


Granting access by resource-based policy

Access may be granted by binding a policy to a resource without the need to bind it to the role. The result of this feature is that to know if a user has access to a specific resource, all policies that are bound to the resource must be checked in addition to the policies that are bound to the role.

The following diagram shows how different levels of resource-based policies can grant access to a user. Access of user U1 to resource R2 can be granted by resource-based policies 1, 2, and 4. All policies of all levers of resources have to be reviewed to conclude whether a user has access and which type of access:


Impersonation

Users may act on-behalf other roles. The result of this feature is that to know if a user has access to a resource, all roles that the user can act on-behalf them have to be reviewed as well.

The following diagram shows how access can be impersonated. User U1 can impersonate user U2 and access to resource R2 or impersonate user U4 and access to resource R1:


Combined example

The following diagram shows how all users in user group 2 can impersonate user U7 and access to resource R2 due to user group’s policy and impersonation capability. In addition, user U1 can impersonate user U5 and access all resources in resource group 1 due to the impersonation capability and resource-based policy of a group of resources.