Tema
INV-004 — Cryptographic Key Custody Registry
| Campo | Valor |
|---|---|
| ID | INV-004 |
| Versión | 1.0 |
| Fecha emisión | 2026-08-01 |
| Próxima revisión | 2026-11-01 (trimestral) |
| Propietario | CISO + CTO |
| PCI DSS | Req 3.5, 3.6.1, 3.6.2, 3.7.1-3.7.9, 8.2.1 |
| Retención | 7 años post-retiro de la clave |
1. Propósito
Inventario auditable de todas las claves criptográficas en uso en el sistema Fintrixs Pay, con custodios asignados, rotación programada, propósito y estado.
Cumple con PCI DSS Req 3.7.2: "Restrict access to cryptographic keys to the fewest number of custodians necessary" — este documento es ese registro.
2. Claves activas — Producción
KEY-001 — Vault Shamir Master Key
| Campo | Valor |
|---|---|
| ID interno | KEY-001 |
| Algoritmo | Shamir Secret Sharing over GF(256) |
| Configuración | 5 shares, threshold 3-of-5 |
| Propósito | Desbloqueo del Vault OSS 1.15.6 |
| Ubicación | Distribuido en 5 custodios físicos (papel notariado) |
| Fecha generación | 2026-07-30 (inicial) / 2026-08-XX (ceremonia distribución) |
| Rotación programada | 2027-08-05 (anual) |
| Longitud | 256 bits (base key), each share ~64 chars hex |
| Custodios | Ver INV-004-CUSTODIANS (secreto, restringido a coord + notario) |
| Método distribución | Papel A4 con QR + hex, notariado |
| Registro cadena de custodia | docs/security/vault-shamir-ceremony/CUSTODIAL-CHAIN-OF-CUSTODY.md |
| Ceremonia asociada | SHAMIR-20260805-01 |
| Ubicaciones físicas | Bogotá (4), Medellín (1) — separación geográfica |
| Threshold recuperación | 3 custodios cooperando |
| Estado | ⚠️ Ceremonia pendiente ejecución (paquete preparado en repo) |
Uso operativo:
- Startup del cluster Vault: unseal automático via Auto-Unseal (si config), o manual con 3 shares.
- Rotación anual:
vault operator rekeyen nueva ceremonia.
Riesgos + mitigaciones:
- Pérdida de 3+ shares: Vault irrecuperable. Mitigación: 5 shares = sobrevive a 2 perdidos.
- Compromiso de 3 shares: rekey de emergencia < 24h + re-cifrado todas las KEK downstream.
KEY-002 — Vault Transit KEK (kek-card-vault)
| Campo | Valor |
|---|---|
| ID interno | KEY-002 |
| Algoritmo | AES-256-GCM (Vault Transit) |
| Propósito | Cifrar/descifrar PANs almacenados en card-vault-service |
| Ubicación | Vault Transit engine, path transit/kek-card-vault |
| Custodio efectivo | HashiCorp Vault (custodia técnica) |
| Custodio human | CTO Gabriel Ureña (autoriza rotaciones via UI Vault) |
| Rotación programada | Cada 12 meses (PCI DSS Req 3.7.4) |
| Última rotación | 2026-XX-XX (pending si no ejecutada) |
| Próxima rotación | 2027-XX-XX |
| Método rotación | vault write -f transit/keys/kek-card-vault/rotate |
| Estrategia rewrap | Automatizada — script rewrap-kek-card-vault.sh reencripta ciphertexts existentes a la nueva versión |
| Versión activa | v1 (actualizar tras primera rotación) |
| Estado | ✅ Activa |
Riesgos:
- Compromiso de KEK: attacker con acceso Vault + policy Transit puede descifrar TODOS los PANs. Mitigación: Vault protegido con Shamir, policies restrictivas, auditoría.
KEY-003 — HMAC PAN Fingerprint Key (hmac-pan-fpr)
| Campo | Valor |
|---|---|
| ID interno | KEY-003 |
| Algoritmo | HMAC-SHA256 (Vault Transit) |
| Propósito | Fingerprint determinístico de PAN sin revelar (para dedup / search) |
| Ubicación | Vault Transit engine, path transit/hmac-pan-fpr |
| Custodio efectivo | Vault |
| Custodio human | CTO |
| Rotación programada | 24 meses (dedup breaks al rotar, evaluar impacto) |
| Última rotación | 2026-XX-XX |
| Próxima rotación | 2028-XX-XX |
| Estado | ✅ Activa |
KEY-004 — DR Backup GPG Public Key
| Campo | Valor |
|---|---|
| ID interno | KEY-004 |
| Algoritmo | RSA 4096-bit + AES-256 (GPG hybrid) |
| Propósito | Cifrar backups DR antes de subir a Backblaze B2 |
| Recipient | [email protected] |
| Fingerprint | (ver backend/infra/dr/backup-public.gpg) |
| Public key location | backend/infra/dr/backup-public.gpg (repo git) + /root/.gnupg-dr/ en vault-01,02,03 |
| Private key custodios | 2 personas independientes (backup dual): |
| 1. CTO Gabriel Ureña — pendrive USB encriptado, safe residencia | |
| 2. Legal Externa Laura Gómez (ejemplo) — sobre lacrado en Notaría 42 | |
| Rotación programada | Cada 24 meses |
| Última rotación | 2026-07-30 (generación inicial) |
| Próxima rotación | 2028-07-30 |
| Estado | ✅ Activa. Public key distribuida; private key custodial. |
Uso operativo:
- Cada backup DR (vault snapshot, pg_dump, k8s state, terraform state, container images) se cifra con esta pubkey antes de upload a B2.
- Para restore: 1 de los 2 custodios provee su private key.
KEY-005 — Auth Service JWT Signing Key (RS256)
| Campo | Valor |
|---|---|
| ID interno | KEY-005 |
| Algoritmo | RSA 2048-bit (JWT RS256) |
| Propósito | Firma de JWT emitidos por auth-service para usuarios finales |
| Ubicación | auth-service K8s secret auth-service-secrets key JWT_PRIVATE_KEY |
| Custodio técnico | Kubernetes Secrets (encrypted at rest via kube API) |
| Public key | Distribuida a: card-vault-service, tokenization-service, payments-api (secret JWT_PUBLIC_KEY) |
| Rotación programada | 12 meses |
| Última rotación | 2026-XX-XX |
| Próxima rotación | 2027-XX-XX |
| Método rotación | Dual-key rollout: emit nueva key, verificar en todos los consumers, retirar vieja |
| Estado | ✅ Activa |
KEY-006 — Service-to-Service JWT HMAC (HS256)
| Campo | Valor |
|---|---|
| ID interno | KEY-006 |
| Algoritmo | HMAC-SHA256 |
| Propósito | Firma de JWT S2S entre payments-api → card-vault-service |
| Ubicación | K8s secret payments-api-secrets + card-vault-jwt en namespace pci-cde |
| Custodio técnico | Kubernetes Secrets (encrypted at rest) |
| Rotación programada | 6 meses |
| Última rotación | 2026-07-31 (creación inicial durante cutover pci-cde) |
| Próxima rotación | 2027-01-31 |
| Método rotación | Rekey → patch K8s secret → rolling restart |
| Estado | ✅ Activa |
KEY-007 — Vault AppRole SecretIDs (card-vault, tokenization)
| Campo | Valor |
|---|---|
| ID interno | KEY-007a (card-vault), KEY-007b (tokenization) |
| Algoritmo | Random opaque token 32-byte |
| Propósito | Autenticación service-to-Vault via AppRole |
| Ubicación | K8s secrets vault-approle-card-vault + vault-approle-tokenization en pci-cde |
| Custodio técnico | K8s Secrets encrypted at rest |
| TTL | 720h (30 días) desde 2026-07-31 hardening |
| Rotación programada | Cada 7 días vía cronjob systemd |
| Última rotación | 2026-07-31 (manual durante hardening) |
| Próxima rotación auto | Domingo 2026-08-02 03:08 UTC (vault-approle-rotator.timer) |
| Estado | ✅ Activa + auto-rotation |
KEY-008 — B2 Application Keys (6 scoped)
| Campo | Valor |
|---|---|
| ID interno | KEY-008a → KEY-008f (una por bucket) |
| Algoritmo | Random opaque token 32-byte (Backblaze) |
| Propósito | Autenticación least-privilege por bucket DR |
| Ubicación | Vault-01,02,03 /etc/b2-credentials/ (root:root 600) |
| Custodio técnico | Sistema (root drive) |
| Custodio human | CTO |
| Rotación programada | 90 días (PCI DSS 8.3.10.1) |
| Última rotación | 2026-07-31 (creación inicial + terraform/images 2026-08-01) |
| Próxima rotación | 2026-10-31 |
| Estado | ✅ Activas. |
Detalle por bucket:
- KEY-008a:
writer-fintrix-dr-vault— vault snapshots - KEY-008b:
writer-fintrix-dr-postgres— pg backups - KEY-008c:
writer-fintrix-dr-manifests— k8s state - KEY-008d:
writer-fintrix-dr-audit— vault audit logs - KEY-008e:
writer-fintrix-dr-terraform— tfstate - KEY-008f:
writer-fintrix-dr-images— container images mirror
KEY-009 — Master B2 Key PCI (temporal)
| Campo | Valor |
|---|---|
| ID interno | KEY-009 |
| Algoritmo | Random opaque token 32-byte |
| Propósito | Master account key para crear las 6 scoped keys |
| Ubicación | Local en máquina del CTO — no persistida en repo |
| Custodio | CTO Gabriel Ureña |
| Estado | ⚠️ ACTIVA — PENDING REVOCACIÓN |
| Fecha creación | 2026-08-01 |
| Fecha revocación esperada | Tan pronto como usuario confirme setup completo (< 24h post-creación) |
Acción requerida: el CTO revocará esta master key desde app.backblazeb2.com
Application Keys → deletes "PCI" key.
3. Claves retiradas / rotadas
(Historial de claves que ya no están en uso pero se conservan por auditoría — según Req 3.7.9 rotación implica retirement documentado)
| ID | Retirada | Motivo | Reemplaza a | Reemplazada por |
|---|---|---|---|---|
| KEY-010 | 2026-07-31 | Hardening PCI | Master B2 antigua Fintrixs-compliance | KEY-008a-f + KEY-009 |
4. Matriz responsabilidad
| Actividad | CTO | CISO | CFO | Legal | Vault ops |
|---|---|---|---|---|---|
| Autorizar rotación programada | R | A | I | I | C |
| Autorizar rotación emergencia | A | R | I | C | C |
| Ejecutar rotación técnica | R | I | — | — | C |
| Custodia física (shares Shamir) | C | C | C | C | — |
| Auditoría de rotación | I | R | — | A | — |
R = Responsible, A = Accountable, C = Consulted, I = Informed
5. Cronograma de rotaciones 2026-2027
| Fecha | Clave | Acción | Owner |
|---|---|---|---|
| 2026-08-05 | KEY-001 (Shamir) | Ceremonia distribución inicial | CTO |
| 2026-08-XX | KEY-002 (KEK card-vault) | Rotación primera (si aún v1) | CTO |
| Sun 2026-08-02 03:08 UTC | KEY-007 (AppRole) | Rotación auto (weekly) | System |
| 2026-10-31 | KEY-008 (B2 scoped) | Rotación 90d | CTO |
| 2027-01-31 | KEY-006 (S2S JWT) | Rotación 6m | CTO |
| 2027-07-30 | KEY-004 (DR GPG) | Rotación 24m | CTO + Legal |
| 2027-08-05 | KEY-001 (Shamir) | Ceremonia rotación anual | Todos |
6. Notificación al QSA
Cada rotación de clave debe:
- Documentarse en este INV-004 (actualizar "última rotación").
- Escribir entry en
docs/security/ROTATION-LOG.md(crear si no existe). - Si es rotación de emergencia: notificar al QSA en < 48h.