4. Cifrado y protección técnica

Clasificar y enmascarar protege el dato en uso. Pero mientras viaja por la red, o mientras está guardado en disco, necesita otra capa distinta: cifrado.

El cifrado busca proteger la confidencialidad de la información. Puede aplicarse:

durante la comunicación
durante el almacenamiento
en respaldos
en determinados campos
en credenciales, mediante mecanismos especializados

El cifrado es un control, no una estrategia completa de seguridad.

¿Qué es la criptografía?

La criptografía es la disciplina que diseña técnicas matemáticas para proteger información frente a quien no debería tener acceso a ella.

Técnica	Qué logra
Cifrado	Confidencialidad reversible con la clave correcta.
Hash	Integridad y verificación sin guardar el dato original.
Firma digital	Autenticidad e integridad usando un par de llaves.

La codificación (como Base64) no es criptografía: no busca proteger nada, solo cambia la representación del dato — lo vemos más abajo con un ejemplo.

Referencia. Ferguson, Schneier y Kohno, Cryptography Engineering (2010), cap. 1.

Cifrado simétrico y asimétrico

Tipo	Cómo funciona	Dónde lo usa esta unidad
Simétrico	Misma llave para cifrar y descifrar. Rápido.	`pgcrypto` en PostgreSQL.
Asimétrico	Llave pública para cifrar, llave privada para descifrar.	Es la base de TLS.

Referencia. NIST FIPS 197, Advanced Encryption Standard, RFC 8446, TLS 1.3.

Simétrico y asimétrico juntos: cómo funciona HTTPS

Momento	Tipo de cifrado	Qué ocurre
Al conectar	Asimétrico	Navegador y servidor usan llave pública y privada solo para acordar una llave nueva.
Durante la sesión	Simétrico	Esa llave compartida cifra todo el tráfico real, porque es mucho más rápida.

Lo asimétrico es lento pero no necesita compartir un secreto de antemano. Lo simétrico es rápido pero necesita que ambos ya tengan la misma llave. HTTPS usa primero uno y después el otro.

Cómo se ve esto en la práctica: SSH por el puerto 22

$ ssh -i ~/.ssh/id_ed25519 estudiante@servidor.uas.edu.mx -p 22

Nunca se escribió ni se transmitió una contraseña. El servidor solo comprobó que la computadora respondiera al reto con la llave privada que coincide con la pública en authorized_keys.

Referencia. OpenSSH manual, “How Public Key Authentication Works”.

Ejemplo guiado: cifrado simétrico

$ echo -n "numero-de-tarjeta-de-ejemplo" | \
  openssl enc -aes-256-cbc -pbkdf2 -a -salt -pass pass:clave-de-prueba
U2FsdGVkX1+3f8K9pQ2mVx7bT4nO5rWePq8LxAYbZ9w=

El algoritmo AES-256-CBC es público. Solo la clave es secreta. Este es el principio de Kerckhoffs: la seguridad debe residir en la clave, nunca en ocultar el algoritmo.

Referencia. Kerckhoffs, A. (1883). “La cryptographie militaire”. Journal des sciences militaires.

Cifrado en tránsito

Protege información mientras se desplaza entre componentes.

Sin protección:
Cliente ────────────── Servidor
          datos

Con protección:
Cliente ══ TLS ══════ Servidor

Ejemplos: TLS, conexiones seguras, túneles cifrados, VPN.


Qué significa	Proteger los datos mientras viajan por la red, entre cliente y servidor.
Cómo se protege	TLS con certificados válidos, deshabilitando versiones antiguas de TLS.
En qué beneficia	Previene interceptación y protege credenciales que viajan por la conexión.
Ventaja	Transparente para la aplicación una vez configurado, estándar ampliamente soportado.
Desventaja	No protege el dato una vez que llega a disco o memoria. Requiere gestionar certificados.

TLS en bases de datos

TLS puede proteger conexiones entre:

aplicación y PostgreSQL
aplicación y MongoDB
herramienta administrativa y servidor
componentes de una arquitectura distribuida

Protege principalmente la confidencialidad, la integridad del canal y la autenticación del servidor.

Ejemplo guiado: cifrar la conexión (PostgreSQL)

openssl req -new -x509 -days 365 -nodes -text \
  -out server.crt -keyout server.key -subj "/CN=servidor-demo"
chmod 600 server.key

ssl = on
ssl_cert_file = 'server.crt'
ssl_key_file = 'server.key'

psql "host=servidor.uas.edu.mx dbname=tienda_demo user=lector sslmode=verify-full sslrootcert=ca.crt"

sslmode=verify-full no solo cifra: también valida que el certificado del servidor corresponda al host al que te conectas. sslmode=require cifra pero no valida identidad — útil solo para entender la diferencia, no para producción (REF-U2-03).

Ejemplo guiado: cifrar la conexión (MongoDB)

net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb.pem

mongosh --tls --tlsCertificateKeyFile client.pem --host servidor.uas.edu.mx

Mismo principio que en PostgreSQL: requireTLS obliga a que toda conexión esté cifrada, no solo a las que el cliente decida iniciar cifradas (REF-U2-06).

Cifrado en reposo

Protege información almacenada. Puede aplicarse mediante cifrado de discos, de volúmenes, de respaldos, de archivos, a nivel de aplicación o con mecanismos específicos del motor.

¿Qué sucede si alguien obtiene una copia física del almacenamiento?

El control de acceso al servidor por sí solo puede no ser suficiente.


Qué significa	Proteger los datos mientras están almacenados: en disco, respaldos o snapshots.
Cómo se protege	Cifrado a nivel de columna con `pgcrypto`, cifrado de disco completo, cifrado a nivel de aplicación.
En qué beneficia	Protege contra robo físico del disco, acceso al sistema de archivos, respaldos filtrados.
Ventaja	Protege incluso si el control de acceso del motor falla o es evadido.
Desventaja	La gestión de llaves añade complejidad real. Cifrar una columna dificulta indexar o buscar sobre ese campo.

El cifrado no sustituye al control de acceso del tema 2: alguien con credenciales válidas puede leer datos cifrados igual que datos sin cifrar.

Referencia. ISO/IEC 27002:2022, secc. 8.24, “Use of cryptography”.

Ejemplo guiado: `pgcrypto`, cifrado en reposo (PostgreSQL)

CREATE EXTENSION IF NOT EXISTS pgcrypto;
ALTER TABLE clientes ADD COLUMN rfc_cifrado BYTEA;
UPDATE clientes SET rfc_cifrado = pgp_sym_encrypt(rfc, '<REDACTED-KEY>');
SELECT pgp_sym_decrypt(rfc_cifrado, '<REDACTED-KEY>') FROM clientes;

 ABCD123456XYZ

(REF-U2-04)

Advertencia. Las claves no deben quedar expuestas directamente en consultas, código fuente o repositorios. Este ejemplo usa una clave ficticia solo para mostrar el mecanismo.

Cifrado de datos frente a hashing

No son lo mismo.

Mecanismo	Uso principal	Recuperación
Hash	Verificación	No
Cifrado	Confidencialidad	Sí
HMAC	Integridad y autenticidad	No
TLS	Comunicación segura	No aplica

Las contraseñas no deberían almacenarse mediante cifrado reversible.

Almacenamiento de contraseñas

Una contraseña no debería almacenarse así:

usuario | contraseña
juan    | Secreto123

Ni simplemente mediante SHA-256(contraseña). Para contraseñas se utilizan funciones diseñadas para derivación de claves y resistencia a ataques de fuerza bruta, como Argon2id, bcrypt o scrypt.

SELECT digest('numero-de-tarjeta-de-ejemplo', 'sha256');

No existe un comando para revertir un hash: solo se vuelve a calcular y se compara.

Algoritmo	Por qué sí o no sirve para contraseñas
SHA-256 solo	Rápido a propósito — un atacante puede probar miles de millones de combinaciones por segundo.
bcrypt, scrypt o Argon2	Deliberadamente lentos, con salt integrado.

SELECT crypt('clave-de-usuario', gen_salt('bf'));

Idea clave. Una contraseña debe almacenarse mediante un mecanismo diseñado específicamente para contraseñas.

Referencia. OWASP Password Storage Cheat Sheet, NIST SP 800-63B, secc. 5.1.1.2.

Codificación con Base64 no es cifrado

$ echo -n "numero-de-tarjeta-de-ejemplo" | base64
bnVtZXJvLWRlLXRhcmpldGEtZGUtZWplbXBsbw==

No se usó ninguna clave para decodificarlo. Eso es exactamente lo que significa que Base64 no protege nada — cualquiera puede revertirlo sin ningún secreto. Base64 no proporciona confidencialidad, protección criptográfica ni resistencia contra lectura.

Regla. Codificación no significa cifrado.

Cifrado en MongoDB: una asimetría real entre motores

MongoDB puede utilizar mecanismos de seguridad para proteger comunicaciones, autenticación, determinados datos y almacenamiento. La disponibilidad exacta de determinadas capacidades depende de la versión y edición utilizada.

Principio. El mecanismo técnico debe seleccionarse de acuerdo con el riesgo y la arquitectura.

PostgreSQL cifra dentro del motor con pgcrypto. Una MongoDB Community típica no tiene ese equivalente nativo y transparente: el cifrado automático por campo requiere Enterprise o Atlas.

$ echo -n "ABCD123456XYZ" | \
  openssl enc -aes-256-cbc -pbkdf2 -a -salt -pass pass:<REDACTED-KEY>

db.clientes.updateOne(
  { nombre: "Persona Ejemplo" },
  { $set: { rfc_cifrado: "U2FsdGVkX1+7h2M..." } }
)

El motor nunca ve el valor original de rfc: la aplicación cifra antes de escribir. La versión explícita de cifrado por campo existe en Community desde la versión 4.2, pero exige key vault, proveedor KMS y la librería libmongocrypt — demasiada infraestructura para un laboratorio. Esto tiene una implicación directa: quién es responsable de gestionar la llave cambia según el motor — dentro de la base de datos en PostgreSQL, fuera de ella (a nivel de aplicación) en MongoDB Community.

Manejo seguro de credenciales

Una credencial puede ser:

contraseña
token
API key
certificado
clave privada
cadena de conexión
secreto de aplicación

Nunca debe asumirse que una contraseña es el único secreto que debe protegerse. Una llave de cifrado, igual que una contraseña, nunca debe guardarse en texto plano dentro del código de la aplicación ni en el propio repositorio de código.

Credenciales expuestas en aplicaciones

Un error frecuente:

DB_HOST=servidor
DB_USER=admin
DB_PASSWORD=123456

dentro del código fuente. También pueden aparecer en repositorios Git, archivos .env, logs, scripts, imágenes de contenedores, archivos de configuración y pipelines CI/CD.

¿Qué hacer ante una credencial expuesta?

La respuesta no debe limitarse a eliminar el archivo.

Detectar
   ↓
Revocar
   ↓
Rotar
   ↓
Investigar exposición
   ↓
Verificar accesos
   ↓
Corregir almacenamiento
   ↓
Registrar incidente

Importante. Una credencial publicada debe considerarse comprometida.

Gestión de llaves

Las claves criptográficas también necesitan protección. Debe controlarse su generación, almacenamiento, acceso, distribución, rotación, revocación, respaldo y destrucción.

Cifrar correctamente pero almacenar la clave junto al dato reduce considerablemente la protección.

Ciclo de vida de una llave

Generación
    ↓
Almacenamiento seguro
    ↓
Uso controlado
    ↓
Rotación
    ↓
Revocación
    ↓
Destrucción

La gestión de llaves debe ser independiente del dato que protegen cuando sea posible. La gestión con un servicio externo (gestor de secretos o KMS) excede el alcance de esta unidad.

Actividad 5 — Protección criptográfica. Analiza una contraseña, una conexión de base de datos, un dato almacenado, una credencial de aplicación y una clave criptográfica. Para cada caso determina qué debe protegerse, contra qué amenaza, qué mecanismo utilizar, dónde almacenar los secretos y cómo verificar el control. Instrucciones completas en la Actividad 5, guía técnica en el Laboratorio 2.

Precaución. En los laboratorios de esta unidad nunca uses contraseñas ni llaves reales. Usa siempre valores de ejemplo, y nunca los incluyas en texto plano en un entregable o repositorio.

Referencias de este tema

The PostgreSQL Global Development Group, Secure TCP/IP Connections with SSL (REF-U2-03).
The PostgreSQL Global Development Group, pgcrypto (REF-U2-04).
MongoDB, Inc., Configure MongoDB Instances for TLS/SSL Encryption (REF-U2-06).

Ver Referencias de la unidad para la ficha completa de cada fuente.

Qué sigue

Ya protegimos clientes técnicamente: acceso, clasificación, cifrado. Falta conectar cada control con la obligación legal que lo exige. Continúa con 5. Privacidad y cumplimiento normativo.