Prácticas recomendadas de seguridad

La seguridad de PostgreSQL en producción es un conjunto de reglas de red, TLS, SCRAM, roles de mínimo privilegio y evidencia de auditoría. Estas reglas se aplican tanto en RDS, como en Patroni autoalojado y en bases de datos Postgres sin servidor.

Cómo usar esta lista

• Valida antes del lanzamiento a producción y después de cualquier incidente de credenciales o acceso a datos.
• Combina con Conceptos básicos de seguridad para el contexto del modelo de amenazas.
• Considera las contraseñas de superusuario compartidas como un fallo automático en la revisión.

A - Red y Transporte

• El puerto 5432 no es público en Internet. Los grupos de seguridad / cortafuegos solo permiten subredes de aplicaciones.
• hostssl para roles remotos en pg_hba. Rechaza hostnossl desde las CIDR de la aplicación.
• Los clientes usan sslmode=verify-full con la CA del proveedor. No solo require en producción.
• Se considera TLS de este a oeste cuando el modelo de amenazas de la VPC incluye movimiento lateral.
• Bastión o VPN para acceso de administración humano. No hay psql directo en producción desde portátiles sin un host de salto.

B - Autenticación y Roles

• SCRAM-SHA-256 para roles de contraseña. Vuelve a hashear los verificadores md5 restantes.
• Ningún superusuario en tiempo de ejecución de la aplicación. Los administradores de "break-glass" son personas nombradas.
• Un rol por servicio / unidad de despliegue. Ningún usuario app compartido entre 12 microservicios.
• REVOKE ALL ON DATABASE ... FROM PUBLIC en bases de datos nuevas. Las concesiones predeterminadas no son seguras.
• Rol de migración solo para DDL en CI. Los roles de tiempo de ejecución no pueden CREATE ni DROP.
• Rotación de contraseñas al dar de baja y trimestralmente para cumplimiento. Secretos generados por Vault.

C - Autorización y Datos

• RLS habilitado para esquemas compartidos multiinquilino. Políticas probadas con casos negativos.
• search_path fijo por rol. Previene el secuestro de objetos.
• Extensiones solo de una lista de permitidos. No se permite CREATE EXTENSION no confiable en producción.
• Tablas de PII con columnas minimizadas. Los analistas obtienen vistas sin campos sensibles.
• Inyección SQL prevenida solo mediante consultas parametrizadas. No concatenación de cadenas en "escape hatches" de ORM.

D - Auditoría y Cumplimiento

• Conexión y desconexión registradas. Retención centralizada de 90 días como mínimo.
• DDL registrado (log_statement = ddl o pgaudit). La deriva del esquema es relevante para la seguridad.
• pgaudit o equivalente en datos regulados. Alcance ajustado para evitar inundaciones de registros.
• Simulacro forense trimestral. "Quién leyó la tabla X el mes pasado" respondido con evidencia.
• Cifrado en reposo verificado en el código de infraestructura. RDS creado cifrado; instantáneas con respaldo de KMS.

E - Operaciones

• Parches aplicados dentro del SLA del proveedor. Existe un manual de respuesta a CVE.
• Copias de seguridad cifradas y restauración probada. Un volcado robado es inútil sin claves.
• Secretos no en git ni en capas de contenedor. Secretos de K8s/SSM con rotación.
• Las credenciales de staging no pueden alcanzar producción. Clústeres y límites de IAM separados.
• El manual de incidentes incluye pasos de revocación de credenciales. Preescrito, no inventado durante una SEV.

Preguntas frecuentes

Relacionado

• Conceptos básicos de seguridad - modelo de amenazas
• Configuración SSL/TLS - configuración de TLS
• Autenticación SCRAM - autenticación de contraseña
• pgaudit y registro de cumplimiento - alcance de la auditoría
• Cifrado en reposo - cifrado de disco

Versiones de la pila: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x y PostGIS 3.5+.