Pular para o conteúdo principal
Última atualização em

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

Este artigo descreve o modelo de privilégios para o metastore Hive legado do Databricks, que está integrado a cada workspace do Databricks. Este documento também descreve como conceder, negar e revogar privilégios para objetos no Hive metastore integrado. O Unity Catalog usa um modelo diferente para conceder privilégios. Consulte a referência de privilégios do Unity Catalog.

nota

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

Requisitos​

nota
  • 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, MSCK e SHOW GRANTS em um notebook ou no editor de consultas do Databricks SQL, utilizando a sintaxe:

SQL
GRANT privilege_type ON securable_object TO principal

Em que:

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

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

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

Você pode também gerenciar access control 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.

Grupos podem ser proprietários de 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 com o seguinte comando:

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

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

Objetos protegíveis no Hive metastore​

Os objetos seguros 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 tabela gerenciada ou externa.
      • VIEW: controla o acesso às visualizações SQL.
      • FUNCTION: controla o acesso a uma função nomeada.

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

nota

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

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

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.

nota

Não são suportados privilégios relativos a visualizações temporárias globais e locais. As visualizações temporárias locais são visíveis apenas na mesma sessão, e as visualizações criadas no esquema global_temp são visíveis para todos os usuários que compartilham um cluster ou um SQL warehouse. No entanto, os privilégios nas tabelas e visualizações subjacentes referenciadas por quaisquer visualizações temporárias são aplicados.

Privilégios que podem ser concedidos em objetos Hive metastore​

  • SELECT: concede 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 ver um objeto e os respectivos metadados.
  • CREATE_NAMED_FUNCTION: permite criar um UDF nomeado em um catálogo ou esquema existente.
  • MODIFY_CLASSPATH: permite adicionar arquivos ao caminho da classe Spark.
  • ALL PRIVILEGES: concede todos os privilégios (é traduzido em todos os privilégios acima).
nota

O privilégio MODIFY_CLASSPATH não é compatível com o Databricks SQL.

privilégioUSAGE​

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 forem negados privilégios a um usuário em um esquema, o usuário não poderá ver que o esquema existe ao tentar listar todos os esquemas no catálogo.

Funções de view dinâmicas​

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(): retornar o nome do usuário atual.
  • is_member(): determinar se o usuário atual é membro de um grupo específico do Databricks no nível do workspace.

O exemplo a seguir combina ambas as funções para determinar se um usuário possui a associação de grupo apropriada.

SQL
-- 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.

SQL
-- 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​

Com visualizações dinâmicas, é possível especificar permissões até o nível da linha ou do campo. Considere o exemplo a seguir, em que apenas os usuários que pertencem ao grupo managers podem ver valores de transação (total coluna) maiores que R$ 1.000.000,00:

SQL
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álise em domínios de email, mas permite que os membros do grupo auditors vejam os endereços de email completos dos usuários.

SQL
-- 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
Nesta página