Multi-Cloud Governance: Access Reviews and Drift

This is Part 5 of the Multi-Cloud Identity series.

In a multi-cloud identity governance environment, identity is not a static asset; it is a dynamic state that diverges from its desired configuration continuously. For security and compliance engineers, the core challenge is not merely listing who has access, but proving that the current permission set matches the approved business requirement at any given millisecond. This requires shifting from periodic "access reviews" to continuous state reconciliation, and from reactive drift alerts to automated remediation loops.

The Accumulation of Entitlements in Multi-Cloud Identity Governance

To understand governance, we must first map how entitlements accumulate across heterogeneous identity providers. In AWS, permissions are attached to IAM roles, users, and groups, often inherited through nested policies and service-linked roles. In Azure, Role-Based Access Control (RBAC) assigns roles to security principals at specific scopes, with inheritance flowing from management groups down to subscriptions and resource groups. GCP uses Identity and Access Management (IAM) with a hierarchical structure where bindings attach roles to members at the organization, folder, project, or resource level, heavily influenced by organizational policies and folder-level constraints.

The complexity arises when these systems interact. A developer might have an AWS IAM role that assumes an Azure AD application identity via federation, or a GCP service account that triggers an AWS Lambda function. Each hop introduces a new permission boundary. Without a unified view, an engineer cannot see that a single logical user holds excessive privileges across all three clouds, nor can they prevent orphaned access from accumulating over time.

The Mechanics of Drift

Drift occurs when the actual state of an identity's permissions diverges from the defined policy. In traditional on-premise environments, drift was often manual—a sysadmin added a user to a local admin group for troubleshooting and forgot to remove them. In cloud environments, drift is systemic and automated.

Consider a CI/CD pipeline that provisions a new microservice. The pipeline uses Terraform to create an AWS IAM role with s3:GetObject and s3:PutObject permissions. However, due to a bug in the Terraform module, the role also inherits s3:DeleteBucket from a parent policy. This is immediate drift. Later, a security engineer manually adds a condition to the role in the AWS Console to restrict access by IP, creating a second layer of drift between the code repository and the live environment.

Detection requires comparing the "desired state" (defined in Infrastructure as Code repositories like Terraform, Pulumi, or CloudFormation) against the "actual state" (queried via cloud provider APIs). Tools like CIEM platforms or Cloud Custodian poll these APIs at intervals, calculating the diff between the two states. The challenge is that cloud APIs return the current effective permissions, which may include temporary credentials or conditional access rules that are not captured in static code definitions.

Access Review as State Reconciliation

An access review is often misunderstood as a human-centric audit. In a technical governance framework, it is a state reconciliation process. The workflow involves three steps: scoping, aggregation, and enforcement.

Scoping defines the boundary of the review. For example, "all users with Contributor role in the Production management group in Azure."

Aggregation pulls the effective permissions for each identity in scope. This is non-trivial. In AWS, you must resolve all attached policies, including those from organizations (AWS Organizations SCPs), to determine if a role is truly allowed or denied. In Azure, you must traverse the hierarchy of management groups and subscriptions to calculate the effective role assignments. This data is then normalized into a common format, such as a JSON object mapping user_id to permission_set.

Enforcement is where the review becomes actionable. Instead of exporting a CSV for an email approval, the system generates a remediation plan. If a user holds Admin rights that are no longer required by their job function, the system can automatically downgrade the role or trigger a ticket in Jira/ServiceNow. The key is that the review is not a one-time event but a recurring job that runs on a schedule, ensuring that the state converges back to the desired configuration.

Real-Time Drift Detection via Event Streams

Periodic polling for drift is insufficient for high-security environments. A more robust approach uses cloud provider event streams to detect drift as it happens. AWS CloudTrail, Azure Activity Log, and GCP Audit Logs record every administrative action.

By subscribing to these logs, a governance engine can watch for specific events:

• CreateRole, AttachRolePolicy, AddUserToGroup in AWS.
• Microsoft.Authorization/roleAssignments/write, Microsoft.Authorization/roleAssignments/delete in Azure.
• SetIamPolicy in GCP.

When such an event occurs, the engine immediately recalculates the effective permissions for the affected identity and compares them against the policy-as-code definition. If the deviation exceeds a threshold (e.g., adding iam:CreateUser to a developer role), the system can trigger an alert or an automatic rollback.

However, this approach faces challenges with ephemeral identities. Just-in-Time (JIT) access models, where privileges are granted for a short duration, represent authorized, time-bound state changes distinct from drift, which is an unauthorized deviation. These legitimate lifecycle events should not be flagged as policy violations. To handle this, the drift detection logic must understand the lifecycle of the identity. If a role is created via a JIT broker and has an expiration time, it is not a drift event until after expiration if it persists. This requires integrating with identity brokers like CyberArk Privileged Access Manager or AWS IAM Identity Center.

Synthesis: The Governance Feedback Loop

Effective multi-cloud identity governance is a closed-loop system. Drift detection identifies deviations from the desired state. Access reviews validate that these deviations are authorized or identify unauthorized changes. The findings from both processes feed back into the policy-as-code repository, updating the desired state.

This loop must be automated. Manual reviews are slow, error-prone, and easily gamed. Automated drift detection without automated remediation creates alert fatigue. The goal is to reach a state where the majority of drift is corrected automatically, and human intervention is reserved for complex exceptions that require business context.

For security engineers, this means investing in tools that can normalize identity data across clouds and integrate with CI/CD pipelines. For compliance engineers, it means defining policies that can be expressed as code, allowing for continuous verification rather than annual audits. The result is a governance model that is resilient, transparent, and scalable across multi-cloud environments.

Conclusion

Multi-cloud identity governance fails not because of a lack of tools, but because access reviews are treated as static audits rather than continuous state reconciliation, and drift detection ignores the temporal nature of just-in-time (JIT) and conditional access. By treating identity as a dynamic state and automating the feedback loop between policy-as-code and cloud APIs, organizations can achieve true continuous compliance.