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.
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
- Um administrador deve habilitar e aplicar o controle de acesso da tabela para o workspace.
- O clustering deve ser ativado para o controle de acesso da tabela.
- 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:
GRANT privilege_type ON securable_object TO principal
Em que:
privilege_type
é um tipo de privilégioHive metastoresecurable_object
é um objeto securizável no Hive metastoreprincipal
é um usuário, uma entidade de serviço (representada por seu valor applicationId) ou um grupo. O senhor deve colocar os nomes de usuários, entidades de serviço e grupos com caracteres especiais entre aspas (
Para conceder um privilégio a todos os usuários do site 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 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:
ALTER <object> OWNER TO `<user-name>@<user-domain>.com`
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:
-
CATALOG
O usuário pode usar o controle de acesso a todo o catálogo de dados.SCHEMA
: controla o acesso a um esquema.TABLE
Controle 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.
ANONYMOUS FUNCTION
não são compatíveis com o Databricks SQL.
ANY FILE
: controla o acesso ao sistema de arquivos subjacente.
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.
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_METADATA
O senhor pode acessar view um objeto e seus metadados.CREATE_NAMED_FUNCTION
UDF nomeada: permite criar uma UDF nomeada em um catálogo ou esquema existente.MODIFY_CLASSPATH
Capacidade de adicionar arquivos ao caminho da classe Spark.ALL PRIVILEGES
: concede todos os privilégios (traduzidos em todos os privilégios acima).
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égioUSAGE
no esquema - Ter o privilégio
USAGE
noCATALOG
ou estar em um grupo com o privilégioUSAGE
- 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:
-- 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 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:
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