Tema
Pregunta 28 — Protección de datos de titular de tarjeta y gestión de claves
| Campo | Valor |
|---|---|
| Destinatario | José David Álvarez — QSA ControlCase |
| Documento | Q28-RESP-2026-08 |
| Fecha | 2026-08-16 |
| Documento base | DOC-KEY-MGMT-01 — Procedimiento de Gestión de Claves v1.0 |
| Controles PCI | Req 3.5.1, 3.6.1, 3.6.1.2, 3.6.1.3, 3.7.x |
| Elaborado | Gabriel Ureña Chacón — CTO Fintrix Pay |
1. Observación sobre la independencia entre la clave de datos y el dato
Es la observación de fondo y la resolvemos con el comportamiento real del servicio, no con la redacción del procedimiento.
Nuestra documentación era ambigua y por eso parecía contradictoria. Decía en un punto que las claves de datos permanecen en memoria y en otro que se almacenan cifradas junto al registro. Ambas afirmaciones son ciertas y describen cosas distintas, pero no lo aclaraban.
1.1 Cómo funciona realmente
| Elemento | Dónde vive | Estado |
|---|---|---|
| Clave de datos en claro | Solo en memoria del proceso, durante la operación | Se descarta al terminar |
| Clave de datos cifrada | Junto al registro, en el mismo almacén | Persistida |
| Clave que cifra las claves de datos | Nunca sale del gestor de claves | Persistida y aislada |
| Dato de titular de tarjeta | Cifrado con la clave de datos | Persistido |
Secuencia de escritura:
- El gestor de claves genera una clave de datos por registro y la entrega en dos formas: en claro y envuelta.
- El cifrado del número de tarjeta se realiza en memoria con la clave en claro.
- La clave en claro se descarta.
- Se persisten el dato cifrado y la clave envuelta.
Secuencia de lectura: el gestor desenvuelve la clave, se descifra en memoria, y la clave se limpia de memoria.
1.2 Por qué esto satisface el requisito
La independencia que exige el requisito es entre la clave que cifra las claves de datos y las propias claves de datos — no entre la clave de datos y el dato. Almacenar la clave de datos cifrada junto al registro es el patrón previsto por el propio estándar.
En nuestra implementación esa independencia es estricta: la clave superior nunca sale del gestor. Obtener el dato exige comprometer simultáneamente el almacén de datos y el gestor de claves, que son sistemas distintos con autenticación y control de acceso independientes.
1.3 Evidencia
La lógica está documentada en el propio código del servicio que custodia los datos, en la cabecera del módulo de cifrado. Los tres invariantes que declara y que quedan a su disposición para revisión:
- el número de tarjeta nunca se escribe en disco sin cifrar
- la clave de datos nunca se escribe en disco sin cifrar
- la clave superior nunca sale del gestor de claves
Se corregirá la redacción del procedimiento para eliminar la ambigüedad.
2. Arquitectura verificada el 2026-08-16
| Elemento | Estado |
|---|---|
| Gestor de claves | Tres instancias en alta disponibilidad, todas accesibles |
| Jerarquía | Clave maestra → clave de cifrado de claves → clave de datos por registro |
| Cifrado de datos | AES-256-GCM |
| Integridad | HMAC-SHA-256 |
| Acceso de servicios | Credenciales por servicio, no compartidas |
Los servicios que manejan datos de titular de tarjeta se autentican contra el gestor con credenciales propias e independientes entre sí.
3. Separación entre producción y pruebas
Los entornos utilizan infraestructura de red separada y gestores de claves distintos. Ninguna clave de producción es accesible desde el entorno de pruebas: son sistemas diferentes, con credenciales diferentes, en redes diferentes.
4. Lo que NO podemos aportar desde el entorno técnico
Estos elementos son de naturaleza organizativa o física y no se declaran como ejecutados en esta respuesta. Se relacionan para que quede claro qué falta:
| # | Elemento solicitado | Situación |
|---|---|---|
| 1 | Fotografías del mecanismo de custodia física de los fragmentos de la clave maestra | Pendiente. Requiere documentar la ceremonia de custodia. Se fotografiará el contenedor y el mecanismo, nunca el contenido de un fragmento |
| 2 | Acta de custodia e inventario de custodios | Pendiente. Documento organizativo |
| 3 | Registro de ubicación de cada fragmento | Pendiente. Documento organizativo |
| 4 | Acta de la última ceremonia de rotación | Pendiente. Depende del calendario de rotación declarado |
| 5 | Reconocimiento formal de responsabilidad de los custodios | Pendiente. Documento firmado por cada custodio |
No presentamos como hechas actividades que no lo están. Preferimos declarar la brecha y aportar fecha de cierre a entregar evidencia que no se sostenga.
5. Compromiso de fechas
| Elemento | Fecha comprometida |
|---|---|
| Corrección de la redacción del procedimiento (§1.3) | Inmediata |
| Ceremonia documentada de custodia y fotografías | A convenir con el equipo evaluador |
| Actas de custodia y reconocimientos firmados | A convenir con el equipo evaluador |
Quedamos a disposición para realizar la ceremonia con presencia o supervisión del equipo evaluador si lo consideran conveniente, lo que resolvería a la vez la evidencia y su verificación independiente.
6. Evidencia de respaldo publicada
| Documento | Qué aporta |
|---|---|
| Procedimiento de gestión de claves | Procedimiento formal DOC-KEY-MGMT-01 |
| Arquitectura criptográfica | Jerarquía de claves y algoritmos |
| Evidencia Q28 — gestión de claves | Paquete de evidencia técnica original |
| Q24 · Criptografía en acceso administrativo | Protección del acceso de administración |
| Q51 · Cifrado en reposo | Cifrado de los almacenes |
| POL-004 · Estándares de cifrado | Política que fija algoritmos y longitudes |
Nota sobre la lectura: la ambigüedad descrita en §1 —clave de datos en memoria frente a clave de datos cifrada— aparece en el procedimiento y en la arquitectura. Ambos se corregirán; el comportamiento real es el descrito en §1.1.
Firma
- Elaborado: Gabriel Ureña Chacón — CTO Fintrix Pay
- Fecha: 2026-08-16