Las cuatro lecciones anteriores han asegurado piezas concretas: identidades, permisos, secretos y perímetro. Todas comparten una limitación incómoda: había que saber que el problema existía para ir a arreglarlo. Nadie ha comprobado todavía si vm-motor-disponibilidad-dev quedó con el puerto 22 abierto a internet en las pruebas del módulo 2, si alguna cuenta de almacenamiento admite tráfico sin cifrar, o si alguien está intentando entrar en db-reservas desde una IP de un país donde Contoso Airlines no tiene ni un empleado. Eso es lo que hace Microsoft Defender for Cloud: mira la plataforma entera de forma continua, la compara con un catálogo de buenas prácticas, dice qué falta ordenado por impacto y avisa cuando algo se comporta de forma anómala. Es el salto del control puntual a la postura de seguridad continua.

Aviso de coste importante: el nivel gratuito de evaluación y recomendaciones no cuesta nada, pero los planes de Defender sí, y bastante: del orden de 14 €/servidor al mes, 13 € por millón de transacciones en Storage, 13 €/instancia de SQL al mes, unos 2 € por vCore de contenedores y unos 0,02 € por 10.000 operaciones de Key Vault. Una suscripción mediana con todos los planes activados a la vez pasa fácilmente de 1.000 € al mes. Actívalos por suscripción y por plan, empezando por los recursos que guardan datos sensibles, y usa siempre la estimación de coste que el propio portal muestra antes de confirmar.

1. CSPM y CWPP: las dos mitades del problema
2. La puntuación de seguridad y cómo usarla de verdad
3. Nivel gratuito frente a planes de pago
4. Activar Defender en la suscripción de producción
5. Recomendaciones: corrección rápida, exención y denegación
6. Las diez primeras recomendaciones de Contoso
7. Alertas de seguridad e investigación
8. Cadena de ataque y el salto a Microsoft Sentinel
9. Cumplimiento normativo y el caso PCI DSS
10. Nubes distintas y recursos locales
11. Automatización de flujos de trabajo
12. Errores Comunes y Consejos
13. Ejercicios
14. Conclusión

Defender for Cloud es en realidad dos productos bajo un mismo panel, y confundirlos lleva a activar lo que no se necesita:

La distinción práctica: el CSPM básico es gratuito y hay que activarlo hoy mismo en todas las suscripciones, sin discusión, porque no cuesta nada y descubre la mitad de los problemas reales. Existe además el CSPM Defender de pago, que añade análisis de rutas de ataque, consultas sobre el grafo de seguridad de la nube y análisis de máquinas sin agente. El CWPP —los planes por recurso— se activa con criterio y de forma selectiva, porque es lo que se factura.

La puntuación de seguridad resume la postura en un porcentaje. Se calcula así:

• Las recomendaciones se agrupan en controles de seguridad (por ejemplo, "Habilitar MFA", "Corregir vulnerabilidades", "Restringir el acceso a la red").
• Cada control vale un número de puntos (los más críticos, hasta 10).
• Un control solo suma cuando todos sus recursos lo cumplen, con puntuación parcial proporcional a los recursos correctos.
• La puntuación final es la suma obtenida sobre la máxima posible.

Contoso arranca en 38 %. Y aquí llega el consejo que más ahorra tiempo: el objetivo no es el 100 %. Perseguirlo lleva a gastar semanas en recomendaciones irrelevantes para tu contexto, o a activar planes de pago carísimos solo para subir el marcador. La puntuación sirve para tres cosas:

1. Priorizar: atacar primero los controles con más puntos posibles y menos recursos afectados, que es donde el esfuerzo rinde más.
2. Medir tendencia: que suba de forma sostenida mes a mes importa mucho más que su valor absoluto.
3. Comunicar: es la métrica que la dirección entiende, y la que justifica el presupuesto de seguridad.

Regla práctica de Contoso: el objetivo trimestral es 70 %, con todos los controles de gravedad alta resueltos o formalmente exentos con justificación escrita.

Advertencia explícita: activar los ocho planes en las dos suscripciones de Contoso supera holgadamente los 1.000 € al mes, más de lo que cuesta buena parte de la infraestructura que protegen. Los planes se activan por suscripción y por plan, y ese es el mecanismo que hay que usar:

• En Contoso Airlines - Producción: SQL (guarda datos personales de pasajeros y es el activo crítico), Storage (tarjetas de embarque) y Key Vault (acceso a secretos). El plan de Servidores se activa solo en vmss-api-disponibilidad-pro, no en todo.
• En Contoso Airlines - Desarrollo: solo el nivel gratuito. Los datos son ficticios y el riesgo, bajo.

Los 30 días de prueba gratuita son útiles para ver el volumen real de alertas antes de comprometerse, pero hay que anotar la fecha de fin en el calendario: si nadie lo desactiva, empieza a facturar sin avisar.

El paso 3 no es opcional en la práctica: sin enviar los datos al área de trabajo de rg-contoso-seguridad-pro, las alertas viven solo en el panel de Defender, no se pueden correlacionar con los registros de Key Vault ni con los del WAF de 04-04, y no hay historial más allá de la retención por defecto. Es la misma decisión que se tomó con la auditoría del almacén en 04-03, y el módulo 7 la explota a fondo con KQL.

Para servidores conviene además el aprovisionamiento automático de las extensiones, de modo que toda VM nueva reciba los agentes sin intervención manual. Es un buen ejemplo de por qué Defender y Azure Policy son inseparables: ese aprovisionamiento se implementa, por debajo, con políticas de tipo DeployIfNotExists como las que verás en 04-06.

Cada recomendación trae gravedad, recursos afectados, impacto en la puntuación y pasos de corrección. Hay tres formas de tratarla:

Sobre las exenciones, dos reglas de higiene: siempre con justificación escrita y caducidad (por ejemplo, seis meses), y revisadas al vencer. Una exención permanente y sin motivo documentado es exactamente igual que ignorar la recomendación, solo que con mejor aspecto en el panel. Y la denegación es el mecanismo que convierte una recomendación en una regla: se hace con Azure Policy, que es la lección siguiente.

Este es el listado real que Defender saca la primera semana, con lo que el equipo decide en cada caso:

Merece la pena fijarse en el patrón: de diez recomendaciones, dos ya estaban cumplidas gracias al trabajo de las lecciones anteriores, una se corrige con un clic, una se resuelve mejor con una política que caso a caso, y dos se exceptúan con justificación y caducidad. Esa mezcla es el trabajo real de seguridad; el panel al 100 % no lo es.

Las alertas nacen de los planes de pago y se generan por tres vías: análisis del comportamiento (algo se desvía de la línea base aprendida), inteligencia de amenazas (una IP o un hash aparecen en fuentes conocidas) y detecciones específicas de cada servicio. Sus gravedades son Alta, Media, Baja e Informativa.

Un ejemplo realista en Contoso:

La investigación, paso a paso:

1. Contexto: son las 03:17, fuera de horario. La identidad es la de la aplicación, que nunca debería usar sqlcmd: la aplicación se conecta con su SDK. Ya hay dos señales fuertes.
2. Correlacionar: buscar en Log Analytics si esa IP aparece en los registros del WAF, en los inicios de sesión de Entra ID o en la auditoría de kv-contoso-pro de las horas previas.
3. Determinar el alcance: SELECT * FROM dbo.Reservas sin filtro apunta a exfiltración masiva, no a una consulta operativa. Se mira el volumen de datos devuelto en la auditoría de SQL (03-02).
4. Contener: si se confirma, revocar los tokens de la identidad, bloquear la IP en el WAF y en el NSG, y aislar el recurso comprometido.
5. Erradicar y recuperar: encontrar cómo se obtuvo el acceso —¿un token robado?, ¿una cadena de conexión antigua que sobrevivió a 04-02?—, cerrarlo y restaurar desde una copia limpia si hubo modificación.
6. Documentar: cronología, alcance del dato afectado y, si hay datos personales de pasajeros, notificación al regulador dentro del plazo legal del RGPD.

En este caso concreto, la causa más probable es la más aburrida: una cadena de conexión antigua que quedó en un script y que alguien ejecutó desde fuera. Que la investigación acabe en algo trivial no significa que la alerta sobrara; significa que el proceso funciona.

Una alerta aislada dice poco. Defender agrupa alertas relacionadas en incidentes y muestra la ruta de ataque: cadenas de configuraciones que, combinadas, permiten llegar a un dato sensible. Por ejemplo: "VM expuesta a internet → con una vulnerabilidad crítica sin parchear → con una identidad administrada que tiene rol de Colaborador de datos sobre sttarjetascontosopro". Ninguno de los tres elementos es alarmante por separado; juntos son una ruta de exfiltración completa. Ese análisis pertenece al CSPM Defender de pago y es, probablemente, lo que más justifica su precio.

Microsoft Sentinel es el escalón siguiente: el SIEM y SOAR nativo de Azure. Mientras Defender for Cloud protege los recursos de Azure, Sentinel correlaciona todas las fuentes —Defender, Entra ID, Microsoft 365, cortafuegos, sistemas locales, aplicaciones de terceros—, aplica reglas de análisis y automatiza la respuesta con manuales de estrategia. Se factura por GB ingeridos, así que la decisión de qué registros enviar es a la vez de seguridad y económica. Contoso lo tiene en su hoja de ruta para cuando exista un equipo de seguridad dedicado: sin alguien que atienda los incidentes, un SIEM es un gasto que genera alertas que nadie mira.

El panel de cumplimiento normativo asocia las recomendaciones a los controles de estándares reconocidos:

Contoso procesa pagos con tarjeta, así que PCI DSS le aplica, y eso tiene consecuencias concretas que ya has ido montando sin nombrarlas: cifrado en tránsito y en reposo, segmentación de la red que toca datos de tarjeta, control de acceso por identidad con mínimo privilegio, auditoría de todos los accesos (de ahí los registros de Key Vault y de SQL en Log Analytics), gestión de vulnerabilidades y retención de registros de al menos un año.

Dos advertencias serias. Primera: el panel muestra el cumplimiento de los controles técnicos que Azure puede evaluar automáticamente; un estándar como PCI DSS incluye además controles de proceso, formación, contratos y seguridad física que ninguna herramienta mide. Un 100 % en el panel no es una certificación. Segunda, y por eso este aviso se repite: el diseño de cumplimiento debe validarlo un auditor cualificado o el equipo de compliance de tu organización antes de darlo por bueno. La herramienta ayuda; no certifica.

Defender for Cloud no se limita a Azure. Puede conectar cuentas de AWS y proyectos de Google Cloud mediante un conector nativo sin agentes, evaluando su configuración con los mismos criterios y mostrando todo en un único panel de postura multinube. Y los servidores locales —incluido el AD de la oficina de Barcelona y el sistema heredado de facturación— se incorporan con Azure Arc, que los proyecta como recursos de Azure y les aplica planes, políticas y recomendaciones. Para Contoso es la vía de tener una sola visión de seguridad sin migrar antes toda la infraestructura, algo que enlaza directamente con la estrategia de migración de 09-04.

Una alerta que llega a un correo que nadie lee no sirve de nada. La automatización de flujos de trabajo dispara una Logic App (06-04) cuando se genera una alerta o una recomendación que cumpla un filtro:

Contoso lo usa para tres cosas: avisar por Teams al canal de guardia ante gravedad Alta, abrir automáticamente un ticket con el contexto de la alerta, y ejecutar contenciones simples y reversibles, como aislar por NSG una VM con una alerta de minería de criptomonedas. La automatización agresiva conviene reservarla para casos de altísima confianza: una contención automática mal calibrada es, en sí misma, una denegación de servicio autoinfligida.

• Activar todos los planes "para estar seguros". Es la vía rápida a una factura de cuatro cifras. Un plan por tipo de recurso y por suscripción, empezando por los datos sensibles.
• Dejar que caduque la prueba de 30 días sin darse cuenta. Empieza a facturar en silencio. Ponlo en el calendario el mismo día que la actives.
• Perseguir el 100 % de puntuación. Prioriza gravedad alta e impacto real; el resto es marcador.
• Exceptuar sin justificación ni caducidad. Es ignorar el problema con mejor presentación. Justifica por escrito y revisa al vencer.
• Aplicar corrección rápida en producción sin pensar. Algunas correcciones cambian la red o el acceso y pueden cortar el servicio. Pruébalas en desarrollo.
• Confundir el panel de cumplimiento con una certificación. Solo mide controles técnicos automatizables.
• No conectar Defender a Log Analytics. Sin eso no hay correlación, ni historial, ni consultas.
• Consejo: revisa la puntuación y las recomendaciones nuevas en una reunión fija mensual de 30 minutos. La postura de seguridad se degrada sola si nadie la mira.
• Consejo: activa siempre el nivel gratuito en todas las suscripciones, incluidas las de desarrollo y las de pruebas. No cuesta nada y ahí es donde aparecen los descuidos.

Contoso Millas (centro-coste=CC-2077) tiene 400 €/mes para seguridad. Su suscripción contiene: 6 máquinas virtuales, 1 base de datos SQL con datos personales, 2 cuentas de almacenamiento con 30 millones de transacciones al mes, 1 Key Vault y 1 App Service público.

1. Estima el coste de activar todos los planes y compáralo con el presupuesto.
2. Propón una selección justificada que quepa en 400 € e indica qué queda descubierto.
3. ¿Qué activarías gratis en cualquier caso y por qué?

Defender saca cuatro recomendaciones sobre Contoso Reservas: (a) puertos de gestión abiertos en dos VM de desarrollo; (b) transferencia segura deshabilitada en una cuenta de almacenamiento; (c) DDoS Standard no habilitado; (d) registros de diagnóstico deshabilitados en 14 recursos.

1. Indica para cada una si corresponde corregir, exceptuar o denegar, y con qué mecanismo.
2. ¿Cuál resolverías con Azure Policy en lugar de una a una, y por qué?
3. ¿Qué información escribirías en la exención que propongas?

Llega una alerta de gravedad Alta: "Se detectó una operación de extracción masiva de blobs" sobre sttarjetascontosopro, con la identidad app-contoso-reservas-pro como origen, 40.000 blobs descargados en 12 minutos, desde una IP de un proveedor de nube ajeno, a las 04:30.

1. Enumera las tres primeras comprobaciones que harías y qué buscarías en cada una.
2. ¿Qué medidas de contención aplicarías, en qué orden y con qué riesgo?
3. Sabiendo lo que se hizo en 04-02 y 04-03, ¿qué hipótesis de causa raíz manejarías?

Solución 1:

1. Servidores: 6 × 14 = 84 €. SQL: 13 €. Storage: 30 millones de transacciones ≈ 390 €. Key Vault: unos pocos euros. App Service: 13 €. Total aproximado: 500-510 €/mes, un 25 % por encima del presupuesto.
2. Prioridad por dato sensible y exposición: SQL (13 €), App Service (13 €, es lo público), Key Vault (unos 2 €) y Servidores (84 €) suman unos 112 €. Con el resto se puede cubrir Storage parcialmente si se separan las cuentas y solo se protege la que contiene datos personales; si las 30 millones de transacciones son de la cuenta sensible, hay que decidir entre cubrirla (390 €, total ~500 €, fuera de presupuesto) o dejarla con el CSPM gratuito. Queda descubierta la detección de malware y de exfiltración en almacenamiento, riesgo que debe documentarse y aceptarse formalmente.
3. El CSPM básico gratuito en todas las suscripciones, incluidas las de desarrollo, y el envío de registros a Log Analytics. Cuesta cero, detecta configuraciones incorrectas y es precisamente en desarrollo donde aparecen los puertos abiertos y los accesos públicos olvidados.

Solución 2:

1. (a) Corregir: cerrar los NSG y usar Bastion; en desarrollo es tentador exceptuar, pero un puerto 22 abierto a internet es de los vectores más explotados que existen. (b) Corrección rápida inmediata: es un clic, no rompe nada y es requisito de PCI DSS. (c) Exención documentada con caducidad anual, remitiendo a la decisión de coste de 04-04. (d) Corregir con Azure Policy, no manualmente.
2. La (d). Catorce recursos hoy, y mañana veinte: una política DeployIfNotExists los configura y, sobre todo, configura también los futuros, que es lo que la corrección manual nunca consigue. Es exactamente el caso de uso de 04-06.
3. En la exención de (c): recurso o ámbito afectado, categoría "riesgo aceptado", justificación (el tráfico entra por fd-contoso-global, que ya absorbe volumétricos en el borde; el coste de Network Protection es de ~32.000 €/año frente al riesgo residual estimado), quién la aprueba (responsable de seguridad y dirección financiera), fecha de caducidad a doce meses y condición de revisión anticipada (publicar una IP pública crítica propia).

Solución 3:

1. (a) La auditoría del almacenamiento en Log Analytics: qué blobs concretos, con qué patrón y con qué token; se busca si el token procede de la identidad administrada o de una SAS o clave antigua. (b) El comportamiento normal de la aplicación: 40.000 descargas en 12 minutos a las 04:30 no encaja con emisión de tarjetas de embarque, que sigue el horario de vuelos. (c) El origen: una IP de otro proveedor de nube es incompatible con el hecho de que la aplicación se ejecuta en App Service en West Europe.
2. Orden: primero revocar el acceso de la identidad implicada (retirar la asignación de rol sobre el contenedor) y comprobar que --allow-shared-key-access sigue en false; después bloquear la IP en el firewall de la cuenta y en el WAF; después rotar cualquier credencial relacionada en kv-contoso-pro. Riesgo: retirar el rol deja la aplicación sin poder emitir tarjetas de embarque, así que hay que avisar a operaciones antes; la alternativa menos disruptiva es restringir primero la red y observar si el acceso cesa.
3. Hipótesis por orden de probabilidad: (a) una SAS o clave de cuenta antigua emitida en el módulo 2 que sigue siendo válida —comprobable al instante, ya que se desactivó el acceso por clave compartida en 04-02; si de verdad está en false, esta hipótesis cae—; (b) un token robado de la identidad administrada, exfiltrado desde el proceso de la aplicación, lo que implicaría compromiso del código o de una dependencia; (c) una entidad de servicio de despliegue con permisos excesivos cuyo secreto se filtró en el repositorio, que es justo lo que Key Vault e identidades administradas venían a eliminar y que confirmaría que quedó algún resto sin migrar.

Contoso ha pasado del control puntual a la postura continua. Distingues las dos mitades de Defender for Cloud: el CSPM, que evalúa sin descanso si la configuración es correcta y produce recomendaciones, y el CWPP, que detecta en tiempo de ejecución y produce alertas. Sabes que el CSPM básico es gratuito y hay que activarlo en todas las suscripciones hoy mismo, y que los planes de pago se eligen por suscripción y por plan porque activarlos todos supera fácilmente los 1.000 € al mes. Entiendes cómo se calcula la puntuación de seguridad y, más importante, cómo se usa: para priorizar por impacto, medir tendencia y comunicar a dirección, nunca para perseguir el 100 %.

Has activado los planes de SQL, Storage y Key Vault en producción, has enviado todo a Log Analytics en rg-contoso-seguridad-pro y has recorrido las diez primeras recomendaciones viendo el patrón real del trabajo de seguridad: dos ya estaban cumplidas por lecciones anteriores, una se resuelve con corrección rápida, otra pide una política en lugar de arreglar recurso a recurso, y dos acaban en exención con justificación y caducidad. Sabes cómo se genera una alerta, has investigado paso a paso un acceso anómalo a db-reservas —contexto, correlación, alcance, contención, erradicación y documentación, con el plazo del RGPD encima— y conoces la ruta de ataque que encadena configuraciones inocuas por separado y Microsoft Sentinel como escalón siguiente cuando exista un equipo que atienda los incidentes. Cierran la lección el cumplimiento normativo con PCI DSS aplicable a Contoso por procesar pagos —y la advertencia de que el panel no es una certificación—, la cobertura de AWS, Google Cloud y servidores locales con Azure Arc, y la automatización con Logic Apps para que ninguna alerta grave se quede en un correo sin leer.

Queda una grieta, y es la que ha aparecido dos veces en esta lección. Defender detecta después: dice que hay catorce recursos sin diagnóstico, que una VM tiene el puerto abierto o que una cuenta permite acceso público, pero todo eso ya se creó, ya estuvo expuesto y alguien tuvo que ir a arreglarlo. Lo que falta es impedir que llegue a existir. En la última lección del módulo, Gobernanza y cumplimiento con Azure Policy, verás la diferencia esencial entre RBAC —quién puede hacer algo— y Policy —qué se puede hacer—, escribirás definiciones con sus efectos, montarás el conjunto de políticas de Contoso (regiones permitidas, etiquetas obligatorias, prohibición de acceso público, TLS mínimo, tamaños de VM y despliegue automático de diagnóstico) y corregirás lo que ya existe con tareas de corrección, todo sobre una jerarquía de grupos de administración.