Las identidades administradas de la lección anterior eliminaron los secretos de acceso a sttarjetascontosopro y a db-reservas, y esa es la mejor noticia posible: el secreto que no existe no se puede filtrar. Pero no todo se resuelve así. Contoso Airlines sigue necesitando la clave de la pasarela de pago, el token del proveedor de datos meteorológicos que alimenta las previsiones de retraso, la cadena de conexión del sistema heredado de facturación que aún corre en Barcelona y el certificado TLS de contosoairlines.example. Ninguno de esos sistemas habla Entra ID, así que el secreto existe y hay que guardarlo en algún sitio. Hoy ese sitio pasa a ser Azure Key Vault: un almacén respaldado por hardware, con permisos por RBAC, red cerrada, versionado y auditoría de cada lectura. Al terminar, app-contoso-reservas-pro leerá sus secretos con la identidad administrada de 04-02 y no habrá una sola contraseña en el despliegue.

Aviso importante: la gestión de claves y secretos toca directamente el cumplimiento normativo —PCI DSS para los pagos, RGPD para los datos de pasajeros— y una configuración incorrecta puede provocar tanto una brecha como una pérdida irreversible de datos cifrados. Antes de llevar a producción cualquier diseño de Key Vault, de rotación o de claves gestionadas por el cliente, debe revisarlo un profesional de seguridad o el equipo de compliance de tu organización.

1. Dónde viven hoy los secretos de Contoso
2. Qué guarda Key Vault: secretos, claves y certificados
3. Niveles Estándar, Premium y Managed HSM
4. Crear kv-contoso-pro con eliminación temporal y protección contra purga
5. Los dos modelos de permisos: directivas de acceso frente a RBAC
6. Acceso desde red: firewall, punto de conexión privado y servicios de confianza
7. Guardar, recuperar y versionar secretos
8. Rotación de secretos sin caída
9. Certificados TLS gestionados
10. Consumir secretos desde App Service con referencias de Key Vault
11. Claves de cifrado gestionadas por el cliente
12. Auditoría, límites y qué NO poner en el almacén
13. Errores Comunes y Consejos
14. Ejercicios
15. Conclusión

Un inventario honesto antes de arreglar nada:

Ninguno ha rotado nunca, nadie sabe quién los ha leído y su revocación exigiría buscarlos por cinco sitios. Key Vault resuelve las cuatro cosas a la vez: almacenamiento centralizado, control de acceso por identidad, auditoría de cada operación y rotación gestionada.

La distinción entre secreto y clave es la más importante y la que más se confunde. Un secreto se guarda para devolverlo: la aplicación pide la clave de la pasarela y recibe el texto. Una clave nunca se devuelve: se le envía a Key Vault el dato para que él lo cifre, firme o descifre, y la clave privada no abandona jamás el módulo criptográfico. Por eso las claves de cifrado se guardan como claves y no como secretos: aunque alguien robara el token de acceso, no podría exfiltrar el material criptográfico.

Un certificado es en realidad tres objetos coordinados: el certificado, una clave y un secreto que contiene el PFX completo. Key Vault gestiona además su ciclo de vida, incluida la renovación automática.

Contoso elige Estándar para kv-contoso-pro. Es la decisión correcta salvo que una norma exija explícitamente HSM certificado de nivel 3, y conviene saber que el nivel no se puede cambiar de Premium a Estándar una vez creado (de Estándar a Premium sí). Azure Managed HSM existe, cuesta miles de euros al mes y solo tiene sentido cuando el propio auditor lo exige por escrito.

Tres opciones merecen explicación detallada:

• Eliminación temporal (soft delete): está siempre activada y no se puede desactivar. Al borrar un secreto, una clave o el almacén entero, el objeto pasa a estado eliminado y se conserva durante --retention-days (de 7 a 90). Durante ese tiempo se puede recuperar con az keyvault recover.
• Protección contra purga: impide eliminar definitivamente el objeto durante la retención, ni siquiera a un Propietario. Una vez activada tampoco se puede desactivar. Es incómoda a propósito: convierte un borrado malicioso o accidental en algo reversible.
• La consecuencia práctica que sorprende a todo el mundo: mientras un almacén eliminado siga en retención, su nombre queda reservado globalmente y no se puede crear otro igual. Si borras kv-contoso-pro en una prueba, no podrás recrearlo con ese nombre hasta 90 días después (o antes purgándolo, salvo que la protección contra purga lo impida, que es justo el caso). Por eso los almacenes de prueba se crean con nombres desechables y --retention-days 7.

Con --enable-rbac-authorization true, los permisos del plano de datos se conceden con los mismos roles del resto de Azure. Los que se usan:

Ese último es la trampa de 04-02 aplicada aquí: Colaborador de Key Vault no permite leer un solo secreto. Sí permite, en cambio, cambiar la configuración del almacén, motivo por el cual también es un rol privilegiado que conviene mantener bajo PIM.

Fíjate en el ámbito de la primera asignación: un secreto concreto, no el almacén. Si app-contoso-reservas-pro se ve comprometida, el atacante obtiene esa clave y nada más.

Con --public-network-access Disabled el almacén no responde en internet. El acceso llega por un punto de conexión privado en snet-datos, exactamente igual que pe-sql-reservas y pe-storage-tarjetas del módulo 2:

Y hay que registrar el nombre en DNS privado, o el cliente seguirá resolviendo la IP pública: se crea la zona privatelink.vaultcore.azure.net, se vincula a vnet-contoso-pro y se asocia al punto de conexión con un grupo de zonas DNS. Sin ese paso, el punto de conexión existe y no lo usa nadie: es el fallo más frecuente de Private Link.

Queda un matiz operativo. Ciertos servicios de Azure —App Service leyendo referencias, Azure SQL descifrando con clave del cliente, Event Grid— no salen por la red virtual. Para ellos existe la excepción de servicios de confianza de Microsoft, que hay que activar explícitamente:

--bypass AzureServices permite el paso a esa lista cerrada de servicios; --default-action Deny sigue rechazando todo lo demás. La excepción no es un agujero abierto: cada servicio de la lista debe además tener un rol asignado.

Cada secreto tiene un identificador con versión, https://kv-contoso-pro.vault.azure.net/secrets/pasarela-pago-clave/a1b2c3..., y otro sin versión que apunta siempre a la actual. La regla práctica: usa el identificador sin versión para que la rotación no obligue a redesplegar, salvo que necesites fijar una versión concreta por reproducibilidad.

Los atributos --expires y --not-before no bloquean la lectura por sí mismos en todos los clientes: son metadatos que alimentan los avisos de caducidad y las consultas de auditoría. Ponlos siempre; ignorarlos es lo que hace que una clave lleve cuatro años sin rotar.

Rotar es sustituir un secreto por uno nuevo sin que nada deje de funcionar. Tres mecanismos, de más a menos automático:

Rotación totalmente gestionada. Para las claves de cuentas de almacenamiento, Key Vault puede regenerarlas por sí mismo. Se crea un secreto de tipo cuenta administrada, se le indica cada cuánto rotar, y Key Vault alterna entre key1 y key2 regenerando la que no está en uso:

Nótese la ironía saludable: Contoso ya no usa esas claves porque pasó a identidad administrada (04-02). Este mecanismo es para las cuentas heredadas que aún no han migrado.

Notificación de caducidad por Event Grid. Key Vault publica eventos SecretNearExpiry (30 días antes) y SecretExpired, que pueden disparar una función o una Logic App que llame a la API del proveedor, obtenga una credencial nueva y escriba la versión en el almacén. Es el patrón para secretos de terceros como la pasarela de pago.

El patrón de rotación sin caída, que es lo importante conceptualmente y vale para cualquier secreto:

La clave está en el paso 1: el proveedor debe admitir dos credenciales válidas a la vez. Si solo admite una, no hay rotación sin caída posible y habrá que planificar una ventana de mantenimiento. Es una pregunta que conviene hacerle a cada proveedor antes de integrarlo.

Key Vault puede emitir y renovar certificados automáticamente si se integra con una autoridad de certificación asociada (DigiCert, GlobalSign), o custodiar certificados importados de cualquier otra. Se define una directiva con el asunto, los nombres alternativos, la vigencia y el porcentaje de vida a partir del cual se renueva:

Desde ahí, app-contoso-reservas-pro importa el certificado con az webapp config ssl import --key-vault $KV --key-vault-certificate-name cert-contosoairlines, y cuando Key Vault lo renueva, App Service recoge la versión nueva sin intervención. Application Gateway hace lo mismo referenciando el identificador del certificado, y ahí es donde se usará en la lección 04-04 al montar el firewall de aplicaciones web. La alternativa gratuita para casos sencillos son los certificados administrados de App Service, que ya viste en 02-03; Key Vault es la opción cuando el mismo certificado debe compartirse entre varios servicios.

Este es el momento en que las contraseñas desaparecen del despliegue. Una referencia de Key Vault es un ajuste de aplicación cuyo valor no es el secreto, sino un puntero:

Lo que ocurre por debajo: al arrancar, App Service usa la identidad administrada de 04-02 para pedir el token, resuelve la referencia y expone el valor a la aplicación como una variable de entorno normal. Consecuencias que conviene tener claras:

• El código no cambia: sigue leyendo ClavePasarelaPago como siempre. No hay SDK que añadir.
• El secreto no está en la configuración: quien tenga config/list ve el puntero, no el valor.
• La resolución ocurre al arrancar y se cachea 24 horas (o al reiniciar). Tras rotar un secreto, hay que reiniciar la aplicación o esperar; si usaste el URI sin versión, la referencia recoge la versión nueva.
• Si la referencia falla, la aplicación arranca sin ese ajuste y suele fallar de forma confusa. Comprueba siempre el estado con az webapp config appsettings list, donde una referencia rota se muestra con su error.

Cuando la aplicación necesita leer secretos en caliente (no solo al arrancar), se usa SecretClient del SDK con DefaultAzureCredential, la misma credencial de 04-02, y siempre con caché propia, por el motivo del apartado 12.

Todo lo que guarda Azure está cifrado en reposo con claves de Microsoft, sin que haya que hacer nada. Las claves gestionadas por el cliente (CMK) cambian quién controla la clave: la genera Contoso en kv-contoso-pro, y el servicio la usa mediante su identidad administrada.

Qué aporta de verdad: la capacidad de revocar. Si se deshabilita la clave, sttarjetascontosopro deja de poder descifrar sus datos de forma inmediata; es el "botón rojo" que exigen algunos auditores. Y qué cuesta: si esa clave se borra o se pierde, los datos son irrecuperables, sin que Microsoft pueda hacer nada. Por eso la protección contra purga es obligatoria en almacenes con CMK, y por eso Contoso las aplica solo a sttarjetascontosopro y a db-reservas, donde hay datos personales, y no al resto. La rotación de una CMK es transparente: se cifra de nuevo la clave de datos, no los datos.

Key Vault registra cada operación del plano de datos: quién leyó qué secreto, desde qué IP y con qué resultado. Esos registros no se conservan en el almacén, hay que enviarlos:

Con eso, en Log Analytics (07-02) se puede responder a preguntas como "¿quién leyó la clave de la pasarela fuera del horario laboral?" o "¿qué identidades han accedido a este secreto en los últimos 90 días?". Es requisito directo de PCI DSS y la razón por la que el área de trabajo vive en rg-contoso-seguridad-pro junto al almacén.

Sobre límites de rendimiento: Key Vault aplica limitación de solicitudes por almacén y región (del orden de 2.000 operaciones de secreto por 10 segundos, menos para operaciones con claves RSA). Al superarla devuelve HTTP 429. Por eso la regla es innegociable: la aplicación cachea los secretos en memoria durante horas y solo los relee al rotar o al recibir un error de autenticación. Un servicio que pide el secreto en cada petición HTTP tumba su propio almacén en cuanto llega tráfico real.

Y qué no debe ir a Key Vault:

• Configuración que no es secreta (URLs, nombres de servidor, banderas de funcionalidad): va a App Configuration o a los ajustes normales.
• Datos de negocio o datos personales: no es una base de datos. Un secreto son 25 KB como máximo.
• Ficheros grandes, aunque sean sensibles: cífralos y guárdalos en el almacenamiento, con la clave en Key Vault.
• Secretos de usuarios finales (contraseñas de pasajeros): esas viven en Entra External ID (04-01), con su hash, nunca aquí.

• Crear el almacén con directivas de acceso "porque es lo que sale en tutoriales antiguos". Usa --enable-rbac-authorization true desde el principio; migrar después es tedioso.
• Esperar que Colaborador de Key Vault deje leer secretos. No lo hace: gestiona el almacén, no sus datos.
• Borrar un almacén de prueba y no poder recrearlo con el mismo nombre. El nombre queda reservado durante la retención. Usa nombres desechables y 7 días de retención en pruebas.
• Activar protección contra purga sin entenderla. Es irreversible. En producción es obligatoria; en un curso o una prueba, evítala.
• Olvidar la zona DNS privada del punto de conexión. El almacén queda inaccesible con un error de red que no dice nada.
• Pedir el secreto en cada petición. HTTP 429 garantizado bajo carga. Cachea.
• Escribir el secreto en la línea de comandos. Queda en el historial del shell y en los registros de la canalización. Léelo de la entrada estándar o de una variable protegida.
• Consejo: un almacén por entorno y por ámbito de confianza. kv-contoso-pro y kv-contoso-dev separados, nunca el mismo almacén para producción y desarrollo.
• Consejo: pon una alerta sobre el registro de auditoría para lecturas desde identidades inesperadas. Es de las señales de compromiso más limpias que existen.

"Contoso Millas" (centro-coste=CC-2077) necesita guardar: la clave de una API de socios comerciales, el certificado TLS de su subdominio, una clave de cifrado para los datos de los clientes y la cadena de conexión de una base heredada.

1. Clasifica los cuatro elementos como secreto, clave o certificado, y justifícalo.
2. Escribe el comando de creación del almacén con las opciones adecuadas y explica cada una.
3. ¿Qué roles asignarías a la identidad administrada de la aplicación y al grupo de desarrollo, y en qué ámbito?

La pasarela de pago admite dos claves activas simultáneamente y Contoso debe rotar cada 180 días sin cortar la venta de billetes.

1. Describe los cinco pasos del proceso, indicando qué se hace en el proveedor y qué en Azure.
2. ¿Cómo automatizarías el aviso de que se acerca la caducidad?
3. La aplicación cachea el secreto 12 horas. ¿Qué implica eso para el paso de revocación?

1. Tras desplegar, la aplicación arranca pero falla al llamar a la pasarela; en los ajustes, ClavePasarelaPago aparece con un error de referencia.
2. Un proceso por lotes que lee 40 secretos al inicio de cada tarea empieza a recibir HTTP 429 al aumentar la concurrencia.
3. El equipo borró kv-contoso-dev y al recrearlo con el mismo nombre recibe un error de conflicto.

Solución 1:

1. Clave de la API de socios: secreto, porque hay que devolver su valor a la aplicación. Certificado TLS: certificado, para aprovechar la renovación automática y la integración con App Service. Clave de cifrado: clave, porque nunca debe salir del almacén y solo se usa para operaciones criptográficas. Cadena de conexión heredada: secreto (y a medio plazo, sustituirla por identidad administrada si el motor lo permite).
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 las cuatro etiquetas obligatorias con centro-coste=CC-2077. RBAC porque es el modelo recomendado y permite ámbito por secreto; protección contra purga porque hay una clave de cifrado y su pérdida haría irrecuperables los datos; red pública deshabilitada más punto de conexión privado; retención de 90 días por ser producción.
3. A la identidad administrada, Usuario de Key Vault Secrets con ámbito del secreto concreto que necesita, y Usuario de Key Vault Crypto sobre la clave de cifrado si opera con ella. Al grupo de desarrollo, ningún rol de datos en el almacén de producción: como mucho Lector de Key Vault (metadatos, sin valores) para diagnosticar, y Responsable de Secretos solo en kv-contoso-millas-dev.

Solución 2:

1. (a) Generar la clave secundaria en el portal de la pasarela, dejando activa la actual. (b) Escribir la nueva versión del secreto en Key Vault con az keyvault secret set, usando el URI sin versión en la referencia para no redesplegar. (c) Reiniciar la aplicación o esperar a que expire la caché de todas las instancias. (d) Comprobar en los registros del proveedor que el tráfico llega con la clave nueva. (e) Revocar la clave antigua en el proveedor.
2. Con Event Grid: el evento SecretNearExpiry se emite 30 días antes de la fecha de --expires, y se conecta a una Logic App (06-04) que abre un ticket y avisa por correo al propietario indicado en las etiquetas del secreto. Requiere haber puesto la fecha de caducidad al crear el secreto.
3. Que no se puede revocar la antigua hasta pasadas al menos 12 horas desde la escritura de la nueva, o hasta haber reiniciado todas las instancias. Revocar antes provoca fallos de pago en las instancias que aún sirven la clave cacheada. Por eso el paso 4 —verificar en el proveedor— es obligatorio y no una formalidad.

Solución 3:

1. La referencia no se resuelve. Causas por orden: la identidad administrada no tiene el rol Usuario de Key Vault Secrets en ese secreto; el nombre del secreto está mal escrito; el firewall del almacén bloquea a App Service (falta --bypass AzureServices); o el almacén usa directivas de acceso y no RBAC. Se diagnostica con az webapp config appsettings list, que muestra el error concreto de la referencia.
2. Se está superando la limitación de solicitudes del almacén. Solución: cachear los 40 secretos en memoria durante horas en lugar de releerlos por tarea, agrupar la carga en el arranque del proceso y no por tarea, y aplicar reintentos con espera exponencial ante el 429. Si el volumen es realmente necesario, repartir en varios almacenes por dominio funcional.
3. Es la eliminación temporal: el almacén sigue existiendo en estado eliminado y su nombre está reservado. Solución correcta, az keyvault recover -n kv-contoso-dev, que lo restaura con todos sus secretos. Si de verdad se quería destruir, az keyvault purge, que solo funciona si no tenía protección contra purga y requiere el permiso correspondiente.

Contoso ya no tiene secretos repartidos. Has hecho el inventario incómodo del punto de partida —ajustes en claro, un token en el historial de Git, un documento compartido, un PFX en un portátil— y lo has centralizado en kv-contoso-pro, dentro de rg-contoso-seguridad-pro. Distingues los tres tipos de objeto: secretos, que se devuelven; claves, que nunca salen del almacén y operan dentro de él; y certificados, con su ciclo de vida y renovación automática. Sabes que Estándar basta para casi todo, que Premium aporta HSM certificado y que Managed HSM cuesta miles de euros al mes y solo se justifica si lo exige un auditor.

Has creado el almacén con eliminación temporal —siempre activa, no desactivable— y protección contra purga, entendiendo que es irreversible y que el nombre de un almacén eliminado queda reservado durante la retención. Has elegido RBAC de Azure frente a las directivas de acceso heredadas, con el matiz decisivo de que permite conceder un secreto concreto a una identidad concreta, y conoces los roles de datos y la trampa de Colaborador de Key Vault. Has cerrado la red con el punto de conexión privado pe-kv-contoso, su zona DNS y la excepción de servicios de confianza. Manejas el versionado de secretos y sus fechas, los tres mecanismos de rotación —gestionada para claves de almacenamiento, avisos por Event Grid y el patrón de cinco pasos sin caída, que exige que el proveedor admita dos credenciales a la vez—, y los certificados TLS gestionados que App Service y Application Gateway consumen solos. Sobre todo, has llegado al momento en que las contraseñas desaparecen del despliegue: las referencias @Microsoft.KeyVault(...) resuelven los ajustes con la identidad administrada de 04-02 sin tocar una línea de código. Cierran la lección las claves gestionadas por el cliente con su poder de revocación y su riesgo de pérdida definitiva, la auditoría enviada a Log Analytics y los límites que obligan a cachear.

Con identidades gobernadas, permisos mínimos y cero secretos expuestos, el interior de la plataforma está razonablemente sano. El problema es que Contoso Reservas es una web pública: cualquiera en internet puede lanzarle peticiones, y ahí no valen ni RBAC ni Key Vault. En la siguiente lección, Protección DDoS y firewall de aplicaciones web, verás qué ataques llegan de verdad a una web de venta de billetes —volumétricos, de protocolo, de capa de aplicación y los bots que agotan las plazas del carrito—, montarás una directiva de WAF sobre fd-contoso-global con el conjunto de reglas de OWASP, aprenderás por qué se empieza siempre en modo detección y compararás qué protege exactamente cada capa: NSG, Azure Firewall, WAF y DDoS.