Address plan
One IP address plan for every cloud and site, with no overlapping ranges, so networks can be joined later without renumbering.
Multi-cloud security architecture
If your systems run in more than one cloud, every control has to work in each of them. We set up identity, networking, guardrails, keys and audit logging the same way across AWS, Azure and Google Cloud, in Terraform.
That includes each provider’s government offering: AWS GovCloud (US), Azure Government and Google Cloud Assured Workloads.
Who owns which control
AWS, Azure and Google Cloud divide the controls the same way. The provider covers some, shares some with you and leaves the rest to you.
Authorization boundary
Your application
- AC-2Account management
- IA-2(1)MFA for privileged accounts
Cloud platform
- SC-7Boundary protection
- SC-28Protection of information at rest
Provider’s data centers
- PE-3Physical access control
- PE-6Monitoring physical access
First, the boundary
Everything inside the boundary gets assessed, documented and evidenced, so we agree on it before anything else. FISMA calls it the authorization boundary; CMMC calls it the assessment scope.
What your provider covers
Physical security of the data center is the usual example. Where your cloud provider’s own assessment covers a control, your SSP records it as inherited.
What you share with the provider
The provider secures the platform and you configure it. Their customer responsibility matrix says which part of each control is yours.
What is yours
Accounts, application settings and how data is handled stay with you, even on a FedRAMP-certified service. Assessors test them directly.
Equivalent services in AWS, Azure and Google Cloud
| Component | AWS | Azure | Google Cloud |
|---|---|---|---|
| Organization guardrails | AWS Organizations service control policies | Azure Policy at management-group scope | Organization Policy Service |
| Workforce sign-in | AWS IAM Identity Center | Microsoft Entra ID | Cloud Identity or Workforce Identity Federation |
| Workload identity across clouds | IAM Roles Anywhere and OIDC federation | Microsoft Entra Workload ID federated credentials | Workload Identity Federation |
| Keys | AWS KMS | Azure Key Vault and Managed HSM | Cloud KMS and Cloud HSM |
| Audit logs | CloudTrail organization trail | Activity log and Entra logs, exported by diagnostic settings | Cloud Audit Logs with aggregated sinks |
| Posture | AWS Security Hub CSPM | Microsoft Defender for Cloud | Security Command Center |
Networking across the three clouds
Boundary protection has its own control in each catalog: SC-7 in SP 800-53, and 3.13.1 in SP 800-171 for CUI. In a multi-cloud system the boundary runs through three providers’ networks and the links between them.
| Component | AWS | Azure | Google Cloud |
|---|---|---|---|
| Private network | Amazon VPC | Azure Virtual Network | VPC network |
| Hub routing | AWS Transit Gateway | Azure Virtual WAN or a hub virtual network | Network Connectivity Center |
| Firewall | AWS Network Firewall | Azure Firewall | Cloud Next Generation Firewall |
| Private access to cloud services | AWS PrivateLink | Azure Private Link | Private Service Connect |
| Private DNS | Amazon Route 53 Resolver | Azure DNS Private Resolver | Cloud DNS private zones |
| Links to your sites | AWS Direct Connect | Azure ExpressRoute | Cloud Interconnect |
Hub and spoke
Each cloud has a hub that holds the firewall and the shared services. Workloads sit in spokes with no direct route to the internet, and traffic between spokes passes the firewall.
SP 800-53 SC-7 and AC-4; SP 800-171 3.13.1 and 3.13.5
Private paths
Workloads reach cloud services through private endpoints instead of public addresses. Traffic between clouds and to your offices is encrypted, over a private interconnect where the provider offers one for your regions and over IPsec VPN where it does not.
SP 800-53 SC-8; SP 800-171 3.13.8
Outbound traffic
Traffic leaving a cloud is checked at its firewall against an allow list. Anything not on the list is denied, and the firewall logs every decision to the SIEM.
SP 800-53 SC-7(5); SP 800-171 3.13.6
The three providers
| Provider | Commercial | Government | Reviewed against | We configure |
|---|---|---|---|---|
| Amazon Web Services | AWS US East/West | AWS GovCloud (US) | AWS Well-Architected Framework | AWS Control Tower guardrails, IAM |
| Microsoft Azure | Azure Commercial | Azure Government | Azure Well-Architected Framework and Cloud Adoption Framework | Conditional Access, Defender for Cloud, Key Vault, Azure Firewall |
| Google Cloud | Google Cloud commercial regions | Assured Workloads | Google Cloud Well-Architected Framework | VPC Service Controls, CMEK, Cloud Armor, Security Command Center |
What we set up and review in each cloud
Sign-in
Staff sign in to all three clouds through one identity provider, with the same MFA rules, and leavers lose access everywhere at once. Workloads that call another cloud use workload identity federation, which keeps long-lived access keys out of pipelines and config files.
Guardrails
Rules such as allowed regions, required encryption and no public storage buckets live in one Terraform repository, and each provider enforces them through its own policy service.
- Terraform modules
- Guardrails, identity, networking and logging for each provider. Your team owns them after handover.
Audit logs
Logs from every AWS account, Azure subscription and Google Cloud project go to one SIEM and are kept as long as your program requires. Azure drops activity log events after 90 days unless they are exported, so we export them.
Well-Architected review
We review each workload against its provider’s Well-Architected framework and rank the findings by risk, with an owner for each.
Control mapping
We map every setting to the NIST SP 800-53 control it meets and the service that enforces it, so one SSP can cover all three clouds.
- Control matrix
- Control, provider, service and the evidence that shows it working.