Filtros de linha e máscaras de coluna

Esta página fornece diretrizes para usar 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 geralmente é usado para implementar a 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 UDFs (funções definidas pelo usuário) do SQL e também podem incorporar a lógica Python ou Scala quando encapsulados em um UDF do SQL. Você pode aplicar filtros de linha por tabela ou centralmente por meio de políticas ABAC usando marcas governadas.

O que são máscaras de coluna?

As máscaras de coluna controlam quais valores 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 emails, sejam redigidos 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 uma SQL UDF que retorna um valor do mesmo tipo da coluna mascarada. Opcionalmente, a UDF do SQL pode chamar UDFs Python ou Scala para implementar uma complexa lógica de mascaramento. 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.

Assim 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 se integram perfeitamente ao SQL padrão, notebooks e dashboards.

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

Exibições dinâmicas, filtros de linha e máscaras de coluna permitem que você aplique a lógica de filtragem ou transformação no momento da consulta, mas elas diferem em como são gerenciadas, com escopo e expostas aos usuários.

• Use exibições dinâmicas quando precisar de uma camada somente leitura em uma ou mais tabelas de origem, especialmente para compartilhamento de dados ou aplicação de lógica em várias 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. Elas podem ser gerenciadas usando políticas ABAC (recomendadas) ou manualmente em tabelas.

Para obter uma comparação completa, consulte os métodos de controle do Access 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 centralmente filtros e máscaras usando tags governadas e políticas reutilizáveis. Essa abordagem é dimensionada entre catálogos e esquemas e reduz a necessidade de configuração tabela a 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 pelos proprietários de tabela, 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 com mais eficiência do que em UDFs específicas de tabela. O Databricks recomenda o uso do ABAC para a maioria dos casos de uso. Para aplicar filtros e máscara usando o ABAC, consulte o ABAC (controle de acesso baseado em atributo) do Catálogo do Unity.

• 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. Ele permite um controle 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 Performance

Filtros de linha e máscaras de coluna controlam a visibilidade dos dados, garantindo que os usuários não possam exibir o conteúdo dos valores das tabelas base antes de filtrar e mascarar operações. Eles apresentam um bom desempenho ao responder a consultas em casos de uso comuns. Em aplicativos menos comuns, em que 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 em detrimento de algum impacto no desempenho da consulta. Para minimizar esse impacto no desempenho, aplique as seguintes recomendações:

• Usar funções de política simples: 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 consultas, aumentando a sobrecarga de processamento. Aplique máscaras somente a colunas que contêm 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 referências de coluna à tabela de origem resultantes de argumentos de função de política, mesmo que essas colunas não sejam usadas 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 muitos conjuntos AND: Como apenas um filtro de linha distinto pode ser resolvido em runtime para um determinado usuário e tabela, uma abordagem comum é combinar várias funções de política desejadas com AND. No entanto, com cada conjunção adicional, aumentam as chances de que os conjuntos incluam componentes mencionados em outros lugares nesta tabela que possam afetar o desempenho (como tabelas de mapeamento). Use menos conjuntos para melhorar o desempenho.
• Usar expressões determinísticas que não podem gerar erros em políticas de tabela e consultas dessas tabelas: Algumas expressões poderão gerar erros se as entradas fornecidas não forem válidas, como a divisão ANSI. Nesses casos, o compilador SQL não deve empurrar operações com essas expressões (como filtros) para posições muito inferiores no plano de consulta para evitar a possibilidade de erros como "divisão por zero", que poderiam revelar informações sobre valores antes das operações de filtro e/ou mascaramento. Use expressões determinísticas que nunca lançam erros, como try_divide.
• Prefira o SQL às UDFs do Python: as UDFs do Python normalmente têm menos desempenho do que o SQL e oferecem menos oportunidades de otimização. Se você precisar usar o Python, marque explicitamente as UDFs como DETERMINISTIC quando elas não envolvem dependências ou lógicas não determinísticas.
• Execute consultas de teste em sua tabela para medir o desempenho: Construa consultas realistas que representam 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 de política e observe seus efeitos até chegar a um bom equilíbrio entre desempenho e expressividade da lógica de filtragem e mascaramento.

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

Limitações

• As versões do Databricks Runtime abaixo da 12.2 LTS não dão suporte a filtros de linha ou máscaras de coluna. Esses runtimes falham de forma segura, o que significa que, se você tentar acessar tabelas desses runtimes, nenhum dado será retornado.
• Os provedores de compartilhamento Delta não podem compartilhar tabelas com segurança em nível de linha ou máscaras de colunas. No entanto, os destinatários do Delta Sharing 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 de Iceberg gerenciadas não dão suporte a filtros de linha ou máscaras de coluna.
• Você não pode 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 uma exibição.
• A viagem no tempo não funciona com máscaras de coluna ou segurança em nível de linha.
• No momento, não há suporte para o 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 de volta às políticas originais.
• Filtros de linha e máscaras de coluna não podem referenciar tabelas que também têm filtros de linha ativos ou máscaras de coluna. Nas configurações do ABAC, você pode contornar isso excluindo o responsável pela função de política da política da tabela referenciada.
• Clones profundos e rasos não são suportados em tabelas que têm segurança no nível da linha ou máscaras de coluna.
• As instruções MERGE não dão suporte a tabelas com políticas de filtro de linha ou máscara de coluna que contenham aninhamento, agregações, janelas, limites ou funções não determinísticas.
• As versões do Databricks Runtime abaixo da 17.2 não dão suporte a DELETE, UPDATE e MERGE em tabelas particionadas com políticas de filtro de linha ou máscara de coluna definidas na coluna de partição.
• Não há suporte para APIs do Delta Lake.

Limitação do modo de acesso dedicado

Você não pode acessar uma tabela com filtros de linha ou máscaras de coluna 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 o workspace estiver habilitado para computação sem servidor. No entanto, há suporte apenas para operações de leitura no Databricks Runtime 15.4 a 16.2. As operações de gravação (incluindo INSERT, UPDATEe DELETE) exigem o Databricks Runtime 16.3 ou superior e devem usar padrões com suporte, como MERGE INTO.

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