Los datos de prueba PCI DSS son, casi por definición, datos que no pertenecen a nadie. Existe una intuición muy extendida según la cual las normas de seguridad de datos de pago se aplican a producción y dejan en paz el entorno de pruebas. Es justo al contrario. Si en un servidor de staging hay números de tarjeta que pertenecen a personas reales, ese entorno entra en el alcance, con sus copias de seguridad, sus volcados y su red. La etiqueta pruebas no cambia nada para un auditor. Esta guía explica qué exige la norma, qué alternativas admite y cómo evitar que el entorno de desarrollo se convierta en el eslabón débil.
¿Cuándo entra el entorno de pruebas en el alcance?
El origen del problema casi siempre es el mismo: alguien restaura un volcado de producción en un entorno de desarrollo para que los datos parezcan de verdad. A partir de ese momento, el número de sistemas que tocan datos de tarjeta se multiplica. El volcado, la máquina donde se descargó, el servidor que lo importó, la copia de seguridad nocturna, la herramienta que recoge los registros y, muy probablemente, el portátil de alguien.
La norma no distingue por entorno, distingue por datos. Si los datos son de titulares reales, se aplican los mismos requisitos aunque nadie vaya a cobrar nada con ellos. Por eso la conversación útil no es si el entorno entra en el alcance, sino qué datos hay ahí y de dónde salieron.
Qué exige la norma con los datos guardados
La versión principal vigente del estándar es la 4.x. Para este tema, sus reglas se pueden resumir en dos familias de datos.
La primera son los datos de autenticación sensibles: el código de seguridad impreso en la tarjeta y los datos completos de la banda magnética o del chip. Estos no se almacenan después de autorizar la operación. No hay matiz de cifrado ni de plazo corto: no se guardan, y punto. Es la razón por la que un formulario no puede ofrecer guardar el código para el próximo pago y por la que ningún registro de la aplicación debería contener ese valor.
La segunda son los datos de cuenta, encabezados por el número de tarjeta. Aquí sí se permite el almacenamiento, pero con dos condiciones: el dato debe estar protegido mediante cifrado u otra medida equivalente, y cuando se muestra debe aparecer enmascarado, dejando visibles como máximo los seis primeros dígitos y los cuatro últimos. Todo lo intermedio queda oculto.
El texto autorizado es el que publica el organismo que mantiene el estándar, y cualquier resumen, incluido este, es una aproximación que no sustituye al documento oficial.
Enmascarar, tokenizar y separar entornos
Enmascarar es útil y no es suficiente. Un número parcialmente oculto sigue siendo un dato de cuenta, así que no reduce el alcance por sí solo: reduce lo que se ve en pantalla y en las capturas de soporte, que tampoco es poco.
La tokenización sí cambia el panorama. Consiste en sustituir el número por una referencia que emite el proveedor de pagos. Esa referencia solo tiene significado dentro del sistema del proveedor y no se puede usar en otro sitio; si la aplicación únicamente guarda referencias, deja de manejar números de tarjeta y buena parte de los requisitos desaparece del entorno.
Existe además el modelo de cámara segura, en el que los números cifrados viven en un repositorio central con acceso muy restringido y el resto de los sistemas solo manejan referencias. Es una arquitectura más pesada, propia de organizaciones que necesitan conservar el número para cobros recurrentes.
Hay una tercera medida que no depende de la arquitectura: separar entornos de verdad. Claves distintas, redes distintas y permisos distintos. Una clave de producción en un entorno de pruebas se descubre tarde y por el peor camino posible.
Cómo se construyen datos sintéticos decentes
La conclusión práctica del estándar es incómoda para quien trabaja con prisa: no es aceptable utilizar datos reales de titulares en desarrollo ni en pruebas. La alternativa admitida es doble: tokenizar, cuando ya existe un proveedor en el flujo, o generar datos sintéticos.
Un conjunto sintético decente cumple cuatro condiciones:
- Coherente con el formato de cada marca, para que los validadores no rechacen lo que debería pasar.
- Con la suma de control correcta, cuando el sistema la exige.
- Sin pertenecer a ninguna cuenta, ni siquiera por casualidad.
- Reproducible, de modo que un fallo encontrado hoy se pueda repetir mañana con la misma entrada.
El generador de este sitio está hecho para esa cuarta tarea: produce números con estructura válida y nunca emitidos para la marca que le pidas, y puedes fijar el lote para que la prueba sea determinista. Son cadenas correctas para el formulario, no credenciales de pago, y eso es exactamente lo que necesita un entorno de desarrollo.
¿Se pueden usar datos reales si están cifrados?
Es una pregunta razonable y la respuesta corta es que el estándar no lo plantea como una vía de escape. Cifrar un dato de titular real no lo convierte en sintético: sigue siendo información de una persona, sigue ampliando el alcance del entorno y sigue exigiendo los mismos controles que en producción. La única forma de que un dato deje de ser sensible es que no provenga de una persona.
En la práctica, la mayoría de los equipos que preguntan esto no necesitan el dato real. Necesitan que el número parezca de verdad, y eso lo consiguen con un valor sintético que respete el formato. La excepción legítima son los flujos de soporte que deben reproducir un incidente concreto, y para eso la respuesta correcta no es copiar el número, sino trabajar con la referencia del proveedor y los registros del sistema.
Para quien programa
Cumplir con los datos de prueba es menos una tarea de auditoría que una serie de decisiones de ingeniería. Estas son las que más diferencia marcan.
- Depura en el mismo paso. Si un entorno de pruebas recibe datos de producción, el proceso debe sustituir los números por valores sintéticos en el momento de la importación, no en una tarea posterior que quizá nadie ejecute.
- Valida la forma de los datos sintéticos. Un número que no pasa la suma de control hará fallar las pruebas por un motivo falso. Añade una comprobación que verifique el formato antes de cargar el lote.
- Vigila el patrón. Un analizador que busque secuencias compatibles con un número de tarjeta en los registros detecta el error la primera vez, no la vigésima.
- Da una vía de escape al equipo. Quien encuentra un número real en un ticket o en un chat necesita una forma sencilla de reportarlo sin copiarlo otra vez al informe.
- Revisa los accesos por entorno. Un entorno con datos enmascarados no necesita el mismo público que uno con datos reales, y casi siempre tiene más del que debería.
- Documenta el origen del lote. Un archivo de datos de prueba sin fecha ni procedencia acaba generando dudas en la siguiente auditoría.
El hilo común de todos estos puntos es el mismo: que sea fácil hacer lo correcto y difícil hacer lo cómodo.
Siguientes pasos
Si lo que necesitas ahora son datos para trabajar, empieza por el generador: produce lotes estructuralmente correctos y nunca emitidos, listos para un entorno de desarrollo. Para entender por qué el código de seguridad no se puede conservar, el artículo sobre qué es el CVV lo explica sin rodeos, y el de formato del número de tarjeta detalla las reglas de enmascarado al mostrar. Si el objetivo es diseñar la integración completa, la lista de comprobación del formulario de pago ordena los casos de extremo a extremo.