Implement controls and principles in SLZ

As outlined in Controls and principles in Sovereign Public Cloud, Azure Policy is a key tool to help your organization implement sovereignty controls across your Azure environment. However, to effectively manage and apply these policies at scale, you need a well-structured hierarchy that uses Management Groups. The Sovereign Landing Zone (SLZ) reference architecture provides a predefined hierarchy, recommended policies, and the scope to apply them, all built on top of the Azure landing zone reference architecture.

This article describes how to implement the controls and principles outlined in the previous article by using Azure management groups and policies in the context of the Sovereign Landing Zone (SLZ). The following diagram shows the SLZ reference architecture's Management Group hierarchy with the associated controls and principles. These controls and principles translate to various Azure Policy assignments, initiatives, and definitions, and the scope at which you should apply them against the reference architecture.

lightbox="media/sovereign-landing-zone-policy-controls.svg":::

Sovereign landing zone conceptual architecture's Management Group hierarchy with the associated controls and principles applied. Download a Visio file or PDF file of this architecture.

Management Group hierarchy in SLZ

The following sections provide more detail on the management group hierarchy and the recommended controls to apply at each level.

Platform

Use the platform management groups to centralize services such as connectivity, environment management, key management, and more. Because the platform services support sovereign workloads, they must also adhere to sovereignty and security controls. For example, if confidential workloads use identity services hosted in the identity subscription, those services should also use confidential computing to help ensure integrity. Therefore, most services under the platform management group require Level‑1 (data residency), Level‑2 (encryption-at-rest and in-transit), and—where possible—Level‑3 (confidential computing).

Within the platform landing zone, services are hosted in different subscriptions under different management groups. This structure allows different centralized IT teams to manage these services and apply specific policies. This approach aligns with the reference architecture for Azure landing zones, with the addition of the Security management group (and subscription). Add this subscription specifically to address the components that make up the sovereign services, such as the Managed HSM instance hosting all service encryption keys.

Landing zones

The Azure landing zone architecture categorizes workloads into online and corp workloads based on their networking architecture, as detailed in Network topology and connectivity. This segregation distinguishes workloads that require direct internet access from corporate applications that are hosted only on internal networks. This management group layout is especially useful for organizations that run online services alongside corporate workloads and where data classification isn't immediately apparent.

In the Sovereign Landing Zone reference architecture, three additional management groups support the various sovereign policies: Public, Confidential Online, and Confidential Corp. These management groups help segregate workloads based on their data classification and the required sovereignty controls for each classification. The following table summarizes the management groups, their parent management group, the data classification they support and host, and the recommended controls to apply based on Controls and principles in Sovereign Public Cloud.

Public

Because most sovereign controls apply to business workloads, the Public management group hosts publicly available information. Publicly available information shouldn't be restricted by sovereign controls such as data residency or encryption at rest or in use, which is why this management group has only standard security policies. While services hosted in this management group are less restricted, don't allow any private network connectivity from these workloads into the Online/Corp and Confidential Online/Confidential Corp services. Any required communication should follow a zero-trust principle. In some cases, it might be possible to use private endpoints from services hosted in these management groups to make them available to Public management group–hosted applications. Otherwise, API calls to workloads in Online and Confidential Online are also possible. These network restrictions help ensure full isolation between sovereign and highly controlled workloads and publicly available services.

Online / Confidential Online

You can host services that require end users to sign in from the internet in subscriptions in the Online and Confidential Online management groups. These services can also have corporate network access. However, no unauthenticated network traffic should traverse these networks (zero‑trust principle). Given the various data classifications these applications handle, use Level 1 (data residency) and Level 2 (encryption-at-rest and in-transit) controls alongside the default Azure landing zone policies, while Confidential Online workloads also implement Level 3 (encryption in use) controls.

Corp / Confidential Corp

Use Corp and Confidential Corp workloads for internal users or systems only. They aren't published directly to the internet and have tightly controlled networking policies. Standard security policies from the secure landing zone framework regarding the use of public IPs and routing are applicable. From a sovereignty perspective, Online and Corp share Level 1 (data residency) and Level 2 (encryption-at-rest and in-transit) controls; Confidential Corp adds Level 3 (encryption-in-use).

Data classification management groups (alternative approach)

You can also change the default Sovereign Landing Zone architecture. By representing the data classifications in the management group structure, you can deviate from the default Management Groups, beneath Landing Zones, to instead align to your organization's data classification model, following the guidance in Tailor the Azure landing zone architecture to meet requirements.

In this model, you apply the policies at the Management Group scope to monitor compliance across all workloads of a particular data classification. You can also remove the corp and online management groups if your organization doesn't need these management groups in relation to network access controls, as described in Network topology and connectivity.

Summary

Sovereign controls are layered on top of existing or newly deployed Azure landing zones or Sovereign landing zones. You can apply them to various data or workload classifications together with other compliance initiatives. The Sovereign landing zone reference architecture provides a recommended hierarchy, but you should determine whether this layout is applicable or if adaptations are required as per the tailoring guidance in Tailor the Azure landing zone architecture to meet requirements.

Next steps

• Sovereign Landing Zone (SLZ) implementation options
• FAQs for Sovereign Landing Zone