Azure Landing Zone Governance: Policy ve velkém

S příchodem NIS2 v Česku se governance v cloudu přesunul z kategorie "bylo by fajn" do kategorie "povinnost". Najednou nestačí mít Azure Landing Zone se správnou síťovou architekturou z druhého dílu -- musíte také prokazatelně doložit, že vaše prostředí splňuje bezpečnostní politiky, že máte auditní stopu změn a že noncompliantní zdroje jsou identifikované a řešené. Azure Policy je nástroj, který tohle řeší na úrovni platformy, ne na úrovni dokumentů a tabulek.

Náročnost: 2-3 dny na policy framework, průběžně 2 hodiny/týden na compliance review Náklady: 0 $ (Azure Policy je zdarma; Defender for Cloud CSPM přidá cca 15 $/server/měsíc dle potřeby) Předpoklady: Dokončený základ Landing Zone (1. díl) a networking (2. díl), hierarchie Management Groups, role Global Administrator nebo Policy Contributor

Co se změnilo v roce 2025

Governance ekosystém v Azure prošel zásadní proměnou.

Azure Blueprints jdou do důchodu. Microsoft formálně deprecated Blueprints a oznámil end-of-life na rok 2026. Náhrada je kombinace Azure Policy a Bicep/Terraform pro nasazení. Pokud ještě provozujete Blueprints, migrační cesta je export blueprint artefaktů jako ARM/Bicep šablon a konverze policy assignments na samostatné Azure Policy zdroje.

Policy exemptions jsou v GA. Dříve bylo řešení výjimek z politik trápení. Buď jste měli exclusion scopy (které platily pro celou resource group), nebo jste politiku vypnuli úplně. Teď můžete vytvořit časově omezenou výjimku na konkrétní zdroj s polem pro zdůvodnění, které se zobrazí v compliance reportech. Pro produkční prostředí, kde občas potřebujete pravidla porušit s auditní stopou, je to klíčové.

Azure Verified Modules (AVM) nahrazují CAF enterprise-scale modul. Starý terraform-azurerm-caf-enterprise-scale je v extended support a bude archivován v srpnu 2026. AVM moduly jsou menší, skládatelné a udržované přímo Microsoft engineering týmy. Pro nové Landing Zone použijte AVM. Pro existující naplánujte migraci.

Regulatory Compliance dashboard podporuje vlastní frameworky. Vestavěný compliance dashboard nově umožňuje mapovat interní bezpečnostní baseline vedle standardních frameworků (PCI DSS, ISO 27001). Pro české firmy řešící NIS2 to znamená, že si můžete vytvořit vlastní NIS2 compliance framework a sledovat procento splnění per management group.

Proč na tom záleží

Bez policy guardrails vyhrává entropie. Typický průběh, který vidím u českých enterprise klientů s Azure Landing Zone:

Měsíc 1-2: Vše nasazeno přes Bicep pipeline. Architektura je čistá, jmenná konvence dodržena. Měsíc 3: Vývojář vytvoří přes portál storage account "jen na test." Public blob access zapnutý, žádné tagy. Měsíc 4: Další tři zdroje přes portál. Bez tagů. Bez naming convention. Jeden VM s public IP "pro debugging." Měsíc 6: Alert na náklady: 400 000 Kč/měsíc -- o 130 000 Kč nad budget. Dvanáct zdrojů bez owner tagu, VM se zapomenutým Docker kontejnerem pro demo, dva disky odpojené od VM, které nikdo nesmazal.

Řešení nebyla governance dokumentace. Řešení bylo Azure Policy vynucující:

• Deny public IP na VM, pokud není explicitně povoleno výjimkou
• Deny storage accounty bez HTTPS-only
• Audit zdroje bez povinných tagů (CostCenter, Owner, Environment)
• DeployIfNotExists pro automatické zapnutí diagnostických logů na každém novém zdroji

Po nasazení politik další compliance scan ukázal pokles noncompliantních zdrojů z 38 na 2 (oba s dokumentovanou výjimkou).

Implementace: Policy Framework v Bicepu

Framework má čtyři komponenty: vlastní definice politik, policy iniciativa (seskupení souvisejících politik), přiřazení na úrovni Management Group a compliance dashboard query.

Vlastní definice politiky: Zákaz Public IP na VM

// modules/governance/policy-deny-public-ip.bicep
// Vlastní politika: zákaz připojení public IP k síťovému rozhraní VM
 
targetScope = 'managementGroup'
 
param managementGroupId string
 
resource policyDefinition 'Microsoft.Authorization/policyDefinitions@2023-04-01' = {
  name: 'policy-deny-public-ip-vm'
  properties: {
    displayName: 'Zakázat public IP adresy na virtuálních strojích'
    description: 'Brání připojení public IP k síťovým rozhraním VM. Výjimky dostupné pro jump boxy a alternativy k bastionu.'
    policyType: 'Custom'
    mode: 'All'
    metadata: {
      category: 'Network'
      version: '1.0.0'
    }
    policyRule: {
      if: {
        allOf: [
          {
            field: 'type'
            equals: 'Microsoft.Network/networkInterfaces'
          }
          {
            field: 'Microsoft.Network/networkInterfaces/ipConfigurations[*].publicIpAddress.id'
            notEquals: ''
          }
        ]
      }
      then: {
        effect: 'Deny'
      }
    }
  }
}
 
output policyDefinitionId string = policyDefinition.id

Policy Iniciativa: Landing Zone Security Baseline

// modules/governance/initiative-security-baseline.bicep
// Seskupení souvisejících bezpečnostních politik do jedné přiřaditelné iniciativy
 
targetScope = 'managementGroup'
 
param denyPublicIpPolicyId string
param managementGroupId string
 
resource initiative 'Microsoft.Authorization/policySetDefinitions@2023-04-01' = {
  name: 'initiative-landing-zone-security-baseline'
  properties: {
    displayName: 'Landing Zone Security Baseline'
    description: 'Základní bezpečnostní politiky pro všechny Landing Zone subscriptions. Pokrývá síťovou izolaci, šifrování a tagování.'
    policyType: 'Custom'
    metadata: {
      category: 'Security'
      version: '1.0.0'
    }
    policyDefinitions: [
      {
        policyDefinitionId: denyPublicIpPolicyId
        policyDefinitionReferenceId: 'denyPublicIpOnVm'
        parameters: {}
      }
      {
        // Built-in: Storage accounts musí používat HTTPS
        policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/404c3081-a854-4457-ae30-26a93ef643f9'
        policyDefinitionReferenceId: 'storageHttpsOnly'
        parameters: {}
      }
      {
        // Built-in: Vyžadovat tag na zdrojích
        policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/871b6d14-10aa-478d-b466-ef391e9b22ef'
        policyDefinitionReferenceId: 'requireOwnerTag'
        parameters: {
          tagName: {
            value: 'Owner'
          }
        }
      }
      {
        // Built-in: Vyžadovat tag na zdrojích
        policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/871b6d14-10aa-478d-b466-ef391e9b22ef'
        policyDefinitionReferenceId: 'requireCostCenterTag'
        parameters: {
          tagName: {
            value: 'CostCenter'
          }
        }
      }
    ]
  }
}
 
output initiativeId string = initiative.id

Přiřazení na Management Group

// modules/governance/assign-initiative.bicep
// Přiřazení security baseline iniciativy na Landing Zones management group
 
targetScope = 'managementGroup'
 
param initiativeId string
param managementGroupName string
 
resource assignment 'Microsoft.Authorization/policyAssignments@2023-04-01' = {
  name: 'assign-lz-security-baseline'
  properties: {
    displayName: 'Landing Zone Security Baseline Assignment'
    description: 'Vynucuje základní bezpečnostní politiky napříč všemi Landing Zone subscriptions'
    policyDefinitionId: initiativeId
    enforcementMode: 'Default'
    nonComplianceMessages: [
      {
        message: 'Tento zdroj porušuje Landing Zone security baseline. Pro výjimky kontaktujte platformní tým: platform-team@firma.cz'
      }
      {
        message: 'Public IP adresy nejsou povoleny na virtuálních strojích. Použijte Azure Bastion nebo požádejte o výjimku pro jump box.'
        policyDefinitionReferenceId: 'denyPublicIpOnVm'
      }
    ]
  }
}
 
output assignmentId string = assignment.id

Pole nonComplianceMessages je detail, který většina lidí přeskočí, ale výrazně mění uživatelskou zkušenost. Když vývojáři deployment selže kvůli politice, standardně vidí jen generické "RequestDisallowedByPolicy." S custom zprávou vidí konkrétně, co je blokuje a na koho se obrátit. U jednoho klienta v Praze tato jednoduchá změna snížila počet support ticketů na platformní tým o zhruba třetinu.

Compliance Dashboard Query (Azure Resource Graph)

PolicyResources
| where type == 'microsoft.policyinsights/policystates'
| where properties.complianceState != 'Compliant'
| extend
    resourceId = tostring(properties.resourceId),
    policyName = tostring(properties.policyDefinitionName),
    complianceState = tostring(properties.complianceState),
    timestamp = todatetime(properties.timestamp)
| summarize
    nonCompliantCount = count(),
    latestEvaluation = max(timestamp)
    by policyName
| order by nonCompliantCount desc

Tento dotaz spustíte v Azure Resource Graph Exploreru nebo ho napojíte na Azure Monitor workbook pro týdenní compliance email. Pro NIS2 reporting je klíčové mít tato data automatizovaná -- ruční kontrola stovek zdrojů jednoduše nescaluje.

Výsledky z praxe

Po nasazení policy frameworku u klienta s Landing Zone rozdělenou do tří management groups (Platform, Landing Zones, Sandbox) vypadal compliance stav po 30 dnech takto:

$ az policy state summarize \
    --management-group "mg-landing-zones" \
    --query 'results.{total:resourceDetails[0].count, compliant:resourceDetails[1].count, nonCompliant:resourceDetails[2].count}' \
    --output table

Total    Compliant    NonCompliant
-------  -----------  --------------
287      285          2

Dva noncompliantní zdroje měly dokumentované výjimky: staging VM s public IP pro integrační test dodavatele (výjimka expiruje za 14 dní) a storage account vyžadující HTTP kvůli kompatibilitě s legacy aplikací (migrační ticket založen).

Nejsilnější dopad měla politika vyžadující tagy. Před nasazením mělo tagy Owner a CostCenter jen 55 % zdrojů. Po měsíci v "Audit" režimu a následném přepnutí na "Deny" compliance dosáhla 98,6 %. Když finanční ředitel požadoval odpověď na "kdo provozuje ten VM za 90 000 Kč měsíčně," odpověď trvala 30 sekund místo tří dnů.

Reálný příklad auto-remediace: vývojář vytvořil Key Vault přes portál bez zapnutí diagnostického logování. Politika typu DeployIfNotExists automaticky do 15 minut vytvořila diagnostic setting směrující audit logy do centrálního Log Analytics workspace. Vývojář o tom ani nevěděl -- a přesně o to jde.

Klíčové poznatky

• Začněte režimem "Audit," přepněte na "Deny" po 30 dnech. Nasazení nových politik rovnou v Deny režimu rozbije existující deploymenty a znepřátelí si vývojáře. Nejdřív audit, komunikujte timeline, pak vynucujte.
• Používejte policy iniciativy, ne jednotlivá přiřazení. Dvacet individuálně přiřazených politik na úrovni management group vytvoří neudržovatelný seznam. Seskupte je do 3-5 iniciativ podle domény (security, networking, tagging, cost).
• Přidejte custom non-compliance messages ke každému přiřazení. Generická chyba "RequestDisallowedByPolicy" vývojářům nic neříká. Zpráva s názvem politiky, důvodem a kontaktem dramaticky snižuje tření.
• Migrujte z Azure Blueprints hned. S oznámeným retirement v 2026 čekání zvyšuje náročnost migrace. Exportujte blueprint artefakty a konvertujte na Bicep + Policy assignments.
• Pro NIS2 compliance reporty propojte Resource Graph dotazy s Azure Monitor workbooky. Automatizovaný týdenní report je mnohem spolehlivější než ruční kontrola a přesně to auditoři očekávají.

Tímto dílem uzavíráme sérii Azure Landing Zone Enterprise Series. Se základy z prvního dílu, hub-spoke síťovou architekturou z druhého dílu a touto governance vrstvou máte enterprise-grade Landing Zone postavenou na třech pilířích: struktura, konektivita a compliance. Pokud vaše organizace potřebuje pomoc s návrhem nebo implementací kterékoliv z těchto vrstev, podívejte se na naše konzultační služby pro cloudovou architekturu.