Seguridad de PostgreSQL 2026: riesgos, soluciones y buenas prácticas

Principales conclusiones

• PostgreSQL incluye unos valores predeterminados razonables, pero «razonables» no significa «listos para producción»: la autenticación, la exposición a la red y los privilegios de los roles deben reforzarse activamente antes de poner el sistema en producción.
• Las funciones integradas, como SCRAM-SHA-256, la seguridad a nivel de fila y el cifrado TLS, se encargan de la mayor parte del trabajo, pero solo si realmente las activas y las supervisas con regularidad.
• Para las implementaciones que ejecuten PostgreSQL 13 más allá de su fin de vida útil (EOL), fijado para noviembre de 2025, TuxCare proporciona parches de seguridad de forma continua durante el tiempo que sea necesario hasta que puedas realizar la migración.

La mayoría de las vulnerabilidades de PostgreSQL no se originan en una vulnerabilidad de día cero. Comienzan con una excepción temporal: trust autenticación pendiente en pg_hba.conf tras una sesión de depuración que se ha alargado hasta tarde —y que nadie vuelve a quitar nunca—.

La seguridad de PostgreSQL en 2026 no tiene tanto que ver con ataques exóticos como con la labor poco glamurosa de mantener las configuraciones rigurosas, los parches actualizados y los límites de acceso bien controlados. La vergonzosa verdad es que la mayoría de las brechas de seguridad se pueden prevenir: se producen porque no se han llevado a cabo las tareas aburridas. A continuación se detallan las amenazas que afectan realmente a las implementaciones de PostgreSQL en este momento, las defensas integradas que marcan la diferencia y las medidas de refuerzo que merecen tu tiempo.

¿Por qué deberían los usuarios de PostgreSQL preocuparse por la seguridad?

PostgreSQL cuenta con un modelo de seguridad realmente sólido; ahí no está el problema. El problema es que la seguridad en entornos de producción sigue dependiendo de una configuración deliberada: los valores predeterminados están ajustados para que el sistema funcione, no para garantizar la seguridad ante un tráfico real. Los métodos de autenticación, las direcciones de escucha, los privilegios de los roles, el registro de eventos… todo ello requiere una configuración específica. No se trata de un fallo del software, sino simplemente de una laguna que cada equipo debe subsanar por sí mismo, y que muchos no subsanan hasta que surge algún problema.

El panorama de amenazas también ha cambiado de formas que pillan desprevenidos a los equipos. Las operaciones de criptojacking utilizan ahora escáneres automatizados que buscan específicamente instancias de PostgreSQL expuestas en el puerto 5432 y, una vez dentro, instalan mineros a través de PL/Python o PL/Perl. Inyección SQL sigue siendo importante siempre que intervengan SQL dinámico, extensiones o lenguajes procedimentales. Por otra parte —y cada vez más—, los ataques a la cadena de suministro dirigidos a las dependencias de tu aplicación pueden extraer .pgpass archivos, variables de entorno o cadenas de conexión antes de que PostgreSQL reciba una solicitud. Y si tu organización está sujeta a PCI DSS, HIPAAo SOC 2, la cuestión no es si hay que reforzar la seguridad de tu base de datos: los auditores lo exigirán y querrán pruebas documentadas, no solo buenas intenciones.

Los equipos que gestionan bien esta cuestión tratan la deuda de seguridad del mismo modo que tratan la deuda técnica: la supervisan, la programan y la van liquidando de forma gradual. Los que no lo hacen suelen descubrirlo por las malas, normalmente en el peor momento posible.

Amenazas de seguridad habituales para PostgreSQL

Ninguna de las amenazas que se enumeran a continuación es hipotética. Son las que se están aprovechando activamente en este mismo momento contra implementaciones de PostgreSQL, a menudo contra equipos que creían sinceramente que tenían su seguridad bajo control.

Amenaza n.º 1: Inyección SQL a través de extensiones y lenguajes procedimentales

La inyección SQL es el ataque más antiguo que existe, pero el ecosistema de extensiones de PostgreSQL sigue encontrando nuevas formas de mantenerlo vigente. CVE-2025-1094, dado a conocer en febrero de 2025, es un buen ejemplo de cómo evoluciona esto: se trataba de una vulnerabilidad en funciones de escape de libpq (PQescapeLiteral, PQescapeIdentifier y otras): no lograban neutralizar la sintaxis de escape en texto que contenía secuencias de bytes no válidas, por lo que, cuando esa salida se introducía en psql, un atacante podía llevar a cabo una inyección SQL. Tenía una puntuación CVSS de 8,1, afectaba a todas las versiones compatibles anteriores a la 17.3, 16.7, 15.11, 14.16 y 13.19 y, según Rapid7, era necesaria en todos los escenarios que probaron para convertir la vulnerabilidad de BeyondTrust (CVE-2024-12356) en una ejecución remota de código.

Lo interesante de esta vulnerabilidad CVE es que no se trataba de una técnica novedosa: el tratamiento de secuencias de bytes no válidas es un tipo de problema conocido desde hace años. Simplemente no se había detectado en esta ruta de código concreta hasta que alguien lo investigó a fondo.

Los lenguajes procedimentales amplían la superficie de ataque de una forma diferente. Es el no fiable lenguajes procedimentales – PL/Python (que solo existe como plpython3u) y plperlu – que puede ejecutar código arbitrario a nivel del sistema operativo. Esa es la característica, no un error. La trampa es justo lo contrario de lo que la gente supone: un de confianza un lenguaje como plperl está aislada en un entorno de pruebas y es segura para los usuarios sin privilegios, mientras que solo los superusuarios pueden crear funciones en las que no son de confianza. Por lo tanto, el verdadero riesgo radica en conceder esa capacidad —o el propio acceso de superusuario— con más libertad de la que crees. Un equipo de SaaS de 40 personas que gestiona una base de datos compartida no debería conceder CREATE FUNCTION a nadie que no sea el administrador de bases de datos (DBA), pero hay muchos que lo hacen, porque es más rápido que escribir scripts de migración adecuados y nadie espera que eso tenga importancia hasta que la tiene.

Consejo de experto: La solución no es nada glamurosa. Hay que parametrizar todas las consultas y restringir quién puede ejecutarlas CREATE EXTENSION y crear funciones en lenguajes no fiables, auditar periódicamente las extensiones instaladas y revocar CREATE de cualquier función sin que exista una necesidad operativa justificada para ello.

Amenaza n.º 2: Configuración incorrecta de pg_hba.conf

Este es el error más habitual en materia de seguridad de PostgreSQL. El archivo de autenticación basado en el host controla quién puede conectarse a tu base de datos, desde dónde y mediante qué método. Una sola línea mal configurada puede exponer tu base de datos a Internet sin que te des cuenta.

Los dos patrones que más perjudican a los equipos:

• La autenticación por confianza se ha dejado activada en el entorno de producción tras la depuración local. Con la autenticación por confianza, PostgreSQL acepta cualquier nombre de usuario sin contraseña, siempre y cuando la conexión proceda de un host autorizado.
• Las entradas de host con comodines (0.0.0.0/0), combinadas con métodos de contraseñas poco seguras, exponen la base de datos a Internet sin más protección que una contraseña fácil de adivinar.

pg_hba.conf Se evalúa de arriba abajo y prevalece la primera regla que coincida. Este es el detalle que más confunde a la gente: una regla permisiva situada por encima de una estricta no queda anulada, sino que prevalece de forma silenciosa, siempre, sin que se produzca ningún error ni advertencia. El resultado es una conexión que nunca debería haberse permitido, y no hay nada en los registros que indique por qué se ha producido.

Nota: Si se puede acceder a tu instancia de PostgreSQL desde cualquier lugar fuera de 127.0.0.1 o de tu VPC privada, deja de leer y revisa primero este archivo.

Amenaza n.º 3: CVE sin parches

PostgreSQL publica actualizaciones de seguridad siguiendo un calendario predecible; el problema no son las actualizaciones en sí, sino el lapso de tiempo que transcurre entre el momento en que se «publican» y el momento en que se «aplican en producción». El CVE-2024-10979, revelado en noviembre de 2024, ilustra bien lo que está en juego: una vulnerabilidad de alta gravedad (CVSS 8,8) en PL/Perl permitía a usuarios sin privilegios modificar variables de entorno como PATH y ejecutar código arbitrario. Se vieron afectadas todas las versiones anteriores a la 17.1, 16.5, 15.9, 14.14, 13.17 y 12.21.

Son seis ramas de versiones menores. Muchos equipos trabajaban en al menos una de ellas, y muchos siguen haciéndolo hoy en día.

Luego está el problema del fin de vida útil, que podría decirse que es aún peor. El soporte de la comunidad de PostgreSQL tiene una duración de cinco años por cada versión principal. PostgreSQL 12 alcanzó su fin de vida útil en noviembre de 2024, y PostgreSQL 13 lo hizo en noviembre de 2025. Ambas versiones funcionan ahora sin parches de seguridad del desarrollador original: no se aplican correcciones, independientemente de su gravedad, a menos que se actualice o se contrate un soporte ampliado.

Si te ves obligado a seguir utilizando alguna de estas versiones debido a una dependencia de una aplicación o a una migración de plataforma que se va posponiendo continuamente, necesitas un plan. TuxCare ofrece el servicio «Endless Lifecycle Support» (ELS) específicamente para PostgreSQL 13 tras el fin de su ciclo de vida (EOL), lo que significa que tu implementación seguirá recibiendo parches de seguridad mientras llevas a cabo la actualización.

Amenaza n.º 4: Criptojacking mediante la ejecución remota de código

Una vez que un atacante consigue ejecución remota de código (RCE) en un servidor PostgreSQL, la minería de criptomonedas es la vía más fácil. Para ellos supone un riesgo mínimo —no hay que trasladar datos ni gestionar negociaciones de rescate—, solo están utilizando recursos informáticos de forma gratuita. Los escáneres automatizados buscan instancias expuestas en el puerto 5432, realizan ataques de prueba de credenciales contra el superusuario «postgres» y, si tienen éxito, instalan un minero a través de COPY ... FROM PROGRAM o PL/Python.

La mayoría de los equipos se dan cuenta de ello de la misma manera: la CPU del servidor de la base de datos se queda atascada al 100 %, las consultas se ralentizan hasta casi detenerse y, finalmente, alguien abre htop y detecta un proceso que no reconoce. Para entonces, el atacante suele llevar ya varios días infiltrado en el sistema.

Las medidas de defensa coinciden en gran medida con las de refuerzo general de la seguridad: no expongas el puerto 5432 a Internet, aplica una autenticación sólida en el postgres superusuario y otros roles con privilegios, y bloquear las funciones que los atacantes aprovechan para ejecutar código: restringir COPY ... FROM PROGRAM (ya restringido a los superusuarios y a los roles a los que se ha concedido pg_execute_server_program) y evita instalar lenguajes procedimentales de confianza dudosa, como PL/Python, a menos que realmente los necesites.

Amenaza n.º 5: Ataques a la cadena de suministro a través de las dependencias

Uno de los riesgos más graves de PostgreSQL no es un Vulnerabilidad de PostgreSQL En absoluto: se trata de la capa de aplicación. Se han detectado paquetes de npm maliciosos o comprometidos que hacían exactamente lo que cabría esperar: leer variables de entorno, extraer datos de .pgpass archivos y sustrayendo discretamente las cadenas de conexión. Una vez que esas credenciales han salido al exterior, tu base de datos se convierte en el objetivo, independientemente de lo bien protegida que esté la propia PostgreSQL.

PostgreSQL no puede proteger contra esto por sí solo: las credenciales fueron robadas antes incluso de llegar a la base de datos. La solución radica en cómo gestionas la separación entre el código de la aplicación y el acceso a la base de datos: renueva las credenciales periódicamente, limita los permisos de cada usuario de la base de datos al mínimo que realmente necesite y utiliza credenciales de corta duración o un sistema de gestión de secretos cuando tu entorno técnico lo permita.

Para profundizar en el aspecto de las dependencias de este problema, los artículos de TuxCare sobre las dependencias transitivas y su guía sobre SBOM son los puntos de partida idóneos.

Características clave de seguridad de PostgreSQL

PostgreSQL te ofrece los elementos básicos para crear un modelo de seguridad sólido. A continuación se enumeran las características que realmente importan en la práctica, junto con los detalles de configuración que marcan la diferencia entre lo que «técnicamente es posible» y lo que «funciona de verdad».

Característica n.º 1: Métodos de autenticación

PostgreSQL admite una amplia variedad de métodos de autenticación, pero los que más convienen utilizar en 2026 son SCRAM-SHA-256, la autenticación basada en certificados y la integración con un proveedor de identidad externo a través de LDAP o Kerberos.

SCRAM-SHA-256 pasó a ser el valor predeterminado para password_encryption En PostgreSQL 14 —aunque ya se admitía y recomendaba desde PostgreSQL 10— sustituyó a MD5, que presenta debilidades bien documentadas. Pero aquí está el detalle que a menudo se pasa por alto: actualizar la versión de PostgreSQL no migra automáticamente los hash de contraseñas existentes.

Los usuarios que configuraron sus contraseñas antes del cambio siguen utilizando MD5 en segundo plano hasta que las restablezcan. Debes configurar explícitamente password_encryption = scram-sha-256 en postgresql.conf y forzar la rotación de contraseñas; incluso en ese caso, recuerda que las contraseñas existentes seguirán almacenadas con el hash MD5 hasta que cada usuario las restablezca. Una vez que una contraseña se almacena como un hash SCRAM, un md5 línea en pg_hba.conf lo autenticará automáticamente con SCRAM, por lo que el riesgo que persiste son las contraseñas que no se han restablecido y una configuración poco clara, no que la línea de autenticación se imponga de forma silenciosa.

La autenticación basada en certificados es la opción más segura para las conexiones entre servicios. Cada cliente presenta un certificado firmado por tu CA, y PostgreSQL lo verifica antes de aceptar la conexión. No hay contraseñas que puedan filtrarse ni secretos compartidos en variables de entorno.

En el caso de los usuarios humanos, procura integrar LDAP o Kerberos para poder centralizar la gestión de cuentas y la baja de usuarios. Un usuario que abandone la empresa debería perder el acceso a la base de datos ese mismo día, de forma automática.

Característica n.º 2: Control de acceso basado en roles

El sistema de roles y privilegios de PostgreSQL es uno de los más detallados de todas las bases de datos de código abierto. Se pueden conceder privilegios sobre bases de datos, esquemas, tablas, columnas, secuencias, funciones y mucho más. También se pueden crear jerarquías de roles, en las que un rol hereda los privilegios de otro.

El principio fundamental es el siguiente: cada rol dispone de los privilegios mínimos que necesita y nada más. En la práctica, esto significa que los roles de aplicación solo pueden realizar operaciones SELECT, INSERT, UPDATE y DELETE en las tablas específicas con las que interactúan, sin tener «TODOS LOS PRIVILEGIOS» sobre todo el esquema y, desde luego, sin ser superusuarios.

Una dosis de realidad: la mayoría de los equipos que creen que están aplicando el principio del privilegio mínimo, en realidad no lo hacen. La aplicación se conecta con un rol que tiene un acceso amplio «para simplificar las cosas», y nadie se atreve a modificarla porque reconstruir la matriz de privilegios resulta tedioso. De todos modos, merece la pena hacerlo.

Característica n.º 3: Seguridad a nivel de fila

La seguridad a nivel de fila (RLS) te permite aplicar políticas a las tablas que filtran qué filas puede ver o modificar un rol determinado. Es la herramienta ideal para aplicaciones multicliente, en las que una misma base de datos almacena datos de muchos clientes y se necesita una garantía sólida de que el cliente A nunca pueda ver las filas del cliente B.

Lo que hace que RLS sea realmente valioso es que la garantía reside en la base de datos, no en la aplicación. El filtrado en la capa de aplicación puede pasarse por alto, eludirse mediante una consulta que no incluya la cláusula WHERE correcta o dejarse de aplicar de forma silenciosa debido a una abstracción ORM. RLS aplica la política en el lado del servidor para los roles sujetos a ella: una consulta con errores que se olvide de filtrar por tenant_id Aun así, no se filtrarán las filas, ya que PostgreSQL aplica la política antes de devolver los resultados. La salvedad que suele dar problemas a los usuarios: los propietarios de las tablas, los superusuarios y los roles con BYPASSRLS Por defecto, se omiten las políticas, así que asegúrate de que el rol de tu aplicación no sea ninguno de esos y utiliza FORCE ROW LEVEL SECURITY donde realmente importa.

El problema es que RLS puede resultar complicado de depurar y tiene implicaciones en el rendimiento que debes comprobar. Las políticas se evalúan para cada fila, y las políticas complejas en tablas de gran tamaño pueden afectar negativamente a los planes de consulta. Pruébalo con una carga realista antes de confiar en él.

Característica n.º 4: Cifrado SSL/TLS

Los datos que se transmiten entre el cliente y el servidor deben estar cifrados. PostgreSQL es compatible con TLS, pero hay que configurarlo, ya que no está activado de forma predeterminada en la mayoría de las instalaciones.

Hay dos ajustes que hay que configurar correctamente: «ssl = on» en el archivo «postgresql.conf» y entradas «hostssl» (no «host») en el archivo «pg_hba.conf» para cualquier conexión que deba estar cifrada. Sin el requisito «hostssl», los clientes pueden seguir conectándose en texto plano si así lo desean.

Para la verificación del cliente, configura sslmode=verify-full en el lado del cliente. De este modo, el cliente verifica tanto el certificado del servidor como la coincidencia del nombre de host, lo que impide los ataques de tipo «hombre en medio». sslmode=require por sí solo no es suficiente: cifra la conexión, pero no verifica la identidad del servidor de la misma forma que verify-ca o verify-full es así, por lo que un atacante a nivel de red aún puede suplantar la identidad del servidor.Característica n.º 5: Registro de auditoría y pgAudit

El registro nativo de PostgreSQL recoge mucha información, pero para obtener registros de auditoría que cumplan con los requisitos normativos, te conviene utilizar la extensión pgaudit. Esta extensión registra entradas estructuradas de cada instrucción ejecutada, indicando qué rol la ha ejecutado, sobre qué objetos y con qué parámetros. Facilita enormemente la obtención de pruebas para SOC 2, HIPAA y PCI DSS, aunque a costa de un volumen significativo de registros si se aplica con un alcance demasiado amplio.

Una recomendación práctica: limita el parámetro `pgaudit.log` de pgAudit a las categorías que realmente necesites —normalmente DDL, roles y lecturas de tablas confidenciales— en lugar de habilitar el registro generalizado. El registro completo de sentencias en una base de datos con mucho tráfico genera volúmenes que, en realidad, nadie lee, y el almacenamiento de los registros se convierte en un problema operativo en sí mismo. Registra lo que necesiten tus auditores, envíalo a tu SIEM y resiste la tentación de registrarlo todo «por si acaso».

Buenas prácticas para reforzar la seguridad de PostgreSQL

El refuerzo de la seguridad no es un proyecto puntual. Se trata de una disciplina operativa continua, y los equipos que la llevan a cabo correctamente suelen contar con sistemas que automatizan las tareas más tediosas. Las prácticas que se indican a continuación son donde realmente se pone de manifiesto esa disciplina.

1. Instala los parches lo antes posible

El único factor que distingue de forma más constante las implementaciones de PostgreSQL vulnerables de las seguras es la latencia de los parches: el lapso de tiempo que transcurre entre el momento en que se da a conocer una vulnerabilidad CVE y el momento en que la corrección se aplica realmente en el entorno de producción. Ese lapso es el margen de maniobra de los atacantes, y cuanto más amplio sea, mayor será tu exposición.

Aplica las actualizaciones de versión menor sin demora: solo contienen correcciones de seguridad y de errores, y lo único que requieren es reiniciar el servicio. El riesgo de aplicarlas es casi siempre menor que el de no hacerlo. Los equipos que se quedan atrás suelen ser aquellos que esperan a una ventana de mantenimiento oficial para justificar un reinicio de dos minutos.

2. Bloqueo pg_hba.conf y el acceso a la red

Trata el archivo `pg_hba.conf` como si fuera un conjunto de reglas de cortafuegos. Documenta cada entrada. Revísalo periódicamente; cada trimestre es una frecuencia razonable. Elimina todo aquello que no se esté utilizando activamente.

Normas específicas:

• No utilices trust autenticación para cualquier conexión TCP, incluida la de bucle invertido; para las conexiones locales mediante sockets de dominio Unix, se prefiere peer Por lo tanto, la identidad de la base de datos está vinculada al usuario del sistema operativo.
• Utiliza «hostssl» en lugar de «host» para cualquier conexión no local.
• Limita las direcciones IP de origen a rangos CIDR específicos. 0.0.0.0/0 casi nunca es la respuesta correcta.
• Configura PostgreSQL para que se conecte a direcciones específicas utilizando `listen_addresses`, en lugar de `*`.

Si estás ejecutando el servicio en una VPC en la nube, combínalo con grupos de seguridad para que solo se pueda acceder a la base de datos desde tu capa de aplicaciones. Defensa en profundidad: el archivo `pg_hba.conf` es una capa y las ACL de red son otra.

3. Revisar periódicamente las funciones, los privilegios y las extensiones de auditoría

La proliferación de roles es algo que ocurre en todas las bases de datos que llevan mucho tiempo en funcionamiento. Alguien necesita acceso temporal de superusuario para realizar una migración. Ese permiso nunca se revoca. Multiplica eso por años y obtendrás un grafo de privilegios que nadie comprende del todo.

Realizar una revisión trimestral:

• Enumera todos los roles y sus privilegios utilizando \du+ y la vista `information_schema.role_table_grants`.
• Identifica los perfiles que no hayan iniciado sesión en los últimos 90 días. Desactívalos o, como mínimo, exige una justificación para mantenerlos.
• Muestra las extensiones instaladas con SELECT * FROM pg_extension. Cualquier extensión que no se utilice activamente supone un riesgo sin aportar ningún beneficio.
• Comprueba si hay roles con los privilegios SUPERUSER, CREATEDB o CREATEROLE. Cada uno de ellos debe tener una justificación documentada para su existencia.

El objetivo no es la perfección. Se trata de asegurarte de que tu modelo de privilegios refleje lo que realmente necesitas hoy, no lo que necesitabas hace dos años.

Herramientas para reforzar la seguridad de PostgreSQL

Las herramientas que se indican a continuación cubren las principales carencias de una implementación predeterminada de PostgreSQL: aplicación de parches, auditoría, análisis de seguridad e informes de cumplimiento normativo. Ninguna herramienta por sí sola lo hace todo bien, por lo que la mayoría de los equipos acaban utilizando una combinación de ellas.

Herramienta n.º 1: TuxCare

PostgreSQL 13 llegó al final de su ciclo de vida en noviembre de 2025, y PostgreSQL 12, antes que esta, en noviembre de 2024. Ambas versiones funcionan ahora sin parches de seguridad del desarrollador original, lo que significa que no se recibirán correcciones de la comunidad, independientemente de su gravedad, hasta que se realice la actualización.

Para los equipos que no pueden actualizar de inmediato —ya sea por dependencias de aplicaciones, integraciones de terceros o por la complejidad de la migración—, el servicio «Endless Lifecycle Support» de TuxCare para PostgreSQL 13 garantiza que esas implementaciones sigan recibiendo parches de seguridad mientras se planifica una migración adecuada. Se trata de una postura significativamente diferente a la de seguir utilizando el sistema sin parches y esperar que no surja ningún problema crítico antes de estar preparados.

El argumento práctico a favor de ELS es muy claro: una actualización urgente a una nueva versión principal, bajo la presión de un CVE crítico, es precisamente el tipo de situación que provoca interrupciones del servicio. ELS te da tiempo para llevar a cabo la migración correctamente.

Herramienta n.º 2: pgAudit

pgAudit es la extensión de referencia para el registro de auditoría con nivel de cumplimiento normativo en PostgreSQL. Genera entradas de registro estructuradas que se ajustan perfectamente a lo que los auditores de SOC 2, HIPAA y PCI DSS esperan encontrar. La configuración es sencilla, pero el volumen de registros puede aumentar rápidamente; por lo tanto, es recomendable planificar el almacenamiento y el envío a un SIEM en lugar de dejar que los registros se acumulen localmente.

Es gratuito, está bien mantenido y se utiliza ampliamente. La contrapartida es que solo registra los registros, nada más. Seguirás necesitando un sistema independiente para analizar realmente los registros y alertar ante anomalías. Combínalo con cualquier sistema SIEM que tu equipo de seguridad ya utilice.

Herramienta n.º 3: pg_stat_statements + exportadores de Prometheus

Aunque no sea una herramienta de seguridad propiamente dicha, pg_stat_statements, junto con un exportador de Prometheus (como postgres_exporter), te proporciona la visibilidad a nivel de consulta necesaria para detectar patrones de uso indebido. Los picos repentinos en las sentencias COPY, las consultas a los catálogos del sistema realizadas desde roles de aplicación o un número inusual de conexiones procedentes de nuevas direcciones IP son señales que merecen una alerta.

Es la versión económica de una solución de supervisión de la actividad de las bases de datos. No está tan bien acabada como una herramienta DAM específica, pero es gratuita, ligera y suficiente para la mayoría de los equipos que no pueden permitirse los precios de las soluciones empresariales.

Herramienta n.º 4: Escáneres de vulnerabilidades

En entornos en los que PostgreSQL se ejecuta en servidores Linux bajo tu control, los escáneres de vulnerabilidades detectan CVE conocidos en tus binarios de PostgreSQL y en sus dependencias. La mayoría de los escáneres te indican qué es lo que presenta vulnerabilidades, pero tienen dificultades para validar las correcciones: marcan un CVE como abierto incluso después de que se haya solucionado mediante un backport, lo que genera ruido y merma la confianza en los resultados.

Refuerza la seguridad de PostgreSQL con TuxCare

La seguridad de PostgreSQL no es un proyecto con una fecha de finalización, sino una disciplina operativa continua. Las vulnerabilidades CVE no dejan de aparecer, las configuraciones se desvían, los roles acumulan permisos que no deberían tener y las fechas límite de fin de vida útil (EOL) llegan, estés preparado para ellas o no. Los equipos que se mantienen a la vanguardia no están haciendo nada heroico. Han creado sistemas que hacen que el trabajo rutinario de seguridad sea visible, repetible y difícil de pasar por alto, de modo que la próxima CVE o fecha de fin de vida útil (EOL) es una tarea programada, no una situación de emergencia.

Para los equipos que utilicen PostgreSQL 13 más allá de su fin de vida útil (EOL), previsto para noviembre de 2025, el servicio «Endless Lifecycle Support» de TuxCare garantiza el suministro continuo de parches de seguridad mientras se planifica la migración en un plazo realista, y no en una situación de crisis provocada por la próxima vulnerabilidad crítica (CVE).

Preguntas frecuentes