1a.

1 — Instalación segura de PostgreSQL en Ubuntu

Se realizó la instalación del motor PostgreSQL en un entorno Ubuntu asegurando las

buenas prácticas básicas antes de su puesta en marcha.
En primer lugar, se actualizó el sistema y se incorporó el repositorio oficial de
PostgreSQL (PGDG) para garantizar versiones mantenidas y parches de seguridad
recientes. Luego se instaló el paquete del servidor mediante apt.

Una vez instalado, se verificó el clúster creado con:

pg_lsclusters

Posteriormente, se fortaleció la seguridad de autenticación configurando el modo de

almacenamiento de contraseñas a scram-sha-256 en postgresql.conf, y se modificó el
archivo pg_hba.conf para exigir mecanismos de autenticación seguros tanto para
accesos locales como por red. Se reinició el servicio para aplicar los cambios.

Finalmente, se accedió con el rol administrador y se establecieron contraseñas

robustas para los roles de administración, creando además un rol dedicado a la
aplicación y su base de datos asociada.

Este conjunto de acciones asegura una instalación inicial endurecida, con

autenticación robusta desde el primer uso del servicio.
1a.2 autenticación con certificado

Luego de completar la instalación, se procedió a habilitar la capa de cifrado TLS para

proteger las conexiones entre clientes y servidor.
Para ello, se generó una Autoridad Certificadora (CA) local y se firmó un certificado de
servidor (CN=localhost) con dicha CA.
Los archivos resultantes fueron ubicados en /etc/postgresql/16/main/ssl/ con los
permisos mínimos requeridos por PostgreSQL (clave privada solo legible por el usuario
postgres).

Posteriormente, se editaron los parámetros de seguridad en postgresql.conf,

estableciendo:

ssl = on

ssl_cert_file = 'ssl/server.crt'

ssl_key_file = 'ssl/server.key'

ssl_ca_file = 'ssl/ca.crt'

Tras reiniciar el servicio, se verificó mediante consultas SQL que el motor está
utilizando el certificado configurado y que cifrado TLS está activo en las conexiones:

SHOW ssl;
SHOW ssl_cert_file;

SHOW ssl_ca_file;

Finalmente, se realizó una conexión desde el cliente utilizando sslmode=verify-full, lo

que garantiza autenticación del servidor por certificado y canal cifrado End-to-End:

psql "host=localhost dbname=app_db user=app_user sslmode=verify-full" \

-c "SELECT current_user, ssl_is_used();"

El resultado confirmó que la conexión al servidor PostgreSQL se estableció

correctamente bajo un canal TLS cifrado.

Muestra:
1a.3 — Autenticación basada en roles y principio de mínimo privilegio en
PostgreSQL

En PostgreSQL la seguridad se implementa con roles (equivalentes a usuarios y/o

grupos).
La buena práctica es separar:

• Roles de inicio de sesión (LOGIN): representan personas o cuentas de

servicio.

• Roles-grupo (NOLOGIN): agrupan permisos (“lectores”, “escritores”,

“propietarios”) y evitan asignar privilegios directamente a cada usuario.

Para aplicar mínimo privilegio:

1. Separar propiedad del objeto del uso diario: un rol propietario (NOLOGIN)
mantiene la titularidad del esquema y objetos; los usuarios cotidianos no son
dueños.

2. Esquema por aplicación y control granular: USAGE sobre el esquema;

SELECT/INSERT/UPDATE/DELETE según el caso.

3. Privilegios por defecto (objetos futuros): ALTER DEFAULT PRIVILEGES para

que toda tabla/vista/función nueva herede automáticamente los permisos
adecuados.

4. Asignación vía grupos: a los usuarios solo se les da membresía en los roles-
grupo necesarios.

5. Revocaciones explícitas y herencia controlada (INHERIT/NOINHERIT) para

limitar el alcance.

6. (Opcional) RLS: si se requiere, activar Row-Level Security para filtrar filas por
usuario/rol.

Con este enfoque, cada usuario obtiene solo los permisos imprescindibles para su
tarea y la administración se simplifica al gestionar permisos en roles-grupo.
Finalmente, se validó el modelo conectando con el usuario alice (perteneciente a
app_readers), comprobando que podía consultar datos (SELECT) pero no insertar
(INSERT produce permission denied). Esto demuestra que las restricciones se aplican
correctamente.

Muestra:
1a.4 — Cifrado de datos en tránsito en PostgreSQL y diferencias entre SGBD

El cifrado “en tránsito” protege la comunicación cliente-servidor mediante TLS.

En PostgreSQL se habilita con ssl = on y certificados X.509 (al menos certificado de

servidor; opcionalmente también cliente para mTLS). La verificación del certificado por
parte del cliente se controla con sslmode:

disable (sin TLS)

allow / prefer (opcional)

require (cifra, no verifica identidad)

verify-ca (verifica que el emisor sea la CA confiable)

verify-full (además verifica el nombre del servidor contra el SAN/CN)

Parámetros relevantes del lado servidor:

ssl = on, ssl_cert_file, ssl_key_file, ssl_ca_file

ssl_min_protocol_version (recom.: TLSv1.2 o TLSv1.3)

ssl_ciphers / ssl_ecdh_curve (selección de suites y curvas)

Reglas en pg_hba.conf con hostssl (y clientcert=verify-full si se implementa mTLS)

En el cliente, además de sslmode, se puede usar sslrootcert (CA), sslcert/sslkey

(cert/clave del cliente para mTLS).

Diferencias entre SGBD (niveles y control de cifrado en tránsito)

PostgreSQL: TLS 1.2/1.3 vía OpenSSL; modos sslmode graduados (desde “require”
hasta “verify-full”); admite mTLS con clientcert=verify-full en pg_hba.conf. Control fino
de protocolo mínimo y suites.
MySQL/MariaDB: TLS 1.2/1.3; política de cliente con --ssl-
mode={PREFERRED,REQUIRED,VERIFY_CA,VERIFY_IDENTITY} (análogos a
require/verify-ca/verify-full). Soporta mTLS.

SQL Server: TLS (TDS sobre TLS). Opción Force Encryption en el servidor; validación
por CA del certificado del servidor; admite certificados de cliente (mTLS) en escenarios
avanzados/AD.

Oracle: TLS mediante TCPS (SSL/TLS) y, además, Native Network Encryption (NNE) a
nivel propio (no TLS). TCPS permite validación de identidad y mTLS; NNE cifra sin
certificados X.509.

En todos los casos se recomienda: deshabilitar protocolos obsoletos, exigir verificación

de identidad del servidor, y usar certificados emitidos por una CA confiable (interna o
pública). Cuando se requiere autenticación fuerte de clientes, habilitar mTLS.

Muestra:

1a.5 — Cifrado de datos en reposo en PostgreSQL

PostgreSQL no cifra automáticamente los datos en reposo, sino que ofrece dos
mecanismos principales:

1. Cifrado a nivel de tablas/datos mediante la extensión pgcrypto

Permite cifrar columnas específicas utilizando funciones como
pgp_sym_encrypt() y pgp_sym_decrypt().
Este enfoque aplica el principio de “cifrado granular”, protegiendo solo los datos
sensibles dentro de la base.

2. Cifrado completo a nivel de disco o tablespace (TDE vía sistema operativo o

capa externa)
PostgreSQL no trae TDE nativo (Transparent Data Encryption), pero
recomienda usar:

o LUKS/dm-crypt (Linux)

o BitLocker (Windows)

o cifrado en storage del proveedor cloud (EBS, GCE Persistent Disks,

Azure Disk Encryption)

¿Cómo se habilita el cifrado nativo a nivel de tablas con pgcrypto?

1. Activando la extensión:

CREATE EXTENSION IF NOT EXISTS pgcrypto;

 2. Cifrando antes de insertar:

INSERT INTO secrets(nombre_enc)

VALUES (pgp_sym_encrypt('Juan Perez','clave-demo-123!'));

3. Desencriptando al consultar:

SELECT pgp_sym_decrypt(nombre_enc,'clave-demo-123!')::text

FROM secrets;

Diferencia frente a otros SGBD

• SQL Server soporta TDE nativo (cifra toda la base automáticamente).

• Oracle también incluye TDE integrado desde hace años.

• PostgreSQL privilegia el cifrado granular (pgcrypto) y delega el TDE al sistema

operativo o storage.

Esto hace que PostgreSQL sea más flexible, pero requiere decisiones explícitas sobre
qué cifrar, dónde y con qué clave, en lugar de aplicar cifrado global por defecto.

Muestra:

1a.6 Auditoría en PostgreSQL

PostgreSQL permite auditar la actividad de los usuarios mediante dos enfoques

principales:

Auditoría nativa por logs (log_statement, log_connections, etc.)

Auditoría avanzada con la extensión pgaudit (recomendada para entornos de

seguridad).

1) Auditoría básica nativa (logging en postgresql.conf)

PostgreSQL puede registrar:

Conexiones y desconexiones de usuarios (log_connections, log_disconnections)

Sentencias SQL ejecutadas (log_statement)

Errores, fallos de autenticación y eventos sospechosos

Estos eventos quedan registrados en /var/log/postgresql/...log y permiten detectar
intentos fallidos, consultas no autorizadas o comportamientos anómalos.

2) Auditoría avanzada con pgaudit

pgaudit extiende el logging estándar y permite registrar con granularidad:

Consultas que acceden a datos (SELECT)

Modificaciones (INSERT/UPDATE/DELETE/TRUNCATE)

Cambios de roles, permisos y configuración (DDL y SECURITY)

Una vez habilitado, pgaudit registra en el log del servidor los comandos ejecutados por
cada usuario, lo que permite reconstruir acciones y responder ante incidentes.

Uso de los logs para detección de incidentes

Los registros generados pueden integrarse con herramientas SIEM o revisarse

manualmente para:

Detectar accesos fuera de horario, IPs no autorizadas o patrones anómalos

Identificar intentos de intrusión (repetidos fallos de login)

Trazar exactamente qué usuario realizó una consulta o alteró datos sensibles

Soportar análisis forense post-incidente.

Muestra:
1a.7 Restricción de conexiones en PostgreSQL a una lista específica de
direcciones IP

Para restringir PostgreSQL a aceptar conexiones solo desde ciertas IP, se utiliza el
archivo de control de acceso pg_hba.conf, que define qué clientes pueden
autenticarse y con qué método.

Para permitir únicamente un conjunto específico de IPs y bloquear todas las demás, se
agregan reglas explícitas como:

host all all 10.10.10.5/32 scram-sha-256

host all all 192.168.1.0/24 scram-sha-256

host all all 0.0.0.0/0 reject

Luego se recarga la configuración:

sudo pg_ctlcluster 16 main reload

Con esto, PostgreSQL solo acepta conexiones desde las direcciones IP autorizadas.

Cualquier otra IP queda rechazada sin acceder al servicio, cumpliendo el principio de

mínima exposición a la red.

Muestra:

1a.8 — Uso seguro de la extensión pgcrypto para cifrar y descifrar datos en

PostgreSQL

PostgreSQL permite cifrar datos sensibles a nivel de columna mediante la extensión

pgcrypto. Para utilizarla de forma segura se debe, en primer lugar, habilitar la
extensión en la base de datos donde se almacenarán los datos sensibles (CREATE
EXTENSION pgcrypto;). A partir de ese momento se dispone de funciones como
pgp_sym_encrypt() y pgp_sym_decrypt() para cifrado simétrico, y pgp_pub_encrypt() /
pgp_pub_decrypt() para cifrado asimétrico basado en claves públicas y privadas.
Para garantizar un uso seguro, la clave de cifrado no debe almacenarse en la propia
tabla ni en texto plano dentro del código, sino gestionarse mediante variables de
entorno, vaults o configuraciones protegidas del servidor. El cifrado se realiza antes del
almacenamiento, de modo que los datos quedan en disco en formato cifrado, y solo
son revertidos a texto plano al momento de consulta bajo autorización controlada.

El uso de pgcrypto no modifica el motor ni requiere cambios estructurales, lo que lo

convierte en una solución eficaz para proteger columnas sensibles como DNI, tarjetas,
emails o contraseñas. Al combinarlo con control de roles, auditoría y TLS en tránsito,
se obtiene una protección de datos de extremo a extremo dentro de PostgreSQL.

Muestra:
1a.9 — Configuración de políticas de backup automáticas y seguras en
PostgreSQL para garantizar recuperación ante incidentes

Para asegurar la disponibilidad de la información ante incidentes como ataques, fallos

de sistema o corrupción lógica, PostgreSQL permite implementar políticas de respaldo
seguras combinando backups completos periódicos y archivado continuo de WAL para
lograr recuperación a un punto en el tiempo (PITR).

La estrategia recomendada consiste en:

Habilitar archive_mode y archive_command, lo que permite almacenar los WAL fuera

del clúster activo para poder reconstruir el estado exacto de la base a cualquier
momento previo al incidente.

Programar backups completos con pg_basebackup o herramientas especializadas

como pgBackRest o Barman, que permiten realizar backups incrementales,
verificación de integridad y retención rotativa.

Aplicar buenas prácticas de seguridad, como:

Cifrado del canal y del repositorio de backup

Separar físicamente destino de backups (otro host o almacenamiento externo)

Verificación periódica de restauración

Políticas de retención ajustadas al riesgo y normativa

Con esta combinación (backup completo + WAL + retención + práctica de

restauración), es posible garantizar una recuperación controlada y segura ante
pérdidas totales o parciales del servicio, cumpliendo con requisitos de continuidad y
resiliencia ante ataques.

Muestra: