Crear y administrar áreas de trabajo de Microsoft Sentinel
Enfoque: arquitectura, región y tenant, incorporación, RBAC, retención, planes de tablas y niveles de datos.
0/9
01 / 09Introducción
Sentinel se habilita en un área de Log Analytics. Su arquitectura determina residencia, alcance de consultas, acceso, retención, costos y administración del contenido.
Gobernanza, retención, acceso y facturación regionales.
Contenido repetido y consultas entre áreas.
Varios tenants
Proveedores y organizaciones distribuidas.
Administración delegada como Lighthouse.
SecurityEvent
| union workspace("Regional-SOC").SecurityEvent
La región es crítica: determina residencia y no puede cambiarse. Un área creada deliberadamente puede compartirse con Defender for Cloud; la predeterminada de este no admite incorporación.
04 / 09Administrar áreas entre tenants con Azure Lighthouse
Workspace manager publica contenido desde un área central a áreas miembro. Azure Lighthouse delega acceso a recursos entre tenants para administrar clientes sin cambiar cuentas. Uno centraliza contenido; el otro delega administración y pueden complementarse.
05 / 09Comprender los permisos y roles de Microsoft Sentinel
Rol
Capacidad
Reader
Ver datos, incidentes, libros y recursos.
Responder
Reader más asignar y administrar incidentes.
Contributor
Crear y editar análisis, libros y contenido; administrar incidentes.
Automation Contributor
Rol de servicio para agregar cuadernos a reglas; no para usuarios.
Autores pueden necesitar Logic App Contributor; la cuenta de servicio necesita permiso en el grupo del cuaderno; invitados necesitan Directory Readers; crear libros puede requerir Workbook Contributor.
Clave: RBAC hereda desde suscripción y grupo; un rol Azure amplio puede otorgar más acceso.
06 / 09Administrar la configuración de Microsoft Sentinel
Configuración específica de Sentinel y del área de Log Analytics gobiernan el entorno. Precios, funciones y vínculos aparecen en Sentinel; ingesta, uso, retención y tablas se administran en Log Analytics o el portal de Defender. La lección muestra retención de 30 a 730 días; las tablas pueden reemplazar el valor del área.
Planificá por estado, plan y nivel. Retención analítica admite consultas, alertas, búsqueda y libros. Largo plazo reduce costo y se accede por trabajos de búsqueda, restauración o lago.
Plan/nivel
Uso
Límite
Analytics
Monitoreo, detecciones, joins, búsqueda y libros.
Mayor costo.
Basic
Solución ocasional en una tabla.
KQL restringido.
Auxiliary
Auditoría detallada de poco uso.
Acceso no optimizado.
Data lake
Datos secundarios y a largo plazo.
Sin análisis en tiempo real; trabajos KQL/Spark.
XDR predeterminado
Datos de búsqueda XDR por 30 días.
No se almacena en niveles Sentinel sin extensión.
Analytics puede retener 30 días a dos años y el lago hasta 12 años donde se admita. Sacar una tabla de Analytics puede detener alertas, búsquedas y detecciones.
Un buen diseño ubica datos en la región correcta, equilibra visibilidad con gobernanza, aplica privilegios mínimos y alinea costo y retención con detección e investigación.