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

  • Artigo

Este artigo descreve o modelo de privilégio para o metastore do Hive herdado do Azure Databricks, que é integrado a cada workspace do Azure Databricks. Também descreve como conceder, negar e revogar privilégios para objetos no metastore do Hive interno. O Catálogo do Unity usa um modelo diferente para conceder privilégios. Confira Privilégios e objetos protegíveis do Catálogo do Unity.

Observação

O controle de acesso à tabela de 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 Catálogo do Unity. O Catálogo do Unity simplifica a segurança e a governança de seus dados, fornecendo um local central para administrar e auditar o acesso a dados em vários workspaces em sua conta. Para saber mais sobre como o modelo de privilégio herdado difere do modelo de privilégio do Catálogo do Unity, confira Trabalhar com o Catálogo do Unity e o metastore do Hive herdado.

Requisitos

Observação

  • 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 workspace.
  • Se o controle de acesso à 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 metastore do Hive

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

Para gerenciar privilégios no SQL, use as instruções GRANT, REVOKE, DENY, MSCK e SHOW GRANTS de um notebook ou do editor de consultas do 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 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 como gerenciar privilégios para objetos no metastore do Hive usando comandos SQL, confira Privilégios e objetos protegíveis no metastore do Hive.

Gerencie também 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 ser proprietários de objetos, caso no qual todos os membros do 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 à 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 precisa atribuir um proprietário ao objeto usando o comando ALTER <object> OWNER TO.

Objetos protegíveis no metastore do Hive

Os objetos protegíveis são:

  • CATALOG: controla o acesso ao catálogo de dados inteiro.

    • SCHEMA: controla o acesso a um esquema.
      • TABLE: controla o acesso a uma tabela gerenciada ou externa.
      • VIEW: controla o acesso aos modos de exibição do 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

    Não há suporte para os objetos ANONYMOUS FUNCTION no SQL do Databricks.

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

    Aviso

    Os usuários que concederam acesso ao ANY FILE podem ignorar as restrições colocadas no catálogo, os esquemas, as tabelas e as exibições fazendo a leitura diretamente do sistema de arquivos.

Observação

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 na mesma sessão e as exibições criadas no esquema global_temp são visíveis a todos os usuários que compartilham um cluster ou SQL warehouse. No entanto, são impostos os privilégios às tabelas subjacentes e exibições referenciadas por quaisquer exibições temporárias.

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

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

Observação

Não há suporte para o privilégio MODIFY_CLASSPATH no SQL do Databricks.

Privilégio USAGE

Para executar uma ação em um objeto de esquema no metastore do Hive, 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 atende ao requisito USAGE:

  • Seja um administrador do workspace
  • Ter o privilégio USAGE no esquema ou estar em um grupo que tenha o privilégio USAGE no esquema
  • Ter o privilégio USAGE no CATALOG ou estar em um grupo que tenha o privilégio USAGE
  • Ser o proprietário do esquema ou estar em um grupo proprietário do 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 controle de acesso à tabela está habilitado no workspace e em todos os clusters, os objetos SQL no Azure Databricks são hierárquicos e os privilégios são herdados de cima para baixo. 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 em um objeto de esquema são herdados por todos os objetos nesse esquema. Este padrão é verdadeiro 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 ao 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 ao tentar listar todos os esquemas no catálogo.

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

O Azure Databricks inclui 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 metastore do Hive.

  • current_user(): retorna o nome de usuário atual.
  • is_member(): determina 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 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 somente os usuários que pertencem ao grupo auditors podem ver os endereços de email 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 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 em nível de linha

Usando exibições dinâmicas, você pode especificar permissões até o nível de linha ou de campo. Considere o exemplo a seguir, em que somente os usuários que pertencem ao grupo managers podem ver os valores de transação (coluna total) maiores que $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 em nível de coluna para impedir que os usuários vejam dados de colunas específicas, a menos que estejam no grupo correto. Como essas exibições são padrão SQL do Spark, 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 executem a 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.

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