Destokenización: cómo los tokens vuelven a convertirse en PAN de tarjeta

Qué hace realmente la destokenización

La tokenización sustituye un número de tarjeta por una referencia sin sentido: el token. La destokenización es lo contrario: un sistema autorizado le pide a la bóveda de tokens «devuélveme el número de tarjeta real al que apunta este token», y la bóveda devuelve el PAN. Eso es todo. Lo ingenioso no es el canje en sí, es todo lo que lo rodea: quién puede pedirlo, cómo se autentica la solicitud, qué queda registrado y a dónde va el PAN una vez devuelto.

Si la tokenización es la puerta principal para mantener a los comercios fuera del alcance de PCI, la destokenización es la pequeña puerta trasera, fuertemente vigilada, que usan el puñado de sistemas que de verdad necesitan el número de tarjeta real. Si te equivocas, acabas de meter de nuevo todo tu entorno dentro del alcance.

Cuándo tiene que ocurrir realmente la destokenización

La mayoría de los comercios nunca necesitan destokenizar. El sentido de un token es que puedes usarlo para cobros repetidos, reembolsos, facturación recurrente e informes sin volver a ver nunca el PAN. El token vuelve a la pasarela, la pasarela lo resuelve internamente y tú recibes una respuesta de sí o no.

Pero hay unos pocos motivos legítimos por los que el PAN real tiene que volver a salir:

• Cambios de enrutamiento de la red de tarjetas. Algunos adquirentes necesitan el BIN (los seis primeros dígitos) para enrutar una transacción a un esquema concreto o para aplicar reglas a nivel de red.
• Pruebas en contracargos. Las disputas a veces requieren el PAN original para cotejarlo con los registros del emisor, aunque la mayoría de los portales de disputas modernos funcionan con el token o con una versión enmascarada.
• Migración entre procesadores de pago. Si te mueves de una pasarela a otra y la nueva no puede importar los tokens antiguos, necesitarás una destokenización masiva puntual bajo controles estrictos, normalmente una transferencia directa de bóveda a bóveda en lugar de que los PAN toquen tus sistemas.
• Investigaciones de fraude. Un caso forense puede necesitar que la tarjeta subyacente sea visible, pero esto lo gestiona normalmente el adquirente o el esquema de tarjeta, no el comercio.

Cualquier cosa fuera de esa lista merece que la cuestiones. «Necesitamos el PAN para mostrar los últimos 4 dígitos en el panel del cliente»: no, no lo necesitas, la bóveda de tokens devuelve los últimos 4 como metadatos. «Necesitamos enviarle al cliente su número de tarjeta por correo»: ningún comercio debería hacer esto jamás. Si un desarrollador pide acceso a la destokenización, la primera pregunta siempre es «¿por qué?».

Cómo funciona el canje en realidad

Una solicitud de destokenización es una llamada a la API muy acotada. El sistema autorizado envía el token más sus credenciales de autenticación a la bóveda de tokens. La bóveda valida las credenciales, comprueba que ese solicitante tiene permiso para destokenizar, comprueba que ese token concreto pertenece a ese solicitante, busca el PAN en su almacén cifrado y lo devuelve por un canal cifrado con TLS.

La bóveda escribe entonces una entrada en el registro de auditoría: quién lo pidió, cuándo, qué token, desde qué IP y con qué código de motivo. El requisito 10 de PCI DSS v4.0.1 exige que todo acceso a los datos del titular de la tarjeta quede registrado con suficiente detalle como para reconstruir lo que pasó.

El PAN vuelve, se usa para el fin legítimo que fuera y no debería persistir nunca. Mantener el PAN destokenizado en memoria más tiempo del necesario, escribirlo en un log o guardarlo en una base de datos mete al comercio directamente de vuelta en el alcance completo de PCI DSS para ese sistema.

Quién tiene permiso para destokenizar

Esta es la parte que la mayoría de los equipos hace mal. El acceso a la destokenización debería ser el permiso más restringido de tu entorno de pago, más restringido incluso que la capacidad de cobrar un pago. Un modelo razonable:

• Ningún usuario humano puede destokenizar directamente. Ni siquiera un usuario administrador. La bóveda debería rechazar cualquier solicitud de destokenización que no proceda de una cuenta de servicio registrada.
• Las cuentas de servicio tienen un alcance acotado. Cada cuenta de servicio autorizada solo puede destokenizar los tokens que ella creó, o los tokens que tenga asignados explícitamente. Un servicio de informes no puede destokenizar los tokens de un servicio de pagos.
• Lista blanca de IP. Las solicitudes de destokenización solo prosperan desde una lista corta de IP de servidores de producción conocidos. Una solicitud desde el portátil de un desarrollador, un entorno de staging o cualquier otro sitio se rechaza incluso con credenciales válidas.
• Multifactor o solicitudes firmadas. Las propias credenciales deberían ser tokens de corta duración o solicitudes firmadas con HMAC, no una clave de API estática metida en un archivo de configuración.

Y cada destokenización con éxito debería disparar una alerta si está fuera de los patrones esperados: un pico repentino, una solicitud de un servicio que normalmente no hace esto o un volumen que no encaja con el caso de uso legítimo.

Destokenización frente a descifrado: no son lo mismo

Estos conceptos se confunden mucho. El cifrado es una transformación matemática: el texto cifrado contiene el texto en claro, mezclado con una clave. Cualquiera que tenga la clave puede recuperar el texto en claro. No hay registro central; la relación es puramente criptográfica.

La tokenización es una búsqueda. El token no contiene ninguna información sobre el PAN. La única forma de volver al PAN es preguntar a la bóveda, y la bóveda decide si responde. Si alguien roba un token sin entrar también en la bóveda, no tiene nada útil.

Por eso la tokenización suele preferirse al cifrado para los datos de tarjeta almacenados. Una base de datos cifrada robada más una clave robada te dan todos los PAN. Una base de datos tokenizada robada más un acceso robado a la bóveda te dan lo que la bóveda decida entregar, que debería ser nada sin las credenciales correctas del solicitante.

Tokens de red frente a tokens de bóveda

Hay dos tipos principales de token en juego, y se destokenizan de forma distinta.

Los tokens de bóveda (o «tokens de adquirente») los emite el servicio de tokenización de tu procesador de pagos. La destokenización ocurre internamente en ese procesador; tus sistemas nunca ven el PAN, y por lo general no puedes destokenizar desde fuera. Esta es la respuesta correcta para casi cualquier comercio.

Los tokens de red los emiten los propios esquemas de tarjeta (Visa Token Service, Mastercard Digital Enablement Service). Vinculan un token a un comercio concreto y a un dispositivo o relación con el titular concretos. La destokenización ocurre dentro de la infraestructura de la red como parte del flujo de autorización; el comercio no ve el PAN en absoluto. Los tokens de red también se actualizan automáticamente cuando se reemite una tarjeta, lo que resuelve el problema de la facturación recurrente que se rompe.

Errores habituales que ponen en riesgo la destokenización

Tres patrones que vemos salir mal:

Registrar el PAN destokenizado. Un desarrollador añade una línea de log de depuración que incluye la respuesta de la API, la respuesta contiene el PAN, y ahora hay millones de PAN en un agregador de logs que nunca estuvo dentro del alcance de PCI. La solución es enmascarar el PAN del lado de la aplicación antes de cualquier escritura de log, no confiar en que los desarrolladores se acuerden.

Cachear el PAN destokenizado. Un ingeniero nota que llamar a la bóveda en cada transacción es lento, así que añade una caché. Ahora la caché está llena de PAN y la infraestructura de caché está dentro del alcance de PCI. No caches PAN.

Usar la destokenización para algo que el token ya puede hacer. La mayor parte del trabajo de analítica, informes, visualización al cliente y conciliación puede hacerse con el token más los metadatos (últimos 4, BIN, caducidad, marca). Si estás destokenizando para rellenar un panel, has diseñado mal el panel.

Qué dice PCI DSS v4.0.1

PCI DSS trata el acceso a la destokenización como acceso a los datos del titular de la tarjeta. Eso significa que los sistemas que la hacen son CDE (entorno de datos del titular), necesitan todos los controles pertinentes (autenticación fuerte (8.x), registro de auditoría (10.x), segmentación de red (1.x), análisis de vulnerabilidades periódicos (11.x)) y las personas con acceso administrativo entran en el alcance de los requisitos de selección y formación.

La gran implicación práctica: si diseñas tu flujo de pago de forma que la destokenización nunca ocurra dentro de tus sistemas (el procesador la gestiona internamente en cada flujo legítimo), tu alcance se reduce drásticamente. Esta es la razón de ser del enmascaramiento DTMF para pagos telefónicos y de la tokenización del lado del procesador para tarjetas archivadas. Mantén el PAN, y cualquier sistema que pueda recuperarlo, fuera de tu entorno.

El ciclo de vida de la destokenización dentro de una bóveda

Desde el punto de vista de la bóveda, una solicitud de destokenización es una fila en una tabla de decisiones. Entra el token. Se comprueba la identidad del solicitante. Se comprueban los permisos del solicitante sobre ese token concreto. La primera entrada del registro de auditoría se escribe antes incluso de ejecutar la búsqueda. El PAN se descifra del almacén cifrado de la bóveda. La segunda entrada del registro de auditoría se escribe después de la búsqueda, registrando el éxito o el fallo. El PAN vuelve por una conexión TLS con autenticación mutua. La tercera entrada del registro de auditoría se escribe cuando se cierra la conexión.

El PAN descifrado nunca toca el almacenamiento persistente dentro de la bóveda durante la solicitud: se mantiene en memoria mientras dura la respuesta y luego se pone a cero. El material de claves respaldado por HSM de la bóveda vive en un límite de seguridad físico separado, de modo que comprometer por software la aplicación de la bóveda no le da al atacante de inmediato las claves maestras. Esa es la razón arquitectónica por la que las bóvedas bien construidas pueden resistir ataques que vaciarían una base de datos de PAN cifrados.

Cómo se ve en producción «tokeniza y olvida»

La arquitectura de pago más sana es aquella en la que el comercio tokeniza en el momento de la captura y nunca vuelve a pedir el PAN. Todos los flujos posteriores usan el token:

• Compra repetida: envías el token más el nuevo importe; la pasarela lo resuelve internamente.
• Facturación por suscripción: guardas el token en el registro de la suscripción; el trabajo de facturación envía el token más el importe de la renovación.
• Reembolso: envías el ID de la transacción original o el token más el importe del reembolso; la pasarela lo enruta a la tarjeta original.
• Recibo e informes: muestras la marca y los últimos cuatro dígitos a partir de los metadatos del token, que la bóveda devuelve como campos no sensibles.
• Conciliación: cotejas los registros de liquidación con el token o con el ID de transacción de la pasarela; no hace falta ningún PAN.

Un comercio que construye así elimina en la práctica la destokenización de su operativa diaria. La bóveda la sigue haciendo internamente durante el enrutamiento de la autorización, pero eso ocurre dentro del propio alcance del procesador, no dentro del del comercio.

Destokenización masiva durante las migraciones de procesador

Las migraciones de procesador son el único momento en que la mayoría de los comercios se ven forzados a enfrentarse a la destokenización en volumen. El conjunto de tokens acumulado durante años con el procesador saliente no le sirve de nada al procesador entrante: los tokens son específicos de cada bóveda. El comercio tiene que llevar los PAN subyacentes a la bóveda del nuevo procesador y volver a tokenizarlos bajo la nueva relación.

Bien hecho, esto ocurre como una transferencia de bóveda a bóveda, a menudo bajo un acuerdo tripartito. El comercio firma la documentación que autoriza el movimiento de datos. El procesador saliente exporta un lote (normalmente un archivo comprimido y cifrado) y lo transfiere bajo TLS o mediante intercambio seguro de archivos directamente al procesador entrante. Los PAN nunca aterrizan en un sistema controlado por el comercio. El procesador entrante tokeniza todo bajo su propio esquema y devuelve una correspondencia de token antiguo a token nuevo, que el comercio usa para actualizar su base de datos. Los PAN tocan el entorno del comercio durante cero segundos.

Mal hecho, la migración se convierte en un ejercicio de SFTP y hoja de cálculo en el que alguien se baja un CSV de PAN al portátil de un ingeniero «solo por hoy». Eso es un evento de alcance completo de PCI DSS para cada sistema que tocó el archivo, más un probable informe de incidente. La respuesta correcta es insistir en la vía de bóveda a bóveda aunque añada dos semanas al plan de proyecto.

El rastro de auditoría que espera PCI DSS

El requisito 10 de PCI DSS exige que todo acceso a los datos del titular de la tarjeta quede registrado. Para la destokenización eso significa cada solicitud individual, no recuentos agregados. La entrada del registro de auditoría debería capturar, como mínimo, la identidad de la cuenta de servicio del solicitante, la IP de origen, la marca de tiempo, el token referenciado (a veces solo una referencia con hash), el éxito o el fallo de la solicitud y un código de motivo si se le exige al solicitante facilitar uno.

Los logs van a un almacén resistente a manipulaciones con acceso de escritura restringido. Se revisan con regularidad: el requisito 10.4 establece procesos de revisión automatizados. Y se conservan durante al menos 12 meses, con al menos tres meses de logs disponibles para análisis inmediato. Un QSA que evalúe la bóveda tomará una muestra de estos logs y trazará entradas concretas a lo largo del flujo de procesamiento para confirmar que la cadena de auditoría se sostiene de principio a fin.

Destokenización frente a cifrado que preserva el formato

Algunos comercios confunden la tokenización con el cifrado que preserva el formato (FPE). El FPE produce una salida con la misma forma que la entrada: un texto cifrado de 16 dígitos que parece un número de tarjeta, una caducidad que parece una caducidad. Es un punto intermedio tentador para sistemas heredados que esperan un valor con forma de PAN.

El problema es que el FPE sigue siendo cifrado. La relación entre el texto cifrado y el texto en claro es matemática. Cualquiera que tenga la clave puede revertirla. Y bajo PCI DSS, cualquier sistema que contenga un texto cifrado FPE está dentro del alcance de las reglas de protección del almacenamiento, porque ese texto cifrado sigue siendo datos del titular de la tarjeta. La tokenización, en cambio, sustituye el PAN por un valor que no tiene relación matemática con él: incluso con pleno conocimiento del algoritmo, no puedes revertir el token, solo puedes preguntar a la bóveda. Por eso el FPE normalmente no reduce el alcance como sí lo hace la tokenización, aunque el comportamiento de superficie parezca similar.

Las preguntas que vale la pena hacerle a tu procesador

Si estás eligiendo un proveedor de tokenización (normalmente como parte de elegir un procesador de pagos), hay una lista corta de preguntas cuyas respuestas determinan cuánto riesgo de destokenización estás asumiendo:

• ¿Tus tokens pueden destokenizarse mediante una llamada a la API desde mis sistemas, o solo internamente durante un flujo de pago que tú controlas?
• ¿Qué controles rigen el acceso a la destokenización: cuentas de servicio, lista blanca de IP, solicitudes firmadas, códigos de motivo de la solicitud?
• ¿Qué registro de auditoría puedo ver de la actividad de destokenización contra mis tokens?
• ¿Hay tokens de red disponibles y, en ese caso, para qué esquemas y rangos de BIN?
• ¿Cuál es el plan de migración si algún día os dejo: transferencia directa de bóveda a bóveda al siguiente procesador, o acabamos con un problema de PAN en un CSV?

La respuesta de «sin destokenización invocable por el comercio» es la más fuerte: significa que tu alcance está limitado por lo que el procesador hace en tu nombre, no por la disciplina de tus propios desarrolladores.