Cómo enviar información de la tarjeta de crédito a un servidor / sitio web separado (PCI)

5

Mi empresa tiene un sitio web / servicio que almacena / procesa tarjetas de crédito y es compatible con PCI (Sitio A). También tenemos sitios web con tiendas que necesitan enviar datos de tarjetas de crédito a ese sitio para su procesamiento (Sitio B). Cuando alguien pide algo en el sitio B e ingresa su información de facturación, ¿cómo envío esa información al sitio A y me mantengo en conformidad con PCI?

Obviamente, están en una página segura en el sitio B, cuando ingresan sus detalles de facturación.

¿Puedo simplemente publicar el formulario en una página segura en el Sitio A desde una página segura en el Sitio B? ¿Necesito cifrar la tarjeta de crédito durante esta transacción? Obviamente, se almacena en algún tipo de estado cifrado, pero ¿es necesario cifrarlo durante la transacción de envío?

¿Necesito configurar algún tipo de protocolo de enlace entre los sitios web, como una clave secreta? Si es así, ¿cuál sería una forma segura de crear esa clave / protocolo de enlace?

Hemos estado leyendo y leyendo sobre el cumplimiento de PCI tratando de encontrar respuestas concretas, pero parece algo subjetivo, y oscurece lo que se supone que estamos haciendo.

Esta pregunta también se publica actualmente en StackOverflow .

    
pregunta mikemick 14.04.2011 - 20:42
fuente

2 respuestas

6

El PCI DSS se aplica a cualquier sistema que almacene, procese o transmita datos de titulares de tarjetas. En el escenario que describió anteriormente, a la letra de la ley, tendría que aplicar el estándar a todos los sistemas y redes que conforman el Sitio B.

Como no está almacenando los datos del titular de la tarjeta en el Sitio B, esto reducirá al menos la cantidad de trabajo que tendría que cubrir como, por ejemplo, por lo que puedo ver, la totalidad del "Requisito 3: proteger los datos almacenados del titular de la tarjeta. "sería N / A.

Sin embargo, deberá asegurarse de que las cosas como la arquitectura de su firewall / DMZ se armen y gestionen adecuadamente (Requisito 1), que los datos del titular de la tarjeta estén encriptados en transmisión si la conexión entre el Sitio A y el Sitio B es "abierta, Red pública "como Internet.

Recogiendo su punto, y para hacer eco en @Rook, SSL estará bien para este propósito (consulte el Requisito 4.1). No necesita para codificar o cifrar los datos de la tarjeta en este momento. Es solo cuando está en reposo.

Al moverse a través del estándar, casi todo lo demás se aplicará, los sistemas deberían fortalecerse (Requisito 2), Antivirus (si es un sistema "comúnmente afectado por virus") y administración de parches (Requisito 5), buen desarrollo de software procesos (Requisito 6): sin olvidar el legendario 6.6, la revisión de código o WAF.

Controles de acceso sólidos (requisitos 7 y 8), seguridad física (9), registro y monitoreo (10), pruebas regulares (11) y buena gestión de la seguridad de la información (12) se aplicarán todo lo que puedo ver.

Sin ninguno de estos elementos, si fuera el atacante, simplemente apuntaría al Sitio B y obtendría los datos directamente desde el servidor a medida que los ingresa el cliente o cuando se transmiten desde el Sitio B al Sitio A.

Este es realmente un escenario común en el mundo de procesamiento de pagos (piense en PayPal, WorldPay, etc.). Los "comerciantes" (alguien que realiza pagos con tarjeta de crédito) generalmente tienen dos opciones cuando desean integrarse con un procesador de pagos para aceptar pagos con tarjeta de crédito.

1) Reciben los datos de la tarjeta ellos mismos, generalmente a través de un formulario web y luego envían esos datos a la API del procesador de pagos para su autorización, etc. Esto lo hacen normalmente los comerciantes más grandes. Procesan la respuesta y actualizan sus sistemas y responden al cliente de manera adecuada.

2) "Redirigen" al cliente al procesador de pagos, quien luego toma los datos de la tarjeta a través de un formulario en su propio sitio web para que el comerciante nunca vea los datos de la tarjeta. El comerciante generalmente se actualiza luego como el éxito del pedido por parte de un POST HTTP "fuera de banda" al sitio web del comerciante. El cliente obviamente tiene un resultado inmediato en la pantalla.

En la opción 1, se requeriría al comerciante para lograr el cumplimiento completo de PCI DSS. En la opción 2, el comerciante no tiene la necesidad de cumplir ya que no está almacenando, procesando o transmitiendo datos de la tarjeta.

Si el sitio B no está actualmente dentro del alcance de su cumplimiento con las normas PCI DSS y desea mantenerlo así, le sugiero que desarrolle un medio para tomar los datos de pago directamente en el sitio A y el sitio B simplemente apunta a las personas de esa manera.

Espero que esto haya sido útil. Tengo mucha experiencia con el PCI DSS, por lo que me complacería seguir discutiéndolo. Sin embargo, el descargo de responsabilidad estándar no es un QSA, por lo que cualquier decisión relacionada con el alcance debe verificarse con un Asesor de seguridad calificado antes de comenzar a trabajar.

    
respondido por el Marc Wickenden 14.04.2011 - 21:38
fuente
0

En resumen, el PCI-DSS establece que la información de la tarjeta de crédito nunca debe estar en texto sin formato. Dicho esto, no deberías preparar tu propio protocolo para esto. HTTPS es una gran solución.

    
respondido por el rook 14.04.2011 - 21:06
fuente

Lea otras preguntas en las etiquetas