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 são tratados os conflitos entre múltiplas políticas
• Como funciona a fundição de tipos de máscara de coluna
• Que salvaguardas evitam a exposição de dados quando etiquetas ou funções das quais uma política depende são eliminadas

Avaliação e aplicação da política

Quando um utilizador consulta uma tabela, a avaliação ABAC decorre em duas fases: avaliação de políticas no Unity Catalog e aplicação de políticas no Databricks Runtime.

Utilizadores diferentes podem ver resultados distintos da mesma consulta porque a avaliação da política depende da identidade do utilizador, das pertenças aos grupos e das etiquetas nos dados a que acedem. Alterações na pertença a grupos ou atribuições de etiquetas alteram dinamicamente as políticas efetivas no momento da consulta.

Avaliação de políticas (Catálogo Unity)

O Unity Catalog executa os seguintes passos usando os metadados do securável (por exemplo, atribuições de etiquetas governadas) e a identidade do utilizador que consulta e as pertenças aos grupos:

1. Identifica todas as políticas cujo âmbito abrange a tabela consultada.
2. Para cada uma destas políticas, verifica se o utilizador que faz a consulta está na TO lista e não na EXCEPT lista.
3. Para cada política, avalia as condições das tabelas e colunas em relação às etiquetas do objeto consultado, incluindo as etiquetas herdadas. As condições da coluna devem corresponder a pelo menos uma coluna.
4. Se a política se aplicar, determina o filtro de linha efetivo ou a máscara de coluna e envia-o para o Databricks Runtime como parte dos metadados da tabela.

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

O planeador de consultas em tempo de execução Databricks traduz o filtro de linha efetivo ou a máscara de coluna para uma vista segura sobre as análises de tabela que aplicam filtragem e mascaramento durante a execução da consulta. Este é o mesmo mecanismo de implementação usado para filtros de linha a nível de tabela e máscaras de coluna.

Design falha-fechada

ABAC segue um modelo fail-closed, onde o Azure Databricks recusa o acesso por padrão se não conseguir verificar os parâmetros de segurança. O Azure Databricks só permite o acesso a tabelas seguras por ABAC quando pode aplicar em segurança todas as políticas aplicáveis. Isto aplica-se a versões de computação não suportadas, operações específicas sobre os dados da tabela subjacente e situações em que as dependências de uma política (etiquetas ou funções) foram removidas.

Versões de computação não suportadas

As políticas ABAC exigem Databricks Runtime 16.4 ou superior, ou computação em modo "serverless". Se um utilizador tentar aceder a uma tabela protegida por ABAC a partir de uma versão não suportada, a consulta falha como encerrada (o acesso é negado) para evitar exposição de dados não protegidos.

No modo de acesso dedicado, o Azure Databricks delega a aplicação dos controlos à computação sem servidor para garantir que são aplicados controlos de acesso granulares. Para permitir que utilizadores em runtimes mais antigos acedam a estas tabelas, é necessário isentá-los explicitamente das políticas.

Operações não suportadas em dados protegidos

Certas operações são incompatíveis com filtros de linha ou máscaras de coluna. Estas operações falham em vez de contornar a aplicação. Para os executar, o principal deve estar listado na EXCEPT cláusula de cada política ABAC que se aplique à tabela. Os principais isentos não estão sujeitos à política, pelo que o Azure Databricks não precisa de a aplicar e pode permitir a operação em segurança.

As operações que exigem a isenção do principal executante incluem atualizações de pipeline, processos de backup e fluxos de trabalho administrativos, tais como os seguintes:

• Aceder a tabelas protegidas por ABAC a partir de computação em execução em versões do Databricks Runtime inferiores a 16.4
• Consultas sobre viagens no tempo
• Clonagem profunda e superficial
• Delta Sharing, onde o acionista deve estar isento da apólice e possuir as permissões necessárias para a Delta Sharing. Note que a política não regula o acesso do destinatário.
• Criação e sincronização de índice de pesquisa vetorial

Para mais detalhes sobre estas e outras limitações, consulte requisitos, quotas e limitações da ABAC.

Dependências de políticas removidas

As políticas ABAC dependem de etiquetas governadas e UDFs. Se alguma destas dependências for removida enquanto a política ainda as referencia, as consultas sobre tabelas dentro do âmbito da política falharão.

Eliminação de etiquetas governada

Se eliminar uma etiqueta governada referenciada por uma política ABAC, todas as consultas contra o objeto onde a política está anexada e os seus sub-objetos falham com um erro INVALID_PARAMETER_VALUE.UC_ABAC_UNKNOWN_TAG_POLICY. Isto ocorre mesmo que a etiqueta não tenha sido aplicada às tabelas consultadas.

Quando uma etiqueta governada é eliminada, torna-se uma etiqueta não governada. As restrições de valores permitidas são removidas, e qualquer pessoa com APPLY TAG pode modificar valores sem esse privilégio ASSIGN.

Para resolver o erro, deve restaurar a etiqueta eliminada, ou atualizar ou eliminar a política que a referencia. Veja Criar e gerir etiquetas governadas.

Eliminar uma coluna que está marcada

O Azure Databricks impede a eliminação de uma coluna que tenha uma etiqueta governada aplicada. Para eliminar a coluna, um utilizador com ASSIGN na etiqueta e APPLY TAG no objeto deve primeiro remover a etiqueta, depois a coluna pode ser eliminada.

Isto é relevante para pipelines declarativos e outros fluxos de trabalho automatizados que modificam esquemas de tabelas. Se um pipeline tentar eliminar uma coluna etiquetada, a operação falhará. Para desbloquear o pipeline, um utilizador com as permissões de etiqueta necessárias deve remover a etiqueta, executar o pipeline para que a alteração do esquema seja bem-sucedida, e depois reaplicar a etiqueta às colunas relevantes. Se a etiqueta não for reaplicada, as consultas aos dados falharão porque a política ainda está dentro do âmbito mas a etiqueta esperada já não está no objeto.

Eliminação de funções referenciadas pelas políticas

Se um UDF referenciado por uma política for excluído enquanto a política ainda está dentro do âmbito, as consultas às tabelas desse âmbito falham com UC_DEPENDENCY_DOES_NOT_EXIST. Para resolver, restaure a função ou atualize a política para referenciar um UDF diferente.

Regras para múltiplos filtros e máscaras

Apenas um filtro de linha distinto pode ser aplicado em tempo de execução da consulta para uma tabela e um utilizador específicos. De forma semelhante, apenas uma máscara de coluna distinta por coluna pode ser resolvida em tempo de execução para uma dada coluna e utilizador. Isto evita resultados ambíguos.

Se vários filtros ou máscaras distintas se aplicarem ao mesmo utilizador e tabela (ou coluna), o Azure Databricks bloqueia o acesso e devolve um erro. Por exemplo:

• Um filtro ao nível de tabela ou máscara entra em conflito com uma política ABAC. Uma tabela ou coluna que já tenha um filtro de linha ou máscara de coluna aplicada manualmente entra em conflito com qualquer filtro ou máscara definido por ABAC no mesmo alvo.
• Na cláusula de USING COLUMNS de um filtro de linha, refere-se a um alias de MATCH COLUMNS que corresponde a várias colunas. A USING COLUMNS cláusula passa os valores das colunas para a UDF. Se um MATCH COLUMNS alias na USING COLUMNS cláusula corresponder a mais do que uma coluna, o mecanismo é incapaz de determinar qual coluna transferir para o UDF, e a consulta resulta em erro.
• Uma coluna mascarada é referenciada na USING COLUMNS cláusula de outra apólice. Se uma coluna estiver mascarada por uma política, não pode ser usada como argumento de entrada na USING COLUMNS cláusula de outra política.

Múltiplas políticas ABAC podem coexistir para a mesma tabela ou coluna se resultarem no mesmo filtro ou máscara eficaz. Por exemplo, duas políticas que fazem referência ao mesmo UDF com os mesmos argumentos equivalem ao mesmo filtro ou máscara, e não entram em conflito.

Resolução de conflitos de políticas

Quando Azure Databricks deteta múltiplos filtros ou máscaras distintos durante a avaliação de políticas para um dado utilizador, lança 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 ao nível da tabela ou máscaras de coluna que possam entrar em conflito.
3. Verifique quais as políticas que se sobrepõem nos seus TO/EXCEPT principais e WHEN/MATCH COLUMNS condições.
4. Resolver através de:
   • Aperfeiçoamento das condições da apólice. Atualizar as cláusulas WHEN ou MATCH COLUMNS para que sejam mais específicas, de modo que políticas distintas visem diferentes tabelas ou colunas.
   • A ajustar etiquetas governadas. Revise as atribuições de etiquetas em colunas ou tabelas que desencadeem correspondências de políticas não intencionais e remova-as ou atualize-as.
   • Ajustar princípios. Atualize TO/EXCEPT as cláusulas para que cada utilizador fique coberto por no máximo uma política por tabela (para filtros de linhas) ou por coluna (para máscaras de coluna).
   • Políticas de reestruturação. Consolidar políticas sobrepostas numa única política, ou dividir políticas amplas em políticas separadas e explicitamente direcionadas.

Conversão automática de tipos para máscaras de coluna

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

1. Execução da função de mascaramento: Quando a avaliação de políticas determina que o mascaramento se aplica, a função de mascaramento é executada sobre os valores das colunas correspondentes.
2. Cast automático de tipos: Azure Databricks projeta o valor da coluna de entrada para corresponder ao tipo de parâmetro da função, e projeta a saída da função para corresponder ao tipo de dados da coluna de destino.
3. Retorno do resultado: O resultado digitado corretamente é retornado para a consulta.

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

Deve assegurar que as funções de máscara retornam tipos compatíveis com colunas alvo. Veja Funções de mascaramento compatíveis com Cast para exemplos e a abordagem VARIANT para mascaramento flexível entre tipos de coluna.