Administrar el acceso a los datos de Microsoft Sentinel por recurso

El acceso a un área de trabajo se administra mediante Azure RBAC. Normalmente, los usuarios que tienen acceso a un área de trabajo de Log Analytics habilitada para Microsoft Sentinel también tienen acceso a todos los datos del área de trabajo, incluido el contenido de seguridad. Los administradores pueden usar roles de Azure para configurar el acceso a características específicas de Microsoft Sentinel, en función de los requisitos de acceso de su equipo.

Sin embargo, es posible que tenga algunos usuarios que necesiten acceder solo a datos específicos en el área de trabajo, pero que no deberían tener acceso a todo el entorno de Microsoft Sentinel. Por ejemplo, es posible que desee proporcionar a un equipo de operaciones que no son de seguridad (no SOC) acceso a los datos de eventos de Windows para los servidores que poseen.

En tales casos, se recomienda configurar el control de acceso basado en rol (RBAC) en función de los recursos que se permiten a los usuarios, en lugar de proporcionarles acceso al área de trabajo o a características Microsoft Sentinel específicas. Este método también se conoce como configuración de RBAC de contexto de recursos.

Cuando los usuarios tienen acceso a los datos de Microsoft Sentinel a través de los recursos a los que pueden acceder, en lugar de mediante el área de trabajo, pueden ver registros y libros de trabajo mediante los siguientes métodos:

Mediante el propio recurso, como una máquina virtual Azure. Use este método para consultar los registros y los libros de un recurso específico únicamente.
A través de Azure Monitor. Use este método cuando desee crear consultas que abarquen varios recursos o grupos de recursos. Al ir a los registros y libros de trabajo de Azure Monitor, defina el ámbito para incluir uno o varios grupos de recursos o recursos específicos.

Habilitar RBAC en el contexto de recursos en Azure Monitor. Para obtener más información, consulte Administración del acceso a los datos de registro y las áreas de trabajo en Azure Monitor.

Nota:

Si los datos no son un recurso de Azure, como Syslog, CEF o Microsoft Entra ID datos, o datos recopilados por un recopilador personalizado, deberá configurar manualmente el identificador de recurso que se usa para identificar los datos y habilitar el acceso. Para obtener más información, vea Configuración explícita de RBAC de contexto de recursos para recursos que no son Azure.

Además, las funciones y las búsquedas guardadas no se admiten en contextos centrados en recursos. Por lo tanto, las características de Microsoft Sentinel como el análisis y la normalización no se admiten para el control de acceso basado en roles en el contexto de recursos de Microsoft Sentinel.

Escenarios para RBAC en contexto de recursos

La siguiente tabla destaca los escenarios en los que el RBAC en el contexto de los recursos resulta más útil. Tenga en cuenta las diferencias en los requisitos de acceso entre los equipos SOC y los equipos ajenos al SOC.

Tipo de requisito	Equipo de SOC	Equipo que no es de SOC
Permisos	Todo el área de trabajo	Solo recursos específicos
Acceso a los datos	Todos los datos del área de trabajo	Solo los datos de los recursos a los que el equipo está autorizado a acceder
Experiencia	La experiencia de Microsoft Sentinel completa, posiblemente limitada por los permisos funcionales asignados al usuario	Solo consultas de registro y libros

Si su equipo tiene requisitos de acceso similares a los del equipo no SOC descrito en la tabla anterior, el RBAC en contexto de recurso puede ser una buena solución para su organización.

Por ejemplo, en la imagen siguiente se muestra una versión simplificada de una arquitectura de área de trabajo en la que los equipos de seguridad y operaciones necesitan acceso a distintos conjuntos de datos y se usa RBAC de contexto de recursos para proporcionar los permisos necesarios.

En esta imagen:

El área de trabajo de Log Analytics habilitada para Microsoft Sentinel se coloca en una suscripción independiente para aislar mejor los permisos de la suscripción que usan los equipos de aplicaciones para hospedar sus cargas de trabajo.
A los equipos de aplicaciones se les concede acceso a sus respectivos grupos de recursos, donde pueden administrar sus recursos.

Esta suscripción independiente y el RBAC de contexto de recursos permiten a estos equipos ver los registros generados por los recursos a los que tienen acceso, incluso cuando los registros se almacenan en un área de trabajo donde no tienen acceso directo. Los equipos de aplicaciones pueden acceder a sus registros a través del área Registros de la Azure Portal, para mostrar los registros de un recurso específico, o a través de Azure Monitor, para mostrar todos los registros a los que pueden acceder al mismo tiempo.

Configurar explícitamente el RBAC en el contexto del recurso para recursos que no son de Azure

Los recursos de Azure admiten de forma nativa RBAC en contexto de recurso, pero pueden requerir ajustes adicionales al trabajar con recursos que no son de Azure. Por ejemplo, los datos del área de trabajo de Log Analytics habilitados para Microsoft Sentinel que no son Azure recursos incluyen datos de Syslog, CEF o AAD, o datos recopilados por un recopilador personalizado.

Siga los pasos siguientes si desea configurar RBAC en el contexto de recursos, pero sus datos no son un recurso de Azure.

Para configurar explícitamente RBAC en el contexto de recursos:

Asegúrese de que haya habilitado RBAC en el contexto de recursos en Azure Monitor.
Cree un grupo de recursos para cada equipo de usuarios que necesite acceder a los recursos sin todo el entorno de Microsoft Sentinel.

Asigne permisos de lector de registros para cada uno de los miembros del equipo.
Asigne recursos a los grupos de equipos de recursos que creó y etiquete eventos con los identificadores de recursos pertinentes.

Cuando Azure recursos envían datos a Microsoft Sentinel, los registros se etiquetan automáticamente con el identificador de recurso del origen de datos.

Sugerencia

Se recomienda agrupar los recursos para los que se concede acceso en un grupo de recursos específico creado con el fin.

Si no puedes, asegúrate de que tu equipo tenga permisos de lectura de registros directamente sobre los recursos a los que quieres que accedan.

Para obtener más información sobre los identificadores de recursos, consulte:

Id. de recursos con reenvío de registros

Cuando los eventos se recopilan mediante Common Event Format (CEF) o Syslog, el reenvío de registros se usa para recopilar eventos de varios sistemas de origen.

Por ejemplo, cuando una máquina virtual de reenvío de CEF o Syslog escucha los orígenes que envían eventos de Syslog y los reenvía a Microsoft Sentinel, el id. de recurso de la máquina virtual de reenvío de registros se asigna a todos los eventos que reenvían.

Si tiene varios equipos, asegúrese de que tiene máquinas virtuales de reenvío de registros independientes que procesan los eventos para cada equipo independiente.

Por ejemplo, separar las máquinas virtuales garantiza que los eventos de Syslog que pertenecen al equipo A se recopilan mediante la máquina virtual del recopilador A.

Sugerencia

Al usar una máquina virtual local u otra máquina virtual en la nube, como AWS, como reenviador de registros, asegúrese de que tiene un identificador de recurso mediante la implementación de Azure Arc.
Para escalar el entorno de la máquina virtual de reenvío de registros, tiene la opción de crear un conjunto de escalado de máquinas virtuales para recopilar los registros de CEF y Syslog.

Id. de recursos con recopilación Logstash

Si va a recopilar los datos mediante el complemento de salida Microsoft Sentinel Logstash, use el campo azure_resource_id para configurar el recopilador personalizado para incluir el identificador de recurso en la salida.

Si usa RBAC de contexto de recursos y quiere que los eventos recopilados por la API estén disponibles para usuarios específicos, use el identificador de recurso del grupo de recursos que creó para los usuarios.

Por ejemplo, el código siguiente muestra un archivo de configuración logstash de ejemplo:

 input {
     beats {
         port => "5044"
     }
 }
 filter {
 }
 output {
     microsoft-logstash-output-azure-loganalytics {
       workspace_id => "4g5tad2b-a4u4-147v-a4r7-23148a5f2c21" # <your workspace id>
       workspace_key => "u/saRtY0JGHJ4Ce93g5WQ3Lk50ZnZ8ugfd74nk78RPLPP/KgfnjU5478Ndh64sNfdrsMni975HJP6lp==" # <your workspace key>
       custom_log_table_name => "tableName"
       azure_resource_id => "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/contosotest" # <your resource ID>   
     }
 }

Sugerencia

Es posible que desee agregar varias output secciones para diferenciar las etiquetas aplicadas a diferentes eventos.

Identificadores de recurso en la colección de API de Log Analytics

Al recopilar mediante el uso de la API de recopilador de datos de Log Analytics, puede asignar un identificador de recurso a los eventos mediante el encabezado de solicitud HTTP x-ms-AzureResourceId.

Alternativas al RBAC en contexto de recursos

En función de los permisos necesarios en su organización, es posible que el uso de RBAC de contexto de recursos no proporcione una solución completa. Por ejemplo, considere el caso de que la organización cuya arquitectura se describe en la sección anterior deba también conceder acceso a los registros de Office 365 a un equipo interno de auditoría. En este caso, podrían usar RBAC de nivel de tabla para conceder al equipo de auditoría acceso a toda la tabla OfficeActivity , sin conceder permisos a ninguna otra tabla.

En la lista siguiente se describen escenarios en los que otras soluciones para el acceso a datos pueden ajustarse mejor a sus requisitos:

Escenario	Solución
Una filial tiene un equipo de SOC que requiere una experiencia Microsoft Sentinel completa.	En este caso, use una arquitectura de varias áreas de trabajo para separar los permisos de datos. Para más información, vea: Extensión de Microsoft Sentinel entre áreas de trabajo e inquilinos > Trabajar con incidentes en muchas áreas de trabajo a la vez
Quiere proporcionar acceso a un tipo específico de evento.	Por ejemplo, proporcione a un administrador de Windows acceso a eventos de Seguridad de Windows en todos los sistemas. En tales casos, use RBAC de nivel de tabla para definir permisos para cada tabla.
Limitar el acceso a un nivel más granular, ya sea no basado en el recurso, o solo a un subconjunto de los campos de un evento	Por ejemplo, es posible que desee limitar el acceso a los registros de Office 365 en función de la filial del usuario. En este caso, proporcione acceso a los datos mediante la integración integrada con paneles e informes de Power BI.
Limitar el acceso por grupo de administración	Coloque Microsoft Sentinel en un grupo de administración independiente dedicado a la seguridad, lo que garantiza que solo se hereden permisos mínimos a los miembros del grupo. En el equipo de seguridad, asigne permisos a grupos diferentes según cada función de grupo. Dado que todos los equipos tienen acceso a todo el área de trabajo, tendrán acceso a la experiencia de Microsoft Sentinel completa, restringida solo por los roles de Microsoft Sentinel que se les asignan. Para obtener más información, vea Permisos en Microsoft Sentinel.

Para más información, vea:

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2026-07-29