Quando usar ABAC vs filtros de linha e máscaras de coluna no nível de tabela

O Catálogo do Unity dá suporte a duas abordagens para segurança em nível de linha e de coluna: políticas ABAC e filtros de linha no nível da tabela e máscaras de coluna. Nenhuma das abordagens concede acesso a dados por conta própria– ambas adicionam restrições sobre privilégios de nível de objeto existentes. Você deve conceder acesso à tabela base separadamente por meio de permissões no nível do objeto (GRANT).

A principal diferença é onde as restrições são definidas. Filtros de linha de nível de tabela e máscaras de coluna aplicam controles de sensibilidade diretamente em tabelas individuais usando ALTER TABLE. Os proprietários de tabelas gerenciam sua própria proteção de dados sem precisar de um sistema de etiquetagem governada. Isso é simples para um pequeno número de tabelas, mas cada tabela deve ser configurada individualmente e os proprietários da tabela podem modificar ou remover seus próprios filtros e máscaras.

As políticas ABAC podem ser aplicadas no nível de catálogo, esquema ou tabela e correspondem a tabelas e colunas de forma dinâmica com base em tags governadas. Uma política definida no nível do catálogo se aplica a todas as tabelas desse catálogo e os proprietários de tabelas individuais não podem removê-la, modificá-la ou ignorá-la. A política reside no catálogo e é avaliada pelo Catálogo do Unity antes que a consulta chegue ao runtime. Isso permite que administradores de nível superior imponham regras de toda a organização e garantam que administradores e proprietários de nível inferior não possam contorná-las.

Resumo detalhado da comparação

Esta tabela resume as diferenças entre políticas ABAC, filtros de linha no nível de tabela e máscaras de coluna.

Em geral, use políticas ABAC quando:

• Você precisa de regras de acesso consistentes em várias tabelas, esquemas ou catálogos.
• Sua organização separa as responsabilidades. Por exemplo, os autores de política definem regras e os administradores de dados classificam os dados com marcas.
• Sua infraestrutura de dados está crescendo e você deseja que novas tabelas sejam abrangidas automaticamente quando forem marcadas.
• Você precisa da EXCEPT cláusula para permitir operações como viagem no tempo, Compartilhamento Delta ou otimização completa de consultas para principais específicos.

Em geral, use filtros de linha no nível da tabela e máscaras de coluna quando:

• Cada tabela tem uma lógica estrita e específica que não generaliza para outras tabelas.
• Os proprietários de tabela devem gerenciar seus próprios filtros e máscaras diretamente, sem um sistema de tags centralizado.
• Você tem um conjunto pequeno e estável de tabelas que mudam com pouca frequência.

Combinando ABAC e filtros de linha e máscaras de coluna no nível da tabela

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

• Somente um filtro de linha distinto pode ser aplicado.
• Somente uma máscara de coluna distinta pode ser resolvida por coluna.

Azure Databricks avalia o conflito comparando as funções aplicadas, não a saída de dados. Se uma política ABAC e um filtro de nível de tabela ou máscara aplicarem a mesma função de filtro de linha ou máscara de coluna para o mesmo usuário, Azure Databricks permitirá a execução. Se aplicarem funções diferentes, Azure Databricks bloqueará o acesso e retornará um erro, mesmo que essas funções produzam saídas de dados idênticas.

Para obter detalhes sobre resolução de conflitos e solução de problemas, consulte Regras para vários filtros e máscaras.

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

Exibições dinâmicas também podem implementar a segurança em nível de linha e de coluna inserindo funções de identidade como current_user() e is_account_group_member() diretamente na definição de exibição. Exibições dinâmicas, filtros de linha e máscaras de coluna aplicam lógica de filtragem ou transformação no momento da consulta, mas diferem no escopo em que são gerenciados e expostos aos usuários.

Use exibições dinâmicas quando precisar de um controle de acesso refinado que abrange várias tabelas de origem ou remodele os dados para compartilhamento. Use filtros de linha e máscaras de coluna quando quiser controlar o acesso em tabelas individuais sem introduzir novos objetos.

Por exemplo, uma exibição 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

Visões dinâmicas dão suporte total à otimização de consulta e ao empurro de predicado, de modo que possam proporcionar um desempenho de consulta superior ao de filtros de linha e máscaras de coluna. Eles também impedem que os usuários modifiquem as tabelas subjacentes.

No entanto, as exibições dinâmicas têm duas desvantagens para a governança de dados:

• Auditoria limitada: as exibições dinâmicas não têm metadados semânticos, como marcas ou definições de política em tabelas do sistema, o que as torna mais difíceis de auditar em escala.
• Vulnerabilidade à sondagem: como eles não têm uma SecureView barreira, não fornecem proteção contra ataques de sondagem, em que um usuário cria um predicado com efeitos colaterais para inferir dados sobre linhas filtradas. Veja Entenda a aplicação de predicados em tabelas protegidas.