Avaliação de políticas de filtro de linha e mascaramento de coluna 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 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 Unity Catalog executa as seguintes etapas usando os metadados do objeto protegível (por exemplo, atribuições de tag governada) e a identidade do usuário que faz a consulta e seus pertencimentos a grupos:

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 executá-las, a entidade deve ser listada na cláusula EXCEPT 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:

• Acesso a 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
• OpenSharing, em que o proprietário do compartilhamento deve ser isento da política e ter as permissões de OpenSharing necessárias. Observe que a política não rege o acesso do destinatário.
• Criação e sincronização de índice da Pesquisa de IA

Para obter mais detalhes sobre essas e outras limitações, consulte Requisitos, cotas e limitações para políticas de filtro de linha e máscara de coluna.

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 tag governada à qual uma política ABAC faz referência, todas as consultas do objeto ao qual a política está anexada e os objetos filhos 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 pipelines declarativos e outros fluxos de trabalho automatizados 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.

Condições do atributo identidade

As funções de atributo identidade (has_identity_attribute_value e has_identity_attribute_tag_match) resolvem da seguinte forma:

• Se o usuário não tiver valor para o atributo, não tiver atributo algum, ou se a política especificar um atributo que não existe, a função retorna false. Isso não gera erro. Como um valor ausente retorna false, formule as condições de modo que um valor ausente restrinja o acesso em vez de concedê-lo.
• Se uma política aprova has_identity_attribute_tag_match uma chave de tag governada que não existe, a criação de políticas falha.

Condições de atributo de contexto

As funções de atributos de contexto (has_context_attribute e has_context_attribute_value) resolvem da seguinte forma:

• request.client_id está presente apenas em alguns caminhos de requisição. É definido para solicitações em nome de outro usuário feitas por meio de um aplicativo OAuth e, caso contrário, não está presente. request.is_on_behalf_of está presente com valor de 'true' ou 'false', ou está ausente em caminhos de computação não suportados.
• Quando um atributo reconhecido não está presente na solicitação, a função retorna false; ela não gera erro. Formule as condições de modo que esse resultado restrinja o acesso, em vez de concedê-lo.
• Uma chave que não é um atributo reconhecido request.* , como uma chave com erro ortográfico, gera um erro de avaliação em vez de resolver para false. Use os nomes exatos request.client_id e request.is_on_behalf_of.

Se você desativar a versão prévia de Atributos de Contexto do UC ABAC enquanto ainda existirem políticas de filtro de linha ou políticas de mascaramento de coluna que usam essas funções, as consultas aos dados afetados falharão com UC_ABAC_CONTEXT_ATTRIBUTE_FUNCTIONS_DISABLED, em vez de simplesmente não retornar nenhuma linha. A gestão de políticas não é afetada. Você ainda pode listar, alterar e eliminar políticas. Remova ou reescreva políticas de atributos de contexto antes de desativar o recurso.

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 runtime 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 USING COLUMNS de um filtro de linha faz referência a um alias MATCH COLUMNS 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 nas entidades TO/EXCEPT e condições WHEN/MATCH COLUMNS.
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 tags controladas. Examine as atribuições de tag em colunas ou tabelas que disparam correspondências de políticas não intencionais e remova-as ou atualize-as.
   • Ajustando entidades. 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 máscaras de coluna

O 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 operações CAST (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 estruturas em 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 conversão para obter exemplos e a abordagem VARIANT para mascaramento flexível entre tipos de coluna.