Bloque 2 — TLS/SSL: cifrado en tránsito

Por qué TLS es obligatorio

Sin TLS, la contraseña de tu usuario viaja en texto plano por la red. Un atacante con `tcpdump` o Wireshark en el mismo segmento de red la captura en segundos.

# Captura sin TLS (peligro)
sudo tcpdump -i any -A port 3306 | grep -i password
En 30 segundos ves la contraseña en texto plano

Configurar TLS en MySQL

Generar o obtener certificados:

# Opción 1: Certificados autofirmados (para desarrollo)
openssl req -newkey rsa:2048 -nodes -keyout ca.key -x509 -days 3650 -out ca.pem
openssl req -newkey rsa:2048 -nodes -keyout server.key -out server.csr
openssl x509 -req -in server.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out server.pem -days 3650

Opción 2: certificados de Let's Encrypt (gratis) o de una CA interna (producción).

Configurar MySQL (`my.cnf`):

[mysqld]
ssl_ca   = /etc/mysql/ssl/ca.pem
ssl_cert = /etc/mysql/ssl/server.pem
ssl_key  = /etc/mysql/ssl/server.key
require_secure_transport = ON

`require_secure_transport = ON` rechaza cualquier conexión no TLS.

Forzar TLS para un usuario específico:

ALTER USER 'app_tienda'@'localhost' REQUIRE SSL;

Verificar desde el cliente:

mysql -u app_tienda -p --ssl-mode=REQUIRED -h localhost
mysql> SHOW STATUS LIKE 'Ssl_cipher';
-- Esperado: una cifra como TLS_AES_256_GCM_SHA384

Configurar TLS en PostgreSQL

`postgresql.conf`:

ssl = on
ssl_cert_file = '/etc/postgresql/ssl/server.crt'
ssl_key_file = '/etc/postgresql/ssl/server.key'
ssl_ca_file = '/etc/postgresql/ssl/ca.crt'

`pg_hba.conf` (cambiar método):

hostssl  tienda_tlalli  all  0.0.0.0/0  scram-sha-256
hostssl fuerza TLS para esta regla

Verificar:

psql "host=localhost dbname=tienda_tlalli user=app_tienda sslmode=require"
postgres=# SHOW ssl;
-- Esperado: on

Bloque 3 — Cifrado en reposo

Cifrado en reposo protege los datos si el disco es robado, el servidor es decomisado, o el backup se filtra.

Opciones por motor

| Motor | Cifrado nativo | Cifrado a nivel OS | Cifrado en cloud | |---|---|---|---| | MySQL 8 Community | No (TDE es Enterprise) | LUKS, BitLocker, eCryptfs | AWS RDS encryption, Azure TDE | | MySQL 8 Enterprise | TDE (tablespace) | LUKS, BitLocker | Igual | | MariaDB | Tablespace encryption (open source) | LUKS, BitLocker | Igual | | PostgreSQL | pgcrypto (datos específicos), TDE en forks | LUKS, BitLocker | AWS RDS encryption, Azure TDE |

Cifrado a nivel OS con LUKS (Linux)

# Verificar si la partición está cifrada
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE
Si TYPE dice "crypt", está cifrada
Crear volumen cifrado (ejemplo con /dev/sdb)
sudo cryptsetup luksFormat /dev/sdb
sudo cryptsetup open /dev/sdb data_crypt
sudo mkfs.ext4 /dev/mapper/data_crypt
sudo mount /dev/mapper/data_crypt /var/lib/mysql

Cifrado de columnas específicas con pgcrypto (PostgreSQL)

-- Instalar extensión
CREATE EXTENSION IF NOT EXISTS pgcrypto;
-- Crear tabla con columna cifrada
CREATE TABLE clientes_seguros (
  cliente_id SERIAL PRIMARY KEY,
  nombre TEXT,
  email BYTEA,  -- Cifrado
  telefono BYTEA
);
-- Insertar con cifrado
INSERT INTO clientes_seguros (nombre, email, telefono) VALUES
  ('Xochitl Hernández Ruiz',
   pgp_sym_encrypt('xochitl@example.com', 'ClaveMaestra_2026!'),
   pgp_sym_encrypt('+52 55 1234 5678', 'ClaveMaestra_2026!'));
-- Leer descifrando
SELECT nombre, pgp_sym_decrypt(email, 'ClaveMaestra_2026!') AS email
FROM clientes_seguros;

Trade-off: el cifrado por columna impide hacer `WHERE email = 'xochitl@example.com'` directamente. Se cifra en la app o se usan técnicas como `pgp_sym_encrypt` con índice sobre un hash determinístico.

Cifrado en AWS RDS

Si tu base está en RDS, activa el cifrado en reposo al crear la instancia:

# Terraform
resource "aws_db_instance" "tienda" {
  identifier     = "tienda-tlalli"
  engine         = "postgres"
  instance_class = "db.t3.micro"
  storage_encrypted = true  # ← Cifrado en reposo
  kms_key_id        = aws_kms_key.tienda.arn
  # ...
}

Bloque 4 — Hardening del servidor: CIS Benchmarks

El CIS (Center for Internet Security) publica benchmarks de configuración segura para MySQL y PostgreSQL. No son obligatorios pero son la línea base que auditan PCI-DSS, ISO 27001 y SOC 2.

CIS MySQL 8.0 Benchmark (resumen de los 30+ controles clave)

1.1 — Backup de configuración:

   sudo cp /etc/mysql/my.cnf /etc/mysql/my.cnf.bak
   sudo chown root:root /etc/mysql/my.cnf.bak
   sudo chmod 600 /etc/mysql/my.cnf.bak
   ```
2.1 — Deshabilitar el uso de `LOCAL INFILE`:
   ```ini
   [mysqld]
   local_infile = 0
   ```
   Previene `LOAD DATA LOCAL INFILE`, vector de exfiltración.
2.2 — Limitar `secure_file_priv` (vacío = cualquier path):
   ```ini
   [mysqld]
   secure_file_priv = /var/lib/mysql-files/
   ```
2.3 — Deshabilitar `skip-grant-tables` (debe estar comentado o en 0):
   ```ini
   # skip-grant-tables
   ```
   Si está activo, cualquiera entra sin contraseña.
3.1 — Eliminar usuarios anónimos:
   ```sql
   DELETE FROM mysql.user WHERE User = '';
   FLUSH PRIVILEGES;
   ```
3.2 — Deshabilitar login remoto como root:
   ```sql
   DELETE FROM mysql.user WHERE User = 'root' AND Host NOT IN ('localhost', '127.0.0.1', '::1');
   FLUSH PRIVILEGES;
   ```
4.1 — Forzar contraseñas con plugin seguro:
   ```ini
   [mysqld]
   default_authentication_plugin = caching_sha2_password
   ```
4.4 — Política de contraseñas (validar longitud y complejidad):
   ```ini
   [mysqld]
   validate_password_policy = STRONG
   validate_password_length = 12
   validate_password_mixed_case_count = 1
   validate_password_number_count = 1
   validate_password_special_char_count = 1
   ```
5.1 — Limitar `max_connections`:
   ```ini
   [mysqld]
   max_connections = 100
   ```
   Previene ataques de agotamiento de conexiones.
6.1 — Habilitar log de errores:
    ```ini
    [mysqld]
    log_error = /var/log/mysql/error.log
    ```
CIS PostgreSQL 16 Benchmark (resumen)
1.1 — Permisos de los archivos de configuración:
   ```bash
   sudo chown postgres:postgres /etc/postgresql/16/main/postgresql.conf
   sudo chmod 600 /etc/postgresql/16/main/postgresql.conf
   ```
1.2 — Permisos del directorio de datos:
   ```bash
   sudo chown postgres:postgres /var/lib/postgresql/16/main
   sudo chmod 700 /var/lib/postgresql/16/main
   ```
3.1 — `listen_addresses` solo en local o red interna:
   ```ini
   listen_addresses = 'localhost'  # o '10.0.0.5'
   ```
4.1 — `log_connections = on`:
   ```ini
   log_connections = on
   log_disconnections = on
   log_statement = 'ddl'
   ```
4.2 — `log_min_duration_statement` (log de queries lentas):
   ```ini
   log_min_duration_statement = 1000  # ms
   ```
6.1 — `password_encryption = scram-sha-256` (Tema 18).

6.2 — `pg_hba.conf` estricto (Tema 18).

Bloque 5 — Respuesta a incidentes
Si te atacan: el protocolo de las 6 horas
Hora 0 — Detección: una alerta salta (log de errores inusual, caída de la base, reporte de usuario).
Hora 0:15 — Contención:
Aislar la base: bloquear IPs sospechosas en el firewall.
Cambiar contraseñas de todos los usuarios con permisos altos.
Si hay ransomware: desconectar de la red, no apagar.
Hacer un snapshot forense del estado actual.

Hora 1 — Evaluación:
¿Qué datos fueron accedidos? Revisar logs de conexión, log de queries.
¿Qué cuentas fueron comprometidas?
¿Hay persistencia? (usuarios nuevos creados, tareas programadas, triggers sospechosos).
¿Hay exfiltración? (logs de red saliente grandes, archivos .sql o .zip subidos a servicios externos).

Hora 3 — Erradicación:
Revocar permisos de cuentas comprometidas.
Eliminar usuarios y backdoors.
Parchar la vulnerabilidad explotada.
Restaurar desde respaldo limpio si hay duda de integridad.

Hora 6 — Recuperación:
Restaurar en entorno limpio.
Monitoreo intensificado las siguientes 72 horas.
Verificación de integridad de los datos.

Post-incidente:
Documentar timeline detallado.
Análisis de causa raíz.
Acciones correctivas: ¿qué control faltaba?
Comunicado a usuarios si hubo filtración de datos (LFPDPPP en México: aviso en 72 horas).

Recursos forenses
MySQL: `general_log` (si estaba activo), `slow_query_log`, `audit_log` (Enterprise), `binlog`.
PostgreSQL: `log_statement`, `pg_stat_statements`, `pgAudit`, `log_min_duration_statement = 0` durante el incidente.

AI Mission
Pídele a tu IA que evalúe la configuración actual de tu base. Prompt sugerido:

Dame:

Lista de 10 hallazgos de seguridad ordenados por severidad. Para cada hallazgo, el cambio exacto en la configuración. ¿Qué pasa si reinicio la base con estos cambios? Riesgos residuales que no se arreglan con configuración.

Revisa cada sugerencia. La IA no conoce tu entorno completo (réplicas, otras apps que dependen de la base, etc.).
Errores típicos
Confiar en `localhost` para "no necesita TLS" → dentro de la misma red, un atacante con ARP spoofing puede interceptar.
`require_secure_transport = ON` solo en producción → en desarrollo se filtra la contraseña y la usan en producción.
TLS con certificados autofirmados sin verificar en el cliente → vulnerable a MITM.
Cifrado en reposo sin cifrado de backups → el backup se filtra aunque el disco esté cifrado.
Hardening solo del motor, no del SO → MySQL seguro sobre un Windows sin updates es inseguro.
Confiar en que el ORM te protege de SQL injection → si concatenas strings en algún lugar del código, sigue siendo vulnerable.

LAB práctico — Aplicar CIS Benchmarks a tienda_tlalli
Objetivo: dejar tu MySQL y PostgreSQL con los 10 controles CIS más críticos aplicados, documentados, y verificados.
Paso 1 — Backup de la configuración