O Hologres oferece suporte ao modelo de permissão padrão do PostgreSQL (também chamado de modelo de permissão avançado), que proporciona um controle refinado sobre quem pode acessar, modifique ou exclua objetos de banco de dados específicos. Use este modelo quando sua carga de trabalho exigir controle de permissão por objeto.
Para cenários mais simples, o Hologres também fornece o simple permission model (SPM). O SPM usa permissões de granularidade grossa e é mais fácil de configurar, mas não oferece suporte ao controle por objeto.
Como funciona o modelo de permissão do PostgreSQL
O modelo de permissão do PostgreSQL possui dois comportamentos principais que o diferenciam de modelos mais simples.
As permissões se aplicam apenas a objetos existentes. Quando você concede um privilégio em todas as tabelas de um schema, essa concessão abrange apenas as tabelas que existem naquele momento, e não as tabelas criadas posteriormente. Por exemplo:
O User1 executa
GRANT SELECT ON ALL TABLES IN SCHEMA public TO User2.O User1 cria uma nova tabela
table_newno schemapublic.O User2 executa
SELECT * FROM table_newe recebeERROR: permission denied.
Para abranger tabelas futuras, use ALTER DEFAULT PRIVILEGES. Consulte a referência do ALTER DEFAULT PRIVILEGES.
A propriedade controla quem pode excluir uma tabela. O PostgreSQL atribui uma tabela recém-criada ao usuário que a criou. Apenas o proprietário da tabela, o proprietário do schema ou um superusuário podem excluir uma tabela. Para permitir que um grupo gerencie ou exclua uma tabela, transfira a propriedade da tabela para esse grupo.
Planeje seu modelo de permissão
Antes de escrever qualquer SQL, responda a estas perguntas para a sua instância do Hologres:
De quantos grupos de permissão você precisa?
Qual é o propósito de cada grupo?
Quais usuários pertencem a cada grupo?
Em quais schemas cada grupo trabalha?
Quem pode excluir tabelas e sob quais condições?
Estrutura de grupos recomendada
Organize as permissões em torno de projetos. Para cada projeto, crie três grupos:
|
Grupo |
Nível de privilégio |
O que os membros podem fazer |
|
|
Total (proprietário da tabela) |
crie, leia, grave e exclua tabelas |
|
|
Gravação |
Inserir dados em tabelas específicas |
|
|
Leitura |
visualize e selecione dados em tabelas específicas |
Substitua XX pelo nome do seu projeto. Para um projeto chamado PROJ1, os grupos são PROJ1_DEV_GROUP, PROJ1_WRITE_GROUP e PROJ1_VIEW_GROUP.
Observações:
Esta convenção de nomenclatura é uma recomendação, não uma exigência.
Um DEV_GROUP pode ser proprietário de várias tabelas, mas cada tabela pertence a apenas um DEV_GROUP.
Um usuário pode pertencer a vários DEV_GROUPs. Por exemplo, um usuário pode ser membro tanto do
PROJ1_DEV_GROUPquanto doPROJ2_DEV_GROUP.Atribua um schema por projeto sempre que possível. Um projeto pode abranger vários schemas, e um schema pode atender a vários projetos.
Por padrão, todos os usuários têm os privilégios CREATE e USAGE no schema
public.
Prática recomendada 1: Conceder permissões por tabela
Use esta abordagem quando desejar controle explícito sobre as permissões de cada tabela no momento da criação.
Etapa 1: Crie grupos de permissão
Peça a um superusuário que crie os três grupos do seu projeto:
CREATE ROLE PROJ1_DEV_GROUP; -- Table owner with full privileges
CREATE ROLE PROJ1_WRITE_GROUP; -- Write privilege to insert data into specific tables
CREATE ROLE PROJ1_VIEW_GROUP; -- Read privilege to view data in specific tablesEtapa 2: Conceder privilégios de schema aos grupos
Conceda a cada grupo o acesso no nível de schema necessário. Este exemplo usa SCHEMA1:
-- Grant schema privileges to PROJ1 groups
GRANT CREATE, USAGE ON SCHEMA SCHEMA1 TO PROJ1_DEV_GROUP;
GRANT USAGE ON SCHEMA SCHEMA1 TO PROJ1_WRITE_GROUP;
GRANT USAGE ON SCHEMA SCHEMA1 TO PROJ1_VIEW_GROUP;Por padrão, todos os usuários têm os privilégios CREATE e USAGE no schema public .
Etapa 3: Crie usuários e atribua-os aos grupos
Crie usuários e adicione-os aos grupos apropriados:
CREATE USER "USER1";
GRANT PROJ1_DEV_GROUP TO "USER1";
CREATE USER "USER2";
GRANT PROJ1_VIEW_GROUP TO "USER2";Etapa 4: Conceder privilégios de tabela após criar uma tabela
Quando um membro do PROJ1_DEV_GROUP (ou um superusuário) criar uma nova tabela, execute as seguintes instruções para atribuir privilégios e transferir a propriedade. Este exemplo usa TABLE1:
GRANT ALL ON TABLE SCHEMA1.TABLE1 TO PROJ1_WRITE_GROUP; -- Write privilege on TABLE1
GRANT SELECT ON TABLE SCHEMA1.TABLE1 TO PROJ1_VIEW_GROUP; -- Read privilege on TABLE1
ALTER TABLE SCHEMA1.TABLE1 OWNER TO PROJ1_DEV_GROUP; -- Transfer ownership to the groupTransferir a propriedade para o grupo permite que todos os membros do PROJ1_DEV_GROUP gerencie ou exclua a TABLE1. Sem esta etapa, apenas o criador original pode excluir a tabela.
Condições para alterar a propriedade da tabela:
O usuário atual deve ser o proprietário da tabela.
O usuário atual deve ser um membro direto ou indireto do grupo de destino.
O grupo de destino deve ter o privilégio CREATE no schema.
Um superusuário pode alterar o proprietário de qualquer tabela.
Prática recomendada 2: Usar privilégios padrão para automatizar concessões
Use esta abordagem quando você souber antecipadamente a qual projeto uma nova tabela pertence. O ALTER DEFAULT PRIVILEGES atua como um gatilho: quando uma tabela é criada, o Hologres verifique o pg_catalog.pg_default_acl em busca de uma regra correspondente e a aplica automaticamente.
A correspondência usa apenas o usuário atual (não os grupos do usuário). As regras do ALTER DEFAULT PRIVILEGES são avaliadas apenas no momento da criação da tabela — alterar o proprietário posteriormente não as aciona.
Etapa 1: Crie grupos de permissão
CREATE ROLE PROJ1_DEV_GROUP; -- Table owner with full privileges
CREATE ROLE PROJ1_WRITE_GROUP; -- Write privilege to insert data into specific tables
CREATE ROLE PROJ1_VIEW_GROUP; -- Read privilege to view data in specific tablesEtapa 2: Conceder privilégios de schema aos grupos
-- Grant schema privileges to PROJ1 groups
GRANT CREATE, USAGE ON SCHEMA SCHEMA1 TO PROJ1_DEV_GROUP;
GRANT USAGE ON SCHEMA SCHEMA1 TO PROJ1_WRITE_GROUP;
GRANT USAGE ON SCHEMA SCHEMA1 TO PROJ1_VIEW_GROUP;Por padrão, todos os usuários têm os privilégios CREATE e USAGE no schema public .
Etapa 3: Crie um usuário e defina privilégios padrão
Crie o USER1 (uma conta válida da Alibaba Cloud), defina privilégios padrão para que as tabelas criadas pelo USER1 sejam compartilhadas automaticamente com os grupos do PROJ1 e, em seguida, adicione o USER1 ao grupo DEV:
CREATE USER "USER1";
-- Automatically grant full privileges to PROJ1_DEV_GROUP on tables USER1 creates
ALTER DEFAULT PRIVILEGES FOR ROLE "USER1" GRANT ALL ON TABLES TO PROJ1_DEV_GROUP;
-- Automatically grant read and write permission to PROJ1_WRITE_GROUP on tables USER1 creates
ALTER DEFAULT PRIVILEGES FOR ROLE "USER1" GRANT ALL ON TABLES TO PROJ1_WRITE_GROUP;
-- Automatically grant read privilege to PROJ1_VIEW_GROUP on tables USER1 creates
ALTER DEFAULT PRIVILEGES FOR ROLE "USER1" GRANT SELECT ON TABLES TO PROJ1_VIEW_GROUP;
GRANT PROJ1_DEV_GROUP TO "USER1"; -- Add USER1 to PROJ1_DEV_GROUPCondições para usar ALTER DEFAULT PRIVILEGES FOR ROLE xxx:
O usuário atual é membro do grupo
xxx, ouO usuário atual é um superusuário e
xxxé um usuário ou grupo.
verifique as regras de privilégio padrão:
\ddpIsso consulta o pg_catalog.pg_default_acl e lista todas as regras de privilégio padrão configuradas.
Como funciona a correspondência: A regra corresponde apenas ao usuário atual, não aos grupos do usuário. Por exemplo, se o USER1 pertencer ao GROUP1 e você definir uma regra de privilégio padrão para o GROUP1, a regra não será acionada quando o USER1 criar uma tabela. Para acionar a regra, alterne primeiro a função da sessão:
SET SESSION ROLE GROUP1;
-- Now create the table; the rule matches because the current user is GROUP1Etapa 4: Transferir a propriedade da tabela para o grupo
Depois que o USER1 criar uma tabela, transfira a propriedade para o PROJ1_DEV_GROUP para que todos os membros do grupo a gerencie ou a exclua. Este exemplo usa a TABLE1:
ALTER TABLE SCHEMA1.TABLE1 OWNER TO PROJ1_DEV_GROUP;Ignore esta etapa se apenas o criador da tabela ou um superusuário for gerenciá-la ou excluí-la.
Dois padrões comuns para executar esta etapa:
Um superusuário transfere periodicamente a propriedade das tabelas recém-criadas.
O criador transfere a propriedade antes que outro membro do grupo precise gerenciar ou excluir a tabela.
Etapa 5: Mover um usuário para um projeto diferente
Para reatribuir o USER1 do PROJ1 para o PROJ2 sem afetar as tabelas existentes, revogue primeiro os privilégios padrão atuais e, em seguida, defina novos. Revogar primeiro garante que as regras antigas não se apliquem mais às tabelas futuras antes que as novas regras entrem em vigor.
-- Revoke existing default privileges for PROJ1
ALTER DEFAULT PRIVILEGES FOR ROLE "USER1" REVOKE ALL ON TABLES FROM PROJ1_DEV_GROUP;
ALTER DEFAULT PRIVILEGES FOR ROLE "USER1" REVOKE ALL ON TABLES FROM PROJ1_WRITE_GROUP;
ALTER DEFAULT PRIVILEGES FOR ROLE "USER1" REVOKE SELECT ON TABLES FROM PROJ1_VIEW_GROUP;
-- Set new default privileges for PROJ2
ALTER DEFAULT PRIVILEGES FOR ROLE "USER1" GRANT ALL ON TABLES TO PROJ2_DEV_GROUP;
ALTER DEFAULT PRIVILEGES FOR ROLE "USER1" GRANT ALL ON TABLES TO PROJ2_WRITE_GROUP;
ALTER DEFAULT PRIVILEGES FOR ROLE "USER1" GRANT SELECT ON TABLES TO PROJ2_VIEW_GROUP;Execute o \ddp novamente e confirme que as regras foram atualizadas.