Pular para o conteúdo principal

Requisitos, quotas e limitações do ABAC

Esta página lista os requisitos, as quotas de políticas e as limitações atuais para o controle de acesso baseado em atributos (ABAC) no Unity Catalog.

requisitos de computação

Para usar as políticas ABAC, você deve usar uma das seguintes configurações compute :

Para obter orientações sobre como executar cargas de trabalho que exigem tempos de execução mais antigos, consulte Acesso a partir de tempos de execução mais antigos.

Requisito tags regulamentadas

As políticas ABAC usam tags regulamentadas, não tags não regulamentadas. tags governadas são definidas no nível account com controles de acesso que determinam quem pode criá-las, atribuí-las e gerenciá-las. Para obter detalhes completos, consulte tagsregulamentadas.

nota

Após atribuir ou modificar uma tag, pode levar alguns minutos para que a alteração entre em vigor.

Cotas de política

Recursos

Limite

Políticas por metastore

10.000

Políticas por catálogo ou esquema

100

Políticas por mesa

50

Princípios por política (aplica-se às cláusulas TO e EXCEPT )

20

Condições de coluna por cláusula MATCH COLUMNS

3

Para obter mais detalhes, incluindo as quotas de tags regulamentadas, consulte Limites de serviço.

Limitações do ABAC

Acesso a partir de ambientes de execução mais antigos

compute padrão e dedicados do Databricks Runtime , em versões anteriores à 16.4, não conseguem acessar tabelas protegidas por ABAC. Se você precisar que determinadas cargas de trabalho continuem sendo executadas em um ambiente de execução mais antigo, defina o escopo da política ABAC para um grupo específico em vez de aplicá-la de forma ampla. Adicione apenas os usuários ou entidades que você deseja que a política se aplique a esse grupo e exclua a entidade que executa a carga de trabalho de tempo de execução mais antiga usando a cláusula EXCEPT . Usuários externos ao grupo mantêm acesso total às tabelas subjacentes. Isso permite que essa carga de trabalho continue acessando as tabelas enquanto você faz a transição para um ambiente de execução compatível.

Políticas da ABAC em exibição

Não é possível aplicar políticas ABAC diretamente à visualização. No entanto, quando um usuário consulta uma view que faz referência a tabelas com políticas ABAC, essas políticas são respeitadas ao acessar os dados por meio da view.

Os filtros de linha e as máscaras de coluna ABAC nas tabelas subjacentes são avaliados usando a identidade do usuário da sessão , ou seja, a pessoa que executa a consulta. O usuário vê apenas as linhas e os valores das colunas aos quais está autorizado a acessar, conforme definido pelas políticas ABAC nas tabelas base. As verificações de acesso à tabela base e as verificações de acesso às dependências usam a identidade do proprietário view , para que os usuários possam consultar a visualização sem privilégios diretos nas tabelas subjacentes.

nota

O mesmo modelo de identidade de usuário da sessão se aplica quando tabelas com políticas ABAC são acessadas por meio de funções.

O modelo de identidade de usuário de sessão foi introduzido juntamente com o lançamento da versão GA do ABAC. Anteriormente, as políticas eram avaliadas usando a identidade do proprietário view ou do definidor da função. Para mais informações, consulte as notas sobre a versão de abril de 2026.

Políticas ABAC sobre visão materializada e tabelas de transmissão

nota

Anteriormente, as políticas ABAC em tabelas de visualização materializada e de transmissão eram suportadas apenas quando o proprietário pipeline ou a identidade de execução estava isenta da política. Essa limitação foi removida.

Quando um pipeline atualiza uma view materializada ou uma tabela de transmissão, as políticas são avaliadas usando a identidade do proprietário pipeline ou a identidade de execução. Se essa identidade estiver sujeita à política, a view materializada ou a tabela de transmissão conterá permanentemente dados mascarados ou filtrados. Databricks recomenda manter a isenção de identidade refresh usando a cláusula EXCEPT e direcionar os consumidores que devem ver dados mascarados ou filtrados na cláusula TO .

Delta Sharing de tabelas com políticas ABAC ou visualizações que fazem referência a elas.

Tabelas com políticas ABAC ou visualizações que referenciam tabelas com políticas ABAC só podem ser compartilhadas por meio Delta Sharing se o proprietário do compartilhamento estiver isento da política (listado na cláusula EXCEPT ). A política não regula o acesso do destinatário. Os destinatários podem aplicar suas próprias políticas ABAC às tabelas compartilhadas para impor o controle de acesso em seu próprio ambiente.

Para obter detalhes sobre como usar Delta Sharing com o ABAC, consulte Delta Sharing e ABAC.

viagem do tempo e clonagem em tabelas com políticas ABAC

As políticas ABAC não podem ser avaliadas em relação ao Snapshot da tabela histórica, portanto, as consultas de viagem do tempo falham em tabelas com filtros de linha ou máscaras de coluna ativos. Clones profundos e superficiais também não são suportados em tabelas com políticas ABAC.

Para habilitar essas operações, crie uma entidade de serviço ou grupo e adicione-a à cláusula EXCEPT da política. A apólice não é avaliada para diretores isentos, portanto essas operações podem ser executadas.

importante

Os diretores isentos visualizam dados não filtrados e não mascarados. Somente identidades confiáveis, como entidades de serviço usadas para cargas de trabalho ETL ou pipeline , devem ser isentas.

Por exemplo, a política a seguir mascara colunas PII para todos os usuários, exceto etl_service_principal, que pode executar consultas de viagem do tempo e clonar operações:

SQL
CREATE POLICY mask_pii
ON CATALOG prod
COLUMN MASK prod.governance.mask_value
TO `account users`
EXCEPT `etl_service_principal`
FOR TABLES
MATCH COLUMNS
has_tag_value('pii', 'ssn') AS ssn
ON COLUMN ssn;

Índices de pesquisa vetorial e políticas ABAC

As políticas ABAC em uma tabela de origem não se aplicam aos índices de pesquisa vetorial criados a partir dessa tabela. O índice sincroniza todas as linhas da tabela de origem e não impõe políticas de filtro de linha ou máscara de coluna ao atender às consultas.

Para tabelas com máscaras de coluna, você pode excluir as colunas mascaradas do índice usando a configuração "Colunas a sincronizar" .

Várias políticas na mesma tabela ou coluna para o mesmo usuário.

Apenas um filtro de linha distinto pode ser resolvido em tempo de execução para uma determinada tabela e um determinado usuário, e apenas uma máscara de coluna distinta pode ser resolvida para uma determinada coluna e um determinado usuário. Você pode definir várias políticas, mas quando um usuário consulta a tabela, apenas as condições de uma política precisam ser atendidas. Se vários filtros de linha ou máscaras de coluna distintos se aplicarem ao mesmo usuário e tabela ou coluna, o Databricks bloqueará o acesso e retornará um erro. É permitida a utilização de múltiplas políticas, desde que elas resultem na mesma UDF (função definida pelo usuário) de filtro de linha ou máscara de coluna com os mesmos argumentos.

Para mais detalhes, consulte as Regras para múltiplos filtros e máscaras.

Políticas ABAC e esquema de informação

Não há tabela de esquema de informação para políticas ABAC. As tabelas information_schema.row_filters e information_schema.column_masks mostram apenas filtros de linha e máscaras de coluna em nível de tabela. Eles não exibem as definições de política ABAC nem os filtros e máscaras derivados das políticas ABAC em tempo de execução.

Para listar as políticas ABAC, use a APIREST Unity Catalog . Os eventos de criação, modificação e exclusão de políticas são registrados na tabela de log de auditoria do sistema.

ABAC em computededicada

Para limitações do ABAC em compute dedicada, consulte Limitações.

Limitações comuns ao ABAC e aos filtros de linha e máscara de coluna em nível de tabela.

Para limitações gerais de filtros de linha e máscaras de coluna que se aplicam tanto a filtros de linha e máscaras de coluna em nível ABAC quanto em nível de tabela, consulte Limitações.