Uso de RBAC con ABAC

Importante

RBAC está en versión preliminar pública. ABAC está disponible con carácter general. En esta página se describe cómo funcionan las dos juntas.

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:

Function	Cuando el usuario actúa con su identidad de usuario	Cuando el usuario asume un rol
current_user()	Devuelve el nombre de usuario del usuario.	Devuelve el nombre del rol asumido.
is_member(group)	Devuelve true si el usuario es miembro del grupo (un grupo local del área de trabajo o un grupo de cuentas asignado al área de trabajo).	Devuelve true solo si el rol asumido forma parte de group. Devuelve false para los grupos de los que el usuario subyacente es miembro, pero el rol asumido no lo es.
is_account_group_member(group)	Devuelve true si el usuario es miembro del grupo de nivel de cuenta	Igual que is_member: devuelve true basándose únicamente en la pertenencia a grupos del rol asumido, no en la del usuario subyacente.

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 políticas ABAC, la resolución de concesiones de Unity Catalog y la atribución en auditoría. 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.

Note

Un rol no es automáticamente miembro de sí mismo. Cuando un usuario asume el rol de G, current_user() devuelve G, pero is_member('G') y is_account_group_member('G') devuelven false a menos que G se haya añadido explícitamente como miembro de sí mismo. Para buscar coincidencias con el rol asumido en una directiva, compare con current_user() en lugar de probar la pertenencia con is_member o is_account_group_member.

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 de nivel de tabla consiste en filtrar filas uniéndolas con una tabla de aprovisionamiento (también denominada tabla de asignación 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

Trate el rol como otro principal en sus datos de aprovisionamiento: inserta una fila por cada rol con los centros (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 tienen el permiso para asumir solo en 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 dirigidas a entidades de seguridad, como TO / EXCEPT, no pueden expresarlo, ya que estas se dirigen a entidades de seguridad, no al contenido de la fila. Como explica la guía dirigida al principal, prefiera TO / EXCEPT para una delimitación sencilla del principal y reserve las funciones de identidad dentro de una UDF para casos como este, en los que una sola 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. Cambiar a role-beta sustituye los datos visibles sin 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, un usuario debe adoptar explícitamente un rol designado autorizado para acceder a información de identificación personal. Los registros de auditoría registran el evento de asunción de rol, por lo que «Necesitaba consultar PII real» se convierte en una adhesión explícita 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 a los usuarios autorizados para ver datos PII sin procesar un rol de acceso denominado role-pii-cleared Assume.

Función UDF de enmascaramiento de columna (estática: la directiva especifica qué entidades de seguridad se deben enmascarar):

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 EXCEPT cláusula excluye role-pii-cleared por completo de la directiva, por lo que la UDF nunca se invoca cuando ese rol es la identidad activa. Consulte Se prefieren TO/EXCEPT para la selección de entidades de seguridad para obtener la guía general sobre la selección de entidades de seguridad mediante TO / EXCEPT.

Comportamiento:

• Un usuario que actúa con su propia identidad de usuario ve *** en cada columna 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 grabación de la sesión identity_metadata.run_as = role-pii-cleared, para que los revisores puedan ver exactamente cuándo se desenmascararon los datos PII y por quién.

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 una sola fila 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 de ABAC como las consultas subyacentes respetan la atribución de 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.