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.
To increase cloud identity visibility and reduce risk, security teams need to find a way to distill clarity from cloud IAM complexity. They must be able to:
To paraphrase Albert Einstein, we cannot achieve clarity from cloud IAM complexity with the same level of thinking that created it. This change in thinking starts by understanding what it takes to grant access to a cloud resource.
Whether their resources are in the cloud or on premises, most organizations have three primary IAM goals:
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.
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 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).
Working through this cloud IAM policy gate process leaves security teams with an overlapping policy stack consisting of multiple permit/deny decision points for every cloud asset. Determining the effective permissions requires conducting extensive Venn diagram analysis. Plus, this process is ongoing since every IAM setting change affects every overlapping policy permission. Given that a typical enterprise cloud footprint has hundreds of cloud assets and principals, organizations often deal with thousands of identity and access rules. Put all the Venn diagrams together, and cloud IAM quickly becomes a raging inferno of conflicting, overlapping, and continually changing policy rules.
This cloud IAM inferno makes determining effective permissions exceedingly tricky. More importantly, even if the security team figures out how to quell the inferno and muscle through the Venn diagram analysis, effective permissions alone are insufficient to meet IAM goals. The reason is that effective permissions determine whether an actor (user or application) should have access to a cloud asset, not the potential impact or reach of that access.
Put another way, effective permissions are a threat-based concept, whereas a blast radius determination is a risk-based concept (i.e., involving understanding the impact of the threat). Specifically, effective permissions are missing two core components necessary to address risk:
Unfortunately, risk context and true identity are not bolt-on capabilities. Aligning risk context, true identity, and effective permissions requires reassembling an organization’s cloud IAM policy stack. Teams must first deconstruct the stack to its most basic elements (e.g., assets, permissions, rules, and accounts). Next, they match these elements to the enterprise IAM source of truth (i.e., Active Directory, LDAP, or third-party identity stores). Finally, they must match applications and their respective resources, business metadata, and historical context from a configuration management database (CMDB). The outcome shows what user/role is accessing a cloud asset (i.e., true identity) and the potential impact of that access (i.e., risk context).
Here is an illustration of how this works. DivvyCloud’s IAM Governance Module deconstructs and reconstructs the cloud IAM policy stack by creating an IAM boundary view. The IAM boundary view consists of three lenses that operations staff, analysts, incident response (IR) staff, and auditors can use to analyze and simulate their cloud IAM environment. These lenses are:
Using these lenses, teams can quickly identify all the resources a federated user has access to and why and what they did to gain access. This perspective gives the team what it needs to net out all the different permission boundaries and establish critical areas of risk and noncompliance. For example, the DivvyCloud IAM Governance Module provides immediate answers to the following primary questions relevant to establishing a baseline assessment in the event of a cloud IAM event:
Following an approach like cloud IAM boundaries sets up an organization to manage and govern cloud IAM. Given the dynamism of cloud infrastructure and the need for continuous permissions updates to manage risk, successfully implementing a cloud IAM boundary approach requires a lifecycle approach.
Step 1: Assess Risk
Understanding risk underlies successful cloud IAM. Teams can use DivvyCloud’s IAM Governance Module, Filters, and Scorecard to assess effective permissions. Teams can then use historical data to compare current efforts to previous actions. This comparison helps to address false permission alerts (i.e., non-effective permissions) and highlight anomalous activities that could represent IAM policy risks or indicate areas of noncompliance.
Step 2: Prioritize and Remediate
Using DivvyCloud’s IAM Governance Module’s simulation capabilities, teams can perform what-if analysis to look for potential cloud IAM issues proactively. Simulation is essential for modeling the blast radius of a possible cloud IAM exploit and identifying excessive and unused permissions that indicate permission “bloat.”
Step 3: Cloud LPA
After assessing risk, prioritizing cloud IAM misconfigurations, and remediating permission bloat, teams can establish and manage LPA by setting the minimum privilege possible to achieve the organization’s risk goals. LPA is a never-ending process, requiring ongoing assessment of privilege levels against organizational roles and permissions. Teams can use DivvyCloud’s bot automation to remediate permissions that are too restrictive or not sufficiently restrictive.
Step 4: Automate for Scalability
Finally, to address the ongoing growth of their cloud footprint, organizations must implement automated remediation of common high-risk IAM issues, such as anomalous behaviors, permission bloat, and under- or over-provisioning of LPA. This automation is essential for saving time and continually improving the organization’s risk posture, while accelerating its response to change.
In the end, operations staff, analysts, IR personnel, and even DevOps teams need to answer this simple question: what is the risk associated with access to my cloud applications and data by different users and systems?
By focusing on threats and risks, adopting an approach like the cloud IAM boundary view, and following a cloud IAM lifecycle approach, teams can cut through the complexity of current cloud provider IAM controls. This approach gives teams the clarity and context they need to answer this question confidently and easily. With precise answers, organizations can quickly determine the blast radius of an IAM incident and stablish and manage LPA at scale.
The result is establishing identity as the new security perimeter in the cloud, continually identifying and reducing cloud identity risk, and ultimately decreasing the chance of breaches and their resulting damage.
For more information, please read more about DivvyCloud's IAM governance here.