alcance PCI al ingresar los detalles de la tarjeta en el navegador

3

Supongamos que tengo un sitio web de comercio electrónico, alojado en Azure (o AWS). Usaré una pasarela de pago de terceros que esté totalmente certificada como PCI nivel 1. Toda la comunicación se realiza con TLS 1.1 o superior.

Escenario A : durante el proceso de pago, se presenta una página que solicita al usuario sus detalles, incluida la tarjeta de crédito. Este formulario de navegador se sirve desde el servidor mi en Azure. Cuando el usuario presiona PAGAR, mediante JavaScript enviamos los detalles de la tarjeta a la puerta de enlace de terceros para procesar el pago y esperar la respuesta. En ningún momento se envían los datos de la tarjeta de crédito a mi servidor en Azure.

Escenario B : en lugar de entregar un formulario de tarjeta de crédito desde mi sitio, en su lugar usamos la página de pago alojada de la puerta de enlace de terceros. Eso significa que hacemos una redirección al sitio de la puerta de enlace, donde el usuario ingresa los detalles de la tarjeta, y luego el navegador redirige a mi página de pago completo.

Escenario C : una especie de híbrido, mostramos la página de pago alojada desde la puerta de enlace en un iframe dentro de una página servida desde mi servidor en Azure.

Preguntas:

  1. En estos tres escenarios, ¿hay una diferencia en el alcance de PCI para el servidor que se ejecuta en Azure? ¿Cuál es el alcance? ¿Nuestra infraestructura de Azure necesita someterse a una auditoría anual?

  2. Hace una diferencia si Yo soy un comerciante (así que la puerta de enlace de terceros está usando mi cuenta de comerciante en mi nombre) frente a una puerta de enlace que procesa transacciones con su propia cuenta de comerciante y luego me reembolsa más tarde.

Me llevan a creer que hay una diferencia en el alcance de PCI entre estos escenarios, pero realmente no puedo ver por qué. Si el servidor de Azure está comprometido, un atacante podría servir páginas maliciosas y capturar la tarjeta del usuario, independientemente del enfoque que se utilice.

Veo sitios de comercio electrónico utilizando el escenario A todo el tiempo, pero estoy bastante seguro de que muy pocos de ellos se ejecutan en entornos compatibles con PCI.

    
pregunta richb 28.03.2017 - 12:12
fuente

1 respuesta

2

Advertencia IANAQSA

  

En estos tres escenarios, ¿hay una diferencia en el alcance de PCI para el   servidor que se ejecuta en Azure? ¿Cuál es el alcance? ¿Nuestro Azure?   ¿La infraestructura necesita someterse a una auditoría anual?

El alcance aquí se debe medir como una cosa por comerciante, no como por servidor. Sí, sus servidores de Azure estarán cubiertos por su alcance (el nivel del cual hablaré más adelante). AWS es el estándar de oro para los proveedores de la nube que lo ayudan a comprender qué problemas de alcance son suyos suyo. Azure parece ser menos útil en ese sentido; apuntan a PCI, pero al menos tienen una Matriz de Cumplimiento .

(A falta de otros detalles), el Escenario A probablemente se consideraría alcance de SAQ A-EP y los escenarios B y C serían SAQ A. Aquí hay un buena descripción de PCIComplianceGuide.org :

  

el Consejo dice que un comerciante aún puede usar SAQ A si:

     
  • El sitio web del comerciante proporciona un marco en línea (iframe) a un PCI DSS   Procesador de terceros compatible que facilita el proceso de pago.
  •   
  • El sitio web del comerciante contiene un enlace de URL que redirige a los usuarios del comerciante   sitio web a un procesador de terceros compatible con PCI DSS que facilita la   proceso de pago. (Fuente: Descripción de los SAQ para PCI DSS versión 3, pág.   5)
  •   

...

  

¿Hay alguna diferencia si yo mismo soy un comerciante (por lo que el tercero   party gateway está usando mi cuenta de comerciante en mi nombre) vs una puerta de enlace   que procesa las transacciones con su propia cuenta mercantil, y luego   me reembolsa más tarde.

No lo creo. Los clientes van a su sitio; los clientes sacan su tarjeta y escriben los números; Los clientes esperan bienes o servicios a cambio. Eres un comerciante, ya sea que estés administrando tu cuenta con el procesador de pagos o pasando por un facilitador de pagos.

  

Me llevan a creer que hay una diferencia en el alcance de PCI entre estos   Escenarios, pero realmente no puedo ver por qué. Si el servidor de Azure es   comprometido, un atacante podría servir páginas maliciosas y capturar   La tarjeta del usuario, independientemente del enfoque que se utilice.

Hay una diferencia entre los ámbitos SAQ A y A-EP; la primera es 14 preguntas; el último está más cerca de 100 y requiere escaneos.

En términos de seguridad reales hay una diferencia insignificante. Hablando por mí mismo, creo que el razonamiento que sugiere que los marcos son más seguros donde javascript es menos seguro son engañosos y no impulsados por la tecnología. Ambos son igualmente vulnerables a un atacante malicioso que compromete el servidor web y reemplaza {iframe, javascript} por su propio.

  

Veo sitios de comercio electrónico usando el escenario A todo el tiempo, pero estoy bastante   Seguro que muy pocos de ellos se ejecutan en entornos compatibles con PCI.

Estoy seguro de que algunos de ellos han completado correctamente los SAQ.

Algunos de estos subconjuntos son compatibles con PCI.

Algunos subconjuntos de ellos son realmente seguros.

    
respondido por el gowenfawr 28.03.2017 - 17:08
fuente

Lea otras preguntas en las etiquetas