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

Artículo
12/06/2023

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 crearán 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 solo usa uno de estos servicios, puede omitir el otro en su evaluación.

Aquí tiene un vídeo sobre los fundamentos de Azure Monitor Logs y los procedimientos recomendados y consideraciones de diseño para diseñar su implementación de Azure Monitor Logs:

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. No hay limitaciones de rendimiento de la cantidad de datos en el área de trabajo. Varios servicios y orígenes de datos pueden enviar datos a la misma área de trabajo. A medida que identifique los criterios para crear más áreas de trabajo, su diseño debe utilizar el menor número que se ajuste a 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. La consolidación en una sola área de trabajo puede permitirle reducir los cargos aún más con un nivel de compromiso. Evalúe cada uno de los criterios de forma independiente. Tenga en cuenta sus requisitos y prioridades a fin de determinar qué diseño será 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. También puede tener implicaciones en los costos de cada estrategia.
Inquilinos de Azure	Si tiene varios inquilinos de Azure, 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 Azure.
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, puede crear áreas de trabajo por empresas subsidiarias o afiliadas.
Facturación dividida	Al colocar áreas de trabajo en suscripciones independientes, se pueden facturar a distintas entidades.
Retención y archivado de datos	Puede establecer diferentes opciones de retención para cada área de trabajo y cada tabla de un área de trabajo. Necesita un área de trabajo independiente si requiere 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 le permiten reducir el coste de ingesta confirmando una cantidad mínima de datos diarios 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 error en una región, puede ingerir datos en varias áreas de trabajo en 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. See Detalles de los precios de los registros de Azure Monitor.

Área de trabajo combinada La combinación de sus datos de Azure Monitor y Microsoft Sentinel en el mismo área de trabajo le ofrece una mejor visibilidad de todos sus datos, lo que le permite combinarlos fácilmente en consultas y libros. Si el acceso a los datos de seguridad debe limitarse a un equipo concreto, puede usar RBAC de nivel de tabla para bloquear a determinados usuarios de las tablas con datos de seguridad o limitar a los usuarios el acceso al área de trabajo mediante el contexto de recursos.

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 inquilinos de Azure, puede crear cuatro áreas de trabajo con un área de trabajo operativa y de seguridad en cada inquilino.

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 Azure

La mayoría de recursos solo pueden enviar datos de supervisión a un área de trabajo del mismo inquilino de Azure. 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 Azure independientes. Puede plantearse este escenario como proveedor de servicios.

Si tiene un único inquilino de Azure: cree una sola área de trabajo para ese inquilino.
Si tiene varios inquilinos de Azure: 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.

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. Puede usar Cost Management y Facturación de Azure para ver los cargos por área de trabajo. También puede usar una consulta de registro para ver 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 realizar una devolución de cargos: considere si Cost Management y Facturación de Azure o una consulta de registro proporciona informes de costos suficientemente pormenorizados para sus requisitos. Si no es así, use un área de trabajo independiente para cada propietario del coste.

Retención y archivado de datos

Puede configurar la retención de datos y los valores de archivo predeterminados para un área de trabajo o configurar diferentes opciones para cada tabla. Puede requerir una configuración diferente para diferentes conjuntos de datos en una tabla determinada. De ser así, debe separar esos datos en diferentes áreas de trabajo, cada una con una configuración de retención única.

Si puede usar la misma configuración de retención y archivo para todos los datos de cada tabla: utilice una sola área de trabajo para todos los recursos.
Si necesita una configuración de retención y archivo 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 una sola área de trabajo para alcanzar el valor de 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 puede confirmar a la ingesta diaria de al menos 100 GB al día, debe implementar un clúster dedicado que proporcione función 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 de contexto de recursos: de manera predeterminada, si un usuario tiene acceso de lectura a un recurso de Azure, hereda permisos a cualquiera de los datos de supervisión de ese recurso enviados 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. Si necesita bloquear este acceso, puede cambiar 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 de nivel de tabla: con RBAC de nivel de tabla, puede conceder o denegar el acceso a tablas específicas del área de trabajo. De este modo, se pueden implementar 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 por tabla pormenorizado: conceda a las operaciones y al equipo de seguridad acceso a sus recursos y permita a los propietarios de recursos usar RBAC de contexto de recursos 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.

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, puede ingerir 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.

Trabajo con varias áreas de trabajo

Dado que muchos diseños incluirán varias áreas de trabajo, Azure Monitor y Microsoft Sentinel incluyen características que le ayudarán a analizar estos datos entre áreas de trabajo. Para obtener más información, consulte:

Varias estrategias de inquilino

Los entornos con varios inquilinos de Azure, incluidos los proveedores de servicios de Microsoft (MSP), los proveedores de software independientes (ISV) y las grandes empresas, suelen requerir una estrategia en la que un equipo de administración central tenga acceso a administrar los espacios de trabajo ubicados en otros inquilinos. Cada uno de los inquilinos puede representar clientes independientes o unidades de negocio diferentes.

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 Azure. Esta es la única opción que puede usar si está supervisando los servicios de Azure distintos de las máquinas virtuales.

Hay dos opciones para permitir que los administradores del proveedor de servicios accedan 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.
El aislamiento entre los clientes con respecto a las disposiciones legales y el 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 visualización y el análisis de datos de forma centralizada entre los inquilinos del cliente con herramientas, como libros de Azure Monitor, pueden dar lugar a experiencias más lentas. En especial, este es el caso cuando se analizan datos en más de 50 á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.

Centralizado

Se crea una sola área de trabajo en la suscripción del proveedor de servicios. Esta opción solo puede recopilar datos de las máquinas virtuales del cliente. Los agentes instalados en las máquinas virtuales están configurados para enviar sus registros a esta área de trabajo central.