Partilhar via

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

  • Artigo

Este artigo descreve o modelo de privilégio para o metastore herdado do Azure Databricks Hive, que é incorporado em cada espaço de trabalho do Azure Databricks. Ele também descreve como conceder, negar e revogar privilégios para objetos no metastore interno do Hive. O Unity Catalog usa um modelo diferente para conceder privilégios. Consulte Privilégios do catálogo Unity e objetos protegíveis.

Nota

O controle de acesso à tabela para dados gerenciados pelo metastore do Hive é um modelo de governança de dados herdado. O Databricks recomenda que você atualize as tabelas gerenciadas pelo metastore do Hive para o metastore do Unity Catalog. O Unity Catalog simplifica a segurança e a governação dos seus dados ao fornecer um local central para administrar e auditar o acesso aos dados em várias áreas de trabalho na sua conta. Para saber mais sobre como o modelo de privilégio herdado difere do modelo de privilégio do Unity Catalog, consulte Trabalhar com o Unity Catalog e o metastore herdado do Hive.

Requisitos

  • Um administrador deve habilitar e impor o controle de acesso à tabela para o espaço de trabalho.
  • O cluster deve estar habilitado para controle de acesso à tabela.

Nota

  • O controle de acesso a dados está sempre habilitado no Databricks SQL, mesmo que o controle de acesso à tabela não esteja habilitado para o espaço de trabalho.
  • Se o controle de acesso à tabela estiver habilitado para o espaço de trabalho e você já tiver especificado ACLs (privilégios concedidos e negados) no espaço de trabalho, essas ACLs serão respeitadas no Databricks SQL.

Gerenciar privilégios em objetos no metastore do Hive

Os privilégios em objetos de dados gerenciados pelo metastore do Hive podem ser concedidos por um administrador de espaço de trabalho ou pelo proprietário de um objeto. Você pode gerenciar privilégios para objetos de metastore do Hive usando comandos SQL.

Para gerenciar privilégios em SQL, use as instruções GRANT, REVOKE, DENY, MSCK e SHOW GRANTS em um bloco de anotações ou no editor de consultas Databricks SQL, usando a sintaxe:

GRANT privilege_type ON securable_object TO principal

Em que:

Para conceder um privilégio a todos os usuários em seu espaço de trabalho, conceda o privilégio ao users grupo. Por exemplo:

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

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

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

Propriedade do objeto

Quando o controle de acesso à tabela é habilitado em um cluster ou SQL warehouse, um usuário que cria um esquema, tabela, exibição ou função se torna 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 de espaço de trabalho pode transferir a propriedade de um objeto usando o seguinte comando:

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

Nota

Quando o controle de acesso à tabela é desabilitado em um cluster ou SQL warehouse, os proprietários não são registrados quando um esquema, tabela ou exibição é criado. Um administrador de espaço de trabalho deve atribuir um proprietário ao objeto usando o ALTER <object> OWNER TO comando.

Objetos protegíveis no metastore do Hive

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 tabela gerenciada ou externa.
      • VIEW: controla o acesso a exibiçõ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.

    Aviso

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

Nota

Não há suporte para privilégios em exibições temporárias globais e locais. As exibições temporárias locais são visíveis apenas dentro da mesma sessão, e as global_temp exibições criadas no esquema são visíveis para todos os usuários que compartilham um cluster ou um SQL warehouse. No entanto, os privilégios nas tabelas subjacentes e modos de exibição referenciados por quaisquer modos de exibição temporários são impostos.

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

  • SELECT: dá acesso de leitura a um objeto.
  • CREATE: dá a capacidade de 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 dá nenhuma habilidade, mas é um requisito adicional para executar qualquer ação em um objeto de esquema.
  • READ_METADATA: dá a capacidade de visualizar um objeto e seus metadados.
  • CREATE_NAMED_FUNCTION: dá a capacidade de criar um UDF nomeado em um catálogo ou esquema existente.
  • MODIFY_CLASSPATH: dá a capacidade de adicionar arquivos ao caminho da classe Spark.
  • ALL PRIVILEGES: dá todos os privilégios (é traduzido em todos os privilégios acima).

Nota

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

USAGE privilégio

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

  • Seja um administrador de espaço de trabalho
  • Ter o USAGE privilégio no esquema ou estar em um grupo que tenha o USAGE privilégio no esquema
  • Ter o USAGE CATALOG privilégio no ou estar em um grupo que tem o USAGE privilégio
  • Seja o proprietário do esquema ou esteja em um grupo que possui o esquema

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

Hierarquia de privilégios

Quando o controle de acesso à tabela é habilitado no espaço de trabalho e em todos os clusters, os objetos SQL no Azure Databricks são hierárquicos e os privilégios são herdados para baixo. Isso significa que conceder ou negar um privilégio no CATALOG automaticamente concede ou nega o privilégio a todos os esquemas no catálogo. Da mesma forma, os privilégios concedidos em um objeto de esquema são herdados por todos os objetos nesse esquema. Esse padrão é verdadeiro para todos os objetos protegíveis.

Se você negar privilégios de usuário em uma tabela, o usuário não poderá ver a tabela tentando listar todas as tabelas no esquema. Se você negar privilégios de 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 Azure Databricks inclui duas funções de usuário que permitem expressar permissões de nível de coluna e linha dinamicamente no corpo de uma definição de exibição gerenciada pelo metastore do Hive.

  • current_user(): retornar o nome de usuário atual.
  • is_member(): determine se o usuário atual é membro de um grupo específico do Azure Databricks no nível do espaço de trabalho.

O exemplo a seguir combina ambas as 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 no nível da coluna

Você pode usar modos de exibição dinâmicos para limitar as colunas que um grupo ou usuário específico pode ver. Considere o exemplo a seguir, onde apenas os usuários que pertencem ao auditors grupo podem ver endereços de e-mail da sales_raw tabela. No momento da análise, o Spark substitui a CASE instrução pelo literal 'REDACTED' ou pela coluna email. Esse comportamento permite todas as otimizações de desempenho usuais fornecidas 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 de nível de linha

Usando modos de exibição dinâmicos, você pode especificar permissões até o nível de linha ou campo. Considere o exemplo a seguir, em que apenas os usuários que pertencem ao managers grupo podem ver valores de transação (total coluna) superiores a 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;

Máscara de dados

Como 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 padrão do Spark SQL, você pode fazer tipos mais avançados de mascaramento com expressões SQL mais complexas. O exemplo a seguir permite que todos os usuários realizem análises em domínios de email, mas permite que os membros do grupo vejam os auditors 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