Pregunta

Tengo esta idea, pero no estoy seguro si es compatible con PCI. Soy nuevo en la arena de cumplimiento de PCI y tengo curiosidad por saber si este escenario viola PCI.

Por lo tanto, vamos a configurar el escenario. La empresa A es compatible con PCI y tiene un servicio web en https exponer bits de funcionalidad alrededor de procesamiento de pagos. La empresa B no es compatible, pero su sitio es seguro.

Estos son los pasos del escenario.

  1. sitio web de B contactos servicio web de un medio de código del lado del servidor. Este servicio devuelve un token de cifrado authetication.
  2. B inyecta esta ficha en una página que contiene un formulario para aceptar información de tarjeta de crédito.
  3. El usuario introduce su información de tarjeta de crédito en el sitio web del B.
  4. La información del formulario, junto con el token, se envían a través de una llamada AJAX al servicio web de A.
  5. servicio web de un procesa los datos y escupe un estado (Aprobado / denegado / etc)

La pregunta es, ya que el javascript va directamente desde la máquina del usuario a los servidores compatibles con la Compañía A, que es compatible con PCI? Estoy muy interesado en saber lo que los expertos en este campo creen.

¿Fue útil?

Solución

folleto sobre PCI DSS Toda la Normas PCI

PCI DSS (Payment Card Data Security Standard) tiene el concepto de "Alcance" -. Determinar qué sistemas están bajo el paraguas PCI

¿Es usted un comerciante o un proveedor de software? Si el PAN (número de cuenta principal), el número de tarjeta de crédito de largo, nunca se envía a su sitio web, entonces su sitio web por lo general no está bajo el alcance de PCI. - Suponiendo que usted es el comerciante. Si usted es un proveedor de software, a continuación, su software, probablemente estaría en el ámbito de la PA-DSS (véase más adelante).

PAN en tránsito por su servidor La vieja idea era que el PAN sería enviado a su sitio web (a través de un formulario de presentación del navegador), entonces su sitio web podría dar la vuelta y enviarlo a una pasarela de pago (por ejemplo, Authorize.Net). En este escenario, el PAN no se almacena en el servidor, pero hizo tránsito su servidor. Este utiliza en el sentido de que sus sistemas comerciales no estarían bajo el alcance de las PCI DSS ya que nunca se almacenan el PAN. Pero esos días están terminando rápidamente o ya se han ido. (Que depende de la agresividad de su proveedor de cuenta adquirente / Comerciante se trata de PCI.)

El control de su página web Desde su página web no transmite ninguna PAN a su servidor, que no está en el alcance de PCI. Pero ¿cómo se sabe que alguien no ha cambiado su página web para transmitir la parte posterior del PAN a su servidor (o en otro lugar, utilizando técnicas JSONP)? La respuesta es que se necesita para asegurarse que nadie va a interferir con su página de formas de pago.

¿Cómo usted asegura a sí mismo de esta depende de usted. Usted podría utilizar las técnicas de PCI u otras técnicas. Se trata de una cuestión de seguridad de su equipo interno y auditoría.

Aplicaciones de Pago Data Security Standard (PA-DSS) Si usted vende su sw a los comerciantes a continuación, probablemente sería dentro del alcance de la norma PA-DSS. Vea la estándar.

PCI es política y no técnica Recuerde que alcance PCI depende de usted. Si usted es un comerciante lo suficientemente grande, entonces también tendrá que trabajar con un QSA (Asesor de Seguridad) que va a revisar y bien su cumplimiento de PCI y un plan de alcance.

Sin duda, es posible que un QSA podría decir que desde el control de su página Web tiene que estar bajo PCI, ya que podría estar dañado por alguien. Pero eso sería un argumento agresivo. Después de todo, usted podría decir entonces que todas las páginas web de las necesidades mercantiles internet a estar bajo PCI desde cualquier página web podría estar dañado a pedir a la gente para una sartén y luego hacer algo mal con él. Por otra parte, este es exactamente el tipo de argumento que Visa está utilizando para aumentar el alcance PCI para franquiciadores corporativos. artículo .

certificación PCI no es una excusa nota también de que las asociaciones de tarjetas se reservan el derecho a echarte si tiene un robo - incluso si usted era compatible con PCI. Así que usted quiere estar seguro de que usted es un objetivo mucho más dura que cualquier otra persona en su bloque.

Agregado: Más en materia de ámbito Como se puede deducir de lo anterior, una cuestión clave es qué sistemas son dentro o fuera del alcance de PCI. El Consejo PCI tiene ahora un Grupo de Interés Especial (SIG) examinar todo este tema de lo que está dentro y lo que está fuera del alcance de PCI. Y yo creo que van a querer el sobre a crecer, se encoge.

Alta: Es un asunto entre usted y su abogado Su escenario tiene el comienzo del PAN transformación efectuada en los navegadores de sus clientes. El PAN nunca llega a sus sISTEMAS, ni siquiera por un instante. Así que mi interpretación es que estás fuera del alcance del comerciante PCI DSS. Pero usted es el que firma la declaración de cumplimiento de PCI que es un contrato entre usted y su adquirente. Por lo tanto, depende de usted y su abogado para interpretar la norma PCI DSS, no yo.

Conclusión debe nunca almacenar datos PAN en sus sistemas. Ni siquiera debe tenerlo el tránsito de sus sistemas. Pasarela de pago nueva protocolos de Authorize.Net y Braintree permiten la técnica sin tránsito. Dependiendo de su volumen de transacciones de tarjetas de crédito, el cumplimiento de PCI varía de una lista de comprobación autoadministrado para un gran proyecto.

Para más PCI-historias de guerra, comprobar el href="http://www.storefrontbacktalk.com/" rel="noreferrer"> StorefrontBacktalk el blog y de su cobertura PCI .

Otros consejos

La respuesta de Larry K es buena. Es sobre todo una cosa capa / política.

Parece que el uso de un iframe para la publicación de B a A es una solución aceptada, mientras que el uso de Ajax - con CORS o JSONP - es algo más discutible pero aún así, al menos para algunos grandes jugadores, aceptable

.

Suplemento: Directrices PCI DSS E-commerce costuras v2 decir que esta solución (directa post API) está bien, pero que le debería tener cuidado de código de seguridad (aunque PCI DSS no prescribe nada concreto que tendría que hacer) - véase la sección API 3.4.3.1 insertado por terceros con Direct mensaje y los relativos 3.4.3.4 Consideraciones de seguridad para implementaciones Shared-Gestión de comercio electrónico , que dice lo siguiente:

  

Enfoque API directa post : Con el enfoque directo de post-API, el   comerciante sigue siendo responsable de la página web que se presenta a   el consumo, y los anfitriones mercantes los campos de la página de pago   que aceptan los datos de sólo los datos de los titulares se publica directamente desde   el consumidor al proveedor de servicios. Desde las páginas de pago son   organizada por el comerciante, las páginas de pago son tan segura como la   sitio web de un comerciante y un compromiso del sistema del comerciante pudo   llevar a un compromiso de los datos de tarjetas de pago.   ...   En concreto, para todos los casos anteriores, el comerciante debe   monitorear cualquier tipo de prueba que los sistemas han cambiado y responden rápidamente   para restaurar los sistemas a un estado de confianza cuando son cambios no autorizados   detectado. Los comerciantes que adopten dichas-gestión compartida subcontratados   modelos para minimizar los requisitos de PCI DSS aplicables deben ser conscientes de   los posibles riesgos que son inherentes a este tipo de sistema   arquitectura. Para minimizar la posibilidad de un ataque en estos escenarios,   los comerciantes deben actuar con la debida diligencia adicional para garantizar la web   aplicación se desarrolla de forma segura y se somete a la penetración exhaustiva   pruebas.

Por ejemplo, el raya pasarela de pago utiliza post directo sobre JSONP desde 2012 en lugar del enfoque de marco flotante que tienen usado antes.

Por otro lado, WePay también proporciona una API directa post pero recomienda iframe para deshacerse por completo de los requisitos de PCI [WP] (que afirman que con la API directa-post " [..] aún eres requerido para cumplir con el pago de normas de seguridad de tarjetas de datos de la Industria (PCI-DSS) y el pago de Normas de Seguridad de datos de aplicación (PA-DSS) siempre que sea aplicable. "(sin especificar qué es exactamente 'cuando los medios aplicables').

[WP] WePay enlace: https://www.wepay.com/developer/tutorial/tokenization

He pasado recientemente a través de un trabajo de cumplimiento PCI para nuestros servidores, por lo que este es justo en frente de mí. La respuesta corta es no.

cumplimiento PCI requiere que cada paso de la trayectoria a través del cual pasa la información sensible cumple con los requisitos PCI en y de sí mismo. Algo puede ser seguro, pero no conforme, como usted señaló en relación con la empresa B. Debido a que ya se ha dicho que la empresa B no es compatible con PCI, sin embargo, la empresa B está recogiendo la información de tarjeta de crédito a través de su propio sitio web, entonces todo el proceso, es lógicamente no compatible.

Si un servicio de cumplimiento de PCI-realidad conecta estos puntos y la forma en que certificaría como pasa o no puede ser otra cosa.

Independientemente de si se "técnicamente" cumple con los estándares PCI (o no), yo no poner mi confianza en esta forma de hacer las cosas.

Si el formulario se encuentra en una página dentro del nombre de host B, B tiene acceso completo a lo que está en los campos de formulario. (Servidor de B es capaz de enviar al usuario malintencionado Javascript si quiere.)

La forma más segura de hacerlo (en términos de protección de números de tarjetas de crédito) es poner el formulario en su totalidad dentro del nombre de host del servicio de procesamiento de pagos en lugar de en un nombre de host no es de confianza.

Aquí está el PCI sitio web

En el fondo, si usted podría ver el número de tarjeta o cualquier información de identificación acerca de la tarjeta, tendrá que cumplir con los requisitos de PCI. No estoy seguro de que sean necesariamente un documento legal 'sin embargo', pero si se le encuentra en la violación, su capacidad de proceso, o ser parte de un proceso de transacción puede ser revocado. Además, como un comerciante de firmar un acuerdo acerca de su responsabilidad y de exclusión en un proceso en el que las compañías de tarjetas de crédito pueden imponerle una multa. Todo por el privilegio de aceptar tarjetas de crédito.

Para la diversión que aquí hay una (pdf) enlace a la página 38 Guía 'rápido' .

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top