Hacking do histórico de consultas do Postgresql

[posso] ter 100% de certeza de que o servidor de banco de dados não possui memória de consultas executadas com sucesso e, portanto, ninguém mais pode ter acesso a essas informações?

Não, você nunca pode ter 100% de certeza disso.

O PostgreSQL mantém um cache de plano interno. Atualmente, esse cache é usado apenas para instruções preparadas; declarações one-shot não vão para o cache. No entanto, se você usar uma instrução preparada, o plano será armazenado em cache e, quando não for mais necessário, o plano em cache será invalidado, mas não necessariamente excluído, até que o back-end do PostgreSQL que o armazenou em cache seja encerrado.

O PostgreSQL armazena a string de consulta em uma variável de depuração interna. Quando uma nova consulta substitui a antiga, a variável de depuração é substituída. Se a nova consulta for mais curta que a antiga, parte da consulta antiga não será substituída.

Uma consulta pode estar executando um back-end que possui páginas de memória gravadas em disco no espaço de troca devido à pressão da memória. Essa memória pode conter a string de consulta e/ou parâmetros. Esse espaço de troca não é necessariamente substituído mesmo após a conclusão da consulta e o encerramento do back-end. Se o servidor for desligado abruptamente, o disco rígido poderá ser analisado forense e descobrir o texto da consulta.

Quando o PostgreSQL libera os objetos do planejador/executor de consultas internas, ele não os zera. Apenas marca a memória como livre para reutilização. Essa memória permanece mapeada até que o back-end do PostgreSQL saia e pode conter texto de consulta, valores de parâmetros, etc.

Quando um back-end do PostgreSQL sai, o kernel geralmente não zera sua memória, apenas a marca como liberada. Um invasor que pode explorar o kernel para obter acesso de leitura de memória bruta pode ver algumas consultas anteriores (e, é claro, todas as atuais).

Então se:

• Você criptografou o espaço de troca com uma senha fornecida interativamente na inicialização;

• Você aceita que qualquer pessoa com acesso físico à máquina provavelmente poderá explorá-la para recuperar o histórico de consultas recentes;

• Você entende que qualquer pessoa com acesso root, ou acesso como postgresusuário do sistema, pode rastrear a execução do PostgreSQL e capturar dados de consulta (mas não retroativamente); e

• Você só se preocupa com a capacidade de recuperação do texto da consulta depois que o back-end individual do PostgreSQL que executou essa consulta foi encerrado

então desligar o registro provavelmente é bom o suficiente. Você também precisa evitar o uso de extensões como pg_stat_planse pg_stat_statementsque podem capturar o texto da consulta e gravá-lo no banco de dados.

Observe que, se PL/Python, PL/Perl, etc. estiverem instalados, ou alguns módulos contrib estiverem presentes, pode ser bastante fácil escalar o acesso do postgresusuário do banco de dados (ou outro superusuário) para o postgresusuário do shell. A partir daí, você pode reconfigurar o banco de dados para habilitar o log, instalar extensões, injetar código C, etc.

Um invasor que obtém acesso mesmo como proprietário da tabela pode instalar um FOR EACH STATEMENTgatilho nas tabelas de interesse que registra as consultas que afetam essas tabelas. Isso não funcionará para SELECT, mas funcionará para todo o resto. Eles nem precisam ser superusuários do banco de dados para isso.

Geralmente, suas consultas não devem ser sensíveis à segurança tanto quanto seus dados de parâmetro de consulta . Você pode reduzir bastante as chances de ser capturado ou registrado usando parâmetros de ligação apropriados, por exemplo, libpq's PQexecParams, classe de PgJDBC PreparedStatement, etc.

Mais importante, porém... se você deseja manter a segurança do banco de dados, não perca as credenciais de acesso privilegiado. Não use uma conta de superusuário, exceto do servidor de banco de dados e configurada pg_hba.confpara que o superusuário não possa fazer login remotamente. Não tenha aplicativos conectados ao banco de dados como a mesma conta que possui as tabelas que eles usam, use uma conta diferente e GRANTapenas os direitos que eles exigem. etc.

O IMO PostgreSQL precisa de uma extensão no protocolo que permita marcar os parâmetros de consulta como "sensíveis". Esses parâmetros de consulta nunca devem ser emitidos em arquivos de log, mostrados pg_stat_activityou registrados de outra forma. No entanto, esse recurso não existe atualmente e não tenho conhecimento de ninguém trabalhando nele