Multi-cloud security: NSA's ten mitigation strategies applied across providers
Each cloud has its own identity system, logs and defaults. Securing several at once comes down to applying one set of rules everywhere, and the NSA has published a good starting list.
Running workloads in more than one cloud multiplies the security work. AWS, Azure and Google Cloud each have different identity models, policy languages, logging services and default settings. A control set up carefully in one is often missing in the other.
In March 2024, the NSA, with CISA on most items, published ten cloud security mitigation strategies. One of them addresses hybrid and multi-cloud complexity directly, but all ten work as a checklist to apply across every provider.
The ten strategies, applied across clouds
| NSA strategy | What it means in a multi-cloud setup |
|---|---|
| Uphold the shared responsibility model | Write down which controls you own in each provider and service |
| Use secure identity and access management | One identity provider with single sign-on into every cloud, no local admin users |
| Use secure key management | Consistent rules for who controls encryption keys in each cloud |
| Segment networks and encrypt data in transit | Same segmentation design and encryption standard everywhere |
| Secure data in the cloud | Block public storage by default in every account |
| Defend CI/CD environments | Pipelines that deploy to any cloud are protected as production systems |
| Use infrastructure as code | Define resources in code so policies can be checked before deployment |
| Mitigate hybrid and multi-cloud complexity | Central visibility and policy across providers |
| Mitigate risks from managed service providers | Review and limit MSP access in every environment |
| Manage cloud logs for threat hunting | Send logs from all clouds to one SIEM with consistent retention |
The three controls that matter most
Identity first. A single identity provider, with conditional access and phishing-resistant MFA, gives one place to grant and remove access to every cloud. Cloud-native users created inside each provider are the gaps attackers find.
Policy as code second. Infrastructure as code lets you check every deployment against the same rules, such as no public buckets, encryption on and required tags, before it reaches any cloud.
Central logging third. Each provider's audit logs, such as AWS CloudTrail, Azure Activity Log and Google Cloud Audit Logs, need to land in one place where they can be searched together. An attacker moving between clouds is invisible if each provider's logs are reviewed separately.
Tools
Cloud security posture management and cloud-native application protection platforms scan all providers against one benchmark and flag drift. They help, but only after identity, policy and logging foundations are in place.
What IT teams should do
- Remove local admin users in each cloud and route all access through one identity provider.
- Write a short shared responsibility matrix for every cloud service you use.
- Enforce the same baseline policies in infrastructure-as-code checks for every provider.
- Send audit logs from all clouds to one SIEM and test a cross-cloud search.