APRENDER. PRATICAR. EVOLUIR.Separar ligação, schema e objeto
Um serviço pode autenticar-se e ainda assim receber permission denied ao consultar uma tabela. No laboratório, app_a possui SELECT em service.old_data, mas falta USAGE no schema. A primeira consulta falha; conceder USAGE permite ler a linha existente. Este contraste localiza a dependência em falta sem dar capacidade de criar objetos. A etapa seguinte tenta CREATE TABLE e continua a falhar. No incidente, recolhe a operação completa, identidade efetiva e objeto qualificado. O êxito de uma ligação, de um SELECT 1 ou de uma consulta feita pelo administrador não demonstra que o caminho da aplicação esteja autorizado.
Seguir todos os caminhos de concessão
A equipa remove um grant direto e espera que o acesso desapareça. No ensaio, app_a continua a ler porque também pertence a reader com INHERIT TRUE. Revogar a concessão direta remove apenas esse caminho; não representa uma negação que prevaleça sobre os restantes. Antes de declarar a revogação concluída, inspeciona memberships e concessões a PUBLIC, além das permissões diretas. A correção deve corresponder à intenção: retirar uma exceção individual é diferente de retirar todo o acesso. Testa com a identidade afetada e mantém uma matriz das operações que devem continuar disponíveis para evitar interromper funções legítimas.
Distinguir herança de mudança de role
O ensaio separa duas configurações. app_a herda os privilégios de reader, mas SET FALSE impede SET ROLE reader. operator tem membership em manual_reader com INHERIT FALSE e SET TRUE: a leitura falha inicialmente, funciona depois da mudança e volta a falhar após RESET ROLE. Durante a mudança, session_user continua operator e current_user passa a manual_reader. Regista ambas as identidades quando investigares diferenças entre sessões. Uma política que usa current_user pode comportar-se de outra forma após SET ROLE. Num pool, a recuperação da identidade deve fazer parte da reutilização; este laboratório não implementa nem valida um pool real.
Autorizar a sequência usada pelo INSERT
A aplicação recebe INSERT na tabela jobs, mas inserir apenas label continua a falhar. A coluna serial obtém o identificador através de uma sequência, que tem privilégios próprios. O erro do ensaio identifica jobs_id_seq; conceder USAGE nessa sequência permite concluir a inserção. A decisão deve partir da expressão efetivamente executada e do erro recolhido. Não generalizes este resultado para todas as estratégias de geração de identificadores nem concedas privilégios sobre todas as sequências sem inventário. Se a aplicação também usar RETURNING, verifica as permissões de leitura das colunas devolvidas num teste separado. Aqui o INSERT executado não contém RETURNING.
Tratar projeções como parte do contrato
O suporte precisa de id e email de contactos fictícios, sem acesso ao campo secret. O grant por coluna permite SELECT id,email e rejeita SELECT *. A alteração de uma ferramenta para selecionar todas as colunas pode, portanto, quebrar uma consulta que antes estava corretamente autorizada. Mantém projeções explícitas e testa os comandos emitidos pelo cliente, incluindo filtros e expressões. Não transformes o erro numa justificação automática para alargar acesso à tabela inteira. A matriz de aceitação deve conter a consulta permitida e a consulta proibida; uma delas, isoladamente, deixa por demonstrar metade do requisito.
Preparar uma mudança de acessos verificável
Num handover fictício, o deployer consegue executar todas as queries e propõe encerrar a mudança. A equipa de RUN deve repetir as operações com as contas de runtime, incluindo negações esperadas e recuperação da identidade. Guarda SQLSTATE, identidade, objeto e resultado sem colocar dados sensíveis no relatório. Define a reversão dos grants e memberships alterados, preservando o registo do estado anterior. O laboratório demonstra autorização SQL local com autenticação trust num socket privado; não demonstra passwords, TLS, identidade federada ou isolamento entre utilizadores do sistema operativo. Estes limites devem permanecer explícitos quando a evidência é usada numa aprovação de release.
SELECT session_user, current_user;
SELECT has_schema_privilege(current_user, 'service', 'USAGE');
SELECT has_table_privilege(current_user, 'service.old_data', 'SELECT');
-- In the owned lab, connect as operator before switching:
SET ROLE manual_reader;
SELECT session_user, current_user;
RESET ROLE;app_a tem SELECT sobre uma tabela, mas só consegue consultá-la depois de receber USAGE no schema service.
Armadilhas comuns
Dar ALL para corrigir um erro isolado; testar apenas com o owner; confundir membership com SET ROLE; ignorar sequências.
Tópicos relacionados: Identidade efetiva e menor privilégio · Aceitação e recuperação de mudanças
Um grant isolado não descreve o acesso efetivo. Regista identidade, memberships, schema, objeto e dependências.
Referência: Object and column privileges · PostgreSQL 18 reference semantics;18.6 current stable at review