MCFS : Empowering Governments with Secure Cloud Innovation

MCFS : Empowering Governments with Secure Cloud Innovation

A few days ago, Microsoft announced the public preview of the Microsoft Cloud for Sovereignty, a cloud offering designed to assist governments in meeting their compliance, security, and policy requirements while harnessing the power of the cloud to deliver value to their citizens. Let’s take a closer look at this preview.

Public cloud for governments

Historically, government customers faced challenges in their digital transformation efforts due to the need for controls 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 architecture principles as the ELZ, separating the Platform design area from the Application one. The SLZ is developed using Bicep and PowerShell. In version 0.3.0 preview, it 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 few workload examples in this repository. For the application design area, the SLZ simply creates two dedicated management groups where to deploy confidential application workloads (confidential corp and confidential online) and defines the guardrails to be applied to those groups to ensure compliance and security.

Let’s deploy the Sovereign Landing Zone

1️⃣Prerequisites

The SLZ automation comes in a form of PowerShell scripts. To make sure you get a seamless deployment experience Microsoft provide a script to check prerequisites (Confirm-SovereignLandingZonePrerequisites.ps1). The script worked as 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 options 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 to the EA, MCA or MPA account to provision subscriptions according to the landing zone vending principles.
• Because I skipped the bootstrap command and I had to manually create the management group hierarchy (see image below).
• I run the script as 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 where 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, … are created in the network resource group.
• no spokes are created neither for identity nor management.

In the image below 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 a 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 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 a two of initiatives to target specific regulations for Italy and 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 at this link. The SLZ 0.3.0 by default deploys the NIST SP 800-53 Rev. 5 initiative, more details 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 to extend 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, 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 problem and evaluate whether an exemption is needed.

6️⃣ Exemption

This command exempt all the non compliant policies. I believe exemption is a process that should be done thoughtfully and with consideration for your organization’s specific compliance requirements. A 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 a 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:

• The version 0.3.0 do not support the freshly announced North Italy region and it’s a pity because MCFS and the new italian region has been announced the same day.
• Locks. The SLZ v0.3.0 do not implement resource locks nor 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 legislations are slowly opening to public cloud and that Microsoft is firmly committed to helping those governments with smart solutions that ensure they meet rules, stay secure, and follow policies effectively. The sovereign landing zone is a first important step to build confidential solutions where we can run trusted workload in a secure and compliant environment.

 Photo by Guillaume Périgois on Unsplash