5 Common Cloud IAM Security Challenges and Why They Are Difficult to Fix

Challenge 1: Separation of Duties Between IGA and CloudOps

The global identity market is huge, with major players valued at over $100 billion combined. IGA teams use Okta, Entra, Ping, Sailpoint, Saviant and other Identity related tools. To secure IAM in cloud the IGA teams should learn atypical for them technologies: cloud IAM, IaaC, DevOps, SDLC and other frameworks and processes. From the other side, the Cloud Operations teams are focused on provisioning, deployments, high availability of cloud infrastructures and other related cloud management work. For them, managing cloud IAM is more “give more permissions to unblock developers” work. When the IGA specialists should implement a secure Cloud IAM setup, they have a temptation to say that this has to be done by the CloudOps engineers. The CloudOps  engineers’ main goal is to deploy/provision new applications in short terms to avoid new feature release delays, so to speed up solving permissions related issues in cloud they tend to grant more permissions for a Cloud Identity than it really needs and “fix it later” which rarely happens. New permissions provisioning and existing permissions changes in the cloud happen every day, so these overprovisioned identities and other Cloud Identity related problems accumulate over time and can cause high risks in the future. The overlapped part of cloud IAM needs understanding of both worlds: the Identity Governance and Administration skill from one side and the Cloud Operations from the other. It usually requires a dedicated engineer, special tooling and sophisticated processes, especially in a multi-cloud environment.

Challenge 2: Cloud IAM Permissions Change Constantly

Permissions in the cloud change every day. If no right process was set up, misconfigurations and vulnerabilities accumulate quickly which increases the blast radius.

1. The most dangerous permissions that can be added to a cloud identity are the IAM management permissions. If these permissions are given, then the identity can create a new identity, grant an existing identity more permissions, remove some permissions that an authorized identity really needs, that may block access for authorized administrators. Restoring access takes time that the attacker will use to exfiltrate data or cause other damage. 
2. Cloud IAM vulnerabilities can accumulate very quickly. By the time a company decides to clean them up, nobody remembers why they were assigned and whether it is safe to remove them or not.
3. Often organizational software development teams use cloud IAM vulnerabilities to implement business logic. Fixing these vulnerabilities will either cause production downtime or require rebuilding the whole application.
4. Change requests. In a perfect world no permissions changes should happen without approval and a strict apply process that involves GitOps process. This reduces the risk to minimum while slowing down the SDLC process and new feature releases. So businesses must decide  between a quick release with more risk or slower release with more security. 

Challenge 3: Implementing Least Privilege in Cloud IAM

In my opinion this is the most painful part of managing cloud IAM. Everybody knows that it is a good thing: a few know how to make it right, just a few of a few have time to make it right, and only a few of a few of a few do make it right. Developers and their managers are always requesting new identities or new permissions. They do not care about security; they need to release a new feature for yesterday. If the CloudOps team does not implement the request right now, “the whole organization is blocked” escalation request will be sent to upper management immediately. Organizations do not have time or resources to implement “least privileges” for thousands of identities over three clouds. According to the Microsoft’s “State of Cloud Permissions Risks Report” report, 98% of permissions in the cloud are not used. Overprovisioned and overprivileged identities become a huge problem when an organization is under attack. To implement “least privileges” correctly, the organization should have a tool that detects the overprovisioned identities, helps prioritize remediation, and the engineering team needs to spend time on remediation daily.

Challenge 4: Managing IAM Across Multiple Clouds

This problem is more about people and skillsets. Having one engineer who understands all major clouds well, or having an engineer per cloud provider…  For example:

1. AWS manages all identity and permissions management inside the cloud, all permissions are defined in JSON code 
2. Google separates it: users and groups are managed in G-suite, which is usually inaccessible by Cloud Operations teams, but all GCP service accounts and permissions reside in Google Cloud IAM.
3. Microsoft manages ALL identities in Entra, only the permissions are managed in Azure RBAC

The other example: 

• AWS OIDC setup takes up to two hours and is very simple, but AWS does not support custom JWT fields in roles’ trust relationships policy 
• GCP OIDC setup is much more complex and might require Google support to complete correctly 
• Azure OIDC setup happens not in Azure, but in Entra, so the engineer should have access to the Microsoft SSO provider, know how to manage it and keep in mind that Entra does not support JWT wildcard masking for CircleCI before choosing a continuous integration provider 

Managing and securing cloud IAM in a multicloud environment requires a dedicated full time senior level engineer to keep risk at the acceptable level.

Challenge 5: Cloud IAM Governance, Risk, Compliance and Reporting

Risk officers do not and should not know a lot about cloud IAM depths, but they should have human readable cloud IAM risk reports and metrics. Executives and board members should have more generalized reports to understand whether they need to invest time and money to secure cloud IAM or buy more expensive insurance. CloudOperations engineers should understand business expectations to be able to properly manage and protect cloud IAM. Sometimes it is hard for CloudOps to accurately express security and tech priorities to the executives. In this case, wrong prioritization can cause potential breaches when cloud IAM compliance is sacrificed to release a new feature on time. Understanding and setting right prioritization and risk evaluation is the main responsibility of the risk officers, and to implement this task efficiently the right choice of tools is critical. Teriam provides all three levels of reporting: reports for board members and executives, reports and metrics for risk and governance officers and intelligent CIEM for operations engineers.