Privilégios do Hive metastore e objetos protegíveis (legado)

Este artigo descreve o modelo de privilégio do Hive metastore integrado a cada Databricks workspace. Ele também descreve como conceder, negar e revogar privilégios para objetos no Hive metastore. O Unity Catalog usa um modelo diferente para conceder privilégios. Consulte Privilégios do Unity Catalog e objetos protegíveis.

Observação

O access control da tabela para dados gerenciados pelo Hive metastore é um modelo de governança de dados herdado.A Databricks recomenda que você atualize as tabelas gerenciadas pelo Hive metastore para o metastore Unity Catalog .O Unity Catalog simplifica a segurança e a governança dos seus dados, oferecendo um local central para administrar e auditar o acesso a dados em vários espaços de trabalho em sua conta.Para mais informações sobre como o modelo de privilégio herdado difere do modelo de privilégio Unity Catalog, consulte Como trabalhar com Unity Catalog e o Hive metastore.

Requisitos

Observação

  • O controle de acesso a dados está sempre habilitado no Databricks SQL, mesmo que o access control da tabela não esteja habilitado para o workspace.

  • Se o access control da tabela estiver habilitado para o workspace e você já tiver especificado ACLs (privilégios concedidos e negados) no workspace, esses ACLs serão respeitados no Databricks SQL.

gerenciar privilégios em objetos no Hive metastore

Privilégios em objetos de dados gerenciados pelo Hive metastore podem ser concedidos por um administrador de workspace ou pelo proprietário de um objeto. Você pode gerenciar privilégios para objetos Hive metastore com comandos SQL.

Para gerenciar privilégios no SQL, você usa as instruções GRANT, REVOKE, DENY, MSCKe SHOW GRANTS em um bloco de anotações ou no editor de consultas Databricks SQL, utilizando a sintaxe:

GRANT privilege_type ON securable_object TO principal

Onde:

Para conceder um privilégio a todos os usuários no seu workspace, conceda o privilégio ao grupo users. Por exemplo:

GRANT SELECT ON TABLE <schema-name>.<table-name> TO users

Para obter mais informações sobre o gerenciamento de privilégios para objetos no Hive metastore usando comandos SQL, consulte Privilégios e objetos protegíveis no Hive metastore.

Você também pode gerenciar o controle de acesso da tabela em uma configuração totalmente automatizada usando o provedor Databricks Terraform e databricks_sql_permissions.

Propriedade do objeto

Quando o access control da tabela é ativado em um cluster ou SQL warehouse, o usuário que cria um esquema, tabela, exibição ou função torna-se seu proprietário. O proprietário recebe todos os privilégios e pode conceder privilégios a outros usuários.

Os grupos podem possuir objetos, caso em que todos os membros desse grupo são considerados proprietários.

O proprietário de um objeto ou um administrador do workspace pode transferir a propriedade de um objeto usando o seguinte comando:

ALTER <object> OWNER TO `<user-name>@<user-domain>.com`

Observação

Quando o controle de acesso da tabela está desabilitado em clusters ou SQL warehouse, os proprietários não são registrados quando um esquema, tabela ou view é criado. Um administrador workspace deve atribuir um proprietário ao objeto usando o comando ALTER <object> OWNER TO.

Objetos protegíveis no Hive metastore

Os objetos protegíveis são:

  • CATALOG: controla o acesso a todo o catálogo de dados.

    • SCHEMA: controla o acesso a um esquema.

      • TABLE: controla o acesso a uma mesa gerenciada ou externa.

      • VIEW: controla o acesso à view SQL.

      • FUNCTION: controla o acesso a uma função nomeada.

  • ANONYMOUS FUNCTION: controla o acesso a funções anônimas ou temporárias.

    Observação

    ANONYMOUS FUNCTION objetos não são suportados no Databricks SQL.

  • ANY FILE: controla o acesso ao sistema de arquivos subjacente.

    Aviso

    Os usuários com acesso concedido a ANY FILE podem ignorar as restrições colocadas no catálogo, esquemas, tabelas e exibições que leem diretamente do sistema de arquivos.

Observação

Privilégios na view temporária global e local não são suportados. view temporárias locais são visíveis apenas na mesma sessão, e view criadas no esquema global_temp são visíveis para todos os usuários que compartilham clusters ou SQL warehouse. No entanto, os privilégios nas tabelas subjacentes e view referenciadas por qualquer view temporária são impostos.

Privilégios que você pode conceder em objetos Hive metastore

  • SELECT: dá acesso de leitura a um objeto.

  • CREATE: permite criar um objeto (por exemplo, uma tabela em um esquema).

  • MODIFY: permite adicionar, excluir e modificar dados de ou para um objeto.

  • USAGE: não oferece nenhuma habilidade, mas é um requisito adicional para executar qualquer ação em um objeto de esquema.

  • READ_METADATA: permite view um objeto e seus metadados.

  • CREATE_NAMED_FUNCTION: permite criar uma UDF nomeada em um catálogo ou esquema existente.

  • MODIFY_CLASSPATH: permite adicionar arquivos ao caminho da classe Spark.

  • ALL PRIVILEGES: dá todos os privilégios (é traduzido em todos os privilégios acima).

Observação

O privilégio MODIFY_CLASSPATH não tem suporte no Databricks SQL.

USAGE privilégio

Para executar uma ação em um objeto de esquema no Hive metastore, um usuário deve ter o privilégio USAGE nesse esquema, além do privilégio para executar essa ação. Qualquer um dos seguintes satisfaz o requisito USAGE:

  • Seja um administrador do workspace

  • Ter o privilégio USAGE no esquema ou estar em um grupo com o privilégio USAGE no esquema

  • Ter o privilégio USAGE no CATALOG ou estar em um grupo com o privilégio USAGE

  • Ser o proprietário do esquema ou estar em um grupo que tenha o esquema

Mesmo o proprietário de um objeto dentro de um esquema deve ter o privilégio USAGE para usá-lo.

Hierarquia de privilégios

Quando o access control da tabela está habilitado no workspace e em todos os clusters, os objetos SQL no Databricks são hierárquicos e os privilégios são herdados nos níveis inferiores. Isso significa que conceder ou negar um privilégio no CATALOG concede ou nega automaticamente o privilégio a todos os esquemas no catálogo. Da mesma forma, os privilégios concedidos a um objeto de esquema são herdados por todos os objetos desse esquema. Esse padrão é válido para todos os objetos protegíveis.

Se você negar privilégios a um usuário em uma tabela, o usuário não poderá ver a tabela se tentar listar todas as tabelas no esquema. Se você negar privilégios a um usuário em um esquema, o usuário não poderá ver que o esquema existe tentando listar todos os esquemas no catálogo.

Funções de visualização dinâmica

O Databricks contém duas funções de usuário que permitem que você expresse permissões em nível de coluna e linha dinamicamente no corpo de uma definição de exibição gerenciada pelo Hive metastore.

  • current_user(): retorna o nome do usuário atual.

  • is_member(): determinar se o usuário atual é membro de um Databricks grupo específico no workspace nível .

O exemplo a seguir combina as duas funções para determinar se um usuário tem a associação de grupo apropriada:

-- Return: true if the user is a member and false if they are not
SELECT
  current_user as user,
-- Check to see if the current user is a member of the "Managers" group.
  is_member("Managers") as admin

Permissões em nível de coluna

Você pode usar exibições dinâmicas para limitar as colunas que um grupo ou usuário específico pode ver. Considere o exemplo a seguir em que apenas os usuários que pertencem ao grupo auditors podem ver os endereços de e-mail da tabela sales_raw . No momento da análise, o Spark substitui a instrução CASE pelo literal 'REDACTED' ou pela coluna email. Esse comportamento possibilita todas as otimizações de desempenho usuais oferecidas pelo Spark.

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW sales_redacted AS
SELECT
  user_id,
  CASE WHEN
    is_group_member('auditors') THEN email
    ELSE 'REDACTED'
  END AS email,
  country,
  product,
  total
FROM sales_raw

Permissões em nível de linha

Usando view dinâmica, você pode especificar permissões até o nível de linha ou campo. Considere o seguinte exemplo, onde apenas os usuários que pertencem ao grupo managers podem ver valores de transação (coluna total ) maiores que US$ 1.000.000,00:

CREATE VIEW sales_redacted AS
SELECT
  user_id,
  country,
  product,
  total
FROM sales_raw
WHERE
  CASE
    WHEN is_group_member('managers') THEN TRUE
    ELSE total <= 1000000
  END;

mascaramento de dados

Conforme mostrado nos exemplos anteriores, você pode implementar o mascaramento no nível da coluna para impedir que os usuários vejam dados específicos da coluna, a menos que estejam no grupo correto. Como essas exibições são Spark SQL padrão, você pode fazer tipos mais avançados de mascaramento com expressões SQL mais complexas. O exemplo a seguir possibilita que todos os usuários realizem análises em domínios de e-mail, mas permite que os membros do grupo auditors vejam os endereços de e-mail completos dos usuários.

-- The regexp_extract function takes an email address such as
-- user.x.lastname@example.com and extracts 'example', allowing
-- analysts to query the domain name

CREATE VIEW sales_redacted AS
SELECT
  user_id,
  region,
  CASE
    WHEN is_group_member('auditors') THEN email
    ELSE regexp_extract(email, '^.*@(.*)$', 1)
  END
  FROM sales_raw