Les identitats administrades de la lliçó anterior van eliminar els secrets d'accés a sttarjetascontosopro i a db-reservas, i aquesta és la millor notícia possible: el secret que no existeix no es pot filtrar. Però no tot es resol així. Contoso Airlines continua necessitant la clau de la passarel·la de pagament, el testimoni del proveïdor de dades meteorològiques que alimenta les previsions de retard, la cadena de connexió del sistema heretat de facturació que encara corre a Barcelona i el certificat TLS de contosoairlines.example. Cap d'aquests sistemes no parla Entra ID, així que el secret existeix i s'ha de guardar en algun lloc. Avui aquest lloc passa a ser Azure Key Vault: un magatzem sustentat per maquinari, amb permisos per RBAC, xarxa tancada, versionat i auditoria de cada lectura. En acabar, app-contoso-reservas-pro llegirà els seus secrets amb la identitat administrada de 04-02 i no hi haurà ni una sola contrasenya al desplegament.

Avís important: la gestió de claus i secrets toca directament el compliment normatiu —PCI DSS per als pagaments, RGPD per a les dades de passatgers— i una configuració incorrecta pot provocar tant una bretxa com una pèrdua irreversible de dades xifrades. Abans de portar a producció qualsevol disseny de Key Vault, de rotació o de claus gestionades pel client, l'ha de revisar un professional de seguretat o l'equip de compliance de la teva organització.

1. On viuen avui els secrets de Contoso
2. Què guarda Key Vault: secrets, claus i certificats
3. Nivells Estàndard, Premium i Managed HSM
4. Crear kv-contoso-pro amb eliminació temporal i protecció contra purga
5. Els dos models de permisos: directives d'accés davant de RBAC
6. Accés des de la xarxa: tallafoc, punt de connexió privat i serveis de confiança
7. Desar, recuperar i versionar secrets
8. Rotació de secrets sense caiguda
9. Certificats TLS gestionats
10. Consumir secrets des d'App Service amb referències de Key Vault
11. Claus de xifratge gestionades pel client
12. Auditoria, límits i què NO posar al magatzem
13. Errors Comuns i Consells
14. Exercicis
15. Conclusió

Un inventari honest abans d'arreglar res:

Cap no ha rotat mai, ningú no sap qui els ha llegit i revocar-los exigiria buscar-los per cinc llocs. Key Vault resol les quatre coses alhora: emmagatzematge centralitzat, control d'accés per identitat, auditoria de cada operació i rotació gestionada.

La distinció entre secret i clau és la més important i la que més es confon. Un secret es guarda per tornar-lo: l'aplicació demana la clau de la passarel·la i rep el text. Una clau no es torna mai: s'envia a Key Vault la dada perquè ell la xifri, la signi o la desxifri, i la clau privada no abandona mai el mòdul criptogràfic. Per això les claus de xifratge es guarden com a claus i no com a secrets: encara que algú robés el testimoni d'accés, no podria exfiltrar el material criptogràfic.

Un certificat és en realitat tres objectes coordinats: el certificat, una clau i un secret que conté el PFX complet. Key Vault en gestiona a més el cicle de vida, inclosa la renovació automàtica.

Contoso tria Estàndard per a kv-contoso-pro. És la decisió correcta llevat que una norma exigeixi explícitament HSM certificat de nivell 3, i convé saber que el nivell no es pot canviar de Premium a Estàndard un cop creat (d'Estàndard a Premium sí). Azure Managed HSM existeix, costa milers d'euros al mes i només té sentit quan el mateix auditor ho exigeix per escrit.

Tres opcions mereixen una explicació detallada:

• Eliminació temporal (soft delete): està sempre activada i no es pot desactivar. En esborrar un secret, una clau o el magatzem sencer, l'objecte passa a estat eliminat i es conserva durant --retention-days (de 7 a 90). Durant aquest temps es pot recuperar amb az keyvault recover.
• Protecció contra purga: impedeix eliminar definitivament l'objecte durant la retenció, ni tan sols a un Propietari. Un cop activada tampoc no es pot desactivar. És incòmoda a propòsit: converteix un esborrat maliciós o accidental en una cosa reversible.
• La conseqüència pràctica que sorprèn tothom: mentre un magatzem eliminat continuï en retenció, el seu nom queda reservat globalment i no se'n pot crear cap altre d'igual. Si esborres kv-contoso-pro en una prova, no el podràs recrear amb aquest nom fins 90 dies després (o abans purgant-lo, llevat que la protecció contra purga ho impedeixi, que és justament el cas). Per això els magatzems de prova es creen amb noms d'usar i llençar i --retention-days 7.

Amb --enable-rbac-authorization true, els permisos del pla de dades es concedeixen amb els mateixos rols de la resta d'Azure. Els que es fan servir:

Aquest últim és el parany de 04-02 aplicat aquí: Col·laborador de Key Vault no permet llegir ni un sol secret. Sí que permet, en canvi, canviar la configuració del magatzem, motiu pel qual també és un rol privilegiat que convé mantenir sota PIM.

Fixa't en l'àmbit de la primera assignació: un secret concret, no el magatzem. Si app-contoso-reservas-pro queda compromesa, l'atacant obté aquesta clau i res més.

Amb --public-network-access Disabled el magatzem no respon a internet. L'accés arriba per un punt de connexió privat a snet-datos, exactament igual que pe-sql-reservas i pe-storage-tarjetas del mòdul 2:

I cal registrar el nom al DNS privat, o el client continuarà resolent la IP pública: es crea la zona privatelink.vaultcore.azure.net, es vincula a vnet-contoso-pro i s'associa al punt de connexió amb un grup de zones DNS. Sense aquest pas, el punt de connexió existeix i no el fa servir ningú: és la fallada més freqüent de Private Link.

Queda un matís operatiu. Certs serveis d'Azure —App Service llegint referències, Azure SQL desxifrant amb clau del client, Event Grid— no surten per la xarxa virtual. Per a ells existeix l'excepció de serveis de confiança de Microsoft, que cal activar explícitament:

--bypass AzureServices permet el pas a aquesta llista tancada de serveis; --default-action Deny continua rebutjant tota la resta. L'excepció no és un forat obert: cada servei de la llista ha de tenir a més un rol assignat.

Cada secret té un identificador amb versió, https://kv-contoso-pro.vault.azure.net/secrets/pasarela-pago-clave/a1b2c3..., i un altre sense versió que apunta sempre a l'actual. La regla pràctica: fes servir l'identificador sense versió perquè la rotació no obligui a tornar a desplegar, llevat que necessitis fixar una versió concreta per reproductibilitat.

Els atributs --expires i --not-before no bloquegen la lectura per si sols en tots els clients: són metadades que alimenten els avisos de caducitat i les consultes d'auditoria. Posa'ls sempre; ignorar-los és el que fa que una clau porti quatre anys sense rotar.

Rotar és substituir un secret per un de nou sense que res deixi de funcionar. Tres mecanismes, de més a menys automàtic:

Rotació totalment gestionada. Per a les claus de comptes d'emmagatzematge, Key Vault les pot regenerar per si mateix. Es crea un secret de tipus compte administrat, se li indica cada quant ha de rotar, i Key Vault alterna entre key1 i key2 regenerant la que no està en ús:

Fixa't en la ironia saludable: Contoso ja no fa servir aquestes claus perquè va passar a identitat administrada (04-02). Aquest mecanisme és per als comptes heretats que encara no han migrat.

Notificació de caducitat per Event Grid. Key Vault publica esdeveniments SecretNearExpiry (30 dies abans) i SecretExpired, que poden disparar una funció o una Logic App que cridi l'API del proveïdor, obtingui una credencial nova i escrigui la versió al magatzem. És el patró per a secrets de tercers com la passarel·la de pagament.

El patró de rotació sense caiguda, que és l'important conceptualment i val per a qualsevol secret:

La clau és al pas 1: el proveïdor ha d'admetre dues credencials vàlides alhora. Si només n'admet una, no hi ha rotació sense caiguda possible i caldrà planificar una finestra de manteniment. És una pregunta que convé fer a cada proveïdor abans d'integrar-lo.

Key Vault pot emetre i renovar certificats automàticament si s'integra amb una autoritat de certificació associada (DigiCert, GlobalSign), o custodiar certificats importats de qualsevol altra. Es defineix una directiva amb l'assumpte, els noms alternatius, la vigència i el percentatge de vida a partir del qual es renova:

A partir d'aquí, app-contoso-reservas-pro importa el certificat amb az webapp config ssl import --key-vault $KV --key-vault-certificate-name cert-contosoairlines, i quan Key Vault el renova, App Service recull la versió nova sense intervenció. Application Gateway fa el mateix referenciant l'identificador del certificat, i és allà on es farà servir a la lliçó 04-04 en muntar el tallafoc d'aplicacions web. L'alternativa gratuïta per a casos senzills són els certificats administrats d'App Service, que ja vas veure a 02-03; Key Vault és l'opció quan el mateix certificat s'ha de compartir entre diversos serveis.

Aquest és el moment en què les contrasenyes desapareixen del desplegament. Una referència de Key Vault és un ajust d'aplicació el valor del qual no és el secret, sinó un punter:

El que passa per sota: en arrencar, App Service fa servir la identitat administrada de 04-02 per demanar el testimoni, resol la referència i exposa el valor a l'aplicació com una variable d'entorn normal. Conseqüències que convé tenir clares:

• El codi no canvia: continua llegint ClavePasarelaPago com sempre. No hi ha cap SDK per afegir.
• El secret no és a la configuració: qui tingui config/list veu el punter, no el valor.
• La resolució passa en arrencar i es guarda en memòria cau 24 hores (o en reiniciar). Després de rotar un secret, cal reiniciar l'aplicació o esperar; si has fet servir l'URI sense versió, la referència recull la versió nova.
• Si la referència falla, l'aplicació arrenca sense aquest ajust i sol fallar de manera confusa. Comprova sempre l'estat amb az webapp config appsettings list, on una referència trencada es mostra amb el seu error.

Quan l'aplicació necessita llegir secrets en calent (no només en arrencar), es fa servir SecretClient de l'SDK amb DefaultAzureCredential, la mateixa credencial de 04-02, i sempre amb memòria cau pròpia, pel motiu de l'apartat 12.

Tot el que guarda Azure està xifrat en repòs amb claus de Microsoft, sense que calgui fer res. Les claus gestionades pel client (CMK) canvien qui controla la clau: la genera Contoso a kv-contoso-pro, i el servei la fa servir mitjançant la seva identitat administrada.

Què aporta de debò: la capacitat de revocar. Si es deshabilita la clau, sttarjetascontosopro deixa de poder desxifrar les seves dades de manera immediata; és el «botó vermell» que exigeixen alguns auditors. I què costa: si aquesta clau s'esborra o es perd, les dades són irrecuperables, sense que Microsoft hi pugui fer res. Per això la protecció contra purga és obligatòria en magatzems amb CMK, i per això Contoso les aplica només a sttarjetascontosopro i a db-reservas, on hi ha dades personals, i no a la resta. La rotació d'una CMK és transparent: es torna a xifrar la clau de dades, no les dades.

Key Vault registra cada operació del pla de dades: qui va llegir quin secret, des de quina IP i amb quin resultat. Aquests registres no es conserven al magatzem, cal enviar-los:

Amb això, a Log Analytics (07-02) es pot respondre a preguntes com ara «qui va llegir la clau de la passarel·la fora de l'horari laboral?» o «quines identitats han accedit a aquest secret els últims 90 dies?». És requisit directe de PCI DSS i el motiu pel qual l'àrea de treball viu a rg-contoso-seguridad-pro al costat del magatzem.

Sobre límits de rendiment: Key Vault aplica limitació de sol·licituds per magatzem i regió (de l'ordre de 2.000 operacions de secret per 10 segons, menys per a operacions amb claus RSA). En superar-la retorna HTTP 429. Per això la regla és innegociable: l'aplicació guarda els secrets en memòria durant hores i només els torna a llegir en rotar o en rebre un error d'autenticació. Un servei que demana el secret a cada petició HTTP tomba el seu propi magatzem tan bon punt arriba trànsit real.

I què no ha d'anar a Key Vault:

• Configuració que no és secreta (URLs, noms de servidor, marques de funcionalitat): va a App Configuration o als ajustos normals.
• Dades de negoci o dades personals: no és una base de dades. Un secret són 25 KB com a màxim.
• Fitxers grans, encara que siguin sensibles: xifra'ls i desa'ls a l'emmagatzematge, amb la clau a Key Vault.
• Secrets d'usuaris finals (contrasenyes de passatgers): aquestes viuen a Entra External ID (04-01), amb el seu resum criptogràfic, mai aquí.

• Crear el magatzem amb directives d'accés «perquè és el que surt a tutorials antics». Fes servir --enable-rbac-authorization true des del principi; migrar després és tediós.
• Esperar que Col·laborador de Key Vault deixi llegir secrets. No ho fa: gestiona el magatzem, no les seves dades.
• Esborrar un magatzem de prova i no poder recrear-lo amb el mateix nom. El nom queda reservat durant la retenció. Fes servir noms d'usar i llençar i 7 dies de retenció a les proves.
• Activar la protecció contra purga sense entendre-la. És irreversible. En producció és obligatòria; en un curs o una prova, evita-la.
• Oblidar la zona DNS privada del punt de connexió. El magatzem queda inaccessible amb un error de xarxa que no diu res.
• Demanar el secret a cada petició. HTTP 429 garantit sota càrrega. Fes memòria cau.
• Escriure el secret a la línia d'ordres. Queda a l'historial de l'intèrpret d'ordres i als registres de la canalització. Llegeix-lo de l'entrada estàndard o d'una variable protegida.
• Consell: un magatzem per entorn i per àmbit de confiança. kv-contoso-pro i kv-contoso-dev separats, mai el mateix magatzem per a producció i desenvolupament.
• Consell: posa una alerta sobre el registre d'auditoria per a lectures des d'identitats inesperades. És un dels senyals de compromís més nets que existeixen.

«Contoso Millas» (centro-coste=CC-2077) necessita guardar: la clau d'una API de socis comercials, el certificat TLS del seu subdomini, una clau de xifratge per a les dades dels clients i la cadena de connexió d'una base heretada.

1. Classifica els quatre elements com a secret, clau o certificat, i justifica-ho.
2. Escriu l'ordre de creació del magatzem amb les opcions adequades i explica cadascuna.
3. Quins rols assignaries a la identitat administrada de l'aplicació i al grup de desenvolupament, i en quin àmbit?

La passarel·la de pagament admet dues claus actives simultàniament i Contoso ha de rotar cada 180 dies sense tallar la venda de bitllets.

1. Descriu els cinc passos del procés, indicant què es fa al proveïdor i què a Azure.
2. Com automatitzaries l'avís que s'acosta la caducitat?
3. L'aplicació guarda el secret en memòria cau 12 hores. Què implica això per al pas de revocació?

1. Després de desplegar, l'aplicació arrenca però falla en cridar la passarel·la; als ajustos, ClavePasarelaPago apareix amb un error de referència.
2. Un procés per lots que llegeix 40 secrets a l'inici de cada tasca comença a rebre HTTP 429 en augmentar la concurrència.
3. L'equip va esborrar kv-contoso-dev i en recrear-lo amb el mateix nom rep un error de conflicte.

Solució 1:

1. Clau de l'API de socis: secret, perquè cal tornar-ne el valor a l'aplicació. Certificat TLS: certificat, per aprofitar la renovació automàtica i la integració amb App Service. Clau de xifratge: clau, perquè no ha de sortir mai del magatzem i només es fa servir per a operacions criptogràfiques. Cadena de connexió heretada: secret (i a mitjà termini, substituir-la per identitat administrada si el motor ho permet).
2. az keyvault create -n kv-contoso-millas-pro -g rg-contoso-seguridad-pro -l westeurope --sku standard --enable-rbac-authorization true --enable-purge-protection true --retention-days 90 --public-network-access Disabled més les quatre etiquetes obligatòries amb centro-coste=CC-2077. RBAC perquè és el model recomanat i permet àmbit per secret; protecció contra purga perquè hi ha una clau de xifratge i la seva pèrdua faria irrecuperables les dades; xarxa pública deshabilitada més punt de connexió privat; retenció de 90 dies per ser producció.
3. A la identitat administrada, Usuari de Key Vault Secrets amb àmbit del secret concret que necessita, i Usuari de Key Vault Crypto sobre la clau de xifratge si hi opera. Al grup de desenvolupament, cap rol de dades al magatzem de producció: com a molt Lector de Key Vault (metadades, sense valors) per diagnosticar, i Responsable de Secrets només a kv-contoso-millas-dev.

Solució 2:

1. (a) Generar la clau secundària al portal de la passarel·la, deixant activa l'actual. (b) Escriure la nova versió del secret a Key Vault amb az keyvault secret set, fent servir l'URI sense versió a la referència per no tornar a desplegar. (c) Reiniciar l'aplicació o esperar que expiri la memòria cau de totes les instàncies. (d) Comprovar als registres del proveïdor que el trànsit arriba amb la clau nova. (e) Revocar la clau antiga al proveïdor.
2. Amb Event Grid: l'esdeveniment SecretNearExpiry s'emet 30 dies abans de la data d'--expires, i es connecta a una Logic App (06-04) que obre un tiquet i avisa per correu el propietari indicat a les etiquetes del secret. Requereix haver posat la data de caducitat en crear el secret.
3. Que no es pot revocar l'antiga fins passades com a mínim 12 hores des de l'escriptura de la nova, o fins a haver reiniciat totes les instàncies. Revocar-la abans provoca fallades de pagament a les instàncies que encara serveixen la clau en memòria cau. Per això el pas 4 —verificar al proveïdor— és obligatori i no una formalitat.

Solució 3:

1. La referència no es resol. Causes per ordre: la identitat administrada no té el rol Usuari de Key Vault Secrets en aquest secret; el nom del secret està mal escrit; el tallafoc del magatzem bloqueja App Service (falta --bypass AzureServices); o el magatzem fa servir directives d'accés i no RBAC. Es diagnostica amb az webapp config appsettings list, que mostra l'error concret de la referència.
2. S'està superant la limitació de sol·licituds del magatzem. Solució: guardar en memòria cau els 40 secrets durant hores en lloc de tornar-los a llegir per tasca, agrupar la càrrega a l'arrencada del procés i no per tasca, i aplicar reintents amb espera exponencial davant del 429. Si el volum és realment necessari, repartir-los en diversos magatzems per domini funcional.
3. És l'eliminació temporal: el magatzem continua existint en estat eliminat i el seu nom està reservat. Solució correcta, az keyvault recover -n kv-contoso-dev, que el restaura amb tots els seus secrets. Si de debò es volia destruir, az keyvault purge, que només funciona si no tenia protecció contra purga i requereix el permís corresponent.

Contoso ja no té secrets repartits. Has fet l'inventari incòmode del punt de partida —ajustos en clar, un testimoni a l'historial de Git, un document compartit, un PFX en un portàtil— i l'has centralitzat a kv-contoso-pro, dins de rg-contoso-seguridad-pro. Distingeixes els tres tipus d'objecte: secrets, que es tornen; claus, que no surten mai del magatzem i operen a dins; i certificats, amb el seu cicle de vida i renovació automàtica. Saps que Estàndard n'hi ha prou per a gairebé tot, que Premium aporta HSM certificat i que Managed HSM costa milers d'euros al mes i només es justifica si ho exigeix un auditor.

Has creat el magatzem amb eliminació temporal —sempre activa, no desactivable— i protecció contra purga, entenent que és irreversible i que el nom d'un magatzem eliminat queda reservat durant la retenció. Has triat RBAC d'Azure davant de les directives d'accés heretades, amb el matís decisiu que permet concedir un secret concret a una identitat concreta, i coneixes els rols de dades i el parany de Col·laborador de Key Vault. Has tancat la xarxa amb el punt de connexió privat pe-kv-contoso, la seva zona DNS i l'excepció de serveis de confiança. Domines el versionat de secrets i les seves dates, els tres mecanismes de rotació —gestionada per a claus d'emmagatzematge, avisos per Event Grid i el patró de cinc passos sense caiguda, que exigeix que el proveïdor admeti dues credencials alhora—, i els certificats TLS gestionats que App Service i Application Gateway consumeixen sols. Sobretot, has arribat al moment en què les contrasenyes desapareixen del desplegament: les referències @Microsoft.KeyVault(...) resolen els ajustos amb la identitat administrada de 04-02 sense tocar ni una línia de codi. Tanquen la lliçó les claus gestionades pel client amb el seu poder de revocació i el seu risc de pèrdua definitiva, l'auditoria enviada a Log Analytics i els límits que obliguen a fer memòria cau.

Amb identitats governades, permisos mínims i zero secrets exposats, l'interior de la plataforma està raonablement sa. El problema és que Contoso Reserves és un web públic: qualsevol a internet li pot llançar peticions, i allà no valen ni RBAC ni Key Vault. A la lliçó següent, Protecció DDoS i tallafoc d'aplicacions web, veuràs quins atacs arriben de debò a un web de venda de bitllets —volumètrics, de protocol, de capa d'aplicació i els bots que exhaureixen les places de la cistella—, muntaràs una directiva de WAF sobre fd-contoso-global amb el conjunt de regles d'OWASP, aprendràs per què sempre es comença en mode detecció i compararàs què protegeix exactament cada capa: NSG, Azure Firewall, WAF i DDoS.