Cumplimiento de PCI DSS para comercio electrónico: Guía de seguridad de pagos

Cada transacción de comercio electrónico que involucra una tarjeta de pago crea una obligación de cumplimiento según PCI DSS, el Estándar de seguridad de datos de la industria de tarjetas de pago. El incumplimiento no es un riesgo teórico: las marcas de tarjetas (Visa, Mastercard, Amex) pueden imponer multas de entre 5.000 y 100.000 dólares al mes a los bancos adquirentes, que transfieren la responsabilidad directamente a los comerciantes a través de sus acuerdos de procesamiento de pagos. Después de una infracción, los comerciantes que no cumplen se enfrentan a multas de entre 50 y 90 dólares por cada tarjeta comprometida, costos de investigación forense de la marca de la tarjeta y, en los casos más graves, la cancelación de su cuenta de comerciante.

PCI DSS v4.0, lanzado en marzo de 2022 con cumplimiento obligatorio a partir de marzo de 2025, introdujo cambios significativos en los requisitos criptográficos, los estándares de autenticación y el manejo de scripts en las páginas de pago. Esta guía brinda a los equipos de comercio electrónico una hoja de ruta de implementación completa.

Conclusiones clave

• PCI DSS v4.0 es obligatorio a partir del 31 de marzo de 2025: todos los comerciantes de comercio electrónico deben cumplir con la nueva versión
• El alcance es el primer paso más crítico: reducir el entorno de datos del titular de la tarjeta (CDE) tanto como sea posible.
• El uso de la página de pago alojada de un procesador de pagos (Stripe, Braintree, Adyen) reduce drásticamente el alcance
• El SAQ A se aplica a la mayoría de los comerciantes con páginas de pago alojadas, pero solo si los datos del titular de la tarjeta no entran en contacto con sus servidores.
• Los nuevos requisitos de la versión 4.0 incluyen MFA para todos los accesos a CDE, controles de integridad de secuencias de comandos en las páginas de pago y análisis de riesgos específicos.
• El skimming web (ataques Magecart) se aborda en el nuevo Requisito 6.4.3 en el inventario de secuencias de comandos de la página de pago
• Las pruebas de penetración anuales y los análisis de vulnerabilidad trimestrales siguen siendo obligatorios
• Las sanciones por incumplimiento se aplican desde las marcas de tarjetas → bancos adquirentes → comerciantes

---

Fundamentos del marco PCI DSS

PCI DSS es mantenido por el Consejo de Estándares de Seguridad de la Industria de Tarjetas de Pago (PCI SSC), un organismo fundado por American Express, Discover, JCB, Mastercard y Visa. El estándar actual es PCI DSS v4.0.

El estándar está organizado en 12 requisitos divididos en 6 objetivos:

El cumplimiento se aplica a cualquier entidad que almacene, procese o transmita datos de titulares de tarjetas, o que pueda afectar la seguridad de los datos de los titulares de tarjetas. Esto incluye comerciantes, procesadores de pagos, adquirentes, emisores y proveedores de servicios.

---

Paso 1: Defina y reduzca su alcance

El entorno de datos del titular de la tarjeta (CDE) es cualquier sistema que almacena, procesa o transmite datos del titular de la tarjeta (CHD) o datos de autenticación confidenciales (SAD). Minimizar el alcance es el paso más impactante que puede tomar.

Datos del titular de la tarjeta frente a datos de autenticación confidenciales:

Estrategias de reducción de alcance para el comercio electrónico:

1. Utilice una página de pago alojada: redirija a los clientes a la página de pago alojada de su procesador de pagos (Stripe Checkout, Braintree Hosted Fields, Adyen Drop-in). Ningún dato del titular de la tarjeta afecta a sus servidores y usted califica para SAQ A, el cuestionario de autoevaluación más simple.

2. Tokenización: Reemplace los números de tarjeta con tokens generados por el procesador inmediatamente después de la autorización. Almacene sólo el token, que es inútil para los atacantes sin acceso a la bóveda de tokenización del procesador.

3. Formularios de pago basados ​​en iFrame: inserte el formulario renderizado en JavaScript del procesador de pagos en su página de pago. Los datos de la tarjeta se ingresan directamente en un formulario alojado en el dominio del procesador, no en el suyo.

4. Segmentación de red: aísle los sistemas CDE (servidores de procesamiento de pagos, bases de datos) de los sistemas fuera de alcance mediante firewalls. Las redes correctamente segmentadas reducen drásticamente el alcance de la auditoría.

---

Paso 2: Identifique su tipo de SAQ

El Cuestionario de Autoevaluación (SAQ) es una herramienta de validación para comerciantes y proveedores de servicios que no requieren una evaluación in situ de un Asesor de Seguridad Calificado (QSA). El tipo de SAQ está determinado por cómo acepta los pagos:

SAQ A: Aplicable a comerciantes sin tarjeta presente (comercio electrónico) que subcontratan completamente el procesamiento de pagos a un tercero que cumple con PCI DSS. No se almacena, procesa ni transmite ningún dato del titular de la tarjeta electrónica en sus sistemas o instalaciones. Su página de pago es entregada íntegramente por su procesador de pagos. Aproximadamente 22 requisitos.

SAQ A-EP: para comerciantes de comercio electrónico que subcontratan parcialmente el procesamiento de pagos pero aún tienen una página de pago alojada en su propio servidor, que incorpora un iframe de pago de terceros. Su servidor web afecta indirectamente a la seguridad del procesamiento de pagos. Más requisitos que SAQ A. Críticamente afectado por la nueva v4.0 Requisito 6.4.3.

SAQ D: para comerciantes que no cumplen con los criterios de ningún otro tipo de SAQ o que almacenan datos de titulares de tarjetas. Cubre los 12 requisitos. Requerido para los comerciantes que ejecutan su propia infraestructura de procesamiento de pagos. Normalmente, más de 300 subrequisitos.

Niveles de nivel (estándar Mastercard/Visa):

---

Paso 3: Cambios clave de PCI DSS v4.0 para el comercio electrónico

PCI DSS v4.0 introdujo varios requisitos que afectan específicamente a los comerciantes de comercio electrónico. Todos eran obligatorios a partir del 31 de marzo de 2025.

Requisito 6.4.3: Gestión de secuencias de comandos de la página de pago

Este requisito apunta directamente a los ataques de Magecart/web skimming, donde los atacantes inyectan JavaScript malicioso en páginas de pago de comercio electrónico para robar datos de los titulares de tarjetas en tiempo real. Según 6.4.3, los comerciantes que utilizan SAQ A-EP o superior deben:

• Mantener un inventario de todos los scripts autorizados para ejecutarse en las páginas de pago.
• Justificar la necesidad comercial o técnica de cada script.
• Implementar un método para confirmar la integridad de cada script (hashes de integridad de subrecursos para scripts de terceros o directivas de política de seguridad de contenido)

Para los comerciantes del SAQ A con una página de pago totalmente subcontratada, este requisito se aplica a las páginas de su procesador de pagos: deben demostrar el cumplimiento en su nombre.

Requisito 11.6.1: Detección de cambios y manipulaciones en páginas de pago

Los comerciantes deben implementar un mecanismo (por ejemplo, una política de seguridad de contenido, un servicio de monitoreo de scripts) para detectar modificaciones no autorizadas en los encabezados HTTP y el contenido de los scripts en las páginas de pago. Las alertas deben generarse dentro de los 7 días posteriores a cualquier cambio no aprobado.

Requisito 8.4.2 — MFA para todos los accesos al CDE

Ahora se requiere autenticación multifactor para todas las cuentas de usuario con acceso al CDE, no solo para el acceso remoto. Esto incluye a los usuarios internos que acceden a los sistemas de pago de producción desde dentro de la red corporativa.

Requisito 3.3.1.1 — El DUA no se puede conservar después de la autorización

Prohíbe explícitamente el almacenamiento de datos de autenticación confidenciales (datos de seguimiento completos, CVV, PIN) después de la autorización. Esto siempre estuvo prohibido, pero ahora está redactado de manera más precisa para cerrar las lagunas en la forma en que algunos sistemas registran SAD en las salidas de depuración/diagnóstico.

Análisis de riesgos dirigido (TRA)

v4.0 introduce el concepto de análisis de riesgos dirigido: los comerciantes pueden demostrar enfoques alternativos para algunos requisitos si realizan un análisis de riesgos documentado que muestre una protección equivalente. Esto proporciona flexibilidad para entornos más grandes y complejos.

---

Paso 4: Arquitectura de seguridad de red

Para los comerciantes con sistemas cuyo alcance va más allá del SAQ A, la seguridad de la red es un dominio de cumplimiento fundamental.

Requisito 1: Instalar y mantener controles de seguridad de red:

• Implementar un firewall entre redes no confiables (internet) y el CDE
• Implementar un firewall entre CDE y otras redes internas (segmentación)
• Documentar todas las reglas de firewall con justificación comercial.
• Revisar las reglas del firewall al menos cada 6 meses.
• Denegar todo el tráfico que no se requiera explícitamente (postura de denegación predeterminada)
• Para comercio electrónico: implementar WAF (Web Application Firewall) frente a los servidores web

Pruebas de segmentación de red:

Un error común es pensar que la segmentación de la red reduce el alcance automáticamente. PCI SSC requiere que usted pruebe que la segmentación es efectiva; las pruebas de penetración deben incluir intentos de cruzar el límite de la segmentación. Si un probador de penetración puede llegar a los sistemas CDE desde redes fuera de alcance, la segmentación no es efectiva y el entorno más amplio entra en su alcance.

Arquitectura DMZ para comercio electrónico:

Internet → WAF/Load Balancer → DMZ (Web Servers) → Internal Firewall → CDE (Payment Servers, DB) → Internal Network

Los servidores web en la DMZ sirven a su tienda. Solo el tráfico específico y documentado (HTTPS a API de pago, SQL en un puerto específico a una base de datos específica) cruza de DMZ a CDE. Todo el resto del tráfico está bloqueado.

---

Paso 5: Requisitos de seguridad de la aplicación

Requisito 6: Desarrollar y mantener sistemas y software seguros:

• Mantener un inventario de todo el software personalizado y de terceros dentro del alcance.
• Abordar las vulnerabilidades como parte de un proceso formal de gestión de vulnerabilidades.
• Proteger las aplicaciones web contra ataques conocidos (OWASP Top 10)
• Realizar revisiones del código de seguridad o pruebas de penetración de aplicaciones antes de implementar cambios significativos en producción.
• Utilice únicamente software de proveedores acreditados con procesos de parches de seguridad comprometidos.

Firewall de aplicaciones web (WAF): Requisito 6.3.2 y 6.4.2:

WAF es obligatorio para todas las aplicaciones web públicas y está configurado para bloquear ataques o generar alertas y revisarlas en 1 hora. Para el comercio electrónico, WAF debe cubrir:

• Prevención de inyección SQL
• Protección de secuencias de comandos entre sitios (XSS)
• Protección contra falsificación de solicitudes entre sitios (CSRF)
• Detección de bots maliciosos
• Limitación de velocidad para la prevención de fuerza bruta

Gestión de dependencias y software de terceros:

Las plataformas de comercio electrónico (personalizaciones de WooCommerce, Magento, Shopify) dependen en gran medida de complementos y extensiones. Se debe evaluar la seguridad de cada complemento dentro del alcance. Mantenga un inventario y aplique parches dentro de su SLA de parches (crítico: 7 días desde el lanzamiento del parche del proveedor).

---

Paso 6: Control de acceso y autenticación

Requisito 7: restringir el acceso a los componentes del sistema y a los datos del titular de la tarjeta:

• Implementar control de acceso basado en roles basado en privilegios mínimos
• Todos los accesos predeterminados son "denegar todo" con concesiones explícitas documentadas
• Revisar los derechos de acceso de los usuarios al menos cada 6 meses.

Requisito 8: Identificar usuarios y autenticar el acceso:

• Asignar una identificación única a cada persona con acceso al CDE
• Contraseñas de mínimo 12 caracteres (v4.0 aumentan de 7 en v3.2.1), requisitos de complejidad
• Bloquear cuentas después de un máximo de 10 intentos no válidos (v4.0 por defecto o según TRA)
• Tiempo de espera de la sesión después de un máximo de 15 minutos de inactividad para sesiones de CDE
• Se requiere MFA para todos los accesos a CDE (expansión v4.0 solo desde forma remota)
• Las cuentas de servicio y las cuentas del sistema deben administrarse por separado de las cuentas de usuario.

---

Paso 7: Gestión y prueba de vulnerabilidades

Requisito 11: Probar la seguridad de los sistemas y redes:

Análisis de vulnerabilidad internos trimestrales: analiza todos los sistemas incluidos. Corrija todas las vulnerabilidades críticas y de alta gravedad antes del siguiente análisis. Los escaneos pueden ser realizados por personal interno utilizando herramientas aprobadas (Nessus, Qualys, OpenVAS).

Análisis de vulnerabilidad externos trimestrales realizados por un proveedor de análisis aprobado (ASV): los análisis externos de todos los sistemas accesibles externamente deben ser realizados por un ASV aprobado por PCI SSC. El análisis debe aprobarse (sin vulnerabilidades altas/críticas abiertas) antes de poder certificar el cumplimiento.

Pruebas de penetración anuales: realizadas por un recurso interno calificado o una empresa externa acreditada. Debe cubrir:

• Todos los sistemas y redes dentro del alcance.
• Controles de segmentación (verificar que el CDE esté correctamente aislado)
• OWASP Top 10 para aplicaciones web
• Ingeniería social (para entornos de mayor riesgo)

Corrija todos los hallazgos de las pruebas de penetración y realice pruebas de verificación para confirmar la corrección.

Monitoreo de integridad de archivos (FIM): implemente FIM en todos los archivos críticos del sistema, archivos de configuración y archivos de contenido. Alerta dentro de 1 hora (v4.0) de cualquier cambio no autorizado.

---

Lista de verificación de cumplimiento de PCI DSS para comercio electrónico

• Alcance del procesamiento de pagos definido y reducido (página de pago alojada o tokenización utilizada cuando sea posible)
• [] Tipo de SAQ identificado según el método de aceptación de pago
• Segmentación de red implementada y documentada
• [] Inventario de datos del titular de la tarjeta completado: no hay SAD almacenado en ninguna parte
• [] Todo el almacenamiento de datos del titular de la tarjeta cifrado (AES-256 o equivalente)
• [] TLS 1.2+ aplicado para todas las transmisiones de datos de pago
• Inventario del script de la página de pago documentado (Requisito 6.4.3)
• Detección de cambios/manipulación implementada en páginas de pago (Requisito 11.6.1)
• [] WAF implementado frente a todas las aplicaciones web públicas
• MFA aplicado para todos los accesos CDE (Requisito 8.4.2)
• [] ID de usuario únicos, contraseñas seguras, bloqueo de cuenta configurado
• [] Se completaron análisis de vulnerabilidad trimestrales (internos + ASV externos)
• Prueba de penetración anual completada, resultados corregidos
• [] Monitoreo de integridad de archivos implementado en sistemas CDE
• [] Reglas de firewall revisadas en los últimos 6 meses
• [] Se completó la capacitación sobre concientización sobre seguridad para todo el personal que toca al CDE
• El plan de respuesta a incidentes cubre escenarios de violación de tarjetas de pago
• Cumplimiento de PCI DSS del proveedor/proveedor de servicios verificado

---

Preguntas frecuentes

Usamos Shopify para nuestra tienda. ¿Aún necesitamos el cumplimiento de PCI DSS?

Shopify es un proveedor de servicios certificado PCI DSS Nivel 1. Si utilizas el procesamiento de pagos estándar de Shopify (Shopify Payments o pago alojado en Shopify), tu alcance de cumplimiento se reduce drásticamente. Aún tienes obligaciones, principalmente el SAQ A, que cubren tu uso de los servicios de Shopify. Si agregas JavaScript personalizado a tu proceso de compra de Shopify o utilizas aplicaciones de pago de terceros que procesan datos de tarjetas fuera del entorno de Shopify, el alcance se expande.

¿Cuál es la diferencia entre el cumplimiento de PCI DSS y la certificación PCI DSS?

No existe una "certificación PCI DSS" formal para los comerciantes. Los comerciantes dan fe del cumplimiento mediante cuestionarios de autoevaluación o (comerciantes de nivel 1) mediante un informe de cumplimiento (RoC) realizado por un QSA. Los proveedores de servicios pueden figurar en el Registro global de proveedores de servicios de Visa. Los términos "certificado" y "cumple" a menudo se usan indistintamente en las comunicaciones de mercado, pero técnicamente los comerciantes dan fe por sí mismos o tienen el cumplimiento certificado por QSA.

¿A qué sanciones se enfrentan los comerciantes por incumplimiento?

Las sanciones no provienen directamente del PCI SSC: fluyen de las marcas de tarjetas a través de los bancos adquirentes. Las multas mensuales suelen oscilar entre $ 5000 y $ 100 000, según el nivel del comerciante y la duración del incumplimiento. Después de una infracción, las marcas de tarjetas pueden imponer multas por tarjeta ($50 a $90 por tarjeta Visa, similar a Mastercard), costos de investigación forense ($20 000 a $200 000 o más) y costos obligatorios de reemisión de la tarjeta. En casos graves, los comerciantes pierden por completo la capacidad de aceptar pagos con tarjeta. Los infractores reincidentes o los comerciantes con grandes impactos en las infracciones se enfrentan a las sanciones más altas.

¿Qué es un ataque Magecart y cómo lo aborda PCI DSS v4.0?

Magecart se refiere a ataques en los que se inyecta JavaScript malicioso en las páginas de pago del comercio electrónico para interceptar los datos de los titulares de tarjetas en tiempo real a medida que los clientes los escriben. Estos ataques explotan scripts de terceros (análisis, widgets de chat, administradores de etiquetas) que los comerciantes incluyen en las páginas de pago. Los requisitos PCI DSS v4.0 6.4.3 y 11.6.1 abordan esto directamente: los comerciantes deben inventariar y verificar la integridad de todos los scripts en las páginas de pago e implementar monitoreo para detectar cambios no autorizados en el código de la página de pago.

¿Cómo manejamos PCI DSS para una arquitectura de comercio electrónico sin cabeza?

El comercio electrónico sin cabeza separa la capa de presentación del frontend del motor de comercio backend. A efectos de PCI DSS, lo que importa es dónde fluyen los datos de los titulares de tarjetas. Si su interfaz sin cabeza utiliza Stripe Elements o una solución similar basada en iFrame, los datos de la tarjeta van directamente desde el navegador al procesador de pagos sin tocar sus servidores de interfaz: este es territorio SAQ A. Si su arquitectura headless implica un procesamiento de pagos personalizado del lado del servidor, el alcance se expande significativamente y debe contratar a un QSA para que le oriente sobre el alcance.

¿Necesitamos un QSA para nuestra evaluación PCI DSS?

Solo los comerciantes de Nivel 1 (más de 6 millones de transacciones/año para Visa/Mastercard) deben contratar un QSA para un Informe de Cumplimiento (RoC) anual. Los comerciantes de nivel 2 a 4 pueden realizar su propia certificación a través de SAQ. Sin embargo, muchos comerciantes contratan voluntariamente a una QSA o una empresa asesora de seguridad calificada (QSAC) para obtener orientación incluso cuando no es necesaria, particularmente cuando no están seguros de su alcance o tienen una infraestructura compleja.

---

Próximos pasos

El cumplimiento de PCI DSS protege los datos de pago de sus clientes, limita su exposición a la responsabilidad y es un requisito previo para mantener la aceptación de la tarjeta. Para las empresas de comercio electrónico en Shopify o plataformas personalizadas, el primer paso es siempre la reducción del alcance: llegar al SAQ A mediante el uso adecuado de las páginas de pago alojadas es el camino más rápido y rentable.

El equipo de implementación de comercio electrónico de ECOSIRE tiene amplia experiencia en la creación de tiendas Shopify compatibles con PCI DSS y plataformas de comercio personalizadas, con una arquitectura de pago diseñada desde cero para minimizar el alcance de CDE.

Comenzar: Servicios de Shopify de ECOSIRE

Descargo de responsabilidad: esta guía tiene fines informativos únicamente y no constituye asesoramiento legal o de cumplimiento. Los requisitos de PCI DSS pueden cambiar y variar según la marca de la tarjeta y el adquirente. Contrate a un QSA para obtener orientación definitiva sobre cumplimiento específico para su entorno.