How to avoid the 4 main pitfalls of cloud identity management

Securing cloud identities isn’t easy. Organizations need to complete a laundry list of actions to confirm proper configuration, ensure clear visibility into identities, determine and understand who can take what actions, and on top of it all make sure the actions aren’t malicious or inappropriate.

But one of the core benefits of the cloud is the ability to move fast and innovate rapidly, which means teams may just throw in the towel and grant admin privileges to their entire cloud identities instead of tackling the massive deluge of individual requests for access. This is a key reason why there are more than 35,000 possible permissions from AWS, Azure, and Google Cloud alone.

In the cloud, developers are capable of spinning compute, storage, and database services on their own, making it difficult to know what’s actually running in an environment. Behind cloud complexity you’ll almost always find out that users and entities are over-permissioned, which puts the company at risk.

Cloud identity management is a real challenge, but organizations are capable of preventing identity risk exposure and identity threats, especially if they avoid the four common pitfalls.

Pitfall #1: Misconfigurations

Misconfigurations tied to cloud identities leave organizations vulnerable to malicious actors and more prone to breaches.

To avoid misconfigurations, organizations need to first implement a system which automatically discovers cloud resources and services. From there, it’s possible to assess configurations for identity-related risks, like weak and default passwords, hardcoded secrets/keys, and wildcard permissions.

There’s also the case for increasing visibility to avoid misconfigurations. The Center for Internet Security (CIS), PCI Security Standards Council, and International Organization for Standardization (ISO) provide frameworks and best practices that can help organizations learn how to improve visibility across their environment. Lastly, organizations should always write custom policies to meet their unique needs.

If your security posture is more mature, consider cutting through alert noise with innovations like attack path analysis, which can pinpoint the riskiest assets and provide visibility into exactly how an attacker could exploit a misconfiguration.

Pitfall #2: Leveraging IaC without factoring in security

DevOps and Security teams are often at odds with each other. DevOps wants to ship applications and software as fast and efficiently as possible, while Security’s goal is to slow the process down and make sure bad actors don’t get in. At the end of the day, both sides are right – fast development is useless if it creates misconfigurations or vulnerabilities and security is ineffective if it’s shoved toward the end of the process.

Historically, deploying and managing IT infrastructure was a manual process. This setup could take hours or days to configure, and required coordination across multiple teams. (And time is money!) Infrastructure as code (IaC) changes all of that and enables developers to simply write code to deploy the necessary infrastructure. This is music to DevOps ears, but creates additional challenges for security teams.

IaC puts infrastructure in the hands of developers, which is great for speed but introduces some potential risks. To remedy this, organizations need to be able to find and fix misconfigurations in IaC to automate testing and policy management. It’s important to correlate potential cloud misconfigurations to IaC and enable remediation at the source before they happen. Only then can organizations truly benefit from IaC and move quickly without compromising security and reliability.

Pitfall #3: Check your privilege

A least-privileged approach to granting access is truly the best way to prevent dangerous identities from entering a cloud environment. But that’s not realistic anymore. Most users are granted access for the sake of speed and innovation, and this only creates problems down the line.

Not everyone needs admin access. Microsoft’s 2023 State of Cloud Permissions Risks report reveals that even though 50% of cloud identities are granted access as “super admins,” only 1% of permissions are used.

How do we fix this? Let’s start with visibility. Organizations need to first discover cloud identities and associated entitlements to receive an honest and up-to-date inventory of cloud users, resources, groups, and roles. Each cloud identity should also be analyzed and correlated to understand which entities and permissions are used and at what rate. Usage patterns can help pinpoint which cloud identities require attention. From there, you can determine how to limit access to only resource-based permissions that the users will actually utilize.

Pitfall #4: Always on the defensive

Unfortunately, the best least-privilege program won’t always be able to prevent credentials and accounts from being compromised. That’s why risk prevention and threat detection are mission critical for cloud identity management.

Organizations need to actively keep an eye on activities within their environment, human and non-human, to track unusual behavior. A unified set of automated tools can help with this by continuously collecting, monitoring, and analyzing massive amounts of data, making it easier to quickly detect unusual behaviors or malicious threats.

Conclusion

The first step to avoiding these pitfalls is to better understand your cloud identity environment. With visibility into all cloud identities and permissions, your organization will be able to determine all potential threats in progress and more easily determine which pose a genuine risk.

Pay close attention to which users are causing access and identify misconfigurations both during development and at runtime. Paying attention to your cloud environment and the security it requires will only help you innovate faster, and at much lower risk.