Conceitos centrais para controlo de acesso baseado em atributos (ABAC)

Esta página apresenta o ABAC, como utiliza etiquetas governadas, políticas e funções definidas pelo utilizador para controlar que linhas os utilizadores podem ver e como os valores das colunas são apresentados, bem como os 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 este permite entre equipas.

Consulte Controlo de acesso baseado em atributos no Catálogo Unity para uma visão geral de todos os tópicos ABAC, incluindo tutoriais, gestão de políticas, melhores práticas e limitações.

O que é ABAC?

O controlo de acesso baseado em atributos (ABAC) é um modelo dinâmico de controlo de acessos onde as decisões de acesso são baseadas em políticas avaliadas em função dos atributos associados a seguranças. No Unity Catalog, estes atributos são representados através de etiquetas governadas. Estas etiquetas governadas são usadas em condições de política para corresponder a objetos de dados dentro de um determinado âmbito, como um catálogo ou um esquema. Isto permite que uma única política se aplique automaticamente entre múltiplos objetos de dados que cumpram as suas condições.

Por exemplo, uma política ABAC pode mascarar todas as colunas etiquetadas PII para tabelas dentro de esquemas etiquetados HR. À medida que novos objetos de dados são criados e etiquetados, a política aplica-se automaticamente sem exigir definições de política separadas para cada objeto.

O ABAC suporta segurança ao nível de linha e coluna através de políticas de filtro de linha e políticas de máscaras de coluna em tabelas, vistas materializadas e tabelas de streaming. As políticas de filtro de linhas restringem quais as linhas que o utilizador pode ver. As políticas de máscara de coluna controlam como os valores das colunas são apresentados aos utilizadores.

Para uma comparação entre filtros de linha ao nível de tabela e máscaras de coluna, veja Quando usar ABAC vs filtros de linha ao nível de tabela e máscaras de coluna.

Tags controladas

No Unity Catalog, os atributos são implementados como etiquetas governadas. Etiquetas governadas são pares chave-valor definidos ao nível da conta e aplicados a objetos securáveis do Unity Catalog, como catálogos, esquemas, tabelas e colunas, além de objetos de espaço de trabalho. Representam características como sensibilidade, classificação ou domínio de negócio.

Por defeito, as etiquetas herdam dos catálogos e esquemas pais para tabelas, mas não das tabelas para as colunas. Pode sobrescrever etiquetas herdadas a qualquer nível, mas as etiquetas ao nível da coluna devem ser aplicadas diretamente.

Etiquetas governadas podem ser referenciadas em condições de política usando funções incorporadas como has_tag() e has_tag_value(), que verificam se uma dada etiqueta está presente no objeto de dados alvo, seja diretamente ou através de herança de etiquetas.

As etiquetas governadas são definidas ao nível da conta. Isto significa que pode usar a mesma taxonomia de etiquetas em todo o seu património de dados numa conta, incluindo em múltiplas metastores.

Para mais informações, veja Etiquetas Governadas e Aplicar etiquetas a objetos seguros do Unity Catalog.

Policies

As políticas são anexadas a objetos securáveis no Unity Catalog para definir regras de controlo de acesso com base nas condições da etiqueta. Abaixo encontra-se um exemplo:

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 apólice especifica:

• Âmbito: A garantia onde a apólice está anexada, especificada pela ON cláusula. Anexar uma política a um elemento seguro significa que as condições da política são avaliadas para todos os objetos do tipo especificado na cláusula FOR, nesse elemento seguro e todos os seus descendentes.
  • Os âmbitos de política atualmente suportados são CATALOG, SCHEMA, ou TABLE.
  • As tabelas, incluindo as tabelas de streaming e as vistas materializadas, são atualmente o único tipo securável suportado, especificado através da FOR TABLES cláusula.
  • Uma política associada a um catálogo avalia todas as tabelas desse catálogo. Uma política anexada a um esquema é avaliada em relação a todas as tabelas nesse esquema. Uma política anexada a uma tabela avalia apenas contra essa mesma tabela.

• Destinatários: A quem se aplica a apólice e quem está isento. A TO cláusula especifica os utilizadores, grupos ou principais de serviço sujeitos à política. A cláusula opcional EXCEPT exclui princípios específicos desta política.
• Ações: Quer a política aplique um filtro de linha ou uma máscara de coluna. A ação é implementada por uma função definida pelo utilizador (UDF) que define a lógica de filtragem ou máscara. Ver Tipos de Políticas.
• Condições: Expressões baseadas em etiquetas que determinam quais as tabelas ou colunas a que a política se destina. Ver Condições e funções incorporadas.

As políticas são criadas e geridas através da interface ou programaticamente com instruções SQL, como CREATE POLICY, DROP POLICY, SHOW POLICIES, ou DESCRIBE POLICY, APIs REST, SDKs Databricks ou Terraform. Consulte Criar e gerir políticas ABAC para a sintaxe completa e exemplos.

Tipos de política

O ABAC suporta dois tipos de políticas: políticas de filtro por linha e políticas de máscara de coluna. Ambos requerem UDFs para implementar a lógica de filtragem ou máscaras.

Políticas de filtro de linha

As políticas de filtro de linhas restringem que linhas um utilizador pode ver numa tabela com base em valores em colunas identificadas por etiquetas que correspondem às Condições e funções incorporadas. A política faz referência a um UDF que avalia cada linha. As linhas onde a função devolve FALSE são excluídas dos resultados da consulta. Os argumentos são transmitidos à UDF através da USING COLUMNS cláusula.

Exemplo de caso de uso: Para um catálogo de vendas, certifique-se de que a equipa EMEA vê apenas os registos de vendas EMEA em todas as tabelas com uma coluna 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');

Políticas de máscaras em coluna

As políticas de máscaras de coluna controlam que valores um utilizador vê para colunas específicas identificadas por etiquetas que correspondem às Condições e funções incorporadas. A política faz referência a um UDF que recebe o valor da coluna como entrada e devolve o valor original ou uma versão mascarada. O valor da coluna mascarada é atribuído automaticamente como o primeiro argumento da ON COLUMN cláusula, e argumentos adicionais podem ser passados por USING COLUMNS. O tipo de retorno deve corresponder ou ser castável ao tipo de dados da coluna.

Exemplo de caso de uso: Máscara colunas de SSN etiquetadas com pii : ssn para que os utilizadores vejam ***-**-XXXX (apenas nos últimos quatro dígitos), a menos que estejam num grupo de conformidade isento da política.

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 USING COLUMNS cláusula passa os argumentos para a UDF. Aceita pseudónimos para colunas que correspondem a uma expressão baseada em etiquetas, ou valores constantes (cadeias entre aspas, literais numéricos, valores booleanos (TRUE/FALSE), ou NULL), fornecidos na ordem que a função espera. Para políticas de máscaras de coluna, estes são argumentos adicionais para além da coluna mascarada (que é vinculada automaticamente a partir de ON COLUMN). Isto permite que um único UDF seja reutilizado entre políticas com diferentes parâmetros.

Recomenda-se UDFs SQL para melhor desempenho. UDFs Python registados no Catálogo Unity também são suportados, embora o otimizador de consultas não os consiga incorporar diretamente ou otimizar da mesma forma que faz com UDFs SQL. Consulte Considerações de Desempenho para orientações sobre a seleção da língua UDF.

Condições e funções incorporadas

As condições são expressões baseadas em etiquetas que determinam quais as tabelas e colunas que uma política tem como alvo dentro do seu âmbito.

• Condições de tabela (WHEN cláusula): Expressões booleanas que correspondem às tabelas com base nas suas etiquetas. Se omitido, o padrão é TRUE, ou seja, a política aplica-se a todas as tabelas no âmbito definido.
• Condições de coluna (MATCH COLUMNS cláusula): Uma ou mais expressões booleanas separadas por vírgulas que identificam quais as colunas que a política destina. Cada expressão pode ser uma única função incorporada como has_tag('pii'), ou uma combinação usando operadores lógicos como has_tag_value('pii', 'ssn') AND has_tag('sensitive'). Cada expressão pode ser atribuída a um alias (especificado após AS) que pode ser referenciado nas cláusulas ON COLUMN e USING COLUMNS. Uma política pode incluir até 3 expressões de colunas, e todas têm de coincidir para que a política se aplique.

Ambos os tipos de cláusulas utilizam as seguintes funções incorporadas, avaliadas pelo Unity Catalog em relação a metadados securáveis:

As etiquetas não se propagam das tabelas para as colunas. Usar has_tag() numa MATCH COLUMNS cláusula apenas corresponde a etiquetas ao nível da coluna, nem etiquetas na tabela pai ou seus antecessores.

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

1. has_tag_value('pii', 'email') identifica a coluna que contém endereços de email (a coluna para mascarar).
2. has_tag('consent_to_contact') identifica a coluna que contém informações de consentimento (usada pela UDF para decidir se deve mascarar).

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 tenham tanto uma coluna etiquetada pii : email como uma coluna etiquetada 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 devolvidos sem mascaramento.

Funções definidas pelo utilizador (UDFs)

As políticas de filtro de linhas e máscaras de coluna utilizam funções definidas pelo utilizador (UDFs - User-Defined Functions) para implementar a sua lógica de filtragem ou máscara. Consulte Funções definidas pelo utilizador (UDFs) no Unity Catalog para como criar e gerir UDFs, e Padrões comuns para filtragem de linhas e mascaramento de colunas para exemplos.

Separação de deveres e permissões

A criação do ABAC envolve vários passos, cada um com os seus próprios requisitos de permissão. As organizações podem distribuir estas tarefas por grupos especializados dependendo de como escolherem separar as tarefas. Por exemplo, uma organização pode definir uma taxonomia de etiquetas centralmente, depois fazer com que os gestores de dados classifiquem os dados, os administradores de governação escrevam políticas, os criadores de dados criem objetos dentro de escopos governados e os consumidores de dados consultem os resultados.

1. Crie a taxonomia da etiqueta. Defina as chaves de etiquetas governadas e os seus valores permitidos antes de alguém as aplicar ou escrever políticas. Por exemplo, criar uma sensitivity etiqueta com valores controlados (public, internal, confidential, restricted) ou uma pii etiqueta com valores como ssn, email, e phone_number. Consulte Standardize atributos e nomenclatura para recomendações sobre convenções de nomenclatura e design de taxonomia.

   • Permissões necessárias: administrador de conta, ou um utilizador com CREATE permissão para etiquetas ao nível da conta.

2. Etiquetar ativos de dados. Um gestor de dados, criador de dados ou sistema de classificação por IA aplica etiquetas governadas a catálogos, esquemas, tabelas ou colunas. Por exemplo, colunas de etiquetas que contêm informação pessoalmente identificável com pii : ssn. A etiquetagem correta é o primeiro passo essencial para que as políticas ABAC se apliquem.

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

3. Crie uma política. Um administrador de governação cria uma política num âmbito específico, como um catálogo ou esquema. A política especifica a quem se aplica, que condições avalia e o UDF que implementa a lógica de filtragem ou mascaramento.

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

4. Criar objetos de dados. Os criadores de dados criam tabelas dentro dos escopos a que tiveram acesso. Novas tabelas herdam etiquetas de objetos pais, como catálogos e esquemas. Os criadores de dados também têm APPLY TAG automaticamente sobre os objetos que criam, para poderem aplicar etiquetas adicionais. Em alternativa, podem confiar na classificação automática dos dados para tratar da marcação. Se uma organização depende dos criadores de dados para marcar os seus próprios objetos, deve estabelecer práticas claras de marcação. Os criadores de dados não precisam de configurar quaisquer controlos de acesso se as políticas forem definidas em níveis superiores, como o Azure Databricks recomenda.

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

5. Consultar dados Quando um consumidor de dados consulta uma tabela dentro do âmbito da política, a política é avaliada automaticamente. Se a tabela ou colunas corresponderem às condições da política e o utilizador não estiver isento, o consumidor vê dados filtrados ou mascarados.

   • Permissões obrigatórias: Os utilizadores devem receber permissões na tabela, como SELECT, através de uma concessão direta de objetos. As políticas de filtro de linha e mascaramento de coluna do ABAC não concedem permissões diretamente por si só. Só filtram registos ou mascaram colunas para tabelas a que o utilizador já pode aceder.

Benefícios do ABAC

• Apólices reutilizáveis baseadas em atributos: Uma única política pode aplicar-se a múltiplos objetos de dados que correspondam às mesmas condições baseadas em atributos, em vez de estarem ligadas a um objeto específico.

• Aplicação automática a novos objetos: Quando novos objetos de dados são criados dentro do âmbito e etiquetados com os atributos relevantes, as políticas ABAC existentes aplicam-se sem configuração adicional. As políticas funcionam como futuras subvenções, o que significa que os controlos de acesso aplicam-se automaticamente à medida que novos dados são criados e etiquetados adequadamente.

• Aplicação consistente dentro de um determinado âmbito: As políticas associadas ao nível do catálogo ou esquema são avaliadas dinamicamente contra objetos de dados correspondentes nesse âmbito, o que elimina diferenças na forma como dados semelhantes são filtrados ou mascarados.

• Menor manutenção contínua: As alterações podem ser feitas atualizando a lógica de políticas ou etiquetas governadas, em vez de revisitar cada objeto individual, como é exigido com filtros de linhas ao nível de tabela e máscaras de coluna.

• Governação centralizada: Como as políticas podem ser definidas uma vez e aplicadas em muitos objetos de dados correspondentes, as equipas de governação podem gerir controlos em partes maiores do património de dados com menos definições de políticas.

Mais informações

• Tags controladas
• CRIAR POLÍTICA
• Gerenciar privilégios no Catálogo Unity
• Filtros de linha e máscaras de coluna
• Referência da tabela do sistema de registos de auditoria
• Requisitos, quotas e limitações ABAC