Scripts SQL e Gerenciamento de Acesso

Procedimento atualizado para criar usuários técnicos e conceder permissões no Azure PostgreSQL Flexible Server para uso com QGIS.

Este guia documenta o procedimento que funciona no ambiente atual da Urbis para criar usuários de acesso ao PostgreSQL/PostGIS usado pelo QGIS. O foco aqui é Azure Database for PostgreSQL Flexible Server, onde existem limitações importantes em relação a um PostgreSQL self-hosted ou com superusuário completo.

Quando usar este guia

Use este documento quando precisar:

criar um novo usuário técnico para uso no QGIS;
conceder acesso amplo a um ou mais bancos de aplicação;
validar se o usuário realmente consegue conectar e operar no banco;
ajustar permissões sem depender de superusuário global.

[!IMPORTANT] Contexto real do ambiente: no Azure PostgreSQL Flexible Server, o usuário administrador não é superuser global. Por isso, alguns GRANT ALL sobre extensões como PostGIS e pg_trgm podem retornar warnings do tipo no privileges were granted, o que é esperado.

Premissas

Antes de executar qualquer comando:

tenha o host, porta, usuário administrador e senha do servidor PostgreSQL;
saiba em quais databases o usuário deve acessar, por exemplo: integracoes, urbis, arandu;
execute os comandos com sslmode=require;
se o nome do usuário tiver hífen, escreva-o sempre entre aspas duplas, por exemplo: "urbis-qgis".

Fluxo recomendado

O fluxo correto para este ambiente é:

conectar com o usuário administrador do Azure;
criar o usuário com LOGIN;
conceder permissões por database;
conceder permissões no schema public;
aplicar ALTER DEFAULT PRIVILEGES para novos objetos criados pelo administrador;
testar login real com o usuário novo.

1. Conectar no servidor

Exemplo com psql:

export PGPASSWORD='<senha_admin>'

psql "host=<host>.postgres.database.azure.com port=5432 dbname=postgres user=<admin> sslmode=require"

Exemplo real do ambiente:

export PGPASSWORD='<senha_admin>'

psql "host=slui-geoserver.postgres.database.azure.com port=5432 dbname=postgres user=postgres sslmode=require"

2. Criar o usuário

Se quiser recriar do zero, remova antes. Isso é útil quando a senha precisa ser regenerada.

DROP ROLE IF EXISTS "urbis-qgis";

CREATE ROLE "urbis-qgis"
WITH LOGIN
PASSWORD '<senha_forte>'
INHERIT
CREATEDB
CREATEROLE;

[!TIP] Use uma senha forte, com alta entropia, e distribua essa credencial apenas pelos canais internos autorizados.

3. Conceder acesso ao database

Para cada database que o usuário deve acessar, conceda os privilégios de conexão e criação no database:

GRANT CONNECT, TEMP ON DATABASE "integracoes" TO "urbis-qgis";
GRANT CREATE ON DATABASE "integracoes" TO "urbis-qgis";

Se o usuário precisar acessar múltiplos bancos, repita o processo em cada um deles.

Databases já validados neste ambiente

Os grants abaixo já foram testados com sucesso neste servidor:

arandu
integracoes
postgres
slui-geoserver
sluigeoserver
urbis

[!WARNING] Evite aplicar esse procedimento em databases internos da Azure, como azure_sys e azure_maintenance.

4. Conceder permissões dentro do schema `public`

Depois de conceder acesso ao database, conecte-se em cada database alvo e aplique os grants no schema:

GRANT USAGE, CREATE ON SCHEMA public TO "urbis-qgis";
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO "urbis-qgis";
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO "urbis-qgis";
GRANT ALL PRIVILEGES ON ALL FUNCTIONS IN SCHEMA public TO "urbis-qgis";

Esses comandos permitem que o usuário técnico consiga:

ler tabelas existentes;
inserir, atualizar e remover dados;
usar sequences;
criar objetos no schema public;
consumir funções disponíveis quando o provedor permitir.

5. Garantir acesso em objetos novos

Para que tabelas, sequences e funções novas criadas pelo administrador também fiquem acessíveis ao usuário técnico, aplique ALTER DEFAULT PRIVILEGES dentro de cada database alvo:

ALTER DEFAULT PRIVILEGES FOR ROLE postgres IN SCHEMA public
GRANT ALL PRIVILEGES ON TABLES TO "urbis-qgis";

ALTER DEFAULT PRIVILEGES FOR ROLE postgres IN SCHEMA public
GRANT ALL PRIVILEGES ON SEQUENCES TO "urbis-qgis";

ALTER DEFAULT PRIVILEGES FOR ROLE postgres IN SCHEMA public
GRANT ALL PRIVILEGES ON FUNCTIONS TO "urbis-qgis";

[!IMPORTANT] Ajuste o nome do role em FOR ROLE postgres caso o dono real dos objetos seja outro usuário administrador.

6. Exemplo completo por database

O bloco abaixo representa o procedimento completo para um database, por exemplo urbis:

GRANT CONNECT, TEMP ON DATABASE "urbis" TO "urbis-qgis";
GRANT CREATE ON DATABASE "urbis" TO "urbis-qgis";

\c urbis

GRANT USAGE, CREATE ON SCHEMA public TO "urbis-qgis";
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO "urbis-qgis";
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO "urbis-qgis";
GRANT ALL PRIVILEGES ON ALL FUNCTIONS IN SCHEMA public TO "urbis-qgis";

ALTER DEFAULT PRIVILEGES FOR ROLE postgres IN SCHEMA public
GRANT ALL PRIVILEGES ON TABLES TO "urbis-qgis";

ALTER DEFAULT PRIVILEGES FOR ROLE postgres IN SCHEMA public
GRANT ALL PRIVILEGES ON SEQUENCES TO "urbis-qgis";

ALTER DEFAULT PRIVILEGES FOR ROLE postgres IN SCHEMA public
GRANT ALL PRIVILEGES ON FUNCTIONS TO "urbis-qgis";

7. Validar o acesso

Depois da criação, o passo mais importante é testar com login real usando o novo usuário.

Exemplo de teste no database urbis:

export PGPASSWORD='<senha_do_novo_usuario>'

PGUSER='urbis-qgis' \
PGHOST='slui-geoserver.postgres.database.azure.com' \
PGPORT='5432' \
PGDATABASE='urbis' \
PGSSLMODE='require' \
psql -v ON_ERROR_STOP=1 -tAc "SELECT current_user, current_database(); CREATE TEMP TABLE cline_priv_test(id int); INSERT INTO cline_priv_test VALUES (1); SELECT count(*) FROM cline_priv_test;"

Saída esperada:

urbis-qgis|urbis
CREATE TABLE
INSERT 0 1
1

Isso confirma que o usuário consegue:

autenticar;
criar tabela temporária;
inserir dados;
consultar dados.

8. Verificar privilégios de forma objetiva

Para validar rapidamente se o usuário tem CREATE no database e USAGE, CREATE no schema public, use:

SELECT
  current_user,
  current_database(),
  has_database_privilege(current_user, current_database(), 'CREATE'),
  has_schema_privilege(current_user, 'public', 'USAGE,CREATE');

Resultado esperado:

urbis-qgis|urbis|t|t

Limitações conhecidas no Azure

Alguns warnings são esperados ao aplicar grants amplos, por exemplo:

WARNING: no privileges were granted for "geometry_columns"
WARNING: no privileges were granted for "word_similarity"

Isso normalmente ocorre em objetos de extensões gerenciadas pelo provedor. Esses avisos não invalidam o acesso principal ao banco e ao schema public.

Revogar ou remover acesso

Para remover o usuário por completo:

DROP ROLE IF EXISTS "urbis-qgis";

Para apenas trocar a senha:

ALTER ROLE "urbis-qgis" WITH PASSWORD '<nova_senha_forte>';

Boas práticas

nunca distribua credenciais de administrador para equipes de operação em QGIS;
prefira um usuário técnico por contexto de uso;
registre em quais databases cada usuário recebeu grants;
valide sempre com login real antes de entregar a credencial;
rotacione senhas periodicamente;
mantenha a projeção SIRGAS 2000 / UTM como padrão dos dados geográficos do projeto.

Relação com o guia do QGIS

Este documento complementa o guia de Integração com o QGIS. Depois que o usuário for criado e validado, use essas credenciais para configurar a conexão PostgreSQL/PostGIS no QGIS.

Scripts SQL e Gerenciamento de Acesso

On this page