Reducing Risk With Identity Access Management (IAM)

Last updated at Tue, 20 Aug 2024 19:36:18 GMT

A cloudy picture of identity and access

As your supply chain grows, so does your attack surface. As business scales up and cloud providers release new services and resources to support, it becomes exponentially more challenging for security teams to manage access. With this growth, an intrinsic — and completely understandable — need arises to protect valuable company assets.

So gates go up in the form of policy evaluation rules that review requests for access. But what happens when more and more policy layers are put in place to protect deeper access, sometimes overlapping in the same application? It’s easy for this to happen, but the need to safeguard and create efficiencies can co-exist. Let’s look at some methods for gaining full cloud-IAM visibility without clouding the view.

Policy puffery

As an organization realizes the scale that cloud enables, hopefully identity management becomes part of the growth strategy. But as more Identity Access Management (IAM) policies are written, things can get...messy. Because when there are too many overlapping policies, this can actually result in an increase in vulnerabilities as a team races to put gates in place and then, ironically, ends up creating a more porous attack surface. 3 IAM directives usually underscore the thinking of most organizations:

• Limiting the blast radius of any IAM failures
• Responding quickly to IAM incidents
• Establishing the coveted state of Least Privileged Access (LPA)

Everything in the cloud has its own identity; every service or asset contains multiple layers of permissions. Small cloud environments alone can encompass hundreds of permission rules. To help cut through all of this potential chaos and confusion, AWS features policy evaluation logic that includes 5 steps for a classic threat-based approach where each “permit-deny” check helps shrink the potential fallout from a threat actor.

The most important step in this process is arguably the “explicit deny.” For example, this may come in the form of a “hard no” when reviewing an API call from a country known to sponsor terrorism. This IAM logic-flow in AWS begins with a denial, and then several policy actions to make a final permit-or-deny decision.

To get a bit more granular, an AWS Organizations “Service Control Policy” (SCP) takes security a step further. SCPs offer a sort of centralized control over permissions for all accounts in an organization and create guardrails that keep accounts aligned with access standards. The SCP keeps the process moving. It doesn’t grant anything, rather it keeps it all in line by limiting permissions that identity-based policies or resource-based policies grant to entities, ensuring that an organization is authorized.

• A permit response allows the organization to pass to the next IAM security gate.
• An implicit-deny response results after the check has failed or if there is no SCP attached to the requesting organization.

At the final gate of the process, access is granted with an “explicit permit” only if the requestor is associated with both an identity-based policy and a permit response.

Effective permissions

The concept of effective permissions in the realm of IAM essentially means the net-permission set for the cloud asset or user within all policy sets. With regard to AWS SCPs discussed above, a team might put an SCP in place to restrict identity permission for certain member accounts within an organization. Therefore, the effective permissions would come at the intersection of the SCP, the permissions boundary, and the identity-based policy. A request is only allowed if all 3 policies grant permission; an explicit deny results if any one of them does not.

Permissions boundaries in particular zoom out to the administrator view, giving them the power to create guidelines along which delegated tasks are executed. This boundary sets maximum permissions for an IAM user. DivvyCloud by Rapid7 contains an IAM Governance Module that essentially destroys and rebuilds an IAM policy stack by implementing a boundary view. When security teams are tasked with governing cloud environments at scale, this is when compliance might become a problem — without anyone realizing it. Even with what might be considered a sustainable boundary view, that perimeter will likely be more fluid than anyone can predict. DivvyCloud helps create a rational approach for managing that ever-changing identity-access perimeter.

Once teams are able to implement truly sustainable boundary views within a cloud IAM ecosystem, they can quickly identify critical areas of risk and non-compliance. They should ultimately be able to see which users have access to a resource, determine which roles contain cross-account permissions, and which resources or users link to an application.

Make it make sense for you

There are many ways to tailor IAM policies to rapidly scaling cloud security operations. As always, the challenge lies in keeping up with the changes. Setting IAM boundaries and determining effective permissions are part of the lifecycle that will help manage cloud IAM.

Want to learn more about AWS’s extensive IAM feature set and how it can help determine the blast radius of an IAM incident or establish and maintain LPA at scale? Read more about the cloud IAM lifecycle in the new Rapid7 report at the link below.