Administración del acceso a Microsoft Sentinel datos 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 Microsoft Sentinel datos a través de los recursos a los que pueden acceder en lugar del área de trabajo, pueden ver registros y libros mediante los métodos siguientes:

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

Habilite RBAC de 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, no se admiten características Microsoft Sentinel como el análisis y la normalización para RBAC de contexto de recursos en Microsoft Sentinel.

Escenarios para RBAC de contexto de recursos

En la tabla siguiente se resaltan los escenarios en los que RBAC de contexto de recursos es más útil. Tenga en cuenta las diferencias en los requisitos de acceso entre los equipos soc y los equipos que no son soc.

Tipo de requisito	Equipo de SOC	Equipo que no es 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 está autorizado el equipo
Experiencia	La experiencia de Microsoft Sentinel completa, posiblemente limitada por los permisos funcionales asignados al usuario	Solo consultas de registro y libros

Si el equipo tiene requisitos de acceso similares al equipo que no es SOC descrito en la tabla anterior, RBAC de contexto de recursos 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 RBAC de contexto de recursos para recursos que no son Azure

Azure recursos tienen compatibilidad integrada con RBAC de contexto de recursos, pero pueden requerir un ajuste adicional al trabajar con recursos que no son 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 estos pasos si desea configurar RBAC de contexto de recursos, pero los datos no son un recurso Azure.

Para configurar explícitamente RBAC de contexto de recursos:

Asegúrese de que ha habilitado RBAC de 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 puede, asegúrese de que el equipo tiene permisos de lector de registros directamente para los recursos a los que desea que accedan.

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

Identificadores 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 cef o Syslog escucha los orígenes que envían eventos de Syslog y los reenvía a Microsoft Sentinel, el identificador 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 máquina virtual de reenvío de registros, considere la posibilidad de crear un conjunto de escalado de máquinas virtuales para recopilar los registros CEF y Syslog.

Identificadores de recursos con la colecció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 recursos con la colección de API de Log Analytics

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

Alternativas a RBAC de 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 si la organización cuya arquitectura se describe en la sección anterior también debe conceder acceso a Office 365 registros a un equipo de auditoría interno. 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 Office 365 registros en función de la filial de un 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-04-23