Defender for Cloud va deixar Contoso Airlines amb una llista de recomanacions i una escletxa evident: detecta després. Algú crea una màquina virtual enorme en una regió equivocada i sense etiquetes, el recurs existeix, factura i apareix exposat; dies més tard una recomanació avisa i algú ha d'anar a arreglar-ho. Encara pitjor, qui ho va fer en tenia tot el dret: era Col·laborador de la subscripció, que és exactament el permís que necessita per treballar. RBAC no pot resoldre això, perquè RBAC només respon a qui. El que falta és un sistema que respongui a què, i aquest és Azure Policy: les regles del joc, aplicades en el moment de crear el recurs, amb independència de qui el creï. Amb aquesta lliçó es tanca el mòdul de seguretat i la plataforma passa d'estar assegurada a estar governada.

Avís important: les polítiques de governança i compliment tenen efectes immediats i amplis —una política amb efecte Deny mal delimitada pot aturar desplegaments legítims en producció, i un Modify mal escrit pot alterar recursos en massa—. A més, el compliment normatiu real (PCI DSS, RGPD, ENS) va molt més enllà del que una eina avalua. Abans d'aplicar qualsevol iniciativa de governança en producció, l'ha de revisar un professional de seguretat o l'equip de compliance de la teva organització.

1. RBAC davant de Policy: qui pot davant de què es pot
2. Anatomia d'una definició de política
3. Els efectes i quan fer servir cadascun
4. Assignació, àmbit, exclusions i recursos ja existents
5. Iniciatives i les integrades de compliment
6. El conjunt de polítiques de Contoso
7. Avaluació de compliment i tasques de correcció
8. Grups d'administració: l'arrel de la governança
9. De Blueprints a especificacions de plantilla i zones d'aterratge
10. El cost de la governança davant del de no tenir-ne
11. Policy i infraestructura com a codi
12. Errors Comuns i Consells
13. Exercicis
14. Conclusió

L'exemple que ho explica tot. En Diego Salas és Col·laborador de rg-contoso-reservas-dev, un permís perfectament legítim que li va concedir la Marta a 04-02. Amb ell crea una màquina virtual Standard_E64s_v5 a East US per a una prova de rendiment, sense etiquetes. Res del que ha fet no viola RBAC: tenia permís per crear recursos.

El resultat, en canvi, és un problema en quatre fronts: cost (uns 3.500 € al mes que ningú no ha pressupostat), facturació (sense centro-coste, no es pot imputar a ningú), compliment (dades que podrien acabar fora de la UE) i operació (un recurs en una regió que l'equip no monitora).

Es complementen i no se substitueixen: RBAC decideix si pots prémer el botó; Policy decideix què és acceptable que surti de prémer-lo. Fixa't en l'asimetria del model per defecte: a RBAC no pots res fins que t'ho concedeixen; a Policy ho pots tot fins que algú ho restringeix.

Element a element:

• mode: Indexed avalua només els tipus de recurs que admeten etiquetes i ubicació —és el correcte per a regions i etiquetes—; All inclou a més grups de recursos i subscripcions. Fer servir All quan toca Indexed provoca falsos incompliments en recursos que no tenen ubicació real.
• parameters: fan la política reutilitzable. La llista de regions es decideix en assignar, no en definir, de manera que la mateixa política serveix per a producció i per a un futur entorn en una altra geografia.
• policyRule.if: les condicions, combinables amb allOf (I) i anyOf (O), i imbricables. Els operadors habituals són equals, notEquals, in, notIn, like, exists i contains.
• Les dues exclusions de l'exemple no són cap adorn: molts recursos tenen ubicació global (Front Door, Traffic Manager, DNS) i bloquejar-los trencaria la plataforma; i els grups de recursos s'exclouen perquè la seva ubicació només indica on es guarden les seves metadades.
• then.effect: què fer quan la condició es compleix.

Dues diferències que convé gravar. Append davant de Modify: Append només actua en crear i no toca el que ja existeix; Modify pot corregir recursos ja creats mitjançant tasques de correcció, i per això és el que es fa servir per a etiquetes. Deny davant de DeployIfNotExists: el primer rebutja i obliga qui desplega a arreglar-ho; el segon accepta i ho arregla pel seu compte. Fes servir Deny per al que no ha d'existir mai i DeployIfNotExists per al que sempre ha d'acompanyar el recurs.

Els efectes Modify i DeployIfNotExists necessiten una identitat administrada a l'assignació, perquè Azure Policy ha d'actuar en nom teu, i aquesta identitat necessita els rols corresponents. És la causa número u de tasques de correcció que fallen.

Una definició no fa res fins que s'assigna a un àmbit: grup d'administració, subscripció o grup de recursos. L'assignació s'hereta cap avall, igual que RBAC, i admet exclusions de subàmbits concrets.

El punt que més confusió genera: què passa amb els recursos que ja existeixen.

• Un efecte Deny no elimina ni bloqueja el que ja està creat. Només actua sobre creacions i modificacions futures. Un recurs preexistent que l'incompleix apareix com a no conforme, i saltarà el bloqueig la propera vegada que algú intenti modificar-lo (efecte secundari que sorprèn: una actualització rutinària comença a fallar).
• Els efectes Audit i AuditIfNotExists avaluen tot el que existeix i ho reporten.
• Modify i DeployIfNotExists poden arreglar el que existeix, però només si es llança una tasca de correcció explícita (apartat 7).

D'aquí la seqüència de desplegament correcta, anàloga a la del WAF a 04-04: assignar en Audit, mesurar l'incompliment real, corregir el que existeix, comunicar la data i només aleshores canviar l'efecte a Deny.

Una iniciativa (o conjunt de directives) agrupa polítiques que s'assignen i es mesuren juntes. Avantatges: una sola assignació, paràmetres compartits i una única vista de compliment. Contoso crea la iniciativa «Base de gobernanza de Contoso» amb les sis polítiques de l'apartat següent.

Azure porta iniciatives integrades per a estàndards complets: Microsoft Cloud Security Benchmark (assignada per defecte), PCI DSS 4.0, ISO 27001, CIS Azure Foundations, NIST SP 800-53 i l'ENS espanyol. Són la contrapartida del tauler de compliment de Defender de la lliçó anterior: allà en veies el resultat, aquí hi ha el mecanisme que l'avalua. Gairebé totes les seves polítiques són de tipus Audit, precisament perquè un estàndard serveix per mesurar, no per bloquejar desplegaments.

Tres comentaris sobre aquest bloc. La política d'etiquetes obligatòries s'assigna quatre vegades perquè la integrada accepta una etiqueta per assignació; l'ordre importa: la d'herència (Modify) s'ha d'avaluar abans que la d'exigència, o els desplegaments sense centro-coste serien rebutjats en lloc de completats automàticament. L'assignació d'herència crea una identitat administrada amb --mi-system-assigned i li dona el rol Col·laborador a l'àmbit: sense això, la política s'assigna correctament i la correcció falla sempre.

En falten dues més. La de mides de VM en desenvolupament s'assigna només a la subscripció de desenvolupament, perquè en producció les restriccions són unes altres:

I la de diagnòstic automàtic, el cas canònic de DeployIfNotExists, que resol d'arrel la recomanació número 7 de Defender (04-05): en lloc de configurar catorze recursos a mà, la política els configura i configura també tots els futurs.

Azure Policy avalua en tres moments, i convé conèixer-los perquè expliquen gairebé tots els dubtes del tipus «he assignat la política i no passa res»:

• En crear o modificar un recurs: immediat. És quan actuen Deny, Append i Modify.
• En assignar o canviar una política: es dispara una avaluació en uns 30 minuts.
• Cicle periòdic: cada 24 hores es torna a avaluar tot.

La correcció és el que arregla el que ja existeix. Només s'aplica a Modify i DeployIfNotExists, i no és automàtica: cal crear una tasca que recorre els recursos no conformes i els aplica el canvi fent servir la identitat administrada de l'assignació.

Si failedDeployments és més gran que zero, la causa és gairebé sempre la mateixa: la identitat administrada de l'assignació no té els permisos suficients en algun subàmbit. Es comprova amb az role assignment list --assignee <principalId de l'assignació>.

Assignar polítiques subscripció per subscripció no escala: cada subscripció nova neix sense govern i algú se n'ha de recordar. Els grups d'administració són contenidors per sobre de les subscripcions que permeten assignar polítiques i RBAC una sola vegada, heretant-se cap avall.

El repartiment que fa Contoso, i la seva lògica:

• A mg-contoso: allò innegociable per a tothom —regions permeses, etiquetes obligatòries, sense accés públic a l'emmagatzematge, HTTPS i diagnòstic automàtic—. Ningú, en cap subscripció present o futura, no s'ho pot saltar.
• A mg-contoso-plataforma: regles pròpies de la infraestructura compartida, com ara exigir que tota subxarxa tingui NSG associat.
• A mg-contoso-cargas: regles de les aplicacions, i sota seu la restricció de mides de VM que només s'aplica a la subscripció de desenvolupament.

Dos avisos pràctics. El grup arrel de l'inquilí existeix sempre i assignar-hi res afecta absolutament tot, incloses subscripcions que encara no existeixen; s'hi toca amb una cura extrema i cal el rol d'Administrador de grups d'administració. I les exclusions han de ser escasses i documentades: una jerarquia plena d'excepcions no governa res.

Azure Blueprints va ser l'intent d'empaquetar en un artefacte únic plantilles ARM, assignacions de polítiques i assignacions de rol. Està en desús i no s'ha de fer servir en dissenys nous. El seu substitut són dues peces separades i millors:

• Especificacions de plantilla: plantilles ARM o Bicep versionades i emmagatzemades com a recurs d'Azure, compartibles amb RBAC.
• Zones d'aterratge d'Azure: la implementació de referència del Cloud Adoption Framework, que desplega la jerarquia de grups d'administració, les polítiques, la topologia de xarxa i la identitat com un conjunt coherent. És cap a on evoluciona el que has muntat avui a mà, i es tracta a la lliçó 09-04.

Azure Policy és gratuït: no es paga per definició, assignació, avaluació ni correcció. El que costa és el temps de dissenyar-ho i el fregament inicial quan un desplegament es rebutja.

Davant d'això, el cost de no tenir-ne, amb les xifres de l'exemple de l'apartat 1: la VM Standard_E64s_v5 a East US costa uns 3.500 € al mes i, sense centro-coste, no s'imputa a ningú, amb la qual cosa apareix al repartiment general i ningú no la reclama. Suma-hi el cost real d'un incident: un compte d'emmagatzematge amb accés públic és una bretxa de dades personals, i les sancions de l'RGPD es mesuren en percentatge de facturació. Tota la secció de governança costa zero euros al mes; el primer recurs mal creat que evita paga de sobres el temps invertit. És, de bon tros, la millor relació cost/benefici del mòdul, i per això la Nuria Peña la reclamarà des del mòdul 8: sense centro-coste a cada recurs, no hi ha anàlisi de costos possible.

Podria semblar que si tota la infraestructura es defineix en Bicep amb les etiquetes i les regions correctes, Policy hi sobra. No és així, i el motiu és el que ha aparegut durant tot el mòdul: la plantilla protegeix el que desplega la canalització, la política protegeix tota la resta. Algú crearà un recurs des del portal per «provar una cosa», una eina de tercers aprovisionarà alguna cosa pel seu compte, o una canalització mal revisada desplegarà a la regió equivocada. Policy és la xarxa de seguretat que no depèn de la disciplina de ningú.

La manera correcta de combinar-los és en capes: la plantilla defineix la intenció i fa fàcil el que és correcte; la política impedeix el que és incorrecte vingui d'on vingui; i les mateixes definicions i assignacions de política es gestionen com a codi, versionades al repositori i desplegades per la canalització, no a cop de portal. Com es fa això amb Bicep i Azure Pipelines és el contingut de les lliçons 05-03 i 05-06.

• Assignar Deny directament en producció. Comença en Audit, mesura l'incompliment, corregeix, comunica-ho i després bloqueja.
• Oblidar la identitat administrada a Modify i DeployIfNotExists. L'assignació es crea sense error i totes les correccions fallen.
• Esperar que Deny netegi el que ja existeix. Només actua sobre creacions i modificacions; el que existeix es corregeix amb tasques de correcció.
• Impacientar-se. L'avaluació triga uns 30 minuts després d'assignar, i el cicle complet 24 hores.
• Exigir etiquetes sense la política d'herència. Cada desplegament comença a fallar i l'equip acaba demanant que es tregui la política.
• Bloquejar la ubicació global. Front Door, Traffic Manager i DNS deixen de poder-se crear. Exclou sempre global i els grups de recursos.
• Fer servir Blueprints en un disseny nou. Està en desús; fes servir especificacions de plantilla i zones d'aterratge.
• Omplir la jerarquia d'exclusions. Cada excepció és una escletxa; documenta i revisa les poques que siguin inevitables.
• Consell: prova cada política nova a rg-contoso-reservas-dev abans de pujar-la al grup d'administració. El radi de dany d'una política mal escrita a l'arrel és tota l'empresa.
• Consell: agrupa les teves polítiques pròpies en una iniciativa des del principi. Deu assignacions soltes es tornen impossibles de gestionar; una iniciativa s'assigna, es parametritza i es mesura d'una sola vegada.

«Contoso Millas» (centro-coste=CC-2077) tindrà la seva pròpia subscripció. Requisits: només West Europe; les quatre etiquetes obligatòries amb centro-coste heretat del grup de recursos; cap base de dades accessible des d'internet; diagnòstic enviat a log-contoso-pro; i VMs limitades a Standard_D4s_v5 com a màxim.

1. Indica per a cada requisit l'efecte adequat i en quin àmbit de la jerarquia l'assignaries.
2. Quins necessiten identitat administrada i quin rol li donaries?
3. Descriu l'ordre de desplegament per no bloquejar l'equip el primer dia.

Després d'assignar la política d'etiquetes obligatòries amb efecte Deny a mg-contoso, la canalització nocturna de Contoso comença a fallar amb RequestDisallowedByPolicy i, a més, 240 recursos preexistents apareixen com a no conformes.

1. Per què fallen els desplegaments nous i què falta al disseny?
2. Què cal fer amb els 240 recursos existents, amb les ordres?
3. Proposa l'ordre correcte d'assignació perquè això no hagués passat.

Indica l'efecte (Audit, Deny, Modify, DeployIfNotExists, DenyAction) i justifica'l:

1. Tot compte d'emmagatzematge nou ha d'exigir TLS 1.2 com a mínim.
2. Tot recurs ha de tenir l'etiqueta propietario; si falta, cal posar-la amb el valor del grup de recursos.
3. Tota base de dades SQL ha de tenir auditoria activada enviant-la a Log Analytics.
4. Es vol saber quantes VMs no tenen còpia de seguretat, sense canviar res encara.
5. Ningú no ha de poder eliminar kv-contoso-pro, ni tan sols un Propietari.

Solució 1:

1. Regions: Deny, al grup d'administració que contingui la subscripció de Millas (o a mg-contoso si la resta de l'empresa comparteix la restricció; com que aquí és només West Europe, s'assigna a nivell de la subscripció amb el seu paràmetre propi). Etiquetes obligatòries: Deny a la subscripció. Herència de centro-coste: Modify a la subscripció. Bases de dades sense accés públic: Deny a la subscripció. Diagnòstic: DeployIfNotExists, millor a mg-contoso perquè s'aplica a tota l'empresa. Mides de VM: Deny a la subscripció.
2. Les de Modify (herència d'etiqueta) i DeployIfNotExists (diagnòstic). Rol: Col·laborador a l'àmbit de l'assignació, o millor un de més estret —Col·laborador d'etiquetes per a la primera i Col·laborador de supervisió més Col·laborador de Log Analytics per a la segona—, aplicant el mínim privilegi de 04-02.
3. Primer les d'Audit i les de Modify/DeployIfNotExists amb les seves tasques de correcció, perquè la plataforma es posi al dia sola. Després mesurar el compliment durant uns dies. Després comunicar a l'equip la data d'entrada en vigor. I només aleshores canviar a Deny els efectes de regions, etiquetes, accés públic i mides.

Solució 2:

1. Perquè la canalització crea recursos sense l'etiqueta centro-coste, i amb Deny la petició es rebutja sencera. Falta la política d'herència amb efecte Modify, que hauria de completar l'etiqueta des del grup de recursos abans que la d'exigència avaluï; també falta haver passat per una fase d'Audit que hauria revelat el problema sense tallar res.
2. Els Deny no els toquen: continuen existint, marcats com a no conformes, però fallaran la propera vegada que algú els modifiqui. S'arreglen assignant la política d'herència amb identitat administrada i llançant az policy remediation create -n corrige-etiquetas --policy-assignment hereda-centro-coste --resource-discovery-mode ExistingNonCompliant --scope /subscriptions/$SUB, i comprovant després deploymentSummary.failedDeployments. Els recursos el grup dels quals tampoc no tingui l'etiqueta s'hauran d'etiquetar a mà o caldrà etiquetar abans els grups de recursos.
3. (a) Assignar la d'herència (Modify) i executar-ne la correcció. (b) Assignar la d'etiquetes en Audit i mesurar durant una o dues setmanes. (c) Corregir manualment el que quedi i avisar l'equip amb data. (d) Canviar l'efecte a Deny. És la mateixa seqüència detectar-analitzar-corregir-aplicar del WAF a 04-04, i pel mateix motiu.

Solució 3:

1. Deny: és una propietat coneguda en el moment de crear, no hi ha cap raó per acceptar un compte insegur i el requisit és innegociable per PCI DSS. S'acompanya d'una fase prèvia en Audit si ja hi ha comptes creats.
2. Modify: afegeix l'etiqueta que falta i, a diferència d'Append, pot corregir els recursos existents amb una tasca de correcció. Requereix identitat administrada.
3. DeployIfNotExists: l'auditoria és un recurs relacionat (una configuració de diagnòstic) que cal crear, no una propietat de la base. Requereix identitat administrada amb permisos sobre l'àrea de treball.
4. AuditIfNotExists: només es vol mesurar l'absència d'un recurs relacionat (l'element de còpia de seguretat) sense desplegar res ni bloquejar. És la fase prèvia natural abans de decidir si es passa a DeployIfNotExists.
5. DenyAction sobre l'operació d'eliminació, complementat amb un bloqueig de recurs CanNotDelete (01-05) i amb la protecció contra purga del mateix magatzem (04-03). Tres capes per al mateix objectiu, perquè perdre un Key Vault amb claus de xifratge és irreversible.

Amb aquesta lliçó es tanca el mòdul 4, i convé veure què ha canviat. Saps distingir el que RBAC no pot resoldre: RBAC respon a qui pot fer una cosa i Azure Policy a què es pot fer, amb models per defecte oposats —RBAC denega fins que concedeixes; Policy permet fins que restringeixes—. Has dissecat una definició de política amb el seu mode, els seus paràmetres, les seves condicions i els seus efectes, i saps quan fer servir cadascun: Audit per descobrir, Deny per a allò innegociable, Append i Modify per completar valors —amb la diferència que només Modify arregla el que ja existeix—, DeployIfNotExists i AuditIfNotExists per a recursos relacionats, i Disabled per pausar. Entens que un Deny no neteja el que ja s'ha creat, que l'avaluació triga uns 30 minuts després d'assignar i 24 hores en el seu cicle complet, i que les tasques de correcció són les que posen al dia la plataforma, sempre que l'assignació tingui la seva identitat administrada amb els permisos correctes.

Has implementat el conjunt de polítiques de Contoso: regions limitades a West Europe i North Europe, les quatre etiquetes obligatòries amb centro-coste heretat del grup de recursos, prohibició d'accés públic a l'emmagatzematge, HTTPS i TLS mínim, mides de VM acotades en desenvolupament i desplegament automàtic del diagnòstic cap a log-contoso-pro —que resol d'arrel, i també per al futur, una de les recomanacions que Defender va treure a 04-05—. Tot això penjant d'una jerarquia de grups d'administració (mg-contoso → mg-contoso-plataforma i mg-contoso-cargas) que fa que cap subscripció futura no neixi sense govern. Saps que Blueprints està en desús i que el seu lloc l'ocupen les especificacions de plantilla i les zones d'aterratge del Cloud Adoption Framework (09-04), que Policy és gratuït mentre que un sol recurs mal creat costa milers d'euros, i que la infraestructura com a codi i la política són capes complementàries: la plantilla fa fàcil el que és correcte, la política impedeix el que és incorrecte vingui d'on vingui.

Recapitulant el mòdul sencer: la plataforma de Contoso Airlines hi va entrar amb contrasenyes escrites a mà i en surt governada. Les identitats viuen a Microsoft Entra ID amb grups, MFA, accés condicional, PIM i un compte d'emergència exclòs. Els permisos són mínims i s'assignen a grups, amb rols de dades separats del pla de gestió i un rol personalitzat per a operacions. No queda ni un sol secret al codi ni al desplegament: les identitats administrades van eliminar els que podien desaparèixer i kv-contoso-pro custodia els que no, amb referències @Microsoft.KeyVault(...) que l'aplicació resol sola. El perímetre està protegit amb el WAF de fd-contoso-global, les seves regles OWASP i de bots, la limitació de velocitat i un guió de resposta davant d'atacs, amb les decisions de cost de DDoS argumentades i no improvisades. La postura es vigila sola amb Defender for Cloud, la seva puntuació, les seves recomanacions prioritzades, les seves alertes i el seu tauler de PCI DSS. I les regles del joc ja no depenen que algú se'n recordi: estan escrites com a política i s'apliquen en el moment de crear cada recurs.

Queda, però, una cosa que aquest mòdul ha deixat en evidència sense dir-ho. Tot el que has construït en quatre mòduls s'ha desplegat a mà, ordre a ordre, des de la CLI. Funciona, però no escala, no és reproduïble, no hi ha manera de saber qui va canviar què ni de tornar enrere si alguna cosa es trenca, i no hi hauria manera de recrear aquesta plataforma en una altra regió després d'un desastre. La mateixa disciplina que has aplicat avui a la governança cal aplicar-la al lliurament. Al mòdul 5, Azure DevOps, muntaràs el cicle complet: Azure Repos per versionar el codi i també les plantilles, Azure Pipelines per construir i provar a cada canvi, desplegament continu amb entorns i aprovacions per arribar a producció sense por, Azure Artifacts per als paquets compartits i, tancant el cercle, infraestructura com a codi amb Bicep, on tota aquesta plataforma —xarxes, aplicacions, bases de dades, polítiques incloses— deixa de ser una col·lecció d'ordres executades una vegada i passa a ser codi revisable, versionat i repetible. Ens hi veiem.