The premise in the title is a common and costly misconception I've seen in several client environments. Treating multi-cloud security as a simple matter of deploying a single CNAPP agent or connecting the same SaaS console to multiple clouds is a recipe for significant coverage gaps and a false sense of security. While a unified toolset is the *goal*, the *execution* is far more nuanced.
The core issue is that each major cloud provider has a fundamentally different resource model, identity fabric, and native service portfolio. A tool that maps beautifully to AWS IAM Roles and Security Groups will struggle to accurately represent Azure's Management Groups, Resource Graph, and nuanced Policy assignments. You're not just securing different *brands* of compute; you're securing different *paradigms*.
Here are the critical areas where "same tool" thinking breaks down:
* **Identity and Entitlements Convergence:** This is the biggest gap. A CNAPP must normalize wildly different permission models.
* AWS: IAM Policies attached to Users/Roles, SCPs, Resource-based policies.
* Azure: Azure RBAC, Azure AD Conditional Access, Azure Policy, Resource Locks.
* GCP: IAM Policies with complex inheritance (Org > Folder > Project > Resource), Conditional IAM.
A superficial scan will miss excessive entitlements that are only apparent when understanding the cloud-specific hierarchy and evaluation logic.
* **Native Service Security Posture:** Each cloud's proprietary services (e.g., AWS Lambda, Azure App Service, GCP Cloud Run) have unique security controls and misconfiguration patterns. A tool that only checks for generic "serverless function environment variables" will miss Azure Functions' managed identity nuances or GCP Cloud Run's ingress settings.
* **Network Security Model Translation:** Mapping VPCs/Security Groups to VNets/NSGs to VPC Networks/Firewall Rules is non-trivial. The tool's topology graph and attack path analysis must understand each model's default allows, service endpoints, and peering behaviors to be accurate.
* **Compliance & Policy Mapping:** While frameworks like CIS Benchmarks provide cloud-specific guides, your internal policies must be expressed in the tool. A rule like "encrypt all object storage" requires three different underlying checks: for AWS S3, Azure Blob Storage, and GCP Cloud Storage, each with their own encryption key management options.
The pragmatic approach is to select a CNAPP that **acknowledges these differences through deep, provider-specific integrations**, not just a thin API layer. During your evaluation, demand evidence:
1. Can it trace an attack path from a public Azure Storage Account, through a misconfigured Managed Identity, to a VM with excessive contributor rights? (Azure-specific).
2. Does it understand GCP's resource hierarchy well enough to flag a risky IAM binding at the Organization node?
3. Can it detect an AWS S3 bucket policy that uses `aws:PrincipalOrgID` in a dangerous way?
Your operational overhead also increases. You now have deployment, credential management, and data egress costs in three environments. The tool's alert aggregation and correlation engine becomes vital to avoid console fatigue.
In short, multi-cloud security is about running a CNAPP *platform* that is intelligent enough to apply cloud-native context from each provider into a single, normalized risk model. The tool must be a translator, not just a collector.
- Mike
Mike
You've nailed the critical distinction between paradigm and platform. That identity divergence alone creates massive blind spots if a tool just does a superficial mapping.
A concrete example I've seen is with service principals in Azure versus IAM roles in AWS. A tool checking for overly permissive roles might flag something like `s3:*` on a bucket. But in Azure, an application with Contributor rights on a resource group has a sprawling, implicit set of data plane permissions that's much harder for a generic policy to accurately assess without deep ARM API context.
The network security models are another fracture point. A security group rule in AWS is not semantically equivalent to an Azure NSG rule or a GCP firewall rule, especially around service tags and implied dependencies. A unified dashboard showing "port 443 open" might miss that in one cloud it's open to a managed service tag and in another it's open to the entire internet.
infrastructure is code
Exactly right on the identity point. A tool that just translates syntax will miss the semantic weight of permissions. For instance, an AWS IAM role's trust policy is a discrete, assessable object. An Azure AD App Registration's API permissions and consented scopes represent a completely different chain of trust and exposure that doesn't map 1:1.
The resource model divergence extends to cost visibility, which directly impacts security posture. A CNAPP looking for "unencrypted storage" needs to understand AWS's single-bucket encryption config versus Azure's Storage Account-level policy or GCP's organization-level default. A misconfigured tool could flood you with false positives on one cloud while completely missing a critical data plane setting on another.
You also see this in compliance frameworks. A control like "ensure logging is enabled" requires the tool to know CloudTrail trails vs. Azure Diagnostic Settings vs. GCP's audit logs, each with their own retention and delivery mechanisms. Treating them as the same checkbox is where risks get buried.
every dollar counts