Controle de acesso baseado em atributos (ABAC) do Unity Catalog
Visualização
Este recurso está em Pré-visualização Pública.
Esta página descreve o controle de acesso baseado em atributos (ABAC) no Unity Catalog.
O que é ABAC?
O ABAC é um modelo de governança de dados que oferece controle de acesso flexível, dimensionável e centralizado no Databricks. O ABAC complementa o modelo de privilégio existente do Unity Catalog, permitindo que as políticas sejam definidas com base em tags governadas, que são aplicadas aos dados ativos. Isso simplifica a governança e fortalece a segurança.
Os usuários com permissões MANAGE ou propriedade de objetos só precisam definir políticas uma vez e podem aplicá-las de forma consistente em vários ativos de dados. As políticas são anexadas no nível do catálogo, do esquema ou da tabela e se aplicam automaticamente a todas as tabelas dentro desse escopo. Quando definidas em níveis mais altos, as políticas herdam objetos descendentes para secundários. As tags governadas nos dados ativos determinam quais políticas são aplicadas, permitindo que o controle de acesso se adapte dinamicamente.
Benefícios do ABAC
- Escalabilidade: gerencie os controles de acesso em escala, utilizando tags em vez de permissões individuais.
- Flexibilidade: Ajuste facilmente a governança atualizando tags ou políticas sem modificar cada ativo de dados.
- Governança centralizada: simplifique o gerenciamento de políticas por meio de um modelo unificado que abrange catálogos, esquemas e tabelas.
- Segurança aprimorada: aplique controles de acesso refinados dinamicamente com base nos atributos dos dados.
- Auditabilidade: Mantenha a visibilidade real do acesso aos dados por meio de uma auditoria abrangente logs.
Como funciona o ABAC
O ABAC no Unity Catalog usa tags governadas, políticas e funções definidas pelo usuário (UDFs) para impor um controle de acesso dinâmico e baseado em atributos. Os seguintes componentes e mecanismos são fundamentais para o ABAC:
-
Governado tags: Governado tags são definidos no nível account usando as políticas tag. Essas tags representam atributos como sensibilidade dos dados, classificação ou domínio de negócios e são atribuídas a tabelas, esquemas ou catálogos no Unity Catalog. Eles servem como atributos que impulsionam a aplicação de políticas. Consulte Governed tags e Apply tags to Unity Catalog securable objects.
-
Políticas: As políticas são criadas e gerenciadas em três níveis hierárquicos em Unity Catalog:
- Nível de catálogo: aplique políticas abrangentes que afetem todos os esquemas e tabelas contidos.
- Nível do esquema: aplique políticas específicas a um esquema e suas tabelas.
- Nível da tabela: aplique políticas refinadas diretamente em tabelas individuais.
As políticas seguem um modelo de herança : quando uma política é definida no nível do catálogo ou do esquema, ela se aplica automaticamente a todos os objetos secundários, esquemas e tabelas dentro desse escopo. Isso permite que os administradores implementem uma governança eficiente, aplicando uma única política que governa grandes conjuntos de dados ativos. As políticas herdadas reduzem a redundância e promovem a aplicação consistente em toda a hierarquia de dados. A Databricks recomenda a definição de políticas no nível mais alto aplicável, geralmente o catálogo, para maximizar a eficiência da governança e reduzir a sobrecarga administrativa. Consulte Criar e gerenciar políticas de controle de acesso baseado em atributos (ABAC).
-
Funções definidas pelo usuário (UDFs): As UDFs são funções personalizadas definidas no nível do esquema e podem ser referenciadas globalmente no espaço de nomes do Unity Catalog. As UDFs são usadas em políticas para expressar lógicas complexas, como filtrar linhas ou mascarar valores de colunas com base em atributos. Por exemplo, um UDF chamado
filter_regionpode ser usado em uma política de filtro de linha para retornar apenas as linhas em queregion = 'EMEA'. Consulte Funções definidas pelo usuário (UDFs) no Unity Catalog. -
Aplicação dinâmica: Quando um usuário tenta acessar um ativo de dados com tags, o Unity Catalog avalia as políticas aplicáveis com base nas tags e aplica os controles de acesso definidos.
Usuários explicitamente excluídos de uma política podem continuar a executar ações como clonagem profunda e superficial, e viagem do tempo nos dados subjacentes. No entanto, os usuários que não são excluídos das políticas ABAC estão sujeitos às mesmas limitações que se aplicam ao controle de acesso granular.
-
Registro de auditoria: Todas as operações em dados ativos marcados são capturadas e registradas na tabela do sistema de auditoria log, permitindo visibilidade abrangente e acompanhamento compliance. Consulte Auditoria logs.
Para saber como configurar o ABAC, consulte o tutorial: Configurar o ABAC.
Para obter uma demonstração da configuração do ABAC, consulte Descubra o controle de acesso baseado em atributos (ABAC) com o Unity Catalog.
Tipos de políticas
Há suporte para dois tipos de políticas ABAC:
-
As políticas de filtro de linha restringem o acesso a linhas individuais em uma tabela com base em seu conteúdo. Um UDF de filtro avalia se cada linha deve ser visível para um usuário. Essas políticas são úteis quando o acesso depende das características dos dados.
Exemplo de caso de uso: mostre somente linhas em uma tabela de transações de clientes em que a coluna da região corresponda a uma tag controlada, como
region=EMEA. Isso permite que as equipes regionais vejam somente dados relevantes para sua região. -
As políticas de máscara de coluna controlam quais valores os usuários veem em colunas específicas. Um UDF de mascaramento pode retornar o valor real ou uma versão editada, com base nas tags governadas.
Exemplo de caso de uso: Mascarar uma coluna que contém números de telefone, a menos que a tabela tenha a tag
sensitivity=lowou o usuário solicitante esteja em um grupo compliance. Os usuários sem acesso veem um valor nulo ou de espaço reservado, comoXXX-XXX-XXXX.
Consulte Criar e gerenciar políticas de controle de acesso baseado em atributos (ABAC).
Limitações
-
Para acessar uma tabela protegida por ABAC, você deve usar compute do Databricks Runtime 16.4 ou superior, ou compute serverless . Usuários que não estão sujeitos à política podem usar qualquer ambiente de execução.
-
Não é possível aplicar políticas ABAC diretamente à visualização. No entanto, ao consultar uma view baseada em tabelas com políticas ABAC, a identidade e as permissões do proprietário da view são usadas para avaliar as políticas. Isso significa:
- O proprietário view deve ter as permissões apropriadas nas tabelas subjacentes protegidas por ABAC.
- O acesso aos dados é avaliado com base nas permissões do proprietário view . Quando os usuários consultam a view, eles veem os dados filtrados ou mascarados da mesma forma que aparecem para o proprietário view .
- O comportamento pode variar dependendo da sua configuração compute . Para obter detalhes, consulte Requisitos para consultar a visualização.
-
As políticas relativas às tabelas de visualização materializada e de transmissão só são suportadas quando o proprietário pipeline está isento da política.
-
Os usuários podem compartilhar tabelas Delta protegidas por políticas ABAC se possuírem as permissões Delta Sharing necessárias e estiverem isentos das políticas ABAC. A política não rege o acesso do destinatário. Para provedores de compartilhamento, consulte Adicionar tabelas e esquemas protegidos por políticas ABAC a um compartilhamento. Para destinatários de compartilhamento, consulte Ler dados protegidos por ABAC e aplicar políticas ABAC.
-
Apenas um filtro de linha distinto pode ser resolvido em tempo de execução para uma determinada tabela e um determinado usuário. Você pode definir várias políticas de filtro de linhas, 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 distintos forem aplicados ao mesmo usuário e tabela, o Databricks bloqueará o acesso e exibirá um erro. É permitido ter várias políticas se elas resultarem no mesmo filtro (por exemplo, a mesma UDF com os mesmos argumentos). Consulte a seção Solução de problemas com vários filtros ou máscaras.
-
Apenas uma máscara de coluna distinta pode ser resolvida em tempo de execução para uma determinada coluna e um determinado usuário. Você pode definir várias políticas de máscara de coluna, mas quando um usuário consulta a tabela, apenas as condições de uma política precisam ser atendidas para cada coluna. Se várias máscaras de coluna distintas se aplicarem à mesma coluna para o mesmo usuário, o Databricks bloqueará o acesso e exibirá um erro. É permitido o uso de múltiplas políticas, desde que resultem na mesma máscara (por exemplo, a mesma UDF com os mesmos argumentos). Consulte a seção Solução de problemas com vários filtros ou máscaras.
-
Uma política ABAC pode incluir até três condições de coluna em sua cláusula
MATCH COLUMNS. -
Não existe uma tabela de esquema de informação para as políticas ABAC. As tabelas
information_schema.row_filterseinformation_schema.column_masksmostram apenas os filtros de linha e as máscaras de coluna que são aplicados diretamente às tabelas. 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 limitações do ABAC em compute dedicada, consulte Limitações.
Para limitações de filtros de linha e máscaras de coluna, consulte Limitações.