Avaliação de políticas e comportamento em tempo de execução

Esta página explica como as políticas ABAC são avaliadas no momento da consulta, incluindo:

• Como lidar com conflitos entre múltiplas políticas
• Como funciona a conversão de tipo por máscara de coluna
• Quais medidas de segurança impedem a exposição de dados quando tags ou funções das quais uma política depende são excluídas?

Avaliação e aplicação de políticas

Quando um usuário consulta uma tabela, a avaliação do ABAC ocorre em duas etapas: avaliação da política no Unity Catalog e aplicação da política no Databricks Runtime.

Usuários diferentes podem ver resultados diferentes para a mesma consulta, pois a avaliação da política depende da identidade do usuário, das suas associações a grupos e das tags nos dados que ele acessa. Alterações na associação a grupos ou na atribuição tag alteram dinamicamente as políticas efetivas no momento da consulta.

Avaliação de políticas (Unity Catalog)

Unity Catalog executa os seguintes passos usando os metadados do objeto protegível (por exemplo, atribuições tag controladas) e a identidade e as associações de grupo do usuário que realiza a consulta:

1. Identifica todas as políticas cujo escopo abrange a tabela consultada.
2. Para cada uma dessas políticas, verifica se o usuário que está fazendo a consulta está na lista TO e não na lista EXCEPT .
3. Para cada política, avalia as condições da tabela e da coluna em relação às tags do objeto consultado, incluindo tags herdadas. As condições da coluna devem corresponder a pelo menos uma coluna.
4. Se a política for aplicável, determina o filtro de linha ou a máscara de coluna efetiva e a envia para o Databricks Runtime como parte dos metadados da tabela.

Aplicação de políticas (Databricks Runtime)

O planejador de consultas Databricks Runtime traduz o filtro de linha ou a máscara de coluna efetiva em view segura, com base nas varreduras de tabela que impõem filtragem e mascaramento durante a execução da consulta. Este é o mesmo mecanismo de aplicação usado para filtros de linha em nível de tabela e máscaras de coluna.

projeto à prova de falhas

O ABAC segue um modelo de falha fechada, em que Databricks nega o acesso por padrão caso não consiga verificar a segurança. O Databricks só permite o acesso a tabelas protegidas por ABAC quando consegue aplicar com segurança todas as políticas aplicáveis. Isso se aplica a versões compute não suportadas, operações específicas nos dados da tabela subjacente e situações em que as dependências de uma política (tags ou funções) foram removidas.

Versões compute não suportadas

As políticas ABAC exigem Databricks Runtime 16.4 ou superior, ou compute serverless . Se um usuário tentar acessar uma tabela protegida por ABAC a partir de uma versão não compatível, a consulta será encerrada com falha (o acesso será negado) para evitar a exposição de dados desprotegidos.

No modo de acesso dedicado, Databricks delega a aplicação de políticas de segurança a compute serverless para garantir que os controles de acesso refinados sejam aplicados. Para permitir que usuários em versões mais antigas do ambiente de execução acessem essas tabelas, você deve isentá-los explicitamente das políticas.

Operações não suportadas em dados protegidos

Determinadas operações são incompatíveis com filtros de linha ou máscaras de coluna. Essas operações falham em vez de contornar a aplicação da lei. Para executá-las, o principal deve ser listado na cláusula EXCEPT de cada política ABAC que se aplica à tabela. Os principais isentos não estão sujeitos à política, portanto Databricks não precisa aplicá-la e pode permitir as operações com segurança.

as operações que exigem que o principal executor seja isento incluem atualização pipeline , processos de backup e fluxo de trabalho administrativo, como os seguintes:

• Acessando tabelas protegidas por ABAC a partir de compute que executam versões Databricks Runtime anteriores à 16.4
• viagem do tempo consultas
• Clonagem profunda e superficial
• Delta Sharing, em que o titular da quota deve estar isento da política e possuir as permissões necessáriasDelta Sharing. Note que a política não rege o acesso do destinatário.
• Criação e sincronização de índices de pesquisa vetorial

Para obter mais detalhes sobre essas e outras limitações, consulte Requisitos, cotas e limitações do ABAC.

Dependências de política removidas

As políticas ABAC dependem de tags e UDFs regulamentadas. Se alguma dessas dependências for removida enquanto uma política ainda fizer referência a elas, as consultas às tabelas no escopo da política falharão.

Exclusão tag controlada

Se você excluir uma tag governada que uma política ABAC referencia, todas as consultas contra o objeto onde a política está anexada e seus objetos filhos falharão com um erro INVALID_PARAMETER_VALUE.UC_ABAC_UNKNOWN_TAG_POLICY . Isso ocorre mesmo que a tag não tenha sido aplicada às tabelas consultadas.

Quando uma tag regulamentada é excluída, ela se torna uma tag não regulamentada. As restrições de valores permitidos são removidas e qualquer pessoa com APPLY TAG pode modificar valores sem o privilégio ASSIGN .

atenção

A interface do usuário e a API não impedem a exclusão de uma tag controlada que seja referenciada em uma política ABAC. Antes de excluir uma tag controlada, certifique-se de que nenhuma política ABAC faça referência a ela.

Para resolver o erro, restaure a tag excluída ou atualize ou exclua a política que a referencia. Consulte Criar e gerenciar tags governadas.

Excluindo uma coluna que contém tags.

O Databricks impede a exclusão de uma coluna que tenha uma tag de restrição aplicada. Para remover a coluna, um usuário com ASSIGN na tag e APPLY TAG no objeto deve primeiro remover a tag, então a coluna poderá ser excluída.

Isso é relevante para pipelines declarativos e outros fluxos de trabalho automatizados que modificam esquemas de tabelas. Se um pipeline tentar remover uma coluna de tags, a operação falhará. Para desbloquear o pipeline, um usuário com as permissões tag necessárias deve remover a tag, executar o pipeline para que a alteração do esquema seja bem-sucedida e, em seguida, reaplicar a tag às colunas relevantes. Se a tag não for reaplicada, as consultas aos dados falharão porque a política ainda estará em vigor, mas a tag esperada não estará mais presente no objeto.

Exclusão de função referenciada por política

Se uma UDF referenciada por uma política for excluída enquanto a política ainda estiver em escopo, as consultas em tabelas nesse escopo falharão com UC_DEPENDENCY_DOES_NOT_EXIST. Para resolver, restaure a função ou atualize a política para referenciar uma UDF diferente.

Regras para múltiplos filtros e máscaras

Apenas um filtro de linha distinto pode ser aplicado no momento da consulta para uma determinada tabela e usuário. Da mesma forma, apenas uma máscara de coluna distinta por coluna pode ser resolvida em tempo de execução para uma determinada coluna e usuário. Isso evita resultados ambíguos.

Se vários filtros ou máscaras distintos se aplicarem ao mesmo usuário e tabela (ou coluna), o Databricks bloqueará o acesso e retornará um erro. Por exemplo:

• Um filtro ou máscara em nível de tabela entra em conflito com uma política ABAC. Uma tabela ou coluna que já possui um filtro de linha ou máscara de coluna aplicada manualmente entra em conflito com qualquer filtro ou máscara definida pelo ABAC no mesmo destino.
• A cláusula USING COLUMNS de um filtro de linha faz referência a um alias MATCH COLUMNS que corresponde a várias colunas. A cláusula USING COLUMNS passa os valores da coluna para a UDF. Se um alias MATCH COLUMNS na cláusula USING COLUMNS corresponder a mais de uma coluna, o mecanismo não poderá determinar qual coluna passar para a UDF e a consulta falhará com um erro.
• Uma coluna mascarada é referenciada na cláusula USING COLUMNS de outra política. Se uma coluna for mascarada por uma política, ela não poderá ser usada como argumento de entrada na cláusula USING COLUMNS de outra política.

Várias políticas ABAC podem coexistir para a mesma tabela ou coluna se resultarem no mesmo filtro ou máscara efetiva. Por exemplo, duas políticas que fazem referência à mesma UDF com os mesmos argumentos resultam no mesmo filtro ou máscara e não entram em conflito.

Solução de problemas de conflitos de políticas

Quando o Databricks detecta vários filtros ou máscaras distintos durante a avaliação da política para um determinado usuário, ele gera um erro INVALID_PARAMETER_VALUE.UC_ABAC_MULTIPLE_ROW_FILTERS ou COLUMN_MASKS_FEATURE_NOT_SUPPORTED.MULTIPLE_MASKS e bloqueia o acesso à tabela até que o conflito seja resolvido.

Para diagnosticar e resolver:

1. Use SHOW EFFECTIVE POLICIES para ver todas as políticas que se aplicam à tabela.
2. Verifique INFORMATION_SCHEMA.ROW_FILTERS e INFORMATION_SCHEMA.COLUMN_MASKS para identificar quaisquer filtros de linha ou máscaras de coluna em nível de tabela que possam entrar em conflito.
3. Verifique quais políticas se sobrepõem em seus princípios TO/EXCEPT e condições WHEN/MATCH COLUMNS .
4. Resolver por:
   • Aprimorando as condições da política. Atualize as cláusulas WHEN ou MATCH COLUMNS para serem mais específicas, de modo que políticas distintas visem tabelas ou colunas diferentes.
   • Ajustando tags regulamentadas. Analise as atribuições tag em colunas ou tabelas que acionam correspondências de políticas não intencionais e remova-as ou atualize-as.
   • Ajustando os princípios. Atualize as cláusulas TO/EXCEPT para que cada usuário seja coberto por no máximo uma política por tabela (para filtros de linha) ou por coluna (para máscaras de coluna).
   • Políticas de reestruturação. Consolidar políticas sobrepostas em uma única política ou dividir políticas amplas em políticas separadas e explicitamente direcionadas.

Fundição automática de tipos para máscaras de coluna

O Databricks converte automaticamente tanto a entrada quanto a saída das funções de máscara de coluna resolvidas a partir de políticas ABAC. O valor da coluna de entrada é convertido para corresponder ao tipo de parâmetro da função de máscara, e a saída da função é convertida para corresponder ao tipo de dados da coluna de destino. Isso garante a consistência de tipos e um comportamento de consulta confiável ao mascarar colunas. A fundição automática funciona da seguinte maneira:

1. Execução da função de mascaramento : Quando a avaliação da política determina que o mascaramento se aplica, a função de mascaramento é executada nos valores da coluna correspondente.
2. Conversão automática de tipos : o Databricks converte o valor da coluna de entrada para corresponder ao tipo do parâmetro da função e converte a saída da função para corresponder ao tipo de dados da coluna de destino.
3. Resultado retornado : O resultado digitado corretamente é retornado à consulta.

Se os tipos de entrada ou saída não forem compatíveis, a conversão falhará e a consulta retornará um erro de tempo de execução. A conversão segue os padrões ANSI SQL para operações CAST (detalhes completos de compatibilidade), com uma adição: no Databricks Runtime 18.1 e superior, as políticas de máscara de coluna ABAC podem converter structs para VARIANT, o que não é suportado no SQL geral.

Você deve garantir que as funções de máscara retornem tipos compatíveis com a coluna de destino. Consulte as funções de mascaramento compatíveis com Cast para obter exemplos e a abordagem VARIANT para mascaramento flexível em diferentes tipos de coluna.