Uso de RBAC con ABAC

El control de acceso basado en rol (RBAC) y el control de acceso basado en atributos (ABAC) en el catálogo de Unity son controles complementarios diseñados para trabajar juntos. Responden a preguntas diferentes:

• RBAC controla con qué identidad actúa un usuario en una sesión. Un usuario asume un rol para actuar con los permisos de ese rol en lugar de los suyos propios. Use RBAC para conceder a un usuario varios conjuntos de permisos distintos entre los que cambian explícitamente, por ejemplo, separando el acceso entre ensayos clínicos, proyectos o niveles de confidencialidad.
• ABAC controla qué datos puede ver la identidad activa, fila por fila o columna por columna. Las directivas se adjuntan a los datos a través de etiquetas reguladas y se aplican a cualquier identidad que ejecute la consulta. Use ABAC para filtrar o enmascarar de forma coherente en muchas tablas controladas por atributos de datos.

RBAC establece la identidad activa de la sesión y ABAC evalúa sus políticas en función de esa identidad. En esta página se explica cómo se reproduce esa interacción en la práctica, el comportamiento de las funciones SQL relacionadas con la identidad y los patrones de uso combinado.

Cómo se comportan las funciones de identidad al asumir un rol

Las funciones SQL de Unity Catalog relacionadas con la identidad se evalúan según la identidad activa de la sesión, no según el usuario autenticado subyacente. Cuando un usuario asume un rol, la identidad de sesión activa se convierte en el rol:

Las directivas de ABAC que hacen referencia a estas funciones se evalúan con el rol asumido, no con el usuario. El rol asumido es la identidad activa para la evaluación de directivas ABAC, la resolución de concesiones de Unity Catalog y la atribución de auditorías. Como resultado, asumir un rol cambia el comportamiento de las directivas y vistas existentes que se crearon en torno a la identidad de cada usuario.

Problema común: vistas de seguridad a nivel de fila basadas en current_user()

Un patrón común en ABAC y en los filtros de filas en el nivel de tabla consiste en filtrar filas mediante una unión con una tabla de aprovisionamiento (también denominada tabla de mapeo o lista de control de acceso) indexada por el nombre de usuario devuelto por current_user(). Por ejemplo:

CREATE OR REPLACE FUNCTION facility_filter(facility_id STRING)
RETURN EXISTS (
  SELECT 1
  FROM governance.user_facility_provisioning p
  WHERE p.user = current_user()
    AND p.facility_id = facility_id
);

Cuando el mismo usuario asume un rol, current_user() ya no devuelve su nombre de usuario. Devuelve el nombre del rol. Dado que el rol no está en la tabla de aprovisionamiento, el filtro no devuelve ninguna fila y el usuario parece perder el acceso a los datos que se le habían concedido.

Adición del rol a la tabla de aprovisionamiento

Trata el rol como si fuera otro sujeto en tus datos de aprovisionamiento: inserta una fila por cada rol con los recursos (u otros atributos) a los que el rol debe tener acceso. A continuación, el filtro comprueba si la identidad activa es el usuario o el rol asumido.

Patrones de uso combinado

A continuación se muestran ejemplos de cómo los clientes usan RBAC y ABAC juntos para resolver problemas de control de acceso reales. Estos son puntos de partida, no recetas exhaustivas.

Filtros de filas por proyecto basados en el rol asumido

El filtrado de filas por proyecto es una necesidad común en la investigación de ensayos clínicos, el marketing de contratos, la consultoría de clientes y otras configuraciones en las que un equipo trabaja en varios proyectos aislados. En el ejemplo siguiente se usan ensayos clínicos, pero el patrón se generaliza en cualquier aislamiento de datos por proyecto.

Una organización de investigación clínica ejecuta varios ensayos simultáneos, cada uno en su propio rol de acceso. Etiquete cada tabla con el identificador del proyecto. Los usuarios solo ven las filas del proyecto cuyo rol han asumido actualmente.

Configuración:

• Las tablas debajo de clinical_trials.* tienen una columna project_id etiquetada con la clave etiqueta de controlproject.
• Cada proyecto tiene un rol de acceso correspondiente denominado role-<project> (por ejemplo, role-alpha, role-beta).
• Los usuarios solo tienen permiso Assume sobre los roles de los proyectos en los que trabajan.

UDF de filtro de filas:

CREATE FUNCTION project_match(project_id STRING) RETURNS BOOLEAN
DETERMINISTIC
RETURN current_user() = CONCAT('role-', project_id);

Directiva:

CREATE POLICY per_project_row_filter
ON CATALOG clinical_trials
ROW FILTER project_match
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('project') AS project
USING COLUMNS (project);

Esta UDF correlaciona la identidad activa con el valor de la etiqueta project de cada fila, por lo que las cláusulas de selección de entidades como TO / EXCEPT no pueden expresarlo, ya que estas se dirigen a entidades, no al contenido de las filas. Tal y como explica la guía sobre la selección de entidades, es preferible utilizar TO / EXCEPT para definir de forma sencilla el ámbito de las entidades y reservar las funciones de identidad dentro de una UDF para casos como este, en los que una única regla depende tanto de la identidad activa como del contenido de la fila.

Una sola directiva cubre todos los proyectos: USING COLUMNS (project) pasa el valor de etiqueta de project cada fila a la UDF, por lo que no necesita una directiva independiente por proyecto. Para ver la forma general de esta técnica —gestionar el acceso a las filas desde una tabla de consulta en lugar de basarse en la coincidencia de nombres de rol—, consulte Uso de tablas de asignación para el control de acceso dinámico.

Comportamiento:

• Un usuario que actúa con su propia identidad de usuario no ve ninguna fila en ninguna clinical_trials tabla. current_user() devuelve su nombre de usuario, que nunca coincide con el patrón de nomenclatura de role-*. Se trata de la denegación predeterminada prevista.
• Un usuario que asume role-alpha solo ve las filas en las que project_id es igual a alpha. Al cambiar a role-beta, se intercambian los datos visibles sin necesidad de volver a consultar nada más.

Se flexibiliza el enmascaramiento de PII para los usuarios con un rol designado

De forma predeterminada, las columnas PII (SSN, correo electrónico, teléfono) aparecen enmascaradas para todos. Para ver los valores sin procesar, el usuario debe asumir explícitamente un rol específico autorizado para el tratamiento de datos personales. Los registros de auditoría recogen el evento de asunción de rol, por lo que necesitaba consultar datos personales reales se convierte en una opción de participación voluntaria auditable, en lugar de un permiso implícito.

Configuración:

• Las columnas confidenciales se etiquetan con la clave pii (valores permitidos como ssn, email, phone).
• Se concede el rol de acceso denominado role-pii-cleared con la función Assume a los usuarios autorizados para ver datos personales sin procesar.

Función definida por el usuario (UDF) de máscara de columna (estática: la directiva especifica qué entidades deben enmascararse):

CREATE FUNCTION mask_pii(val STRING) RETURNS STRING
DETERMINISTIC
RETURN '***';

Directiva:

CREATE POLICY pii_default_mask
ON CATALOG customer_data
COLUMN MASK mask_pii
TO `account users`
EXCEPT `role-pii-cleared`
FOR TABLES
MATCH COLUMNS has_tag('pii') AS pii_col
ON COLUMN pii_col;

La cláusula EXCEPT excluye por completo a role-pii-cleared de la directiva, por lo que la UDF nunca se invoca cuando ese rol es la identidad activa. Consulte Preferir TO/EXCEPT para la selección de entidades para obtener orientación general sobre la selección de entidades mediante TO / EXCEPT.

Comportamiento:

• Un usuario que actúe con su identidad de usuario ve *** en todas las columnas de PII. Este es el estado predeterminado para todos, incluidos aquellos usuarios con el permiso «Assume» en role-pii-cleared.
• Después de asumir role-pii-cleared, la directiva ya no se aplica a la sesión y el mismo usuario ve los valores sin procesar.
• Las entradas del registro de auditoría de la sesión registran identity_metadata.run_as = role-pii-cleared, de modo que los revisores pueden ver exactamente cuándo se desocultó la PII y quién lo hizo.

Directivas de nivel de confidencialidad que varían según el rol asumido

Los datos se clasifican en niveles de confidencialidad (internal, confidential, restricted). Cada nivel tiene un rol de acceso correspondiente, lo que restricted implica también el acceso a confidential y internal . Una UDF de filtro de fila única controla la visibilidad de las filas comparando el nivel de cada fila con el rol asumido por el usuario.

Configuración:

• Las tablas tienen una sensitivity_level columna etiquetada con la clave sensitivity de etiqueta regulada (valores permitidos: internal, confidential, restricted).
• Tres roles de acceso: role-sens-internal, role-sens-confidential, role-sens-restricted.

UDF de filtro de filas:

CREATE FUNCTION sensitivity_allowed(row_sensitivity STRING) RETURNS BOOLEAN
DETERMINISTIC
RETURN CASE
  WHEN current_user() = 'role-sens-restricted' THEN TRUE
  WHEN current_user() = 'role-sens-confidential' THEN row_sensitivity IN ('internal', 'confidential')
  WHEN current_user() = 'role-sens-internal' THEN row_sensitivity = 'internal'
  ELSE FALSE
END;

Directiva:

CREATE POLICY sensitivity_filter
ON CATALOG corp_data
ROW FILTER sensitivity_allowed
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('sensitivity') AS sens
USING COLUMNS (sens);

Dado que un rol no es miembro de sí mismo, esta UDF compara current_user() con cada nombre de rol en lugar de comprobar la pertenencia con is_account_group_member(). Consulte la nota anterior para saber por qué las pruebas de pertenencia no coinciden con el rol asumido. Consulte Consideraciones de rendimiento sobre las directivas de filtro de fila y máscara de columna para conocer las características de rendimiento de las funciones de identidad en las UDF.

Comportamiento:

• Un usuario que actúa con su identidad de usuario no ve ninguna fila. La rama ELSE FALSE coincide con cualquier cosa que no sea uno de los tres roles. Como en el ejemplo por proyecto anterior, se trata de la denegación predeterminada prevista.
• Suponiendo que role-sens-internal solo revela internal filas.
• Suponiendo que role-sens-confidential muestra filas internal y confidential.
• Suponiendo que role-sens-restricted revela todas las filas.

Los usuarios asumen el nivel más alto que necesitan para la sesión; El filtro excluye automáticamente todo lo que está por encima de ese nivel sin necesidad de que el usuario sepa qué tablas contienen qué clasificaciones.

Atribución de auditoría

Tanto las evaluaciones de directivas ABAC como las consultas subyacentes respetan la atribución RBAC run_as / run_by. Las entradas del registro de auditoría registran identity_metadata.run_by como el usuario de autenticación y identity_metadata.run_as como rol asumido, independientemente de qué directivas de ABAC se aplicaron durante la evaluación. Consulte la referencia de la tabla del sistema del registro de auditoría para obtener el esquema completo del registro de auditoría.

Pasos siguientes

• Acceso exclusivo del modelo: aplique patrones para configurar el acceso exclusivo mediante un grupo local de cuenta o un grupo sincronizado desde Microsoft Entra ID. Consulte Acceso exclusivo del modelo.
• Cambiar de rol: asumir un rol mediante el selector de roles, clústeres en modo de acceso dedicado, la CLI, la API o herramientas de BI de terceros. Consulte Cambiar roles.
• Gestionar los permisos de «Assume»: Conceder o revocar «Assume» a un grupo para que los usuarios puedan adoptar el rol correspondiente. Consulte Administración de permisos en un grupo.
• Revise los conceptos básicos de ABAC: obtenga información sobre cómo funcionan las etiquetas, las directivas y la evaluación de directivas. Consulte Control de acceso basado en atributos en el catálogo de Unity.