RBAC granular (versión preliminar) en Azure Monitor

2025-06-05

El control de acceso basado en rol (RBAC) granular en Log Analytics de Azure Monitor permite filtrar los datos del área de trabajo que cada usuario puede ver o consultar, en función de las condiciones que especifique para satisfacer sus necesidades empresariales y de seguridad. Entre las ventajas de este control de acceso se incluyen:

Acceso a nivel de fila
Acceso de nivel de tabla
Separación del control y los planos de datos

Si la arquitectura de Log Analytics incluye varias áreas de trabajo para dar cabida a la segregación de datos, la privacidad o el cumplimiento, RBAC granular ayuda a simplificar al reducir el número de áreas de trabajo necesarias.

Vídeo de introducción

Prerrequisitos

Acción	Permiso necesario
Creación de un rol personalizado	Permiso `Microsoft.Authorization/roleDefinitions/write` en los ámbitos asignables. Por ejemplo, según lo proporcionado por el rol integrado con privilegios, Administradores de acceso de usuario.
Agregar o actualizar condiciones	Permisos `Microsoft.Authorization/roleAssignments/write` y `Microsoft.Authorization/roleAssignments/delete` para el área de trabajo de Log Analytics. Por ejemplo, según lo proporcionado por el rol integrado con privilegios, Administrador de control de acceso basado en roles.

¿Cuándo usar RBAC pormenorizado?

RBAC pormenorizado le ayuda a lograr los siguientes escenarios:

Segregación de datos : separe los datos de diferentes unidades, equipos y ubicaciones geográficas dentro del mismo área de trabajo y asegúrese de que cada usuario solo pueda acceder a los datos pertinentes para su grupo. Las condiciones de acceso usan campos de registro personalizados para aplicar el acceso de nivel de fila segregado por atributos como firewall, tipo de dispositivo, identificador de suscripción u otros identificadores.
Privacidad de los datos : proteja datos confidenciales o confidenciales, como información personal, registros de salud o transacciones financieras, y solo permita el acceso a los usuarios autorizados.
Cumplimiento de datos - Utilice RBAC pormenorizado como herramienta para ayudarle a satisfacer los requisitos normativos o legales de su sector o región. Aplique las directivas y controles adecuados sobre el acceso a los datos y el uso.

RBAC granular controla el acceso a datos, como ver o consultar datos. No aborda las acciones del plano de control, como establecer permisos para el acceso a datos, la administración del área de trabajo, las transformaciones o la exportación de datos.

Configuración de RBAC pormenorizado

Descubre RBAC pormenorizado con un ejemplo detallado de RBAC paso a paso.

En las secciones siguientes se proporciona información general sobre los conceptos clave y los pasos necesarios para configurar RBAC pormenorizado.

Creación de roles
Condiciones y expresiones
Operadores de expresión

Creación de roles

Para configurar RBAC pormenorizado, debe crear un rol personalizado con las acciones necesarias y, a continuación, asignar el rol personalizado con condiciones. Para más información sobre los roles personalizados, consulte Roles personalizados de Azure.

Los permisos mínimos necesarios para la acción de rol personalizado y las acciones de datos son:

Definición de roles personalizados	Permiso	Descripción
Acciones del plano de control (Acciones)	`Microsoft.OperationalInsights/workspaces/query/read`	Ejecute consultas en Log Analytics y consulte los metadatos. Este permiso no concede acceso a los datos.
Acciones del plano de datos (DataActions)	`Microsoft.OperationalInsights/workspaces/tables/data/read`	Acceso a los datos y es el `dataaction` elegido en la condición de asignación de roles. Si no se establece ninguna condición, este permiso concede acceso a todos los datos en el ámbito asignado.

Opcionalmente, agregue la Microsoft.OperationalInsights/workspaces/read acción de control para incluir el acceso desde Azure Portal. Para más información, consulte Acciones de datos y control RBAC de Azure.

Nota:

RBAC granular, como RBAC de Azure, es un modelo aditivo. Tus permisos efectivos son la suma de tus asignaciones de roles. Para que las condiciones de RBAC pormenorizadas surtan efecto, debe quitar las asignaciones de roles con privilegios de acceso más altos.

Por ejemplo, si tiene dos asignaciones de roles en el mismo ámbito, una establecida con una */read acción y la otra con condiciones que limitan el acceso a registros específicos, el permiso resultante es la */read acción que concede acceso a todos los registros del ámbito. No hay ninguna acción de denegación explícita, solo asignaciones de denegación.

Condiciones y expresiones

Al igual que las asignaciones de roles normales, el rol personalizado creado debe asignarse a un usuario o grupo. La diferencia es que, durante la asignación de roles, las condiciones se configuran para ajustar el control de acceso de forma precisa.

RBAC granular permite establecer una condición en tablas y en el nivel de fila, en función de los datos de cada registro. Planee restricciones basadas en estas dos estrategias:

Método de control de acceso	Ejemplo
Sin acceso a los datos, excepto lo que se permite	Restrinja el acceso a los logs de aplicaciones para que los usuarios solo puedan ver los registros donde la columna es una aplicación a la que pueden acceder.
Acceso a todos los datos, excepto lo que no se permite	Permitir el acceso a todos los registros de inicio de sesión, excepto aquellos en los que el valor de la columna `userPrincipalName` es "CEO".

Una condición consta de la acción de datos del rol y las expresiones. Una expresión es una instrucción lógica con el formato de AttributeOperatorValue.

Los valores están restringidos con soporte para los siguientes caracteres:

Caracteres alfanuméricos.
Caracteres especiales:@, , .-

RBAC granular de Log Analytics admite atributos de tabla y columna/valor:

Origen del atributo	Nombre de pantalla	Tipo	Descripción	Nombre del atributo
Recurso	Nombre de la tabla	Cuerda	Nombres de tabla usados para conceder o limitar.	Microsoft.OperationalInsights/workspaces/tables:'<nombre>'
Recurso	Valor de columna (Key es el nombre de la columna)	Diccionario (clave-valor)	Nombre y valor de columna. El nombre de columna es la clave. El valor de datos de la columna es el valor.	Microsoft.OperationalInsights/workspaces/tables/record:<clave>

Esta es una captura de pantalla de ejemplo de una condición de asignación de roles RBAC granular utilizando el método Sin acceso a los datos, excepto lo permitidoconfigurado mediante el portal de Azure.

Reduzca la complejidad configurando las asignaciones de roles RBAC pormenorizadas en el ámbito que establezca sus condiciones para que coincidan. Por ejemplo, si el rol personalizado se asigna en un ámbito de grupo de recursos, es posible que otras áreas de trabajo no tengan los recursos de tabla o columna especificados en la expresión, lo que hace que la condición se aplique inesperadamente.

Sin embargo, si establece una condición para una asignación de roles en el nivel de tabla, se deben crear dos roles de la siguiente manera:

Rol 1: Acción: Microsoft.OperationalInsights/workspaces/query/read para el área de trabajo de la tabla.
Rol 2: DataAction: Microsoft.OperationalInsights/workspaces/tables/data/read para la tabla de esta área de trabajo. Defina la condición en el rol con la acción de datos.

Para evitar crear dos roles, use el enfoque más sencillo asignando el rol en el entorno de trabajo y estableciendo las condiciones para controlar el nivel de la tabla.

Para más información, consulte Niveles de ámbito de RBAC de Azure.

Operadores de expresión

Las expresiones RBAC granulares usan un subconjunto de operadores de control de acceso basado en atributos (ABAC).

El atributo de nombre de tabla admite cuatro operadores. Estos operadores ofrecen flexibilidad para ajustar los valores relacionados con los nombres de tabla al establecer una condición.

Operadores de ABAC	Descripción
`StringEquals`	Coincidencia con distinción entre mayúsculas y minúsculas. Los valores deben coincidir exactamente con la cadena.
`StringNotEquals`	Negación de StringEquals.
`ForAllOfAnyValues:StringEquals`	Equivalente lógicamente a `in()`. Si cada valor del lado izquierdo satisface la comparación con al menos un valor del lado derecho, la expresión se evalúa como verdadera.
`ForAllOfAllValues:StringNotEquals`	Equivalente lógicamente a `!in()`. Si cada valor del lado izquierdo satisface la comparación con al menos un valor en el lado derecho, la expresión se evalúa como false.

Las condiciones de ABAC definidas para los valores de columna de Log Analytics se basan en los datos de esa columna. Solo se pueden comparar tipos de datos de cadena. Para el atributo de acceso de nivel de fila, cualquier conversión se basa únicamente en el comportamiento de KQL.

En la tabla siguiente se muestran los operadores de expresión de ABAC admitidos. Los operadores de Kusto equivalentes se enumeran para mayor claridad.

Operador ABAC	Operador equivalente de Kusto	Descripción
`StringEquals` / `StringEqualsIgnoreCase`	`==` / `=~`	Coincidencia que distingue mayúsculas de minúsculas (o no distingue mayúsculas de minúsculas) Los valores deben coincidir exactamente con la cadena.
`StringNotEquals` / `StringNotEqualsIgnoreCase`	`!=` / `!~`	Negación de StringEquals (o StringEqualsIgnoreCase).
`StringLike` / `StringLikeIgnoreCase`	`has_cs` / `has`	Coincidencia que distingue mayúsculas de minúsculas (o no distingue mayúsculas de minúsculas) El lado derecho del operador (RHS) es un término entero en el lado izquierdo (LHS).
`StringNotLike` / `StringNotLikeIgnoreCase`	`!has_cs` / `!has`	Negación del operador StringLike (o StringLikeIgnoreCase)
`StringStartsWith` / `StringStartsWithIgnoreCase`	`startswith_cs`/ `startswith`	Coincidencia que distingue mayúsculas de minúsculas (o no distingue mayúsculas de minúsculas) El valor comienza con la cadena.
`StringNotStartsWith` / `StringNotStartsWithIgnoreCase`	`!startswith_cs` / `!startswith`	Negación del operador StringStartsWith (o StringStartsWithIgnoreCase).
`ForAllOfAnyValues:StringEquals` / `ForAllOfAnyValues:StringEqualsIgnoreCase` `ForAllOfAllValues:StringNotEquals` / `ForAllOfAllValues:StringNotEqualsIgnoreCase` `ForAnyOfAnyValues:StringLikeIgnoreCase`	`In` / `In~` `!in` / `!in~` `has_any`	'ForAllOfAnyValues:<BooleanFunction>' admite varias cadenas y números. Si cada valor del lado izquierdo satisface la comparación con al menos un valor en el lado derecho, la expresión se evalúa como true.

Las condiciones de ABAC no se establecen directamente en las funciones. Si establece la condición en una tabla, se propagará a cualquier función que se base en ella. Para obtener más información sobre operadores y términos, vea Operadores de cadena.

Sugerencia

Use transformaciones para enriquecer los datos, cambiar los tipos de datos y cambiar mayúsculas y minúsculas para adaptarse mejor a las expresiones de ABAC. Si los datos no admiten las condiciones que desea aplicar, las transformaciones también son la solución. Por ejemplo, para aplicar condiciones a los datos con alta cardinalidad, como intervalos IP, use transformaciones para agrupar direcciones IP que pertenecen a subredes seleccionadas por nombre de subred.

Para más información, consulte Transformaciones de recopilación de datos en Azure Monitor.

Consideraciones

Se aplican varias consideraciones al usar RBAC pormenorizado en Log Analytics. En las secciones siguientes se proporcionan detalles.

RBAC granular solo está disponible en la nube pública.

Azure Monitor

Los trabajos de búsqueda y las reglas de resumen están planeados para la compatibilidad granular con RBAC, pero no para la exportación de datos. Para todas estas experiencias, si no existe acceso total a las tablas consultadas, el usuario no puede configurar el trabajo o regla de búsqueda y recibe un error.
Alertas: solo se admiten alertas de registro basadas en identidad administrada.
Application Insights: solo se admite Application Insights basado en áreas de trabajo.

Microsoft Sentinel

Cuando los datos se replican desde tablas originales mediante la búsqueda, los marcadores, la regla de análisis y los incidentes, los datos replicados no están protegidos por las condiciones de ABAC.

Azure ABAC y RBAC

Se aplican limitaciones normales de Azure RBAC y ABAC. Por ejemplo, el umbral de las asignaciones de roles máximas por suscripción es un límite de servicio de Azure para RBAC. Azure ABAC limita el número de expresiones por condición y el tamaño general de la condición en KB. Para obtener más información, consulte los artículos siguientes:

Auditoría y supervisión

Los cambios en las asignaciones de roles se registran en los registros de actividad de Azure. Las consultas de usuario de la LAQueryLogs tabla indican si la consulta se ejecutó con una condición de acceso ABAC aplicable en la ConditionalDataAccess columna. Habilite los registros mediante la configuración de diagnóstico en el área de trabajo de Log Analytics. Para más información, consulte Configuración de diagnóstico de registros de Azure Monitor.

Preguntas más frecuentes

Estoy accediendo a mis registros a través del contexto de recursos. ¿Se puede aplicar mi condición?
RBAC y ABAC se aplican para las consultas de contexto de recursos, pero requieren que las áreas de trabajo que contienen los registros de recursos cumplan estos requisitos previos:

Establezca el modo de control de acceso de todas las áreas de trabajo pertinentes en Requerir permisos de área de trabajo.
Si se establece en Uso de recursos o permisos de área de trabajo, el permiso de lectura de Azure asignado a un recurso proporciona acceso a todos los registros. Se omiten los permisos de área de trabajo y ABAC.
Establezca ABAC en todas las áreas de trabajo pertinentes.

Para más información, consulte Administración del acceso a áreas de trabajo de Log Analytics, modo de acceso.

¿Las condiciones de RBAC granulares se conservan cuando se exporta una tabla?
Las condiciones de RBAC pormenorizadas solo se aplican en las consultas. Por ejemplo, los datos exportados correctamente mediante la función de exportación de datos del entorno de trabajo no conservan las condiciones de ABAC en los datos de la tabla de destino.

¿Cómo se configura el acceso en función de la clasificación de datos?
Para implementar el modelo de acceso de estilo Bell-LaPadula, debe establecer explícitamente condiciones de ABAC para que se adhieren a entidades de seguridad como la lectura. Por ejemplo, un usuario con permisos de alto secreto debe tener permiso establecido explícitamente para niveles inferiores, como secreto, confidencial y sin clasificar para asegurarse de que pueden acceder a los datos en niveles inferiores a su nivel asignado superior.