Filtros de linha e máscaras de coluna

Esta página fornece orientação para o uso de filtros de linha e máscaras de coluna para filtrar dados confidenciais em suas tabelas.

O que são filtros de linha?

Os filtros de linha permitem controlar quais linhas um usuário pode acessar em uma tabela com base na lógica personalizada. No momento da consulta, um filtro de linha avalia uma condição e retorna apenas as linhas que a atendem. Isso é comumente usado para implementar segurança em nível de linha, por exemplo, restringindo os usuários a registros de uma região, departamento ou conta específica.

Os filtros de linha são definidos como funções definidas pelo usuário (UDFs) do SQL e também podem incorporar a lógica Python ou Scala quando encapsuladas em um UDF SQL. Você pode aplicar filtros de linha por tabela ou centralmente por meio de políticas ABAC usando tags controladas.

O que são máscaras de coluna?

As máscaras de coluna controlam os valores que os usuários veem em colunas específicas, dependendo de quem são. No momento da consulta, a máscara substitui cada referência a uma coluna pelo resultado de uma função de mascaramento. Isso permite que dados confidenciais, como SSNs ou e-mails, sejam editados ou transformados com base na identidade ou função do usuário.

Cada coluna pode ter uma máscara. A máscara deve ser definida como um SQL UDF que retorna um valor do mesmo tipo da coluna que está sendo mascarada. O SQL UDF pode, opcionalmente, chamar UDFs Python ou Scala para implementar uma lógica de mascaramento complexa. As máscaras de coluna também podem usar outras colunas como entradas, por exemplo, para variar o comportamento com base em vários atributos.

Como os filtros de linha, as máscaras de coluna podem ser aplicadas por tabela ou gerenciadas centralmente por meio de políticas ABAC. Eles operam no momento da consulta e integram-se perfeitamente com SQL, blocos de anotações e painéis padrão.

Quando você deve usar exibições dinâmicas versus filtros e máscaras?

Modos de exibição dinâmicos, filtros de linha e máscaras de coluna permitem aplicar lógica de filtragem ou transformação no momento da consulta, mas diferem na forma como são gerenciados, definidos e expostos aos usuários.

• Utilize visões dinâmicas quando precisar de uma camada de apenas leitura em uma ou mais tabelas de origem, especialmente para o compartilhamento de dados ou para aplicar lógica a múltiplas entradas.
• Use filtros de linha e máscaras de coluna quando quiser aplicar lógica diretamente a uma tabela, sem alterar o nome da tabela ou introduzir novos objetos. Eles podem ser geridos utilizando políticas ABAC (recomendadas) ou manualmente nas tabelas.

Para obter uma comparação completa, consulte Métodos de controle de acesso comparados.

Como aplicar filtros e máscaras

Você pode implementar filtros de linha e máscaras de coluna de duas maneiras principais:

• Usando políticas ABAC (Visualização pública): aplique filtros e máscaras centralmente usando tags controladas e políticas reutilizáveis. Esta abordagem escalona através de esquemas e catálogos e reduz a necessidade de configuração tabela por tabela. As políticas ABAC são mais seguras do que as políticas manuais de nível de tabela porque podem ser definidas por administradores de nível superior e não podem ser substituídas por proprietários de tabelas, o que ajuda a impor controles de acesso centralizados. Eles também são mais eficientes em muitos casos, uma vez que a lógica de filtragem e mascaramento em políticas ABAC é avaliada de forma mais eficiente do que em UDFs específicas de tabela. A Databricks recomenda o uso do ABAC para a maioria dos casos de uso. Para aplicar filtros e máscaras usando ABAC, consulte Unity Catalog, controle de acesso baseado em atributos (ABAC).

• Atribuição manual por tabela: aplique filtros e máscaras atribuindo funções diretamente a tabelas e colunas individuais. Esse método pode usar tabelas de mapeamento ou outra lógica personalizada. Permite um controlo refinado e específico da tabela, mas é mais difícil de dimensionar e manter. Para obter mais informações, consulte Aplicar manualmente filtros de linha e máscaras de coluna.

Recomendações de desempenho

Os filtros de linha e as máscaras de coluna controlam a visibilidade dos dados, garantindo que os usuários não possam visualizar o conteúdo dos valores das tabelas base antes das operações de filtragem e mascaramento. Os sistemas têm um bom desempenho em resposta a consultas em casos de uso comuns. Em aplicativos menos comuns, onde o mecanismo de consulta deve escolher entre otimizar o desempenho da consulta e proteger contra vazamento de informações dos valores filtrados/mascarados, ele sempre tomará a decisão segura às custas de algum impacto no desempenho da consulta. Para minimizar esse impacto no desempenho, aplique as seguintes recomendações:

• Use funções de política simples: As funções de política com menos expressões geralmente têm um desempenho melhor do que expressões mais complexas. Evite usar tabelas de mapeamento e subconsultas de expressão em favor de funções CASE simples.
• Limite o número de máscaras de coluna e funções de mascaramento: Várias máscaras de coluna exclusivas em tabelas grandes podem prejudicar o desempenho da consulta. Cada máscara distinta requer avaliação durante as consultas, aumentando a sobrecarga de processamento. Aplique máscaras apenas a colunas que contenham dados verdadeiramente confidenciais e reutilize funções de mascaramento sempre que possível.
• Reduzir o número de argumentos de função: O Azure Databricks não pode otimizar as referências de coluna para a tabela de origem resultantes dos argumentos de função de política, mesmo que essas colunas não sejam utilizadas na consulta. Use funções de política com menos argumentos, pois as consultas dessas tabelas terão um desempenho melhor.
• Evite adicionar filtros de linha com demasiados conjuntos AND: Como apenas um filtro de linha distinto pode ser resolvido em tempo de execução para um dado utilizador e tabela, uma abordagem comum é combinar múltiplas funções de política desejadas com AND. No entanto, a cada conjunto adicional, aumentam as chances de que o(s) conjunto(s) inclua(m) componentes mencionados em outras partes desta tabela que possam afetar o desempenho (como tabelas de mapeamento). Utilize menos conectivos para melhorar o desempenho.
• Use expressões determinísticas que não podem gerar erros em políticas de tabela e consultas a partir destas tabelas: Algumas expressões podem gerar erros se as entradas fornecidas não forem válidas, como a divisão ANSI. Nesses casos, o compilador SQL não deve enviar operações com essas expressões (como filtros) muito para baixo no plano de consulta para evitar a possibilidade de erros como "divisão por zero" que revelam informações sobre valores antes de filtrar e/ou mascarar operações. Use expressões determinísticas que nunca lancem erros, como try_divide.
• Prefira SQL a UDFs Python: UDFs Python são normalmente menos eficientes do que SQL e oferecem menos oportunidades de otimização. Se você precisar usar Python, marque explicitamente UDFs como DETERMINISTIC quando eles não envolvem lógica ou dependências não determinísticas.
• Execute consultas de teste sobre sua tabela para avaliar o desempenho: Construa consultas realistas que representem a carga de trabalho esperada para sua tabela com filtros de linha ou máscaras de coluna e meça o desempenho. Faça pequenas modificações nas funções da política e observe seus efeitos até alcançar um bom equilíbrio entre desempenho e expressividade da lógica de filtragem e mascaramento.

Para obter mais práticas recomendadas e exemplos de UDFs, consulte UDFs para práticas recomendadas de políticas ABAC.

Limitações

• As versões do Databricks Runtime abaixo de 12.2 LTS não suportam filtros de linha ou máscaras de coluna. Esses runtimes falham de forma segura, o que significa que, se o utilizador tentar aceder às tabelas desses runtimes, não será retornado nenhum dado.
• Os provedores de Compartilhamento Delta não podem compartilhar tabelas com segurança em nível de linha ou com mascaramento de coluna. No entanto, os destinatários do Compartilhamento Delta podem aplicar filtros de linha e máscaras de coluna apenas a tabelas compartilhadas e tabelas estrangeiras, não a tabelas de streaming ou exibições materializadas.
• As tabelas Iceberg geridas não suportam filtros de linha nem máscaras de coluna.
• Não é possível usar o catálogo REST do Iceberg ou as APIs REST do Unity para acessar tabelas com filtros de linha ou máscaras de coluna.
• Não é possível aplicar segurança em nível de linha ou máscaras de coluna a um modo de exibição.
• A viagem no tempo não funciona com segurança em nível de linha ou máscaras de coluna.
• Não há suporte para acesso baseado em caminho a arquivos em tabelas com políticas.
• Não há suporte para políticas de filtro de linha ou máscara de coluna com dependências circulares que remontem às políticas originais.
• Os filtros de linha e as máscaras de coluna não podem fazer referência a tabelas que também tenham filtros de linha ou máscaras de coluna ativos. Nas configurações do ABAC, pode contornar isto excluindo o responsável pela função de política da política da tabela referenciada.
• Não há suporte para clones profundos e superficiais em tabelas com segurança em nível de linha ou máscaras de coluna.
• MERGE instruções não oferecem suporte a tabelas com políticas de filtro de linha ou máscara de coluna que contenham aninhamento, agregações, funções de janela, limites ou funções não determinísticas.
• As versões do Databricks Runtime abaixo de 17.2 não suportam DELETE, UPDATEe MERGE em tabelas particionadas com políticas de filtro de linha ou máscara de coluna definidas na coluna de partição.
• As APIs Delta Lake não são suportadas.

Limitação do modo de acesso dedicado

Não é possível aceder a uma tabela com filtros de linha ou máscaras de coluna a partir de um recurso de computação de acesso dedicado no Databricks Runtime 15.3 ou inferior. Você pode usar o modo de acesso dedicado no Databricks Runtime 15.4 LTS ou superior se seu espaço de trabalho estiver habilitado para computação sem servidor. No entanto, apenas operações de leitura são suportadas no Databricks Runtime 15.4 a 16.2. As operações de escrita (incluindo INSERT, UPDATE e DELETE) requerem o Databricks Runtime 16.3 ou superior e devem usar padrões suportados, como MERGE INTO.

Para obter mais informações, consulte Controle de acesso refinado em computação dedicada.