Diseño de la arquitectura de áreas de trabajo de Microsoft Sentinel
En este artículo se proporciona un árbol de decisión que le va a ayudar a tomar decisiones clave sobre cómo diseñar la arquitectura de áreas de trabajo de Microsoft Sentinel. Para obtener más información, vea Diseños de ejemplo de áreas de trabajo de Microsoft Sentinel y Procedimientos recomendados de arquitectura de áreas de trabajo de Microsoft Sentinel. Este artículo forma parte de la Guía de implementación de Microsoft Sentinel.
Requisitos previos
Antes de trabajar con el árbol de decisión, asegúrese de contar con la siguiente información:
| Requisito previo | Descripción |
|---|---|
| Requisitos normativos relacionados con la residencia de datos de Azure | Microsoft Sentinel se puede ejecutar en áreas de trabajo de la mayoría, si no todas, las regiones admitidas en GA para Log Analytics. Las regiones de Log Analytics recién admitidas pueden tardar un tiempo en incorporarse al servicio Microsoft Sentinel. Los datos que genera Microsoft Sentinel, como incidentes, marcadores y reglas de análisis, pueden contener datos del cliente procedentes de las áreas de trabajo de Log Analytics de este. Para obtener más información, consulte Disponibilidad geográfica y residencia de datos. |
| Orígenes de datos | Descubra qué orígenes de datos necesita conectar, incluidos conectores integrados a soluciones de Microsoft y de otros fabricantes. También puede usar el formato de evento común (CEF), Syslog o API de REST para conectar los orígenes de datos a Microsoft Sentinel. Si tiene máquinas virtuales de Azure en varias ubicaciones de Azure de las que necesita recopilar registros, y es importante para usted ahorrar en el coste de salida de datos, calcule el coste de salida de datos mediante la calculadora de precios de ancho de banda para cada ubicación de Azure. |
| Roles de usuario y niveles o permisos de acceso a datos | Microsoft Sentinel usa control de acceso basado en rol de Azure (RBAC de Azure) para proporcionar roles integrados que se pueden asignar a usuarios, grupos y servicios de Azure. Todos los roles integrados de Microsoft Sentinel conceden acceso de lectura a los datos del área de trabajo de Microsoft Sentinel. Por lo tanto, debe averiguar si es necesario controlar el acceso a los datos por origen de datos o nivel de fila, ya que esta circunstancia afectará a la decisión sobre el diseño de las áreas de trabajo. Para obtener más información, consulte Roles personalizados y RBAC avanzado de Azure. |
| Tasa de ingesta de datos | La tasa de ingesta diaria, normalmente en GB/día, es uno de los factores clave de las consideraciones de administración de costos y planeamiento, y del diseño de áreas de trabajo para Microsoft Sentinel. En la mayoría de los entornos híbridos y en la nube, los dispositivos de red, como firewalls o servidores proxy, y los servidores Windows y Linux generan los datos más ingeridos. Para obtener los resultados más precisos, Microsoft recomienda un inventario exhaustivo de orígenes de datos. También se puede usar la calculadora de costos de Microsoft Sentinel, que incluye tablas útiles para estimar las superficies de orígenes de datos. Importante: Estas estimaciones son un punto de partida; la configuración del nivel de detalle del registro y la carga de trabajo producirán variaciones. Se recomienda supervisar el sistema periódicamente para realizar un seguimiento de posibles cambios. Se recomienda una supervisión periódica en función de su escenario. Para más información, consulte Detalles de los precios de los registros de Azure Monitor. |
Árbol de decisión
En la siguiente imagen se muestra un gráfico de flujo de árbol de decisión completo para ayudarle a conocer la forma óptima de diseñar su área de trabajo.
En las siguientes secciones se proporciona una versión de texto completo de este árbol de decisión, incluidas las notas tomadas de la imagen que figuran a continuación:
Nota 1 | Nota 2 | Nota 3 | Nota 4 | Nota 5 | Nota 6 | Nota 7 | Nota 8 | Nota 9 | Nota 10
Paso 1: ¿Área de trabajo nueva o ya existente?
¿Tiene ya un área de trabajo que pueda usar para Microsoft Sentinel?
Si no es así, y va a crear una desde cero de todos modos, vaya directamente al paso 2.
Si ya tiene un área de trabajo que podría usar, tenga presente la cantidad de datos que va a ingerir.
Paso 2: ¿Mantener los datos en diferentes zonas geográficas de Azure?
Si tiene requisitos normativos que le obliguen a mantener los datos en distintas zonas geográficas de Azure, use un área de trabajo de Microsoft Sentinel independiente para cada región de Azure con requisitos de cumplimiento. Para obtener más información, consulte Consideraciones sobre las regiones.
Si no tiene que mantener los datos en diferentes zonas geográficas de Azure, continúe con el paso 3.
Paso 3: ¿Tiene varios inquilinos de Azure?
Si solo tiene un único inquilino, vaya directamente al paso 4.
Si tiene varios inquilinos de Azure, considere si va a recopilar registros específicos de un límite de inquilino, como Office 365 o XDR de Microsoft Defender.
Si no tiene registros específicos de inquilinos, vaya directamente al paso 4.
Si va a recopilar registros específicos de inquilinos, use un área de trabajo de Microsoft Sentinel independiente para cada inquilino de Microsoft Entra. Continúe con el paso 4 para conocer otras consideraciones.
Nota 1 del árbol de decisión: Los registros específicos de límites de inquilino, como los de Office 365 y Microsoft Defender for Cloud, solo se pueden almacenar en el área de trabajo dentro del mismo inquilino.
Aunque es posible usar recopiladores personalizados para recopilar registros específicos de inquilinos de un área de trabajo de otro inquilino, no se recomienda hacerlo debido a las siguientes desventajas:
- Los datos recopilados por conectores personalizados se ingieren en tablas personalizadas. Por lo tanto, no podrá usar todas las reglas y libros integrados.
- Algunas de las características integradas, como UEBA y las reglas de aprendizaje automático, no tienen en cuenta las tablas personalizadas.
- Los conectores personalizados requieren un coste y esfuerzo adicionales, como el uso de Azure Functions y Logic Apps.
Si estas desventajas no suponen ningún problema para la organización, vaya al paso 4 en lugar de usar áreas de trabajo de Microsoft Sentinel independientes.
Paso 4: ¿Dividir la facturación o el contracargo?
Si necesita dividir la facturación o el contracargo, considere si los informes de uso o los cargos cruzados manuales resultan adecuados en su caso.
Si no necesita dividir la facturación o el contracargo, continúe con el paso 5.
Si necesita dividir la facturación o los contracargos, considere la posibilidad de utilizar los cargos cruzados manuales. Para obtener costes precisos por entidad, puede usar una versión modificada del libro Costes de Microsoft Sentinel, que desglosa los costes por entidad.
Si los informes de uso o los cargos cruzados manuales resultan adecuados en su caso, continúe con el paso 5.
Si ninguna de las dos opciones resulta adecuada en su caso, use un área de trabajo de Microsoft Sentinel independiente para cada propietario de costos.
Nota 2 del árbol de decisión: Para obtener más información, vea Costos y facturación de Microsoft Sentinel.
Paso 5: ¿Recopilar datos que no sean SOC?
Si no va a recopilar datos que no sean SOC, como datos operativos, puede ir directamente al paso 6.
Si va a recopilar datos que no sean SOC, analice si hay superposiciones, esto es, casos en los que se necesite el mismo origen para datos SOC y datos que no sean SOC.
Si encuentra superposiciones entre datos SOC y datos que no sean SOC, trate los datos superpuestos exclusivamente como SOC. A continuación, considere si la ingesta de ambos tipos de datos por separado es inferior a 100 GB/día, pero superior a esta tasa cuando se combinan:
- Sí: continúe con el paso 6 para realizar una evaluación adicional.
- No: con el fin de ahorrar costos, no se recomienda usar la misma área de trabajo. Vaya al paso 6 para realizar una evaluación adicional.
Para más información en ambos casos, consulte la nota 10.
Si no tiene datos superpuestos, considere si la ingesta de ambos tipos de datos por separado es inferior a 100 GB/día, pero superior a esta tasa cuando se combinan:
Combinación de los datos SOC y los datos que no son SOC
Nota 3 del árbol de decisión: aunque generalmente se recomienda que los clientes tengan un área de trabajo independiente para los datos que no sean SOC, de modo que estos datos no generen costos de Microsoft Sentinel, puede haber situaciones en las que combinar datos SOC y datos que no sean SOC resulte menos costoso que separarlos.
Por ejemplo, considere una organización que tenga registros de seguridad que ingieran 50 GB/día, registros de operaciones que ingieran 50 GB/día y un área de trabajo en la región Este de EE. UU.
En la siguiente tabla se comparan opciones de área de trabajo con y sin áreas de trabajo independientes.
Nota
Los costes y términos que figuran en la siguiente tabla son falsos y solo se usan con fines ilustrativos. Para obtener información de costos actualizada, vea la calculadora de precios de Microsoft Sentinel.
| Arquitectura de áreas de trabajo | Descripción |
|---|---|
| El equipo de SOC tiene su propia área de trabajo, con Microsoft Sentinel habilitado. El equipo de operaciones tiene su propia área de trabajo, sin Microsoft Sentinel habilitado. |
Equipo de SOC: El costo de Microsoft Sentinel por 50 GB/día es de 6 500 USD mensuales. Los tres primeros meses de retención son gratuitos. Equipo de operaciones: - El costo de Log Analytics a 50 GB/día es de aproximadamente 3 500 USD mensuales. - Los primeros 31 días de retención son gratuitos. El coste total de ambos asciende a 10 000 USD mensuales. |
| Los equipos de SOC y operaciones comparten la misma área de trabajo con Microsoft Sentinel habilitado. | Combinando ambos registros, la ingesta será de 100 GB/día, lo que cumple los requisitos del nivel de compromiso (50 % para Sentinel y 15 % para Log Analytics). El costo de Microsoft Sentinel por 100 GB/día asciende a 9000 USD mensuales. |
En este ejemplo, obtendría un ahorro de costes de 1000 USD mensuales combinando ambas áreas de trabajo; además, el equipo de operaciones también disfrutaría de tres meses gratuitos de retención en lugar de solo 31 días.
Este ejemplo solo es pertinente en aquellos casos en los que los datos SOC y los datos que no son SOC tienen por separado un volumen de ingesta de >=50 GB/día y <100 GB/día.
Nota 10 del árbol de decisión: Se recomienda usar un área de trabajo independiente para los datos que no sean SOC, de modo que estos datos no acarreen costos de Microsoft Sentinel.
Sin embargo, esta recomendación de usar áreas de trabajo independientes con datos que no sean SOC parte de una premisa puramente basada en costes, y hay otros factores de diseño clave que se deben examinar al determinar si usar una o varias áreas de trabajo. Para evitar duplicar los costes de ingesta, considere la posibilidad de recopilar datos superpuestos en una sola área de trabajo únicamente con RBAC de Azure de nivel de tabla.
Paso 6: ¿Varias regiones?
Si solo va a recopilar registros de VM de Azure en una única región, vaya directamente al paso 7.
Si va a recopilar registros de VM de Azure en varias regiones, ¿en qué medida le preocupa el coste de salida de datos?
Nota 4 del árbol de decisión: La salida de datos hace referencia al coste de ancho de banda por mover datos fuera de centros de datos de Azure. Para obtener más información, consulte Consideraciones sobre las regiones.
Si es prioritario reducir la cantidad de esfuerzo necesario para mantener áreas de trabajo independientes, vaya al paso 7.
Si la importancia del costo de salida de datos hace que merezca la pena mantener áreas de trabajo independientes, use un área de trabajo de Microsoft Sentinel independiente para cada región en la que necesite reducir dicho costo.
Nota 5 del árbol de decisión: Se recomienda tener el menor número de áreas de trabajo posible. Use la calculadora de precios de Azure para calcular el coste y determinar qué regiones necesita realmente, y combine las áreas de trabajo de regiones con costes de salida bajos. Los costos de ancho de banda pueden representar solo una pequeña parte de la factura de Azure en comparación con los costos de ingesta de Microsoft Sentinel y Log Analytics.
Por ejemplo, el coste se podría calcular de la siguiente manera:
- 1000 máquinas virtuales, cada una de las cuales genera 1 GB/día
- Envío de datos desde una región de EE. UU. a una región de Europa;
- Uso de una tasa de compresión de 2:1 en el agente
El cálculo del coste estimado sería el siguiente:
1000 VMs * (1GB/day ÷ 2) * 30 days/month * $0.05/GB = $750/month bandwidth costEste costo de ejemplo sería mucho menor en comparación con los costos mensuales de un área de trabajo independiente de Microsoft Sentinel y Log Analytics.
Nota
Los costes que se muestran son falsos y solo se usan con fines ilustrativos. Para obtener información de costos actualizada, vea la calculadora de precios de Microsoft Sentinel.
Paso 7: ¿Segregar datos o definir límites por propiedad?
Si no necesita segregar datos o definir límites de propiedad, vaya directamente al paso 8.
Si necesita segregar datos o definir límites basados en la propiedad, ¿necesita cada propietario de datos usar el portal de Microsoft Sentinel?
Si cada propietario de datos debe tener acceso al portal de Microsoft Sentinel, use un área de trabajo de Microsoft Sentinel independiente para cada uno de ellos.
Nota 6 del árbol de decisión: Para acceder al portal de Microsoft Sentinel hace falta que cada usuario tenga al menos un rol Lector de Microsoft Sentinel, con permisos de Lector en todas las tablas del área de trabajo. Si un usuario no tiene acceso a todas las tablas del área de trabajo, deberá usar Log Analytics para acceder a los registros en consultas de búsqueda.
Si el acceso a los registros mediante Log Analytics es suficiente en el caso de los propietarios que no tengan acceso al portal de Microsoft Sentinel, vaya al paso 8.
Para obtener más información, vea Permisos de Microsoft Sentinel.
Paso 8: ¿Controlar el acceso a los datos por origen o tabla?
Si no necesita controlar el acceso a los datos por origen o tabla, use una sola área de trabajo de Microsoft Sentinel.
Si necesita controlar el acceso por origen o tabla, considere usar RBAC de contexto de recursos en las siguientes situaciones:
Si necesita controlar el acceso en el nivel de fila, por ejemplo, para proporcionar varios propietarios en cada origen de datos o tabla
Si tiene múltiples tablas u orígenes de datos personalizados, donde cada uno necesita permisos independientes
En otros casos, cuando no necesite controlar el acceso en el nivel de fila, proporcione varias tablas u orígenes de datos personalizados con permisos independientes y use una sola área de trabajo de Microsoft Sentinel, con RBAC de nivel de tabla para el control de acceso a datos.
Consideraciones sobre RBAC de nivel de tabla o contexto de recursos
Si piensa usar RBAC de nivel de tabla o contexto de recursos, tenga presente la siguiente información:
Nota 7 del árbol de decisión: con el fin de configurar RBAC de contexto de recursos para recursos que no sean de Azure, puede que le interese asociar un identificador de recurso a los datos al enviarlos a Microsoft Sentinel, de modo que el ámbito del permiso se pueda establecer mediante RBAC de contexto de recursos. Para obtener más información, consulte Configuración explícita de RBAC de contexto de recursos y Modos de acceso por implementación.
Nota 8 del árbol de decisión: Con los permisos de recursos o el contexto de recursos los usuarios pueden ver registros únicamente de los recursos a los que tengan acceso. El modo de acceso al área de trabajo debe establecerse en Permisos de recurso de usuario o área de trabajo. En los resultados de búsqueda de la página Registros de Microsoft Sentinel solo se incluyen tablas pertinentes para los recursos en los que el usuario tenga permisos.
Nota 9 del árbol de decisión: Con RBAC de nivel de tabla puede definir un control más pormenorizado de los datos de un área de trabajo de Log Analytics, así como los demás permisos. Este control le permite definir tipos de datos específicos que son accesibles solo a un conjunto concreto de usuarios. Para obtener más información, vea RBAC de nivel de tabla en Microsoft Sentinel.
Pasos siguientes
En este artículo, ha revisado un árbol de decisión que le va a ayudar a tomar decisiones clave sobre cómo diseñar la arquitectura de áreas de trabajo de Microsoft Sentinel.