Guía - AZ-500 Microsoft Azure Security Engineer Associate

Proporcionar acceso just-in-time (JIT) a roles privilegiados de Azure AD, que requieren aprobación y justificación.

Configurar Microsoft Entra Privileged Identity Management (PIM) para el rol. Establecer "Requerir aprobación para activar", especificar aprobadores, habilitar "Requerir justificación en la activación" y establecer una duración máxima de activación.

Por qué: PIM es el servicio nativo de Azure para la elevación de roles JIT. Simplemente hacer que un usuario sea elegible no es suficiente; la configuración de la política aplica el flujo de trabajo de aprobación y justificación.

Referencia

Exigir MFA y un dispositivo compatible para todos los usuarios que acceden a aplicaciones sensibles, pero eximir a un grupo específico de la mesa de ayuda de la regla de cumplimiento de dispositivos.

Crear dos políticas de Conditional Access (CA). La Política 1 se dirige a "Todos los usuarios" excluyendo al grupo de mesa de ayuda, requiriendo MFA y un dispositivo compatible. La Política 2 se dirige solo al grupo de mesa de ayuda, requiriendo solo MFA.

Por qué: Una sola política con una exclusión eliminaría todos los requisitos para el grupo excluido. Dos políticas dirigidas garantizan que cada grupo obtenga el conjunto de controles correcto y distinto.

Referencia

Responder automáticamente a los riesgos de identidad detectados: bloquear inicios de sesión de alto riesgo y forzar el restablecimiento de contraseñas para usuarios de alto riesgo.

Configurar dos políticas de Microsoft Entra ID Protection. Establecer la "política de riesgo de inicio de sesión" para Bloquear el acceso a un nivel de riesgo Alto. Establecer la "política de riesgo de usuario" para Requerir cambio de contraseña a un nivel de riesgo Alto.

Por qué: El riesgo de inicio de sesión se refiere a un único intento de autenticación (en tiempo real), mientras que el riesgo de usuario es una puntuación acumulativa sobre la identidad misma (credenciales comprometidas). Requieren diferentes acciones de remediación.

Permitir a los usuarios en un entorno de identidad híbrido restablecer su contraseña en la nube y que esta se sincronice de vuelta con Active Directory local.

En Microsoft Entra Connect, habilitar la característica "Reescritura de contraseña". En Azure AD, habilitar y configurar el Restablecimiento de contraseña de autoservicio (SSPR) para los usuarios objetivo.

Por qué: SSPR proporciona la interfaz de usuario del lado de la nube para el restablecimiento de contraseña, mientras que la Reescritura de Contraseña es el componente en Entra Connect que sincroniza el nuevo hash de contraseña de vuelta al AD local.

Revisar periódicamente todo el acceso de usuarios invitados y eliminar automáticamente a los invitados que ya no están aprobados o están inactivos.

Crear una Revisión de Acceso en Microsoft Entra ID Governance. Dirigirse a usuarios invitados en todos los grupos, establecer un programa recurrente (por ejemplo, trimestral) y habilitar "Aplicar resultados automáticamente al recurso". Opcionalmente, revisar usuarios inactivos.

Por qué: Las Revisiones de Acceso son la herramienta de gobierno dedicada para la recertificación periódica del acceso. La función "Aplicar resultados automáticamente" es crítica para cerrar el ciclo y automatizar la eliminación.

Proporcionar a los socios externos una forma de autoservicio para solicitar un paquete de acceso (grupos, aplicaciones, sitios de SharePoint) que expire automáticamente después de 90 días.

Usar Microsoft Entra Entitlement Management. Crear una Connected Organization para el socio. Crear un Access Package que contenga los recursos. Definir una política para el paquete que permita a los usuarios de la organización conectada solicitarlo, con una caducidad de 90 días.

Por qué: Entitlement Management está diseñado para gobernar el acceso a escala, especialmente para usuarios externos. Agrupa recursos y automatiza todo el ciclo de vida del acceso, desde la solicitud y aprobación hasta la caducidad y eliminación.

Una aplicación de alta seguridad requiere que los usuarios se autentiquen con un método resistente a ataques de phishing y man-in-the-middle.

Aplicar métodos de autenticación como claves de seguridad FIDO2 o Windows Hello for Business. Estos métodos utilizan criptografía de clave pública y están vinculados al dispositivo, evitando el robo de credenciales.

Por qué: Métodos como SMS, llamadas de voz o simples notificaciones push son vulnerables a phishing. FIDO2 y WHfB utilizan desafíos criptográficos vinculados al origen de la solicitud, haciéndolos resistentes al phishing.

Un servicio en segundo plano ejecutándose en una VM necesita leer todos los perfiles de usuario de Microsoft Graph sin ninguna interacción del usuario.

Registrar la aplicación en Microsoft Entra ID. En permisos de API, otorgarle permisos de "Aplicación" de Microsoft Graph (no "Delegados") para `User.Read.All`. Un administrador debe otorgar el consentimiento de administrador.

Por qué: Los permisos de aplicación permiten que la aplicación actúe como ella misma, utilizando su propia identidad (ID de cliente/secreto o certificado). Los permisos delegados requieren un contexto de usuario con sesión iniciada, que no está disponible en una aplicación demonio no interactiva.

Permitir que un pod en un clúster de AKS acceda de forma segura a Azure Key Vault sin usar credenciales almacenadas como secretos de cliente o certificados.

Usar Azure AD Workload Identity. Crear una identidad administrada asignada por el usuario, establecer una credencial de identidad federada entre la cuenta de servicio de K8s y la identidad administrada, y otorgar a la identidad administrada acceso a Key Vault.

Por qué: Workload Identity utiliza la federación OIDC para intercambiar un token de Kubernetes por un token de Azure AD, eliminando completamente la necesidad de almacenar, gestionar o rotar secretos en el clúster.

Referencia

Proteger un Azure Key Vault para permitir solo el acceso desde VNets específicas, registrar todas las operaciones y proteger contra la eliminación accidental de claves críticas.

Configurar el firewall de Key Vault para permitir el acceso desde "Punto de conexión privado y redes seleccionadas". Habilitar el registro de diagnóstico a un espacio de trabajo de Log Analytics. Habilitar tanto Soft Delete como Purge Protection.

Por qué: Soft Delete permite la recuperación de eliminaciones accidentales, pero Purge Protection impide que incluso un usuario privilegiado elimine permanentemente el almacén o su contenido durante el período de retención. Esta combinación es crítica para proteger las claves TDE.

Un Azure App Service necesita autenticarse en Azure SQL Database para recuperar datos, sin almacenar contraseñas de cadenas de conexión en la configuración.

Habilitar una identidad administrada asignada por el sistema en el App Service. En Azure SQL, crear un usuario contenido mapeado al nombre de la identidad administrada del App Service y otorgarle los roles de base de datos necesarios (por ejemplo, db_datareader).

Por qué: Managed Identity proporciona una identidad para el propio recurso de Azure en Azure AD. Azure gestiona la creación y rotación de credenciales automáticamente, eliminando los secretos almacenados, lo cual es una práctica de seguridad fundamental.

Cifrar discos administrados de máquinas virtuales de Azure en reposo utilizando una clave que su organización controla en Azure Key Vault.

Crear un recurso de Disk Encryption Set. Configurarlo para usar una clave administrada por el cliente (CMK) de su Azure Key Vault. Asignar el Disk Encryption Set a los discos administrados de la máquina virtual.

Por qué: Esto es Server-Side Encryption (SSE) con CMK, que cifra los datos en la infraestructura de almacenamiento. Es más simple que Azure Disk Encryption (ADE), que utiliza BitLocker/dm-crypt para cifrar datos dentro del sistema operativo invitado y generalmente se usa para discos de sistema operativo y datos juntos.

Asegurar que las imágenes de contenedor almacenadas en Azure Container Registry (ACR) sean escaneadas en busca de vulnerabilidades antes de ser desplegadas.

Habilitar Microsoft Defender for Containers. Esto escaneará automáticamente las imágenes en ACR cuando se suban, cuando se extraigan y de forma continua en busca de vulnerabilidades recién descubiertas.

Por qué: Esta práctica de seguridad de "shift-left" identifica vulnerabilidades temprano en el pipeline de CI/CD. Defender for Containers proporciona esta capacidad de escaneo de forma nativa dentro del ecosistema de Azure.

Detectar y recibir alertas por posibles ataques de inyección SQL y patrones de acceso anómalos en una Azure SQL Database.

Habilitar Microsoft Defender for SQL en el servidor SQL lógico. Esto proporciona protección avanzada contra amenazas y evaluación de vulnerabilidades.

Por qué: Defender for SQL es el plan de protección de cargas de trabajo dedicado que utiliza análisis de comportamiento y aprendizaje automático para detectar amenazas como inyección SQL, ataques de fuerza bruta y acceso inusual a datos, que no son visibles para las herramientas a nivel de red.

Restringir una cuenta de almacenamiento a una VNet específica, pero seguir permitiendo que servicios de Microsoft de confianza como Azure Backup accedan a ella.

En la configuración de red de la cuenta de almacenamiento, seleccionar "Habilitado desde redes virtuales y direcciones IP seleccionadas". Añadir la VNet/subred requerida. Luego, marcar la casilla "Permitir que los servicios de Microsoft de confianza accedan a esta cuenta de almacenamiento".

Por qué: La excepción de servicios de confianza crea una ruta segura para que servicios específicos de Microsoft omitan las reglas del firewall de VNet. Sin ella, los servicios que operan en nombre del usuario (como Backup o Portal) serían bloqueados.

Proteger columnas de datos sensibles específicas (por ejemplo, números de tarjetas de crédito) en una base de datos de Azure SQL, incluso de administradores de bases de datos (DBAs) privilegiados.

Usar Always Encrypted. El controlador de la aplicación cliente cifra transparentemente los datos antes de enviarlos a la base de datos, y las claves de cifrado nunca se revelan al motor de la base de datos.

Por qué: Transparent Data Encryption (TDE) cifra toda la base de datos en reposo (en disco), pero un DBA con acceso aún puede ver los datos. Always Encrypted proporciona cifrado del lado del cliente, separando a quienes gestionan los datos (DBAs) de quienes pueden verlos.

Procesar datos altamente sensibles en una VM de Azure, asegurando que permanezcan cifrados y protegidos incluso en memoria del hipervisor y los operadores de la nube.

Desplegar una Azure Confidential VM. Estas VMs utilizan Entornos de Ejecución Confiables (TEEs) basados en hardware como AMD SEV-SNP para crear un espacio de memoria aislado y cifrado.

Por qué: El cifrado estándar de VM (como ADE o SSE) protege los datos en reposo. Confidential Computing es la única tecnología que protege los datos *mientras están en uso* en memoria, proporcionando el más alto nivel de privacidad y aislamiento de datos en la nube.

Un App Service necesita usar un secreto de Key Vault como configuración de aplicación, sin cambiar el código de la aplicación para usar el SDK de Key Vault.

Habilitar la identidad administrada en el App Service y otorgarle permisos "Get" sobre los secretos en Key Vault. En la configuración del App Service, crear una configuración de aplicación con el valor formateado como una referencia de Key Vault: `@Microsoft.KeyVault(SecretUri=...)`.

Por qué: Esta característica permite que la plataforma de App Service resuelva el valor del secreto en tiempo de ejecución utilizando la identidad administrada. El código de la aplicación simplemente lee una variable de entorno estándar, abstraendo la interacción con Key Vault.

Almacenar datos relacionados con el cumplimiento en Azure Blob Storage en un estado WORM (Write-Once, Read-Many) durante un período de retención de 7 años.

En el contenedor de almacenamiento, configurar una política de inmutabilidad. Usar una política de retención basada en el tiempo establecida en 7 años y bloquear la política. Una vez bloqueada, los datos no pueden ser modificados o eliminados por nadie hasta que expire el período de retención.

Por qué: Esta característica está específicamente diseñada para cumplir con los requisitos de cumplimiento normativo (por ejemplo, SEC 17a-4). Bloquear la política es el paso crítico que la hace verdaderamente inmutable.

En una aplicación multi-inquilino que utiliza una única base de datos Azure SQL, asegurar que los usuarios de un inquilino solo puedan ver los datos pertenecientes a su propio inquilino.

Implementar Row-Level Security (RLS). Crear una política de seguridad con una función de predicado que filtre filas basándose en el ID de inquilino del usuario, que se almacena en el contexto de la sesión o en una tabla de búsqueda de usuarios.

Por qué: RLS aplica la lógica de acceso directamente dentro del motor de la base de datos. Esto es más seguro y fiable que implementar el filtrado en la capa de aplicación, ya que no se puede eludir y es transparente para el código de la aplicación.

Proteger máquinas virtuales de Generación 2 contra boot kits y rootkits asegurando la integridad de toda la cadena de arranque desde UEFI hasta el kernel del sistema operativo.

Aprovisionar la VM con Trusted Launch habilitado. Esto activa Secure Boot, que valida la firma de todos los componentes de arranque, y un Módulo de Plataforma Confiable virtual (vTPM) para arranque medido y atestación.

Por qué: Trusted Launch aborda malware sofisticado de bajo nivel que puede subvertir los controles de seguridad tradicionales a nivel del sistema operativo. Establece una raíz de confianza de hardware para la VM.

Aislar el tráfico entre las capas de la aplicación (web, aplicación, datos) alojadas en subredes separadas.

Crear un Network Security Group (NSG) dedicado para cada subred. En cada NSG, crear reglas de entrada que solo permitan el tráfico desde el rango IP de origen de la capa precedente en el puerto requerido. (por ejemplo, el NSG de la capa de aplicación permite TCP/8080 desde la subred de la capa web).

Por qué: Aplicar un NSG único y de mínimo privilegio a cada subred proporciona defensa en profundidad y control granular sobre los flujos de tráfico este-oeste, lo cual es más seguro que un único y complejo NSG para la VNet.

En una topología hub-spoke, forzar que todo el tráfico entre VNets spoke sea inspeccionado por un NVA o Azure Firewall en el hub.

En cada subred spoke, crear una Ruta Definida por el Usuario (UDR) para los espacios de direcciones de las otras spokes con el tipo de siguiente salto establecido en "VirtualAppliance" y la IP del NVA/Firewall. Habilitar el reenvío de IP en la NIC del NVA.

Por qué: Por defecto, el emparejamiento de VNet permite que las spokes se comuniquen directamente. Las UDRs anulan este comportamiento de enrutamiento predeterminado, forzando el tráfico al punto de inspección central.

Proporcionar un servicio PaaS (por ejemplo, Azure SQL, Storage) con una dirección IP privada dentro de su VNet, asegurando que el tráfico nunca atraviese la internet pública.

Crear un Private Endpoint para el servicio PaaS en su VNet. Fundamentalmente, en la configuración de red del servicio PaaS, deshabilitar el acceso a la red pública para bloquear el endpoint público.

Por qué: Un Private Endpoint lleva el servicio *dentro* de su VNet con una IP privada. Un Service Endpoint simplemente optimiza la ruta a través de la red troncal de Azure a una IP pública. Deshabilitar el acceso público es necesario para forzar la comunicación solo privada.

Permitir el tráfico saliente desde máquinas virtuales a un conjunto dinámico de endpoints de servicios de Microsoft, como Windows Update, sin mantener manualmente listas de IP.

En Azure Firewall, crear una colección de Application Rule. Añadir una regla con el tipo de FQDN objetivo establecido en "Etiqueta FQDN" y seleccionar la etiqueta "WindowsUpdate".

Por qué: Las FQDN Tags son colecciones curadas de FQDNs que Microsoft gestiona. Esta es la forma correcta de permitir el acceso a servicios PaaS cuyas IPs subyacentes cambian con frecuencia. Las Service Tags son para reglas basadas en IP.

Un Web Application Firewall (WAF) está bloqueando el tráfico legítimo a su aplicación debido a un falso positivo en una regla administrada (por ejemplo, inyección SQL).

En la política de WAF, mantener el WAF en modo Prevención. Encontrar la regla administrada que está bloqueando el tráfico y configurar una exclusión para el encabezado de solicitud, cookie o parámetro de cuerpo específico que está causando el falso positivo.

Por qué: Las exclusiones son la forma más precisa de manejar falsos positivos. Permiten mantener la protección de la regla para todo el demás tráfico mientras se hace una excepción específica, lo cual es más seguro que deshabilitar la regla completa.

Proporcionar acceso seguro RDP/SSH a máquinas virtuales de Azure sin exponer los puertos de administración a internet ni requerir IPs públicas en las máquinas virtuales.

Desplegar Azure Bastion (SKU Estándar para características avanzadas) en una subred dedicada en la VNet. Acceder a las máquinas virtuales a través del portal de Azure, que se conecta a través del servicio Bastion.

Por qué: Bastion actúa como una jump box segura, intermediando la conexión RDP/SSH. La única IP pública está en el propio servicio Bastion, que está endurecido y gestionado por Microsoft, reduciendo drásticamente la superficie de ataque de sus máquinas virtuales.

Proporcionar a los desarrolladores acceso limitado en el tiempo y auditado a los puertos de administración (RDP/SSH) en las máquinas virtuales de desarrollo.

Habilitar Microsoft Defender for Cloud y configurar el acceso Just-in-Time (JIT) a máquinas virtuales. Los usuarios solicitarán acceso a través de Defender for Cloud, que modifica dinámicamente las reglas de NSG para permitir el acceso por un tiempo limitado desde una IP específica.

Por qué: JIT es una característica principal de Defender for Cloud que fortalece la postura de red de las máquinas virtuales manteniendo los puertos de administración cerrados por defecto, abriéndolos solo bajo demanda.

Aplicar las mejores prácticas de seguridad, como no permitir contenedores privilegiados, en un clúster de Azure Kubernetes Service (AKS) en el momento del despliegue.

Habilitar el complemento de Azure Policy para AKS. Asignar la iniciativa de política incorporada denominada "Estándares restringidos de seguridad de pods de clúster de Kubernetes para cargas de trabajo basadas en Linux".

Por qué: Esto aprovecha Azure Policy como un controlador de admisión centralizado y a escala para Kubernetes, aplicando barandillas de seguridad y cumplimiento antes de que las cargas de trabajo sean creadas en el clúster.

Enrutar todo el tráfico con destino a internet desde una VNet de Azure de vuelta a un dispositivo de seguridad local para su inspección antes de que llegue a internet.

Configurar una VPN sitio a sitio o ExpressRoute. Crear una User Defined Route (UDR) para el prefijo de dirección 0.0.0.0/0, y establecer el siguiente salto como el Virtual Network Gateway.

Por qué: Este patrón, conocido como tunelización forzada, anula la ruta predeterminada de Azure a internet y fuerza todo el tráfico saliente a través de la puerta de enlace a la red local, asegurando que ninguna VM pueda eludir los controles de seguridad corporativos.

Inspeccionar el tráfico saliente cifrado con TLS desde VMs en busca de amenazas usando Azure Firewall.

Desplegar Azure Firewall Premium. Habilitar la Inspección TLS y la Detección de Intrusiones (IDPS). Configurar un certificado de CA subordinado en el Firewall y desplegar su clave pública en las VMs cliente como una CA raíz de confianza.

Por qué: Para inspeccionar el tráfico cifrado, el firewall debe realizar una operación de man-in-the-middle. Esto requiere la SKU Premium, IDPS para la detección de amenazas y una infraestructura de certificados adecuada para evitar errores TLS en las máquinas cliente.

Proteger todas las aplicaciones de cara al público en múltiples VNets y suscripciones de ataques DDoS volumétricos de una manera rentable.

Crear un único Plan de Protección Azure DDoS. Asociar este único plan a todas las redes virtuales que contengan direcciones IP públicas que necesiten protección.

Por qué: Un único Plan de Protección DDoS puede cubrir hasta 100 VNets, y se paga una tarifa mensual fija por el plan, no por VNet o por IP. Este modelo centralizado es mucho más rentable que desplegar múltiples planes o usar la SKU de protección por IP.

Cuando se crea un incidente de alta gravedad en Microsoft Sentinel, deshabilitar automáticamente la cuenta de usuario involucrada en Azure AD y notificar al equipo de seguridad en Teams.

Crear una Automation Rule que se active al crear un incidente de alta gravedad. La regla debe llamar a un Playbook (Logic App). El playbook utiliza el conector de Azure AD para deshabilitar al usuario y el conector de Teams para publicar un mensaje.

Por qué: Esto demuestra el patrón SOAR (Security Orchestration, Automation, and Response). La Automation Rule es el motor de disparo/condición, y el Playbook es el motor de acción/flujo de trabajo.

Referencia

Aplicar un conjunto consistente de políticas de seguridad y habilitar planes de Defender for Cloud en un gran número de suscripciones de Azure.

Organizar todas las suscripciones bajo un Management Group. Asignar la iniciativa de política Azure Security Benchmark y habilitar los planes de Defender for Cloud requeridos a nivel del grupo de administración.

Por qué: Los Management Groups son la herramienta principal para la gobernanza a escala empresarial. Las políticas y configuraciones aplicadas a este nivel son heredadas por todas las suscripciones secundarias, asegurando la coherencia y reduciendo la sobrecarga administrativa.

Crear una detección personalizada en Sentinel para un usuario que inicia sesión desde un nuevo país por primera vez.

Crear una regla de análisis de consulta programada. Usar una consulta KQL que una `SigninLogs` recientes con un historial resumido de `SigninLogs` pasados para identificar combinaciones de UserPrincipalName/País no vistas anteriormente.

Por qué: Las reglas de consulta programadas con KQL son la base de la detección de amenazas personalizada en Sentinel, permitiendo una lógica compleja y con estado que va más allá de la simple coincidencia de eventos.

Retener registros de seguridad en Sentinel durante 2 años por cumplimiento, pero mantener solo los últimos 90 días disponibles para consultas rápidas e interactivas para gestionar costos.

En el espacio de trabajo de Log Analytics, establecer la "Retención Interactiva" en 90 días. Establecer la "Retención Total" (Archivo) en 730 días (2 años). Configurar políticas de retención por tabla si es necesario.

Por qué: Este enfoque por niveles equilibra el costo y la capacidad. El nivel interactivo es costoso pero rápido. El nivel de archivo es de muy bajo costo para el almacenamiento a largo plazo. Los datos archivados aún se pueden consultar a través de Search Jobs asíncronos o restaurarse temporalmente.

Durante una investigación de incidentes, necesita visualizar rápidamente las relaciones entre un usuario comprometido, la IP desde la que inició sesión y los recursos a los que accedió.

Desde la página de incidentes en Microsoft Sentinel, abrir el Grafo de Investigación. Usar el grafo para explorar visualmente entidades y sus conexiones a través de diferentes alertas y fuentes de registro.

Por qué: El Grafo de Investigación es una potente herramienta de visualización que traza la historia del ataque, facilitando mucho la comprensión del alcance y la línea de tiempo de un incidente que correlacionando manualmente eventos en consultas de registro.

Detectar a un atacante que ha comprometido una cuenta de usuario y ahora está intentando acceder a recursos o hosts inusuales dentro de la red.

Asegurar que User and Entity Behavior Analytics (UEBA) esté habilitado en Microsoft Sentinel y que las fuentes de datos relevantes (registros de Azure AD, Defender for Endpoint/Eventos de seguridad) estén conectadas. Monitorear UEBA para detecciones de anomalías relacionadas con el movimiento lateral.

Por qué: UEBA construye una línea base del comportamiento normal para cada usuario y entidad. Destaca en la detección de desviaciones que indican movimiento lateral, como un usuario que accede a un servidor por primera vez o que utiliza protocolos inusuales, que son difíciles de detectar con reglas estáticas.

Reducir los costos de ingesta de Microsoft Sentinel para registros voluminosos y detallados que son necesarios para el cumplimiento pero no para el análisis en tiempo real.

Configurar el plan de tabla para estos registros a "Registros Básicos". Además, usar Data Collection Rules (DCRs) con consultas XPath u otras transformaciones para filtrar eventos ruidosos y de bajo valor antes de la ingesta.

Por qué: Los Registros Básicos ofrecen un costo de ingesta significativamente menor a cambio de capacidades de consulta limitadas y una retención más corta. Filtrar en el origen con DCRs es la forma más efectiva de reducir el volumen al evitar que datos no deseados lleguen al espacio de trabajo.

Aplicar automáticamente una configuración de seguridad, como habilitar "Transferencia segura requerida" en todas las cuentas de Azure Storage existentes y nuevas.

Asignar una Azure Policy con el efecto `DeployIfNotExists` o `Modify`. Para los recursos existentes no conformes, crear una tarea de remediación desde el panel de cumplimiento de la política para aplicar el cambio.

Por qué: Las políticas de Auditoría y Denegación solo informan o bloquean el incumplimiento. `DeployIfNotExists` y `Modify` con tareas de remediación corrigen activamente las configuraciones erróneas, haciendo de la política una herramienta poderosa para la gobernanza automatizada y el endurecimiento de la seguridad.

Detectar amenazas en tiempo de ejecución en un clúster de AKS, como la ejecución de procesos sospechosos o un contenedor que se conecta a una IP maliciosa conocida.

Habilitar Microsoft Defender for Containers. Esto despliega un DaemonSet (agente de Defender) en cada nodo del clúster, que recolecta señales de seguridad del host y los contenedores para proporcionar detección de amenazas en tiempo real.

Por qué: Mientras que el escaneo de ACR proporciona seguridad "shift-left", la protección en tiempo de ejecución es crucial para detectar amenazas que ocurren después del despliegue. Defender for Containers proporciona esta visibilidad a nivel de host y carga de trabajo dentro del clúster.