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

Esta página descreve o ABAC (controle de acesso baseado em atributo) no Catálogo do Unity.

O que é ABAC?

O ABAC é um modelo de governança de dados que fornece controle de acesso flexível, escalonável e centralizado no Azure Databricks. O ABAC complementa o modelo de privilégio existente do Catálogo do Unity, permitindo que as políticas sejam definidas com base em etiquetas governadas, que são aplicadas aos ativos de dados. Isso simplifica a governança 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 consistentemente em muitos ativos de dados. As políticas são anexadas no nível de 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. Marcas governadas em ativos de dados determinam quais políticas são impostas, permitindo que o controle de acesso se adapte dinamicamente.

Benefícios do ABAC

• Escalabilidade: Gerencie controles de acesso em escala aproveitando marcas em vez de permissões individuais.
• Flexibilidade: Ajuste facilmente a governança atualizando marcas 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: Imponha controles de acesso refinados dinamicamente com base em atributos de dados.
• Capacidade de auditoria: Mantenha a visibilidade em tempo real do acesso a dados por meio de logs de auditoria abrangentes.

Como o ABAC funciona

O ABAC no Catálogo do Unity usa marcas governadas, políticas e UDFs (funções definidas pelo usuário) para impor controle de acesso dinâmico baseado em atributo. Os seguintes componentes e mecanismos são centrais para o ABAC:

• Marcas governadas: As marcas governadas são definidas no nível da conta usando políticas de marca. Essas marcas representam atributos como confidencialidade de dados, classificação ou domínio de negócios e são atribuídas a tabelas, esquemas ou catálogos no Catálogo do Unity. Eles servem como atributos que impulsionam a imposição da política. Consulte marcas governadas e aplicar marcas a objetos protegíveis do Catálogo do Unity.

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

  • Nível do catálogo: Aplique políticas amplas que afetam todos os esquemas e tabelas contidos.
  • Nível de 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 de catálogo ou esquema, ela se aplica automaticamente a todos os objetos filho, esquemas e tabelas dentro desse escopo. Isso permite que os administradores implementem uma governança eficiente aplicando uma única política que rege grandes conjuntos de ativos de dados. As políticas herdadas reduzem a redundância e promovem a imposição consistente na hierarquia de dados. O Databricks recomenda definir políticas no nível mais alto 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 ABAC (controle de acesso baseado em atributo).

• 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 catálogo do Unity. UDFs são usados 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 em que region = 'EMEA'. Consulte UDFs (funções definidas pelo usuário) no Catálogo do Unity.

• Imposição dinâmica: Quando um usuário tenta acessar um ativo de dados marcado, o Catálogo do Unity avalia as políticas aplicáveis com base nas marcas 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 viagens 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 em nível granular.

• Log 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 os logs de auditoria.

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

Para obter uma demonstração de configuração do ABAC, consulte Descobrir o ABAC (Controle de Acesso Attribute-Based) com o Catálogo do Unity.

Tipos de política

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 estar visível para um usuário. Essas políticas são úteis quando o acesso depende de características de dados.

  Exemplo de caso de uso: Mostrar somente linhas em uma tabela de transações do cliente em que a coluna de região corresponde a uma marca governada, 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 quais valores os usuários veem em colunas específicas. Uma UDF mascarada pode retornar o valor real ou uma versão redigida, com base em marcas governadas.

  Exemplo de caso de uso: Mascarar uma coluna que contém 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 ABAC (controle de acesso baseado em atributo).

Limitações

• Você deve usar a computação no Databricks Runtime 16.4 ou superior, ou computação sem servidor, para acessar uma tabela protegida pelo ABAC. Os usuários que não estão sujeitos à política podem usar qualquer runtime.
• Não é possível aplicar políticas ABAC diretamente a exibições. No entanto, quando você consulta uma exibição baseada em tabelas com políticas ABAC, a identidade e as permissões do proprietário da exibição são usadas para avaliar as políticas. Isso significa:
  • O proprietário da visualização deve ter permissões apropriadas nas tabelas subjacentes protegidas por ABAC.
  • O acesso a dados é avaliado com base nas permissões do proprietário da exibição. Quando os usuários consultam a visão, eles veem os dados filtrados ou mascarados como aparecem para o proprietário da visão.
  • O comportamento pode variar dependendo da configuração de computação. Para obter detalhes, consulte Requisitos para consultar exibições.
• As políticas sobre visões materializadas e tabelas de streaming são suportadas apenas quando o proprietário do pipeline está isento da referida 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 os destinatários de compartilhamento, consulte Ler dados protegidos pelo ABAC e aplicar políticas ABAC.
• Somente um filtro de linha distinto pode ser resolvido em runtime para uma determinada tabela e um determinado usuário. Você pode definir várias políticas de filtro de linha, mas quando um usuário consulta a tabela, apenas as condições de uma política devem corresponder. Se vários filtros de linha distintos se aplicarem ao mesmo usuário e tabela, o Azure Databricks bloqueará o acesso e gerará um erro. Várias políticas serão permitidas se resultarem no mesmo filtro (por exemplo, o mesmo 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 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 devem corresponder a cada coluna. Se várias máscaras de coluna distintas se aplicarem à mesma coluna para o mesmo usuário, o Azure Databricks bloqueará o acesso e gerará um erro. Várias 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 política ABAC pode incluir até três condições de coluna na cláusula MATCH COLUMNS.
• Não há nenhuma tabela de esquema de informações para políticas ABAC. As tabelas information_schema.row_filters e information_schema.column_masks mostram apenas os filtros de linha e as máscaras de coluna que são aplicadas diretamente às tabelas. Eles não mostram definições das políticas ABAC ou os filtros e máscaras derivados de políticas ABAC durante a execução.
• Para obter limitações do ABAC na computação dedicada, consulte Limitações.

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