Machine identities and cloud permissions: why CIEM exists
What is a machine identity?
Any identity that software uses to act in your cloud: the role a serverless function assumes, the service account a build pipeline uses, the instance profile a virtual machine runs with, an access key embedded in a workload. They are created by templates and automation, often by copying an earlier role that already worked.
Why do their permissions grow?
Because broad permissions make things work. A developer who hits an access error adds a wider permission, the deployment succeeds, and nobody removes it later. Multiply that across hundreds of functions and pipelines and the estate fills with identities that can do far more than they do.
Why is that a security problem?
An attacker who compromises a workload inherits its identity. If that identity can read every storage bucket or create new users, a minor vulnerability becomes a serious breach. Security teams call this the blast radius of an identity.
What does a CIEM tool do?
- Reads every identity and policy through cloud APIs, in every cloud you connect.
- Computes effective permissions: what each identity can do once all policies, groups and role assumptions are combined.
- Compares granted permissions with permissions actually used over a period, and flags the unused ones.
- Highlights risky combinations, such as an identity that can escalate its own privileges.
Where does CIEM sit among vendors?
On the pages we read, Orca, Cortex Cloud, CrowdStrike, Defender for Cloud, SentinelOne, Sysdig, Upwind and Wiz name CIEM. Aqua does not name it on the pages we read. The CIEM page shows the status for all nine.
When should CIEM come early?
When you run more than one cloud, when serverless and pipelines create many roles, or when an auditor asks who can reach a sensitive store and the answer takes days. The finder adds CIEM points for exactly those answers.