Diseñar una arquitectura de área de trabajo de Log Analytics

Una única área de trabajo de Log Analytics podría ser suficiente para muchos entornos que usan Azure Monitor y Microsoft Sentinel. Pero muchas organizaciones crean varias áreas de trabajo para optimizar los costes y satisfacer mejor los distintos requisitos empresariales. En este artículo se presenta un conjunto de criterios para determinar si se debe usar una única área de trabajo o varias. También se describe la configuración y la ubicación de esas áreas de trabajo para satisfacer sus requisitos a la vez que optimiza los costos.

Nota

En este artículo se describe Azure Monitor y Microsoft Sentinel porque muchos clientes deben tener en cuenta ambos servicios en su diseño. La mayoría de los criterios de decisión se aplican a ambos servicios. Si usa solo uno de estos servicios, omita el otro en la evaluación.

En el siguiente vídeo se tratan los aspectos básicos de Azure Monitor Logs, las prácticas recomendadas y las consideraciones de diseño para su implementación:

Diseñar la estrategia

El diseño siempre debe empezar con una sola área de trabajo para reducir la complejidad de administrar varias áreas de trabajo y consultar datos de ellas. La cantidad de datos del área de trabajo no impone limitaciones de rendimiento. Varios servicios y orígenes de datos pueden enviar datos a la misma área de trabajo. A medida que identifica criterios para crear más áreas de trabajo, el diseño debe usar el menor número de áreas de trabajo para satisfacer sus requisitos.

El diseño de una configuración del área de trabajo incluye la evaluación de varios criterios. Pero algunos de los criterios podrían estar en conflicto. Por ejemplo, puede reducir los cargos de salida creando un área de trabajo independiente en cada región de Azure. Consolidar todo en una sola área de trabajo podría permitirle reducir aún más los costes con un nivel de compromiso de gasto. Evalúe cada uno de los criterios de forma independiente. Tenga en cuenta sus requisitos y prioridades a fin de determinar qué diseño es más eficaz para su entorno.

Criterios de diseño

En la tabla siguiente se presentan criterios que se deben tener en cuenta al diseñar la arquitectura del área de trabajo. Las secciones siguientes describen los criterios.

Criterios	Descripción
Datos operativos y de seguridad	Puede optar por combinar datos operativos de Azure Monitor en la misma área de trabajo que los datos de seguridad de Microsoft Sentinel o separarlos en su propia área de trabajo. Combinarlos le ofrece una mejor visibilidad de todos sus datos, mientras que sus normas de seguridad pueden requerir separarlos para que su equipo de seguridad disponga de una área de trabajo dedicada. Cada estrategia también puede tener implicaciones de coste.
Inquilinos de Microsoft Entra	Si tiene varios inquilinos de Microsoft Entra, normalmente creará un área de trabajo en cada uno de ellos. Varios orígenes de datos solo pueden enviar datos de supervisión a un área de trabajo del mismo inquilino de Microsoft Entra.
Regiones de Azure	Cada área de trabajo reside en una región de Azure determinada. Es posible que tenga requisitos normativos o de cumplimiento para almacenar datos en ubicaciones específicas.
Propiedad de los datos	Puede optar por crear áreas de trabajo independientes para definir la propiedad de los datos. Por ejemplo, podría crear áreas de trabajo según las filiales o empresas afiliadas.
Facturación dividida	Al colocar áreas de trabajo en suscripciones independientes, se pueden facturar a distintas entidades.
Retención de datos	Establezca una configuración de retención diferente para cada área de trabajo y cada tabla de un área de trabajo. Se necesita un área de trabajo independiente si necesita una configuración de retención diferente para distintos recursos que envían datos a las mismas tablas.
Niveles de compromiso	Los niveles de compromiso te permiten reducir el coste de ingesta al comprometerte con un volumen mínimo diario de datos en una sola área de trabajo.
Limitaciones del agente heredado	Los agentes de máquina virtual heredados tienen limitaciones en el número de áreas de trabajo a las que se pueden conectar.
Control de acceso a datos	Configure el acceso al área de trabajo y a diferentes tablas y datos de distintos recursos.
Resistencia	Para asegurarse de que los datos del área de trabajo están disponibles en caso de que se produzca un error en una región, ingiera datos en varias áreas de trabajo de diferentes regiones.

Datos operativos y de seguridad

La decisión de combinar sus datos operativos de Azure Monitor en la misma área de trabajo que los datos de seguridad de Microsoft Sentinel o separar cada uno en su propia área de trabajo depende de sus requisitos de seguridad y de las posibles implicaciones de costes para su entorno.

Áreas de trabajo dedicadas

La creación de áreas de trabajo dedicadas para Azure Monitor y Microsoft Sentinel le permitirá separar la propiedad de los datos entre los equipos operativos y de seguridad. Este enfoque también puede ayudar a optimizar los costes, ya que cuando se habilita Microsoft Sentinel en un área de trabajo, todos los datos de esa área de trabajo están sujetos a los precios de Microsoft Sentinel, incluso si son datos operativos que recopila Azure Monitor.

Un área de trabajo con Microsoft Sentinel obtiene tres meses de retención de datos gratis en lugar de 31 días. Este escenario suele producir mayores costos para los datos operativos en un área de trabajo sin Microsoft Sentinel. Consulte los detalles de precios de Azure Monitor Logs.

Área de trabajo combinada

La combinación de tus datos de Azure Monitor y Microsoft Sentinel en la misma área de trabajo te ofrece una mejor visibilidad de todos tus datos, permitiéndote combinar fácilmente ambos en consultas y cuadernos de trabajo. Si el acceso a los datos de seguridad debe limitarse a un equipo específico, use RBAC de nivel de tabla para impedir que determinados usuarios accedan a tablas con datos de seguridad o limitar el acceso de los usuarios al área de trabajo mediante resource-context.

Esta configuración puede suponer un ahorro de costes si le ayuda a alcanzar un nivel de compromiso, que proporciona un descuento en sus cargos de ingestión. Por ejemplo, consideremos una organización que tiene datos operativos y datos de seguridad que ingieren cada uno unos 50 GB al día. La combinación de los datos en la misma área de trabajo permitiría un nivel de compromiso de 100 GB al día. Ese escenario proporcionaría un descuento del 15 % para Azure Monitor y del 50 % para Microsoft Sentinel.

Si crea áreas de trabajo independientes para otros criterios, normalmente creará más pares de áreas de trabajo. Por ejemplo, si tiene dos tenants de Microsoft Entra, puede crear cuatro espacios de trabajo, con dos espacios de trabajo en cada tenant: uno operativo y otro de seguridad.

Si usa tanto Azure Monitor como Microsoft Sentinel: Considere separar cada uno en un área de trabajo dedicada si así lo requiere su equipo de seguridad o si supone un ahorro de costes. Considere la posibilidad de combinar los dos para obtener una mejor visibilidad de sus datos de supervisión combinados o alcanzar un nivel de compromiso.
Si usa Microsoft Sentinel y Microsoft Defender for Cloud: considere la posibilidad de usar la misma área de trabajo para ambas soluciones a fin de mantener los datos de seguridad en un solo lugar.

Inquilinos de Microsoft Entra

La mayoría de recursos solo pueden enviar datos de supervisión a un área de trabajo del mismo inquilino de Microsoft Entra. Las máquinas virtuales que usan el agente de Azure Monitor o los agentes de Log Analytics pueden enviar datos a áreas de trabajo en inquilinos de Microsoft Entra independientes. Puede plantearse este escenario como proveedor de servicios.

Si tiene un solo inquilino de Microsoft Entra: Crear un único área de trabajo para ese inquilino.
Si tiene varios inquilinos de Microsoft Entra: Cree un área de trabajo para cada inquilino. Vea Estrategias de varios inquilinos a fin de consultar otras opciones, incluidas las estrategias para los proveedores de servicios.

Regiones de Azure

Cada área de trabajo de Log Analytics reside en una región de Azure determinada. Es posible que tenga propósitos normativos o de cumplimiento para mantener los datos en una región determinada. Por ejemplo, una empresa internacional podría localizar un área de trabajo en cada región geográfica principal, como Estados Unidos y Europa.

Si tiene requisitos a fin de mantener los datos en una geografía determinada: cree un área de trabajo independiente para cada región con esos requisitos.
Si no tiene requisitos a fin de mantener los datos en una geografía determinada: use una sola área de trabajo para todas las regiones.
Si va a enviar datos a una geografía o región que se encuentra fuera de la región de su área de trabajo, independientemente de si el recurso de origen reside en Azure o no: considere usar un área de trabajo en la misma geografía o región que sus datos.

Plantéese también los posibles cargos de ancho de banda que pueden aplicarse al enviar datos a un área de trabajo desde un recurso de otra región. Estos cargos suelen ser menores en relación con los costos de ingesta de datos para la mayoría de los clientes. Normalmente, estos cargos se producen al enviar datos al área de trabajo desde una máquina virtual. La supervisión de datos desde otros recursos de Azure al usar la configuración de diagnóstico no incurre en cargos de salida.

Use la calculadora de precios de Azure para calcular el costo y determinar qué regiones necesita. Considere las áreas de trabajo de varias regiones si los cargos de ancho de banda son significativos.

Si los cargos de ancho de banda son lo suficientemente significativos como para justificar la complejidad adicional: cree un área de trabajo independiente para cada región con máquinas virtuales.
Si los cargos de ancho de banda no son lo suficientemente significativos como para justificar la complejidad adicional: use una sola área de trabajo para todas las regiones.

Propiedad de los datos

Es posible que tenga un requisito para separar los datos o definir límites en función de la propiedad. Por ejemplo, puede tener diferentes subsidiarias o empresas afiliadas que requieran delimitación de sus datos de supervisión.

Si necesita separación de datos: use un área de trabajo independiente para cada propietario de datos.
Si no necesita separación de datos: use una sola área de trabajo para todos los propietarios de datos.

Facturación dividida

Es posible que tenga que dividir la facturación entre diferentes partes o realizar cargos a un cliente o una unidad de negocio interna. Microsoft Cost Management + Billing muestra los cargos por área de trabajo. Una consulta de registros también puede mostrar el volumen de datos facturable por recurso de Azure, grupo de recursos o suscripción. Este enfoque puede ser suficiente para los requisitos de facturación.

Si no necesita dividir la facturación o realizar la devolución de cargos: use una sola área de trabajo para todos los propietarios de costos.
Si necesita dividir la facturación o repercutir cargos: Considere si Microsoft Cost Management + Billing o una consulta de registros proporciona informes de costes con el nivel de detalle suficiente para sus necesidades. Si no es así, use un espacio de trabajo independiente para cada responsable de costes.

Retención de datos

Configure las opciones de retención de datos predeterminadas para un área de trabajo o configure opciones diferentes para cada tabla. En el portal de Azure, vaya a Log Analytics workspaces> su área de trabajo >Tablas para ver y modificar la retención de cada tabla. Puede requerir una configuración diferente para diferentes conjuntos de datos en una tabla determinada. Si es así, separe esos datos en áreas de trabajo diferentes, cada uno con una configuración de retención única.

Si la misma configuración de retención funciona para todos los datos de cada tabla: Use una sola área de trabajo para todos los recursos.
Si necesita una configuración de retención diferente para los distintos recursos de la misma tabla: utilice un área de trabajo independiente para distintos recursos.

Niveles de compromiso

Los niveles de compromiso proporcionan un descuento sobre los costos de ingesta del área de trabajo cuando se compromete a una cantidad específica de datos diarios. Puede optar por consolidar los datos en un único espacio de trabajo para alcanzar un nivel determinado. Este mismo volumen de datos distribuidos entre varias áreas de trabajo no sería apto para el mismo nivel, a menos que tenga un clúster dedicado.

Si la ingesta diaria alcanza al menos 100 GB, implemente un clúster dedicado que proporcione funcionalidad y rendimiento adicionales. Los clústeres dedicados también permiten combinar los datos de varias áreas de trabajo del clúster para alcanzar el nivel de un nivel de compromiso.

Si va a ingerir al menos 100 GB al día entre todos los recursos: cree un clúster dedicado y establezca el nivel de compromiso adecuado.
Si va a ingerir al menos 100 GB al día entre todos los recursos: considere la posibilidad de combinarlos en una sola área de trabajo para aprovechar un nivel de compromiso.

Limitaciones del agente heredado

Aunque debe evitar enviar datos duplicados a varias áreas de trabajo debido a los cargos adicionales, es posible que tenga máquinas virtuales conectadas a varias áreas de trabajo. El escenario más común es un agente conectado a áreas de trabajo independientes para Azure Monitor y Microsoft Sentinel.

El agente de Azure Monitor y el agente de Log Analytics para Windows pueden conectarse a varias áreas de trabajo. El agente de Log Analytics para Linux únicamente puede conectarse a una sola área de trabajo.

Si usa el agente de Log Analytics para Linux: migre al agente de Azure Monitor o asegúrese de que las máquinas Linux solo requieran acceso a una sola área de trabajo.

Control de acceso a datos

Al conceder a un usuario acceso a un área de trabajo, este tiene acceso a todos los datos de esa área de trabajo. Este acceso es adecuado para un miembro de un equipo de administración central o de seguridad que debe acceder a los datos de todos los recursos. El acceso al área de trabajo también lo determina el control de acceso basado en roles (RBAC) de contexto de recursos y el RBAC de nivel de tabla.

RBAC en el contexto de los recursos: De manera predeterminada, si un usuario tiene acceso de lectura a un recurso de Azure, hereda permisos sobre cualquiera de los datos de supervisión de ese recurso que se envíen al área de trabajo. Este nivel de acceso permite a los usuarios acceder a información sobre los recursos que administran sin conceder acceso explícito al área de trabajo. Para bloquear este acceso, cambie el modo de control de acceso para requerir permisos explícitos del área de trabajo.

Si quiere que los usuarios puedan acceder a los datos de sus recursos: mantenga el modo de control de acceso predeterminado de Usar permisos de recurso o área de trabajo.
Si quiere asignar explícitamente permisos para todos los usuarios: cambie el modo de control de acceso a Requerir permisos del área de trabajo.

RBAC a nivel de tabla: con RBAC a nivel de tabla, conceda o deniegue el acceso a tablas específicas en el área de trabajo. De esta manera, implemente permisos pormenorizados necesarios para situaciones específicas en su entorno.

Por ejemplo, puede conceder acceso solo a tablas específicas que recopile Microsoft Sentinel a un equipo de auditoría interno. O bien puede denegar el acceso a las tablas relacionadas con la seguridad a los propietarios de recursos que necesitan datos operativos relacionados con sus recursos.

Si no necesita un control de acceso pormenorizado por tabla: otorgue al equipo de operaciones y al de seguridad acceso a sus recursos y permita que los propietarios de los recursos usen RBAC en el contexto del recurso para sus recursos.
Si necesita un control de acceso pormenorizado por tabla: conceda o deniegue el acceso a tablas específicas mediante RBAC de nivel de tabla.

Para más información, consulte Administración del acceso a los datos de Microsoft Sentinel por recurso.

Resistencia

Para asegurarse de que los datos críticos del área de trabajo están disponibles en caso de que se produzca un error en una región, ingiera algunos o todos los datos en varias áreas de trabajo de diferentes regiones.

Esta opción requiere la administración de la integración con otros servicios y productos por separado para cada área de trabajo. Aunque los datos estarán disponibles en el área de trabajo alternativa en caso de error, los recursos que dependen de los datos, como las alertas y los libros de trabajo, no sabrán que deben cambiar al área de trabajo alternativa. Considere la posibilidad de almacenar plantillas de ARM para recursos críticos con configuración para el área de trabajo alternativa en Azure DevOps o como directivas deshabilitadas que se pueden habilitar rápidamente en un escenario de conmutación por error.

Consideraciones sobre varias áreas de trabajo

Varios diseños pueden incluir varias áreas de trabajo. Por ejemplo, un equipo de operaciones de seguridad central podría usar sus propias áreas de trabajo de Microsoft Sentinel para administrar artefactos centralizados, como reglas de análisis o libros.

Tanto Azure Monitor como Microsoft Sentinel incluyen características que le ayudarán a analizar estos datos entre áreas de trabajo. Para más información, vea:

Al asignar nombres a cada área de trabajo, incluya un indicador significativo en el nombre para que el propósito de cada área de trabajo sea fácilmente identificable.

Estrategias para múltiples arrendatarios

Las organizaciones con múltiples tenants de Microsoft Entra suelen necesitar una estrategia para administrar áreas de trabajo entre distintos tenants. Entre los escenarios multiinquilino comunes se incluyen:

Proveedores de servicios: MSP, MSSP e ISV que administran áreas de trabajo en nombre de los clientes en inquilinos independientes.
Fusiones y adquisiciones empresariales: subsidiarias o empresas adquiridas que conservan inquilinos independientes durante o después de la integración.
Separación de entornos: organizaciones que usan inquilinos independientes para entornos de desarrollo, almacenamiento provisional y producción.

En cada escenario, un equipo de administración central normalmente requiere acceso a las áreas de trabajo ubicadas en otros inquilinos. Cada inquilino puede representar un cliente, una unidad de negocio o una fase de entorno independientes.

Nota

Para los asociados y proveedores de servicios que forman parte del programa Proveedor de soluciones en la nube (CSP), Log Analytics de Azure Monitor es uno de los servicios de Azure disponibles en las suscripciones de CSP de Azure.

En las secciones siguientes se describen dos estrategias básicas para esta función.

Arquitectura distribuida

En una arquitectura distribuida, se crea un área de trabajo de Log Analytics en cada inquilino de Microsoft Entra. Esta opción es la única disponible para la supervisión de servicios Azure distintos de las máquinas virtuales.

Dos opciones permiten a los administradores del proveedor de servicios acceder a las áreas de trabajo de los inquilinos del cliente:

Use Azure Lighthouse para acceder a cada inquilino del cliente. Los administradores del proveedor de servicios se incluyen en un grupo de usuarios de Microsoft Entra en el inquilino del proveedor de servicios. A este grupo se le concede acceso durante el proceso de incorporación para cada cliente. Después, los administradores pueden acceder a las áreas de trabajo de cada cliente desde su propio inquilino del proveedor de servicios, en lugar de tener que iniciar sesión en el inquilino de cada cliente de forma individual. Para obtener más información, consulte Supervisión de los recursos del cliente a escala.
Agregue usuarios individuales desde el proveedor de servicios como usuarios invitados de Microsoft Entra (B2B). Los administradores de inquilinos del cliente administran el acceso individual para cada administrador del proveedor de servicios. Los administradores del proveedor de servicios deben iniciar sesión en el directorio de cada inquilino en Azure Portal para acceder a estas áreas de trabajo.

Las ventajas de esta estrategia son las siguientes:

Los registros se pueden recopilar en todos los tipos de recursos.
El cliente puede confirmar niveles específicos de permisos con la administración de recursos delegados de Azure. O bien el cliente puede administrar el acceso a los registros mediante su propio RBAC de Azure.
Cada cliente puede tener diferentes valores para su área de trabajo, como la retención y límite de datos.
Aislamiento entre clientes por motivos normativos y de cumplimiento.
El cargo por cada área de trabajo se incluye en la factura de la suscripción del cliente.

Las desventajas de esta estrategia son las siguientes:

La ejecución de una consulta en un gran número de áreas de trabajo es lenta y no se puede escalar por encima de 100 áreas de trabajo. Es posible una capa central de visualización y análisis de datos, pero será lenta si existen más de una docena de áreas de trabajo. Esta situación es menos aguda si todas las áreas de trabajo se encuentran en la misma clúster dedicado. Para más información, consulte Ejecución de consultas entre áreas de trabajo.
Si los clientes no se incorporan a la administración de recursos delegados de Azure, los administradores de proveedores de servicios deben aprovisionarse en el directorio del cliente. Este requisito hace más difícil que el proveedor de servicios administre muchos inquilinos de cliente a la vez.
Al ejecutar una consulta en un área de trabajo, es posible que los administradores del área de trabajo tengan visibilidad sobre el texto completo de la consulta a través de auditoría de consultas.

Centralizado

Se crea una sola área de trabajo en la suscripción del proveedor de servicios. Esta opción puede recopilar datos de máquinas virtuales de clientes y servicios PaaS de Azure en función de la configuración de diagnóstico. Los agentes instalados en las máquinas virtuales y servicios PaaS se pueden configurar para enviar sus registros a esta área de trabajo central.