PCI DSS: niveles y cumplimiento

1) Qué es PCI DSS y quién lo necesita

• acepte pagos con tarjeta (directamente o a través de PSP/gateway),
• procesa/almacena/transmite los datos de la tarjeta (PAN, plazo, CVV) o sus formularios acortados/cifrados,
• usted es un proveedor de servicios para otros merchants (alojamiento, procesamiento, anti-frod, orquesta de pago, etc.) si puede afectar la seguridad de los datos de las tarjetas.

Versión y plazos: la versión actual es PCI DSS v4. 0. Requisitos v3. 2. 1 fuera de uso; «futuro-fecha» párrafos v4. 0 ahora son válidos. Nuevo en v4. 0: reforzado con MFA, «Customized Approach», análisis de riesgo dirigido a la frecuencia de los procedimientos, refinamiento por segmentación y cifrado.

2) Niveles de cumplimiento: comerciantes y proveedores de servicios

2. 1 Merchantes (comerciantes)

• Nivel 1:> 6 millones de transacciones/año o hubo compromiso. Se requiere un ROC anual (Informe sobre cumplimiento) de QSA o un ISA interno cuando se negocia, + escáneres ASV trimestrales.
• Nivel 2: ~ 1-6 millones/año. Normalmente - SAQ (autoevaluación) + escáneres ASV; algunos circuitos/equipadores pueden requerir ROC.
• Nivel 3: ~ 20k-1 millón e-commerce/año. Normalmente - SAQ + ASV-scans.
• Nivel 4: por debajo de los umbrales L3. SAQ; los requisitos pueden variar según el banco de equipación.

2. 2 Proveedores de servicios

Normalmente 2 niveles; para Nivel 1 (gran volumen/papel crítico en la cadena) es obligatorio ROC de QSA, para Nivel 2 - SAQ-D SP (a veces ROC a petición de contrapartes/circuitos). En iGaming, muchos PSP/gateways/hosting partners son SP Nivel 1.

3) SAQ vs ROC: cómo elegir

• SAQ A - sólo redireccione/iframe/hosted fields; No hay tratamiento/transmisión/almacenaje de las tarjetas a usted.
• SAQ A-EP es un e-commerce donde su sitio afecta la seguridad de la página de pago (por ejemplo, el alojamiento de scripts), pero el PAN se introduce en el entorno del proveedor.
• SAQ B/B-IP: terminales/impresoras sin almacenamiento electrónico; B-IP - terminales conectados.
• SAQ C-VT/C - terminales virtuales/pequeños entornos de procesamiento, sin almacenamiento.
• SAQ P2PE es sólo una solución PCI P2PE certificada.
• SAQ D (Merchant / Service Provider) - la variante "ancha" a cualquier tratamiento/transmisión/almacenaje, kastomnyh integratsiyah, orkestratorah y semejante

Práctica para iGaming: la ruta de destino es SAQ A/A-EP a través de hilos PAN-safe, tokenización y campos hosted. Si tiene sus propios servicios de pago/valt - normalmente SAQ D o ROC.

4) Copiar: lo que entra en el CDE y cómo reducirlo

CDE (Cardholder Data Environment): sistemas donde se procesan/almacenan/transmiten datos de tarjetas y todos los segmentos conectados/influyentes.

• Campos alojados/iframe/TSP: escriba PAN fuera de su dominio.
• Tokenización y tokens de red: sus servicios operan con tokens, no PAN.
• P2PE: encriptación final a final con solución certificada.
• Segmentación de la red: ACL rígidas, aislamiento de CDE del resto del entorno.
• DLP obligatorio y enmascaramiento de registros, prohibición de volcado con PAN/CVV.

V4. 0 se ha añadido flexibilidad a los métodos para alcanzar los objetivos, pero la prueba de eficacia y el análisis de riesgo dirigido son obligatorios.

5) «12 requisitos» PCI DSS v4. 0 (bloques semánticos)

1. Protección de red y segmentación (firewall, ACL, aislamiento CDE).
2. Configuración segura de hosts/dispositivos (hardning, líneas base).
3. Protección de datos de titulares de tarjetas (almacenamiento PAN - sólo si es necesario, criptografía fuerte).
4. Protección de datos durante la transferencia (TLS 1. 2 + y equivalentes).
5. Antivirus/anti-malware y control de integridad.
6. Desarrollo y modificación seguros (SDLC, SAST/DAST, control de bibliotecas).
7. Acceso por necesidad (privilegio least, RBAC).
8. Identificación y autenticación (MFA para acceso administrativo y remoto, contraseñas por v4. 0).
9. Seguridad física (centros de datos, oficinas, terminales).
10. Lógica y monitorización (centralización de registros, inmutabilidad, alertas).
11. Pruebas de seguridad (escáneres ASV trimestrales, pentestas anuales y posteriores a los cambios, prueba de segmentación).
12. Gestión de políticas y riesgos (procedimientos, capacitación, incidentes-respuesta, evaluaciones de riesgo, documentos de «Aplicación personalizada»).

6) Actividades obligatorias y periodicidad

ASV-scans (externos) - trimestral y después de cambios significativos.
Vulnerabilidades/parches - ciclos regulares (las frecuencias son justificadas por TRA - análisis de riesgo targeted).
Pentests (intra ./exterior.) - Cada año y después de un cambio significativo; la comprobación de segmentación es obligatoria.
Registros y monitoreo - de forma continua, con retén y protección contra modificaciones.
Formación del personal - en la contratación y en lo sucesivo con regularidad.
MFA: para todo el acceso administrativo y remoto al CDE.
Inventario de sistemas/flujos de datos: actualice constantemente.

7) Matriz de selección SAQ (corto)

Sólo iframe/redireccionar, sin PAN tiene → SAQ A.
E-commerce, su sitio afecta a la página de pago → SAQ A-EP.
Terminales/impresores → SAQ B/B-IP.
Terminal virtual → SAQ C-VT.
Una pequeña red de «tarjetas» sin almacenamiento → SAQ C.
Solución P2PE → SAQ P2PE.
Inoe/slozhnoe/hranenie/obrabotka → SAQ D (o ROC).

8) Artefactos y pruebas para la auditoría

• Gráficos de redes y flujos de datos, registro de activos, registro de proveedores, registro de cuentas/accesos.
• Políticas/procedimientos: desarrollo seguro, gestión de cambios, lógica, incidentes, vulnerabilidades, claves/cifrado, acceso remoto, copias de seguridad.
• Informes: ASV, pentests (segmentación inclusive), análisis de vulnerabilidades, resultados de correcciones.
• Registros/alertas: sistema centralizado, inmutabilidad, resolución de incidentes.
• Crypto-control: KMS/HSM procedimientos, rotaciones, inventario de claves/certificados.
• Prueba de «Aplicación personalizada» (si se aplicó): objetivos de control, método, métricas de eficacia, TRA.
• Contornos de responsabilidad de terceros: socios AoC (PSP, hosting, CDN, anti-frod), matriz de respuesta compartida.

9) Proyecto de cumplimiento (paso a paso)

1. Scoping y análisis GAP: determinar CDE, segmentos adyacentes, brechas actuales.
2. Ganancias rápidas: flujo de PAN-seguro (iframe/campos alojados), tokenización, prohibición de PAN en los registros, cerrar vulnerabilidades «externas».
3. Segmentación y red: aislar CDE, mTLS, firewall-ACL, accesos least-privilege, MFA.
4. Observabilidad: lógica centralizada, retén/cadena de conservación, alertas.
5. Gestión de vulnerabilidades y código: SAST/DAST, parches, SBOM, control de dependencias.
6. Pruebas: escáneres ASV, pentestes internos/externos, comprobación de segmentación.
7. Documentos y capacitación: procedimientos, reproductores de IR, capacitaciones, registros de capacitación.
8. Selección del formulario de certificación: SAQ (tipo) o ROC; alinear con el ecuador/marcas.
9. Ciclo anual: apoyo, pruebas, revisión de riesgos/frecuencias, traspaso.

10) Integración con la arquitectura iGaming

El orquestador de pagos sólo funciona con tokens; PAN no lo ve.
Multi-PSP: health-checks, smart-routing, idempotency, ретраи; AoC de cada PSP.
Bus Event-driven/DWH: sin PAN/CVV; enmascarar los últimos 4 dígitos; Gates DLP en CI/CD.
Cheques por 3DS/SCA: almacenar sólo los artefactos necesarios (ID de transacción), sin datos sensibles.

11) Errores frecuentes

La lógica de PAN/CVV y máscaras inválidas.
Conexión de PAN «temporal» a través de API/bus internos.
No hay prueba de segmentación en el pentesto.
Frecuencia indebida de los procedimientos (no TRA por v4. 0).
Dependencia de un único PSP sin AoC y sin fallback.
Segmentos «influyentes» no contabilizados (administración-jump-hosts, monitoreo, backups).

12) Lista de comprobación de inicio rápido (iGaming)

• Ir a los campos alojados/iframe; quitar la entrada PAN de sus formularios.
• Habilitar tokenización/tokens de red; eliminar PAN de eventos/registros.
• Realizar el CDE y el aislamiento del segmento (MFA, RBAC, mTLS).
• Configurar logs y alertas centralizados (inmutabilidad, retencion).
• Ejecute los escáneres ASV, elimine los críticos/altos.
• Realizar pentests (intra ./exterior.) + prueba de segmentación.
• Preparar políticas/procedimientos y pruebas de cumplimiento.
• Armonizar el formulario de certificación con el ecuador (tipo SAQ/ROC).
• Obtener y almacenar AoC de todos los proveedores de creta.
• Incorporar controles PCI en el ciclo de lanzamiento (SDLC, IaC-hardning, DLP en CI/CD).

13) Preguntas frecuentes breves

¿Necesita QSA? Para ROC - sí. Para SAQ, a menudo, la autocertificación es suficiente, pero muchos ecuayers/marcas pueden requerir un socio QSA/ASV.
¿Si no almacenamos PAN? De todos modos, usted está sujeto a PCI DSS si acepta tarjetas. Trate de alcanzar SAQ A/A-EP.
3DS decide PCI? No. 3DS - acerca de la autenticación; PCI - acerca de la protección de datos.
¿Suficiente TLS? No. Se necesitan todos los requisitos relevantes v4. 0, incluyendo procesos y pruebas.

14) Resumen

Para iGaming, la estrategia óptima es minimizar el scop (PAN-safe, tokenización, campos alojados, P2PE donde sea posible), segmentar rígidamente el CDE, automatizar la lógica/vulnerabilidades/pentests, montar un paquete completo de artefactos y seleccionar el formulario de confirmación correcto (SAQ o ROC) según su nivel. Esto reduce el riesgo, acelera las integraciones con PSP y mantiene una conversión y monetización estables mientras se cumplen los requisitos de las marcas de tarjetas.