Controle de acesso baseado em atributos (ABAC) do Unity Catalog

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 fornece controle de acesso flexível, escalável e centralizado no Azure Databricks. O ABAC complementa o modelo de privilégios existente do Unity Catalog, permitindo que as políticas sejam definidas com base em tags controladas, que são aplicadas a ativos de dados. Isto simplifica a governação e reforça a segurança.

Os usuários com MANAGE permissões ou propriedade de objeto só precisam definir políticas uma vez e podem aplicá-las de forma consistente em muitos ativos de dados. As políticas são anexadas no nível do catálogo, esquema ou tabela e se aplicam automaticamente a todas as tabelas dentro desse escopo. Quando definidas em níveis mais altos, as políticas herdam para baixo para objetos filho. As tags controladas em ativos de dados determinam quais políticas são aplicadas, permitindo que o controle de acesso se adapte dinamicamente.

Benefícios do ABAC

• Escalabilidade: Gerencie controles de acesso em escala aproveitando 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 melhorada: Imponha controles de acesso refinados dinamicamente com base em atributos de dados.
• Auditabilidade: Mantenha a visibilidade em tempo real do acesso aos dados por meio de logs de auditoria abrangentes.

Como funciona o ABAC

O ABAC no Unity Catalog usa tags controladas, 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 centrais para o ABAC:

• Tags governadas: As tags governadas são definidas no nível da conta usando políticas de tags. Essas tags representam atributos como sensibilidade de dados, classificação ou domínio comercial e são atribuídas a tabelas, esquemas ou catálogos no Unity Catalog. Eles servem como os atributos que impulsionam a aplicação de políticas. Consulte Tags controladas e Aplicar tags a objetos protegíveis do Unity Catalog.

• Políticas: As políticas são criadas e gerenciadas em três níveis hierárquicos no Unity Catalog:

  • Nível de catálogo: Aplique políticas gerais 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 ao nível de catálogo ou esquema, aplica-se automaticamente a todos os objetos, esquemas e tabelas subordinados nesse âmbito. Isso permite que os administradores implementem uma governança eficiente aplicando uma única política que governa grandes conjuntos de ativos de dados. 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 mais alto nível aplicável, geralmente o catálogo, para maximizar a eficiência de 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): UDFs são funções personalizadas definidas no nível do esquema e podem ser referenciadas globalmente no namespace do Unity Catalog. As UDFs são usadas dentro de políticas para expressar lógica complexa, como filtrar linhas ou mascarar valores de coluna com base em atributos. Por exemplo, um UDF nomeado filter_region pode ser usado em uma política de filtro de linha para retornar apenas linhas onde region = 'EMEA'. Consulte Funções definidas pelo usuário (UDFs) no Catálogo Unity.

• Aplicação dinâmica: Quando um usuário tenta acessar um ativo de dados marcado, o Unity Catalog avalia as políticas aplicáveis com base nas tags e impõe os controles de acesso definidos.

  Os usuários que são explicitamente excluídos de uma política podem continuar a executar ações como clonagem profunda e superficial e viagem no 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 refinado.

• Registo de auditoria: Todas as operações em ativos de dados marcados são capturadas e registradas na tabela do sistema de log de auditoria, permitindo visibilidade abrangente e acompanhamento de conformidade. Consulte Logs de auditoria.

Para saber como configurar o ABAC, consulte Tutorial: Configurar o ABAC.

Para obter uma demonstração da configuração do ABAC, consulte Discover Attribute-Based Access Control (ABAC) with Unity Catalog.

Tipos de políticas

São suportados 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 filtro UDF 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: Mostrar apenas linhas em uma tabela de transações do cliente em que a coluna da região corresponda a uma marca controlada, como region=EMEA. Isso permite que as equipes regionais vejam apenas dados relevantes para sua região.

• As políticas de máscara de coluna controlam os valores que os usuários veem em colunas específicas. Um UDF de mascaramento pode retornar o valor real ou uma versão editada, com base em tags controladas.

  Exemplo de caso de uso: Mascare uma coluna contendo números de telefone, a menos que a tabela esteja marcada sensitivity=low ou o usuário solicitante esteja em um grupo de conformidade. Os usuários sem acesso veem um valor nulo ou de espaço reservado, como XXX-XXX-XXXX.

Consulte Criar e gerenciar políticas de controle de acesso baseado em atributos (ABAC).

Limitações

• Deve usar computação em Databricks Runtime 16.4 ou superior, ou computação serverless, para aceder a uma tabela protegida por ABAC. Utilizadores que não estão sujeitos à política podem usar qualquer runtime.
• Não pode aplicar as políticas ABAC diretamente às opiniões. No entanto, quando consulta uma vista baseada em tabelas com políticas ABAC, a identidade e as permissões do proprietário da vista são usadas para avaliar as políticas. Isto significa:
  • O proprietário da vista 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 da visualização. Quando os utilizadores consultam a visualização, veem os dados filtrados ou mascarados tal como aparecem ao proprietário da visualização.
  • O comportamento pode variar consoante a sua configuração de computação. Para detalhes, consulte Requisitos para consultar visualizações.
• As políticas sobre visualizações materializadas e tabelas de streaming só são suportadas quando o proprietário do pipeline está isento da política.
• Os usuários podem compartilhar tabelas Delta protegidas por políticas ABAC se tiverem as permissões de Compartilhamento Delta 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 recetores de partilha, consulte Ler dados ABAC protegidos e aplicar políticas ABAC.
• Apenas um filtro de linha distinto pode ser resolvido em tempo de execução para uma dada tabela e para um determinado utilizador. Pode definir várias políticas de filtro de linhas, mas quando um utilizador consulta a tabela, apenas as condições de uma política devem corresponder. Se vários filtros de linha distintos se aplicarem ao mesmo utilizador e à mesma tabela, o Azure Databricks bloqueia o acesso e gera um erro. Múltiplas políticas são permitidas se resultarem no mesmo filtro (por exemplo, a mesma UDF com os mesmos argumentos). Consulte Solução de problemas de 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 para um determinado utilizador. Pode definir múltiplas políticas de máscaras de colunas, mas quando um utilizador consulta a tabela, apenas as condições de uma política devem corresponder para cada coluna. Se várias máscaras de coluna distintas se aplicarem à mesma coluna para o mesmo utilizador, o Azure Databricks bloqueia o acesso e gera um erro. Múltiplas políticas são permitidas se resultarem na mesma máscara (por exemplo, a mesma UDF com os mesmos argumentos). Consulte Solução de problemas de vários filtros ou máscaras.
• Uma apólice ABAC pode incluir até três condições de coluna em sua MATCH COLUMNS cláusula.
• Não existe uma tabela de esquemas de informação para as políticas ABAC. As tabelas information_schema.row_filters e information_schema.column_masks mostram apenas os filtros de linhas e as máscaras de coluna que são aplicados diretamente nas tabelas. Não mostram as definições das políticas ABAC nem os filtros e máscaras derivados das políticas ABAC em tempo de execução.
• Para conhecer as limitações do ABAC na computação dedicada, consulte Limitações.

Para obter as limitações dos filtros de linha e das máscaras de coluna, consulte Limitações.