Quando usar ABAC vs filtros de linhas ao nível de tabela e máscaras de colunas

O Unity Catalog suporta duas abordagens para segurança ao nível de linha e a nível de coluna: políticas ABAC e filtros de linhas ao nível de tabela e máscaras de coluna. Nenhuma das abordagens concede acesso a dados por si só — ambas acrescentam restrições aos privilégios existentes ao nível do objeto. Deve conceder acesso à tabela base separadamente através de permissões a nível de objeto (GRANT).

A diferença central está onde as restrições são definidas. Filtros de linha ao nível de tabela e máscaras de coluna aplicam controlos de sensibilidade diretamente em tabelas individuais usando ALTER TABLE. Os proprietários de tabelas gerem a sua própria proteção de dados sem necessidade de um sistema de etiquetas regulado. Isto é simples para um pequeno número de tabelas, mas cada tabela tem de ser configurada individualmente, e os proprietários de tabelas podem modificar ou remover os seus próprios filtros e máscaras.

As políticas ABAC são anexadas ao nível do catálogo, esquema ou tabela e correspondem dinamicamente a tabelas e colunas com base nas etiquetas governadas. Uma política definida ao nível do catálogo aplica-se a todas as tabelas desse catálogo, e os proprietários individuais de tabelas não podem removê-la, modificá-la, nem contorná-la. A política permanece no catálogo e é avaliada pelo Unity Catalog antes de a consulta chegar ao tempo de execução. Isto permite que administradores de nível superior apliquem regras em toda a organização e garantam que administradores e proprietários de nível inferior não as consigam contornar.

Resumo detalhado da comparação

Esta tabela resume as diferenças entre as políticas ABAC, os filtros de linhas ao nível da tabela e as máscaras de colunas.

De um modo geral, utilize as políticas ABAC quando:

• Precisas de regras de acesso consistentes em muitas tabelas, esquemas ou catálogos.
• A sua organização divide as tarefas. Por exemplo, os autores das políticas definem regras, e os gestores de dados classificam os dados com etiquetas.
• O seu património de dados está a crescer e quer que as novas tabelas sejam cobertas automaticamente quando são etiquetadas.
• Precisas da EXCEPT cláusula para permitir operações como viagens no tempo, Delta Sharing, ou otimização total de consultas para princípios específicos.

Em geral, utilize filtros de linha ao nível de tabela e máscaras de coluna quando:

• Cada tabela tem uma lógica estrita e específica que não se generaliza para outras tabelas.
• Os proprietários de tabelas devem gerir diretamente os seus próprios filtros e máscaras, sem um sistema centralizado de etiquetas.
• Tens um conjunto pequeno e estável de tabelas que mudam raramente.

Combinação de ABAC, filtros de linhas ao nível de tabela e máscaras de coluna

ABAC e filtros de linha e máscaras de coluna ao nível da tabela podem coexistir na mesma tabela. No momento da consulta, as políticas são avaliadas independentemente para o utilizador que faz a consulta com as seguintes regras:

• Apenas um filtro de linha distinto pode aplicar-se.
• Apenas uma máscara de coluna distinta pode ser resolvida por coluna.

O Azure Databricks avalia o conflito comparando as funções aplicadas, não a saída dos dados. Se tanto uma política ABAC como um filtro ou máscara ao nível de tabela aplicarem o mesmo filtro de linha ou função de máscara de coluna para o mesmo utilizador, o Azure Databricks permite a execução. Se aplicarem funções diferentes, o Azure Databricks bloqueia o acesso e devolve um erro, mesmo que essas funções produzam saída de dados idêntica.

Para detalhes sobre resolução de conflitos e resolução de problemas, consulte Regras para múltiplos filtros e máscaras.

Segurança a nível de linha e coluna com visões dinâmicas

As vistas dinâmicas também podem implementar segurança ao nível das linhas e das colunas, incorporando funções de identidade como current_user() e is_account_group_member() diretamente na definição da vista. Vistas dinâmicas, filtros de linhas e máscaras de coluna aplicam lógica de filtragem ou transformação no momento da consulta, mas diferem na forma como são geridas, analisadas e expostas aos utilizadores.

Use vistas dinâmicas quando precisar de controlo de acesso detalhado que abrange várias tabelas de origem ou que reformule dados para partilha. Usa filtros de linha e máscaras de coluna quando quiseres controlar o acesso em tabelas individuais sem introduzir novos objetos.

Por exemplo, uma vista dinâmica pode mascarar uma coluna de email para não auditores:

CREATE VIEW sales_redacted AS
SELECT
  user_id,
  CASE
    WHEN is_account_group_member('auditors') THEN email
    ELSE regexp_extract(email, '^.*@(.*)$', 1)
  END AS email,
  country,
  product,
  total
FROM sales_raw

As vistas dinâmicas suportam totalmente a otimização de consultas e a aplicação de predicados, assim podem oferecer melhor desempenho de consulta do que filtros de linha e máscaras de colunas. Também impedem os utilizadores de modificar as tabelas subjacentes.

No entanto, as vistas dinâmicas têm duas desvantagens para a governação de dados:

• Auditoria limitada: As vistas dinâmicas não possuem metadados semânticos como etiquetas ou definições de políticas em tabelas de sistemas, o que as torna mais difíceis de auditar em larga escala.
• Vulnerabilidade à sondagem: Por não terem uma SecureView barreira, não protegem contra ataques de sondagem, onde o utilizador cria um predicado com efeitos secundários para inferir informação sobre linhas filtradas. Veja Compreensão do pushdown de predicados em tabelas protegidas.