<\/p>\n
SQL Server separa login e user em duas camadas; o Postgres funde tudo em um \u00fanico conceito, a role \u2014 e essa fus\u00e3o muda a forma como voc\u00ea pensa superusu\u00e1rio, permiss\u00e3o padr\u00e3o e escopo de acesso.<\/p>\n
Francisco Porf\u00edrio e Renato Siqueira<\/span> \u00b7 Time PostgreSQL da Power Tuning<\/p>\n<\/div>\n Nos dois primeiros posts desta s\u00e9rie, tratamos da instala\u00e7\u00e3o e da hierarquia inst\u00e2ncia\/database\/schema. Resolvidos esses dois estranhamentos, o terceiro geralmente aparece na primeira reuni\u00e3o de seguran\u00e7a: algu\u00e9m pergunta “quem \u00e9 o No SQL Server, o controle de acesso \u00e9 constru\u00eddo em duas camadas distintas: login<\/strong> (autentica\u00e7\u00e3o, n\u00edvel de inst\u00e2ncia) e user<\/strong> (autoriza\u00e7\u00e3o, n\u00edvel de database), com um mapeamento expl\u00edcito entre os dois. No Postgres, essas duas camadas colapsam em um \u00fanico objeto: a role<\/strong>. N\u00e3o existe separa\u00e7\u00e3o estrutural entre “quem se conecta” e “quem tem permiss\u00e3o dentro do banco”.<\/p>\n Este post cobre essa diferen\u00e7a de raiz, compara o superusu\u00e1rio de cada banco ( SQL Server (2 camadas)<\/p>\n \u2193 mapeamento<\/p>\n 1 login pode virar N users<\/p>\n um mapeamento por database<\/p>\n<\/div>\n<\/td>\n PostgreSQL (1 camada)<\/p>\n \u2193 GRANT grupo_leitura TO app_user<\/p>\n 1 role, N databases<\/p>\n permiss\u00e3o \u00e9 dada database a database<\/p>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n No SQL Server, login (autentica) e user (autoriza) s\u00e3o objetos diferentes, ligados por um mapeamento expl\u00edcito por database.<\/p>\n No Postgres, a role faz as duas coisas ao mesmo tempo: existe uma vez no cluster e recebe permiss\u00f5es banco a banco.<\/p> No SQL Server, autentica\u00e7\u00e3o e autoriza\u00e7\u00e3o vivem em camadas separadas. Um login<\/strong> existe no n\u00edvel da inst\u00e2ncia \u2014 pode ser autentica\u00e7\u00e3o do Windows ou autentica\u00e7\u00e3o SQL \u2014 e por si s\u00f3 n\u00e3o d\u00e1 acesso a nenhum dado. Para acessar um database espec\u00edfico, esse login precisa estar mapeado<\/strong> a um user<\/strong> dentro daquele database, e \u00e9 o user que recebe permiss\u00f5es sobre schemas, tabelas e procedures.<\/p>\n Em cima disso, o SQL Server oferece pap\u00e9is prontos em dois n\u00edveis: fixed server roles<\/em> (como O Postgres n\u00e3o tem essa separa\u00e7\u00e3o em duas camadas. Existe um \u00fanico tipo de objeto, a role<\/strong>, e o comando Outra consequ\u00eancia da fus\u00e3o: uma role existe uma \u00fanica vez no cluster<\/strong>, n\u00e3o por database \u2014 diferente do user do SQL Server, que \u00e9 recriado (e pode ter permiss\u00f5es diferentes) em cada database. No Postgres, a mesma role E o PUBLIC do Postgres n\u00e3o \u00e9 o mesmo PUBLIC do SQL Server.<\/strong> No SQL Server, Os dois bancos criam um superusu\u00e1rio automaticamente na instala\u00e7\u00e3o, mas com naturezas ligeiramente diferentes. O Uma diferen\u00e7a de comportamento importante: Pensando como DBA SQL Server:<\/strong> o h\u00e1bito de logar direto como No SQL Server, o papel No Postgres 18<\/strong>, o comportamento de f\u00e1brica no schema Cluster antigo, ainda com o comportamento velho?<\/strong> A mudan\u00e7a introduzida no PG15 vale s\u00f3 para databases criados a partir dessa vers\u00e3o (porque herdam de O passo 3 costuma ser o mais estranho para quem vem do SQL Server. L\u00e1, colocar um user em sa<\/code> do Postgres?” \u2014 e a resposta correta n\u00e3o \u00e9 um nome, \u00e9 uma mudan\u00e7a de modelo mental.<\/p>\nsa<\/code> x postgres<\/code>), e explica o que vem liberado por padr\u00e3o em cada instala\u00e7\u00e3o \u2014 incluindo uma mudan\u00e7a recente do Postgres que pegou muita gente de surpresa.<\/p>\n\n\n
\n \n
\nsa (sysadmin)<\/span>
\nLoginApp, LoginETL…<\/span>
\nAutentica no servidor<\/span><\/div>\n
\ndbo, user_app (por database)<\/span>
\ndb_owner, db_datareader…<\/span>
\nAutoriza dentro de UM database<\/span><\/div>\n\n
\npostgres (superuser)<\/span>
\napp_user (LOGIN)<\/span>
\ngrupo_leitura (NOLOGIN)<\/span>
\nMesmo objeto autentica E autoriza<\/span>
\nvis\u00edvel em todo o cluster<\/span><\/div>\n
\ngrupo_leitura<\/span><\/div>\nComo o SQL Server te acostumou a pensar<\/h2>\n
sysadmin<\/code>, dbcreator<\/code>, securityadmin<\/code>) e fixed database roles<\/em> (db_owner<\/code>, db_datareader<\/code>, db_datawriter<\/code>). No topo de tudo isso est\u00e1 o login sa<\/code>, criado automaticamente na instala\u00e7\u00e3o, membro fixo e permanente do papel sysadmin<\/code>.<\/p>\n-- Criar login (n\u00edvel inst\u00e2ncia) e mapear para user (n\u00edvel database)<\/span>\r\nCREATE LOGIN login_app WITH PASSWORD = 'SenhaForte123!';\r\n\r\nUSE Vendas;\r\nCREATE USER user_app FOR LOGIN login_app;\r\nALTER ROLE db_datareader ADD MEMBER user_app;<\/code><\/pre>\nA filosofia do Postgres: role \u00e9 tudo<\/h2>\n
CREATE USER<\/code> nada mais \u00e9 do que um apelido hist\u00f3rico para CREATE ROLE ... WITH LOGIN<\/code>. Uma role pode se conectar (se tiver o atributo LOGIN<\/code>) e, ao mesmo tempo, receber permiss\u00f5es \u2014 \u00e9 o pr\u00f3prio objeto de autentica\u00e7\u00e3o e de autoriza\u00e7\u00e3o.<\/p>\n-- Estas duas linhas fazem exatamente a mesma coisa<\/span>\r\nCREATE USER app_user WITH PASSWORD 'SenhaForte123!';\r\nCREATE ROLE app_user WITH LOGIN PASSWORD 'SenhaForte123!';\r\n\r\n-- Role sem LOGIN funciona como um \"grupo\" de permiss\u00f5es, sem poder autenticar<\/span>\r\nCREATE ROLE grupo_leitura NOLOGIN;\r\nGRANT grupo_leitura TO app_user;<\/code><\/pre>\napp_user<\/code> \u00e9 usada para se conectar em qualquer database do cluster, e as permiss\u00f5es s\u00e3o concedidas separadamente, database a database.<\/p>\npublic<\/code> \u00e9 um papel de banco de dados real, ao qual todo user pertence automaticamente. No Postgres, PUBLIC<\/code> n\u00e3o \u00e9 uma role de verdade \u2014 \u00e9 uma palavra-chave que significa “toda role existente, incluindo as que ainda v\u00e3o ser criadas”. GRANT SELECT ON tabela TO PUBLIC<\/code> libera acesso para todo mundo, presente e futuro, e isso \u00e9 f\u00e1cil de conceder sem perceber a extens\u00e3o do efeito.<\/p>\n<\/div>\nsa x postgres: o superusu\u00e1rio<\/h2>\n
sa<\/code> \u00e9 um login SQL<\/strong>, membro fixo do papel sysadmin<\/code>; ele pode ser renomeado e, se a inst\u00e2ncia usa Windows Authentication, at\u00e9 desabilitado \u2014 boa pr\u00e1tica comum de hardening. O postgres<\/code> \u00e9 uma role<\/strong> criada pelo initdb<\/code> com o atributo SUPERUSER<\/code>, dono do database postgres<\/code> e de todos os objetos do sistema \u2014 ele tamb\u00e9m pode ser renomeado, mas na pr\u00e1tica quase ningu\u00e9m faz isso, e ele n\u00e3o pode ficar sem nenhum superusu\u00e1rio no cluster.<\/p>\nSUPERUSER<\/code> no Postgres ignora todas as checagens de permiss\u00e3o<\/strong>, sem exce\u00e7\u00e3o \u2014 equivalente ao sysadmin<\/code>. Mas, diferente do SQL Server, o Postgres n\u00e3o tem uma hierarquia intermedi\u00e1ria t\u00e3o rica de pap\u00e9is fixos de servidor: em vez disso, oferece atributos independentes que se combinam, como CREATEDB<\/code>, CREATEROLE<\/code> e REPLICATION<\/code>, permitindo dar poderes pontuais sem entregar superusu\u00e1rio completo.<\/p>\n-- Poderes pontuais, sem entregar SUPERUSER completo<\/span>\r\nCREATE ROLE dba_operacional WITH LOGIN CREATEDB CREATEROLE PASSWORD 'SenhaForte123!';\r\n\r\n-- Ver atributos de um role<\/span>\r\n\\du dba_operacional<\/code><\/pre>\nsa<\/code> no dia a dia j\u00e1 \u00e9 malvisto no mundo SQL Server \u2014 no Postgres essa recomenda\u00e7\u00e3o \u00e9 ainda mais forte. Como o postgres<\/code> ignora toda checagem de permiss\u00e3o, um erro de digita\u00e7\u00e3o em um DROP<\/code> ou DELETE<\/code> n\u00e3o encontra nenhuma barreira no caminho. O padr\u00e3o recomendado \u00e9 reservar postgres<\/code> para tarefas administrativas pontuais e criar roles com OWNER<\/code> do database de aplica\u00e7\u00e3o para o uso do dia a dia.<\/p>\n<\/div>\nPermiss\u00f5es default: o que j\u00e1 vem liberado de f\u00e1brica<\/h2>\n
public<\/code> de cada database vem com permiss\u00f5es m\u00ednimas por padr\u00e3o, e o user guest<\/code> \u2014 que permitiria acesso sem login mapeado \u2014 vem com REVOKE CONNECT<\/strong> por padr\u00e3o em databases novos. De modo geral, o padr\u00e3o de f\u00e1brica \u00e9 restritivo: quase nada funciona at\u00e9 que algu\u00e9m conceda.<\/p>\npublic<\/code> de um database novo j\u00e1 \u00e9 restritivo: apenas o dono do schema (normalmente postgres<\/code>) tem permiss\u00e3o de CREATE<\/code> nele. Vale saber de onde isso veio, porque nem sempre foi assim: at\u00e9 a vers\u00e3o 14, todo database novo concedia CREATE<\/code> e USAGE<\/code> no schema public<\/code> para PUBLIC<\/code> \u2014 ou seja, qualquer role com permiss\u00e3o de conectar naquele database j\u00e1 podia criar tabelas no schema padr\u00e3o, sem nenhum GRANT expl\u00edcito. Esse comportamento liberal foi corrigido no PostgreSQL 15<\/strong>, e \u00e9 a base restritiva que o Postgres 18 mant\u00e9m hoje.<\/p>\ntemplate1<\/code>, que j\u00e1 vem ajustado). Um database criado em vers\u00e3o anterior ao 15 e depois migrado\/atualizado \u2014 inclusive para o Postgres 18 atual \u2014 continua com o GRANT<\/code> antigo em vigor, a menos que algu\u00e9m rode o REVOKE<\/code> manualmente. Vale a pena checar isso explicitamente em qualquer ambiente que j\u00e1 existia antes do upgrade para a vers\u00e3o 15.<\/p>\n<\/div>\n-- Fechar o comportamento antigo em um database criado antes do PG15<\/span>\r\n-- (databases criados em PG15+ j\u00e1 nascem assim, incluindo no Postgres 18)<\/span>\r\nREVOKE CREATE ON SCHEMA public FROM PUBLIC;\r\n\r\n-- Tamb\u00e9m vale revisar quem pode simplesmente se conectar ao database<\/span>\r\nREVOKE CONNECT ON DATABASE minha_base FROM PUBLIC;\r\nGRANT CONNECT ON DATABASE minha_base TO app_user, grupo_leitura;<\/code><\/pre>\nPasso a passo: criando role, dando acesso e ajustando permiss\u00f5es default<\/h2>\n
-- 1. Cria a role de aplica\u00e7\u00e3o, com senha e permiss\u00e3o de conectar<\/span>\r\nCREATE ROLE app_user WITH LOGIN PASSWORD 'SenhaForte123!';\r\nGRANT CONNECT ON DATABASE minha_base TO app_user;\r\n\r\n-- 2. D\u00e1 acesso ao schema e \u00e0s tabelas que j\u00e1 existem hoje<\/span>\r\nGRANT USAGE ON SCHEMA vendas TO app_user;\r\nGRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA vendas TO app_user;\r\n\r\n-- 3. Garante que TABELAS FUTURAS criadas nesse schema j\u00e1 saiam com o mesmo acesso<\/span>\r\n-- (equivalente funcional a n\u00e3o existir no SQL Server: l\u00e1, cada objeto novo<\/span>\r\n-- herda do db_datareader\/db_datawriter automaticamente por causa da role fixa)<\/span>\r\nALTER DEFAULT PRIVILEGES FOR ROLE postgres IN SCHEMA vendas\r\n GRANT SELECT, INSERT, UPDATE ON TABLES TO app_user;<\/code><\/pre>\ndb_datareader<\/code> j\u00e1 resolve leitura para objetos futuros, porque \u00e9 um papel de database inteiro. No Postgres, um GRANT<\/code> comum vale s\u00f3 para os objetos que j\u00e1 existem<\/strong> no momento em que ele \u00e9 executado \u2014 uma tabela criada depois n\u00e3o herda nada automaticamente, a menos que exista uma regra de ALTER DEFAULT PRIVILEGES<\/code> configurada de antem\u00e3o, associada a quem vai criar os objetos novos.<\/p>\n
\nComparativo lado a lado<\/h2>\n