Pular para o conteúdo principal

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

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

nota

O controle de acesso à tabela para gerenciar dados pelo site Hive metastore é um modelo legado de governança de dados. Databricks recomenda que o senhor atualize as tabelas gerenciadas pelo Hive metastore para o metastore Unity Catalog. Unity Catalog simplifica a segurança e a governança de seus dados, fornecendo um local central para administrar e auditar o acesso aos dados em vários espaços de trabalho em seu site account. Para saber mais sobre como o modelo de privilégio legado difere do modelo de privilégio Unity Catalog, consulte Trabalhar com Unity Catalog e o legado Hive metastore.

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 em SQL, o senhor usa GRANT, REVOKE, DENY, Msck, e SHOW GRANTS em um Notebook ou no editor de consultas Databricks SQL, usando a sintaxe:

SQL
GRANT privilege_type ON securable_object TO principal

Em que:

Para conceder um privilégio a todos os usuários do site 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 o gerenciamento de privilégios para objetos no Hive metastore usando o comando SQL, consulte Privileges and securable objects in the Hive metastore.

O senhor 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; nesse caso, 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:

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

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

Objetos seguros no Hive metastore​

Os objetos seguros são:

  • CATALOGO usuário pode usar o controle de acesso a todo o catálogo de dados.

    • SCHEMA: controla o acesso a um esquema.
      • TABLEControle de acesso a uma tabela gerenciadora ou externa.
      • VIEW: controla o acesso à visualização 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 não são compatíveis com o 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 há suporte para privilégios na visualização temporária global e local. As visualizações temporárias locais são visíveis somente 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 clustering ou SQL warehouse. No entanto, os privilégios nas tabelas subjacentes e na visualização referenciada por qualquer visualização temporária são aplicados.

Privilégios que o senhor pode conceder aos objetos do site 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_METADATAO senhor pode acessar view um objeto e seus metadados.
  • CREATE_NAMED_FUNCTIONUDF nomeada: permite criar uma UDF nomeada em um catálogo ou esquema existente.
  • MODIFY_CLASSPATHCapacidade de adicionar arquivos ao caminho da classe Spark.
  • ALL PRIVILEGES: concede todos os privilégios (traduzidos em todos os privilégios acima).
nota

O privilégio MODIFY_CLASSPATH não é compatível com o site 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

Até 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.

Dinâmico view funções​

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 de 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:

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​

Usando a exibição dinâmica, o senhor pode especificar as permissões até o nível da linha ou do campo. Considere o exemplo a seguir, em que somente usuários que pertencem ao grupo managers podem ver valores de transação (coluna total) maiores que $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á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.

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
Última atualização em