Conceitos básicos para controle de acesso baseado em atributos (ABAC)

Esta página apresenta o ABAC, como ele usa tags controladas , políticas e funções definidas pelo usuário para controlar quais linhas os usuários podem ver e como os valores das colunas são apresentados, além de seus benefícios. Esta página também aborda as permissões necessárias para configurar o ABAC e a separação de funções que ele possibilita entre as equipes.

Consulte para obter Unity Catalog uma visão geral de todos os tópicos sobre ABAC, incluindo tutoriais, gerenciamento de políticas, práticas recomendadas e limitações.

O que é ABAC?

O controle de acesso baseado em atributos (ABAC) é um modelo de controle de acesso dinâmico em que as decisões de acesso são baseadas em políticas avaliadas em relação a atributos associados a objetos protegíveis. No Unity Catalog, esses atributos são representados por meio de tags gerenciadas. Essas tags regulamentadas são usadas em condições de política para corresponder a objetos de dados dentro de um escopo específico, como um catálogo ou um esquema. Isso permite que uma única política seja aplicada automaticamente a vários objetos de dados que atendam às suas condições.

Por exemplo, uma política ABAC pode mascarar todas as tags de coluna PII para tabelas dentro de tags de esquema HR. À medida que novos objetos de dados e tags são criados, a política é aplicada automaticamente, sem a necessidade de definições de política separadas para cada objeto.

O ABAC oferece suporte à segurança em nível de linha e coluna por meio de políticas de filtro de linha e políticas de máscara de coluna em tabelas, visualizações materializadas e tabelas de transmissão. As políticas de filtro de linhas restringem quais linhas um usuário pode visualizar. As políticas de máscara de coluna controlam como os valores das colunas são apresentados aos usuários.

Para uma comparação com filtros de linha e máscaras de coluna em nível de tabela, consulte Quando usar ABAC em vez de filtros de linha e máscaras de coluna em nível de tabela.

tagsregulamentadas

No Unity Catalog, os atributos são implementados como tags controladas. tags governadas são pares de key-valor definidos no nível account e aplicados a objetos protegíveis Unity Catalog , como catálogos, esquemas, tabelas e colunas, além de objetos workspace . Representam características como sensibilidade, classificação ou domínio de negócios.

Por default, tags são herdadas dos catálogos e esquemas pai para as tabelas, mas não das tabelas para as colunas. Você pode sobrescrever tags herdadas em qualquer nível, mas as tags de nível de coluna devem ser aplicadas diretamente.

tags governadas podem ser referenciadas nas condições da política usando funções integradas como has_tag() e has_tag_value(), que verificam se uma determinada tag está presente no objeto de dados de destino, seja diretamente ou por meio de herança tag .

tags controladas são definidas no nível account . Isso significa que você pode usar a mesma taxonomia tag em todos os seus dados em uma account, inclusive em vários metastores.

Para obter mais informações, consulte tagsregidas e Aplicar tags a objetos protegíveis Unity Catalog.

Políticas

As políticas são associadas a objetos protegíveis no Unity Catalog para definir regras de controle de acesso com base nas condições tag . Segue abaixo um exemplo:

SQL

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 política especifica:

• Escopo : O objeto protegível ao qual a política está anexada, especificado pela cláusula ON . Anexar uma política a um objeto protegível significa que as condições da política são avaliadas para todos os objetos do tipo especificado na cláusula FOR , nesse objeto e em todos os seus descendentes.
  • Os escopos de política suportados atualmente são CATALOG, SCHEMA ou TABLE.
  • As tabelas, incluindo tabelas de transmissão e visão materializada, são atualmente o único tipo de objeto protegível suportado, especificado usando a cláusula FOR TABLES .
  • Uma política associada a um catálogo é avaliada em relação a todas as tabelas desse catálogo. Uma política associada a um esquema é avaliada em todas as tabelas desse esquema. Uma política associada a uma tabela é avaliada apenas em relação a essa tabela.

nota

A Databricks recomenda anexar políticas no nível mais alto aplicável, geralmente o catálogo, para maximizar a eficiência da governança. Consulte as Melhores práticas para políticas ABAC.

• Principais : A quem a política se aplica e quem está isento. A cláusula TO especifica os usuários, grupos ou entidade de serviço sujeitos à política. A cláusula opcional EXCEPT exclui princípios específicos desta política.
• Ações : Indica se a política aplica um filtro de linha ou uma máscara de coluna. A ação é implementada por uma função definida pelo usuário (UDF) que define a lógica de filtragem ou mascaramento. Consulte Tipos de política.
• Condições : expressões baseadas em tags que determinam quais tabelas ou colunas a política visa. Consulte Condições e funções integradas.

As políticas são criadas e gerenciadas por meio da interface do usuário ou programaticamente com instruçõesSQL, como CREATE POLICY, DROP POLICY, SHOW POLICIES ou DESCRIBE POLICY, APIsREST, SDKsDatabricks ou Terraform. Consulte Criar e gerenciar políticas ABAC para obter a sintaxe completa e exemplos.

Tipos de política

O ABAC suporta dois tipos de políticas: políticas de filtro de linha e políticas de máscara de coluna. Ambas requerem UDFs (Funções Definidas pelo Usuário) para implementar a lógica de filtragem ou mascaramento.

Políticas de filtro de linha

As políticas de filtro de linhas restringem quais linhas um usuário pode ver em uma tabela com base em valores em colunas identificadas por tags que correspondem às Condições e funções integradas. A política faz referência a uma UDF (função definida pelo usuário) que avalia cada linha. As linhas em que a função retorna FALSE são excluídas dos resultados da consulta. Os argumentos são passados para a UDF através da cláusula USING COLUMNS .

Exemplo de caso de uso: Para um catálogo de vendas, garantir que a equipe EMEA veja apenas registros de vendas da EMEA em todas as tabelas que têm uma coluna tags region.

SQL

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');

Políticas de máscara de coluna

As políticas de máscara de coluna controlam quais valores um usuário vê para colunas específicas identificadas por tags que correspondem às Condições e funções integradas. A política faz referência a uma UDF (função definida pelo usuário) que recebe o valor da coluna como entrada e retorna o valor original ou uma versão mascarada. O valor da coluna mascarada é vinculado automaticamente como o primeiro argumento da cláusula ON COLUMN , e argumentos adicionais podem ser passados através de USING COLUMNS. O tipo de retorno deve corresponder ou ser convertível para o tipo de dados da coluna.

Exemplo de caso de uso: Mascarar as tags das colunas do SSN com pii : ssn para que os usuários vejam ***-**-XXXX (apenas os últimos quatro dígitos), a menos que pertençam a um grupo compliance isento da política.

SQL

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);

A cláusula USING COLUMNS passa argumentos para a UDF. Aceita aliases para colunas que correspondem a uma expressão baseada em tag , ou valores constantes ( strings entre aspas, literais numéricos, valores booleanos (TRUE/FALSE) ou NULL), fornecidos na ordem que a função espera. Para políticas de máscara de coluna, estes são argumentos adicionais além da coluna mascarada (que é vinculada automaticamente a partir de ON COLUMN). Isso permite que uma única UDF seja reutilizada em políticas com parâmetros diferentes.

Recomenda-se o uso de UDFs SQL para melhor desempenho. As UDFs em Python registradas no Unity Catalog também são suportadas, embora o otimizador de consultas não consiga incorporá-las ou otimizá-las da mesma forma que faz com as UDFs em SQL. Consulte a seção Considerações sobre desempenho para obter orientações sobre a seleção da linguagem UDF.

Condições e funções integradas

As condições são expressões baseadas em tagque determinam quais tabelas e colunas uma política abrange em seu escopo.

• Condições de tabela (cláusula WHEN ): expressões Boolean que correspondem a tabelas com base em suas tags. Se omitido, o padrão é TRUE, o que significa que a política se aplica a todas as tabelas no escopo.
• Condições de coluna (cláusula MATCH COLUMNS ): Uma ou mais expressões booleanas separadas por vírgulas que identificam quais colunas a política visa. Cada expressão pode ser uma única função integrada como has_tag('pii') ou uma combinação usando operadores lógicos como has_tag_value('pii', 'ssn') AND has_tag('sensitive'). A cada expressão pode ser atribuído um alias (especificado após AS) que pode ser referenciado nas cláusulas ON COLUMN e USING COLUMNS . Uma política pode incluir expressões de até 3 colunas, e todas devem corresponder para que a política seja aplicada.

Ambos os tipos de cláusula utilizam as seguintes funções integradas, avaliadas pelo Unity Catalog em relação aos metadados protegíveis:

Função	Contexto	Descrição
has_tag('tag_name')	Tabelas e colunas	Retorna verdadeiro se o recurso possuir a tag especificada. Nas condições da tabela (WHEN), verifica as tags definidas diretamente na tabela ou herdadas de um catálogo ou esquema pai. Nas condições de coluna (MATCH COLUMNS), verifica apenas as tags definidas diretamente na coluna — não corresponde às tags da tabela.
has_tag_value('tag_name', 'tag_value')	Tabelas e colunas	Retorna verdadeiro se o recurso tiver a tag especificada com o valor especificado. Mesmo comportamento de contexto que has_tag().

As tags não se propagam das tabelas para as colunas. O uso de has_tag() em uma cláusula MATCH COLUMNS corresponde apenas a tags de nível de coluna, não a tags na tabela pai ou em seus ancestrais.

nota

As funções has_tag e has_tag_value usam nomes snake_case. As formas camelCase mais antigas (hasTag, hasTagValue) continuam a funcionar, mas não são recomendadas. A Databricks planeja descontinuar o uso de formulários em camelCase na criação de novas políticas. As políticas existentes não serão afetadas.

Exemplo: usando condições de duas colunas. Um esquema customers possui tabelas com uma coluna email com tags pii : email e uma coluna de consentimento com tags consent_to_contact. A política oculta os endereços email , a menos que o cliente tenha consentido em ser contatado. Utiliza duas condições de coluna:

1. has_tag_value('pii', 'email') Identifica a coluna que contém endereços email (a coluna a ser mascarada).
2. has_tag('consent_to_contact') Identifica a coluna que contém informações de consentimento (usadas pela UDF para decidir se deve ou não mascarar os dados).

SQL

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 política aplica-se apenas a tabelas que têm uma coluna com a etiqueta pii : email e uma coluna com a etiqueta consent_to_contact. Se uma tabela não tiver colunas que correspondam a ambas as condições, a política não se aplica e os dados são retornados sem máscara.

Funções definidas pelo usuário (UDFs)

As políticas de filtro de linha e máscara de coluna usam funções definidas pelo usuário (UDFs) para implementar sua lógica de filtragem ou mascaramento. Consulte Funções definidas pelo usuário (UDFs) no Unity Catalog para saber como criar e gerenciar UDFs e Padrões comuns para filtragem de linhas e mascaramento de colunas para ver exemplos.

Separação de funções e permissões

A configuração do ABAC envolve várias etapas, cada uma com seus próprios requisitos de permissão. As organizações podem distribuir essas tarefas entre grupos especializados, dependendo de como optarem por separar as funções. Por exemplo, uma organização pode definir uma taxonomia tag centralmente, e então a gestão de dados classifica os dados, os administradores escrevem políticas, os criadores de dados criam objetos dentro dos escopos governados e os consumidores de dados consultam os resultados.

1. Crie a taxonomia tag . Defina a chave tag governada e seus valores permitidos antes que alguém as aplique ou escreva políticas. Por exemplo, crie uma tag sensitivity com valores controlados (public, internal, confidential, restricted) ou uma tag pii com valores como ssn, email e phone_number. Consulte a seção Padronizar atributos e nomenclatura para obter recomendações sobre convenções de nomenclatura e design de taxonomia.

   • Permissões necessárias: administrador da conta ou um usuário com permissão CREATE para tags no nível account .

2. dados de tag ativos. Uma gestão de dados, criador de dados ou sistema de classificação AI aplica tags governadas a catálogos, esquemas, tabelas ou colunas. Por exemplo, tag as colunas que contêm informações de identificação pessoal com pii : ssn. A correção correta das tags é o primeiro passo essencial para que as políticas ABAC sejam aplicadas.

   • Permissões necessárias: ASSIGN na tag e APPLY TAG no objeto.

atenção

As tags representam um limite de segurança. Se um usuário puder alterar as tags de um ativo de dados, ele poderá alterar quais políticas se aplicam a ele. As organizações devem controlar quem pode aplicar tags e auditar as alterações tag .

3. Criar uma política. Um administrador de governança cria uma política em um escopo, como um catálogo ou esquema. A política especifica a quem se aplica, quais condições avalia e a UDF que implementa a lógica de filtragem ou mascaramento.

   • Permissões necessárias: permissão MANAGE ou propriedade do objeto no objeto protegível onde a política está anexada (catálogo, esquema ou tabela) e privilégio EXECUTE na UDF.

4. Criar objetos de dados. Os criadores de dados criam tabelas dentro dos escopos aos quais lhes foi concedido acesso. As novas tabelas herdam tags de objetos pai, como catálogos e esquemas. Os criadores de dados também têm APPLY TAG automaticamente nos objetos que criam, para que possam aplicar tags adicionais. Alternativamente, podem recorrer à classificação automática de dados para lidar com as etiquetas. Se uma organização depende dos criadores de dados para tag seus próprios objetos, ela deve estabelecer práticas claras de etiquetagem. Os criadores de dados não precisam configurar nenhum controle de acesso se as políticas forem definidas em níveis mais altos, conforme recomendado pela Databricks.

   • Permissões necessárias: CREATE TABLE ou outros privilégios de criação relevantes no objeto pai.

5. Dados da consulta. Quando um consumidor de dados consulta uma tabela dentro do escopo da política, a política é avaliada automaticamente. Se a tabela ou as colunas corresponderem às condições da política e o usuário não for isento, o consumidor verá dados filtrados ou mascarados.

   • Permissões necessárias: Os usuários devem receber permissões na tabela, como SELECT, por meio de uma concessão de objeto direto. As políticas de filtro de linha e mascaramento de coluna do ABAC não concedem permissões por si só. Eles filtram apenas registros ou mascaram colunas para tabelas às quais o usuário já tem acesso.

Benefícios do ABAC

• Políticas reutilizáveis baseadas em atributos: Uma única política pode ser aplicada a vários objetos de dados que correspondam às mesmas condições baseadas em atributos, em vez de estar vinculada a um objeto específico.

• Aplicação automática a novos objetos: Quando novos objetos de dados são criados dentro do escopo e marcados com os atributos relevantes, as políticas ABAC existentes são aplicadas sem configuração adicional. As políticas funcionam como concessões futuras, o que significa que os controles de acesso são aplicados automaticamente à medida que novos dados são criados e etiquetados adequadamente.

• Aplicação consistente dentro de um escopo: as políticas anexadas no nível do catálogo ou do esquema são avaliadas dinamicamente em relação aos objetos de dados correspondentes nesse escopo, o que elimina as diferenças na forma como dados semelhantes são filtrados ou mascarados.

• Redução da necessidade de manutenção contínua: as alterações podem ser feitas atualizando a lógica da política ou as tags regulamentadas, em vez de revisar cada objeto individualmente, como é necessário com filtros de linha em nível de tabela e máscaras de coluna.

• Governança centralizada: Como as políticas podem ser definidas uma única vez e aplicadas a vários objetos de dados correspondentes, as equipes de governança podem gerenciar controles em partes maiores do conjunto de dados com menos definições de políticas.

Mais informações

• tagsregulamentadas
• CRIAR POLÍTICA
• Consulte Gerenciar privilégios no Unity Catalog
• Filtros de linha e máscaras de coluna
• Referência da tabela do sistema de logs de auditoria
• Requisitos, quotas e limitações do ABAC