Microsoft AZ-801: Microsoft Sentinel y monitoreo de seguridad — Guía de estudio

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Forma parte de la Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Información general

Microsoft Sentinel es un SIEM y SOAR nativo de la nube que unifica la ingesta de registros, el análisis, la detección de amenazas, la respuesta a incidentes y la búsqueda proactiva de amenazas (proactive hunting) en entornos híbridos de Windows Server. Para los escenarios del AZ-801, el dominio de la materia implica conectar a escala orígenes de Windows Security Events, Syslog de Linux y CEF de terceros, diseñar análisis con una latencia mínima, mapear alertas a entidades para una investigación precisa y automatizar la contención mediante playbooks basados en Logic Apps. El éxito también depende de una arquitectura disciplinada del área de trabajo de Log Analytics, reglas de recopilación de datos (DCR) bien gobernadas para el Azure Monitor Agent (AMA), una estrategia de retención sólida y competencia operativa en UEBA, watchlists, hunting y workbooks.

Conectores e ingesta de datos

Los Windows Security Events a través de AMA son el origen canónico para los eventos de inicio de sesión, creación de procesos, cambio de directivas y otros eventos de auditoría de Windows Server. Habilite el conector “Windows Security Events via AMA” en Microsoft Sentinel y cree una DCR que seleccione los conjuntos de eventos apropiados para su perfil de riesgo (Mínimo, Común o Todos, o una selección personalizada por ID de evento). Los datos se almacenan principalmente en la tabla SecurityEvent; los canales de Windows que no son de seguridad (si están habilitados) se almacenan en la tabla WindowsEvent. Combine esto con Group Policy para asegurar que la línea de base de seguridad y las subcategorías de auditoría (p. ej., Logon/Logoff, Account Logon, Object Access, DS Access) estén habilitadas en los servidores de origen para generar la telemetría necesaria.

Syslog a través de AMA recopila datos de servidores Linux y dispositivos de red que utilizan Syslog. Instale AMA en los hosts de Linux (o en un recopilador de Linux dedicado) y configure una DCR para especificar las facilities y los niveles de gravedad (severities) que se van a ingerir. Los eventos se escriben en la tabla Syslog. Para las facilities de gran volumen pero de bajo valor, considere la recopilación selectiva o la transformación en el origen para controlar el costo y el ruido.

CEF a través de AMA permite la ingesta de registros de seguridad normalizados de productos de seguridad de terceros (firewalls, IDS/IPS, proxies, EDR). Despliegue AMA en un recopilador de Linux y configure a sus proveedores para que reenvíen CEF al demonio de syslog local (rsyslog/syslog-ng) en los puertos, normalmente 514/UDP o TCP. En Sentinel, habilite el conector de datos “CEF via AMA” y vincule el host mediante una DCR que analice (parse) los datos CEF. Los datos analizados ingresan en la tabla CommonSecurityLog con un esquema coherente (campos deviceVendor, deviceProduct, destination/source y atributos de extensión), lo que simplifica el análisis y la correlación entre proveedores.

Para los servidores Windows Server locales (on-premises), utilice servidores habilitados para Azure Arc para conectarse con Azure. Incorpore las máquinas con el agente de Azure Connected Machine y luego despliegue la extensión AMA a través de Azure Policy para escalar. Cree DCRs dirigidas a ámbitos de servidores de Arc para enrutar los Windows Security Events, los registros de Windows Firewall y, si utiliza Sysmon, una DCR personalizada para el canal Microsoft-Windows-Sysmon/Operational. Este patrón centraliza la configuración, el control de versiones y la segmentación basada en ámbitos, asegurando una ingesta coherente sin trabajo manual en cada host.

Arquitectura del área de trabajo y ciclo de vida de los datos

Sentinel se asocia a una única área de trabajo de Log Analytics por cada despliegue. El diseño del área de trabajo debe minimizar la latencia y el egreso entre regiones, ubicar las áreas de trabajo junto a la mayoría de los productores de datos y evitar una fragmentación excesiva que complique las consultas, la clasificación de incidentes y el RBAC. Los patrones comunes son una única área de trabajo de seguridad por tenant o una por cada región principal donde la residencia de datos y la latencia requieran separación. Utilice el acceso de contexto de recurso siempre que sea posible para garantizar que los equipos puedan consultar los registros de los recursos que poseen sin necesidad de permisos amplios sobre el área de trabajo, mientras que los roles de Sentinel (Lector, Respondedor, Colaborador) gobiernan las operaciones del SOC.

Las DCRs gobiernan qué tipos de telemetría, canales y conjuntos de eventos se recopilan y a dónde se envían. Trate las DCRs como código: estandarice la nomenclatura, los controles de versiones y los ámbitos (suscripciones, grupos de recursos, etiquetas). Agrupe orígenes y destinos relacionados, y prefiera múltiples DCRs específicas en lugar de una regla monolítica para simplificar el radio de impacto (blast radius) y la gestión del ciclo de vida. Cuando los volúmenes de syslog y CEF son altos, considere usar DCRs separadas para ajustar la facility y la severity de forma independiente y para dar soporte a pruebas por etapas.

La retención y el costo se controlan a nivel de tabla. Establezca la retención predeterminada del área de trabajo para cumplir con la política (p. ej., de 90 a 180 días para la búsqueda activa) y luego anule la retención por tabla cuando sea necesario. Las tablas de alto valor (SecurityEvent, CommonSecurityLog, SecurityAlert) suelen retenerse por más tiempo; las tablas detalladas (verbose) (Syslog con DEBUG) pueden retenerse por menos tiempo. Utilice el archivo para el almacenamiento a largo plazo y de bajo costo con trabajos de búsqueda (search jobs); promueva los datos a almacenamiento en caliente (hot) según sea necesario para las investigaciones. Cuando sea apropiado, mueva algunas tablas detalladas (como Syslog) a Registros Básicos (Basic Logs) para reducir el costo, reconociendo las limitaciones de consulta y que ciertas tablas de seguridad (p. ej., SecurityEvent) no son elegibles para el nivel Básico. Revise regularmente los límites de datos, los niveles de compromiso (commitment tiers) y las tendencias de ingesta para evitar la limitación (throttling) y optimizar los costos.

Análisis, Incidentes y Automatización de la Respuesta

Las reglas de análisis son el motor de la detección. Las reglas de consulta programada (scheduled query rules) ejecutan KQL según una programación (p. ej., cada 5 minutos) sobre un período de retrospectiva (lookback period) (p. ej., 30 minutos), y admiten agregaciones, combinaciones (joins), enriquecimientos con listas de seguimiento (watchlists) y ventanas de supresión. Son ideales para patrones bien conocidos como múltiples inicios de sesión fallidos seguidos de uno exitoso, heurísticas de movimiento lateral o linaje de procesos sospechosos. Las reglas de casi tiempo real (NRT) minimizan la latencia de detección al procesar continuamente datos nuevos, con ejecuciones aproximadamente cada minuto y alertas en unos dos minutos; diseñe las reglas NRT para que sean concisas y se basen en ingestion_time() o en ventanas de tiempo estrechas para evitar escaneos históricos pesados. Las reglas de Fusion utilizan el análisis de ataques multietapa de Microsoft para correlacionar alertas de baja señal entre productos (p. ej., Defender for Endpoint, Defender for Identity, Entra ID Protection, CEF de terceros) y convertirlas en incidentes de alta fidelidad para campañas como el robo de credenciales o el ransomware. Las reglas de anomalías aprovechan plantillas de ML integradas que aprenden líneas base (p. ej., ubicaciones de inicio de sesión inusuales, ejecución de procesos poco comunes) y emiten desviaciones; estas suelen leer desde BehaviorAnalytics y otras fuentes normalizadas.

Los incidentes unifican múltiples alertas, entidades y evidencias bajo un único caso de investigación. La severidad es asignada por la regla de análisis (o dinámicamente por Fusion) y puede ser escalada o reducida mediante reglas de automatización. El mapeo de entidades es fundamental para la eficacia de la investigación: en el asistente de reglas, mapee las columnas de la consulta a los tipos de entidad (Account, Host, IP, URL, File, Process, CloudApplication, AzureResource). Un mapeo adecuado rellena el grafo de investigación, que visualiza las relaciones entre alertas, eventos y entidades, permitiendo pivotar sobre cuentas, hosts, procesos e IPs. Utilice comentarios, etiquetas (tags), propietario (owner) y clasificación para capturar la resolución del analista y para entrenar los flujos de trabajo de ajuste.

La automatización combina reglas de automatización (Automation rules) y Playbooks. Las reglas de automatización evalúan los metadatos del incidente en su creación o actualización para asignar propietarios, cambiar la severidad, añadir etiquetas, cerrar falsos positivos o invocar playbooks. Los Playbooks son Azure Logic Apps construidas con los conectores de Microsoft Sentinel. Los playbooks desencadenados por incidentes (incident-triggered) reaccionan a eventos del ciclo de vida del incidente (p. ej., cuando se crea un incidente) y son adecuados para acciones acotadas al incidente, como notificar a un equipo, enriquecer todas las entidades o crear un ticket en ServiceNow. Los playbooks desencadenados por alertas (alert-triggered) se ejecutan sobre alertas individuales antes de que se agrupen en un incidente, lo que es útil para enriquecimientos específicos del proveedor o para un pre-triaje. Adopte identidades administradas (managed identity) para los playbooks, conceda el mínimo privilegio a través de Azure RBAC y permisos de API, y parametrice los ID de los espacios de trabajo, los endpoints de ticketing y las rutas de las listas de bloqueo para promover la reutilización. Cuando la contención esté justificada, incluya acciones que pongan en cuarentena los endpoints (Defender for Endpoint), deshabiliten cuentas (Entra ID), bloqueen IPs (firewalls) o revoquen sesiones (Conditional Access) solo después de que se cumplan los umbrales de confianza.

Operaciones de seguridad proactivas (caza de amenazas, UEBA, listas de seguimiento, libros de trabajo)

La caza de amenazas (threat hunting) en Sentinel se basa en la pericia con KQL y en el panel de caza. Comience con las consultas de caza integradas, organizadas por táctica; personalícelas para su entorno haciendo referencia a tablas como SecurityEvent (auditoría de Windows), las tablas Device* de Defender, CommonSecurityLog (CEF) y SigninLogs (Entra). Use marcadores (bookmarks) para capturar instantáneas de registros interesantes, anotarlos y compartir contexto con el equipo; se pueden promover varios marcadores a un incidente nuevo o existente. Livestream ejecuta continuamente un patrón de KQL para detectar nuevos eventos que coincidan casi en tiempo real, lo cual es ideal para investigaciones con plazos definidos o escenarios de aumento rápido de actividad. Convierta las consultas de caza maduras en reglas de análisis programadas para operacionalizar las detecciones.

UEBA (Análisis de comportamiento de usuarios y entidades) enriquece la detección con líneas base de comportamiento y puntuación de anomalías. Habilite UEBA desde la configuración de Sentinel y asegúrese de que las fuentes de datos de identidad y actividad (inicios de sesión de Microsoft Entra, Defender for Endpoint, Defender for Identity, actividad de M365) estén conectadas. Las páginas de entidad para usuarios y hosts muestran cronologías, comparaciones con homólogos, actividades anómalas (ubicación geográfica de inicio de sesión inusual, proceso poco común) y puntuaciones de riesgo agregadas. Los analistas pueden pivotar desde los incidentes a las páginas de entidad para evaluar si una acción es típica para esa identidad o dispositivo; las puntuaciones y secuencias de anomalías ayudan a priorizar el triaje y a corroborar o refutar hipótesis rápidamente.

Las listas de seguimiento (watchlists) proporcionan datos de referencia rápidos y mantenidos por analistas. Cree listas de seguimiento a partir de cargas de CSV o de una ruta de cuenta de almacenamiento, defina un alias y seleccione una columna clave para búsquedas eficientes. Use la función

undefined

en KQL para hacer uniones (joins); los usos comunes incluyen listas de permitidos/denegados de cuentas administrativas, hosts sensibles, dominios autorizados o usuarios VIP. Incorpore listas de seguimiento en las reglas de análisis para suprimir la actividad conocida como benigna (reducir falsos positivos) o para elevar la gravedad cuando una coincidencia involucre un activo crítico. Intégrelas con la inteligencia de amenazas uniendo las listas de seguimiento a la tabla

undefined

para obtener contexto (p. ej., enriquecer las IP detectadas con una gravedad interna o notas del caso), o convirtiendo fuentes de inteligencia de amenazas (TI) seleccionadas en una lista de seguimiento para referencia rápida y anulaciones.

Los libros de trabajo (workbooks) potencian la monitorización y la visibilidad para ejecutivos. Comience con plantillas integradas como Eficiencia de las operaciones de seguridad, Inicios de sesión de Active Directory, Detecciones de Fusion e Información de UEBA. Cree libros de trabajo personalizados usando consultas KQL, parámetros y visualizaciones para crear paneles del SOC para el estado de la ingesta, el rendimiento de las reglas, los SLA de incidentes y las amenazas emergentes. Aplique RBAC sobre el recurso del libro de trabajo y parametrice las suscripciones, los espacios de trabajo y los rangos de tiempo para que el mismo libro de trabajo pueda servir a diferentes equipos. Combine mosaicos de múltiples tablas para correlacionar la postura (Defender for Cloud), las detecciones (Sentinel) y las métricas de respuesta en una sola vista.

Escenario de problema práctico

Spotify debe centralizar la monitorización de seguridad para 2000 servidores Windows distribuidos entre Azure y centros de datos locales, además de firewalls y proxies de terceros. Necesitan detecciones de baja latencia para el abuso de credenciales, creación de tickets y contención automatizadas, y paneles claros y flujos de trabajo de caza para el SOC.

1. Incorporar servidores híbridos con Azure Arc y AMA

• Despliegue la incorporación de servidores habilitados para Azure Arc a escala usando Azure Policy, y luego asigne la política de extensión de AMA al ámbito de Arc. Cree DCR para “Eventos de seguridad de Windows a través de AMA” (conjunto común), Firewall de Windows y una DCR personalizada para Sysmon donde esté instalado. Este enfoque proporciona una recopilación consistente y gestionada de forma centralizada sin necesidad de scripts por host y asegura que SecurityEvent se popule para el análisis de identidad y procesos.

2. Ingerir telemetría de red y de dispositivos de seguridad mediante Syslog y CEF

• Despliegue una VM colectora Linux con AMA. Configure “Syslog a través de AMA” para las instalaciones relevantes y habilite “CEF a través de AMA” para analizar el CEF de firewalls y proxies en la tabla CommonSecurityLog. Usar CEF normaliza los datos de múltiples proveedores, lo que permite la portabilidad de las reglas y uniones (joins) sencillas entre fuentes.

3. Diseñar análisis para velocidad y fidelidad

• Habilite Fusion para capturar ataques multietapa con un ajuste mínimo. Cree reglas NRT para ráfagas de inicios de sesión fallidos seguidos de un éxito en cuentas privilegiadas usando SecurityEvent y

undefined

, proporcionando una detección en menos de dos minutos. Cree reglas programadas para patrones de movimiento lateral (p. ej., la creación de procesos de net.exe en servidores unidos a cuentas de administrador inusuales) y para anomalías de egreso del proxy unidas a listas de seguimiento de VIP y de hosts críticos (joyas de la corona). Esta combinación minimiza el MTTR mientras frena los falsos positivos.

4. Mapear entidades y dar forma a los incidentes

• En cada regla programada, mapee las entidades Account, Host, IP y Process desde las columnas de la consulta. Use reglas de automatización para asignar incidentes por unidad de negocio (derivada de las etiquetas del host), estandarizar la gravedad, añadir etiquetas de MITRE y cerrar automáticamente las señales de prueba conocidas. Un mapeo adecuado permite que el gráfico de investigación muestre relaciones por las que los analistas de Spotify pueden pivotar rápidamente.

5. Automatizar el enriquecimiento, la creación de tickets y la contención con playbooks

• Cree un playbook desencadenado por incidente que enriquezca todas las cuentas y hosts (búsquedas en el grafo, riesgo del dispositivo), publique en Teams y abra un ticket en Jira. Un playbook separado, desencadenado por alerta, enriquece alertas CEF específicas con API de proveedores. Use identidades administradas con RBAC de privilegios mínimos y ramificación condicional que solo aísle dispositivos (a través de Defender for Endpoint) o deshabilite usuarios (a través de Entra ID) cuando se cumplan los umbrales de confianza (p. ej., múltiples alertas corroborantes y una puntuación UEBA alta). Esto preserva la continuidad del negocio al tiempo que permite una respuesta rápida y gobernada.

6. Habilitar UEBA y operacionalizar la caza de amenazas

• Active UEBA y valide las fuentes de datos (SigninLogs, actividad de M365, señales de Defender). Forme a los analistas para que pivoten desde los incidentes a las páginas de entidad para ver las puntuaciones de anomalías y las comparaciones con homólogos. Convierta dos consultas de caza de alto valor —“Nuevas herramientas de administración remota en servidores” y “Patrones inusuales de exfiltración a IP externas”— en análisis programados una vez validadas mediante marcadores y livestream. UEBA, junto con una caza de amenazas disciplinada, refuerza la detección de técnicas novedosas.

7. Gobernar el ciclo de vida de los datos y visualizar la postura

• Establezca la retención en 180 días para SecurityEvent y CommonSecurityLog, 30 días para Syslog detallado con archivado a 1 año, y monitorice el costo con niveles de compromiso. Publique un libro de trabajo del SOC personalizado que rastree el estado de la ingesta, las reglas más ruidosas, MTTA/MTTR, las colas de incidentes por gravedad y las anomalías de UEBA a lo largo del tiempo. Esto proporciona transparencia para la dirección e impulsa el ajuste continuo.

Cada herramienta fue elegida por su fortaleza para un propósito específico: Arc y AMA+DCR ofrecen una ingesta escalable e impulsada por políticas; CEF asegura logs de seguridad normalizados de múltiples proveedores; Fusion y NRT reducen la latencia de detección sin un ajuste excesivo; el mapeo de entidades y el gráfico de investigación aceleran el triaje; los playbooks proporcionan una automatización gobernada y respaldada por identidades; UEBA proporciona contexto de comportamiento; las herramientas de caza maduran las detecciones; y los libros de trabajo mantienen las operaciones medibles y visibles.

← Microsoft Defender for Cloud y seguridad de endpoints · Todos los dominios · Seguridad de Active Directory Domain Services →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Microsoft →