Multi-Cloud Security: Managing Risk Across AWS, Azure, and GCP

Running workloads across multiple cloud providers has become the norm rather than the exception. A 2024 Flexera report found that 87% of enterprises use multiple clouds. Each cloud has its own security model, IAM system, logging format, and compliance controls. Managing security coherently across this heterogeneous environment requires specific tooling, processes, and architectural patterns.

The Multi-Cloud Security Challenge

Multi-cloud security isn't simply the sum of securing AWS plus Azure plus GCP. The challenges are qualitatively different:

Visibility fragmentation: Each cloud has its own security console, log format, and finding type. A security team that has excellent AWS Security Hub coverage may have no visibility into their GCP Security Command Center findings.

Identity silos: AWS IAM, Entra ID, and Google IAM are fundamentally different systems. A user leaving the organization may have their Entra ID account disabled but retain active AWS access keys or a GCP service account key.

Inconsistent policy baselines: A security baseline enforced via AWS SCPs doesn't translate to GCP org policies. Maintaining equivalent controls across clouds requires parallel policy authoring and testing.

Compliance mapping complexity: SOC 2 controls map differently to each cloud's native services. A single compliance assessment requires collecting evidence from multiple dashboards.

CSPM Tools: The Foundation of Multi-Cloud Visibility

Cloud Security Posture Management (CSPM) tools provide unified visibility and compliance assessment across multiple clouds. The major platforms have converged toward what's now called CNAPP (Cloud-Native Application Protection Platform), which combines CSPM with workload protection (CWPP) and attack path analysis.

Wiz

Wiz took the market by storm with its agentless architecture and "security graph" approach. Rather than generating thousands of individual findings, Wiz builds a graph of relationships between cloud resources and identifies attack paths that combine multiple issues.

How it works: Wiz connects via read-only API access across all cloud accounts. It builds a graph database of every resource, its configuration, network connections, IAM relationships, and running workloads (using out-of-band disk scanning for VMs). The security graph then evaluates complete attack paths rather than individual misconfigurations.

Strengths:

• Zero agents, instant deployment
• Attack path analysis that shows which findings are actually exploitable
• Excellent multi-cloud coverage (AWS, Azure, GCP, OCI, Alibaba)
• Container and Kubernetes security without Kubernetes API access
• Data security posture (identifies sensitive data in cloud storage and databases)

Pricing: Per-resource pricing, typically $15-25 per VM/month for full CNAPP coverage.

Example Wiz finding (attack path):

Internet → Public-facing EC2 instance (has SSRF vulnerability)
  → EC2 IAM role (has s3:GetObject on *)
  → S3 bucket containing customer PII

Individual tools would surface the public EC2, the overpermissioned role, and the sensitive data in S3 as separate findings. Wiz presents them as a connected attack path.

Prisma Cloud (Palo Alto Networks)

Prisma Cloud is the most comprehensive platform, combining CSPM, CWPP, CIEM (Cloud Infrastructure Entitlement Management), CI/CD security, and API security. It's the market leader for enterprise deployments requiring agent-based workload protection.

Architecture: Prisma Cloud offers both agentless scanning and agent-based protection (Defender agent for Kubernetes, VMs, and serverless). The agent enables real-time threat detection, forensics, and runtime blocking.

Strengths:

• Deepest feature set in the market
• Real-time container and serverless protection with Defenders
• CI/CD pipeline scanning (Twistlock/bridgecrew integration)
• Comprehensive compliance frameworks (80+ frameworks)
• Network policy recommendations

Weaknesses:

• Complex deployment, high learning curve
• Agent management overhead at scale
• Higher cost than newer entrants

Lacework

Lacework differentiates with its behavioral analysis engine (Polygraph) that builds a model of normal behavior for your cloud environment and alerts on deviations. This is particularly effective for detecting credential compromise and insider threats.

How it works: Lacework collects CloudTrail, GCP Audit Logs, Azure Activity Logs, and container runtime data. The Polygraph algorithm builds a baseline of normal API call patterns, network connections, and process behavior. Anomalies are surfaced without requiring a library of predefined rules.

Strengths:

• Behavioral detection catches novel attacks that rule-based systems miss
• Low false positive rate (behavioral baseline adapts to your environment)
• Strong cloud threat detection and investigation workflow
• Agentless for cloud posture, agent available for deep workload monitoring

Example: Lacework detects when an IAM role that normally only calls s3:GetObject suddenly starts making RunInstances calls — indicative of credential compromise even before specific attack patterns are known.

Orca Security

Orca pioneered "SideScanning" — out-of-band scanning that reads cloud storage and compute directly via provider APIs without agents or network access. This provides deep visibility with minimal deployment complexity.

How it works: Orca takes snapshots of cloud storage volumes and reads them in Orca's own environment. This allows scanning for vulnerabilities, sensitive data, malware, and misconfigurations within running workloads without deploying any software into your environment.

Strengths:

• True agentless (no network access to customer workloads required)
• Contextual prioritization (combines vulnerability severity, workload exposure, and data sensitivity)
• Fast time-to-value
• Strong data security posture management

Weaknesses:

• No real-time runtime protection (agentless means no in-process monitoring)
• Lower granularity than agent-based tools for threat detection

Comparison Matrix

Feature	Wiz	Prisma Cloud	Lacework	Orca
Deployment	Agentless API	Agent + Agentless	Agent + Agentless	Agentless SideScan
Attack Path Analysis	Excellent	Good	Good	Good
Runtime Protection	Limited	Full	Medium	Limited
Behavioral Detection	Good	Good	Excellent	Good
CIEM	Good	Excellent	Good	Good
CI/CD Security	Good	Excellent	Good	Good
Time to Value	Hours	Days-Weeks	Days	Hours
Multi-Cloud	AWS, Azure, GCP, OCI	All major	AWS, Azure, GCP	AWS, Azure, GCP

Unified Identity Management

Federated Identity with an IdP

The foundation of multi-cloud identity management is a single Identity Provider that serves as the authoritative source for all user accounts. Workday, Okta, or Azure AD (Entra ID) federated to AWS via SAML/OIDC and to GCP via Workforce Identity Federation:

AWS with Okta:

# Configure Okta as SAML IdP in AWS
aws iam create-saml-provider \
  --name Okta \
  --saml-metadata-document file://okta-metadata.xml

# Create roles that Okta users can assume
aws iam create-role \
  --role-name OktaDeveloperRole \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"Federated": "arn:aws:iam::123456789012:saml-provider/Okta"},
      "Action": "sts:AssumeRoleWithSAML",
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
      }
    }]
  }'

GCP with Workforce Identity Federation:

gcloud iam workforce-pools create my-workforce-pool \
  --organization=123456789 \
  --location=global \
  --display-name="Corporate Identity Pool"

gcloud iam workforce-pools providers create-oidc my-okta-provider \
  --workforce-pool=my-workforce-pool \
  --location=global \
  --display-name="Okta OIDC" \
  --issuer-uri="https://my-org.okta.com" \
  --client-id="my-gcp-app-client-id" \
  --attribute-mapping="google.subject=assertion.sub,google.groups=assertion.groups"

Consistent Offboarding Process

When an employee leaves, a unified offboarding checklist prevents access persistence:

# Offboarding automation pseudocode
def offboard_user(user_email):
    # Disable in IdP (propagates to federated access)
    okta.deactivate_user(user_email)

    # AWS: deactivate any direct IAM users (should be minimal)
    for account in aws_accounts:
        iam_user = find_iam_user(account, user_email)
        if iam_user:
            aws.iam.delete_access_keys(iam_user)
            aws.iam.deactivate_mfa(iam_user)

    # GCP: remove direct IAM bindings
    for project in gcp_projects:
        remove_iam_bindings_for_user(project, user_email)

    # Azure: handled by Entra ID deactivation + PIM role removal

    # Revoke any service account keys the user created
    audit_and_rotate_keys_created_by(user_email)

Consistent Policy Enforcement

Policy as Code with Terraform + OPA

Use Open Policy Agent (OPA) Rego policies to enforce security rules across all cloud Terraform configurations, regardless of provider:

# policies/cloud-security.rego

package cloud_security

# Rule: No public S3 buckets
deny[msg] {
    resource := input.resource_changes[_]
    resource.type == "aws_s3_bucket_public_access_block"
    not resource.change.after.block_public_acls
    msg := sprintf("S3 bucket %v must block public ACLs", [resource.address])
}

# Rule: No unencrypted EBS volumes
deny[msg] {
    resource := input.resource_changes[_]
    resource.type == "aws_ebs_volume"
    not resource.change.after.encrypted
    msg := sprintf("EBS volume %v must be encrypted", [resource.address])
}

# Rule: No GCP instances with public IPs
deny[msg] {
    resource := input.resource_changes[_]
    resource.type == "google_compute_instance"
    resource.change.after.network_interface[_].access_config[_]
    msg := sprintf("GCP instance %v must not have external IP", [resource.address])
}

# Rule: Azure VMs must have disk encryption
deny[msg] {
    resource := input.resource_changes[_]
    resource.type == "azurerm_managed_disk"
    not resource.change.after.disk_encryption_set_id
    msg := sprintf("Azure managed disk %v must use customer-managed encryption", [resource.address])
}

Integrate OPA into your Terraform pipeline:

terraform plan -out=tfplan
terraform show -json tfplan > tfplan.json
opa eval --input tfplan.json \
  --data policies/ \
  --format pretty \
  'data.cloud_security.deny'

Cloud-Native Policy Enforcement

Despite the appeal of unified policy-as-code, use each cloud's native enforcement mechanism for runtime guardrails:

• AWS: Service Control Policies (SCPs) + AWS Config Rules
• GCP: Organization Policies + Security Command Center
• Azure: Azure Policy + Defender for Cloud

These native mechanisms are evaluated by the cloud provider before API calls succeed — they're the last line of defense if infrastructure-as-code checks are bypassed.

Multi-Cloud Incident Response

When an incident occurs in a multi-cloud environment, the investigation is complicated by:

• Different log formats and retention policies
• Different incident response workflows per cloud
• Possible lateral movement between clouds (e.g., AWS credentials accessed from a compromised GCP service)

Standardize on a common log format in your SIEM using Common Event Format (CEF) or OCSF (Open Cybersecurity Schema Framework):

# Normalize AWS CloudTrail event to OCSF
def normalize_cloudtrail_to_ocsf(event):
    return {
        "class_uid": 3002,  # API Activity
        "category_uid": 3,  # Identity & Access Management
        "time": event["eventTime"],
        "actor": {
            "user": {
                "uid": event["userIdentity"]["arn"],
                "type": event["userIdentity"]["type"]
            },
            "session": {
                "created_time": event["userIdentity"].get("sessionContext", {})
                    .get("sessionIssuer", {}).get("arn")
            }
        },
        "api": {
            "operation": event["eventName"],
            "service": {"name": event["eventSource"]},
            "response": {"error": event.get("errorCode")}
        },
        "src_endpoint": {"ip": event["sourceIPAddress"]},
        "cloud": {"provider": "AWS", "region": event["awsRegion"]}
    }

The multi-cloud security maturity model goes: unified visibility (CSPM) → unified identity (federated IdP) → unified policy (OPA + native enforcement) → unified response (SIEM + normalized logs + documented runbooks). Most organizations are at stage 1 or 2; reaching stage 4 is the goal of a mature multi-cloud security program.