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

El control de acceso basado en atributos (ABAC) es un modelo de control de acceso que usa etiquetas y directivas reguladas para conceder permisos basados en atributos de objeto en lugar de concesiones por objeto. En esta página se definen los componentes básicos: las etiquetas gobernadas, los tres tipos de directivas ABAC (filtro de filas, enmascaramiento de columnas y directivas GRANT), los permisos necesarios para configurarlas y la segregación de funciones que ABAC permite entre 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 objetos 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.

ABAC también admite la concesión dinámica de privilegios mediante GRANT directivas, en los tipos de elementos protegibles compatibles. Consulta las políticas de ABACGRANT.

Etiquetas reguladas

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

De forma predeterminada, los elementos protegibles heredan etiquetas de su esquema o catálogo primario. Puede invalidar las etiquetas heredadas en todos los niveles excepto el nivel de columna: las etiquetas de columna no heredan de la tabla primaria y se deben aplicar 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: objeto protegible donde se adjunta la directiva, especificada por la ON cláusula . Asociar una directiva a un objeto protegible significa que las condiciones de la directiva se evalúan para todos los objetos del tipo especificado en la cláusula FOR, tanto para ese objeto como para todos sus descendientes.
  • En el caso de las directivas de filtro de fila y máscara de columna, los ámbitos de directiva admitidos son CATALOG, SCHEMAo TABLE. Para GRANT políticas, los ámbitos de política apoyados son CATALOG y SCHEMA.
  • Las tablas, incluidas las tablas de streaming y las vistas materializadas, son el único tipo de objeto protegible compatible para las políticas de filtro de filas y de enmascaramiento de columnas, especificadas mediante la cláusula FOR TABLES. GRANT las políticas se aplican a modelos, servicios modelo, servicios de proveedor modelo, servicios MCP y servicios de agente, y utilizan la GRANT <privilege> FOR <securable_type> cláusula. Para la lista completa de tipos y privilegios de seguros soportados, véase Tipos y privilegios de seguros soportados.
  • Una política adjunta a un catálogo se evalúa con respecto a todos los elementos protegibles del tipo especificado en la cláusula FOR de ese catálogo. Una directiva adjunta a un esquema se evalúa con respecto a todos los elementos protegibles de ese tipo dentro de dicho esquema. Una directiva asociada a una tabla se aplica únicamente a esa tabla.

• Sujetos: A quiénes se aplica la directiva 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 a sujetos específicos de esta directiva.
• Acciones: indica si la directiva aplica un filtro de fila, una máscara de columna o una concesión de privilegios. Las directivas de filtro de fila y máscara de columna usan una función definida por el usuario (UDF) para implementar la lógica de filtrado o enmascaramiento. GRANT Las directivas no utilizan UDF. 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 tres tipos de políticas: políticas de filtro de filas, políticas de enmascaramiento de columnas y políticas de GRANT. Las directivas de filtro de fila y máscara de columna requieren UDF para implementar la lógica de filtrado o enmascaramiento. GRANT Las directivas no usan UDF y, en su lugar, conceden privilegios cuando su condición basada en etiquetas coincide con los atributos del objeto de destino.

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 cláusula USING COLUMNS.

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 cláusula USING COLUMNS 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. También acepta funciones de introspección de etiquetas, que extraen el valor de una etiqueta en el momento de la consulta y la pasan a la UDF. 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. También se admiten las UDF de Python registradas en Unity Catalog, aunque el optimizador de consultas no puede integrarlas ni optimizarlas de la misma forma que lo hace con las UDF de SQL. Consulte Consideraciones de rendimiento para obtener instrucciones sobre la selección del lenguaje UDF.

GRANT políticas

GRANT las directivas conceden dinámicamente un privilegio de Catálogo de Unity cuando su condición basada en etiquetas coincide con las etiquetas de un objeto protegible. Cada vez que un usuario intenta tener acceso a un objeto protegible, el Catálogo de Unity identifica todas las GRANT directivas cuyo ámbito cubre el objeto, comprueba si el usuario está en la TO lista y no en la EXCEPT lista y evalúa la condición de WHEN la directiva con respecto a las etiquetas del elemento protegible, incluidas las etiquetas heredadas. Si se aplica la directiva, Unity Catalog concede el privilegio. GRANT las directivas usan el mismo modelo de evaluación que las directivas de filtro de fila y máscara de columna, salvo que no usan UDF. La condición se expresa en línea en la definición de directiva.

Los privilegios efectivos de un objeto son la unión de concesiones directas y cualquier directiva aplicable GRANT. Una entidad tiene el privilegio si una directiva GRANT dentro del ámbito se aplica a dicha entidad o si se aplica un GRANT directo del mismo privilegio. Las directivas GRANT solo añaden acceso. No pueden revocar el acceso que se concedió directamente.

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:

Para coincidir con los atributos del usuario que ejecuta la consulta en lugar de en etiquetas de recursos, véase Funciones de atributos de identidad.

Para realizar una coincidencia en el contexto de una solicitud, como la aplicación que realiza la llamada, consulte Funciones de atributos de contexto.

Las etiquetas no se propagan de tablas a columnas. El uso de has_tag() en una cláusula MATCH COLUMNS solo coincide con etiquetas a nivel de columna, no con etiquetas de la tabla principal ni de sus antecesoras.

Ejemplo: uso de dos condiciones de columna. 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. Utiliza 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 de atributo de identidad (Beta)

Las funciones de atributos de identidad evalúan propiedades del usuario que ejecuta la consulta, como departamento, país o rol laboral. Estos atributos pueden ser provisionados desde tu proveedor de identidad y referenciados directamente en las condiciones de la póliza. Esto permite expresar condiciones más flexibles sin crear grupos separados para cada combinación de propiedades de identidad. Cuando la información de identidad cambia en tu proveedor de identidad, las políticas utilizan los valores actualizados de los atributos, igual que usan la membresía actualizada en grupos.

Estas funciones se admiten en la cláusula WHEN de las directivas de enmascaramiento de columnas.

Ten en cuenta el siguiente comportamiento cuando escribas políticas que las utilicen:

• Un atributo que falta se resuelve a false. Si el usuario no tiene valor para el atributo, no tiene ningún tipo de atributos o el atributo no existe, la función devuelve false en lugar de generar un error. Condiciones de frase para que este false resultado restrinja el acceso. Véase Condiciones de atributo de identidad.
• Las claves y los valores de los atributos distinguen entre mayúsculas y minúsculas y se comparan de forma exacta: Finance y finance no coinciden.
• Los cambios de atributo no son instantáneos. Los cambios en tu proveedor de identidad no se sincronizan inmediatamente con Azure Databricks. Consulta atributos de identidad para más información.

Para los atributos que soporta Azure Databricks y cómo están provisionados, véase atributos de identidad. Para ver ejemplos de cómo usar atributos de identidad en políticas, consulte Enmascarar una columna en función de los atributos del usuario que realiza la consulta.

Funciones de atributos contextuales (Beta)

Los atributos de contexto se utilizan para restringir el acceso a los datos de solicitudes realizadas en nombre del usuario a través de una aplicación OAuth. Esta configuración puede usarse para restringir el acceso a los agentes a los datos cuando actúan en nombre de un usuario, manteniendo esos mismos datos accesibles si el usuario los consulta directamente en el espacio de trabajo.

Cubre cualquier aplicación OAuth, ya sea una aplicación integrada como la CLI de Azure Databricks o una app OAuth personalizada. Existen dos atributos contextuales diferentes:

• request.is_on_behalf_of: la cuerda 'true' o 'false'. Indica si la solicitud se ejecuta en nombre de un usuario a través de una aplicación OAuth. Cualquier solicitud de una app OAuth tiene este valor configurado como 'true'.
• request.client_id: el ID de cliente OAuth. Esto puede usarse para dirigirse a un cliente OAuth específico, ya sea una app OAuth integrada (por ejemplo, databricks-cli) o una app OAuth personalizada. El client_id se puede ver en la página Conexiones de la aplicación de la consola de la cuenta. En el caso de Databricks Apps, también se puede consultar en la página de detalles de Autorización de la aplicación, en ID de cliente de la aplicación OAuth2. O bien, puede consultarse desde el identity_metadata.acting_resource campo de los registros de auditoría.

Estos atributos no son modificables por el usuario y son proporcionados explícitamente por el sistema; Un llamante solo les influye por cómo se autentican. Estos atributos pueden usarse para identificar agentes externos, no agentes Genie.

Los atributos de contexto pueden usarse mediante las siguientes funciones:

Las claves de los atributos no distinguen entre mayúsculas y minúsculas, mientras que los valores sí lo hacen.

Para aprender a usar estos atributos de contexto para controlar el acceso desde agentes externos, véase Restringir el acceso para agentes externos que actúan en nombre de un usuario.

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 las funciones definidas por el usuario (UDF) de SQL y Python en Unity Catalog para obtener información sobre cómo crear y administrar UDFs, y Patrones comunes para el filtrado de filas y el enmascaramiento de columnas para ver ejemplos.

Funciones de introspección de etiquetas

Las funciones de introspección de etiquetas extraen el valor de una etiqueta regulada y la pasan a una UDF a través de la USING COLUMNS cláusula . Dado que la UDF recibe el valor de etiqueta como argumento, una única directiva y UDF pueden controlar varios valores de etiqueta, en lugar de requerir una directiva independiente para cada valor de etiqueta. Estas funciones solo están disponibles para las directivas de filtro de fila y máscara de columna, ya que GRANT las directivas no usan UDF.

La creación de una directiva que use estas funciones requiere Databricks Runtime 18 LTS o superior. Este requisito solo se aplica a la creación de directivas, no a consultar las tablas reguladas.

En el momento de la consulta, Unity Catalog evalúa estas funciones en función de las etiquetas de la tabla o de las columnas a las que se aplica la directiva: get_tag_value() lee de la tabla que cumple la condición WHEN y get_column_tag_value() lee de las columnas identificadas por MATCH COLUMNS. Solo pueden aparecer en la cláusula USING COLUMNS, no en las condiciones WHEN o MATCH COLUMNS.

Ambas funciones aceptan la clave de la etiqueta como una cadena literal. La etiqueta debe ser una etiqueta regulada y get_column_tag_value() debe hacer referencia a un alias que exista en la cláusula de MATCH COLUMNS la directiva. Si la etiqueta no se rige o el alias no es válido, se produce un error en la creación de directivas. Si una etiqueta a la que se hace referencia ya no se rige cuando se ejecuta una consulta, las consultas en las tablas de destino de la directiva producirán un error en tiempo de ejecución.

Ejemplo: una directiva para todos los tipos de PII

Sin la introspección de etiquetas, enmascarar cada tipo de información de identificación personal (correo electrónico, SSN, teléfono) requiere una directiva independiente y UDF para cada valor de etiqueta. Con get_column_tag_value(), una única directiva pasa el valor de la etiqueta pii de la columna coincidente a una UDF. La UDF se ramifica según ese valor:

CREATE FUNCTION mask_pii(col STRING, pii_type STRING)
RETURNS STRING
RETURN CASE
  WHEN pii_type = 'email' THEN regexp_replace(col, '(^[^@]+)', '***')
  WHEN pii_type = 'ssn' THEN '***-**-' || right(col, 4)
  WHEN pii_type = 'phone' THEN '***-***-' || right(col, 4)
  ELSE col
END;

CREATE POLICY mask_all_pii
ON CATALOG main
COLUMN MASK mask_pii
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('pii') AS col
ON COLUMN col
USING COLUMNS (get_column_tag_value(col, 'pii'));

Para cada columna enmascarada, get_column_tag_value(col, 'pii') se resuelve como el valor de la etiqueta pii de esa columna (email, ssn, phone, etc.), y mask_pii aplica la transformación correspondiente. Un nuevo valor de etiqueta solo requiere una nueva rama en la UDF, no una nueva directiva.

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 acceden a los objetos regulados.

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 objetos protegibles del Catálogo de Unity, como catálogos, esquemas, tablas, columnas, modelos y volúmenes. Por ejemplo, etiquete columnas que contienen información de identificación personal con pii : ssn, o etiquete un modelo con lifecycle : production. 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 política especifica a quién se aplica, qué condiciones evalúa y la acción aplicable, como un filtro de fila, una máscara de columna o un otorgamiento de privilegios.

   • Permisos necesarios: permiso MANAGE o propiedad del objeto sobre el objeto protegible al que se aplica la directiva. Para las directivas de filtro de filas y máscara de columnas, también se requiere el privilegio EXECUTE sobre la UDF.

4. Cree objetos de datos. Los creadores de datos crean objetos protegibles, como tablas, modelos o volúmenes dentro de los ámbitos a los que se les concedió acceso. Los nuevos objetos heredan etiquetas de los catálogos y esquemas primarios. 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. Obtener acceso a objetos regulados. Cuando un usuario intenta acceder a un objeto protegible dentro del ámbito de una directiva, El catálogo de Unity evalúa automáticamente las directivas aplicables. En el caso de las directivas de filtro de fila y máscara de columna, el usuario ve datos filtrados o enmascarados si la tabla o las columnas coinciden con las condiciones de la directiva y el usuario no está exento. Para políticas GRANT , el usuario obtiene el privilegio concedido si las condiciones coinciden y el usuario está en TO y no en EXCEPT.

   • Permisos necesarios: para las directivas de filtro de filas y máscara de columnas, se deben conceder a los usuarios permisos sobre la tabla, como SELECT, mediante una concesión directa de objetos. Estas políticas filtran registros o enmascaran columnas de las tablas a las que el usuario ya puede acceder. No conceden permisos por sí mismos. GRANT Las políticas conceden por sí mismas el privilegio y se combinan con cualquier concesión directa sobre el mismo elemento protegible.

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.

Recursos adicionales

• Etiquetas gobernadas
• CREAR DIRECTIVA
• 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 para las directivas de filtro de fila y máscara de columna