Last updated at Tue, 11 Apr 2023 19:26:11 GMT
Cloudy judgement
Combining the separate themes of cloud technology and identity access management (IAM) might seem like an oxymoron in today’s endlessly scaling environments, but there’s really no going back in the box when it comes to the promise of cloud in driving innovation. The fact is, security and operations teams currently have close to zero visibility as deployments accelerate and identity management becomes increasingly difficult to scale.
Losing control but gaining ideas
Can security teams ever truly understand their cloud permissions? As DevSecOps grows ever further into the cloud, more people have the ability to provision cloud resources independently, without involving IT. This freedom offers tremendous opportunity, but also poses a risk if IAM isn’t addressed. IAM policies are becoming more complex, making it harder to determine who or what has access to your cloud resources and what they can do.
And that could simply be the tip of the iceberg; a harbinger of how difficult managing identity can become at scale. Vulnerabilities are the inevitable follow-along, as IAM confusion sends countless organizations down the road toward future security incidents. To a large extent, this is all avoidable. Organizations can start by asking themselves these questions:
- How can we limit and understand the cloud security “blast radius”?
- What is the best approach to ensure that the right people and cloud resources have the ability to do the right things at the right time for the right reason?
- Can we verify access by each principal, resource, or application?
Cloud services and assets all have their own identities containing several permission layers. And even something like a group policy permission may cancel, augment, or reduce an individual policy permission. There are, however, ways to open permissions with data, insights, and risk context.
The AWS permission model
Security teams must ensure they are protecting their cloud resources by verifying identity and access levels. The logic for determining access can be complicated. Let’s take a look at how AWS determines whether to allow or deny access.
- Explicit deny evaluates all applicable IAM policies to determine if an explicit-deny exists for a specific request.
- An AWS Organizations service control policy (SCP) limits “permissions that identity-based policies or resource-based policies grant to entities.”
- Resource-based policies evaluate inline permissions to a resource (e.g., S3 bucket and IAM role trust policies).
- IAM permissions boundaries define the maximum permissions that identity-based policies can grant to an IAM entity.
- Session policies limit permissions that the user’s identity-based policies grant to the session.
- Identity-based policies give an implicit-deny if there is no policy associated with the individual or if there is a policy but no permit.
Figuring out what access a principal, resource, or application has when viewed in the context of these gates is by no means an easy task. It’s a process that continues in perpetuity as identity verification needs change and modifications subsequently affect policy permissions. And with the multitude of cloud assets in each organization, it’s easy to see how the potential of IAM chaos can quickly become reality.
Another key aspect of IAM is the concept of effective permissions or access. Even though gates may be in place, risk still exists. Once a principal, resource, or application is verified, what can they do after they’re in? Someone may be posing as a properly credentialed person or may make a mistake that has unintended consequences. Plus, effective permissions don’t currently address the fact that applications consist of many cloud assets. Risk increases exponentially if someone needs to get into one of them, but actually has access to all of them.
Making IAM make sense
These issues are not insurmountable. In order to make cloud IAM function properly, organizations must align risk context, effective permissions, and the true identity and intentions of users. For instance, InsightCloudSec creates an IAM “boundary view” to tear down and then rebuild the cloud IAM policy stack. Why does it do this? It’s really the only way to ensure each step of the process is as holistic and secure as it can possibly be.
This boundary approach provides a full understanding of an organization’s cloud environment and the contexts in which it is used. Using this full picture, InsightCloudSec’s IAM Governance module analyzes the scope of access for principals, applications, and resources. Security teams have greater visibility and can therefore assess risk with historical data and trends, automate high-risk IAM processes, and continuously tune identity and access permissions. This process ultimately helps teams work toward achieving least-privileged access and creates a foundational baseline from which a successful cloud IAM lifecycle can be sustained.
Rewards outweigh risks
Want to learn more about the pitfalls and potential of cloud IAM operations? A new Rapid7 whitepaper dives deeper into the risks associated with standing up and scaling up an identity access management program, specifically the myriad ways threat actors add vulnerabilities. But with a deliberate and detailed approach, any team can significantly reduce complexities and harness the potential of cloud IAM.
