Avaliação de política e comportamento de runtime

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

• Como os conflitos entre várias políticas são tratados
• Como funciona a conversão de tipo de máscara de coluna
• Quais proteções impedem a exposição de dados quando marcas ou funções das quais uma política depende são excluídas

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

Quando um usuário consulta uma tabela, a avaliação do ABAC prossegue em dois estágios: avaliação de política no Catálogo do Unity e imposição de política no Databricks Runtime.

Usuários diferentes podem ver resultados diferentes da mesma consulta porque a avaliação da política depende da identidade do usuário, das associações de grupo e das marcas nos dados que eles acessam. As alterações nas associações de grupos ou nas atribuições de etiquetas alteram dinamicamente as políticas vigentes durante a consulta.

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

O Catálogo do Unity executa as seguintes etapas usando os metadados do protegível (por exemplo, atribuições de marca governada) e as associações de grupo e identidade do usuário de 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á consultando está na TO lista e não está na EXCEPT lista.
3. Para cada política, avalia as condições das tabelas e colunas em relação às tags no objeto consultado, incluindo as tags herdadas. As condições da coluna devem corresponder a pelo menos uma coluna.
4. Se a política se aplicar, determinará o filtro de linha efetivo ou a máscara de coluna e a enviará para o Databricks Runtime como parte dos metadados da tabela.

Aplicação de Política (Databricks Runtime)

O planejador de consultas do Databricks Runtime transforma o filtro de linha efetivo ou a máscara de coluna em uma exibição segura sobre as varreduras de tabela que impõem filtragem e mascaramento durante a execução da consulta. Esse é o mesmo mecanismo de imposição usado para filtros de linha no nível da tabela e máscaras de coluna.

Design de falha fechada

O ABAC segue um modelo de falha fechada, no qual o padrão do Azure Databricks é negar o acesso se não puder verificar a segurança. Azure Databricks só permite acesso a tabelas protegidas pelo ABAC quando pode impor com segurança todas as políticas aplicáveis. Isso se aplica a versões de computação sem suporte, operações específicas nos dados da tabela subjacente e situações em que as dependências de uma política (marcas ou funções) foram removidas.

Versões computacionais sem suporte

As políticas ABAC exigem o Databricks Runtime 16.4 ou superior, ou a computação sem servidor. Se um usuário tentar acessar uma tabela protegida pelo ABAC de uma versão sem suporte, a consulta falhará fechada (o acesso é negado) para evitar a exposição de dados desprotegida.

No modo de acesso dedicado, Azure Databricks delega a imposição à computação sem servidor para garantir que os controles de acesso detalhados sejam aplicados. Para permitir que os usuários em runtimes mais antigos acessem essas tabelas, você deve isentá-los explicitamente das políticas.

Operações sem suporte 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 ignorar a imposição. Para que os principais possam executá-las, eles devem ser listados na EXCEPT cláusula de cada política ABAC que se aplica à tabela. Principais isentos não estão sujeitos à política, portanto, o Azure Databricks não precisa aplicá-la e pode permitir a operação com segurança.

As operações que exigem que a entidade de execução seja isenta incluem atualizações de pipeline, processos de backup e fluxos de trabalho administrativos, como o seguinte:

• Acessando tabelas protegidas pelo ABAC a partir da execução em computação com versões do Databricks Runtime anteriores a 16.4
• Consultas de viagem no tempo
• Clonagem profunda e superficial
• Compartilhamento Delta, em que o proprietário do compartilhamento deve ser isento da política e ter as permissões de compartilhamento Delta necessárias. Observe que a política não rege o acesso do destinatário.
• Criação e sincronização de índice de pesquisa vetor

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 governadas e UDFs. Se qualquer uma dessas dependências for removida enquanto uma política ainda fizer referência a elas, as consultas em tabelas no escopo da política falharão.

Exclusão de tag governada

Se você excluir uma etiqueta governada à qual uma política ABAC faz referência, todas as consultas do objeto ao qual a política está anexada e seus objetos filho falharão com um erro INVALID_PARAMETER_VALUE.UC_ABAC_UNKNOWN_TAG_POLICY. Isso ocorre mesmo se a tag não tiver sido aplicada às tabelas da consulta.

Quando uma marca governada é excluída, ela se torna uma marca desgovernada. As restrições de valor permitidas são removidas e qualquer pessoa com APPLY TAG pode modificar valores sem o ASSIGN privilégio.

Para resolver o erro, restaure a marca excluída ou atualize ou exclua a política que faz referência a ela. Consulte Criar e gerenciar tags governados.

Excluindo uma coluna marcada

Azure Databricks impede a exclusão de uma coluna que tenha uma marca governada aplicada. Para remover a coluna, um usuário com ASSIGN na marca e APPLY TAG no objeto deve primeiro remover a marca, em seguida, a coluna pode ser excluída.

Isso é relevante para fluxos de trabalho automatizados, como pipelines declarativos, que modificam esquemas de tabela. Se um pipeline tentar remover uma coluna marcada, a operação falhará. Para desbloquear o pipeline, um usuário com as permissões de marca necessárias deve remover a marca, executar o pipeline para que a alteração do esquema seja bem-sucedida e, em seguida, reaplicar a marca para as colunas relevantes. Se a tag não for reaplicada, as consultas nos dados falharão porque a política ainda está em vigor, mas a tag esperada não está mais 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 no 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 fazer referência a uma UDF diferente.

Regras para vários filtros e máscaras

Somente 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 coluna e usuário determinados. Isso impede resultados ambíguos.

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

• Um filtro de nível de tabela ou máscara entra em conflito com uma política ABAC. Uma tabela ou coluna que já tem um filtro de linha ou máscara de coluna aplicado manualmente entra em conflito com qualquer filtro ou máscara definido pelo ABAC no mesmo destino.
• A cláusula de um filtro de USING COLUMNS linha faz referência a um MATCH COLUMNS alias que corresponde a várias colunas. A USING COLUMNS cláusula passa valores de coluna para a UDF. Se um MATCH COLUMNS alias 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 um argumento de entrada na USING COLUMNS cláusula de outra política.

Várias políticas ABAC poderão 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 à mesma UDF com os mesmos argumentos se resolvem em um mesmo filtro ou máscara, e não entram em conflito.

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

Quando Azure Databricks detecta vários filtros ou máscaras distintos durante a avaliação da política para um determinado usuário, ele 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 as políticas que têm sobreposição em seus principais e condições.
4. Resolva por:
   • Refinando condições de política. Atualizar cláusulas WHEN ou MATCH COLUMNS para serem mais específicas, de modo que políticas distintas sejam direcionadas a diferentes tabelas ou colunas.
   • Ajustando marcas controladas. Examine as atribuições de etiqueta em colunas ou tabelas que disparam acertos de políticas não intencionais e remova-as ou atualize-as.
   • Ajustando entidades de segurança. Atualize TO/EXCEPT cláusulas para que cada usuário esteja 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. Consolide políticas sobrepostas em uma única política ou divida políticas amplas em políticas separadas e explicitamente direcionadas.

Conversão automática de tipo para filtros de coluna

Azure Databricks converte automaticamente a entrada e a saída de funções de máscara de coluna derivadas 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 conversão automática funciona da seguinte maneira:

1. Execução da função de mascaramento: quando a avaliação de política determina que a máscara se aplica, a função de mascaramento é executada nos valores de coluna correspondentes.
2. Conversão automática de tipo: O Azure Databricks converte o valor da coluna de origem para coincidir com o tipo de parâmetro da função e ajusta 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, a conversão falhará e a consulta retornará um erro de runtime. O processo de conversão segue os padrões de SQL ANSI para CAST operações (detalhes completos de compatibilidade), com uma adição: no Databricks Runtime 18.1 e versões posteriores, as políticas de máscara de coluna ABAC podem converter structs para VARIANT, algo que não é suportado no SQL geral.

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