Skip to content

EVD-CRYPTO-DATA — Evidencia de Cifrado y Protección de Datos ​

Direccionamiento corregido el 2026-08-16 · AVISO-SUBREDES-2026-08

Este documento describía subredes por función —10.100.10.0/24, 10.100.20.0/24 y similares— que no existen en la infraestructura. La red de producción es plana, 10.100.0.0/16, con todos los sistemas en 10.100.0.x.

Las referencias se han sustituido por el mecanismo de separación real: cortafuegos aplicados por etiqueta y políticas de red del orquestador con denegación por defecto. Las zonas funcionales sí existen; su direccionamiento no.

Descripción completa en Arquitectura de red — descripción verificada.

CampoValor
IDEVD-CRYPTO-DATA
Versión1.0
Fecha2026-04-03
ClasificaciónInterno — Confidencial
PropietarioCISO / Equipo de Desarrollo
Política de referenciaPOL-004 Estándares de Cifrado
PCI DSS v4.0Requisitos 3, 4
Preguntas ControlCaseQ26, Q29, Q1034

Q26 — Descubrimiento de Datos de Tarjeta (PAN, Track, CVV, PIN) ​

Alcance del CDE ​

Solo dos microservicios dentro del Cardholder Data Environment (CDE) tienen contacto con PANs:

ServicioFunciónZonaNode Pool
card-vault-service (puerto 3003)Cifrado/descifrado de PANs mediante envelope encryption AES-256-GCMetiqueta fintrix-cde (CDE)cde-pool (Taint pci-scope=true)
tokenization-service (puerto 3002)Recibe PAN, genera token irreversible, almacena dato cifrado en vaultetiqueta fintrix-cde (CDE)cde-pool (Taint pci-scope=true)

Ningun otro servicio del monorepo (payments-api, orchestration-service, email-service, etc.) recibe, almacena ni procesa PANs. Estos servicios trabajan exclusivamente con tokens (tok_pan_*).

Cifrado en Reposo ​

Tokenization Service — AES-256-GCM directo ​

El servicio cifra el dato sensible antes de almacenarlo en la tabla payments_vault.tokenized_data:

typescript
// backend/apps/tokenization-service/src/tokenization.service.ts
private encrypt(data: string): { encrypted: string; iv: string; authTag: string } {
  const iv = crypto.randomBytes(12);                                    // 96-bit IV
  const cipher = crypto.createCipheriv('aes-256-gcm', this.encryptionKey, iv);
  let encrypted = cipher.update(data, 'utf8', 'hex');
  encrypted += cipher.final('hex');
  const authTag = cipher.getAuthTag();
  return { encrypted, iv: iv.toString('hex'), authTag: authTag.toString('hex') };
}
  • Algoritmo: AES-256-GCM (cifrado autenticado)
  • IV: 12 bytes aleatorios por registro (CSPRNG crypto.randomBytes)
  • Auth Tag: 16 bytes (integridad garantizada)
  • Clave: 32 bytes desde VAULT_ENCRYPTION_KEY via ConfigService

Card Vault Service — Envelope Encryption (DEK + KEK) ​

El vault implementa un esquema de envelope encryption donde cada registro tiene su propia DEK:

typescript
// backend/apps/card-vault-service/src/crypto/envelope/envelope-crypto.service.ts
async encrypt(plaintext: string): Promise<EncryptedEnvelope> {
  const dek = randomBytes(32);       // DEK unica por registro
  const iv  = randomBytes(12);       // IV unico por registro
  const cipher = createCipheriv('aes-256-gcm', dek, iv);
  // ...encrypt...
  const wrapped = await this.kek.wrapDek(dek);   // KEK wraps DEK
  return { ciphertextB64: payload, dekCiphertextB64: wrapped.dekCiphertextB64, kekKeyId: wrapped.kekKeyId };
}

Esquema de Base de Datos ​

sql
-- payments_vault.tokenized_data
CREATE TABLE payments_vault.tokenized_data (
    token           VARCHAR(100) PRIMARY KEY,
    encrypted_data  BYTEA NOT NULL,         -- PAN cifrado AES-256-GCM
    hmac_hash       BYTEA NOT NULL,         -- HMAC-SHA256 de integridad
    data_type       VARCHAR(50) NOT NULL,
    merchant_id     UUID NOT NULL,
    key_version     INTEGER DEFAULT 1,      -- Versionado de claves
    created_at      TIMESTAMPTZ DEFAULT NOW(),
    expires_at      TIMESTAMPTZ
);

-- RLS: acceso solo por merchant autenticado
ALTER TABLE payments_vault.tokenized_data ENABLE ROW LEVEL SECURITY;
CREATE POLICY vault_access_policy ON payments_vault.tokenized_data
    FOR ALL TO vault_user
    USING (merchant_id::text = current_setting('app.current_merchant_id', true));

Redaccion Automatica de PAN en Logs (@fintrix/logging) ​

El paquete @fintrix/logging implementa masking automatico a nivel de string y objeto:

Patrones de redaccion (regex):

DatoPatronReemplazo
PAN/\b\d{13,19}\b/g[REDACTED-PAN]
Password/password["\s:=]+...password=[REDACTED]
Authorization/authorization["\s:=]+...authorization=[REDACTED]
API Key/api[_-]?key["\s:=]+...api_key=[REDACTED]
Token/token["\s:=]+...token=[REDACTED]

Claves sensibles redactadas en objetos:

password, token, secret, apiKey, api_key, authorization, pan, cardNumber, card_number, cvv, cvc, ssn, socialSecurityNumber

typescript
// backend/packages/logging/src/logger.service.ts
private redactSensitiveData(value: string): string {
  let redacted = value;
  redacted = redacted.replace(SENSITIVE_PATTERNS.PAN, '[REDACTED-PAN]');
  redacted = redacted.replace(SENSITIVE_PATTERNS.PASSWORD, 'password=[REDACTED]');
  redacted = redacted.replace(SENSITIVE_PATTERNS.AUTH_HEADER, 'authorization=[REDACTED]');
  redacted = redacted.replace(SENSITIVE_PATTERNS.API_KEY, 'api_key=[REDACTED]');
  redacted = redacted.replace(SENSITIVE_PATTERNS.TOKEN, 'token=[REDACTED]');
  return redacted;
}

Resultado: ningun PAN, CVV, password o clave de API aparece en texto claro en los logs de la aplicacion.

Datos Sensibles de Autenticacion (SAD) ​

Dato SADEstadoEvidencia
CVV/CVCNo almacenado. DTOs validan y rechazan almacenamiento post-autorizaciontokenization-service procesa solo para transmision inmediata al procesador
Track completo (Track 1/2)No procesado ni almacenadoNo existe campo en ningun DTO ni tabla de base de datos
PIN / PIN blockNo procesado ni almacenadoFintrixs no procesa transacciones con PIN
PAN completo en logsRedactado automaticamente@fintrix/logging aplica SENSITIVE_PATTERNS.PAN a toda salida

Escaneo de Descubrimiento de Datos de Tarjeta ​

AspectoEstado
HerramientaControlCase Card Data Discovery Tool (CDAT)
Ticket#684997 — pendiente de ejecucion por QSA
Alcance del escaneoBases de datos (vault_db, payments_db, auth_db), logs almacenados, backups, archivos temporales
Frecuencia objetivoTrimestral
Escaneo interno previoScripts personalizados (grep -rP '\b\d{13,19}\b') ejecutados sobre logs y codigo fuente — sin hallazgos de PAN en claro

Referencias ​


Q29 — Cifrado de Datos en Transito ​

Inventario de Conexiones TLS ​

Protocolos y Cipher Suites por Conexion ​

ConexionProtocoloVersion MinCipher SuitesCertificado
Cliente → LB (publico)TLS1.3TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256Let's Encrypt DV (auto-renovacion 60 dias via cert-manager)
LB → Kong GatewayTLS1.2TLS_AES_256_GCM_SHA384CA interna K8s
Kong → Microservicios CDEmTLS1.2TLS_AES_256_GCM_SHA384CA interna K8s (cert-manager)
Servicios → PostgreSQLTLS1.2TLS_AES_256_GCM_SHA384DigitalOcean Managed CA
Servicios → KafkaTLS + SASL_SSL1.2TLS_AES_256_GCM_SHA384Confluent Cloud CA
VPN administrativaWireGuard (Noise)IKpsk2ChaCha20-Poly1305, BLAKE2sPre-shared keys

PostgreSQL — Conexion TLS Obligatoria ​

Todas las conexiones a PostgreSQL usan sslmode=require:

postgresql://<user>:<pass>@<host>:25060/<db>?sslmode=require

DigitalOcean Managed PostgreSQL fuerza TLS en todas las conexiones y no permite conexiones sin cifrar.

Kafka — TLS + SASL ​

yaml
# Configuracion Kafka en cada servicio (via @fintrix/event-bus)
security.protocol: SASL_SSL
sasl.mechanism: PLAIN              # Confluent Cloud
ssl.enabled.protocols: TLSv1.2,TLSv1.3

Kong Gateway — HTTPS Enforced ​

Kong API Gateway esta configurado para:

  • Rechazar tráfico HTTP (solo HTTPS en puerto 443)
  • Aplicar mTLS para comunicacion interna al CDE
  • Validar cadena de certificados completa

Referencia: backend/infra/kong/kong.yaml

Inventario de Certificados TLS ​

Dominio/ServicioEmisorTipoVigenciaAuto-renovacion
*.fintrixs.comLet's EncryptDV90 dias (renovacion cada 60)cert-manager
mTLS interno (Kong ↔ CDE)CA interna K8sInterno1 anocert-manager
Managed PostgreSQLDigitalOcean CAManagedGestionado por DOSi
Kafka (Confluent Cloud)Confluent CAManagedGestionado por ConfluentSi

Protocolos Prohibidos ​

ProtocoloRazon de Prohibicion
SSL 2.0, 3.0Vulnerabilidades POODLE, BEAST
TLS 1.0Deprecated por NIST SP 800-52 Rev 2
TLS 1.1Deprecated por NIST SP 800-52 Rev 2
RC4Bias estadistico conocido

Ejemplo de Verificacion de TLS en Transito ​

bash
# Verificar cipher suite del endpoint publico
$ openssl s_client -connect api.fintrixs.com:443 -tls1_3 2>/dev/null | grep -E 'Protocol|Cipher'
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384

# Verificar que TLS 1.0 esta rechazado
$ openssl s_client -connect api.fintrixs.com:443 -tls1 2>&1 | grep -i error
    error: ... handshake failure

Q1034 — Gestion de Cipher Suites Criptograficas ​

Inventario Completo de Cifrados en Uso ​

Cifrado en Transito ​

ContextoProtocoloCipher Suites Aceptadas
Trafico publico (API)TLS 1.3TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256
Trafico publico (fallback)TLS 1.2ECDHE-RSA-AES256-GCM-SHA384, ECDHE-RSA-AES128-GCM-SHA256
Comunicacion interna CDEmTLS 1.2+TLS_AES_256_GCM_SHA384
PostgreSQLTLS 1.2+TLS_AES_256_GCM_SHA384
KafkaSASL_SSL TLS 1.2+TLS_AES_256_GCM_SHA384

Cifrado en Reposo ​

DatoAlgoritmoKey SizeModoUbicacion
PAN (tokenization-service)AES256 bitsGCM (autenticado)payments_vault.tokenized_data
PAN (card-vault-service)AES256 bitsGCM (envelope: DEK + KEK)vault_db.encrypted_cards
Integridad de PANHMAC256 bitsSHA-256Columna hmac_hash
PAN fingerprintHMAC256 bitsSHA-256Columna panFingerprint
Disco de PostgreSQL (DO)AES256 bitsXTSGestionado por DigitalOcean
Backups de DBAES256 bitsCBCDigitalOcean Spaces cifrado

Firmas Digitales y Hashing ​

UsoAlgoritmoKey SizeImplementacion
JWT Tokens (auth-service)RSA2048 bitsRS256 via @nestjs/jwt
Webhook signaturesHMAC256 bitsSHA-256
Password hashingbcryptcost factor 12bcryptjs
Certificados TLSRSA / ECDSA2048 / 256 bitsLet's Encrypt, CA interna

Algoritmos y Protocolos Prohibidos ​

Algoritmo/ProtocoloRazonReferencia
SSL 2.0, 3.0POODLE, BEASTNIST SP 800-52 Rev 2
TLS 1.0, 1.1DeprecatedNIST SP 800-52 Rev 2
DES, 3DESKey size insuficienteNIST SP 800-131A
RC4Bias estadistico conocidoRFC 7465
MD5Colisiones demostradasNIST
SHA-1Colisiones demostradas (SHAttered)NIST
RSA < 2048 bitsKey size insuficienteNIST SP 800-57
CBC sin HMACVulnerable a padding oraclePCI DSS v4.0

Ciclo de Vida de Claves Criptograficas ​

Calendario de Rotacion de Claves ​

Tipo de ClaveFrecuenciaMetodoResponsable
Master Encryption Key (KEK)AnualManual con dual controlCISO + DevOps Lead
Data Encryption Keys (DEK)Por registro (card-vault)Automatico (CSPRNG)Sistema
VAULT_ENCRYPTION_KEYTrimestralRotacion manual con re-cifradoDevOps
HMAC KeysMensualCronJob automatizadoSistema
JWT Signing Keys (RSA)SemanalAutomaticoauth-service
TLS Certificates (publicos)Cada 60 diascert-manager (auto)Sistema
TLS Certificates (internos)Anualcert-managerSistema
Database passwordsTrimestralSemi-automaticoDevOps

Custodia de Claves (Dual Control) ​

  • La Master Encryption Key (KEK) 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 firman un reconocimiento de responsabilidad
  • Referencia: POL-004, seccion 4.3

Monitoreo de Viabilidad Criptografica ​

Fuentes Monitoreadas ​

FuenteFrecuencia de RevisionResponsable
NIST Special Publications (SP 800-57, SP 800-131A)TrimestralCISO
ENISA Algorithms ReportTrimestralEquipo de Desarrollo
RFC/IETF deprecation noticesContinuo (suscripcion)DevOps
PCI SSC Bulletin BoardMensualCISO
CERT/CC AdvisoriesContinuo (suscripcion)DevOps
CVE Database (NVD)Continuo (automatizado)Sistema de alertas

Estrategia de Migracion para Cipher Suites Deprecated ​

SeveridadAccionPlazo
Critica (explotacion activa)Migracion de emergencia24-72 horas
Alta (vulnerabilidad demostrada)Plan de migracion urgente30 dias
Media (deprecation anunciado)Plan de migracion planificado6 meses
Baja (recomendacion de transicion)Inclusion en roadmap12 meses

Procedimiento de Migracion Criptografica ​

  1. Evaluacion de impacto (sistemas afectados, volumen de datos)
  2. Seleccion de algoritmo de reemplazo (aprobado por NIST)
  3. Pruebas en entorno de desarrollo/staging
  4. Migracion gradual con soporte dual temporal (version N y N+1)
  5. Verificacion de compatibilidad con procesadores de pago
  6. Remocion del algoritmo deprecated
  7. Actualizacion de POL-004 y este documento de evidencia

Resumen de Controles y Estado ​

ControlPCI DSS ReqEstadoEvidencia
Cifrado de PAN en reposo (AES-256-GCM)3.4.1Implementadotokenization-service, card-vault-service
Envelope encryption (DEK + KEK)3.5.1Implementadocard-vault-service/crypto/
No almacenamiento de SAD post-auth3.3ImplementadoSin campos CVV/PIN en schema
Redaccion de PAN en logs3.4Implementado@fintrix/logging
TLS 1.2+ en todas las conexiones4.2.1ImplementadoLB, Kong, PostgreSQL, Kafka
Inventario de cipher suites4.2.1DocumentadoPOL-004, este documento
Protocolos deprecated bloqueados4.2.1ImplementadoSSL/TLS 1.0/1.1 deshabilitados
Rotacion de claves programada3.6.1ImplementadoCalendario definido
Dual control de KEK3.6.1ImplementadoProcedimiento documentado
Escaneo de descubrimiento de PAN3.4Pendiente QSATicket #684997 (CDAT)
Monitoreo de viabilidad criptografica4.2.1ActivoSuscripciones NIST/CERT

Historial de Revisiones ​

VersionFechaAutorCambios
1.02026-04-03Equipo de Desarrollo / SeguridadDocumento inicial de evidencia

Aprobacion ​

RolNombreFirmaFecha
CISO / Oficial de Seguridad__________________________________//____
Gerencia Ejecutiva__________________________________//____

Documentación Confidencial — Solo para uso interno y auditoría PCI DSS