← Back to Dashboard

Design 27: Policy & Governance

Summary

This design implements Azure Policy to enforce compliance (e.g., "Only deploy in East US", "Require Tags").

Topology: Policies are assigned at the Management Group or Subscription level, affecting all Hub and Spoke resources.

1. Key Design Decisions (ADR)

ADR-01: Scope

  • Decision: Use Management Groups.
  • Rationale: Apply policy once to the "Corp" group, and it inherits down to "Production", "Dev", and all 50 subscriptions.

ADR-02: Effect

  • Decision: Deny for critical rules (Location), Audit for soft rules (Tags).
  • Rationale: Prevent bad deployments immediately.

2. High-Level Design (HLD)

+---------------------------------------------------------+
|  Root Management Group (Tenant Root)                    |
|                                                         |
|   +-------------------------------------------------+   |
|   |  Corp Management Group                          |   |
|   |  [Policy: Allowed Locations = East US, West US] |   |
|   |                                                 |   |
|   |   +-----------------------+                     |   |
|   |   | Subscription: Prod    |                     |   |
|   |   | (Inherits Policy)     |                     |   |
|   |   |                       |                     |   |
|   |   |   +---------------+   |                     |   |
|   |   |   |  Hub VNet     |   |                     |   |
|   |   |   +---------------+   |                     |   |
|   |   +-----------------------+                     |   |
|   +-------------------------------------------------+   |
+---------------------------------------------------------+

3. Low-Level Design (LLD)

+-----------------------------------------------------------------------+
| Policy Definition: Require-SQL-Encryption                             |
| JSON Rule: "If type is SQL and Encryption is Off -> Deny"             |
+-----------------------------------|-----------------------------------+
                                    |
                                    v
+-----------------------------------|-----------------------------------+
| Assignment: Assign-SQL-Enc-Prod                                       |
| Scope: /providers/Microsoft.Management/managementGroups/Corp          |
| Parameters: None                                                      |
+-----------------------------------|-----------------------------------+
                                    |
                                    v
+-----------------------------------|-----------------------------------+
| Compliance Scan                   |                                   |
| Result:                           |                                   |
| - vm-hub (Compliant)              |                                   |
| - sql-spoke (Non-Compliant)       |                                   |
+-----------------------------------|-----------------------------------+

4. Component Rationale

  • Initiative: A group of policies (e.g., "NIST 800-53"). Easier to assign 1 initiative than 100 policies.

5. Strategy: High Availability (HA)

  • Built-in: Azure Policy is a global service.

6. Strategy: Disaster Recovery (DR)

  • Implementation: Policy as Code.
  • Process: Keep your Policy definitions (JSON) in GitHub. If someone accidentally deletes the assignment, redeploy via DevOps pipeline.

7. Strategy: Backup

  • N/A.

8. Strategy: Security

  • Exemptions: You can exempt specific resource groups (e.g., rg-legacy) if they cannot comply yet.
  • Remediation: Policy can automatically fix resources (e.g., "Deploy Diagnostic Settings" if missing).

9. Well-Architected Framework Analysis

  • Reliability: High.
  • Security: High. Enforces security baseline.
  • Cost Optimization: High. Prevent deployment of expensive SKUs (e.g., Deny G-Series VMs).
  • Operational Excellence: High.
  • Performance Efficiency: N/A.

10. Detailed Traffic Flow

1. User: Runs az vm create --location japanwest.

2. ARM: Azure Resource Manager receives request.

3. Policy Engine: Checks "Allowed Locations" policy.

4. Match: japanwest is NOT in [East US, West US].

5. Deny: ARM rejects the request.

6. Output: "Deployment failed due to Policy violation."

11. Runbook: Deployment Guide (Azure Portal)

11. Runbook: Deployment Guide (Azure Portal)

Phase 1: Create Policy Definition

1. Search: "Policy" -> Definitions.

2. + Policy definition.

3. Definition location: Select your Management Group (e.g., Corp) or Subscription.

4. Name: Audit-Storage-Public-Access.

5. Category: Storage.

6. Policy Rule:

* Paste the JSON rule (or select "Use existing" and find "Storage accounts should disable public network access").

* *Tip: Using built-in policies is safer.*

7. Save.

Phase 2: Assign Policy

1. Go to Assignments -> Assign policy.

2. Basics:

* Scope: Select Subscription: Production.

* Policy definition: Select Audit-Storage-Public-Access.

* Assignment name: Enforce-Secure-Storage.

3. Parameters:

* Effect: Audit (Start with Audit) or Deny (Block new deployments).

4. Remediation:

* Uncheck "Create a Managed Identity" (unless using DeployIfNotExists).

5. Review + create -> Create.

Phase 3: Verify Compliance

1. Wait 30 minutes (Policy evaluation cycle).

2. Go to Compliance (Left Menu).

3. Find Enforce-Secure-Storage.

4. Status:

* Compliant: All storage accounts have public access disabled.

* Non-compliant: Click to see which accounts are violating the rule.

Phase 4: Remediation (Optional)

1. If you have non-compliant resources, click Create Remediation Task.

2. Azure will attempt to modify the resources (if the policy supports Modify or DeployIfNotExists) to fix the setting.

* *Note: Deny policies do not remediate existing resources; they only block new ones.*