Administración del acceso a los datos de Microsoft Sentinel por recurso

Artículo
10/17/2024

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 los 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 solo necesiten acceder a datos específicos en el área de trabajo, pero no deben tener acceso a todo el entorno de Microsoft Sentinel. Por ejemplo, puede que quiera proporcionar a un equipo de operaciones que no son de seguridad (no SOC) el acceso a los datos de eventos de Windows de los servidores que son de su propiedad.

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 específicas de Microsoft Sentinel. 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 del área de trabajo, pueden ver registros y libros mediante los métodos siguientes:

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

Habilite RBAC de contexto de recursos en Azure Monitor. Para 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 datos de Microsoft Entra ID, o los 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 más información, consulte Configuración explícita de RBAC de contexto de recursos para recursos que no son de 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 de RBAC de contexto de recursos

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

Tipo de requisito	Equipo de SOC	Equipo que no es de SOC
Permisos	Toda la área de trabajo	Solo recursos específicos
Acceso a 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 completa de Microsoft Sentinel, 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 de SOC descrito en la tabla anterior, el 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 diferentes conjuntos de datos y RBAC de contexto de recursos se usa 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 los equipos de aplicaciones usan para hospedar sus cargas de trabajo.
A los equipos de aplicaciones se les concede acceso a sus respectivos grupos de recursos, donde pueden administrar los recursos.

Este RBAC de contexto de recurso y suscripción independiente permite 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 del 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.

Configuración explícita de RBAC de contexto de recursos para recursos que no son de Azure

Los recursos de Azure tienen compatibilidad integrada con RBAC de contexto de recursos, pero pueden requerir un ajuste adicional al trabajar con recursos que no son de Azure. Por ejemplo, los datos del área de trabajo de Log Analytics habilitada para Microsoft Sentinel que no son recursos de Azure 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 de 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 registro para cada uno de los miembros del equipo.
Asigne recursos a los grupos de equipos de recursos creados y etiquete los eventos con los id. de recursos correspondientes.

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

Sugerencia

Se recomienda agrupar los recursos a los que va a conceder acceso en un grupo de recursos específico creado para dicho fin.

Si no es posible, asegúrese de que el equipo tenga permisos de lector de registro directamente para los recursos a los que quiere que tengan acceso.

Para más información sobre los id. de recurso, vea:

Id. de recursos con reenvío de registros

Cuando los eventos se recopilan con el formato de evento común (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 hay máquinas virtuales de reenvío de registros independientes que procesan los eventos para cada equipo.

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

Sugerencia

Cuando use 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 id. de recurso mediante la implementación de Azure Arc.
Para escalar el entorno de la máquina virtual de reenvío de registros, considere la posibilidad de crear un conjunto de escalado de máquina virtual para recopilar los registros de CEF y Sylog.

Id. de recursos con recopilación Logstash

Si va a recopilar los datos mediante el complemento de salida Logstash de Microsoft Sentinel, use el campo azure_resource_id para configurar el recopilador personalizado a fin de incluir el id. 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 id. 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 muestra:

 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/wvvu95a2-99u4-uanb-hlbg-2vatvgqtyk7b/resourceGroups/contosotest" # <your resource ID>   
     }
 }

Sugerencia

Puede que quiera agregar varias secciones output para diferenciar las etiquetas aplicadas a distintos eventos.

Id. de recursos con recopilación de API de Log Analytics

Al realizar la recopilación mediante la API del recopilador de datos de Log Analytics, puede asignar a los eventos un id. 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 los registros de Office 365 a un equipo de auditoría interno. En este caso, pueden 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 los escenarios en los que otras soluciones para el acceso a datos pueden ajustarse mejor a sus requisitos:

Escenario	Solución
Una subsidiaria tiene un equipo de SOC que requiere una experiencia completa de Microsoft Sentinel.	En este caso, use una arquitectura de varias áreas de trabajo para separar los permisos de los datos. Para más información, consulte: Extensión de Microsoft Azure Sentinel entre áreas de trabajo e inquilinos >Procesamiento de incidentes en varias áreas de trabajo a la vez
Quiere proporcionar acceso a un tipo de evento específico.	Por ejemplo, proporcione a un administrador de Windows el acceso a los eventos de seguridad de Windows en todos los sistemas. En tales casos, use RBAC de nivel de tabla para definir los permisos de cada tabla.
Limitación del acceso a un nivel más granular, ya sea no basado en el recurso o a solo un subconjunto de los campos de un evento.	Por ejemplo, puede que quiera limitar el acceso a los registros de Office 365 en función de la subsidiaria de un usuario. En este caso, proporcione acceso a los datos mediante la integración incorporada 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 los permisos mínimos a los miembros del grupo. Dentro del 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 completa de Microsoft Sentinel, restringida solo por los roles de Microsoft Sentinel que están asignados. Para más información, consulte Permisos de Microsoft Sentinel.

Pasos siguientes

Para más información, consulte Permisos de Microsoft Sentinel.

Compartir a través de