Do You Know Who IAM? Why Cloud Identity Is So Complicated

It has been well established that certain traditional IT security frameworks must be reimagined when approaching cloud-native architectures. One component of a strong security posture takes on a particularly critical role in the cloud: identity. Identity access management (IAM) is the "front door" to your cloud account and therefore to your business. While the concept "identity is the new perimeter" goes as far back as the ancient times of 2012 when AWS first announced its IAM service, balancing ease of use and security has remained a perennial challenge.

Looking back at some recent cloud security failures, a common trend emerges with inadequate management of identities, access, and privileges. In fact, Gartner predicts that, by 2023, 75% of all cloud security breaches will be the result of inadequate permission management. Things such as overpermissive roles, reusing the same IAM role for multiple users, and resources that are exposed to the public Internet are among the top reasons for public cloud security breaches.

So, how can we know what caused those failures and still predict such a large volume of continued incidents? If the potential risk is clear to security teams and solutions have existed for several years, why is it still an issue?

Permissions Get Handed Out Like Candy
When users create a new cloud account, it's most common to begin with a single identity that has complete access to the resources in that account. From this simple point, it doesn't take very long before permission complexity sprawls. Users can be part of many groups, and roles can be assumed by identities such as users, machines, and functions — plus, resources can have their own resource-based policies.

And because permissions can be attached directly to identities, groups, roles, accounts, and even to the organization — sometimes simultaneously — answering very simple questions like What are the net effective permissions of User X? or Who can access my sensitive resources? becomes a real challenge.

The inconsistencies in how each of those permissions are defined and the ways guardrails are set to enforce them makes it impractical to manually track and understand "net effective permissions." There are real limitations to reviewing individual user policies as a way to understand who can take what actions on which resources at the organizational level.

The Least Is the Most You Can Do
Understanding net effective permissions across complex IAM mechanisms is a foundation for good security hygiene in the public cloud, but it's only the beginning. Knowing users' actual usage and the last time an identity took a specific action on a particular resource is the next essential component of achieving a least-privilege operating model.

Similar to understanding net effective permissions, where the idea seems much simpler than the reality, actual usage can be tricky to track. Many different scenarios need to be taken into consideration. For example, the actual usage of any machine can be influenced by any number of policies performing the same action, multiple functions sharing the same execution role, or single sign-on (SSO) users might be assuming the same role based on their group.

Even the Fixes Get Messy
The other big challenge organizations struggle with is mitigating IAM-related risks once they understand net effective permissions and actual usage. The problem is that there are so many ways to address overprivileged entitlements.

Do you fix the problem at the identity level, the resource level, the group level, or the organization level? Should you create a new policy or modify the existing one? How do you manage remediation when multiple identities share the same role? These are all tough questions with no single answer — the solution differs based on the ways each organization implements IAM security.

You Can See Why the Issue Persists
Managing a large number of privileged users that have access to an ever-expanding set of services is challenging, and this is further complicated by the proliferation of IAM roles and groups that spread across cloud accounts.

If you cannot confidently answer basic questions like What can this user effectively do?, Are there any permissions that haven't been used for a while?, or What third parties have access to my cloud account?, then it's important to revisit your IAM security strategy.

That said, cloud providers deliver a great baseline for implementing a least-privileged approach to permissions; these guides from AWS and Google Cloud are good examples. And as cloud adoption scales in your organization, and as you inevitably establish a multicloud architecture, the challenges mentioned above (and more) will become more pressing.

At that point, it might be worth looking at a more comprehensive third-party solution that can automatically calculate net effective permissions across users, resources, and entitlements; continuously monitor for excess and unused privileges; and help remediate overpermissive entitlements to streamline a least-privilege access model.

About the Authors:

Bar Schwartz is product lead for the IAM Security module in Prisma Cloud. He has previously held software engineer positions, including PureSec as it was acquired by Palo Alto Networks. He has extensive experience with public cloud platforms and security, and he has an AWS solution architect certificate. Bar holds a bachelor's degree in computer science and is currently studying for an MBA focused on technology, innovation, and entrepreneurship.

Jonathan Bregman drives Prisma Cloud product marketing at Palo Alto Networks, focused on helping customers secure their cloud environments. Previously, he was a product marketer at Barracuda Networks and software development consultant at Slalom. Outside of work, he enjoys spending as much time as possible outdoors in nature, visiting parks for overlanding expeditions, mountain biking, and hiking.