Les quatre lliçons anteriors han assegurat peces concretes: identitats, permisos, secrets i perímetre. Totes comparteixen una limitació incòmoda: calia saber que el problema existia per anar a arreglar-lo. Ningú no ha comprovat encara si vm-motor-disponibilidad-dev va quedar amb el port 22 obert a internet a les proves del mòdul 2, si algun compte d'emmagatzematge admet trànsit sense xifrar, o si algú està intentant entrar a db-reservas des d'una IP d'un país on Contoso Airlines no té ni un empleat. Això és el que fa Microsoft Defender for Cloud: mira la plataforma sencera de manera contínua, la compara amb un catàleg de bones pràctiques, diu què hi falta ordenat per impacte i avisa quan alguna cosa es comporta de manera anòmala. És el salt del control puntual a la postura de seguretat contínua.

Avís de cost important: el nivell gratuït d'avaluació i recomanacions no costa res, però els plans de Defender sí, i força: de l'ordre de 14 €/servidor al mes, 13 € per milió de transaccions a Storage, 13 €/instància de SQL al mes, uns 2 € per vCore de contenidors i uns 0,02 € per 10.000 operacions de Key Vault. Una subscripció mitjana amb tots els plans activats alhora passa fàcilment dels 1.000 € al mes. Activa'ls per subscripció i per pla, començant pels recursos que guarden dades sensibles, i fes servir sempre l'estimació de cost que el mateix portal mostra abans de confirmar.

1. CSPM i CWPP: les dues meitats del problema
2. La puntuació de seguretat i com fer-la servir de debò
3. Nivell gratuït davant dels plans de pagament
4. Activar Defender a la subscripció de producció
5. Recomanacions: correcció ràpida, exempció i denegació
6. Les deu primeres recomanacions de Contoso
7. Alertes de seguretat i investigació
8. Cadena d'atac i el salt a Microsoft Sentinel
9. Compliment normatiu i el cas PCI DSS
10. Núvols diferents i recursos locals
11. Automatització de fluxos de treball
12. Errors Comuns i Consells
13. Exercicis
14. Conclusió

Defender for Cloud són en realitat dos productes sota un mateix tauler, i confondre'ls porta a activar el que no es necessita:

La distinció pràctica: el CSPM bàsic és gratuït i cal activar-lo avui mateix a totes les subscripcions, sense discussió, perquè no costa res i descobreix la meitat dels problemes reals. Existeix a més el CSPM Defender de pagament, que hi afegeix anàlisi de rutes d'atac, consultes sobre el graf de seguretat del núvol i anàlisi de màquines sense agent. El CWPP —els plans per recurs— s'activa amb criteri i de manera selectiva, perquè és el que es factura.

La puntuació de seguretat resumeix la postura en un percentatge. Es calcula així:

• Les recomanacions s'agrupen en controls de seguretat (per exemple, «Habilitar MFA», «Corregir vulnerabilitats», «Restringir l'accés a la xarxa»).
• Cada control val un nombre de punts (els més crítics, fins a 10).
• Un control només suma quan tots els seus recursos el compleixen, amb puntuació parcial proporcional als recursos correctes.
• La puntuació final és la suma obtinguda sobre la màxima possible.

Contoso arrenca al 38 %. I aquí arriba el consell que més temps estalvia: l'objectiu no és el 100 %. Perseguir-lo porta a gastar setmanes en recomanacions irrellevants per al teu context, o a activar plans de pagament caríssims només per apujar el marcador. La puntuació serveix per a tres coses:

1. Prioritzar: atacar primer els controls amb més punts possibles i menys recursos afectats, que és on l'esforç rendeix més.
2. Mesurar tendència: que pugi de manera sostinguda mes a mes importa molt més que el seu valor absolut.
3. Comunicar: és la mètrica que la direcció entén, i la que justifica el pressupost de seguretat.

Regla pràctica de Contoso: l'objectiu trimestral és el 70 %, amb tots els controls de gravetat alta resolts o formalment exempts amb justificació escrita.

Advertiment explícit: activar els vuit plans a les dues subscripcions de Contoso supera folgadament els 1.000 € al mes, més del que costa bona part de la infraestructura que protegeixen. Els plans s'activen per subscripció i per pla, i aquest és el mecanisme que cal fer servir:

• A Contoso Airlines - Producció: SQL (guarda dades personals de passatgers i és l'actiu crític), Storage (targetes d'embarcament) i Key Vault (accés a secrets). El pla de Servidors s'activa només a vmss-api-disponibilidad-pro, no a tot.
• A Contoso Airlines - Desenvolupament: només el nivell gratuït. Les dades són fictícies i el risc, baix.

Els 30 dies de prova gratuïta són útils per veure el volum real d'alertes abans de comprometre's, però cal anotar la data de finalització al calendari: si ningú no ho desactiva, comença a facturar sense avisar.

El pas 3 no és opcional a la pràctica: sense enviar les dades a l'àrea de treball de rg-contoso-seguridad-pro, les alertes viuen només al tauler de Defender, no es poden correlacionar amb els registres de Key Vault ni amb els del WAF de 04-04, i no hi ha historial més enllà de la retenció per defecte. És la mateixa decisió que es va prendre amb l'auditoria del magatzem a 04-03, i el mòdul 7 l'explota a fons amb KQL.

Per a servidors convé a més l'aprovisionament automàtic de les extensions, de manera que tota VM nova rebi els agents sense intervenció manual. És un bon exemple de per què Defender i Azure Policy són inseparables: aquest aprovisionament s'implementa, per sota, amb polítiques de tipus DeployIfNotExists com les que veuràs a 04-06.

Cada recomanació porta gravetat, recursos afectats, impacte en la puntuació i passos de correcció. Hi ha tres maneres de tractar-la:

Sobre les exempcions, dues regles d'higiene: sempre amb justificació escrita i caducitat (per exemple, sis mesos), i revisades en vèncer. Una exempció permanent i sense motiu documentat és exactament igual que ignorar la recomanació, només que amb millor aspecte al tauler. I la denegació és el mecanisme que converteix una recomanació en una regla: es fa amb Azure Policy, que és la lliçó següent.

Aquest és el llistat real que Defender treu la primera setmana, amb el que l'equip decideix en cada cas:

Val la pena fixar-se en el patró: de deu recomanacions, dues ja estaven complertes gràcies a la feina de les lliçons anteriors, una es corregeix amb un clic, una es resol millor amb una política que cas a cas, i dues s'exceptuen amb justificació i caducitat. Aquesta barreja és la feina real de seguretat; el tauler al 100 % no ho és.

Les alertes neixen dels plans de pagament i es generen per tres vies: anàlisi del comportament (alguna cosa es desvia de la línia base apresa), intel·ligència d'amenaces (una IP o un resum apareixen en fonts conegudes) i deteccions específiques de cada servei. Les seves gravetats són Alta, Mitjana, Baixa i Informativa.

Un exemple realista a Contoso:

La investigació, pas a pas:

1. Context: són les 03:17, fora d'horari. La identitat és la de l'aplicació, que mai no hauria de fer servir sqlcmd: l'aplicació es connecta amb el seu SDK. Ja hi ha dos senyals forts.
2. Correlacionar: buscar a Log Analytics si aquesta IP apareix als registres del WAF, als inicis de sessió d'Entra ID o a l'auditoria de kv-contoso-pro de les hores prèvies.
3. Determinar l'abast: SELECT * FROM dbo.Reservas sense filtre apunta a exfiltració massiva, no a una consulta operativa. Es mira el volum de dades retornat a l'auditoria de SQL (03-02).
4. Contenir: si es confirma, revocar els testimonis de la identitat, bloquejar la IP al WAF i a l'NSG, i aïllar el recurs compromès.
5. Erradicar i recuperar: trobar com es va obtenir l'accés —un testimoni robat?, una cadena de connexió antiga que va sobreviure a 04-02?—, tancar-ho i restaurar des d'una còpia neta si hi va haver modificació.
6. Documentar: cronologia, abast de la dada afectada i, si hi ha dades personals de passatgers, notificació al regulador dins del termini legal de l'RGPD.

En aquest cas concret, la causa més probable és la més avorrida: una cadena de connexió antiga que va quedar en un script i que algú va executar des de fora. Que la investigació acabi en una cosa trivial no vol dir que l'alerta sobrés; vol dir que el procés funciona.

Una alerta aïllada diu poc. Defender agrupa alertes relacionades en incidents i mostra la ruta d'atac: cadenes de configuracions que, combinades, permeten arribar a una dada sensible. Per exemple: «VM exposada a internet → amb una vulnerabilitat crítica sense pedaç → amb una identitat administrada que té rol de Col·laborador de dades sobre sttarjetascontosopro». Cap dels tres elements no és alarmant per separat; junts són una ruta d'exfiltració completa. Aquesta anàlisi pertany al CSPM Defender de pagament i és, probablement, el que més en justifica el preu.

Microsoft Sentinel és l'esglaó següent: el SIEM i SOAR natiu d'Azure. Mentre Defender for Cloud protegeix els recursos d'Azure, Sentinel correlaciona totes les fonts —Defender, Entra ID, Microsoft 365, tallafocs, sistemes locals, aplicacions de tercers—, aplica regles d'anàlisi i automatitza la resposta amb manuals d'estratègia. Es factura per GB ingerits, així que la decisió de quins registres enviar és alhora de seguretat i econòmica. Contoso el té al seu full de ruta per a quan hi hagi un equip de seguretat dedicat: sense algú que atengui els incidents, un SIEM és una despesa que genera alertes que ningú no mira.

El tauler de compliment normatiu associa les recomanacions als controls d'estàndards reconeguts:

Contoso processa pagaments amb targeta, així que PCI DSS se li aplica, i això té conseqüències concretes que ja has anat muntant sense anomenar-les: xifratge en trànsit i en repòs, segmentació de la xarxa que toca dades de targeta, control d'accés per identitat amb mínim privilegi, auditoria de tots els accessos (d'aquí els registres de Key Vault i de SQL a Log Analytics), gestió de vulnerabilitats i retenció de registres d'almenys un any.

Dos advertiments seriosos. Primer: el tauler mostra el compliment dels controls tècnics que Azure pot avaluar automàticament; un estàndard com PCI DSS inclou a més controls de procés, formació, contractes i seguretat física que cap eina no mesura. Un 100 % al tauler no és una certificació. Segon, i per això aquest avís es repeteix: el disseny de compliment l'ha de validar un auditor qualificat o l'equip de compliance de la teva organització abans de donar-lo per bo. L'eina ajuda; no certifica.

Defender for Cloud no es limita a Azure. Pot connectar comptes d'AWS i projectes de Google Cloud mitjançant un connector natiu sense agents, avaluant-ne la configuració amb els mateixos criteris i mostrant-ho tot en un únic tauler de postura multinúvol. I els servidors locals —inclòs l'AD de l'oficina de Barcelona i el sistema heretat de facturació— s'incorporen amb Azure Arc, que els projecta com a recursos d'Azure i els aplica plans, polítiques i recomanacions. Per a Contoso és la via de tenir una sola visió de seguretat sense migrar abans tota la infraestructura, cosa que enllaça directament amb l'estratègia de migració de 09-04.

Una alerta que arriba a un correu que ningú no llegeix no serveix de res. L'automatització de fluxos de treball dispara una Logic App (06-04) quan es genera una alerta o una recomanació que compleixi un filtre:

Contoso ho fa servir per a tres coses: avisar per Teams el canal de guàrdia davant de gravetat Alta, obrir automàticament un tiquet amb el context de l'alerta, i executar contencions simples i reversibles, com ara aïllar per NSG una VM amb una alerta de mineria de criptomonedes. L'automatització agressiva convé reservar-la per a casos d'altíssima confiança: una contenció automàtica mal calibrada és, en si mateixa, una denegació de servei autoinfligida.

• Activar tots els plans «per estar segurs». És la via ràpida a una factura de quatre xifres. Un pla per tipus de recurs i per subscripció, començant per les dades sensibles.
• Deixar que caduqui la prova de 30 dies sense adonar-se'n. Comença a facturar en silenci. Posa-ho al calendari el mateix dia que l'activis.
• Perseguir el 100 % de puntuació. Prioritza gravetat alta i impacte real; la resta és marcador.
• Exceptuar sense justificació ni caducitat. És ignorar el problema amb millor presentació. Justifica-ho per escrit i revisa-ho en vèncer.
• Aplicar la correcció ràpida en producció sense pensar. Algunes correccions canvien la xarxa o l'accés i poden tallar el servei. Prova-les en desenvolupament.
• Confondre el tauler de compliment amb una certificació. Només mesura controls tècnics automatitzables.
• No connectar Defender a Log Analytics. Sense això no hi ha correlació, ni historial, ni consultes.
• Consell: revisa la puntuació i les recomanacions noves en una reunió fixa mensual de 30 minuts. La postura de seguretat es degrada sola si ningú no la mira.
• Consell: activa sempre el nivell gratuït a totes les subscripcions, incloses les de desenvolupament i les de proves. No costa res i és allà on apareixen els descuits.

Contoso Millas (centro-coste=CC-2077) té 400 €/mes per a seguretat. La seva subscripció conté: 6 màquines virtuals, 1 base de dades SQL amb dades personals, 2 comptes d'emmagatzematge amb 30 milions de transaccions al mes, 1 Key Vault i 1 App Service públic.

1. Estima el cost d'activar tots els plans i compara'l amb el pressupost.
2. Proposa una selecció justificada que càpiga en 400 € i indica què queda descobert.
3. Què activaries gratis en qualsevol cas i per què?

Defender treu quatre recomanacions sobre Contoso Reserves: (a) ports de gestió oberts en dues VM de desenvolupament; (b) transferència segura deshabilitada en un compte d'emmagatzematge; (c) DDoS Standard no habilitat; (d) registres de diagnòstic deshabilitats en 14 recursos.

1. Indica per a cadascuna si correspon corregir, exceptuar o denegar, i amb quin mecanisme.
2. Quina resoldries amb Azure Policy en lloc d'una a una, i per què?
3. Quina informació escriuries a l'exempció que proposis?

Arriba una alerta de gravetat Alta: «S'ha detectat una operació d'extracció massiva de blobs» sobre sttarjetascontosopro, amb la identitat app-contoso-reservas-pro com a origen, 40.000 blobs descarregats en 12 minuts, des d'una IP d'un proveïdor de núvol aliè, a les 04:30.

1. Enumera les tres primeres comprovacions que faries i què buscaries a cadascuna.
2. Quines mesures de contenció aplicaries, en quin ordre i amb quin risc?
3. Sabent el que es va fer a 04-02 i 04-03, quines hipòtesis de causa arrel manejaries?

Solució 1:

1. Servidors: 6 × 14 = 84 €. SQL: 13 €. Storage: 30 milions de transaccions ≈ 390 €. Key Vault: uns pocs euros. App Service: 13 €. Total aproximat: 500-510 €/mes, un 25 % per sobre del pressupost.
2. Prioritat per dada sensible i exposició: SQL (13 €), App Service (13 €, és el que és públic), Key Vault (uns 2 €) i Servidors (84 €) sumen uns 112 €. Amb la resta es pot cobrir Storage parcialment si se separen els comptes i només es protegeix el que conté dades personals; si els 30 milions de transaccions són del compte sensible, cal decidir entre cobrir-lo (390 €, total ~500 €, fora de pressupost) o deixar-lo amb el CSPM gratuït. Queda descoberta la detecció de programari maliciós i d'exfiltració a l'emmagatzematge, risc que s'ha de documentar i acceptar formalment.
3. El CSPM bàsic gratuït a totes les subscripcions, incloses les de desenvolupament, i l'enviament de registres a Log Analytics. Costa zero, detecta configuracions incorrectes i és precisament en desenvolupament on apareixen els ports oberts i els accessos públics oblidats.

Solució 2:

1. (a) Corregir: tancar els NSG i fer servir Bastion; en desenvolupament és temptador exceptuar-ho, però un port 22 obert a internet és un dels vectors més explotats que existeixen. (b) Correcció ràpida immediata: és un clic, no trenca res i és requisit de PCI DSS. (c) Exempció documentada amb caducitat anual, remetent a la decisió de cost de 04-04. (d) Corregir amb Azure Policy, no manualment.
2. La (d). Catorze recursos avui, i demà vint: una política DeployIfNotExists els configura i, sobretot, configura també els futurs, que és el que la correcció manual no aconsegueix mai. És exactament el cas d'ús de 04-06.
3. A l'exempció de (c): recurs o àmbit afectat, categoria «risc acceptat», justificació (el trànsit entra per fd-contoso-global, que ja absorbeix els volumètrics a la vora; el cost de Network Protection és d'uns 32.000 €/any davant del risc residual estimat), qui l'aprova (responsable de seguretat i direcció financera), data de caducitat a dotze mesos i condició de revisió anticipada (publicar una IP pública crítica pròpia).

Solució 3:

1. (a) L'auditoria de l'emmagatzematge a Log Analytics: quins blobs concrets, amb quin patró i amb quin testimoni; es busca si el testimoni prové de la identitat administrada o d'una SAS o clau antiga. (b) El comportament normal de l'aplicació: 40.000 descàrregues en 12 minuts a les 04:30 no encaixa amb l'emissió de targetes d'embarcament, que segueix l'horari de vols. (c) L'origen: una IP d'un altre proveïdor de núvol és incompatible amb el fet que l'aplicació s'executa a App Service a West Europe.
2. Ordre: primer revocar l'accés de la identitat implicada (retirar l'assignació de rol sobre el contenidor) i comprovar que --allow-shared-key-access continua a false; després bloquejar la IP al tallafoc del compte i al WAF; després rotar qualsevol credencial relacionada a kv-contoso-pro. Risc: retirar el rol deixa l'aplicació sense poder emetre targetes d'embarcament, així que cal avisar operacions abans; l'alternativa menys disruptiva és restringir primer la xarxa i observar si l'accés cessa.
3. Hipòtesis per ordre de probabilitat: (a) una SAS o clau de compte antiga emesa al mòdul 2 que continua sent vàlida —comprovable a l'instant, ja que es va desactivar l'accés per clau compartida a 04-02; si de debò està a false, aquesta hipòtesi cau—; (b) un testimoni robat de la identitat administrada, exfiltrat des del procés de l'aplicació, cosa que implicaria compromís del codi o d'una dependència; (c) una entitat de servei de desplegament amb permisos excessius el secret de la qual es va filtrar al repositori, que és justament el que Key Vault i les identitats administrades venien a eliminar i que confirmaria que va quedar alguna resta sense migrar.

Contoso ha passat del control puntual a la postura contínua. Distingeixes les dues meitats de Defender for Cloud: el CSPM, que avalua sense descans si la configuració és correcta i produeix recomanacions, i el CWPP, que detecta en temps d'execució i produeix alertes. Saps que el CSPM bàsic és gratuït i que cal activar-lo a totes les subscripcions avui mateix, i que els plans de pagament es trien per subscripció i per pla perquè activar-los tots supera fàcilment els 1.000 € al mes. Entens com es calcula la puntuació de seguretat i, més important, com es fa servir: per prioritzar per impacte, mesurar tendència i comunicar a direcció, mai per perseguir el 100 %.

Has activat els plans de SQL, Storage i Key Vault en producció, ho has enviat tot a Log Analytics a rg-contoso-seguridad-pro i has recorregut les deu primeres recomanacions veient el patró real de la feina de seguretat: dues ja estaven complertes per lliçons anteriors, una es resol amb correcció ràpida, una altra demana una política en lloc d'arreglar recurs a recurs, i dues acaben en exempció amb justificació i caducitat. Saps com es genera una alerta, has investigat pas a pas un accés anòmal a db-reservas —context, correlació, abast, contenció, erradicació i documentació, amb el termini de l'RGPD a sobre— i coneixes la ruta d'atac que encadena configuracions innòcues per separat i Microsoft Sentinel com a esglaó següent quan hi hagi un equip que atengui els incidents. Tanquen la lliçó el compliment normatiu amb PCI DSS aplicable a Contoso per processar pagaments —i l'advertiment que el tauler no és una certificació—, la cobertura d'AWS, Google Cloud i servidors locals amb Azure Arc, i l'automatització amb Logic Apps perquè cap alerta greu no es quedi en un correu sense llegir.

Queda una escletxa, i és la que ha aparegut dues vegades en aquesta lliçó. Defender detecta després: diu que hi ha catorze recursos sense diagnòstic, que una VM té el port obert o que un compte permet accés públic, però tot això ja s'ha creat, ja ha estat exposat i algú ha hagut d'anar a arreglar-ho. El que falta és impedir que arribi a existir. A l'última lliçó del mòdul, Governança i compliment amb Azure Policy, veuràs la diferència essencial entre RBAC —qui pot fer una cosa— i Policy —què es pot fer—, escriuràs definicions amb els seus efectes, muntaràs el conjunt de polítiques de Contoso (regions permeses, etiquetes obligatòries, prohibició d'accés públic, TLS mínim, mides de VM i desplegament automàtic de diagnòstic) i corregiràs el que ja existeix amb tasques de correcció, tot sobre una jerarquia de grups d'administració.