Cuando una compañía aborda el proyecto de cumplimiento PCI DSS la primera tarea será determinar y delimitar el alcance del ámbito de aplicación, en palabras del estándar, definir cuál será el entorno de datos de cuenta CDE (Cardholder data environment, por sus siglas en inglés). La mejor manera de reducir el ámbito de aplicación de PCI DSS sobre sistemas que procesen, almacenen o transmitan datos de tarjeta, resulta bastante elemental: no usar datos de tarjeta, pero esto no siempre es posible.
En caso de ser necesario el almacenamiento del número de cuenta principal PAN (Primary Account Number, por sus siglas en inglés) esté deberá estar protegido donde sea que se almacene (requisito 3.5.1 del estándar PCI DSS 4.0.1), PCI DSS establece los siguientes cuatro métodos para garantizar que los datos PAN permanezcan ilegibles:
- Hashes unidireccionales basados en criptografía sólida del PAN completo.
- Truncamiento
- Índice de tokens.
- Criptografía robusta con procesos y procedimientos de gestión de claves
asociados.
Partiendo del dato de tarjeta ejemplo mostrado a continuación, revisaremos cada uno de los métodos y los resultados obtenidos al aplicarlos:
Son funciones criptográficas utilizados para proteger datos sensibles, como los datos de tarjetas de crédito, convirtiéndolos en una cadena de longitud fija que no puede revertirse a su forma original de manera práctica, es decir, no se puede obtener el valor original desde el hash, cualquier pequeño cambio en el valor de entrada genera un hash completamente diferente.
Para elegir algoritmos de hashing adecuados en estas implementaciones es importante basarse en estándares aceptados por la industria como NIST SP 800-107 (Revisión 1).
Ejemplo de hashing (one-way hash):
Truncamiento:
Consiste en eliminar o reemplazar parte del número de la tarjeta de forma que no se almacene el número completo y, por tanto, no pueda ser usado maliciosamente si es capturado. Es importante indicar que los hashes no pueden utilizarse para reemplazar el segmento truncado del PAN. A diferencia de métodos como la criptografía robusta que oculta el PAN, pero permite su recuperación con la clave, o la tokenización, que lo reemplaza por un valor que se mapea al PAN completo en otro lugar, el truncamiento implica la eliminación definitiva de segmentos de datos del PAN en su almacenamiento, haciendo imposible su recuperación.
Ejemplo de Truncamiento:
Índice de tokens (Tokenización):
Es una técnica de seguridad que busca reemplazar la información sensible de la tarjeta (especialmente el Número de Cuenta Principal o PAN) por un valor no sensible, llamado token, el cual no tiene ningún valor intrínseco ni relación matemática con los datos originales, lo que lo hace inútil para un atacante en caso de una brecha de seguridad.
Ejemplo de Tokenización:
Criptografía robusta con procesos y procedimientos de gestión de claves asociados.
Consiste en implementar un cifrado con algoritmos modernos y seguros, claves lo suficientemente largas, y un proceso estricto y seguro para gestionar esas claves, haciendo que los datos de la tarjeta sean inútiles para cualquier persona no autorizada, cuestión fundamental para proteger a los titulares de tarjetas de potenciales fraudes.
Una guía aceptada por la industria en la elección de algoritmos y mecanismos criptográficos son aceptables lo otorga el NIST en su documento NIST SP 800-175B (Revisión 1). Es preciso recordar que un algoritmo fuerte no sirve de nada si las claves son débiles o están comprometidas, en caso de requerir mayor detalle sobre cómo gestionar las claves criptográficas, el documento NIST SP 800-57 Part 1 (Revision 5) brinda los detalles.
Ejemplo de cifrado robusto:
Si se tiene una necesidad de negocio de almacenar el dato de tarjeta completo para utilizarlo en procesos posteriores, por ejemplo, pagos recurrentes, suscripciones, la organización se integra con múltiples pasarelas de pago o reportes a entes de control, se deberá elegir el método de cifrado o de tokenización, pero si PCI DSS me brinda cuatro opciones, ¿por qué no hacer uso de hashing o de truncamiento? La respuesta es simple, esto últimos dos métodos mencionados proporcionan una protección irreversible de los datos, partiendo del hash o del dato truncado de la tarjeta nunca se podrá obtener el PAN completo, por tanto, no se cumpliría con la necesidad de negocio.
Retornando a la necesidad de almacenar el dato de tarjeta completo para utilizarlo en procesos posteriores nos queda decidir entre los dos métodos: criptografía robusta de datos de tarjeta o tokenización de los mismos.
¿Cuál camino escoger?, ¿Qué es mejor?
La criptografía robusta puede ser beneficioso cuando:
▪️Se tienen aplicaciones de muy alto volumen transaccional, el cifrado/descifradolocal puede ser más eficiente que las llamadas a un servicio de tokenización.
▪️Se necesita mantener control directo sobre tus datos y procesos de seguridad, en
contraparte las organizaciones deberán contar con equipos y procesos de
seguridad maduros.
▪️Se requiere integración con sistemas legacy y estos pueden adaptarse más
fácilmente al cifrado que a la implementación de llamadas a servicios de
tokenización.
Por su parte la tokenización generalmente ofrece mayores beneficios en términos de:
▪️Reducción del alcance de PCI DSS, la tokenización es superior cuando el objetivoprincipal es minimizar el perímetro de cumplimiento. Al reemplazar los datos del
titular de la tarjeta (CHD – Cardholder data) con tokens, los sistemas que manejan
tokens quedan fuera del alcance de PCI DSS, siempre que estos estén fuera de la
red del CDE.
▪️Mitigación de riesgos, en caso de una brecha de seguridad, los atacantes solo
obtendrían tokens sin valor comercial fuera del sistema.
▪️Cuando se tienen múltiples aplicaciones o sistemas que necesitan referenciar los
mismos datos de tarjetas, la tokenización permite que estos sistemas trabajen con
tokens mientras mantienes los datos sensibles centralizados en un solo sistema
seguro.
▪️Reducción de cumplimiento cuando se contrata un proveedor de servicio de
tokenización (certificado en PCI DSS, obviamente) para que este se encargue de
todo el proceso de captura de datos de tarjeta (PAN) y todos los procesos
asociados al uso de este.
Tokenización
Ya que vimos los beneficios de la tokenización en un ambiente con datos de tarjeta veamos ahora las diferentes implementaciones que se pueden realizar y sus principales características:
Tokenización con Bóveda (Vault-Based Tokenization)
La tokenización de bóveda se refiere al proceso de almacenamiento de datos confidenciales en una bóveda segura, donde se cifra y se reemplaza con un token. Este token actúa como una referencia a los datos originales, pero no revela ninguna información confidencial. La bóveda se convierte en el punto central para administrar y controlar el acceso a datos confidenciales. Es el método más tradicional, en este sistema, el PAN se almacena en una base de datos altamente segura llamada "bóveda de tokens" o token vault.
Funcionamiento:
Cuando se recibe el número de tarjeta real, el servicio de tokenización genera un token único (generalmente alfanumérico). El dato de tarjeta real se almacena cifrado con criptografía fuerte en la bóveda junto con su token correspondiente. Solo el token circula por los sistemas de la organización
Para procesar pagos, se consulta la bóveda para obtener el dato de tarjeta real.
Ventajas:
▪️Máximo nivel de seguridad al centralizar los datos sensibles.
▪️Control total sobre el proceso de tokenización.
▪️Cumplimiento más sencillo con estándares PCI DSS.
▪️Tokens reversibles cuando sea necesario.
Desventajas:
▪️Requiere infraestructura robusta y costosa, puede requerir infraestructura adicional
de hardware y software para garantizar un almacenamiento y acceso seguros.
▪️La bóveda se convierte en un punto único de falla.
▪️Mayor complejidad operativa.
▪️Responsabilidad total sobre la seguridad de los datos.
Tokenización sin Bóveda (Vaultless Tokenization)
También conocido como tokenización criptográfica, no requiere una bóveda de tokenización para almacenar datos. En cambio, utiliza dispositivos criptográficos seguros para reemplazar datos confidenciales con un token único. Este método a menudo se considera más eficiente y seguro debido a la ausencia de una base de datos o bóveda que puede verse comprometida. Con la tokenización sin bóveda, los datos confidenciales nunca se almacenan, y solo el token único se utiliza con fines de identificación o recuperación. Esto elimina el riesgo de una violación de datos o acceso no autorizado a información confidencial.
Funcionamiento:
Se utiliza un algoritmo criptográfico (como AES) con una clave secreta, el número de tarjeta se cifra usando esta clave para generar el token, como no se hace almacenamiento en ninguna base de datos de correspondencia para poder recuperar el número de tarjeta original, se debe descifrar el token con la misma clave utilizada en el proceso de cifrado.
Es por esto por lo que en este tipo de entornos se hace necesario comprender el papel determinante que juegan los dispositivos criptográficos en la tokenización sin bóveda, estos dispositivos criptográficos utilizan algoritmos basados en estándares para convertir datos confidenciales en datos o tokens no sensibles.
Ventajas:
▪️Conserva el formato de datos, la naturaleza conservadora del formato de la
tokenización sin bóveda lo hace adecuado para aplicaciones que requieren que se
conserve el formato de datos original, como bases de datos o sistemas heredados.
▪️No hay base de datos que proteger o que pueda ser comprometida
▪️Menor infraestructura requerida
▪️Escalabilidad más sencilla
▪️Menor costo operativo.
Desventajas:
▪️La seguridad depende completamente de la protección de las claves criptográficas
▪️Si se compromete la clave, todos los tokens quedan expuestos
▪️Menos flexibilidad en el formato de los tokens
▪️Puede ser más complejo implementar rotación de claves
Tokenización sin bóveda en ambientes en la nube
La tokenización sin bóveda se soporta en el algoritmo FPE (Format-Preserving Encryption) el cual es un método especializado de cifrado que mantiene el formato de los datos originales después de la encriptación. En un proceso de tokenización, FPE juega un papel crucial, ya que es quien proporciona:
▪️Preservación del formato: Conserva la longitud y estructura de los datos originales.
Por ejemplo, un número de tarjeta de crédito de 16 dígitos seguirá siendo un
número de 16 dígitos después del cifrado.
▪️Reversibilidad: A diferencia de la tokenización tradicional que utiliza tablas de
mapeo, FPE permite la reversión determinista mediante una clave criptográfica.
▪️Seguridad: Proporciona un alto nivel de seguridad criptográfica mientras mantiene
la utilidad de los datos.
El FPE utiliza estándares comunes, los algoritmos FPE más utilizados son:
▪️FF1 (NIST SP 800-38G)
▪️FF3 (versión revisada)
Si una organización está planteando implementar tokenización sin bóveda (vaultless tokenization) y su infraestructura tecnológica está soportada en infraestructuras de nubes públicas, es importante indicar que cada proveedor ofrece servicios específicos de gestión de claves y cifrado, que pueden facilitar estos procesos de implementación.
A continuación, se muestra una tabla de los servicios específicos con los que cuentan los principales proveedores de servicios en la nube para implementar tokenización sin bóveda.
| Componente | AWS | Microsoft Azure | Google Cloud Platform |
| Gestión de Claves Criptográficas | AWS Key Management Service (KMS) | Azure Key Vault | Cloud Key Management Service (Cloud KMS) |
| Gestión de Secretos | AWS Secrets Manager | Azure Key Vault | Secret Manager |
| Almacenamiento de Parámetros | AWS Systems Manager Parameter Store | Azure App Configuration | Cloud Runtime Configuration API |
| Funciones Serverless | AWS Lambda | Azure Functions | Cloud Functions |
| Gestión de APIs | Amazon API Gateway | Azure API Management | Cloud Endpoints |
| Autenticación y Autorización | AWS IAM | Azure Entra ID | Identity and Access Management (IAM) |
| Auditoría y Logging | AWS CloudTrail | Azure Monitor / Azure Audit Logs | Cloud Audit Logs |
| Monitoreo y Métricas | Amazon CloudWatch | Azure Monitor | Cloud Monitoring |
| Red y Seguridad | AWS VPC / Security Groups | Azure Virtual Network / NSG | VPC / Firewall Rules |
| Base de Datos (si se requiere) | Amazon DynamoDB / RDS | Azure Cosmos DB / SQL Database | Cloud Firestore / Cloud SQL |
Los roles de los componentes descritos en un ambiente de tokenización sin bóveda serían:
▪️Gestión de Claves Criptográficas: Se encarga de generar, almacenar y rotar las
claves maestras utilizadas para los algoritmos de tokenización. Es el componente
más crítico ya que protege la clave que permite generar tokens de forma
determinística.
▪️Gestión de Secretos: Almacena credenciales, tokens de acceso y otros secretos
necesarios para la comunicación entre servicios. Permite rotación automática y
acceso controlado a información sensible.
▪️Almacenamiento de Parámetros: Guarda configuraciones de la aplicación como
algoritmos de tokenización a usar, políticas de formato de tokens, y parámetros
operacionales no sensibles.
▪️Funciones Serverless: Ejecutan la lógica de tokenización y destokenización.
Procesan las solicitudes aplicando los algoritmos criptográficos usando las claves
del KMS, sin mantener estado entre invocaciones.
▪️Gestión de APIs: Expone los endpoints de tokenización/destokenización de forma
segura. Maneja autenticación, autorización, rate limiting (evita el uso excesivo de la
API) y transformación de mensajes.
▪️Autenticación y Autorización: Controla quién puede acceder a los servicios de
tokenización y qué operaciones puede realizar. Implementa políticas de acceso
granulares y multi-factor authentication.
▪️Auditoría y Logging: Registra todas las operaciones de tokenización para
cumplimiento normativo. Captura quién, cuándo, dónde y qué datos fueron
tokenizados o destokenizados.
▪️Monitoreo y Métricas: Supervisa el rendimiento, disponibilidad y salud del sistema.
Detecta anomalías, latencias altas y posibles intentos de ataque.
▪️Red y Seguridad: Aísla el tráfico de tokenización en redes privadas virtuales.
Implementa firewalls y controles de acceso a nivel de red para proteger los
componentes.
▪️Base de Datos (opcional): En tokenización sin bóveda, se usa mínimamente para
logs de auditoría, configuraciones o metadatos, pero nunca para almacenar
mapeos token-valor.
Cada componente trabaja en conjunto para crear un ecosistema seguro donde los datos sensibles se pueden tokenizar sin mantener una base de datos de mapeos, utilizando algoritmos determinísticos basados en claves criptográficas.
Conclusiones
La tokenización puede reducir el ámbito de aplicación de PCI DSS, ya que los sistemas que almacenan tokens en lugar de datos reales de tarjetas quedan fuera de los requisitos de PCI DSS, pero dependerá en gran medida en realizar un aislamiento correcto de los flujos con datos de tarjeta en todos los componentes del entorno de la mano del QSA.
Es crucial entender que, aunque la tokenización reduce el alcance PCI DSS, no elimina completamente las responsabilidades de cumplimiento. Las organizaciones aún deben proteger el proceso de captura inicial de datos yasegurar que sus sistemas de tokenización cumplan con los estándares deseguridad apropiados.
Cuando se utiliza tokenización en la nube todo el sistema depende completamente del servicio de gestión de claves del proveedor de nube. Si el KMS falla o se compromete, toda la solución se ve afectada. No debemos olvidar el modelo de responsabilidad compartida, la responsabilidad final de la configuración segura, gestión de accesos y la correcta implementación de algoritmos recae en la organización cliente.
Referencias:
🔗 Directrices de Seguridad de Productos con Token PCI SCC
https://www.pcisecuritystandards.org/documents/Tokenization_Product_Security_Guidelines.pdf
🔗 Tokenization Product Security Guidelines
https://docs-prv.pcisecuritystandards.org/Guidance%20Document/Tokenization/Tokenization_Product_Security_Guidelines.pdf
🔗 Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, versión 4.0.1, marzo 2022.
🔗 NIST SP 800-107r1 Recommendation for Applications Using Approved Hash Algorithms
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-107r1.pdf
🔗 NIST SP 175Br1 Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms (Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms).
🔗 NIST SP 800-57 Part 1 r5 Recommendation for Key Management: Part 1 – General (Recommendation for Key Management: Part 1 - General).
