Segurança do PostgreSQL 2026: Riscos, Soluções e Melhores Práticas

Principais conclusões

• O PostgreSQL vem com configurações padrão razoáveis, mas “razoável” não significa “pronto para produção” – a autenticação, a exposição à rede e os privilégios de funções precisam passar por um processo ativo de fortalecimento de segurança antes de entrar em produção.
• Recursos integrados como o SCRAM-SHA-256, a segurança no nível da linha e a criptografia TLS fazem a maior parte do trabalho pesado, mas somente se você realmente os ativar e os auditar regularmente.
• Para implantações que executam o PostgreSQL 13 após o fim do suporte (EOL) em novembro de 2025, a TuxCare fornece correções contínuas para vulnerabilidades pelo tempo que for necessário, até que você possa realizar a migração.

A maioria das violações de segurança no PostgreSQL não começa com uma vulnerabilidade de dia zero. Elas começam com uma exceção temporária – trust autenticação restante em pg_hba.conf depois de uma sessão de depuração que se prolongou até tarde – e que ninguém nunca mais tira de lá.

A segurança do PostgreSQL em 2026 tem menos a ver com ataques exóticos e mais com o trabalho pouco glamoroso de manter as configurações rigorosas, os patches atualizados e os limites de acesso rigorosamente aplicados. A verdade embaraçosa é que a maioria das violações é evitável — elas acontecem porque as tarefas enfadonhas não foram realizadas. A seguir, apresentamos as ameaças que realmente estão afetando as implantações do PostgreSQL neste momento, as defesas integradas que fazem a diferença e as medidas de fortalecimento que valem a pena adotar.

Por que os usuários do PostgreSQL devem se preocupar com a segurança?

O PostgreSQL possui um modelo de segurança realmente robusto — esse não é o problema. O problema é que a segurança em ambiente de produção ainda depende de uma configuração cuidadosa: os padrões são ajustados para permitir que o sistema comece a funcionar, não para mantê-lo seguro sob tráfego real. Métodos de autenticação, endereços de escuta, privilégios de funções, registro de logs — tudo isso precisa de configuração deliberada. Não é uma falha no software; é apenas uma lacuna que cada equipe precisa preencher por conta própria, e muitas não o fazem até que algo dê errado.

O panorama das ameaças também mudou de maneiras que pegam as equipes de surpresa. As operações de cryptojacking agora utilizam scanners automatizados que procuram especificamente por instâncias expostas do PostgreSQL na porta 5432, instalando mineradores por meio de PL/Python ou PL/Perl assim que conseguem acesso. Injeção de SQL isso ainda é importante sempre que há SQL dinâmico, extensões ou linguagens procedurais envolvidas. Por outro lado — e cada vez mais —, ataques à cadeia de suprimentos nas dependências do seu aplicativo podem extrair .pgpass arquivos, variáveis de ambiente ou cadeias de conexão antes mesmo que o PostgreSQL receba uma solicitação. E se a sua organização estiver sujeita a PCI DSS, HIPAA, ou SOC 2, a questão não é se você deve reforçar a segurança do seu banco de dados — os auditores vão exigir isso e vão querer provas documentadas, não apenas boas intenções.

As equipes que lidam bem com isso tratam a dívida de segurança da mesma forma que tratam a dívida técnica — elas a monitoram, planejam e a reduzem gradualmente. As que não fazem isso tendem a descobrir da maneira mais difícil, geralmente no pior momento possível.

Ameaças comuns à segurança do PostgreSQL

Nenhuma das ameaças abaixo é hipotética. Elas são o que está sendo ativamente explorado contra implantações do PostgreSQL neste exato momento — muitas vezes contra equipes que acreditavam sinceramente estar com a segurança em dia.

Ameaça nº 1: Injeção de SQL por meio de extensões e linguagens procedurais

A injeção de SQL é o ataque mais antigo que existe, mas o ecossistema de extensões do PostgreSQL continua encontrando novas maneiras de mantê-lo relevante. O CVE-2025-1094, divulgado em fevereiro de 2025, é um bom exemplo de como isso evolui — tratava-se de uma falha nas funções de escapamento da libpq (PQescapeLiteral, PQescapeIdentifier e outras): elas não conseguiam neutralizar a sintaxe de escapamento em textos contendo sequências de bytes inválidas; assim, quando essa saída era enviada ao psql, um invasor podia realizar uma injeção de SQL. Ela apresentava uma pontuação CVSS de 8,1, afetava todas as versões suportadas anteriores às 17.3, 16.7, 15.11, 14.16 e 13.19 e — segundo a Rapid7 — era necessária em todos os cenários testados para transformar a falha da BeyondTrust (CVE-2024-12356) em execução remota de código.

O interessante sobre essa vulnerabilidade (CVE) é que não se tratava de uma técnica nova — o tratamento de sequências de bytes inválidas já é uma classe de problemas conhecida há anos. Simplesmente não havia sido identificada nesse caminho de código específico até que alguém investigasse a fundo.

As linguagens procedurais ampliam a superfície de ataque de uma maneira diferente. É o não confiável linguagens procedurais – PL/Python (que existe apenas como plpython3u) e plperlu – que pode executar código arbitrário no nível do sistema operacional. Essa é uma funcionalidade, não um bug. O problema é o contrário do que as pessoas imaginam: um confiável linguagem como plperl está isolado em sandbox e é seguro para usuários sem privilégios, enquanto apenas os superusuários podem criar funções em ambientes não confiáveis. Portanto, o verdadeiro risco está em conceder essa capacidade — ou o próprio acesso de superusuário — com mais liberdade do que você imagina. Uma equipe de SaaS com 40 pessoas que utiliza um banco de dados compartilhado não deveria conceder CREATE FUNCTION para qualquer pessoa que não seja o DBA – mas muitos fazem isso, porque é mais rápido do que escrever scripts de migração adequados e ninguém imagina que isso vá fazer diferença até que realmente faça.

Dica profissional: A correção não é nada glamorosa. Parametrize todas as consultas, restrinja quem pode executá-las CREATE EXTENSION e criar funções em linguagens não confiáveis, auditar suas extensões instaladas periodicamente e revogar CREATE de qualquer função, sem que haja uma necessidade operacional documentada para tal.

Ameaça nº 2: Configuração incorreta do pg_hba.conf

Esse é o erro mais comum em matéria de segurança no PostgreSQL. O arquivo de autenticação baseado no host controla quem pode se conectar ao seu banco de dados, de onde e por meio de qual método. Uma única linha mal configurada pode, sem que você perceba, deixar seu banco de dados exposto à internet.

Os dois padrões que mais prejudicam as equipes:

• A autenticação por confiança permaneceu em produção após a depuração local. Com a autenticação por confiança, o PostgreSQL aceita qualquer nome de usuário sem senha, desde que a conexão venha de um host autorizado.
• Entradas de host com curinga (0.0.0.0/0), combinadas com métodos de senha pouco seguros, expõem o banco de dados à internet, protegido por nada mais do que uma senha fácil de adivinhar.

pg_hba.conf é avaliada de cima para baixo, e a primeira regra que corresponder prevalece. Esse é o detalhe que mais confunde as pessoas: uma regra permissiva acima de uma regra restritiva não é substituída — ela prevalece silenciosamente, sempre, sem nenhum erro ou aviso. Você acaba com uma conexão que nunca deveria ter sido permitida, e nada nos registros indica por que isso aconteceu.

Observação: Se sua instância do PostgreSQL estiver acessível a partir de qualquer endereço fora de 127.0.0.1 ou de sua VPC privada, pare de ler e verifique esse arquivo primeiro.

Ameaça nº 3: CVEs sem correção

O PostgreSQL lança atualizações de segurança em um cronograma previsível – o problema não são os lançamentos, e sim o intervalo entre o momento em que são “lançadas” e o momento em que são “aplicadas em produção”. O CVE-2024-10979, divulgado em novembro de 2024, é um bom exemplo do que está em jogo: uma falha de alta gravidade (CVSS 8,8) no PL/Perl permitia que usuários sem privilégios modificassem variáveis de ambiente, como PATH, e executassem código arbitrário. Todas as versões anteriores às 17.1, 16.5, 15.9, 14.14, 13.17 e 12.21 foram afetadas.

São seis ramificações de versão secundária. Muitas equipes trabalhavam em pelo menos uma delas, e muitas ainda trabalham em uma delas até hoje.

Além disso, há o problema do fim do ciclo de vida, que é, sem dúvida, ainda pior. O suporte da comunidade do PostgreSQL dura cinco anos por versão principal. O PostgreSQL 12 atingiu o fim do ciclo de vida (EOL) em novembro de 2024, e o PostgreSQL 13 seguiu o mesmo caminho em novembro de 2025. Ambos estão agora em operação sem patches de segurança do desenvolvedor original — sem correções, independentemente da gravidade, a menos que você faça a atualização ou contrate suporte estendido.

Se você estiver preso a qualquer uma dessas versões devido a uma dependência de aplicativo ou a uma migração de plataforma que não para de ser adiada, você precisa de um plano. A TuxCare oferece o Suporte de Ciclo de Vida Ilimitado (ELS) especificamente para o PostgreSQL 13 após o fim do suporte (EOL), o que significa que sua implantação continuará recebendo patches de segurança enquanto você realiza a atualização.

Ameaça nº 4: Cryptojacking por meio da execução remota de código

Assim que um invasor consegue RCE em um host do PostgreSQL, a mineração de criptomoedas é o caminho de menor resistência. É um risco baixo para eles — não há exfiltração de dados a ser realizada, nem negociação de ransomware para lidar — apenas recursos computacionais que estão utilizando de graça. Scanners automatizados procuram instâncias expostas na porta 5432, realizam ataques de tentativa de senha contra o superusuário do PostgreSQL e, em caso de sucesso, instalam um minerador por meio de COPY ... FROM PROGRAM ou PL/Python.

A maioria das equipes descobre isso da mesma maneira: a CPU do servidor do banco de dados fica estagnada em 100%, as consultas ficam cada vez mais lentas até pararem completamente, e alguém finalmente abre htop e percebe um processo que não reconhece. Nesse momento, o invasor geralmente já está no sistema há dias.

As medidas de defesa se sobrepõem amplamente às práticas gerais de fortalecimento da segurança: não exponha a porta 5432 à internet, implemente autenticação forte no postgres superusuário e outras funções privilegiadas, e bloquear os recursos que os invasores exploram para a execução de código – restringir COPY ... FROM PROGRAM (já restrito a superusuários e funções concedidas pg_execute_server_program) e evite instalar linguagens procedurais não confiáveis, como PL/Python, a menos que você realmente precise delas.

Ameaça nº 5: Ataques à cadeia de suprimentos por meio de dependências

Um dos riscos mais graves do PostgreSQL não é um Vulnerabilidade do PostgreSQL De forma alguma — trata-se da camada de aplicação. Pacotes npm maliciosos ou comprometidos foram flagrados fazendo exatamente o que seria de se esperar: lendo variáveis de ambiente, coletando dados .pgpass arquivos e extraindo discretamente as sequências de conexão. Assim que essas credenciais forem divulgadas, seu banco de dados se tornará o alvo — independentemente do nível de segurança do próprio PostgreSQL.

O PostgreSQL não consegue se proteger contra isso por conta própria — as credenciais foram roubadas antes mesmo de chegarem ao banco de dados. A solução está na forma como você gerencia a separação entre o código da aplicação e o acesso ao banco de dados: alterne as credenciais periodicamente, limite cada usuário do banco de dados às permissões mínimas de que ele realmente precisa e utilize credenciais de curta duração ou gerenciamento de segredos, sempre que sua pilha de tecnologia permitir.

Para uma análise mais aprofundada sobre o aspecto das dependências desse problema, o artigo da TuxCare sobre dependências transitivas e o guia sobre SBOMs são os pontos de partida ideais.

Principais recursos de segurança do PostgreSQL

O PostgreSQL oferece os recursos básicos para construir um modelo de segurança sólido. A seguir, apresentamos os recursos que realmente fazem diferença na prática, juntamente com os detalhes de configuração que distinguem o que é “tecnicamente viável” do que “realmente funciona”.

Recurso nº 1: Métodos de autenticação

O PostgreSQL oferece suporte a uma longa lista de métodos de autenticação, mas os que valem a pena usar em 2026 são o SCRAM-SHA-256, a autenticação baseada em certificado e a integração com um provedor de identidade externo por meio de LDAP ou Kerberos.

O SCRAM-SHA-256 passou a ser o valor padrão para password_encryption no PostgreSQL 14 — já era compatível e recomendado desde o PostgreSQL 10 — substituindo o MD5, que apresenta vulnerabilidades bem documentadas. Mas eis o detalhe que muitas vezes passa despercebido: atualizar a versão do PostgreSQL não migra automaticamente os hashes de senha existentes.

Os usuários que definiram suas senhas antes da mudança ainda estão usando o MD5 nos bastidores até que as redefinam. É necessário definir explicitamente password_encryption = scram-sha-256 em postgresql.conf e forçar a renovação das senhas – e, mesmo assim, lembre-se de que as senhas existentes continuam com o hash MD5 até que cada usuário as redefina. Quando uma senha é armazenada como um hash SCRAM, um md5 linha em pg_hba.conf ele será autenticado automaticamente pelo SCRAM – portanto, o risco remanescente está nas senhas não redefinidas e na configuração pouco clara, e não na linha de autenticação que é executada silenciosamente.

A autenticação baseada em certificados é a opção mais segura para conexões entre serviços. Cada cliente apresenta um certificado assinado pela sua CA, e o PostgreSQL o verifica antes de aceitar a conexão. Não há senhas que possam vazar, nem segredos compartilhados em variáveis de ambiente.

Para usuários humanos, busque a integração com LDAP ou Kerberos para que você possa centralizar o gerenciamento de contas e o cancelamento de acesso. Um usuário que sair da empresa deve perder o acesso ao banco de dados no mesmo dia, automaticamente.

Recurso nº 2: Controle de acesso baseado em funções

O sistema de funções e privilégios do PostgreSQL é um dos mais detalhados entre todos os bancos de dados de código aberto. É possível conceder privilégios a bancos de dados, esquemas, tabelas, colunas, sequências, funções e muito mais. Também é possível criar hierarquias de funções, nas quais uma função herda os privilégios de outra.

O princípio fundamental é o seguinte: cada função recebe o mínimo de privilégios de que precisa e nada mais. Na prática, isso significa que as funções de aplicativo só podem executar SELECT, INSERT, UPDATE e DELETE nas tabelas específicas com as quais interagem — e não têm “TODOS OS PRIVILÉGIOS” sobre todo o esquema, e muito menos privilégios de superusuário.

Uma análise realista: a maioria das equipes que acredita estar seguindo o princípio do privilégio mínimo, na verdade, não está. O aplicativo se conecta como uma função com amplo acesso “para simplificar as coisas”, e ninguém mexe nisso porque reconstruir a matriz de privilégios é trabalhoso. Mas vale a pena fazer mesmo assim.

Recurso nº 3: Segurança no nível da linha

A Segurança em Nível de Linha (RLS) permite associar políticas às tabelas para filtrar quais linhas uma determinada função pode visualizar ou modificar. É a ferramenta ideal para aplicativos multilocatários, nos quais um único banco de dados armazena dados de vários clientes e é necessária uma garantia sólida de que o cliente A nunca possa visualizar as linhas do cliente B.

O que torna o RLS genuinamente valioso é que a garantia está no banco de dados, e não no aplicativo. A filtragem na camada de aplicativo pode ser esquecida, contornada por uma consulta que não inclua a cláusula WHERE correta ou silenciosamente prejudicada por uma abstração ORM. O RLS aplica a política no lado do servidor para as funções sujeitas a ela — uma consulta com erros que se esqueça de filtrar por tenant_id mesmo assim não haverá vazamento de linhas, pois o PostgreSQL aplica a política antes de retornar os resultados. A armadilha que costuma pegar as pessoas: proprietários de tabelas, superusuários e funções com BYPASSRLS ignorar políticas por padrão; portanto, certifique-se de que a função do seu aplicativo não seja nenhuma dessas e use FORCE ROW LEVEL SECURITY onde é importante.

O problema é que o RLS pode ser complicado de depurar e tem implicações no desempenho que você precisa testar. As políticas são avaliadas para cada linha, e políticas complexas em tabelas grandes podem prejudicar os planos de consulta. Teste-o sob carga realista antes de confiar nele.

Recurso nº 4: Criptografia SSL/TLS

Os dados em trânsito entre o cliente e o servidor devem ser criptografados. O PostgreSQL oferece suporte ao TLS, mas é preciso configurá-lo — ele não vem ativado por padrão na maioria das instalações.

Duas configurações que devem ser definidas corretamente: ssl = on no arquivo postgresql.conf e entradas hostssl (não host) no arquivo pg_hba.conf para qualquer conexão que deva ser criptografada. Sem a exigência do hostssl, os clientes ainda podem se conectar em texto simples, se assim o desejarem.

Para a verificação do cliente, defina sslmode=verify-full no lado do cliente. Isso faz com que o cliente verifique tanto o certificado do servidor quanto a correspondência do nome do host, impedindo ataques do tipo “man-in-the-middle”. sslmode=require por si só não é suficiente — ele criptografa a conexão, mas não verifica a identidade do servidor da maneira que verify-ca ou verify-full é verdade, portanto, um invasor na rede ainda pode se passar pelo servidor.Recurso nº 5: Registro de auditoria e pgAudit

O registro nativo do PostgreSQL captura muitas informações, mas, para trilhas de auditoria que atendam aos requisitos de conformidade, é recomendável utilizar a extensão pgaudit. Ela registra dados estruturados de cada instrução executada, indicando por qual função, em quais objetos e com quais parâmetros. Isso facilita muito a geração de evidências para SOC 2, HIPAA e PCI DSS — embora acarrete um volume significativo de registros caso o escopo seja definido de forma muito ampla.

Uma prática recomendada: limite o parâmetro `pgaudit.log` do pgAudit às categorias de que você realmente precisa — normalmente DDL, função e leitura para tabelas confidenciais — em vez de habilitar o registro generalizado. O registro completo de instruções em um banco de dados com alto volume de tráfego gera volumes que ninguém realmente lê, e o armazenamento dos registros se torna um problema operacional por si só. Registre o que seus auditores precisam, encaminhe os registros para o seu SIEM e resista à tentação de registrar tudo “por precaução”.

Melhores práticas para reforçar a segurança do PostgreSQL

O fortalecimento da segurança não é um projeto pontual. Trata-se de uma disciplina operacional contínua, e as equipes que a executam bem costumam ter sistemas que automatizam as tarefas mais enfadonhas. As práticas abaixo são onde essa disciplina se manifesta de fato.

1. Aplique as correções imediatamente

O único fator que distingue de forma mais consistente as implantações do PostgreSQL comprometidas das seguras é a latência das correções – o intervalo entre o momento em que uma vulnerabilidade CVE é divulgada e o momento em que a correção é efetivamente implementada em produção. É nesse intervalo que os invasores atuam, e quanto mais longo ele for, maior será a sua exposição.

Aplique atualizações de versão secundária imediatamente — elas contêm apenas correções de segurança e de bugs e não exigem nada além de uma reinicialização do serviço. O risco de aplicá-las é quase sempre menor do que o risco de ignorá-las. As equipes que ficam para trás geralmente são aquelas que esperam por uma janela de manutenção formal para justificar uma reinicialização de dois minutos.

2. Bloqueio pg_hba.conf e o acesso à rede

Trate o arquivo pg_hba.conf como um conjunto de regras de firewall. Documente cada entrada. Faça uma revisão periódica — a cada trimestre é uma frequência razoável. Remova tudo o que não estiver em uso ativo.

Regras específicas:

• Não use trust autenticação para qualquer conexão TCP, incluindo loopback; para conexões locais de soquete do domínio Unix, dar preferência a peer portanto, a identidade do banco de dados está vinculada ao usuário do sistema operacional.
• Use `hostssl` em vez de `host` para qualquer conexão não local.
• Restrinja os endereços IP de origem a intervalos CIDR específicos. 0.0.0.0/0 quase nunca é a resposta correta.
• Configure o PostgreSQL para usar endereços específicos com a opção `listen_addresses`, em vez de `*`.

Se você estiver executando em uma VPC na nuvem, combine isso com grupos de segurança para que o banco de dados só seja acessível a partir da camada de aplicativos. Defesa em profundidade – o arquivo pg_hba.conf é uma camada, e as ACLs de rede são outra.

3. Auditar regularmente funções, privilégios e extensões

A proliferação de funções ocorre em todos os bancos de dados de longa duração. Alguém precisa de acesso temporário como superusuário para uma migração. A concessão nunca é revogada. Multiplique isso por anos e você terá um gráfico de privilégios que ninguém compreende totalmente.

Realize uma revisão trimestral:

• Liste todos os papéis e seus privilégios usando o comando \du+ e a visualização information_schema.role_table_grants.
• Identifique as funções que não fizeram login nos últimos 90 dias. Desative-as ou, no mínimo, exija uma justificativa para mantê-las.
• Liste as extensões instaladas com o comando SELECT * FROM pg_extension. Qualquer extensão que não esteja em uso ativo representa um risco sem trazer nenhum benefício.
• Verifique se há funções com os privilégios SUPERUSER, CREATEDB ou CREATEROLE. Cada uma delas precisa ter um motivo documentado para existir.

O objetivo não é a perfeição. É garantir que seu modelo de privilégios reflita o que você realmente precisa hoje, e não o que você precisava há dois anos.

Ferramentas para reforçar a segurança do PostgreSQL

As ferramentas abaixo cobrem as principais lacunas em uma implantação padrão do PostgreSQL: aplicação de patches, auditoria, varredura e relatórios de conformidade. Nenhuma ferramenta sozinha realiza todas essas tarefas de maneira satisfatória; por isso, a maioria das equipes acaba utilizando uma combinação delas.

Ferramenta nº 1: TuxCare

O PostgreSQL 13 chegou ao fim do ciclo de vida em novembro de 2025, e o PostgreSQL 12, antes dele, em novembro de 2024. Ambas as versões estão agora em execução sem patches de segurança do desenvolvedor original — o que significa que não haverá correções da comunidade, independentemente da gravidade, até que você faça a atualização.

Para equipes que não podem atualizar imediatamente — devido a dependências de aplicativos, integrações de terceiros ou complexidade da migração —, o Suporte de Ciclo de Vida Ilimitado da TuxCare para o PostgreSQL 13 garante que essas implantações continuem recebendo patches de segurança enquanto uma migração adequada é planejada. Essa é uma abordagem significativamente diferente de manter o sistema sem patches e torcer para que nada crítico aconteça antes que você esteja pronto.

O argumento prático a favor do ELS é bem claro: uma atualização de versão principal feita às pressas, sob pressão de um CVE crítico, é exatamente o tipo de situação que causa interrupções no serviço. O ELS lhe dá tempo para realizar a migração da maneira correta.

Ferramenta nº 2: pgAudit

O pgAudit é a extensão padrão para o registro de logs de auditoria em conformidade com normas regulatórias no PostgreSQL. Ele gera entradas de log estruturadas que correspondem perfeitamente ao que os auditores do SOC 2, HIPAA e PCI DSS esperam ver. A configuração é simples, mas o volume de logs pode aumentar rapidamente — planeje o armazenamento e o envio para um SIEM, em vez de deixar os logs se acumularem localmente.

É gratuito, mantido e amplamente utilizado. A desvantagem é que ele apenas registra os logs, nada mais. Você ainda precisa de um sistema separado para realmente analisar os logs e emitir alertas sobre anomalias. Combine-o com qualquer SIEM que sua equipe de segurança já utilize.

Ferramenta nº 3: pg_stat_statements + Exportadores do Prometheus

Embora não seja uma ferramenta de segurança propriamente dita, o pg_stat_statements, combinado com um exportador do Prometheus (como o postgres_exporter), oferece a visibilidade no nível das consultas necessária para identificar padrões de uso indevido. Picos repentinos nas instruções COPY, consultas a catálogos do sistema feitas por funções de aplicativos ou contagens incomuns de conexões provenientes de novos endereços IP são sinais que merecem um alerta.

É a versão econômica de uma solução de monitoramento de atividades de banco de dados. Não é tão sofisticada quanto uma ferramenta dedicada de DAM, mas é gratuita, leve e suficiente para a maioria das equipes que não podem arcar com os custos de uma solução empresarial.

Ferramenta nº 4: Scanners de vulnerabilidades

Em ambientes em que o PostgreSQL é executado em servidores Linux sob seu controle, os verificadores de vulnerabilidades detectam CVEs conhecidos nos binários e nas dependências do PostgreSQL. A maioria dos verificadores indica o que está vulnerável, mas apresenta dificuldades na validação da correção — eles sinalizam um CVE como aberto mesmo depois de ter sido corrigido por meio de um backport, o que gera ruído e prejudica a confiança nos resultados.

Reforce a segurança do PostgreSQL com a TuxCare

A segurança do PostgreSQL não é um projeto com data de conclusão — é uma disciplina operacional contínua. Os CVEs não param de surgir, as configurações se desviam, as funções acumulam permissões que não deveriam ter e os prazos de EOL chegam, esteja você preparado ou não. As equipes que se mantêm à frente não estão fazendo nada de heróico. Elas criaram sistemas que tornam o trabalho rotineiro de segurança visível, repetível e difícil de deixar passar — de modo que o próximo CVE ou prazo de EOL seja uma tarefa programada, e não um alarme de incêndio.

Para equipes que utilizam o PostgreSQL 13 após o fim do suporte (EOL) em novembro de 2025, o Endless Lifecycle Support da TuxCare garante o fornecimento contínuo de patches de segurança enquanto a migração é planejada dentro de um prazo realista — e não em uma situação de crise forçada pela próxima vulnerabilidade crítica (CVE).

Perguntas frequentes