El Plano de Refuerzo de Seguridad
La seguridad de PostgreSQL no es un control que se activa, es una pila de capas que asumen que la capa inferior puede ser eludida.
Esta página construye el modelo mental que une esas capas: identidad, autorización, transporte, almacenamiento y auditoría, y explica por qué el refuerzo en producción significa razonar sobre las cinco a la vez en lugar de elegir una favorita.
Resumen
- El refuerzo de seguridad es la práctica de apilar controles independientes (identidad, autorización, transporte, almacenamiento, auditoría) de modo que ningún fallo único exponga datos.
- Por Qué Importa: Una única capa mal configurada, como una línea
trustenpg_hba.confo una contraseña compartida de superusuario, puede deshacer todos los demás controles del clúster. - Conceptos Clave: autenticación, autorización, cifrado de transporte, cifrado en reposo, defensa en profundidad, rastro de auditoría.
- Cuándo Usar: Cualquier base de datos accesible desde Internet, cualquier sistema que contenga datos regulados (PCI, HIPAA, SOC2), y cualquier esquema multi-inquilino compartido entre clientes.
- Limitaciones / Compensaciones: Cada capa añadida cuesta complejidad operativa, latencia o fricción para el desarrollador, por lo que el refuerzo es un presupuesto para gastar deliberadamente, no una lista de verificación para completar ciegamente.
- Temas Relacionados: protocolos de autenticación, seguridad a nivel de fila, registro de cumplimiento, gestión de claves de cifrado.
Fundamentos
Un modelo de amenazas es simplemente una lista honesta de quién puede acceder a tu base de datos y qué podría hacer si lo hiciera.
Para PostgreSQL, esa lista suele tener cuatro entradas: un atacante en la red, una credencial filtrada o adivinada, un intermediario malicioso o descuidado, y un disco o instantánea de copia de seguridad robada.
Cada entrada de esa lista se mapea a un control diferente, que es la idea central detrás de la defensa en profundidad.
La autenticación responde a "¿quién eres?", y el mecanismo predeterminado de PostgreSQL es SCRAM-SHA-256, un protocolo de desafío-respuesta que nunca envía la contraseña en sí a través del cable.
La autorización responde a "¿qué tienes permitido tocar?", y se aplica a través de GRANT/REVOKE sobre objetos más políticas opcionales de seguridad a nivel de fila para un aislamiento de inquilino más granular.
El cifrado de transporte (TLS) responde a una pregunta completamente diferente: incluso si la identidad y los permisos son correctos, ¿puede alguien en la red leer o manipular los bytes en tránsito?
El cifrado en reposo protege los datos cuando los controles de tiempo de ejecución son irrelevantes, como cuando una instantánea de disco o una unidad dada de baja termina en las manos equivocadas.
La analogía útil es un edificio: la autenticación es la tarjeta de identificación en la puerta, la autorización es a qué pisos desbloquea esa tarjeta, TLS es un camión de reparto cerrado entre edificios, y el cifrado en reposo es la caja fuerte atornillada al suelo en el interior.
Ninguno de estos sustituye a otro, y un edificio con una gran caja fuerte pero una puerta principal sin cerrar no es seguro.
PostgreSQL se envía sin ninguna de estas capas configuradas agresivamente de fábrica, porque la instalación predeterminada está optimizada para el portátil de un desarrollador, no para un clúster de producción expuesto públicamente.
Esa brecha entre "se instala limpiamente" y "es seguro exponerlo" es exactamente lo que un plano de refuerzo existe para cerrar.
Mecánica e Interacciones
Las capas interactúan en un orden específico cada vez que un cliente se conecta, y comprender ese orden explica la mayoría de las decisiones de refuerzo.
Una conexión primero cruza la capa de red, donde las reglas del firewall, los grupos de seguridad y las entradas de pg_hba.conf deciden si el intento se considera siquiera.
Si la entrada requiere hostssl, la negociación TLS ocurre a continuación, estableciendo un canal cifrado antes de que se intercambie cualquier credencial.
Solo entonces se ejecuta la autenticación, donde SCRAM valida la prueba del cliente contra el verificador salado almacenado en pg_authid, nunca la contraseña en texto plano.
Una vez que la sesión se establece, cada declaración pasa por la capa de autorización, donde PostgreSQL verifica los privilegios de los objetos y, si están habilitados, evalúa las políticas de seguridad a nivel de fila contra current_user.
El registro de auditoría se sienta junto a todo este flujo como un observador pasivo, registrando conexiones, desconexiones y (dependiendo de la configuración) el texto de las declaraciones para una revisión forense posterior.
Este orden importa porque una debilidad anterior en la cadena socava todo lo posterior: una entrada trust en pg_hba.conf omite completamente la autenticación, haciendo que las concesiones a nivel de rol sean irrelevantes para cualquiera en esa ruta de red.
-- Un mecanismo hecho concreto: el orden de las líneas de pg_hba.conf decide
-- qué método de autenticación se ejecuta realmente para un intento de conexión dado.
-- La primera línea coincidente gana, las líneas posteriores nunca se evalúan.
hostssl orders app_api 10.20.0.0/16 scram-sha-256
hostnossl orders app_api 0.0.0.0/0 rejectEl fragmento anterior muestra por qué el orden de las capas es una decisión de seguridad en sí misma: la primera línea exige TLS y SCRAM para la subred de confianza, y la segunda línea rechaza explícitamente cualquier intento no TLS desde cualquier otro lugar, cerrando la brecha que una regla faltante dejaría abierta.
Un error de razonamiento común es tratar estas capas como redundantes en lugar de complementarias, asumiendo que debido a que los roles están bloqueados, TLS es opcional.
En realidad, cada capa defiende contra una capacidad de atacante diferente, y omitir una solo reduce el conjunto de ataques contra los que estás protegido en lugar de hacer que las otras sean innecesarias.
Consideraciones Avanzadas y Aplicaciones
A escala, el plano se extiende más allá de una sola base de datos a cómo se centraliza la identidad y cómo se rotan los secretos en una flota.
Las empresas delegan cada vez más la autenticación a LDAP, Kerberos o tokens de IAM en la nube en lugar de contraseñas SCRAM estáticas, de modo que un único proveedor de identidad gobierne el acceso a través de todos los servicios, no solo Postgres.
La seguridad a nivel de fila se vuelve fundamental en arquitecturas multi-inquilino, donde un único esquema compartido sirve a muchos clientes y la base de datos misma, no solo la aplicación, debe garantizar el aislamiento del inquilino.
Los marcos de cumplimiento como SOC2, HIPAA y PCI DSS no introducen nuevos controles técnicos, sino que formalizan qué de estas capas deben existir y cómo su evidencia (registros, revisiones de concesiones, atestaciones de cifrado) se retiene y audita.
La observabilidad de la capa de seguridad importa tanto como los propios controles, porque un sistema perfectamente configurado pero no monitoreado no puede decirte cuándo se eludió un control o se usó incorrectamente una credencial.
La gobernanza de extensiones es una superficie de refuerzo a menudo pasada por alto: CREATE EXTENSION puede otorgar una capacidad significativa, por lo que los clústeres de producción típicamente la limitan detrás de una lista blanca y un rol de migración privilegiado en lugar de dejarla abierta a los roles de la aplicación.
| Enfoque | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Contraseñas SCRAM estáticas | Simple, sin dependencia externa | Rotación manual, proliferación de credenciales | Equipos pequeños, cuentas de servicio |
| Autenticación por certificado (mTLS) | Identidad fuerte por servicio | Se requiere herramienta de rotación y revocación | Topologías de malla de servicios fijas |
| Autenticación de token de IAM en la nube | De corta duración, revocable centralmente | Vinculado a un proveedor de nube | Postgres administrado nativo de AWS/GCP |
| Seguridad a nivel de fila | Aplica aislamiento de inquilinos en la propia BD | Complejidad de planificación de consultas y políticas | SaaS multi-inquilino de esquema compartido |
| Registro de declaraciones pgaudit | Rastro de evidencia a nivel de declaración completo | Volumen de registro y riesgo de exposición de PII | Datos regulados, auditorías de cumplimiento |
Conceptos Erróneos Comunes
- "TLS significa que la base de datos es segura." - TLS solo protege los datos en tránsito; no dice nada sobre quién puede autenticarse o qué pueden tocar una vez conectados.
- "La seguridad a nivel de fila reemplaza la autorización de la aplicación." - RLS es una segunda línea de defensa para un rol de base de datos compartido, no un sustituto de las comprobaciones de reglas de negocio de la propia aplicación.
- "Superusuario es solo una cuenta de conveniencia." - superusuario omite RLS y la mayoría de las comprobaciones de privilegios, por lo que usarlo como credencial de aplicación colapsa todas las demás capas de este plano.
- "Postgres administrado se encarga de la seguridad por mí." - el proveedor asegura el hipervisor y el sustrato de almacenamiento, pero los roles, las concesiones, las políticas de RLS y la exposición a nivel de consulta siguen siendo completamente responsabilidad del cliente.
- "La certificación de cumplimiento significa que el esquema está reforzado." - un informe SOC2 atestigua procesos y controles en un momento dado, no que cada tabla tenga las concesiones correctas hoy.
- "El cifrado en reposo detiene las amenazas internas." - el cifrado en reposo protege contra medios robados, no contra un intermediario autenticado con acceso de consulta legítimo.
Preguntas Frecuentes
¿Cuál es el paso de refuerzo de mayor impacto para un nuevo clúster de PostgreSQL?
Reemplazar cualquier entrada trust o no autenticada de pg_hba.conf con hostssl más scram-sha-256 cierra la exposición más común en el mundo real.
¿Habilitar SSL/TLS por sí solo hace que una base de datos esté lista para producción?
No, TLS solo asegura la ruta de red; la autenticación, la autorización y el registro de auditoría aún deben configurarse de forma independiente.
¿Por qué PostgreSQL se envía con valores predeterminados más débiles que una configuración de producción reforzada?
La instalación predeterminada se dirige a la ergonomía del desarrollo local, no a la exposición en Internet, por lo que el refuerzo se trata como una responsabilidad en el momento de la implementación.
¿Cómo difieren realmente la autenticación y la autorización en PostgreSQL?
La autenticación (SCRAM, certificados, LDAP) prueba la identidad en el momento de la conexión; la autorización (GRANT, REVOKE, RLS) decide qué puede hacer esa identidad en cada declaración posterior.
¿Es necesaria la seguridad a nivel de fila para todas las aplicaciones multi-inquilino?
Solo cuando los inquilinos comparten un único esquema o rol; bases de datos o esquemas completamente aislados por inquilino pueden depender de la separación a nivel de concesión en su lugar.
¿Debería la aplicación conectarse alguna vez con un rol de superusuario?
No, los entornos de ejecución de aplicaciones deben usar un rol de mínimo privilegio, reservando el superusuario para administración de emergencia y gestión de extensiones.
¿Cuál es la compensación entre el registro de auditoría a nivel de declaración y el rendimiento?
El registro amplio de declaraciones (a través de pgaudit o log_statement = all) agrega E/S y puede filtrar literales sensibles en los registros, por lo que la mayoría de los equipos lo limitan a DDL y tablas sensibles específicas.
¿Cómo encaja el cifrado en reposo en este plano si la base de datos ya está controlada por acceso?
Defiende un escenario que ninguno de los controles de tiempo de ejecución cubre: un disco robado, una instantánea de volumen o un medio de copia de seguridad dado de baja.
¿Los proveedores de nube administrados eliminan la necesidad de este plano?
Eliminan el trabajo a nivel de infraestructura (parcheo, sustrato de cifrado de disco) pero dejan los roles, las concesiones, RLS y la exposición a nivel de consulta completamente al cliente.
¿Qué es un concepto erróneo común sobre los marcos de cumplimiento como SOC2 o HIPAA?
Los equipos a menudo tratan la certificación como prueba de que el esquema está reforzado hoy, cuando en realidad atestigua procesos y controles observados durante una ventana de auditoría.
¿Por qué el orden de las líneas de `pg_hba.conf` se considera una decisión de seguridad?
PostgreSQL utiliza la primera línea coincidente para un intento de conexión, por lo que una regla laxa colocada antes de una estricta la anula silenciosamente.
¿Cómo deben gobernarse las extensiones desde una perspectiva de refuerzo?
Restringir CREATE EXTENSION a un rol de migración privilegiado y una lista blanca explícita, ya que las extensiones pueden introducir nueva superficie de ataque o capacidad.
Relacionado
- Conceptos Básicos de Seguridad - el punto de partida a nivel de receta para roles, concesiones y reglas de pg_hba.
- Autenticación SCRAM - una mirada más profunda a la capa de autenticación descrita aquí.
- Configuración SSL/TLS - la capa de cifrado de transporte en la práctica.
- pgaudit y Registro de Cumplimiento - la capa de auditoría para cargas de trabajo reguladas.
- Cifrado en Reposo - el control de la capa de almacenamiento para escenarios de medios robados.
- Descripción General de PostgreSQL Administrado - cómo cambia este plano en una plataforma administrada.
Versiones de la pila: Esta página fue escrita para PostgreSQL 18.4 (versión principal estable 18, línea de mantenimiento 17), PgBouncer 1.x y Patroni 3.x.