Skip to content

Commit 98d44fb

Browse files
kayrogkayrog
authored
Merge pull request #109 from cabinetoffice/DH-91
adding azure policy guidance
2 parents 5c7795b + 7d055d6 commit 98d44fb

2 files changed

Lines changed: 188 additions & 0 deletions

File tree

‎source/docs/cloud/azure-cloud/azure-cloud-platform-guidance.html.md.erb‎

Lines changed: 181 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,181 @@
1+
---
2+
title: Azure Cloud Platform Guidance
3+
last_reviewed_on: 2026-05-14
4+
review_in: 12 months
5+
---
6+
7+
# <%= current_page.data.title %>
8+
9+
This guidance explains how the Cabinet Office uses Microsoft Azure to host digital services and analytics platforms. This includes services at the OFFICIAL classification and those with the OFFICIAL-SENSITIVE handling caveat.
10+
11+
## Strategic intent
12+
13+
The Cabinet Office uses a diversified cloud approach to avoid vendor lock-in. While we use AWS as a strategic platform, Azure is the preferred choice for:
14+
15+
* Systems integrated with the Microsoft ecosystem, such as M365 and SharePoint
16+
* Enterprise-wide analytics and business intelligence through Microsoft Fabric and Power BI
17+
* Resilience and disaster recovery as a second strategic cloud provider
18+
19+
20+
## **Azure landing zone**
21+
22+
The Cabinet Office Azure environment uses a structured, scalable foundation built with Infrastructure as Code (Terraform). This foundation is called the Azure landing zone (ALZ). All workloads inherit central governance, connectivity, and security guardrails from this foundation.
23+
24+
### **Organisational structure**
25+
26+
The Cabinet Office Azure tenant (codigitalcloud.onmicrosoft.com) uses management groups to apply policies and governance controls.
27+
28+
### **Management group hierarchy**
29+
30+
All subscriptions are placed in a hierarchy to ensure they inherit the correct policies:
31+
32+
* Root: the top-level container for centrally managed policies and roles
33+
* Landing zones: subscriptions for application workloads
34+
* Corp: internal applications like learning platforms and internal APIs
35+
* Online: external applications and APIs that need strict network controls
36+
* Sandbox: short-lived experiments and prototypes that do not use live data
37+
* Quarantine: isolated subscriptions under investigation for security concerns
38+
* Decommissioned: retired workloads waiting for deletion
39+
40+
41+
### **Network topology**
42+
43+
The platform uses a dual-region hub-and-spoke topology. This includes redundant hub virtual networks (VNets) in the UK South and UK West regions.
44+
45+
* Hub VNets: Host the Azure firewall for packet inspection and egress filtering.
46+
* Spoke VNets: each workload has its own spoke peered to the central hubs. This ensures central security rules govern all traffic.
47+
48+
## **Regional strategy**
49+
50+
To comply with UK data residency policies, the Cabinet Office uses specific hosting regions:
51+
52+
* UK South (Primary): hosts all active workloads and availability zones
53+
* UK West (Secondary): used for failover and additional hosting
54+
55+
If you encounter resource limits in UK South, you can use UK West as a primary hosting option. UK South and UK West are paired regions. If UK South fails, data remains available in UK West if you use geo-redundant storage (GRS).
56+
57+
## **How to request Azure services and support**
58+
59+
Use the Cabinet Office Digital One-Stop Shop portal to request Azure resources, subscriptions, user management, or technical support.
60+
61+
[Azure Service Request Form](https://digital-one-stop-shop.cabinetoffice.gov.uk/a/catalog/request-items/192)
62+
63+
To request a new subscription, you must provide:
64+
65+
* business unit (for example, Cabinet Office Digital)
66+
* subscription name (use a clear, lowercase identifier)
67+
* environment type (sandbox, dev, or production)
68+
* cost codes (both parent and child cost centre codes)
69+
* technical lead (the person responsible for the architecture)
70+
71+
If the team needs more information, they will contact you through the One-Stop Shop ticket.
72+
73+
## **Access levels and permissions**
74+
75+
The Cabinet Office enforces the principle of least privilege to maintain security.
76+
77+
### **Contributor access**
78+
79+
By default, new users of sandbox and dev subscriptions receive contributor permissions. This allows you to create and manage Azure resources. It does not allow you to assign roles or manage service principals.
80+
81+
### **Requesting owner access**
82+
83+
Granting owner access is a deviation from standard security policy. If you need owner permissions, you must submit a request through the One-Stop Shop. You must include:
84+
85+
* the specific individuals who need access
86+
* a technical justification explaining why contributor access is not enough
87+
* the duration for which you need elevated access
88+
89+
The platform engineering and cyber security teams will need to review all requests for owner access.
90+
91+
## **Regional access and governance**
92+
93+
You must get formal approval to use Azure regions outside of UK South and UK West. Hosting data outside the UK introduces risks to data sovereignty and legal compliance under UK GDPR.
94+
95+
### **Process for regional deviation**
96+
97+
To request a new region, you must complete these actions:
98+
99+
1. Data protection impact assessment (DPIA): most workloads involve Official-Sensitive data, making a DPIA a legal requirement. Complete the form on the DPIA intranet page.
100+
2. Information assurance (IA): The IA team will review the risks of hosting data in non-UK regions. More information about this process can be found on the Cabinet Office Intranet.
101+
3. Technical design authority (TDA): You can email the TDA with a project description. The TDA must approve any design that deviates from approved hosting locations. More information about this process can be found on the Cabinet Office Intranet.
102+
103+
Provide evidence of any prior technical or financial approvals to streamline the review. You must state if the data belongs to the Cabinet Office or a third party. You may raise a request via the [One Stop Shop Form](https://digital-one-stop-shop.cabinetoffice.gov.uk/a/catalog/request-items/192) if you require more details on the process.
104+
105+
## **Engineering standards**
106+
107+
Service teams must manage Azure infrastructure using Infrastructure as Code (IaC). Use Terraform and Terragrunt as the primary tools.
108+
109+
### **Using the Cabinet Office GitHub repository**
110+
111+
Store all code for Cabinet Office workloads in the official Cabinet Office GitHub organisation. You can request an account or a new repository through the GitHub access request form.
112+
113+
[GitHub Access Request Form](https://digital-one-stop-shop.cabinetoffice.gov.uk/a/catalog/request-items/96)
114+
115+
### **Why you must use IaC**
116+
117+
You must not manually create resources in the Azure portal for production-track workloads. IaC is required for:
118+
119+
* Reproducibility: ensures environments are identical and can be rebuilt if they fail
120+
* Auditability: GitHub provides a version history of all changes
121+
* Security: automated pipelines allow for security scanning before resources are created
122+
* Disaster recovery: allows for rapid deployment to a secondary region during an outage
123+
124+
125+
## **Managing secrets with Azure Key Vault**
126+
127+
You must store all sensitive information in Azure Key Vault. This includes passwords, connection strings, API keys, and SSL certificates. Do not hard-code secrets into source code or configuration files.
128+
129+
### **Why you must use Key Vault**
130+
131+
Using a centralised vault is mandatory for all workloads to:
132+
133+
* prevent secret leakage: Key Vault allows infrastructure to fetch secrets at runtime
134+
* centralise management: provides a single location to manage the lifecycle of certificates and keys
135+
* improve auditability: the system logs every access request to a secret
136+
* ensure security by design: vaults are automatically configured to capture diagnostic logs
137+
138+
### **Implementation standards**
139+
140+
* Integration: use Terraform to provision Key Vaults and manage access policies. Use managed identities to retrieve secrets.
141+
* No manual overrides: do not add secrets manually through the Azure portal.
142+
* Zero standing access: use privileged identity management (PIM) to control access to secrets.
143+
144+
Request guidance on integrating Key Vault with your pipeline through the One-Stop Shop.
145+
146+
## **Logging, monitoring, and the SOC**
147+
148+
The platform ensures every workload is visible to central security teams.
149+
150+
### **The centralised logging pipeline**
151+
152+
All diagnostic logs follow a specific path:
153+
154+
1. Spoke collection: we capture logs from your subscription resources.
155+
2. Hub log analytics workspace: logs stream to a central workspace in the hub subscription.
156+
3. Stream: logs are filtered to reduce costs and formatted into a standard schema.
157+
4. Destination: the final destination for security telemetry.
158+
159+
### **Security operations centre (SOC)**
160+
161+
The cyber security team uses tools to:
162+
163+
* monitor the Azure estate
164+
* respond to incidents by detecting irregular behaviour or configuration changes
165+
* generate automated alerts for security breaches
166+
167+
### **Monitoring responsibilities**
168+
169+
Monitoring is a shared responsibility:
170+
171+
* Platform engineering (COPE): manages the Azure hub & log analytics workspace.
172+
* Cyber security team: operates the tools used for monitoring outside of Azure and defines security policies.
173+
* Service team: monitors the performance and health of your specific application. You must ensure your service meets its operational service level agreements (SLAs).
174+
175+
## **Policies**
176+
177+
For more information, see:
178+
179+
* [Azure sandbox policy](https://digital-handbook.cabinetoffice.gov.uk/docs/cloud/general/sandbox-policy.html)
180+
* [Azure recharge policy](https://digital-handbook.cabinetoffice.gov.uk/docs/cloud/recharge-policies/azure-recharge-policy.html)
181+

‎source/partials/_nav-cloud.html.erb‎

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -9,6 +9,13 @@
99
</ul>
1010
</li>
1111

12+
<ul>
13+
<li>
14+
<strong>Azure</strong>
15+
<ul>
16+
<li><a href="/docs/cloud/azure-cloud/azure-cloud-platform-guidance.html">Azure cloud platform guidance </a></li>
17+
18+
1219
<li>
1320
<strong>Cloud recharge policies</strong>
1421
<ul>

0 commit comments

Comments
 (0)