Conceitos do modelo de permissão do Catálogo Unity

Esta página explica os principais conceitos do modelo de permissões do Catálogo do Unity, incluindo o modelo de objeto, privilégios, propriedade e herança.

Para obter uma referência geral de todos os privilégios do Catálogo do Unity, consulte a referência de privilégios do Catálogo do Unity. Para obter instruções sobre como conceder e revogar privilégios, consulte Mostrar, conceder e revogar privilégios.

Objetos protegíveis

No Catálogo do Unity, dados e metadados residem em um contêiner de nível superior chamado metastore. Nesse metastore, os dados são representados como objetos em um namespace de três níveis: catalog.schema.table. Essa estrutura hierárquica também fornece a base para o controle de acesso no Catálogo do Unity.

Cada objeto nessa hierarquia é um objeto protegível. O controle de acesso no Catálogo do Unity funciona concedendo privilégios, como SELECT, MODIFYou USE SCHEMA, nesses objetos protegíveis. Esse modelo fornece controle refinado sobre quem pode acessar e gerenciar dados em toda a sua organização.

Para obter uma lista completa de objetos protegíveis e os privilégios que se aplicam a cada um, consulte a referência de privilégios do Catálogo do Unity.

Objetos de contêiner

Alguns objetos protegíveis no Catálogo do Unity são objetos de contêiner, o que significa que contêm objetos filhos dentro da hierarquia. Os objetos de contêiner têm uma função especial no modelo de permissões porque os privilégios concedidos a eles podem afetar seus filhos por meio da herança.

Veja a seguir os objetos de contêiner no Catálogo do Unity:

• Catálogos: o nível superior do namespace de três níveis. Os catálogos contêm esquemas como filhos diretos.
• Esquemas: o nível médio do namespace de três níveis. Os esquemas contêm tabelas, visualizações, volumes e funções como filhos diretos.

Objetos de contêiner têm várias características importantes:

Objetos que não são container, como tabelas, visualizações, volumes e funções, não contêm objetos filhos.

Privilégios

Os privilégios determinam quais ações um usuário ou grupo pode executar em um objeto protegível. Os privilégios comuns incluem:

• SELECT: Ler dados de tabelas ou visões
• MODIFY: gravar dados em tabelas ou exibições
• USE CATALOG: acessar um catálogo (requer privilégios adicionais para trabalhar com objetos filhos)
• USE SCHEMA: Acessar um esquema (requer privilégios adicionais para trabalhar com objetos secundários)
• CREATE TABLE: criar tabelas dentro de um esquema

Um usuário ou grupo deve receber explicitamente um privilégio para executar uma ação.

As seções a seguir descrevem privilégios especiais importantes no Azure Databricks. Para obter uma referência completa de todos os privilégios, consulte a referência de privilégios do Catálogo do Unity.

Privilégios de uso

USE CATALOG e USE SCHEMA são privilégios de uso. Em geral, os privilégios de uso são um pré-requisito para interagir com um objeto e seus subobjetos na hierarquia.

Para trabalhar com qualquer objeto em um catálogo, você precisa do USE CATALOG privilégio no catálogo, e para trabalhar com qualquer objeto em um esquema, você precisa do USE SCHEMA privilégio sobre o esquema. Gerenciar um objeto com esse MANAGE privilégio é uma exceção, com requisitos reduzidos de privilégios de uso. Veja Requisitos de privilégio de uso para MANAGE.

Por exemplo, para executar a maioria das operações em tabelas, exibições, volumes ou funções, você precisa:

1. USE CATALOG no catálogo pai
2. USE SCHEMA no esquema pai
3. O privilégio específico para a operação (como SELECT, MODIFYou EXECUTE)

Todos os três são necessários. Ter apenas o privilégio SELECT em uma tabela não é suficiente para lê-la se você não tiver USE CATALOG ou USE SCHEMA em seus objetos pai.

Os privilégios de uso fornecem um mecanismo de controle de acesso importante para administradores de nível superior. Por exemplo, mesmo que um proprietário de tabela queira compartilhar sua tabela com outros usuários, esses usuários não poderão acessar a tabela sem privilégios USE CATALOG e USE SCHEMA nos objetos pai. Como somente os proprietários de catálogo e esquema ou usuários com o MANAGE privilégio podem conceder esses privilégios de uso, isso impede que os proprietários de tabela concedam acesso fora dos limites aprovados.

Requisitos de privilégio de uso para MANAGE

O MANAGE privilégio tem requisitos reduzidos de privilégios de uso. Para exercer MANAGE, você não precisa de um privilégio de uso no nível onde MANAGE é concedido: MANAGE em um catálogo não requer USE CATALOG sobre esse catálogo, e MANAGE em um esquema não exige USE SCHEMA sobre esse esquema. Você precisa do privilégio de uso apenas nos níveis do contêiner estritamente acima do nível em que você tem MANAGE, não nesse nível nem abaixo dele. Em cada um desses níveis superiores, você pode satisfazer o requisito com USE CATALOG ou USE SCHEMA ou com propriedade ou MANAGE. Como MANAGE em um contêiner é herdado por todos os seus objetos filhos, ter MANAGE em um nível superior significa que você não precisa de privilégios de uso abaixo dele. Por exemplo:

• MANAGE em um catálogo não requer privilégios de uso. Você pode gerenciar o catálogo e qualquer esquema, tabela ou outro objeto dentro dele sem USE CATALOG ou USE SCHEMA.
• MANAGE em um esquema requer USE CATALOG no catálogo pai (ou propriedade ou MANAGE nesse catálogo), mas não USE SCHEMA no esquema.
• MANAGE em um objeto que não seja um contêiner, como uma tabela, visualização, volume ou função, requer USE CATALOG no catálogo pai e USE SCHEMA no esquema pai (ou propriedade ou MANAGE em qualquer um dos pais).

Essa redução se aplica apenas aos recursos de metadados que MANAGE e quaisquer privilégios derivados de MANAGE, como READ METADATA, fornecem. Privilégios de acesso a dados como SELECT e MODIFY ainda requerem USE CATALOG e USE SCHEMA, mesmo para usuários com MANAGE. Para mais informações sobre o que MANAGE permite, veja O MANAGE privilégio.

A tabela a seguir mostra operações comuns e seus privilégios necessários:

ALL PRIVILEGES Comportamento

ALL PRIVILEGESimplica todos os privilégios aplicáveis para um tipo de objeto específico, sem que o Azure Databricks conceda explicitamente cada privilégio individual. Por exemplo:

• ALL PRIVILEGES em uma tabela implica a capacidade de executar SELECT, MODIFYe APPLY TAG.
• ALL PRIVILEGES em um volume implica a capacidade de executar READ VOLUME, WRITE VOLUMEe APPLY TAG.
• ALL PRIVILEGES em um esquema implica todos os privilégios no nível do esquema.
• ALL PRIVILEGES em um catálogo implica todos os privilégios de nível de catálogo.

ALL PRIVILEGES não inclui os EXTERNAL USE SCHEMA, EXTERNAL USE LOCATION, MANAGE, ou READ METADATA privilégios.

Para obter mais detalhes sobre como ALL PRIVILEGES é avaliado e revogado, consulte TODOS os PRIVILÉGIOS.

O MANAGE privilégio

O MANAGE privilégio permite que os usuários gerenciem privilégios, transfiram a propriedade e excluam um objeto sem ser o proprietário. Ter MANAGE é semelhante à propriedade, mas há algumas diferenças importantes. Consulte Propriedade versus MANAGE privilégio.

Para exercer MANAGE, os usuários precisam dos privilégios de uso apropriados nos contêineres pais acima do objeto onde MANAGE é concedido, mas não nesse objeto em si. Por exemplo, MANAGE em um catálogo não requer nenhum privilégio de uso. Para detalhes completos, veja Requisitos de privilégio de uso para MANAGE.

Se MANAGE for concedido em um objeto contêiner, o usuário também receberá MANAGE em todos os objetos filho.

Para obter detalhes completos, consulte MANAGE.

O BROWSE privilégio

BROWSE permite que os usuários descubram objetos e exibam seus metadados sem conceder acesso aos dados subjacentes. Os usuários com BROWSE podem ver que um objeto existe, exibir seu nome, descrição e marcas e solicitar acesso a ele sem necessidade USE CATALOG ou USE SCHEMA.

BROWSE é concedido no nível do catálogo e se aplica a todos os objetos dentro desse catálogo. O Databricks recomenda conceder BROWSE em catálogos ao grupo All account users para tornar os dados detectáveis ​​em toda a sua organização.

Para obter detalhes completos, consulte BROWSE.

Privilégios compostos e filhos

Alguns privilégios estão relacionados por meio de um relacionamento composto-filho. Um privilégio composto concede um amplo conjunto de capacidades, e cada um de seus privilégios de filho concede um subconjunto dessas capacidades. Privilégios para crianças permitem que você delegue parte do acesso de um privilégio composto sem conceder o privilégio total.

Privilégios compostos e de criança são concedidos e revogados de forma independente. Conceder um privilégio composto não concede privilégios para crianças, e revogar um privilégio composto não revoga nenhum privilégio de criança concedido explicitamente.

A seguir, exemplos de privilégios compostos e filhos:

• MANAGE é um privilégio composto. READ METADATA é um elemento filho de MANAGE que concede acesso somente leitura aos metadados de um objeto, sem os recursos de modificação e gerenciamento incluídos em MANAGE. Veja LEIA OS METADADOS.
• MODIFY é um privilégio composto, e INSERT, UPDATE, e DELETE (Beta) são seus filhos. Cada um concede um subconjunto das permissões de escrita que MODIFY fornece. Consulte Privilégios DML refinados.

Propriedade

Cada objeto protegível no Catálogo do Unity tem um proprietário. O proprietário pode ser um usuário, entidade de serviço ou grupo. A entidade principal que cria um objeto se torna seu proprietário inicial.

A propriedade tem uma denotação especial no Unity Catalog. Os proprietários de objetos podem executar automaticamente todos os recursos no objeto que possuem. No entanto, o Azure Databricks não concede explicitamente o ALL PRIVILEGES privilégio ao proprietário. Isso significa que você não verá ALL PRIVILEGES retornado ao listar permissões usando a API do Databricks ou com um SHOW GRANTS comando.

A propriedade não é transmitida para níveis inferiores no Unity Catalog. No entanto, os proprietários de objetos têm automaticamente a capacidade de gerenciar todos os objetos filho. Por exemplo, se você for o proprietário de um catálogo, você não será automaticamente o proprietário dos esquemas filhos dentro do catálogo, mas poderá gerenciar todos os esquemas filhos. Assim como os proprietários têm todas as capacidades em seus objetos sem terem explicitamente ALL PRIVILEGES, o Azure Databricks também não concede explicitamente o privilégio MANAGE neste caso.

Os proprietários de objetos podem executar outras operações importantes no objeto, incluindo conceder e revogar permissões, transferir a propriedade e remover o objeto.

Para resumir, o proprietário de um objeto pode fazer o seguinte:

Para obter informações sobre como exibir e transferir a propriedade, consulte Gerenciar a propriedade do objeto.

Propriedade versus privilégio MANAGE

O MANAGE privilégio concede a um usuário a capacidade de conceder e revogar privilégios no objeto. Ele não concede ao usuário todos os privilégios no objeto. No entanto, os usuários com MANAGE podem conceder a si mesmos explicitamente privilégios de acesso a dados, como SELECT.

Por outro lado, os proprietários de objetos têm todos os recursos em seu objeto por padrão. Como a propriedade não é herdada para os objetos filhos, os proprietários ainda precisam de concessões explícitas nesses objetos filhos.

Os requisitos de privilégio de uso são os mesmos para ambos os casos: proprietários e usuários com MANAGE precisam dos privilégios de uso apropriados nos contêineres pai do objeto, mas não no próprio objeto. Veja Requisitos de privilégio de uso para MANAGE.

A tabela a seguir resume as principais diferenças entre a propriedade e o MANAGE privilégio:

Para evitar o escalonamento acidental de privilégios, o ALL PRIVILEGES privilégio não inclui o MANAGE privilégio.

Herança de privilégio

A herança de privilégios é um recurso fundamental do modelo de permissões do Catálogo do Unity. Quando você concede um privilégio em um objeto pai, esse privilégio se aplica automaticamente a todos os objetos filhos atuais e futuros. Isso simplifica o gerenciamento de acesso reduzindo o número de concessões individuais que você precisa fazer.

Os privilégios herdam para baixo por meio da hierarquia do modelo de objeto:

• Um privilégio concedido em um catálogo se aplica a todos os esquemas nesse catálogo e a todas as tabelas, exibições, volumes e funções nesses esquemas
• Um privilégio concedido em um esquema se aplica a todas as tabelas, exibições, volumes e funções nesse esquema

Por exemplo, se você conceder a um usuário o SELECT privilégio em um catálogo, esse usuário poderá ler todas as tabelas e exibições nesse catálogo (com os privilégios apropriados USE CATALOG e USE SCHEMA de uso).

A propriedade não é transmitida para níveis inferiores no Unity Catalog. Como proprietário de um objeto, você recebe automaticamente todos os privilégios somente nesse objeto. Você não assume automaticamente a propriedade de objetos filhos criados sob seu objeto. No entanto, você obtém automaticamente o privilégio MANAGE em todos os objetos filhos novos e existentes.

Exemplos de herança

Suponha que você conceda SELECT, USE CATALOG, e USE SCHEMA no nível do catálogo ao grupo finance_team.

GRANT USE CATALOG, USE SCHEMA, SELECT ON CATALOG sales TO finance_team;

Essa concessão permite que o finance_team grupo:

• Acessar o sales catálogo
• Acessar todos os esquemas no catálogo
• Ler dados de todas as tabelas e visões atuais e futuras no catálogo

Suponha que você conceda CREATE TABLE, USE CATALOG, e USE SCHEMA no nível do catálogo ao grupo data_engineers.

GRANT USE CATALOG, USE SCHEMA, CREATE TABLE ON CATALOG analytics TO data_engineers;

Essa concessão permite que o data_engineers grupo:

• Acessar o analytics catálogo
• Acessar todos os esquemas no catálogo
• Criar tabelas em qualquer esquema atual ou futuro no catálogo

Para obter instruções sobre como conceder e revogar privilégios, consulte Mostrar, conceder e revogar privilégios.