Controle de acesso no Catálogo Unity

Esta página tem uma visão geral do controle de acesso no Unity Catalog, incluindo privilégios, políticas e controles no nível de dados.

Camadas de controle de acesso

O controle de acesso no Unity Catalog é construído nos seguintes modelos complementares:

• As restrições no nível do espaço de trabalho controlam onde os usuários podem acessar dados, limitando objetos a espaços de trabalho específicos.
• Privilégios e controle de propriedadequem pode acessar o quê, usando concessões em objetos protegíveis.
• As políticas baseadas em atributos (ABAC) controlam quais dados os usuários podem acessar, usando tags controladas e políticas centralizadas.
• A filtragem e o mascaramento no nível da tabela controlam quais dados os usuários podem ver nas tabelas usando filtros e exibições específicos da tabela.

Esses modelos trabalham juntos para impor acesso seguro e refinado em todo o seu ambiente de dados.

Restrições no nível do espaço de trabalho

A vinculação de espaços de trabalho limita quais espaços de trabalho em sua conta podem acessar catálogos específicos, locais externos e credenciais de armazenamento. Esse controle de acesso acontece no nível do espaço de trabalho e se aplica independentemente dos privilégios de usuário ou grupo.

Por padrão, todos os catálogos, locais externos e credenciais de armazenamento no Unity Catalog são acessíveis a partir de qualquer espaço de trabalho anexado ao mesmo metastore. Usando associações, você pode:

• Restringir o acesso a um ou mais espaços de trabalho designados
• Tornar o acesso ao catálogo somente leitura a partir de determinados espaços de trabalho
• Isolar ambientes, por exemplo, restringir dados de produção a espaços de trabalho de produção
• Limitar o uso de locais externos e credenciais de armazenamento a espaços de trabalho específicos

Essas associações substituem as permissões no nível do usuário. Se um utilizador tiver privilégios em um objeto, mas tentar acessá-lo a partir de um espaço de trabalho não vinculado, o acesso será negado.

Para obter mais informações, consulte Limitar o acesso do catálogo a espaços de trabalho específicos.

Privilégios e propriedade

O acesso no Unity Catalog é regido principalmente por privilégios e propriedade do objeto. Esse modelo define quem pode acessar ou gerenciar dados e metadados atribuindo funções de administrador e concedendo privilégios e gerenciando a propriedade em objetos protegíveis. Esta seção descreve como os privilégios são concedidos, como a propriedade funciona e quais funções de administrador podem gerenciar o acesso em diferentes escopos.

Funções de administração

O Unity Catalog suporta várias funções de administrador:

• Administrador de conta: pode criar metastores, gerenciar identidades, atribuir administradores de metastore e gerenciar recursos no nível da conta, como Compartilhamento Delta e tabelas do sistema.
• Metastore admin: uma função opcional, mas poderosa, que pode gerenciar todos os objetos no metastore, transferir a propriedade e atribuir privilégios de nível superior, como CREATE CATALOG, CREATE EXTERNAL LOCATIONe muito mais.
• Administrador do espaço de trabalho: gerencia identidades, configurações no nível do espaço de trabalho e o catálogo do espaço de trabalho.

Para obter detalhes, consulte Privilégios de administrador no Catálogo Unity.

Propriedade do objeto

Cada objeto protegível, como um catálogo, esquema ou tabela, no Unity Catalog tem um proprietário. A propriedade concede controle total sobre esse objeto, incluindo a capacidade de:

• Ler ou modificar o objeto e seus metadados
• Conceder privilégios a outros utilizadores
• Transferir a propriedade para outro principal

O Unity Catalog também suporta um MANAGE privilégio, que permite aos usuários conceder acesso e modificar objetos sem torná-los proprietários.

Para obter mais informações sobre propriedade, consulte Gerenciar propriedade de objeto do Catálogo Unity.

Privilégios em objetos protegíveis

No Unity Catalog, o controle de acesso começa com privilégios. Você atribui privilégios como SELECT, MODIFYe USE SCHEMA a usuários e grupos em objetos protegíveis, como catálogos, esquemas, tabelas, modos de exibição, volumes e funções.

A imposição de privilégios é:

• Hierárquico: Concede permissões a objetos de nível superior, como catálogos, afetando em cascata objetos de nível inferior, como tabelas.
• Delegável: Cada objeto tem um proprietário que pode gerenciá-lo e conceder acesso a outros.
• Explícito: o acesso só é permitido quando um usuário ou grupo recebe os privilégios apropriados. Um usuário recebe a união de permissões de todos os grupos dos quais é membro.

Os utilizadores podem solicitar acesso a objetos que podem descobrir, seja por meio do privilégio BROWSE ou de uma URL direta para o objeto, ou quando encontrarem um erro de permissão negada nos notebooks ou no editor SQL. A Databricks recomenda a concessão de BROWSE nos catálogos ao grupo All account users para tornar os objetos descobertos e permitir que os utilizadores solicitem acesso. As solicitações de acesso são enviadas a destinos configurados, como correio eletrónico, Slack, Microsoft Teams, endpoints webhook ou uma URL de redirecionamento. Se nenhum destino estiver configurado, os usuários não poderão solicitar acesso ao objeto.

Para obter mais informações, consulte Gerenciar privilégios no Unity Catalog e privilégios e objetos protegíveis do Unity Catalog.

Cache de permissões para acesso baseado em caminhos

Para melhorar o desempenho do acesso baseado em caminhos ao armazenamento na cloud, o Unity Catalog pode armazenar em cache os resultados das verificações de permissões durante até 60 segundos por utilizador e percurso. Esta cache aplica-se a:

• Operações do sistema de ficheiros usando dbutils.fs comandos
• Consultas baseadas em caminhos usando Spark SQL

Devido ao comportamento de cache, a concessão ou revogação de permissão pode não se refletir imediatamente. Este comportamento afeta apenas o acesso baseado em caminhos. O acesso baseado no nome (por exemplo, SELECT * FROM catalog.schema.table) não é afetado por esta cache.

Controle de acesso baseado em atributos (ABAC)

O ABAC é uma estrutura de política centralizada e baseada em tags para impor o controle de acesso no Unity Catalog. Ele permite que os administradores definam políticas escaláveis que se aplicam dinamicamente em catálogos, esquemas e tabelas com base em tags controladas. As políticas podem filtrar dados ou mascarar valores confidenciais. A Databricks recomenda o uso do ABAC para governança centralizada e escalável, em vez de aplicar filtros ou máscaras individualmente em cada mesa.

O ABAC foi projetado como uma estrutura de uso geral para aplicar políticas de controle de acesso baseadas em atributos de metadados. Ele complementa os controles baseados em privilégios e oferece suporte à imposição refinada sem exigir configuração por objeto.

Principais funcionalidades:

• Políticas orientadas por tags: Defina políticas uma vez usando tags controladas e funções definidas pelo usuário (UDFs) e aplique-as de forma consistente em muitos ativos de dados.
• Aplicação hierárquica: Aplique políticas no nível de catálogo, esquema ou tabela com herança automática a objetos filho.
• Governança centralizada e escalável: Gerencie o acesso em escala sem atribuir privilégios individuais a cada objeto.
• Avaliação dinâmica: As decisões de acesso são avaliadas em tempo real com base nas tags e no contexto do usuário.

Para obter mais informações, consulte Controle de acesso baseado em atributo (ABAC) do Unity Catalog.

Filtragem e mascaramento ao nível da tabela

Esta seção aborda mecanismos que controlam quais dados os usuários podem ver no momento da consulta usando lógica específica da tabela. Estes são, entre outros:

• Filtros de linha e máscaras de coluna: aplique lógica diretamente às tabelas.
• Exibições dinâmicas: defina a lógica usando SQL em uma ou mais tabelas.

Essas abordagens podem ser usadas de forma independente ou ao lado do ABAC, dependendo do seu modelo de governança.

Filtros de linha e máscaras de coluna

Filtros de linha e máscaras de coluna aplicam funções de filtragem ou mascaramento diretamente em tabelas individuais usando UDFs. Eles são úteis quando você deseja impor a lógica por tabela sem gerenciamento centralizado de políticas.

Para saber mais, consulte Filtros de linha e máscaras de coluna.

Vistas dinâmicas

As exibições dinâmicas permitem definir a lógica em uma ou mais tabelas usando SQL. Eles são somente leitura e úteis para:

• Aplicação da lógica de transformação (por exemplo, junções e CASE instruções)
• Compartilhamento de dados filtrados usando o Delta Sharing, onde o ABAC não é suportado.

Para obter detalhes, consulte Criar um modo de exibição dinâmico.

Quando usar cada mecanismo de controle de acesso

As associações de espaço de trabalho, os privilégios e as políticas ABAC avaliam o acesso em diferentes níveis e foram projetados para serem usados juntos. A tabela a seguir os compara entre critérios comuns de controle de acesso: