Contents

1          Introduction   5

1.1        Overview.. 5

1.2        Design Documents. 5

1.3        Design Scope. 6

1.4        Target Audience. 6

1.5        Constraints and Assumptions. 6

1.6        Document Conventions. 7

1.7        Terminology / Glossary. 8

2          Commercials   9

2.1        Azure. 9

2.2        Microsoft Entra ID.. 9

3          Tenant Structure   11

3.1        Landscapes and Environments. 11

3.2        Azure Hierarchy Overview.. 12

3.3        Microsoft Entra Tenant. 13

3.4        Azure Regions. 14

3.5        Management Groups. 14

3.6        Subscriptions. 16

3.7        Resource Groups. 19

3.8        Resource Summary. 21

4          Identity and Access Management  26

4.1        Overview.. 26

4.2        Break Glass Accounts. 26

4.3        Multifactor Authentication (MFA) 27

4.4        Role Based Access Control 28

4.5        Microsoft Entra Groups. 30

5          Governance   36

5.1        Naming Standards. 36

5.2        Resource Locks. 37

5.3        Resource Tagging.. 38

5.4        Azure Policy. 39

5.5        Cost Management. 48

6          Networking   49

6.1        Overview.. 49

6.2        Network Use Cases. 49

6.3        IP Address Allocation.. 49

6.4        Azure Virtual WAN.. 50

6.5        Virtual Networks. 53

6.6        Hybrid Connectivity. 57

6.7        Domain Name Services. 59

6.8        Route Management. 61

6.9        Network Security. 66

7          Security   77

7.1        Secret Management. 77

7.2        Microsoft Defender for Cloud.. 78

8          Management  82

8.1        Monitoring and Alerting.. 82

8.2        Backup.. 90

8.3        Azure Update Manager. 93

Introduction

Overview

For SCXX to achieve a successful cloud adoption, it is vital to set in place a solid foundation to support both traditional Infrastructure as a Service (IaaS) and cloud native services (PaaS) in a secure, well governed, and manageable Enterprise Landing Zone.

Aligned to Microsoft’s Cloud Adoption Framework, The solution detailed within this design document will meet the initial business requirements of SCXX for supporting the deployment of the Azure VMware Solution (AVS) as well as provide an environment ready for future adoption of Azure cloud native services.

Design Documents

This section details the various documents that are produced within the Zone design phase of the engagement, including:

• Solution Design
• Naming Standards

Solution Design (this document)

The purpose of this design document is to capture and present decisions made during design workshops between LAB³ and SCXX to provide a comprehensive guide for the design and deployment of SCXX’s Azure Landing Zone.

It will detail the platform design, constraints, and dependencies, as well as provide detailed descriptions of the components that comprise the solution in addition to any agreed exclusions or action items needing to be performed by SCXX.

Acceptance of this design document by SCXX is a pre-requisite to commencing build.

The naming standards document covers the default standards that will be used for SCXX’s Azure Landing Zone.

Related Documents Register

Table 1.2‑1 – Related Documents

Design Scope

The scope of this design is limited to the Azure Landing Zone deployment into a SCXX Azure Tenancy. It reflects the Statement of Work [Cloud Marketplace SA-LAYYY ALZ-AVS Migration and Intune Deployment (CLT-SOW-5265) Final Fully Executed] and will cover:

• Azure Commercials
• Structure
• Identity Management
• Governance
• Networking
• Security
• Management (Operational)

Out of scope

The following are out of the scope of this design:

• Non-Azure networking design
• Workload Migration and existing Infrastructure Services
• SCXX provided Network Virtual Appliances (NVA) – such as Meraki, Palo Alto, Checkpoint etc
• Integration to SIEM/SOAR and ITSM platforms
• Configuration of ExpressRoute and/or on-premises VPN devices (Express Route will be implemented under a separate stream)
• Anything not specifically denoted as in-scope within this document or the binding Statement of Work Cloud Marketplace SA-LAYYY ALZ-AVS Migration and Intune Deployment (CLT-SOW-5265) Final Fully Executed

Target Audience

The target audience includes:

• [Company] Solution Consultants and Engineers
• SCXXkey stakeholders
• SCXXengineers and other technical resources

Constraints and Assumptions

The following constraints and assumptions have been identified:

• Systems and Interfaces outside of the Azure Landing Zone design have been considered out of scope and will not be documented within this design.
• Commencement of the build phase of the requires the following customer pre-requisites to be met (these have already been provided and communicated in detail):
  • Provisioning of Microsoft Entra accounts with required permissions for assigned [Company]
  • Ensure Microsoft Entra Tenant exists.
  • Have obtained adequate licensing, which may include Microsoft Entra ID/Microsoft365.
  • Confirmed the ability to create Azure subscriptions (directly or indirectly).
  • Planned for change control.
  • Planned for connectivity (VPN and/or ExpressRoute).
• SCXX resources will be available to:
  • Validate build and connectivity between systems.
  • Configure any on-premises firewall rules.
  • Create accounts and grant access to [Company] employees as required.
• Firewall rules will be updated in a timely manner to enable service connectivity.
• Additional Azure Subscriptions will be created in a timely manner and access granted to all [Company] automation assets to move these subscriptions where required.

Document Conventions

The following tables are used to highlight important information or activities above and beyond the general design document content.

Terminology / Glossary

Figure 1.7‑1 – Glossary

Commercials

For SCXX to operate the Azure Landing Zone detailed in this solution the following licensing agreements must be obtained.

Azure

Most resources are billed only when active on a per hour basis with some exceptions such as Azure storage which is billed per GB consumed and Azure App Service environments which are charged for the life cycle of the deployment (i.e. charging continues until the resource is deprovisioned or deleted).

SCXX will use existing Enterprise Agreement licensing. This model allows enterprise customers to purchase Azure services at a discounted rate and provides for centralized billing and management of subscriptions.

Design Highlight 2.1‑1 – Azure Licensing

Enterprise Agreement Hierarchy

Azure enrolment hierarchies define how services are structured within an Enterprise Agreement. The Enterprise Portal allows customers to divide access to Azure resources associated with an Enterprise Agreement based on flexible hierarchies customisable to an organisation’s unique needs.

The hierarchy pattern should match an organisation’s management and geographic structure so that the associated billing and resource access can be accurately accounted for.

Microsoft Entra ID

Regardless of the type of Azure Services agreement, it is important to carefully consider licensing requirements to provide the feature sets that must be implemented to protect your organisation.

Microsoft Entra ID comes in four editions—Free, Office 365 apps, Premium P1, and Premium P2. The licensing purchased directly impacts the authentication options and security controls that can be implemented[1].

The table below lists the specific features used and the licensing required to enable them:

Design Highlight 2.2‑1 – Microsoft Entra ID Licensing

Tenant Structure

A well-designed Azure hierarchy is required to ensure well-defined guardrails can be deployed to achieve optimal outcomes in the following core areas:

• Cost Optimisation
• Operational Optimisation
• Performance
• Reliability
• Security

Landscapes and Environments

A hierarchy of landscapes and environments will be implemented where a landscape contains one or more environments, and an environment belongs to a single landscape.

This approach simplifies management of common controls (such as RBAC, and policy assignment) based on a multi-level hosting classification. For example, you can:

1. Set common controls across all environments that share a common characteristic based on landscape.
2. Refine the controls at the individual environment.

Landscapes

A Landscape is a grouping of environments that share a set of common controls. It allows for a consistent baseline to be applied across a collection of environments simplifying management whilst still allowing each environment to augment or override when required.

For example, you can set RBAC against all production environments via the production landscape to be more restrictive than non-production, or treat the alerts generated from environments within the production landscape differently than non-production. In addition, if you have a pre-production and production environment in your production landscape you can apply more granular controls to differentiate them on the environment itself.

A landscape model will be implemented comprising of:

• Production – used to group all Landing zone subscriptions that align to production like workloads.
• Non-production – used to group all Landing zone subscriptions that align to non-production like workloads.
• Sandbox – used to group all subscriptions which can be used for proof-of-concept activities.

Environments

Within each landscape, environments will be defined and deployed to provide identification and separation of workloads. Each environment will belong to a single landscape.

All environments are identified by a three-letter abbreviation of the environment name and used to inform the naming applied to resources deployed to the environment.

Design Highlight 3.1‑1 – Environments

For example, virtual network names created in a production environment will follow the convention:

• vnet-aue-prd-[landing zone identifier]

Azure Hierarchy Overview

Azure provides four levels of management scope:

• Management Groups (up to six levels in depth),
• Subscriptions,
• Resource Groups and
• Resources

Ensuring a defined structure exists for these scopes is critical to managing and securing cloud environments whilst ensuring maximum visibility into the use and cost of resources in Azure.

Whilst all will be covered in more detail, the following image provides a holistic view of each layer or “tier” in a typical tenant hierarchy incorporating the above concepts throughout to achieve a best practise outcome whilst supporting consistency, scalability and automation.

Figure 3.2‑1 – Azure Hierarchy

Microsoft Entra Tenant

A Microsoft Entra tenant represents an organisation in Microsoft Entra ID. It is a dedicated Microsoft Entra ID service instance that an organisation receives and owns when it signs up for a Microsoft cloud service such as Azure, Microsoft Intune, or Microsoft 365. Each Microsoft Entra tenant is distinct and separate from other Microsoft Entra tenants and contains objects representing constructs such as users, groups and application registrations.

A Microsoft Entra tenant is primarily used as an identity provider for SaaS and PaaS workloads; however, it can be leveraged for IaaS workloads by virtue of utilising Microsoft Entra Domain Services acting as an extension of Microsoft Entra ID, providing Windows Domain Join, group policy, LDAP, and Kerberos authentication capabilities.

Figure 3.3‑1 – Azure Tenant

Design Highlight 3.3‑1 – Entra Tenant

Azure Regions

Azure regions feature datacentres deployed within a latency-defined perimeter. They’re connected through a dedicated regional low-latency network. This design ensures that Azure services within any region offer the best possible performance and security.[2]

Not all Azure services are available in all regions, it is important to consider where Production, Non-Production and Disaster Recovery workloads will reside to ensure optimal efficiency and cost management.

Figure 3.4‑1 – Azure Region Locations in Australia

Design Highlight 3.4‑1 – Azure Region

Management Groups

Management Groups are hierarchical containers that help you manage governance including role-based access, and Azure Policy assignment to achieve compliance across multiple subscriptions. All subscriptions in a management group automatically inherit the conditions applied to the management group(s) they fall under.

The management group structure implemented is reflective of the Microsoft Cloud Adoption Framework (CAF) implementing separation between the areas of responsibility such as core platform services and application landing zones.

Design Highlight 3.5‑1 – Management Groups

Figure 3.5‑1 – SCXX Management Groups

Table 3.5‑1 – Management Group Hierarchy

Subscriptions

Subscriptions help to establish a structure to organise and manage resources in Azure. They also help control resource usage and how it is reported, billed, and paid for. Every cloud service belongs to a subscription and the subscription ID may be required for programmatic operations.

Resources for the core platform services (such as Virtual WAN) will be managed in dedicated subscriptions as outlined in the table below.

For workload landing zones, SCXX will use a combination of dedicating subscriptions to a specific workload (for example, Azure VMware Services) as well as subscriptions shared by multiple workloads that may represent multiple disparate applications but share an environment and therefore that environments governance controls, for example, “production” virtual machines.

Enterprise Agreement Subscriptions

When creating subscriptions under an Enterprise Agreement, account owners have the ability to create subscriptions that will host non-production workloads under the EA Dev/Test offer

Using Dev/Test subscriptions for development and test delivers lower chargeable rates on a number of services including lower rates on Windows Virtual Machines, Cloud Services, SQL Database, SQL Managed Instance, HDInsight, App Service (Basic, Standard, Premium v2, Premium v3) and Logic Apps For more information on the benefits, please refer to: Enterprise Dev/Test.

Please note: An Enterprise Admin may need to enable this feature for account owners to create the subscription. Please see Enable the Enterprise Dev/Test Offer for more details and instructions.

Core Platform Subscriptions

Core platform resources will be deployed into the following dedicated subscriptions.

Figure 3.6‑1 – Core Platform Subscriptions

Landing Zone Subscriptions

Landing Zone subscriptions (also referred to as spoke subscriptions) are onboarded as required to support infrastructure hosting for workloads / applications.

These subscriptions are placed in the hierarchy under one of the following management groups based on the target landscape for the landing zone subscription:

The subscription may be used for hosting a specific workload, such as Azure VMware Solution (AVS), or a mixed workload such as the production subscription. Each subscription will represent a specific environment under the landscape/environment model.

Within each subscription, the following resource will be deployed unless otherwise stated in the table below:

1. Resource Groups as outlined in the next section.
2. A virtual network peered to the regional secure hub.
3. A key vault for secret/certificate management.
4. Recovery Service Vaults for backup with backup policies configured as outlines in section 2 Backup
5. Service Health Alerts
6. Resource Health Alerts

Subscription Summary

The following table summarises the required subscriptions to deploy the solution, their parent Management Group and whether EA Dev/Test licensing can be applied.

Figure 3.6‑2 – Landing Zone Subscriptions

Resource Groups

A resource group is a container that holds related resources for an Azure solution. The resource group can include all the resources for the solution, or only those resources that you want to manage as a group[3].

The following are key factors to consider when defining resource groups:

• All the resources in your group should share the same lifecycle. You deploy, update, and delete them together. If one resource, such as a database server, needs to exist on a different deployment cycle it should be in another resource group.
• Each resource can only exist in one resource group.
• You can add or remove a resource to a resource group at any time.
• A resource group can contain resources that reside in different regions.
• A resource group can be used to scope access control for administrative actions.

As with management groups and subscriptions, resource groups can have RBAC assignments, policy and cost management controls applied.

The Azure Landing Zone can enforce separation of resources by function to simplify management including RBAC boundaries and resource locking and implements a naming standard to help identify each resource groups core purpose as outlined below.

Table 3.7‑1 – Resource Group Classification

Resource Summary

The following sections outline the key resources deployed to each subscription, it is not a complete as-built.

Platform Management Subscription

Resources deployed to sub-scr-prd-management-01.

Table 3.8‑1 – Platform Management Resources

Platform Connectivity Subscription

Resources deployed to sub-scr-prd-connectivity-01.

Table 3.8‑2 – Platform Connectivity Resources

Landing Zone Subscriptions

The following illustrates the resources that will be deployed to a typical application landing zone (excluding AVS).

The names of the resource groups and resources will change based on the environment and landing zone descriptor. For example, for mixed production workloads such as virtual machines the descriptor “workloads” is used, for the DMZ landing zone the descriptor “dmz” will be used.

Table 3.8‑3 – Application Landing Zone Resources

Identity and Access Management

Overview

Identity and access management (IAM) is the process of managing and securing digital identities. This includes creating and managing user accounts, controlling access to resources based on user roles and responsibilities (personas), and monitoring and auditing user activity. The goal of IAM is to ensure that only authorised users have access to sensitive information and resources. This can be done through a variety of methods such as authentication, authorization, and multi-factor authentication.

Microsoft Entra ID is a cloud-based identity and access management service that delivers IAM to Azure.

Break Glass Accounts

Emergency access accounts (or “break glass” accounts) are highly privileged, and they are not assigned to specific individuals. Usage is limited to emergency or “break glass”‘ scenarios where normal administrative accounts cannot be used.

Typical scenarios for using an emergency access account include:

• The user accounts are federated, and federation is currently unavailable because of a cell-network break or an identity-provider outage. For example, if the identity provider host in your environment is unavailable / down, users might be unable to sign in when Microsoft Entra ID redirects to their identity provider.
• The administrators are registered through Azure Multi-Factor Authentication, and all their individual devices are unavailable, or the service is unavailable. If users cannot complete MFA, they will be unable to complete sign-in. For example, a cell network outage is preventing them from answering phone calls or receiving text messages, the only two authentication mechanisms that they registered for their device.
• The person with the most recent Global Administrator access has left the organisation. Microsoft Entra ID prevents the last Global Administrator account from being deleted, but it does not prevent the account from being deleted or disabled on-premises. Either situation might make the organisation unable to recover the account.
• Unforeseen circumstances such as a natural disaster emergency, during which a mobile phone or other networks might be unavailable, hence restricting the ability to authenticate via a 2^nd

Recommendation 4.2‑1 – Break Glass Accounts

Multifactor Authentication (MFA)

Multi-factor authentication[4] (MFA) increases the security of user logins for cloud services above and beyond a simple password. With MFA, users are required to acknowledge a phone call, text message, or an app notification on their smartphone after successful first factor authentication with their password. Only after this second authentication factor has been satisfied is a user signed in.

Conditional Access Policy

A conditional access policy[5] is an automated access control decision for accessing cloud apps based on one or more conditions. Conditional access policies are enforced after the first-factor authentication has been completed. The objective of a conditional access policy is to enforce additional access controls on an access attempt to a cloud app based on how an access attempt is performed.

Conditional access policies support more granular control with advanced signals over the standard MFA for Microsoft Entra ID offering. Conditional Access Policies require Microsoft Entra ID Premium licensing[6].

Use conditional access policies to apply security controls (such as MFA) based on signals provided by Active Directory (such as user risk score or device compliance).

Conditional access policies in their simplest form are if-then statements that determine the conditions that must be met before a user or application can access a resource.

Recommendation 4.3‑1 – Multifactor Authentication with Conditional Access Policies

Role Based Access Control

Access management for cloud resources is a critical function for any organisation that is using the cloud. Azure role-based access control (Azure RBAC) helps you manage who has access to Azure resources, what they can do with those resources, and what areas they have access to.[7]

Personas are made up of a collection of functions or tasks, a persona is generally linked to a job role or title. This is assuming that the job role, title, and functions/tasks are defined for the persona.

A role definition, or role, is a collection of permissions. A role definition lists the operations that can be performed on Azure resources, such as create, read, update, and delete.

Using Azure RBAC, you can segregate duties within your team and grant only the amount of access to users required to perform their specific roles, linked to defined personas and role definitions.

Wherever possible, the solution will align personas to Azure built-in roles to minimise overall RBAC complexity, however, there are cases where it is not possible to use a built-in role as it either lacks a particular permission or will grant more permissions than the persona requires weakening the concept of least privilege.

Azure Roles

LAB³ recommends following a Principle of Least Privilege. This means that a subject (user, group, service principal and managed identities) should be given only those privileges required to complete its task. If a subject does not need an access right, the subject should not have that right. Further, the function of the subject (as opposed to its identity) should control the assignment of rights.

Wherever possible this is achieved via the built-in Azure Roles as listed below, assigned at the appropriate resource level. Where a built-in role cannot achieve the required access, a custom role may be required.

Table 4.4‑1 – Common Azure Built-In Roles

Custom Roles

The following custom roles will be created to support scoped RBAC.

Table 4.4‑2 – Azure Custom Roles

Microsoft Entra Groups

Entra groups allow a resource owner (or Microsoft Entra directory owner) to assign a set of permissions to all members of the group, instead of having to provide rights to individual users.

The resource or directory owner can also provide management rights for the member list to someone else, such as a department manager or Helpdesk administrator, letting them add and remove members as needed.

A set of Microsoft Entra Groups will be created to model the following personas:

• Cloud Operations
• Network Operations
• Finance Operations
• Security Operations

For each persona, multiple groups will be created over the same Azure scope to allow for read access for day-to-day visibility/observation as well as privileged access such as contributor.

Platform Resource Scoped Groups

To support least privilege access to key platform resources including the log analytics workspace and Azure Key vault for platform secrets, the following groups will be created and assigned RBAC.

Please refer to the example scenario at the end of the next section for how these groups can be used.

Landing Zone Scope Based Groups

A standard pattern will be used for deployment of Entra groups associated to each landing zone identified in the design for the highly privileged built-in Azure roles Owner and Contributor as well as the lower privilege Reader role.

Additional groups can be added and assigned as a business-as-usual operation as required.

These groups can be used to provide SCXX employees scoped access to Azure as well as manage access for external contractors and service providers.

Azure Attribute Based Access Control[8] (ABAC) allows conditions to be applied to role assignments that can restrict what the security principal assigned the role can do. For the owner roles assigned to landing zone subscriptions the following restrictions will be applied:

*Monitoring Contributor RBAC assignment achieved via nesting Entra Group as a member of az-sec-monitoring-contributor

**Landing Zone key vaults and Storage Accounts are optional

Example 4.5‑1 – Assigning User Permissions

Nested Group Memberships

Entra Groups nested to simplify RBAC assignments.

Governance

Governance provides mechanisms and processes to maintain control over your applications, resources, and environments within Azure. It involves understanding strategic priorities and initiatives and establishing guard rails that align to these priorities and initiatives. Primarily implemented within Azure with the use of Azure Policy leveraging built-in and custom policies from LAB³ to audit and enforce the previously mentioned guard rails. Azure Cost Management also plays an important role to assist with the management, tracking and insights of your expenditures within Azure.

Naming Standards

It is important to name resources within Azure with a consistent and predictable pattern.

Management of resources within the Azure platform is greatly simplified when key pieces of information that describe the resource are listed in the name of the resource itself. A comprehensive naming standard will allow administrators to identify a resources’ location, classification, purpose, and system it belongs to all by glancing at the name of the resource.

Additionally, resource names in most cloud systems are often consumed by external tool sets (such as command line utilities, or cloud management tools), and a well-defined naming standard ensures that the resources are also identifiable when viewed from outside the context of Azure’s native platform.

There are some special cases within Azure where there are restrictions on the naming of resources, such as disallowed special characters or a maximum character length. In these circumstances, the name of the resource may not fit exactly within the parameters of the convention.

Some Azure resources such as key vaults or storage accounts require the name to be globally unique across all of Azure. The naming convention should also accommodate this restriction to ensure that a duplicate resource in another subscription or region will not clash with an existing globally unique resource name.

The key characteristics of a mature naming standard are:

• It allows resources to be easily identifiable by human eyes.
• It accommodates naming restrictions enforced by the platform.
• It is programmatically accessible.
• It is predictable and follows a logical pattern.
• It is repeatable.
• It is searchable.
• It is scalable.

Design Highlight 5.1‑1 – Naming Standards

Resource Locks

Resource locks can be applied to subscriptions, resource groups, or resources to prevent accidental deletion or modification of critical resources.

The following lock types are supported in Azure:

• CanNotDelete (or delete) allows authorised users to read and modify a locked resource, but they cannot delete the resource.
• ReadOnly allows authorised users to read a resource, but they cannot delete or modify the resource.

When a lock is applied at a parent scope, all resources within that scope inherit the same lock. Even resources added later inherit the lock from the parent. The most restrictive lock in the inheritance takes precedence. Unlike role-based access control, resource locks are used to apply a restriction across all users and roles.

Once a lock is applied, it can only be removed by an identity principal with sufficient privileges.  The following built-in RBAC roles have sufficient privileges to remove resource locks:

• Owner
• User Access Administrator

Post deployment of the landing zone resources, the following will be applied:

1. Locks will be manually managed; there is no automation associated with lock management
2. Locks preventing deletion will be applied to resource groups post deployment
3. Locking applied will be CanNotDelete; read-only locking should be limited to quarantine scenarios
4. The following resource group classes will not have locking applied:
   1. Recovery resource groups (rrg) containing recovery services values
5. The following resource group classes will not have locking enabled by default post creation:
   1. Network resource groups used within application landing zone subscriptions; this is to support PaaS resources requiring the ability to scale up and down on demand (such as SQL managed Instances or Entra Domain Services).
   2. Application resource groups.

Resource Tagging

Azure Resource Manager supports tagging entities with arbitrary text strings to identify the context and streamline automation. Tags should be used to augment and enhance context alongside the naming conventions chosen. The Tags can also be used to identify teams for billing, management or to help with Cost Management governance.

Tags will be applied at the subscription and resource group layers of the hierarchy during the build of the platform.

Azure Policy will be used to:

1. Audit for the presence of tags as shown in the following table. The value will not be considered within the audit condition.
2. Copy tags from resource groups to resources that are deployed into that resource group.

Table 5.3‑1 – Resource Tagging

The following tag values will be applied:

Table 5.3‑2 – Resource Tag Values

Azure Policy

Azure Policy enables enforcement of organisational standards at-scale. Through its compliance dashboard, it provides an aggregated view to evaluate the overall state of the environment, with the ability to drill down to the per-resource, per-policy granularity. It also helps to bring your resources to compliance through bulk remediation for existing resources and automatic remediation for new resources.

Azure Policy utilises Policy Definitions to evaluate the state on an Azure environment, executing a policy effect based on the results.

Table 5.4‑1 – Azure Policy Effects

For a detailed explanation of policy effects please see Understand Azure Policy effects.

Wherever possible, Azure Policy assignments should be scoped to Management Groups to reduce the number of overall assignments and avoid any limitations[9].

Managed Identities

Managed Identities support accessing Azure resources via RBAC assignment without the complication of managing credentials. As part of Azure Policy deployment, they are used to support DeployIfNotExists effects to remediate resources that are non-compliant.

An User Assigned Managed Identity will be used for policy assignments that have a DeployIfNotExists effect.

Policy Assignment

The following Policy will be applied:

CIS Microsoft Azure Foundations Benchmark

The Center for Internet Security (CIS) is a nonprofit entity whose mission is to ‘identify, develop, validate, promote, and sustain best practice solutions for cyber defense.’ CIS benchmarks are configuration baselines and best practices for securely configuring a system. These policies address a subset of CIS Microsoft Azure Foundations Benchmark v1.4.0 controls.

Table 5.4‑2 – CIS Microsoft Azure Foundations Benchmark

Allowed Locations

This policy enables you to restrict the locations your organization can specify when deploying resources. Use to enforce your geo-compliance requirements. Excludes resources that use the ‘global’ region.

Table 5.4‑3 – Allowed Locations

Allowed Locations for Resource Groups

This policy enables you to restrict the locations your organization can create resource groups in. Use to enforce your geo-compliance requirements.

Table 5.4‑4 – Allowed Locations for Resource Groups

Allowed Virtual Machine Size SKUs

This policy enables you to specify a set of virtual machine size SKUs that your organization can deploy. If the machine size is not included in the parameter list used when assigning the policy the “deny” effect will prevent deployment.

Table 5.4‑5 – Allowed virtual machine size SKUs

Configure Azure Activity logs to stream to specified Log Analytics workspace

Deploys the diagnostic settings for Azure Activity to stream subscriptions audit logs to a Log Analytics workspace to monitor subscription-level events.

Table 5.4‑6 – Configure Azure Activity logs to stream to specified Log Analytics workspace

Enable audit category group resource logging for supported resources to Log Analytics

Resource logs should be enabled to track activities and events that take place on your resources and give you visibility and insights into any changes that occur. This initiative deploys diagnostic setting using the audit category group to route logs to Log Analytics for all supported resources.

Table 5.4‑7 – Enable audit category group resource logging for supported resources to Log Analytics

Enable logging by category group for Recovery Services vaults to Log Analytics

Resource logs should be enabled to track activities and events that take place on your resources and give you visibility and insights into any changes that occur. This policy deploys a diagnostic setting using a category group to route logs to a Log Analytics workspace for Recovery Services vaults (microsoft.recoveryservices/vaults).

Table 5.4‑8 – Enable logging by category group for Recovery Services vaults to Log Analytics

Enable logging by category group for Virtual networks to Log Analytics

Resource logs should be enabled to track activities and events that take place on your resources and give you visibility and insights into any changes that occur. This policy deploys a diagnostic setting using a category group to route logs to a Log Analytics workspace for Virtual networks (microsoft.network/virtualnetworks).

Table 5.4‑9 – Enable logging by category group for Virtual networks to Log Analytics

Configure Windows machines to run Azure Monitor Agent and associate them to a Data Collection Rule

Monitor and secure your Windows virtual machines, virtual machine scale sets, and Arc machines by deploying the Azure Monitor Agent extension and associating the machines with a specified Data Collection Rule. Deployment will occur on machines with supported OS images (or machines matching the provided list of images) in supported regions.

Table 5.4‑10 – Configure Windows machines to run Azure Monitor Agent and associate them to a Data Collection Rule

Network interfaces should not have public IPs

This policy denies the network interfaces which are configured with any public IP. Public IP addresses allow internet resources to communicate inbound to Azure resources, and Azure resources to communicate outbound to the internet. This should be reviewed by the network security team.

Table 5.4‑11 – Network interfaces should not have public IPs

Configure virtual network to enable Flow Log and Traffic Analytics

Used to configure virtual networks in the target scope to enable virtual network flow logging to the platform log analytics workspace.

Table 5.4‑12 – Configure virtual network to enable Flow Log and Traffic Analytics

Inherit a tag from the resource group if missing

Adds the specified tag with its value from the parent resource group when any resource missing this tag is created or updated. Existing resources can be remediated by triggering a remediation task. If the tag exists with a different value, it will not be changed.

Please note: This policy will be applied 3 times, once for each tag.

Table 5.4‑14 – Inherit a tag from the resource group if missing

Policy for resource tags on resource group

This is a custom policy created to check for all three required tags. The policy definition will need to be modified if additional tags are to be included.

It will check for the presence of the tags:

• Landscape
• Environment
• Application

Table 5.4‑15 – Inherit a tag from the resource group if missing

Recommendation 5.4‑1 – Azure Policy Assignment

Cost Management

Azure Cost Management provides the tools to plan, analyse, and reduce your spending and maximise the return on your cloud investment. Budgets can be scoped to management groups, subscriptions, resource groups or a collection of resources to set limits and notifications based on predicted spend.

In addition to resource tagging that helps you understand, and track spend in Azure in invoicing reports; costs will also be made visible via Azure Budgets.

Azure Budgets can be created at the following scopes with Azure:

• Management Groups
• Subscriptions
• Resource Groups

The Finance Operations Entra groups will be assigned cost management roles and the top-level management group mg-scr-global scope to create and manage Azure Budgets.

An initial set of Budgets will be created for SCXX as detailed in the following table. These can be augmented with additional budgets scoped to other locations within the Azure hierarchy as a business-as-usual activity.

Design Highlight 5.5‑1 – Azure Cost Management   

Networking

Overview

The intent of this section is to highlight the routable traffic, network layout, and Azure services required to provide a scalable Azure platform to support not only migrations to Azure but also a highly available and disaster recoverable platform that applications can consume.

This section will cover:

• Network topology
• Traffic routing patterns
• Network security
• Domain Name Services
• On-premises connectivity

Network Use Cases

Table 6.2‑1 – Network Use Cases

IP Address Allocation

Azure virtual networks use private RFC1918 IP addresses. The ranges of private IP addresses are the same as for on-premises traditional network IP addressing. The Private RFC1918 ranges are:

• 0.0.0 to 10.255.255.255
• 16.0.0 to 172.31.255.255
• 168.0.1 to 192.168.255.255

The following IP address ranges are required for deployment of the solution:

• Core Platform IP Range – Reserved/utilised for networking services (firewalls, Virtual WAN Hubs, etc) and is recommended to be not smaller than a /22.
• Application IP Range – Allocated for application/service deployments, it needs to be not only large enough for current workloads but also for large future growth.

Design Highlight 6.3‑1 – IP Allocation

Azure Virtual WAN

Overview

Azure Virtual WAN is an Enterprise scale networking service supporting a single operational interface to manage connectivity between virtual networks within Azure and hybrid connectivity services such as Express Route, S2S VPN and P2S VPN. An important element of the Virtual WAN service is that it acts as a central routing control point only, it does not host shared services such as Domain Controllers within the hub network construct.[10]

The main components of Virtual WAN are:

• The Virtual WAN resource, bound to a single region this acts as a configuration container.
• Virtual WAN Hubs which are central network zones that inspect ingress or egress traffic and route between connected networks.
• Virtual WAN Secured Hubs are Virtual WAN Hubs with a Firewall deployed.

Virtual WAN is a Hub and Spoke architecture, meaning that Virtual WAN will be the interconnect and integration point between Azure, spoke networks, on-premises data centres and branch networks.

The network design aligns to the following best practise recommendations from the Cloud Adoption Framework:

• Use a Virtual WAN Secured Hub per Azure region to connect multiple landing zones together across Azure regions by way of a common global Azure Virtual WAN.
• Deploy all Virtual WAN resources for a single Virtual WAN into one resource group in the connectivity subscription, including when you’re deploying across multiple regions.
• Use Virtual WAN routing features to further segment traffic between VNET’s and branches.
• Deploy required shared services, like DNS servers, in a dedicated spoke virtual network.
• Connect Virtual WAN Secured Hubs to on-premises datacentres by using ExpressRoute.
• Create Azure Virtual WAN and firewall resources within the connectivity subscription.
• F(creating a secured virtual hub)
• Use insights in Azure Monitor for Virtual WAN to monitor the end-to-end topology of your Virtual WAN and status and key metrics.

Table 6.4‑1 – Virtual WAN Configuration

Virtual WAN Secured Hubs

leverage Azure Firewall and Azure Firewall Manager to provide advanced security capabilities. Azure Firewall acts as the central firewall and gateway for all traffic flowing through the hub, allowing SCXX to enforce network security policies, perform threat detection, and apply application-level filtering. Azure Firewall Manager provides a centralized management platform to manage and monitor multiple Azure Firewalls across the hub.

Design Highlight 6.4‑1 – Azure Virtual WAN

Table 6.4‑2 – Secured Virtual Hub Configuration

Figure 6.4‑1 – VWAN Network Topology

Virtual Networks

Azure Virtual Network (VNET) is the fundamental building block for private networks in Azure. VNETs enable many types of Azure resources, such as Azure Virtual Machines (VM), to securely communicate with each other, the internet, and on-premises networks[11].

Subnets enable you to segment a virtual network into one or more sub-networks allocating a portion of the virtual network’s address space to each subnet. Azure resources integrated with virtual networks are deployed in a specific subnet. Just like in a traditional network, subnets allow you to segment your virtual network address space into segments that are appropriate for the organisation’s internal network. This also improves address allocation efficiency. You can secure resources within subnets using Network Security Groups and control traffic flow out of them via User Defined Routes.

Recommendation 6.5‑1 – Virtual Networks

Platform Spokes

A Shared services virtual network will be deployed to support future platform tools and services that are consumed by multiple application landing zones or for platform management (for example, domain controllers).

The design for the shared services zone has the following key elements:

• Services hosted in this landing zone require access to the entire private network footprint.
• Network traffic logs are supported via Virtual Network Flow Logs and firewall logs available from the firewall instances within the .

Shared Services

Table 6.5‑1 – Shared Services Virtual Network Configuration

Table 6.5‑2 – Shared Services Virtual Network Subnet Configuration

Figure 6.5‑1 – Shared Services Spoke

Landing Zone Spokes

Virtual Networks will be created in all application landing zone spokes created as part of the initial platform build apart from the landing zone used for Azure VMware Solution (AVS).

Production Landing Zone (Mixed Workloads)

Table 6.5‑3 – Production Landing Zone (Mixed) Virtual Network Configuration

Table 6.5‑4 – Production Landing Zone (Mixed) Virtual Network Subnet Configuration

Production Landing Zone (DMZ)

Table 6.5‑5 – Shared Services Virtual Network Configuration

Table 6.5‑6 – Shared Services Virtual Network Subnet Configuration

Test Landing Zone (Mixed Workloads)

Table 6.5‑7 – Test Landing Zone (Mixed) Virtual Network Configuration

Table 6.5‑8 – Test Landing Zone (Mixed) Virtual Network Subnet Configuration

Sandbox Landing Zone (Mixed Workloads)

Table 6.5‑9 – Sandbox Landing Zone (Mixed) Virtual Network Configuration

Table 6.5‑10 – Sandbox Landing Zone (Mixed) Virtual Network Subnet Configuration

Hybrid Connectivity

ExpressRoute

Microsoft Azure ExpressRoute allows an organisation to leverage Microsoft’s cloud services through a dedicated private connection facilitated by an interconnect provider. ExpressRoute allows organisations to establish connections to three types of Microsoft services:

• Azure Private Services: Organisation’s that utilise private-facing Azure services like virtual machines and Virtual Networks can address those private services through a private connection using private peering. Private Peering also allows Azure services attached to a virtual network to access on-premises private addresses. This is known as ‘ExpressRoute Private Peering’.
• Azure Public Services: Organisations that utilise public-facing Azure services like Data Factory, Azure SQL, Azure Blobs or Azure public IP addresses can address those public services through a private connection using Microsoft peering. This is known as ‘ExpressRoute Microsoft Peering’.
• Office 365: Organisations that utilise Exchange Online, SharePoint Online, Yammer, and Skype for Business can address those public services through a private connection using Microsoft peering. This was known as ‘ExpressRoute Microsoft Peering’, it is now rolled into Microsoft peering as an option.

Figure 6.6‑1 – ExpressRoute Connectivity

ExpressRoute Gateways

Virtual WAN ExpressRoute gateways are an optional component within Azure Virtual WAN that enables the integration of ExpressRoute connectivity into the Virtual WAN infrastructure.

By connecting a ExpressRoute circuit to the Virtual WAN Secured Hub, SCXX will establish dedicated, high-performance, and secure connections between on-premises networks and Azure resources. The ExpressRoute gateway acts as a bridge between the Virtual WAN Secured Hub and the ExpressRoute circuit, facilitating the exchange of data with low latency and high bandwidth.

Virtual WAN Secured Hubs can host an ExpressRoute gateway alongside site-to-site and point-to-site VPN connections although only ExpressRoute is to be deployed for SCXX.

ExpressRoute gateways when provisioned are automatically associated to and propagate to the hubs Default route table.

Table 6.6‑1 – ExpressRoute Gateway Configuration

Domain Name Services

Azure has multiple services to support domain name hosting and resolution. These include private and public DNS zones as well as native/platform resolution using the Azure recursive DNS resolver or services such as Azure DNS Private Resolver.

The following components make up the DNS services that will be deployed for SCXX:

• Azure Firewall DNS proxy
• Virtual Network DNS configuration

Azure Firewall DNS Proxy

Azure Firewall can be configured to act as a DNS proxy. A DNS proxy is an intermediary for DNS requests from virtual machines and other virtual network integrated services to a DNS server.

Figure 6.7‑1 – Azure Firewall DNS Proxy

Recommendation 6.7‑1 – Azure Firewall DNS Proxy

Design Highlight 6.7‑1 – Azure Firewall DNS Proxy

Virtual Network DNS Configuration

Azure virtual networks provide the facility to supply custom DNS settings to facilitate DNS resolution by virtual machines deployed within the virtual network. This allows you to override the default configuration which is for Azure recursive resolver service (168.63.129.16).[13]

Recommendation 6.7‑2 – Virtual Network DNS Settings

Design Highlight 6.7‑2 – Virtual Network DNS Configuration

Route Management

Virtual WAN Routing

Routing Intent simplifies route management in Azure Virtual WAN implementations.

Routing Intent and Routing policies allow you to specify how Virtual WAN Secured Hubs forward network traffic to internet destinations as well as to private network address ranges.

The following policies are supported:

• Internet Traffic Routing Policy: When configured on a Virtual WAN Secured Hub, all branch (Point-to-site VPN, Site-to-site VPN, and ExpressRoute) and virtual network connections to that hub will forward Internet-bound traffic to the Azure Firewall hub resource.
• Private Traffic Routing Policy: When configured on a Virtual WAN Secured Hub , all branch and virtual network traffic in and out of the hub including inter-hub traffic will be forwarded to the Azure Firewall hub resource.

Custom route tables are not supported within the secured hub, routing intent uses the hub default route table for traffic routing.

Design Highlight 6.8‑1 – Virtual WAN Routing

Managing Routes in Virtual Networks

Azure automatically creates system routes for each subnet within an Azure Virtual Network resulting in traffic freely flowing between subnets and to address spaces learnt through peering and gateways.

A User Defined Route (UDR) allows for overriding default system route configuration associated with virtual networks. A common pattern is to support security requirements such as requiring Azure Firewall to inspect traffic between network segments.

Route Tables will be created and linked for each subnet created as part of the initial deployment. These will be configured to allow propagation of gateway routes to support routing intent policy and BGP exchange.

Recommendation 6.8‑1 – User Defines Routes

Traffic Routing Patterns

Traffic routing patterns defines the traffic flow between two locations and the hops it takes. The high-level flows are defined which then determines the detailed design of other network components such as Route Tables, Load Balancers and NSGs.

Subnet to subnet (inter VNET)

Network Use Case(s) addressed: NUC6

This flow demonstrates that multiple subnets deployed within a single virtual network have traffic directly routed between them, it does not leave the virtual network.

This pattern is typically used for a multi-tier application where independent services reside on different subnets or where a dedicated subnet (e.g. application gateway) is required.

Figure 6.8‑1 – Intra Spoke Subnet to Subnet

Description of the flow:

• Subnets within the same VNET automatically route between each other using the VNET router.
• NSG rules used to provide micro segmentation.

Spoke to spoke (Intra VNET)

Network Use Case(s) addressed: NUC5

Spokes represent different application landing zones and virtual networks within the network topology. There may be different applications or services deployed within those landing zone that need network communication capabilities.

This pattern is typically used where application teams have inter-dependant service integrations or where application landing zone applications and infrastructure need to communicate with core services deployed within platform network locations (e.g. Active Directory services).

Figure 6.8‑2 – Spoke to Spoke via Firewall

Description of the flow:

• Traffic from 1 spoke exits the subnet and virtual network and transits Azure Firewall before traversing the target spoke virtual network.
• In the case where this is within a region, the traffic flow through the regional firewall.
• In the case where this is spoke-to-spoke in different regions, the traffic flows through the firewall in the source and destination regions.
• NSG still used to provide micro segmentation.

Spoke to Internet (Egress)

Network Use Case(s) addressed: NUC1

Egress Internet traffic is generally facilitated using a proxy service where IaaS based workloads are concerned and directly routed in most cases when PaaS workloads are concerned. In both cases, it can be routed outbound if the firewall services are designed to do so.

Azure Firewall is the next hop for the default route (0.0.0.0/0) applicable to all spokes and is the egress point of the network for Internet traffic as well as Microsoft Public Management endpoints. The default position is that egress traffic is denied unless there is a specific firewall rule to allow it.

Figure 6.8‑3 – Internet Breakout

Description of the flow:

• Traffic from all spokes leaves the subnet and virtual network and transits Azure Firewall where the firewall will validate the traffic flow against the configured firewall rules.
• In the case where the flow is allowed, the firewall will NAT the outbound traffic and manage the state of the connection.
• In the case where the flow is NOT explicitly allowed, the flow will be denied and dropped by the firewall.
• NSG rules are still used to provide micro segmentation.

Spoke to On-Premises

Network Use Case(s) addressed: NUC3, NUC4

On-premises refers to any environment connected to the Azure private network environment via any supported technologies  such as ExpressRoute or VPN.

In this use case, traffic from the spoke networks (applications or platforms) needs to communicate with services or applications which are on the other end of the Virtual WAN enabled connectivity and hosted on-premises or in another cloud provider.

Figure 6.8‑4 – Spoke to On-Premises

Description of the flow:

• Traffic sourced from all spokes leaves the subnet and virtual network and transits Azure Firewall where the firewall will validate the traffic flow against the configured firewall rules.
• In the case where the flow is allowed, the hub router will direct the traffic to the relevant gateway for routing to on-premises environment.
• In the case where the flow is NOT explicitly allowed, the flow will be denied and dropped.
• Traffic sourced from the on-premises environment will ingress into the virtual WAN secured hub via the enabled gateway, land on the Azure Firewall where the firewall will validate the traffic flow against the configured firewall rules.
• In the case where the flow is allowed, the flow will be routed down the relevant virtual network connection and into the spoke network.
• In the case where the flow is NOT explicitly allowed, the flow will be denied and dropped.
• NSG still used to provide micro segmentation.

Network Security

Network Security will be implemented using a layered approach to support a defence-in-depth incorporating the best practices as defined in Microsoft guidance[14].

As well as providing optimal networking routing, Service Endpoints provide a mechanism for securely accessing Azure PaaS resources (such as Storage Accounts and Key Vaults) from your virtual network subnets or via direct ACL whitelists disabling access from the internet. Enabling service endpoints modifies the Azure SDN to allow for direct connections to the backend resources, when enabled, it adds a dynamic list of routes the route table of the subnet.

Recommendation 6.9‑1 – Service Endpoints

Figure 6.9‑1 – Service Endpoints

Azure Firewall

Azure Firewall is the Azure native, stateful firewall as a service that helps protect resources within virtual networks. When deployed in a hub and spoke network, Azure Firewall acts as the central security enforcement point, inspecting and filtering traffic based on network and application-level rules.

It leverages Azure Firewall Application Rules and Network Rules to define allowed or blocked traffic based on application protocols, IP addresses, ports, and more. Azure Firewall supports fully qualified domain name (FQDN) filtering, allowing granular control over outbound internet access. By leveraging Azure Firewall in Secure Hubs, SCXX can enforce network security policies consistently across application landing zone spokes and WAN connected on-premises datacentres and networks.

Azure Firewall Manager provides centralised management and monitoring for Azure Firewall instances across multiple Azure regions and subscriptions.

With Azure Firewall Manager, administrators can create and manage firewall instances, define rulesets, and monitor firewall health and performance from a single pane of glass. It also integrates with Azure Monitor, providing visibility into network traffic, threat intelligence, and security alerts.

SCXX can take advantage of numerous standard features out of the box as part of all firewall deployments including scalability, high-availability, and standard firewall rule capabilities.

Table 6.9‑1 – Azure Firewall Standard Features

Azure Firewall premium features extend the standard offering delivering Next Generation Firewall features such as advanced threat protection including IDPS and TLS inspection to prevent malware and viruses from spreading across networks.

Table 6.9‑2 – Azure Firewall Premium Features

Table 6.9‑3 – Azure Firewall Configuration

Azure Firewall Policy

Azure Firewall Policies provide a mechanism to define and enforce network security rules and settings for Azure Firewall. They allow organisations to centrally manage and control the behaviour of Azure Firewall instances across multiple virtual networks and subscriptions. Azure Firewall Policies offer granular control over inbound and outbound traffic, application filtering, network rules, threat intelligence integration, and more.

When creating an Azure Firewall Policy, administrators can define rule collections that consist of multiple rules. Each rule collection specifies the traffic matching criteria, action (allow or deny), and rule priority.

Table 6.9‑4 – Azure Firewall Policy Configuration

Rule Management[15]

Azure Firewall rule management is facilitated using policies as detailed in the previous section with the ability to prioritise, organise, and process rules based on a hierarchy made up of rule collection groups, rule collections and rules as shown in the diagram below.

Figure 6.9‑2 – Azure Firewall Rule Hierarchy

Rule Collection Groups, Rule Collections and Rules are all managed using the deployed Azure Firewall Policy associated to the hub firewall.

In addition, rule collections can be templated and applied to multiple firewall policies.

IP Groups

Azure Firewall IP groups are a feature that allows SCXX to group IP addresses for simplified network security rule management within Azure Firewall Policies. IP groups enable administrators to define Firewall rules based on these groups rather than individual addresses, providing flexibility and ease of configuration.

For core services, such as AD domain servers or DNS services, IP groups can be utilised to consolidate and manage the IP addresses associated with these services. This simplifies the process of defining firewall rules, ensuring that only the necessary IPs have access to the core services while reducing the administrative overhead of maintaining individual IP addresses. IP groups also facilitate scalability and ease of updates, making it convenient to add or remove IP addresses as the core services evolve over time.

Recommendation 6.9‑2 – IP Groups

The following IP groups will be created to simplify the management of firewall rules

Firewall Rules

Network Rules

Application Rules

Network Security Groups

Azure Network Security Groups are used to filter network traffic to and from Azure resources in an Azure virtual network. A network security group contains security rules that allow or deny inbound network traffic to, or outbound network traffic from, several types of Azure resources. For each rule, you can specify priority, source, destination, port, and protocol.

Network Security Groups are stateful.

All NSGs contain a set of system default rules, including a rule that blocks all inbound Internet traffic. The default rules cannot be deleted, but custom rules with a higher priority can override them. Once a rule has been satisfied, processing stops.

Azure Default Inbound Rules

Table 6.9‑5 – Azure Default Inbound Rules

Azure Default Outbound Rules

Table 6.9‑6 – Azure Default Outbound Rules

By default, all subnets created as part of the initial platform deployment will have a NSG resource created and associated. Whilst the default rules still allow any peered virtual network traffic inbound or outbound of an associated subnet it blocks internet ingress.

Recommendation 6.9‑3 – Network Security Groups

DDoS

Azure provides default infrastructure-level DDoS protection for services running on its platform under the basic plan, which is:

• Enabled by default (free).
• Mitigates common network attacks.
• Both protects IPv4 and IPv6 public IP addresses.

Basic protection may not be sufficient for individual applications as it has a high threshold and lacks telemetry and alerting capabilities. By opting for Azure DDoS Protection, applications can benefit from dedicated monitoring, attack detection, and application-specific thresholds.

With Azure DDoS Protection, applications receive a tailored protection profile based on their expected traffic volume, offering a stronger defence against DDoS attacks. It ensures that the traffic volume, which may seem harmless to the platform, does not overwhelm, or disrupt the application, thus providing enhanced security and availability.

There are 2 paid protection plans available, namely, Network protection which is configured against a virtual network and IP protection against individual Public IP objects.

For more information on DDoS protection plans, please refer to the following Microsoft documentation:

• What is Azure DDoS Protection?
• Azure DDoS Protection features
• About Azure DDoS Protection Tier Comparison

Design Highlight 6.9‑1 – Virtual Network DDoS Configuration

Security

Secret Management

Managing secrets and certificates in an Azure environment is straight forward  with Azure Key Vault[16].

Key features on the service includes:

• Secrets Management – securely store and tightly control access to tokens, passwords, certificates, API keys, and other secrets using Azure RBAC.
• Key Management – creation and control of encryption keys used to encrypt your data.
• Certificate Management – lets you provision, manage, and deploy public and private Transport Layer Security/Secure Sockets Layer (TLS/SSL) certificates for use with Azure and your internal connected resources.

Key Vaults integrate seamlessly with other Azure services to simplify secret management, for example, managing certificate rotation or managing administrator passwords and integrating  with the remote desktop connection authentication.

The following Key vaults will be deployed:

1. A single platform Key vault, deployed to the management subscription sub-scr-prd-management-01
2. A Key Vault deployed to each application landing zone to manage secrets specific to the landing zone.

Table 7.1‑1 – Azure Key Vault Configuration

Microsoft Defender for Cloud

Microsoft Defender for Cloud is a unified infrastructure security management system that strengthens the security posture of your data centres and provides advanced threat protection across hybrid workloads in Azure, other clouds, or on-premises.[17]

Microsoft Defender for Cloud offers foundational and advanced cloud security posture management solutions to protect across your multi-cloud and hybrid environments.

• Foundational CSPM (free) provides continuous assessments, security recommendations, Secure Score, and the Microsoft cloud security benchmark across Azure, Azure Web Services, and Google Cloud.
• Microsoft Defender CSPM provides advanced security posture capabilities including agentless vulnerability scanning, attack path analysis, integrated data-aware security posture, and an intelligent cloud security graph. Pricing is dependent on cloud size, with billing based only on Server, Storage account, and Database counts.

In addition, Cloud Workload Protection plans exist for compute and storage services including servers, containers, various database products and PaaS offerings.

Figure 7.2‑1 – Sample Defender Cloud Workload Protection Plans

Figure 7.2‑2 – Sample Defender Email Alert

For a full description of plans and pricing please refer to What is Microsoft Defender for Cloud?

As part of a landing zone onboarding, subscriptions will be onboarded onto Microsoft Defender for Cloud and enabled for all the services that form part of that solution. The below services will be enabled.

• Servers
• App Services
• Databases
• Storage
• Containers
• Key Vault
• Resource Manager
• DNS

It is important to note that there are additional costs associated with this service if Application teams deploy any of the service listed above. For the latest pricing associated with Defender Plans please see: Microsoft Defender for Cloud Pricing.

Another key element to the service is the alerts generated when a workload protection plan identifies a threat within the environment. These alerts have some key characteristics.

• Alerts are triggered by resource type leveraging the advanced detection capability.
• Every alert fired details the infected resource, issue, and suggested remediation steps.
• Alerts are classified by severity (High, Medium, Low, Informational)
• Alerts are exportable to a CSV format.
• Alerts can be streamed into Sentinel or an ITSM solution.

Design Highlight 7.2‑1 – Microsoft Defender for Cloud

Monitoring

Microsoft Defender for Cloud offers continuous export to a Log Analytics workspace as a feature to enhance security monitoring and incident response capabilities.

When enabled, this feature allows security teams to stream security-related events and data generated by Microsoft Defender for Cloud to a designated Log Analytics workspace within Azure Monitor. These events and data include threat intelligence, security alerts, detection details, investigation data, and other relevant information.

Figure 7.2‑3 – Defender for Cloud continuous export configuration

By leveraging this continuous export, SCXX can centralise and aggregate security data from Microsoft Defender for Cloud alongside other logs and telemetry data collected in the Log Analytics workspace. This enables the ability to implement advanced analytics, create custom queries, perform correlation analysis, and gain deeper insights into security incidents and trends. It enhances threat detection, enables proactive threat hunting, and facilitates faster incident response by providing a comprehensive view of security events and data across the organisation’s cloud environments.

The following table outlines settings that will be used on subscriptions to export to the Platform Log Analytics workspace.

Table 7.2‑1 – Microsoft Defender for Cloud Monitoring

Management

There are multiple dimensions to consider when looking at the overall management of Azure. Whilst all the traditional layers of management exist such as:

• Patching
• Alerting
• Observability
• Recoverability
• Config Management

To simplify the management of these resources, Azure has several services that will form the management capability the SCXX environment:

• Update Management
• Azure Monitor
• Log Analytics & Azure Monitor & Azure Reporting
• Azure Backup

Monitoring and Alerting

Resources deployed to Azure emit signals in the form of metrics and logs that can be leveraged to monitor the health of the individual resources or combined to monitor the overall health of the infrastructure and services hosting an application workload.

There are multiple facets to monitoring the overall health of an application, some of the sources that can be used to inform are:

1. Service Health Alerts
2. Resource Health Alerts
3. Activity Log
4. Resource metrics and logs
5. Guest logs from virtual machines

The following sections will outline this categories and what will implemented within the SCXX environment to support them.

Log Analytics Workspace

Monitoring of services in Azure is configured using native Log Analytics or third-party toolsets. Out of the box Azure Monitor solutions can be deployed to workspaces to support rich monitoring experiences including for networks, SQL databases etc.

Log Analytics is used to collect and analyse data from several layers of Azure Platform and provides a central collection point for all logging available within Azure

With the deployment of Azure Monitor Agent to virtual machines and association to Data Collection Rules, right insights can be gathered from the guest O/S including performance metrics, security logs, application logs, syslog’s etc.

Figure 8.1‑1 – Logging and Monitoring

To support metric and log collection central platform operational workspace is used to manage and monitor performance and metrics of infrastructure and services; operational alerting is configured against this law, and it is configured for access in a resource centric mode.

The platform log analytics workspace will be deployed in the management subscription and all resources enabled for diagnostic capture will send their enabled metrics and logs to it.

Table 8.1‑1 – Log Analytics Configuration

:

• Microsoft Defender for Cloud

Service Health Alerts

Azure Service Health notifies consumers about Azure service incidents and planned maintenance allowing action to be taken to mitigate downtime.

Alerts can be configured to proactively notify on health issues, monitor the impact to your cloud resources, get guidance and support, and share details and updates.

Service Health alerts will be configured for the most common/likely services to be in use at SCXX and scoped to each subscription providing coverage across all resource groups.

Azure Service Health notifies consumers about Azure service incidents and planned maintenance allowing action to be taken to mitigate downtime. Configure customizable cloud alerts and personalized dashboard to analyse health issues, monitor the impact to your cloud resources, get guidance and support, and share details and updates.

The following resources will be included in a service health alert created on each subscription:

Recommendation 8.1‑1 – Service Health Alerts

Design Highlight 8.1‑1 – Service Health Alert Notification

Resource Health Alerts

Unlike Service Health Alerts, Resource Health Alerts and alerts generated when a specific resource in an Azure subscription transition from one health state to another. They use resource health notifications that are stored in the Azure activity log of each subscription. Alerts can be configured the based on:

• The subscription affected.
• The resource types affected.
• The resource groups affected.
• The resources affected.
• The event statuses of the resources affected.
• The resources affected statuses.
• The reasons and types of the resources affected.

Each subscription comprising the overall landing zone deployment will have resource health alerts enabled for the following resource types:

• Network/virtualNetworks
• Network/networkSecurityGroups
• Network/routeTables
• Network/dnsResolvers
• Storage/storageAccounts
• KeyVault/vaults
• RecoveryServices/vaults
• OperationalInsights/workspaces

The connectivity subscriptions will have the following in scope for alerting:

• Network/virtualNetworks
• Network/networkSecurityGroups
• Network/routeTables
• Storage/storageAccounts
• KeyVault/vaults
• RecoveryServices/vaults
• OperationalInsights/workspaces
• Network/azureFirewalls
• Network/virtualHubs
• Network/virtualWans
• Network/expressRouteCircuits
• Network/expressRouteGateways
• Network/vpnGateways
• Network/vpnGateways/connections
• Network/vpnSites
• Network/vpnSites/connections

The condition on the alerts will be transition from a state of “Available” or “Degraded” to a state of “Unavailable” or “Degraded”

Design Highlight 8.1‑2 – Resource Health Alert Notification

Activity Logs

These alerts are based on Azure Monitor and leverage the Azure Activity Log, which records operational and administrative activities across Azure resources.

With Activity Log Alerts, you can define conditions or filter expressions based on specific events or operations, such as resource creation, deletion, or configuration changes.

Activity Log Alerts enable you to proactively track and respond to critical activities, security incidents, or compliance issues, providing insights into the operational health and governance of your Azure environment.

No Activity Log Alerts will be created as part of the platform deployment.

Resource Metrics and Logs

Resource diagnostics, both metrics and logs can be collected from all Azure resources deployed to support the core platform and landing zones and forwards to the platform Log Analytics workspace. This data can be used to improve performance and availability of applications as well as support security posture strengthening via ingestion and processing of in SIEM platforms such as Microsoft Sentinel.

Azure Policy will be deployed to capture the “AuditLogs” of many resource types that may be deployed by SCXX in Azure.

This will be achieved via the built-in policy assignments:

• Enable audit category group resource logging for supported resources to Log Analytics
• Enable logging by category group for Recovery Services vaults to Log Analytics

Alerting on Metrics and Logs

Metric Alerts are based on Azure Monitor, which collects and analyses telemetry data from various Azure resources.

With Metric Alerts, you can define thresholds or conditions for metrics, when the conditions are met an alert is triggered.

These alerts can be configured at a granular level, allowing you to define the frequency of evaluation, the severity of the alert, and the actions to be taken when triggered.

Metric alerts do not require metric ingestion into a Log Analytics workspace.

Log Alerts are based on resource logs generated and forwarded to a Log Analytics workspace. Creation of the alert rule involves defining a Kusto Query language (KQL) query to detect the alert condition.

Design Highlight 8.1‑3 – resource Health Alert Notification

Virtual Machine Guest Logs

Guest O/S logs can be collected and stored in the platform log analytics workspace via the:

• Deployment of the Azure Monitor Agent to the guest O/S
• Association to a Data Collection Rule

DCRs specify which data to collect from Windows or Linux machines,  define how to transform the data, choose where to send the data (for example, log analytics) and filter unwanted data.

A Data Collection Rule will be created in the management subscription and associated to virtual machines deployed to the Azure environment via a policy definition. This will not be applied to virtual machines running with the Azure VMware Services environment.

Table 8.1‑2 – Data Collection Rule Configuration

Network Watcher

Azure Network Watcher provides tools to monitor, diagnose, view metrics, and enable or disable logs for resources in an Azure virtual network. Network Watcher is designed to monitor and repair the network health of infrastructure-as-a-service (IaaS) products which includes virtual machines, virtual networks, application gateways, load balancers, etc. Endpoint can be any of the following.

• Virtual Machine
• IP Address
• URI or FQDN

Figure 8.1‑2 – Network Watcher overview

It allows users to monitor and diagnose network performance issues, detect, and resolve connectivity problems, and analyse network flows to optimize network resources and security. With its wide range of tools and functionalities, Azure Network Watcher empowers supporting teams to ensure the reliability, efficiency, and security of their Azure virtual networks.

Virtual Network Flow Logs

Virtual Network flow logs is a feature of Azure Network Watcher that can log information about IP traffic flowing through an NSG. Once captured, the data can be used exported to visualisation tools, security information and event management (SIEM) solutions, or intrusion detection system (IDS).

Virtual Network Flow Logs will be captured for all virtual networks deployed.

Flow data will be sent to the following destinations in the landing zone:

Table 8.1‑3 – Flow Log Destinations

Table 8.1‑4 – Flow Log Configuration

Virtual Network Flow Logs will be configured using the following Azure Policy: See Configure virtual network to enable Flow Log and Traffic Analytics.

Azure Virtual WAN

Azure Monitor insights provide great capability and enhanced functionality to monitoring the Azure Virtual WAN service and the key network performance metrics required to support and effectively operationalise this service.

A pre-packaged metrics workbook provides a resource-level metrics view and collection which shows the metrics of virtual WAN, hubs, gateways, and connections.

This is available via the Azure Portal on the Azure Virtual WAN blade under “Insights”

Figure 8.1‑3 – Azure Virtual WAN Insights

Action Groups

Azure Monitor, Service Health, Resource Health and Recovery Service Vaults use action groups to notify users that an alert has been triggered. Various alerts may use the same action group or different action groups depending on the user’s requirements. The following action groups notification methods are available.

1. Email
2. Webhook; these are attempted a maximum of 3 times and can be integrated into workflow management systems such as ServiceNow
3. Pager/SMS
4. Voice; not currently available in Australia.

The following Actions Group will be created to support alert notifications for Service Australia:

Table 8.1‑5 – Action Group – Non-critical Alerts

Table 8.1‑6 – Action Group – Critical Alerts

Backup

Azure Backup is a Backup-as-a-Service solution that extends tried-and-trusted tools on-premises with rich and powerful tools in the cloud. It delivers protection for data no matter where it resides: in the enterprise data centre, in remote and branch offices, or in the public cloud, while being sensitive to the unique requirements these scenarios present.

Recovery Services Vaults

A Recovery Services Vault is a storage entity in Azure that houses data, typically copies of data, or configuration information for virtual machines (VMs), workloads, servers, or workstations. You can use to hold backup data for various Azure services such as IaaS VMs (Linux or Windows) and Azure SQL databases. Recovery Services Vaults support System Center DPM, Windows Server, Azure Backup Server, and more. Recovery Services Vaults make it easy to organize your backup data, while minimizing management overhead.

Recovery Services Vaults provide an option to store backups in locally redundant storage (i.e., within a single Azure Region) or geo-redundant storage (across two Azure Regions, hundreds of kilometres apart), these settings are only configurable at initial deployment (they cannot be altered after the first backup) of RSV and must be carefully considered to ensure adequate replication is achieved as per your underlying BCDR strategy.

Recovery Services vaults will be provisioned into dedicated resource groups within each Landing Zone subscription, the resource group naming convention is rrg-aue-[environment]-[descriptor]-01.

Table 8.2‑1 – Recovery Service Vault Configuration

Backup Policy

Policies can be defined based on the type of data to be backed up (e.g., virtual machine, SQL Server etc), recovery time objective (RTO) and recovery point objective (RPO) requirements, operational or regulatory compliance needs, and workload type (e.g., VM, database, files).

Backups are stored in a Recovery Services vault with built-in management of recovery points. You can restore data with application consistency using VSS snapshot (Windows) and fsfreeze (Linux). Backup data is encrypted at rest and can be kept for extended period. Configuration and scaling are simple, backups are optimized, and you can easily restore as needed.

Each policy consists of:

• Backup frequency (when to take backup)
• Start time (when to take backup)
• Retention period for daily, weekly, monthly, and yearly backups (how long to retain the backups)

The following policies will be deployed to all Recovery Service Vaults created during foundation build:

Table 8.2‑2 – Backup Policies

Azure Update Manager

Azure Update Manager is a comprehensive service provided by Microsoft Azure that simplifies and automates the process of managing updates and patches for virtual machines (VMs) and virtual machine scale sets (VMSS). It centralises the management of updates across multiple Azure subscriptions and regions, offering a unified view and control over the update status of VMs.

Azure Update Manager provides a consolidated dashboard to view the compliance status, schedule update deployments, and track the progress of updates. It supports both Windows and Linux operating systems, allowing administrators to define update deployment schedules, configure maintenance windows, and customize update settings as per their specific requirements. With its automation capabilities, Azure Update Manager orchestrates the installation of updates, ensuring VMs stay up to date with the latest security patches and bug fixes.

Figure 8.3‑1 – Azure Update Manager

Maintenance Configurations

Virtual machines naturally have varying purposes which generally results in different maintenance requirements and times of operation. Typically, in a non-production environment, power off and reboot activities are acceptable as they form part of the cost optimisation efforts of operating within a cloud environment. Adversely, this could prove disruptive in a production environment if scheduled reboots or power cycles are not planned.

Azure Update Manager provides a capability to attach virtual machines to schedules based on selection criteria (such as tags), which allows for structure and control on maintenance windows for targeted machines. The maintenance configurations set the allowed time for installation of updates and defines what reboot settings should be used.

It is important to note that the maintenance configuration schedule requires a time zone. This must be considered in a multi–Geo-Region scenario.

Updates are classified into update types detailed below.

• Critical Updates: Specifies a widely released fix for a specific problem that addresses a critical, non-security-related bug.
• Definition Updates: Specifies a widely released and frequent software update that contains additions to a product’s definition database.
• Feature Packs: Specifies new product functionality that is first distributed outside of a product release and that’s typically included in the next full product release.
• Security Updates: Specifies a widely released fix for a product-specific, security-related vulnerability.
• Service Packs: Specifies a tested, cumulative set of all hotfixes, security updates, critical updates, and updates that are applied to a product. Additionally, service packs may contain additional fixes for problems that are found internally since the release of the product.
• Tools: Specifies a utility or feature that helps to complete one or more tasks.
• Update Rollups: Specifies a tested, cumulative set of hotfixes, security updates, critical updates, and updates that are packaged together for easy deployment. An update rollup generally addresses a specific area, such as a security or product component.
• Updates: Specifies a widely released fix for a specific problem. An update addresses a non-critical, non-security-related bug.
• Upgrade: Specifies an upgrade for Windows functionality. These updates are also known as feature updates for Windows operating systems.

Maintenance Configuration Schedules

Schedules can include Windows and Linux in a single maintenance configuration.

The maintenance configuration name in the first column below will be identical to the tag value for each virtual machine and accompanying schedule.

Figure 8.3‑2 – Patch Schedule Configuration

Virtual Machine Onboarding

Virtual machines onboarded deployed within the SCXX landing zones will have to onboarded to the Azure update manager service. There are 2 methods to achieve the onboarding:

is a flexible method to group Azure Virtual machines to maintenance configurations. This allows you to onboard machines based on criteria such as subscription, resource group, location, resource type, OS type, and tags. They are considered “dynamic” as the virtual machines associated to the maintenance configuration are determined at the start of each maintenance window.

You can use dynamic scoping to group machines based on their characteristics and create a maintenance configuration that includes all the machines that meet the criteria. This approach is ideal when you onboard virtual machines that share common characteristics but don’t have the same tag.

Azure policy-based onboarding: This allows you to onboard machines based solely on PatchingSchedule tag assigned to the virtual machine.

The tag value can be used to group machines based on their characteristics, such as the operating system, location, or environment. These tags are used to create a maintenance configuration that are used to identify a target set of virtual machines. This approach is ideal when you onboard machines that share common characteristics.

In both cases, there is a requirement to apply a maintenance configuration and schedule based on a tag. The following table outlines the pros and cons of each approach:

Table 8.3‑1 – Update Manager Onboarding Options

Dynamic Scope schedule association

Dynamic Scopes[19] is a flexible method to group Azure Virtual machines to maintenance configurations. This allows you to onboard machines based on criteria such as subscription, resource group, location, resource type, OS type, and tags. They are considered “dynamic” as the virtual machines associated to the maintenance configuration are determined at the start of each maintenance window.

You can use dynamic scoping to group machines based on their characteristics and create a maintenance configuration that includes all the machines that meet the criteria. This approach is ideal when you onboard virtual machines that share common characteristics but don’t have the same tag.

[1] Microsoft Entra multifactor authentication versions and consumption plans – Microsoft Entra ID | Microsoft Learn

[2] What are Azure availability zones? | Microsoft Learn

[3] Manage resource groups – Azure portal – Azure Resource Manager | Microsoft Learn

[4] https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mfa-howitworks

[5] https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview

[6] https://www.microsoft.com/en-au/security/business/microsoft-entra-pricing

[7] https://learn.microsoft.com/en-us/azure/role-based-access-control/overview

[8] https://learn.microsoft.com/en-us/azure/role-based-access-control/conditions-overview

[9] https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits#azure-policy-limits

[10] https://learn.microsoft.com/en-us/azure/virtual-wan/virtual-wan-about

[11] https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview

[12] https://learn.microsoft.com/en-us/azure/firewall/dns-settings

[13] https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances?tabs=redhat#azure-provided-name-resolution

[14] https://learn.microsoft.com/en-us/azure/security/fundamentals/network-best-practices

[15] https://learn.microsoft.com/en-us/azure/firewall/policy-rule-sets

[16] https://learn.microsoft.com/en-us/azure/key-vault/general/overview

[17] https://learn.microsoft.com/en-us/azure/security/fundamentals/feature-availability#microsoft-defender-for-cloud

[18] https://learn.microsoft.com/en-us/azure/update-manager/dynamic-scope-overview?tabs=avms

[19] https://learn.microsoft.com/en-us/azure/update-manager/dynamic-scope-overview?tabs=avms