POL-004: Política de Estándares de Cifrado

Campo	Valor
ID	POL-004
Versión	1.0
Clasificación	Interno — Confidencial
Fecha de Emisión	2026-03-13
Próxima Revisión	2027-03-13
Propietario	CISO / Equipo de Desarrollo
PCI DSS	Requisitos 3, 4
Preguntas ControlCase	Q26, Q29, Q1034

---

1. Propósito

Definir los estándares de cifrado y gestión de claves criptográficas para la protección de datos sensibles en reposo y en tránsito.

2. Inventario de Suites y Protocolos de Cifrado

2.1 Cifrado en Tránsito

Conexión	Protocolo	Versión Mín	Cipher Suites	Propósito
Cliente → API	TLS	1.2	TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256	Tráfico API público
Kong → Microservicios	mTLS	1.2	TLS_AES_256_GCM_SHA384	Comunicación interna CDE
Servicios → PostgreSQL	TLS	1.2	TLS_AES_256_GCM_SHA384	Queries a base de datos
VPN (WireGuard)	Noise Protocol	IKpsk2	ChaCha20-Poly1305, BLAKE2s	Acceso remoto administrativo

2.2 Cifrado en Reposo

Dato	Algoritmo	Key Size	Modo	Propósito
PAN tokenizado	AES	256 bits	GCM (autenticado)	Protección de datos de tarjeta en vault_db
Integridad de PAN	HMAC	256 bits	SHA-256	Verificación de integridad
Passwords de usuario	Argon2id	N/A	N/A	Hash unidireccional
API Keys	SHA	256 bits	N/A	Hash unidireccional
Backups de DB	AES	256 bits	CBC	Protección de backups
Managed PostgreSQL (DO)	AES	256 bits	XTS	Cifrado de disco por proveedor

2.3 Firmas Digitales

Uso	Algoritmo	Key Size	Propósito
JWT Tokens	RSA	2048 bits	Firma de tokens de autenticación (RS256)
Webhook signatures	HMAC	256 bits	Verificación de integridad de webhooks
TLS Certificates	RSA/ECDSA	2048/256 bits	Autenticación de servidor

3. Protocolos Prohibidos

Protocolo/Algoritmo	Razón de Prohibición
SSL 2.0, 3.0	Vulnerabilidades conocidas (POODLE, BEAST)
TLS 1.0, 1.1	Deprecated por NIST (SP 800-52 Rev 2)
DES, 3DES	Key size insuficiente
RC4	Bias estadístico conocido
MD5	Colisiones demostradas
SHA-1	Colisiones demostradas (SHAttered)
RSA < 2048 bits	Key size insuficiente
CBC sin HMAC	Vulnerable a padding oracle

4. Gestión de Claves Criptográficas

4.1 Ciclo de Vida de Claves

Fase	Procedimiento	Responsable
Generación	CSPRNG (crypto.randomBytes en Node.js, /dev/urandom)	Sistema automatizado
Distribución	Kubernetes Secrets (sealed) o HashiCorp Vault	DevOps
Almacenamiento	Cifrado en reposo (Sealed Secrets / Vault)	Infraestructura
Uso	Solo por servicios autorizados vía RBAC	Aplicación
Rotación	Según calendario (ver §4.2)	Automatizado + DevOps
Revocación	Inmediata ante compromiso sospechado	Oficial de Seguridad
Destrucción	Secure wipe + registro en audit log	Sistema + Oficial

4.2 Calendario de Rotación

Tipo de Clave	Frecuencia de Rotación	Método
Master Encryption Key (MEK)	Anual	Manual con dual control
Data Encryption Keys (DEK)	Por transacción (derivadas de MEK)	Automático
HMAC Keys	Mensual	Automático (CronJob)
JWT Signing Keys (RSA)	Semanal	Automático
TLS Certificates	Antes de expiración (auto-renewal via cert-manager)	Automático
API Keys de terceros	Anual o ante compromiso	Manual
Database passwords	Trimestral	Semi-automático

4.3 Custodia de Claves

• La clave maestra (MEK) requiere dual control: dos personas distintas, cada una con una parte de la clave
• Ninguna persona individual tiene acceso a la clave completa
• Los custodios de claves firman un reconocimiento de su responsabilidad

5. Inventario de Certificados TLS

Dominio/Servicio	Emisor	Tipo	Expiración	Auto-renewal
*.fintrixs.com	Let's Encrypt	DV	Auto-renovación cada 60 días	cert-manager
API interno (mTLS)	CA interna (K8s)	Interno	1 año	cert-manager
Managed PostgreSQL	DigitalOcean CA	Managed	Gestionado por DO	Sí

5.1 Validación de Certificados

• Certificados que no pueden ser verificados como confiables son rechazados
• Conexiones TLS validan: expiración, cadena de confianza, revocación
• No se aceptan certificados auto-firmados en producción (excepto CA interna para mTLS)

6. Monitoreo de Viabilidad Criptográfica

6.1 Fuentes Monitoreadas

• NIST Special Publications (SP 800-57, SP 800-131A)
• ENISA Algorithms Report
• RFC/IETF deprecation notices
• PCI SSC Bulletin Board

6.2 Proceso de Monitoreo

• Revisión trimestral de avisos de vulnerabilidades criptográficas
• Evaluación de impacto si un algoritmo en uso es declarado vulnerable
• Actualización de este inventario ante cualquier cambio

7. Estrategia de Respuesta a Cambios Criptográficos

Si un algoritmo o protocolo en uso es declarado vulnerable o deprecated:

Severidad	Acción	Plazo
Crítica (explotación activa)	Migración de emergencia	24-72 horas
Alta (vulnerabilidad demostrada)	Plan de migración urgente	30 días
Media (deprecation anunciado)	Plan de migración planificado	6 meses
Baja (recomendación de transición)	Inclusión en roadmap	12 meses

7.1 Plan de Migración Criptográfica

1. Evaluación de impacto (sistemas afectados)
2. Selección de algoritmo de reemplazo (aprobado por NIST)
3. Pruebas en entorno de desarrollo
4. Migración gradual con soporte dual temporal
5. Verificación de compatibilidad
6. Remoción del algoritmo deprecated
7. Actualización de documentación

8. Datos Sensibles — Búsqueda y Verificación (Q26)

8.1 Escaneo de PAN

• Se realiza un escaneo trimestral de todos los activos en scope buscando PAN almacenado
• Herramientas: scripts personalizados + herramientas de descubrimiento de datos
• Alcance: Bases de datos, logs, archivos temporales, backups

8.2 SAD (Sensitive Authentication Data)

• CVV/CVC: No existe campo en ninguna tabla de la base de datos. Validación de DTOs rechaza estos campos.
• Track completo: No procesado ni almacenado
• PIN/PIN block: No procesado ni almacenado
• Los logs de aplicación redactan automáticamente campos sensibles (ver packages/logging/)

---

Historial de Revisiones

Versión	Fecha	Autor	Cambios
1.0	2026-03-13	Equipo de Desarrollo / Seguridad	Documento inicial

Aprobación

Rol	Nombre	Firma	Fecha
CISO / Oficial de Seguridad	_________________	_________________	//____
Gerencia Ejecutiva	_________________	_________________	//____