Update OZ subnet name to App Management Zone (Azure#217)

config/subscriptions/CanadaESLZ-main/pubsec/LandingZones/DevTest/4f9f8765-911a-4a6d-af60-4bc0473268c0_generic-subscription_canadacentral.json

@@ -107,7 +107,7 @@
                 ],
                 "subnets": {
                     "oz": {
-                        "comments": "Foundational Elements Zone (OZ)",
+                        "comments": "App Management Zone (OZ)",
                         "name": "oz",
                         "addressPrefix": "10.2.1.0/25",
                         "nsg": {

config/subscriptions/CanadaESLZ-main/pubsec/LandingZones/DevTest/82f7705e-3386-427b-95b7-cbed91ab29a7_healthcare_canadacentral.json

@@ -123,7 +123,7 @@
                 ],
                 "subnets": {
                     "oz": {
-                        "comments": "Foundational Elements Zone (OZ)",
+                        "comments": "App Management Zone (OZ)",
                         "name": "oz",
                         "addressPrefix": "10.5.1.0/25"
                     },

config/subscriptions/CanadaESLZ-main/pubsec/LandingZones/DevTest/8c6e48a4-4c73-4a1f-9f95-9447804f2c98_machinelearning_canadacentral.json

@@ -144,7 +144,7 @@
         ],
         "subnets": {
           "oz": {
-            "comments": "Foundational Elements Zone (OZ)",
+            "comments": "App Management Zone (OZ)",
             "name": "oz",
             "addressPrefix": "10.6.1.0/25"
           },

config/subscriptions/CanadaESLZ-main/pubsec/LandingZones/DevTest/ec6c5689-db04-4f1e-b76d-834a51dd0e27_machinelearning_canadacentral.json

@@ -148,7 +148,7 @@
         ],
         "subnets": {
           "oz": {
-            "comments": "Foundational Elements Zone (OZ)",
+            "comments": "App Management Zone (OZ)",
             "name": "oz",
             "addressPrefix": "10.1.1.0/25"
           },

config/subscriptions/CanadaESLZ-main/pubsec/LandingZones/DevTest/f08c3057-1713-4a6f-b7e6-0df355b60c30_machinelearning_canadacentral.json

@@ -148,7 +148,7 @@
         ],
         "subnets": {
           "oz": {
-            "comments": "Foundational Elements Zone (OZ)",
+            "comments": "App Management Zone (OZ)",
             "name": "oz",
             "addressPrefix": "10.3.1.0/25"
           },

config/subscriptions/CanadaESLZ-main/pubsec/LandingZones/DevTest/f459218a-e8bb-49c9-b768-ee6828a144aa_machinelearning_canadacentral.json

@@ -149,7 +149,7 @@
         ],
         "subnets": {
           "oz": {
-            "comments": "Foundational Elements Zone (OZ)",
+            "comments": "App Management Zone (OZ)",
             "name": "oz",
             "addressPrefix": "10.4.1.0/25"
           },

config/subscriptions/devopsincanada-main/pubsec/LandingZones/DevTest/248e2ceb-23b4-41e7-bd3f-3d28594ca842_generic-subscription_canadacentral.json

@@ -104,7 +104,7 @@
                 ],
                 "subnets": {
                     "oz": {
-                        "comments": "Foundational Elements Zone (OZ)",
+                        "comments": "App Management Zone (OZ)",
                         "name": "oz",
                         "addressPrefix": "10.11.1.0/25",
                         "nsg": {

config/subscriptions/devopsincanada-main/pubsec/LandingZones/DevTest/802e608f-f31b-4a10-86da-7fbb8f660a10_generic-subscription_canadacentral.json

@@ -105,7 +105,7 @@
                 ],
                 "subnets": {
                     "oz": {
-                        "comments": "Foundational Elements Zone (OZ)",
+                        "comments": "App Management Zone (OZ)",
                         "name": "oz",
                         "addressPrefix": "10.10.1.0/25",
                         "nsg": {

docs/archetypes/generic-subscription.md

@@ -256,7 +256,7 @@ This example configures:
                 ],
                 "subnets": {
                     "oz": {
-                        "comments": "Foundational Elements Zone (OZ)",
+                        "comments": "App Management Zone (OZ)",
                         "name": "oz",
                         "addressPrefix": "10.2.1.0/25",
                         "nsg": {

docs/archetypes/healthcare.md

@@ -416,7 +416,7 @@ This example configures:
                 ],
                 "subnets": {
                     "oz": {
-                        "comments": "Foundational Elements Zone (OZ)",
+                        "comments": "App Management Zone (OZ)",
                         "name": "oz",
                         "addressPrefix": "10.5.1.0/25"
                     },

docs/archetypes/machinelearning.md

@@ -453,7 +453,7 @@ This example configures:
         ],
         "subnets": {
           "oz": {
-            "comments": "Foundational Elements Zone (OZ)",
+            "comments": "App Management Zone (OZ)",
             "name": "oz",
             "addressPrefix": "10.4.1.0/25"
           },

docs/architecture.md

@@ -23,7 +23,6 @@ This document describes the architecture and design decisions for building a **[
 8. [Archetypes](\#8-archetypes)
 9. [Automation](\#9-automation)
 
-
 ---
 
 ## 1. Key Decisions
@@ -35,7 +34,7 @@ The table below outlines the key decisions each department must consider as part
 | Private IP range for Cloud | Based on [RFC 1918][rfc1918] and [RFC 6598][rfc6598], to allow seamless routing for hybrid connectivity. | | | |
 | Ground to Cloud Network Connectivity | Use either: Express Route; or SCED for hybrid connectivity. | | | |
 | Firewalls | Central firewalls for all egress and non-HTTP/S ingress traffic to VMs. | | | |
-| Spoke Network Segmentations | Subnet Addressing & Network Security Groups. | | | |
+| Spoke Network Segmentation | Subnet Addressing & Network Security Groups. | | | |
 | Application Gateway + WAF | Application Gateway per spoke subscription to allow direct delivery for HTTP/S traffic.  WAF and routing rules are managed by CloudOps.  | | | |
 | Security Incident & Monitoring | Centralized security monitoring. | | | |
 | Logging (IaaS & PaaS) | Centralized Log Analytics Workspace with RBAC permissions to allow resource owners to access resource logs & Security Monitor to access all logs. | | | |
@@ -64,7 +63,7 @@ Azure Policy Compliance dashboard provides an up-to-date compliance view across
 
 Custom policy sets have been designed to increase compliance for logging, networking & tagging requirements.
 
-### 2.3 Policy Remediations
+### 2.3 Policy Remediation
 
 Resources that are non-compliant can be put into a compliant state through [Remediation][policyRemediation]. Remediation is accomplished by instructing Azure Policy to run the deployment instructions of the assigned policy on your existing resources and subscriptions, whether that assignment is to a management group, a subscription, a resource group, or an individual resource. This article shows the steps needed to understand and accomplish remediation with Azure Policy.
 
@@ -94,7 +93,7 @@ The compliance reporting will outline the Azure Policies, the resource types, th
 
 For custom reporting requirements, the raw compliance data can be exported using [Azure Resource Graph](https://docs.microsoft.com/azure/governance/resource-graph/overview).  This export allows for additional analysis and align to operational requirements.  A custom data export pipeline and processes will be needed to operationalize the dataset.  Primary queries to access the data are:
 
-```
+```none
 securityresources
 | where type == "microsoft.security/regulatorycompliancestandards"
 
@@ -194,7 +193,7 @@ Azure Landing Zones for Canadian Public Sector assumes that Azure Active Directo
 * App Registration - Consider disabling for all users and created on-demand by CloudOps teams.
 * Sign-In Logs - Logs are exported to Log Analytics workspace & Microsoft Sentinel used for threat hunting (Security Monitoring Team).
 * Break-glass procedure - Process documented and implemented including 2 break glass accounts with different MFA devices & split up passwords.
-*  Azure Directory to Azure Active Directory synchronization - Are the identities synchronized or using cloud only account?
+* Azure Directory to Azure Active Directory synchronization - Are the identities synchronized or using cloud only account?
 
 ### 4.1 Service Principal Accounts
 
@@ -210,6 +209,7 @@ The service principal requires `Owner` role to configure role assignments for:
 Additional service principal accounts must be created and scoped to child management groups, subscriptions or resource groups based on tasks that are expected of the service principal accounts.
 
 ### 4.2 User Accounts
+
 It is common for user accounts to have access to an Azure environment with permanent permissions.  Our recommendation is to limit permanent permissions and elevate roles using time-limited, MFA verified access through Privilege Identity Management (Azure AD PIM).
 
 All user accounts should be assigned to Security Groups and access should be granted to user accounts based on membership.
@@ -228,6 +228,7 @@ Access Control at Management Group scope enables management and oversight at sca
 | Cost Management | [Billing Reader](https://docs.microsoft.com/azure/role-based-access-control/built-in-roles#billing-reader) | - |
 
 ### 4.4 Recommendations for Subscriptions
+
 The table provides the 3 generic roles that are commonly used in Azure environment.  Granular built-in roles can be used based on use case to further limit the access control.  Our recommendation is to assign the least privileged role that is required for a person or service principal to complete the tasks.
 
 Review the [Azure Built-In roles](https://docs.microsoft.com/azure/role-based-access-control/built-in-roles) to evaluate applicability.
@@ -239,10 +240,12 @@ Review the [Azure Built-In roles](https://docs.microsoft.com/azure/role-based-ac
 | Production | Manage Azure resources | No standing management permissions in Production.<br /><br />Owner role is only required for RBAC changes, otherwise, use Contributor role or another built-in role for all other operations. | - | [Contributor](https://docs.microsoft.com/azure/role-based-access-control/built-in-roles#contributor) or [Owner](https://docs.microsoft.com/azure/role-based-access-control/built-in-roles#owner)
 
 ### 4.5 Recommendations for Resource Groups
+
 Follow the same guidance as Subscriptions.
 
 ### 4.6 Recommendations for Resources
-Due to overhead of access control and assignments, avoid assigning permissions per resource.  Consider using Resource Group or Subscription scope permissions. 
+
+Due to overhead of access control and assignments, avoid assigning permissions per resource.  Consider using Resource Group or Subscription scope permissions.
 
 ---
 
@@ -268,12 +271,12 @@ Reference implementation provides two topologies for Hub Network design:
 
 2. [Hub Networking with Fortigate Firewalls](archetypes/hubnetwork-nva-fortigate.md) (departments must configure the firewalls).  Implementation can be adopted for additional firewall ISVs.
 
-
-
 ### Azure Bastion
+
 Bastion [does not support User Defined Route](https://docs.microsoft.com/azure/bastion/bastion-faq#udr) but can work with Virtual Machines on peered virtual networks as long as the [Network Security Groups allow][nsgAzureBastion] it and the user has the [required role based access control](https://docs.microsoft.com/azure/bastion/bastion-faq#i-have-access-to-the-peered-vnet-but-i-cant-see-the-vm-deployed-there)
 
 ### Azure Application Gateway
+
 Application Gateway [does not support default UDRs to an NVA](https://docs.microsoft.com/en-us/azure/application-gateway/configuration-infrastructure):
 
 > "Any scenario where 0.0.0.0/0 needs to be redirected through any virtual appliance, a hub/spoke virtual network, or on-premise (forced tunneling) isn't supported for V2.".
@@ -316,11 +319,12 @@ The reference implementation does not deploy DNS Servers (as Virtual Machines) i
 * Leverage DNS Servers on virtual machines that are managed by department's IT.
 
 ### Spoke Landing Zone Networks
+
 Following the nomenclature of [ITSG-22][itsg22], these would be the default subnets created in the spokes as part of new subscriptions.
 
-* Presentation (PAZ) - frontend web servers (not exposed to the internet, using RFC1918 IPs that only receive traffic via the application delivery controllers or L7 firewalls in the PAZ).
-* Application (RZ) - middleware application servers (only allow connections from the frontend).
-* Data (HRZ) - backend servers (only allow connections from the application RZ).
+* Presentation Zone (PAZ) - frontend web servers (not exposed to the internet, using RFC1918 IPs that only receive traffic via the application delivery controllers or L7 firewalls in the PAZ).
+* Application Zone (RZ) - middleware application servers (only allow connections from the frontend).
+* Data Zone (HRZ) - backend servers (only allow connections from the application RZ).
 * App Management Zone (OZ), an optional network for app management servers in the spoke.
 * All zones would allow management traffic from the Management Access Zone (OZ).
 
@@ -329,6 +333,7 @@ Following the nomenclature of [ITSG-22][itsg22], these would be the default subn
 ## 6. Logging
 
 ### 6.1 Scope
+
 Microsoft's recommendation is [one central Log Analytics workspace](https://docs.microsoft.com/azure/azure-monitor/logs/design-logs-deployment#important-considerations-for-an-access-control-strategy) that will be shared by IT, Security Analysts and Application Teams.
 
 The design and recommendation are based on the following requirements:
@@ -393,7 +398,7 @@ For example, when you grant access to your team responsible for infrastructure s
 
 ## 7. Tagging
 
-Organize cloud assets to support governance, operational management, and accounting requirements. Well-defined metadata tagging conventions help to quickly locate and manage resources. These conventions also help associate cloud usage costs with business teams via chargeback and show back accounting mechanisms.
+Organize cloud assets to support governance, operational management, and accounting requirements. Well-defined metadata tagging conventions help to quickly locate and manage resources. These conventions also help associate cloud usage costs with business teams via charge back and show back accounting mechanisms.
 
 A tagging strategy include business and operational details:
 
@@ -485,7 +490,7 @@ To simplify, let's assume a single `CostCenter` tag is required for every resour
 
 There are 3 principles that are being followed to help automate Azure Landing Zones for Canadian Public Sector design:
 
-* Start with Automation – We must automate all configurations.  There will be activities that are needed once or twice, but those too should be automated so that they can be applied consistently in many tenants.  Procedures that don't have a reasonable means to automate should be documented as manual steps. 
+* Start with Automation – We must automate all configurations.  There will be activities that are needed once or twice, but those too should be automated so that they can be applied consistently in many tenants.  Procedures that don't have a reasonable means to automate should be documented as manual steps.
 
 * Reduce security surface – Automation accounts can have broad access control and we must limit the permissions when reasonably possible.  Start with least-privilege accounts as described in this document.  Least-privilege accounts will reduce the attack surface and create separation of duty.
 
@@ -529,12 +534,12 @@ All pipelines are in **.pipelines/** folder.
 
 Pipelines are stored as YAML definitions in Git and imported into Azure DevOps Pipelines.  This approach allows for portability and change tracking.  To import a pipeline:
 
-1.  Go to Pipelines
-2.  New Pipeline
-3.  Choose Azure Repos Git
-4.  Select Repository
-5.  Select Existing Azure Pipeline YAML file
-6.  Identify the pipeline using the table below and add.
+1. Go to Pipelines
+2. New Pipeline
+3. Choose Azure Repos Git
+4. Select Repository
+5. Select Existing Azure Pipeline YAML file
+6. Identify the pipeline using the table below and add.
 
 Use the [Azure DevOps Pipelines](onboarding/azure-devops-pipelines.md) onboarding guide to configure each pipeline.
 
@@ -552,7 +557,6 @@ Use the [Azure DevOps Pipelines](onboarding/azure-devops-pipelines.md) onboardin
 | Subscriptions | subscription.yml | subscription-ci | Configures a new subscription based on the archetype defined in the configuration file name. | spn-azure-platform-ops | None |
 | Pull Request Validation | pull-request-check.yml | pull-request-validation-ci | Checks for breaking changes to Bicep templates & parameter schemas prior to merging the change to main branch.  This pipeline must be configured as a check for the `main` branch. | spn-azure-platform-ops | None |
 
-
 ### 9.4 Release Process
 
 By using gates, approvals, and manual intervention you can take full control of your releases to meet a wide range of deployment requirements. Typical scenarios where approvals, gates, and manual intervention are useful include the following.
@@ -574,27 +578,27 @@ You can combine all three techniques within a release pipeline to fully achieve
 
 Manual validation can be done in one of two ways:
 
-1.  Add an agentless (server) job before the existing pipeline job(s) where you want to enforce pre-deployment user validation.
+1. Add an agentless (server) job before the existing pipeline job(s) where you want to enforce pre-deployment user validation.
 
-2.  Create an Environment (or multiple environments) in your Azure DevOps project where you can specify pre-deployment user validations via "Approvals and checks".
+2. Create an Environment (or multiple environments) in your Azure DevOps project where you can specify pre-deployment user validations via "Approvals and checks".
 
 We will focus on the second option, as it allows for the following additional types of approvals and checks:
 
 ![Azure DevOps - Checks](media/architecture/ado-approvals-checks.jpg)
 
 Steps to implement user validation (approval) check:
 
-1.  Create an Environment named after the branch (e.g. "main", "sandbox") you want to protect. You can do this manually through the web UI or by running the pipeline (if the environment does not exist, it will be created).
+1. Create an Environment named after the branch (e.g. "main", "sandbox") you want to protect. You can do this manually through the web UI or by running the pipeline (if the environment does not exist, it will be created).
 
-2.  In the web UI, navigate to Pipelines | Environments, select the environment corresponding to the branch you want to protect, and select "Approvals and checks" from the context menu.
+2. In the web UI, navigate to Pipelines | Environments, select the environment corresponding to the branch you want to protect, and select "Approvals and checks" from the context menu.
 
-3.  Select the "Approval" option to add a new user validation approval.
+3. Select the "Approval" option to add a new user validation approval.
 
-4.  Add user(s)/group(s) to the "Approvers" field. Approval check will require approval from all listed users/groups. For a group approval, any one member of the group is sufficient for approval. Note that you may use Azure DevOps and Azure Active Directory groups and may want to do this to minimize administrative overhead associated with managing individual users roles and responsibilities.
+4. Add user(s)/group(s) to the "Approvers" field. Approval check will require approval from all listed users/groups. For a group approval, any one member of the group is sufficient for approval. Note that you may use Azure DevOps and Azure Active Directory groups and may want to do this to minimize administrative overhead associated with managing individual users roles and responsibilities.
 
-5.  Under "Advanced" options, decide if you want to allow users in the Approvers list to approve their own pipeline runs.
+5. Under "Advanced" options, decide if you want to allow users in the Approvers list to approve their own pipeline runs.
 
-6.  Under "Control options", set an appropriate "Timeout" after which approval requests will expire. The default is 30 days, however you may wish to reduce this time window. 
+6. Under "Control options", set an appropriate "Timeout" after which approval requests will expire. The default is 30 days, however you may wish to reduce this time window.
 
 [itsg33]: https://www.cyber.gc.ca/en/guidance/it-security-risk-management-lifecycle-approach-itsg-33
 [itsg22]: https://www.cyber.gc.ca/sites/default/files/publications/itsg-22-eng.pdf

landingzones/lz-generic-subscription/networking.bicep

@@ -51,7 +51,7 @@ param hubNetwork object
 //       ],
 //       "subnets": {
 //           "oz": {
-//               "comments": "Foundational Elements Zone (OZ)",
+//               "comments": "App Management Zone (OZ)",
 //               "name": "oz",
 //               "addressPrefix": "10.2.1.0/25",
 //               "nsg": {
@@ -131,7 +131,7 @@ param hubNetwork object
 //   ]
 //   subnets: {
 //     oz: {
-//       comments: 'Foundational Elements Zone (OZ)'
+//       comments: 'App Management Zone (OZ)'
 //       name: 'oz'
 //       addressPrefix: '10.2.1.0/25'
 //       nsg: {