Public cloud for governments
Historically, government customers have faced challenges in their digital transformation efforts due to the many different controls needed to meet specific national and regional requirements. This legacy approach incurred heavy capital and operational costs associated with owning and operating data centers. However, evolving policy decisions have provided legal support for government adoption of hyperscale cloud computing within the EU.
The Microsoft Cloud for Sovereignty provides a repeatable best-practice approach that assists in achieving complex regulatory compliance. It incorporates industry-leading data sovereignty and encryption controls, enabling governments to create solutions tailored to regional and national requirements.
What does this mean technically?
With this public preview, Microsoft has released a set of accelerators that can be seamlessly integrated into a public cloud environment:
🔒 A sovereign landing zone (SLZ). Based on the ELZ design principles, the SLZ enables the creation of a cloud environment where security and data sovereignty controls can be enforced by policies.
🔒 A set of initiatives to target specific regulations for Italy (ACN) and Netherlands (BIO). You can find the two initiatives in this GitHub repository.
🔒 A set of templates to deploy confidential workloads in the sovereign landing zone
Opening the Sovereign Landing Zone box
The SLZ follows the same architectural principles as the ELZ, separating the Platform design area from the Application one. The SLZ is developed using Bicep and PowerShell. The version 0.3.0 preview includes:
- The automation scripts to configure the management group hierarchy along with the networking (hub&spoke) and management part (log analytics and solutions).
- Scripts for rolling out policies and initiatives, along with automatic remediation.
- A compliancy dashboard.
Note: The application landing zone (workload-generic services) is not part of the SLZ. You can find a few workload examples in this repository. For the application design area, the SLZ simply creates two dedicated management groups where confidential application workloads (confidential corp and confidential online) can be deployed, and guardrails to be applied to those groups to ensure compliance and security can be defined.
Let's deploy the Sovereign Landing Zone
1️⃣Prerequisites
The SLZ automation comes in the form of PowerShell scripts. To make sure you get a seamless deployment experience, Microsoft provides a script to check prerequisites (Confirm-SovereignLandingZonePrerequisites.ps1). The script worked like a charm for me; it checks your machine configuration and returns the component list to be updated along with the command to be executed to meet the prerequisites. In my case, I updated the bicep version and I was good to go.
2️⃣ Orchestrator script
The orchestrator script (New-SovereignLandingZone.ps1) gives you the option to execute the full deployment with a single command or to specify which step to perform.
With this exercise, I wanted to deploy the SLZ on a single subscription for test purposes. Therefore:
- I didn’t use the ‘all-in-one’ command because the first step (bootstrap) requires a billing scope associated with the EA, MCA, or MPA account to provision subscriptions according to the landing zone vending principles.
- I skipped the bootstrap command, so had to manually create the management group hierarchy (see image below).
- I ran the script as a Global Administrator. For more details about the required permissions, check out the official documentation.
- I disabled the Firewall and the DDoS to keep the cost under control ( parEnableFirewall and parDeployDdosProtection parameters).
3️⃣ Platform
Once you’ve established your management group hierarchy, the next step is to proceed with the platform. Make sure to edit the parameter file to specify the subscription IDs on which to deploy the Platform services. Run the “.\New-SovereignLandingZone.ps1 platform” command to create the services that belong to the identity, management, and connectivity working areas.
As result:
- Three resource groups are created, one per design area.
- The VNET, along with the firewall, route tables, DNS, etc. are created in the network resource group.
- No spokes are created, either for identity or management.
The image below shows an overview of the RGs, deployments, and the resources created in the networking RG.
4️⃣ Compliance
The core component of the SLZ: a set of initiatives and policies to strengthen up your cloud environment. SLZ manages four types of guardrails: baseline, alz default, policy portfolio, and custom policies.
The baseline is meant to enhance the security control frameworks already employed by customers in Azure. These Azure policies are organized into three sovereignty control objectives (data residency, confidential computing, and key management). However, it’s important to note that the baseline isn’t a replacement for a security control framework but it is a starting point that goes beyond what traditional control frameworks typically demand. Two initiatives are included in the SLZ baseline: SLZ Global Policies v0.3.0 and SLZ Confidential Policies v0.3.0 for a total of 20 policies. Few parameters can be configured as described here.
If you enable the “parDeployAlzDefaultPolicies” setting to true, the ALZ default initiatives will be deployed at the root level, specifically within the “mcfs” management group. In the following image, you can see the two SLZ baseline initiatives alongside the twelve ALZ default initiatives.
Assignments are created at different MG scopes. For example, in the following picture we can see the confidential policies initiative applied to two confidential management groups.
The policy portfolio repo currently contains two of initiatives to target specific regulations for Italy and The Netherlands. Before assigning one of those initiatives, you first need to create the policy definitions in the top-level or parent management group for the SLZ Preview. To assign the newly created initiatives (or any built-in policy initiatives), edit the “parCustomerPolicySets” parameter in the sovereignLandingZone.parameters.json file.
You can find the list of built-in regulatory compliance here. The SLZ 0.3.0 by default deploys the NIST SP 800-53 Rev. 5 initiative. More details on this here.
Lastly, you can deploy and assign your own custom policies with the SLZ orchestration by adding the policy definitions along with their parameters to the definition templates, as described here. For example, you might consider extending the ‘Enforce-EncryptTransit’ initiative to add a policy to force HTTPS for API Management services.
5️⃣ Remediation
It’s pretty straightforward. Just a single command, with no parameters. The scripts identify the non-compliant objects and run the remediations. When the remediation does not bring the desired compliancy, it’s necessary to analyze the why behind the problem and evaluate whether an exemption is needed.
6️⃣ Exemption
This command exempts all non-compliant policies. I believe exemption is a process that should be made thoughtfully and with consideration for your organization’s specific compliance requirements. Strict documentation of the reasons for policy exemptions and approval workflow is a must.
7️⃣ Dashboard
This final step creates a resource group and deploys an Azure dashboard that visualizes a set of Azure graph queries to follow up the compliancy of your environment.
Once you get a secure foundation set right together with robust governance and monitoring, the more intricate task of safeguarding data in active use begins. However, that’s a topic for another day.
Wish list
It’s great to see such an easy-to-use landing zone, and I’m sure that many things will be added in the coming months, especially in the form of support for new regulations. From a more technical standpoint, here a couple of things I’d love to see integrated:
- Version 0.3.0 does not support the newly announced North Italy region, which is a pity as MCFS and the new Italian region were announced on the same day.
- Locks. The SLZ v0.3.0 does not implement resource locks, or the freshly GAed DenyAction effect for policies.
- I’d love to see used deployment stack ( New-AzManagmentGroupDeploymentStack ) instead of the classic deployments ( New-AzManagementGroupDeployment).
Conclusion
In summary, it’s a pleasure to see that legislation is slowly opening to the public cloud and that Microsoft is committed to helping governments with smart solutions to ensure that rules are met, security is ensured, and policies are followed efficiently. The sovereign landing zone is the first important step to build confidential solutions where we can run trusted workloads in a secure and compliant environment.
Subscribe to our RSS feed