Cumplimiento PCI DSS en sistemas de transferencia segura

PCI DSS 4.0 (obligatorio desde el 31 de marzo de 2025) impone 12 requisitos a cualquier sistema que almacene, procese o transmita datos de titulares de tarjetas. Para sistemas de transferencia de archivos, los controles clave son el Requisito 3 (proteger los datos de cuenta almacenados mediante AES-256 o mayor con gestión adecuada de claves), el Requisito 4 (cifrar la transmisión con TLS 1.2 como mínimo, recomendado TLS 1.3), el Requisito 8 (MFA para todo acceso al entorno de datos de titulares), el Requisito 10 (registrar cada acceso al CDE durante al menos 12 meses) y el Requisito 12 (gobernanza y gestión de proveedores de servicios). Un sistema de transferencia que toque un solo .csv con PANs está en el alcance del estándar completo.

Qué activa el alcance PCI DSS

PCI DSS se aplica a cualquier componente de sistema que procese, almacene o transmita datos de titulares de tarjetas (CHD) o datos de autenticación sensibles (SAD). CHD es el número de cuenta principal (PAN), nombre del titular, fecha de vencimiento y código de servicio. SAD son el CVV, los datos completos de la banda magnética y los PINs; nunca se almacenan tras la autorización. Una herramienta de transferencia que recibe una hoja de cálculo de PANs de un banco asociado está en alcance. Una herramienta para enviar un informe resumen con solo los últimos cuatro dígitos no lo está. Los PANs tokenizados o truncados (primeros seis + últimos cuatro como máximo) quedan fuera del alcance. La reducción de alcance es la actividad PCI con mayor retorno de inversión: tokeniza en el punto más temprano posible.

Cambios relevantes de PCI DSS 4.0

La versión 4.0 (publicada en marzo de 2022, obligatoria en abril de 2024 con requisitos de fecha futura hasta marzo de 2025) introdujo: enfoque personalizado (alternativa al enfoque definido, requiere un análisis de riesgo específico), requisitos revisados de MFA extendidos a todo acceso al CDE (no solo administradores), reglas de contraseñas más estrictas (12+ caracteres desde enero de 2025 bajo 8.3.6), mayor frecuencia en muchas tareas (análisis trimestrales, pruebas de penetración anuales) y requisitos explícitos para páginas de pago del lado del cliente (6.4.3 y 11.6.1 para detección de skimming). Los sistemas de transferencia notan más 8.3.6 y el Requisito 10: autenticación más estricta y registro.

Requisito 3: proteger los PANs almacenados

El Requisito 3 prohíbe almacenar SAD tras la autorización y exige protección sólida para los PANs almacenados. Métodos aceptables: hashes unidireccionales con salt fuerte (SHA-256 con salt por PAN de 128+ bits), truncamiento (no más de los primeros seis y últimos cuatro dígitos), tokens de índice con almohadillas guardadas de forma segura, o cifrado fuerte con gestión de claves asociada. Para sistemas de transferencia, el enfoque más limpio es la tokenización antes de que el archivo entre en el pipeline de transferencia, usando un servicio de tokenización certificado PCI (Braintree, Stripe Radar, VGS) y transfiriendo solo tokens. Si los PANs deben transitar en texto plano, usa AES-256-GCM con claves en un HSM con nivel FIPS 140-2 Level 2+.

Requisito 4: cifrado de transmisión

4.2.1 exige criptografía sólida para la transmisión de PANs sobre redes abiertas y públicas. "Criptografía sólida" según el glosario PCI hace referencia a NIST SP 800-57: AES-256 para simétrico, RSA 3072+ para asimétrico, TLS 1.2+ para transporte. Deshabilita TLS 1.0 y 1.1 por completo (fueron desaconsejados en 2018 y prohibidos por 4.0). Usa SSL Labs o Qualys SSL Test para verificar la configuración trimestralmente. El correo electrónico es explícitamente problemático: 4.2.2 exige que los PANs enviados por tecnologías de mensajería de usuario final se vuelvan ilegibles antes de la transmisión. Un PAN en texto plano en un email falla PCI. Envía en su lugar un enlace seguro a una descarga cifrada.

Requisito 8: MFA en todo el CDE

8.4 y 8.5 en PCI DSS 4.0 exigen MFA para (a) todo acceso no consola al CDE por personal administrativo y (b) todo acceso remoto al CDE por cualquier personal. "Todo" es la palabra clave respecto a versiones anteriores: contratistas, auditores, usuarios de soporte, no solo administradores. Factores MFA aceptables: algo que sabes (contraseña), algo que tienes (token de hardware, app de móvil), algo que eres (biométrico). Los dos factores deben ser independientes; dos contraseñas no cuentan. Las llaves de hardware (YubiKey, Feitian) con FIDO2 satisfacen 8.5 de manera limpia. El OTP por SMS no se recomienda: NIST SP 800-63B redujo su nivel de garantía en 2016.

Requisito 10: registro y retención de 12 meses

10.2 exige registros de auditoría que capturen: acceso individual de usuarios a CHD, acciones de usuarios con privilegios administrativos, acceso a registros de auditoría, intentos de acceso lógico inválidos, mecanismos de identificación y autenticación, inicialización de registros de auditoría, y creación y eliminación de objetos a nivel de sistema. 10.5.1 exige retención de al menos 12 meses con tres meses de disponibilidad inmediata. 10.7 añadió requisitos para detectar y responder a fallos críticos de controles de seguridad en 24 horas. Para sistemas de transferencia del CDE, usa un almacén de logs inmutable: AWS CloudWatch Logs con CloudTrail, Azure Monitor con políticas inmutables, o Splunk con configuración write-once a nivel de indexador.

Requisito 12: gobernanza de proveedores de servicios

12.8 regula la gestión de proveedores de servicios. Mantén una lista de proveedores con descripción de servicios y alcance PCI DSS, un acuerdo escrito con cada uno reconociendo su responsabilidad sobre la seguridad del CHD, documentación de qué requisitos PCI gestiona cada uno, y monitorización anual del estado de cumplimiento del proveedor. Para proveedores de transferencia de archivos, solicita su Attestation of Compliance (AOC) de PCI DSS. Niveles: los proveedores de Nivel 1 (que almacenan/procesan/transmiten 300.000+ transacciones/año) se someten a evaluaciones anuales in situ; los más pequeños pueden autoevaluarse. Los grandes proveedores de transferencia en el espacio de pagos (Globalscape EFT, IBM Sterling) tienen AOCs de Nivel 1.

Reducción de alcance mediante cifrado del lado del cliente

Si tu proveedor de transferencia nunca ve los PANs en texto plano porque el cifrado ocurre en el cliente antes de la carga, el proveedor puede quedar fuera del alcance PCI. La orientación del PCI SSC sobre esto es matizada: las Directrices de Cloud Computing del PCI SSC (2019) reconocen la reducción de alcance mediante cifrado siempre que (a) el proveedor cloud no tenga acceso a las claves, (b) el cliente conserve demostrablemente la custodia de las claves y (c) la criptografía sea sólida. Servicios con arquitectura AES-256-GCM del lado del cliente, como HexaTransfer, pueden actuar como canales de transferencia fuera del alcance del CDE del comerciante si se despliegan correctamente. Documenta la arquitectura en tu System of Record.

Pruebas de penetración y gestión de vulnerabilidades

11.4 exige pruebas de penetración anuales y tras cambios significativos. Para sistemas de transferencia, el alcance de la prueba incluye: los endpoints de carga y descarga, el flujo de autenticación, el segmento de red del CDE y cualquier API usada para operaciones con archivos. Contrata un evaluador certificado CREST o aprobado por PCI. 11.3 exige análisis de vulnerabilidades trimestrales por un Approved Scanning Vendor (ASV) para componentes externos. Los análisis internos se realizan de forma trimestral. Remedia hallazgos críticos y altos en 30 días; los de menor severidad según tu análisis de riesgo.

Segmentación de red y el perímetro del CDE

La segmentación de red aísla el CDE de las redes no-CDE, reduciendo el alcance. La segmentación debe verificarse anualmente (11.4.5) con pruebas que muestren que el aislamiento funciona ante fallos. Para un sistema de transferencia que maneja PANs, segmenta el pipeline de carga, el almacén de objetos cifrados, los endpoints de KMS y el pipeline de registro en una VPC dedicada sin conectividad este-oeste con redes corporativas generales. Usa subredes privadas, grupos de seguridad con denegación por defecto y endpoints VPC hacia servicios cloud. Documenta la segmentación en diagramas de red como parte de tus evidencias PCI.

Controles compensatorios y el enfoque personalizado

El enfoque personalizado de PCI DSS 4.0 permite controles alternativos si satisfacen el objetivo de un requisito estándar. Requiere un análisis de riesgo específico (TRA) que documente el riesgo, el control personalizado, cómo cumple el objetivo y cómo se prueba. Para sistemas de transferencia, el enfoque personalizado suele aparecer en torno a la gestión de claves criptográficas: una organización podría usar una configuración de HSM no estándar con seguridad equivalente. El enfoque personalizado necesita el visto bueno del QSA; no es un ejercicio de bricolaje. El enfoque definido es más sencillo; usa el personalizado solo donde el definido no se adapta a la tecnología.

Prepararse para la evaluación

Una evaluación QSA para un sistema de transferencia implica: entrevistas de alcance (1-2 días), muestreo de evidencias (2-3 semanas), entrevistas con propietarios de controles (3-5 días), pruebas técnicas (1 semana) y redacción del informe (2-4 semanas). Aporta: diagramas de red, diagramas de flujo de datos, inventario de sistemas del CDE, muestras de revisiones de acceso, informes de análisis trimestrales, informe de pentest anual, procedimientos de gestión de claves, plan de respuesta a incidentes con evidencias de pruebas, y lista de proveedores con AOCs. Presupuesta entre 50.000 € y 150.000 € para el compromiso con el QSA.

El cumplimiento PCI en la capa de transferencia se reduce principalmente a reducción de alcance más buenas prácticas de criptografía. Tokeniza los PANs cuanto antes. Pruébalo en hexatransfer.com — gratis, sin cuenta, hasta 10 GB.