Avoid IAM Drifts Using Explicit-Deny

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.

Proposed mitigation: The explicit-deny model

When diving into the root cause of confusion and complexity, the implicit deny access model is the root cause. If one of the policies will instead use explicit-deny, there will not be any need to inspect all other policies.

For example, consider that user group 2 has an allow for resource group 1 but deny to resource group 2. Policies of user group 1 (which includes user group 2) or resource-based policies in all levels will not be able to bypass the explicit allow.

Explicit allow can be also done for fine-grained privileges. For example, to allow write-access for PDF files and explicitly deny write-access for everything that is not PDF file. This can be done identity-based and/or resource-based. Once set, no allow can override it.

Note that cloud service providers support several ways of impersonation. Some of them, may bypass even an explicit deny. Hence, an explicit deny will have to be defined also for impersonation, tightening who can impersonate who and how.

Conclusion

The rich IAM mechanism of cloud service providers may lead to granting unintentional and indirect access to resources. This post demonstrate several ways that make the IAM complex, and proposes to use explicit-deny model wherever possible, in order to ensure that other policies will not be able to grant unwanted access.

About the Author

Over the past 15 years, Israel Chorzevski has gained expertise with multiple technologies, including cloud-native, web, mobile, client-server applications, and IoT/embedded devices. Israel has worked with a variety of industries, including tech giants, financial institutions, gaming companies, and intelligence agencies. The blog represents his own opinion and not his employer’s.