Conceptos básicos para el control de acceso basado en atributos (ABAC)

En esta página se presenta ABAC, cómo usa etiquetas, directivas yfunciones definidas por el usuario para controlar qué filas pueden ver y cómo se presentan los valores de columna y sus ventajas. En esta página también se tratan los permisos necesarios para configurar ABAC y la separación de tareas que habilita en todos los equipos.

Consulte Control de acceso basado en atributos en el Catálogo de Unity para obtener información general sobre todos los temas de ABAC, incluidos tutoriales, administración de directivas, procedimientos recomendados y limitaciones.

¿Qué es ABAC?

El control de acceso basado en atributos (ABAC) es un modelo de control de acceso dinámico en el que las decisiones de acceso se basan en directivas evaluadas con atributos asociados a elementos protegibles. En el catálogo de Unity, estos atributos se representan a través de etiquetas reguladas. Estas etiquetas reguladas se usan en condiciones de directiva para buscar coincidencias con objetos de datos dentro de un ámbito determinado, como un catálogo o un esquema. Esto permite que una única directiva se aplique automáticamente en varios objetos de datos que cumplan sus condiciones.

Por ejemplo, una directiva de ABAC podría enmascarar todas las columnas etiquetadas PII para las tablas dentro de esquemas etiquetadas HR. A medida que se crean y etiquetan nuevos objetos de datos, la directiva se aplica automáticamente sin necesidad de definiciones de directiva independientes para cada objeto.

ABAC admite la seguridad de nivel de fila y columna mediante directivas de filtro de fila y directivas de máscara de columna en tablas, vistas materializadas y tablas de streaming. Las directivas de filtro de fila restringen las filas que puede ver un usuario. Las directivas de máscara de columna controlan cómo se presentan los valores de columna a los usuarios.

Para obtener una comparación con los filtros de fila de nivel de tabla y las máscaras de columna, consulte Cuándo usar ABAC frente a filtros de fila de nivel de tabla y máscaras de columna.

Etiquetas reguladas

En el catálogo de Unity, los atributos se implementan como etiquetas reguladas. Las etiquetas reguladas son pares clave-valor definidos en el nivel de cuenta y se aplican a elementos protegibles del catálogo de Unity, como catálogos, esquemas, tablas y columnas, además de objetos del área de trabajo. Representan características como la confidencialidad, la clasificación o el dominio empresarial.

De forma predeterminada, las etiquetas heredan de catálogos primarios y esquemas a tablas, pero no de tablas a columnas. Puede invalidar las etiquetas heredadas en cualquier nivel, pero las etiquetas de nivel de columna deben aplicarse directamente.

Se puede hacer referencia a las etiquetas reguladas en condiciones de directiva mediante funciones integradas como has_tag() y has_tag_value(), que comprueban si una etiqueta determinada está presente en el objeto de datos de destino, ya sea directamente o a través de la herencia de etiquetas.

Las etiquetas reguladas se definen en el nivel de cuenta. Esto significa que puede utilizar la misma taxonomía de etiquetas en todo el entorno de datos de una cuenta, incluyendo en varios metastores.

Para obtener más información, consulte Etiquetas reguladas y Aplicar etiquetas a objetos protegibles del catálogo de Unity.

Directivas

Las directivas se adjuntan a objetos protegibles en el catálogo de Unity para definir reglas de control de acceso basadas en condiciones de etiqueta. A continuación se muestra un ejemplo:

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

CREATE POLICY mask_pii_for_hr
ON CATALOG catalog_a
COLUMN MASK mask_pii
TO `account users` EXCEPT `HR admins`
FOR TABLES
WHEN has_tag('HR')
MATCH COLUMNS has_tag('PII') AS pii_col
ON COLUMN pii_col;

Cada directiva especifica:

• Ámbito: elemento protegible donde se adjunta la directiva, especificada por la ON cláusula . Adjuntar una directiva a un elemento segurizable significa que las condiciones de la directiva se evalúan para todos los objetos del tipo especificado en la cláusula FOR, en ese elemento segurizable y en todos sus descendientes.
  • Los ámbitos de directiva admitidos actualmente son CATALOG, SCHEMAo TABLE.
  • Las tablas, incluidas las tablas de streaming y las vistas materializadas, son actualmente el único tipo protegible admitido, especificado mediante la FOR TABLES cláusula .
  • Una directiva adjunta a un catálogo evalúa contra todas las tablas de ese catálogo. Una política adjunta a un esquema se evalúa en todas las tablas de ese esquema. Una política adjunta a una tabla se evalúa solo en esa tabla.

• Interesados: a quién se aplica la política y quiénes están exentos. La TO cláusula especifica los usuarios, grupos o entidades de servicio sujetos a la directiva. La cláusula opcional EXCEPT excluye principales específicos de esta directiva.
• Acciones: indica si la directiva aplica un filtro de fila o una máscara de columna. La acción se implementa mediante una función definida por el usuario (UDF) que define la lógica de filtrado o enmascaramiento. Consulte Tipos de directiva.
• Condiciones: expresiones basadas en etiquetas que determinan qué tablas o columnas tiene como destino la directiva. Consulte Condiciones y funciones integradas.

Las directivas se crean y administran mediante la interfaz de usuario o mediante programación con instrucciones SQL, como CREATE POLICY, DROP POLICY, SHOW POLICIES, DESCRIBE POLICY, APIs REST, Databricks SDKs o Terraform. Consulte Creación y administración de directivas de ABAC para obtener la sintaxis y ejemplos completos.

Tipos de directivas

ABAC admite dos tipos de directiva: directivas de filtro de fila y directivas de máscara de columna. Ambos requieren UDF para implementar la lógica de filtrado o enmascaramiento.

Políticas de filtro de fila

Las directivas de filtro de fila restringen las filas que un usuario puede ver en una tabla en función de los valores de las columnas identificadas por etiquetas que coincidan con las funciones integradas y condiciones. La directiva hace referencia a una UDF que evalúa cada fila. Las filas en las que la función devuelve FALSE se excluyen de los resultados de la consulta. Los argumentos se pasan a la UDF a través de la USING COLUMNS cláusula .

Caso de uso de ejemplo: Para un catálogo de ventas, asegúrese de que el equipo de EMEA solo ve registros de venta de EMEA en todas las tablas que tienen una columna etiquetada region.

CREATE FUNCTION filter_by_region(region STRING, allowed STRING) RETURNS BOOLEAN
    RETURN region = allowed;

CREATE POLICY regional_access_emea
ON CATALOG sales
ROW FILTER filter_by_region
TO `emea team`
FOR TABLES
MATCH COLUMNS has_tag('region') AS rgn
USING COLUMNS (rgn, 'EMEA');

Directivas de máscara de columna

Las directivas de máscara de columna controlan qué valores ve un usuario para columnas específicas identificadas por etiquetas que coinciden con las funciones integradas y condiciones. La directiva hace referencia a una UDF que toma el valor de columna como entrada y devuelve el valor original o una versión enmascarada. El valor de columna enmascarado se enlaza automáticamente como primer argumento de la ON COLUMN cláusula y se pueden pasar argumentos adicionales a través de USING COLUMNS. El tipo de valor devuelto debe coincidir o ser convertible al tipo de dato de la columna.

Caso de uso de ejemplo: Enmascara las columnas de SSN etiquetadas con pii : ssn para que los usuarios vean ***-**-XXXX (solo los cuatro últimos dígitos) a menos que estén en un grupo de cumplimiento exento de la directiva.

CREATE FUNCTION mask_ssn(ssn STRING, show_last INT) RETURNS STRING
    RETURN CONCAT('***-**-', RIGHT(ssn, show_last));

CREATE POLICY mask_ssn_columns
ON CATALOG hr_catalog
COLUMN MASK mask_ssn
TO `account users` EXCEPT `compliance team`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'ssn') AS ssn_col
ON COLUMN ssn_col
USING COLUMNS (4);

La USING COLUMNS cláusula pasa argumentos a la UDF. Acepta alias para columnas que coinciden con una expresión basada en etiquetas o valores constantes (cadenas entrecomilladas, literales numéricos, valores booleanos (TRUE/FALSE) o NULL), proporcionados en el orden en que la función los espera. Para las directivas de máscara de columna, estos son argumentos adicionales más allá de la columna enmascarada (que se enlaza automáticamente desde ON COLUMN). Esto permite reutilizar una única UDF entre directivas con distintos parámetros.

Se recomiendan UDF de SQL para mejorar el rendimiento. Python UDFs registradas en el catálogo de Unity también se admiten, aunque el optimizador de consultas no puede inlinarlas ni optimizarlas de la manera en que puede optimizarlas los UDFs de SQL. Consulte Consideraciones de rendimiento para obtener instrucciones sobre la selección del lenguaje UDF.

Condiciones y funciones integradas

Las condiciones son expresiones basadas en etiquetas que determinan qué tablas y columnas tiene como destino una directiva dentro de su ámbito.

• Condiciones de tabla (WHEN cláusula): expresiones booleanas que coinciden con tablas basadas en sus etiquetas. Si se omite, el valor predeterminado es TRUE, lo que significa que la directiva se aplica a todas las tablas del ámbito.
• Condiciones de columna (MATCH COLUMNS cláusula): una o varias expresiones booleanas separadas por comas que identifican qué columnas tiene como destino la directiva. Cada expresión puede ser una única función integrada como has_tag('pii')o una combinación mediante operadores lógicos como has_tag_value('pii', 'ssn') AND has_tag('sensitive'). A cada expresión se le puede asignar un alias (especificado después de AS) al que se puede hacer referencia en las cláusulas ON COLUMN y USING COLUMNS. Una directiva puede incluir hasta 3 expresiones de columna y todas deben coincidir para que se aplique la directiva.

Ambos tipos de cláusulas usan las siguientes funciones integradas, evaluadas por Unity Catalog contra los metadatos securables:

Las etiquetas no se propagan de tablas a columnas. Usar has_tag() en una MATCH COLUMNS cláusula solo coincide con las etiquetas de nivel de columna, no con las etiquetas de la tabla principal o sus antecesores.

Ejemplo: uso de condiciones de dos columnas. Un customers esquema tiene tablas con una columna de correo electrónico etiquetada pii : email y una columna de consentimiento etiquetada consent_to_contact. La directiva enmascara las direcciones de correo electrónico a menos que el cliente tenga el consentimiento para ponerse en contacto con él. Usa dos condiciones de columna:

1. has_tag_value('pii', 'email') identifica la columna que contiene direcciones de correo electrónico (la columna que se va a enmascarar).
2. has_tag('consent_to_contact') identifica la columna que contiene información de consentimiento (usada por la UDF para decidir si se debe enmascarar).

CREATE FUNCTION mask_email_by_consent(email STRING, consent BOOLEAN)
RETURNS STRING
RETURN CASE
  WHEN consent = true THEN email
  ELSE '****@****.***'
END;

CREATE POLICY mask_email_with_consent
ON SCHEMA customers
COLUMN MASK mask_email_by_consent
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'email') AS m,
  has_tag('consent_to_contact') AS c
ON COLUMN m
USING COLUMNS (c);

Esta directiva solo se aplica a las tablas que tienen una columna etiquetada pii : email y una columna etiquetada consent_to_contact. Si una tabla no tiene columnas que coincidan con ambas condiciones, la directiva no se aplica y los datos se devuelven sin máscara.

Funciones definidas por el usuario (UDF)

Las directivas de filtro de fila y máscara de columna usan funciones definidas por el usuario (UDF) para implementar su lógica de filtrado o enmascaramiento. Consulte Funciones definidas por el usuario (UDF) en el catálogo de Unity para obtener ejemplos sobre cómo crear y administrar UDF y patrones comunes para el filtrado de filas y el enmascaramiento de columnas .

Separación de tareas y permisos

La configuración de ABAC implica varios pasos, cada uno con sus propios requisitos de permisos. Las organizaciones pueden distribuir estas tareas entre grupos especializados en función de cómo decidan separar las tareas. Por ejemplo, una organización puede definir una taxonomía de etiquetas de forma centralizada, hacer que los administradores de datos clasifiquen los datos, los administradores de gobernanza escriban directivas, los creadores de datos crean objetos dentro de ámbitos regulados y los consumidores de datos consultan los resultados.

1. Cree la taxonomía de etiquetas. Defina las claves de etiqueta reguladas y sus valores permitidos antes de que cualquier usuario los aplique o escriba directivas. Por ejemplo, cree una sensitivity etiqueta con valores controlados (public, internal, confidential, restricted) o una pii etiqueta con valores como ssn, emaily phone_number. Consulte Estandarizar atributos y nomenclatura para obtener recomendaciones sobre convenciones de nomenclatura y diseño de taxonomía.

   • Permisos necesarios: administrador de cuenta o un usuario con CREATE permiso para etiquetas a nivel de cuenta.

2. Etiquetar activos de datos. Un administrador de datos, creador de datos o sistema de clasificación de IA aplica etiquetas reguladas a catálogos, esquemas, tablas o columnas. Por ejemplo, etiquete columnas que contienen información de identificación personal con pii : ssn. El etiquetado correcto es el primer paso esencial para que se apliquen las directivas de ABAC.

   • Permisos necesarios: ASSIGN en la etiqueta y APPLY TAG en el objeto .

3. Creación de una directiva. Un administrador de gobernanza crea una directiva en un ámbito, como un catálogo o un esquema. La directiva especifica a quién se aplica, a qué condiciones evalúa y la UDF que implementa la lógica de filtrado o enmascaramiento.

   • Permisos necesarios: MANAGE permiso o propiedad de objeto en el elemento protegible donde se adjunta la directiva (catálogo, esquema o tabla) y EXECUTE privilegio en la UDF.

4. Cree objetos de datos. Los creadores de datos crean tablas dentro de los ámbitos a los que se les concedió acceso. Las nuevas tablas heredan etiquetas de objetos primarios, como catálogos y esquemas. Los creadores de datos también tienen APPLY TAG automáticamente en los objetos que crean, por lo que pueden aplicar etiquetas adicionales. Como alternativa, pueden confiar en la clasificación automática de datos para controlar el etiquetado. Si una organización se basa en creadores de datos para etiquetar sus propios objetos, debe establecer prácticas de etiquetado claras. Los creadores de datos no necesitan configurar ningún control de acceso si las directivas se establecen en niveles superiores, que Azure Databricks recomienda.

   • Permisos necesarios: CREATE TABLE u otros privilegios de creación pertinentes en el objeto primario.

5. Consulta de datos. Cuando un consumidor de datos consulta una tabla dentro del ámbito de la directiva, la directiva se evalúa automáticamente. Si la tabla o columnas coinciden con las condiciones de la directiva y el usuario no está exento, el consumidor ve los datos filtrados o enmascarados.

   • Permisos necesarios: debemos conceder a los usuarios permisos en la tabla, como SELECT, mediante la concesión directa de objetos. Las directivas de filtrado de filas y enmascaramiento de columnas de ABAC no conceden permisos por sí solas. Solo filtran registros o enmascaran columnas para las tablas a las que un usuario ya puede acceder.

Ventajas de ABAC

• Directivas reutilizables basadas en atributos: Una sola directiva se puede aplicar a varios objetos de datos que coinciden con las mismas condiciones basadas en atributos, en lugar de estar vinculados a un objeto específico.

• Aplicación automática a nuevos objetos: Cuando se crean nuevos objetos de datos dentro del ámbito y se etiquetan con los atributos pertinentes, las directivas de ABAC existentes se aplican sin configuración adicional. Las directivas actúan como concesiones futuras, lo que significa que los controles de acceso se aplican automáticamente a medida que se crean y etiquetan correctamente los nuevos datos.

• Cumplimiento coherente dentro de un ámbito: Las directivas adjuntas en el nivel de catálogo o esquema se evalúan dinámicamente con los objetos de datos coincidentes en ese ámbito, lo que elimina las diferencias en la forma en que se filtran o enmascaran los datos similares.

• Menor mantenimiento continuo: Los cambios se pueden realizar mediante la actualización de la lógica de directiva o las etiquetas reguladas, en lugar de volver a visitar cada objeto individual, tal como se requiere con filtros de fila de nivel de tabla y máscaras de columna.

• Gobernanza centralizada: Dado que las directivas se pueden definir una vez y aplicarse en muchos objetos de datos coincidentes, los equipos de gobernanza pueden administrar controles en partes más grandes del patrimonio de datos con menos definiciones de directiva.

Más información

• Etiquetas gobernadas
• CREATE POLICY
• Administración de privilegios en el catálogo de Unity
• Filtros de fila y máscaras de columna
• Referencia de la tabla del sistema de registro de auditoría
• Requisitos, cuotas y limitaciones de ABAC