Gaining Control Over Cloud IAM Chaos

The ephemeral and dynamic nature of cloud resources, combined with new features enabled by software-defined networking in the cloud, makes traditional security perimeters insufficient for successful risk management. Therefore, leading cloud adopters have turned their security focus to a new perimeter—identity. This is substantially different and more complex than the firewall perimeters of traditional data centers. The complexity of the cloud service provider identity and access management (IAM) tools makes it exceptionally challenging to determine who—or what—has access to a cloud resource. For example, Amazon Web Services (AWS) offers extensive policy evaluation logic, starting with a request context and then deriving all applicable policies from that. Within a single AWS account, this evaluation logic engages up to five overlapping policy layers to permit or deny access. Combine these policy layers with on-premises identity, and the result is a jumble of overlapping and often conflicting IAM privileges. 

When it comes to cloud IAM, security and operations teams are flying almost blind. This visibility drops to zero as cloud deployments grow and cloud IAM complexity increases with scale. This resulting tangled puzzle of IAM policies and rules means organizations lose any ability to assign and manage cloud least privileged access (LPA), let alone understand the permissiveness of their cloud access. Even more important, when organizations are not entirely in control of cloud IAM governance, they are incredibly vulnerable. If they experience a security incident, the lack of cloud IAM visibility makes determining the potential blast radius a tough, if not impossible, task.

Whether their resources are in the cloud or on premises, most organizations have three primary IAM goals:

1. Assessing and limiting the blast radius of a potential IAM failure;
2. Effectively responding to IAM failures in the event of an exploit; and
3. Establishing and maintaining control over LPA.

Even before the advent of cloud, these goals were challenging to achieve. Identity compromise and privilege escalation have been, are now, and will continue to be primary attack vectors.

Everything Has an Identity

An already tricky practice becomes nearly impossible in the face of the scale, scope, and ephemeral nature of cloud services. Every service and asset in the cloud has its own identity with multiple permission layers.

In public cloud environments like AWS, Microsoft Azure, and Google Cloud Platform, each component (e.g., VM, storage bucket, infrastructure service, serverless function) is associated with roles and permissions. Even small cloud footprints require hundreds of identity permission rules, each built by one or more cloud service provider IAM controls. And, there is a significant control overlap. For example, a group policy permission may cancel, augment, or reduce an individual policy permission.

Once the security team turns all the IAM dials to set IAM policies and rules, what is left are the effective permissions. These make up the net permission set for the cloud asset or principal. Effective permissions are a powerful cloud IAM construct, but as described below, simply determining what they are is not enough for cloud IAM success. The good news is that there are ways to enrich and augment effective permissions with the right data, insights, risk context, and perspective to drive successful cloud IAM.

AWS as a Cloud IAM Reality Check

AWS offers a robust IAM feature set. As shown in the figure below, the AWS policy evaluation logic includes five policy steps plus an explicit deny. Essentially, an IAM action starts with a denial and then flows through the policy steps to make a final permit/deny decision. This five-gate model is a classic threat-based approach where every permit/deny step reduces the potential of an exploit by a malicious threat actor (e.g., outsider, insider, user, or app).