Frage

ich diese Idee, aber ich bin nicht sicher, ob es PCI-konform ist. Ich bin neu in der Arena der PCI-Compliance und bin neugierig, ob dieses Szenario PCI verletzt.

Also, lassen Sie uns Einrichtung das Szenario. Unternehmen A ist PCI-konform und verfügt über einen Web-Service auf https Bit-Funktionalität um die Zahlungsabwicklung auszusetzen. Das Unternehmen B nicht kompatibel ist, aber die Website sicher ist.

Hier sind die Schritte des Szenarios.

  1. B Webseite Kontakte A der Webservice über Server-Side-Code. Dieser Dienst sendet eine verschlüsselte authetication Token.
  2. B einspritzt dieses Token in einer Seite ein Formular für die Annahme von Kreditkarteninformationen enthalten.
  3. Der Benutzer gibt seine Kreditkarteninformationen auf B-Website.
  4. Die Form Informationen, zusammen mit dem Token, werden über einen Ajax-Aufruf an A das Webservice gesendet.
  5. A des Webservice verarbeitet die Daten und spuckt zurück einen Status (Approved / verweigert / etc)

Die Frage ist, da die Javascript direkt von der Maschine des Benutzers geht an Firma A konformen Servern ist es PCI-konform? Ich bin sehr daran interessiert zu wissen, was Experten in diesem Bereich zu denken.

War es hilfreich?

Lösung

Pamphlet auf PCI DSS Alle der PCI Standards

PCI DSS (Payment Card Industry Data Security Standard) hat das Konzept der "Scoping" -. Zu bestimmen, welche Systeme unter dem PCI-Schirm kommen

Sind Sie ein Händler oder ein Software-Anbieter? Wenn die PAN (Primary Account Number), die lange Kreditkartennummer, wird nie auf Ihre Website gesendet wird, dann ist Ihre Website in der Regel nicht unter dem PCI-Scope. - Unter der Annahme, dass Sie der Händler sind. Wenn Sie ein Software-Anbieter sind, dann die Software wahrscheinlich im Rahmen des PA-DSS (siehe unten) sein würde.

PAN Durchfuhr dem Server Die alte Idee war, dass der PAN auf Ihre Website (über eine Browser Formulareinreichung) gesendet werden würde, dann würde Ihre Website umdrehen und es zu einem Payment-Gateway senden (zB Authorize.Net). In diesem Szenario wurde das PAN nie auf dem Server gespeichert, sondern tat Transit Ihr Server. Dies wird verwendet, um bedeuten, dass Ihr Händler Systeme nicht unter PCI DSS Umfang wären, da sie die PAN nie gespeichert. Doch diese Zeiten enden schnell oder sind schon weg. (Welche hängt davon ab, wie aggressiv Ihr Acquirer / Merchant Account Lieferant ist über PCI).

Controlling Ihrer Webseite Da Ihre Webseite überträgt keine PAN zu Ihrem Server, sind Sie nicht in dem PCI-Rahmen. Aber wie Sie wissen, dass jemand Ihre Webseite nicht geändert, um die PAN zurück auf den Server zu übertragen (oder anderswo, JSONP Techniken)? Die Antwort ist, dass Sie sich versichern müssen, dass niemand mit Ihren Zahlungsformular Seite manipulieren wird.

Wie Sie sich selbst von dieser versichern ist Ihnen überlassen. Sie könnten die PCI-Techniken oder andere Techniken verwenden. Dies ist eine Frage der internen Computer-Sicherheit und Revision.

Payment Application Data Security Standard (PA-DSS) Wenn Sie Ihre sw an Händler verkaufen, dann wäre es wohl im Rahmen des PA-DSS-Standard sein. Sehen Sie sich die Standard .

PCI ist politisch, nicht technische Beachten Sie, dass PCI Scoping bis zu Ihnen ist. Wenn Sie einen großen genug Händler sind, dann werden Sie auch mit einem QSA (Qualified Security Assessor) arbeiten müssen, wer und ok Ihre PCI-Compliance und Scoping Plan überprüfen.

Es ist durchaus möglich, dass ein QSA könnte sagen, dass da Sie Ihre Web-Seite zu steuern muss es unter PCI sein, da es von jemandem beschädigt werden könnte. Aber das wäre ein Argument aufdringlich sein. Schließlich könnte man dann sagen, dass jede Web-Seite von jedem Internet-Händler Bedürfnisse unter PCI sein, da jede Web-Seite Menschen für eine PAN könnten beschädigt werden, stellen und dann mit ihm etwas Schlechtes zu tun. Auf der anderen Seite ist dies genau die Art von Argumente, dass Visa PCI Umfang zu erhöhen, für Corporate Franchise-Geber verwendet. Artikel .

PCI-Zertifizierung ist keine Entschuldigung Beachten Sie, dass die Kartengesellschaften das Recht vor, Sie zu treten, wenn Sie einen Einbruch in haben - auch wenn Sie PCI-konform waren. So können Sie sicher sein wollen, dass Sie ein sehr viel härteres Ziel als jeder andere auf dem Block sind.

Hinzugefügt: Mehr zu Scoping Wie Sie aus den oben sagen kann, ein wichtiges Thema ist, welche Systeme sind in den oder aus PCI-Scope. Der PCI Council hat nun eine Special Interest Group (SIG) Prüfung dieser ganzen Frage, was in ist und was von PCI Rahmen ist aus. Und meine Vermutung ist, dass sie der Umschlag wollen würden wachsen, nicht schrumpfen.

Hinzugefügt: Es ist zwischen Ihnen und Ihrem Anwalt hat Ihr Szenario den Beginn des PAN auf Browser getan Verarbeitung Ihrer Kunden. Die PAN erreicht nie Ihre systems, nicht einmal für einen Augenblick. Also meine Interpretation ist, dass Sie von Händlern PCI DSS Umfang unterwegs sind. Aber du bist derjenige, der die PCI-Compliance-Erklärung unterzeichnen, die ist ein Vertrag zwischen Ihnen und Ihrem Acquirer. So ist es an Ihnen und Ihrem Anwalt die PCI-DSS-Standard zu interpretieren, nicht ich.

Fazit Sie sollten nie speichern PAN Daten auf dem System. Sie sollten es nicht einmal Transit Ihre Systeme. New Payment Gateway Protokolle von Authorize.Net und Braintree ermöglichen, die nicht-Transit-Technik. Abhängig von Ihrem Volumen von Kreditkartentransaktionen, ändert sich die PCI-Compliance von einer selbstverwalteten Checkliste zu einem großen Projekt.

Für weitere PCI-Krieg-Geschichten, überprüfen Sie die StorefrontBacktalk Blog und ihre PCI Abdeckung .

Andere Tipps

Larry K Antwort ist gut. Es ist vor allem eine politische / Schicht Sache.

Es scheint, dass für die Buchung von B mithilfe eines iframe auf A ist eine akzeptierte Lösung, während Ajax - mit CORS oder JSONP - ist etwas fraglich, aber immer noch, zumindest für einige große Spieler, akzeptabel

.

Informationen Ergänzung: PCI DSS E-Commerce-Richtlinien v2 Nähte zu sagen, dass diese Lösung (Direct-post API) ist in Ordnung, aber dass Sie sollte , um Code kümmern uns sicher (obwohl PCI DSS nicht verschreiben etwas konkretes tut Sie tun müssen, würde) - siehe Abschnitt 3.4.3.1 von Drittanbietern Embedded-APIs mit Direkt Beitrag und die damit verbundenen 3.4.3.4 Sicherheitsüberlegungen für Shared-Management E-Commerce-Implementationen , der wie folgt lautet:

  

Direkt-post-API-Ansatz : Mit dem direkten-post-API-Ansatz, der   Kaufmann ist immer noch verantwortlich für die Webseite, die vorgestellt   die Verbraucher und die Händler-Hosts die Felder auf der Zahlungsseite   akzeptieren, dass die Daten nur für die Karteninhaberdaten gebucht werden direkt aus   der Verbraucher an den Dienstanbieter. Da die Zahlungsseiten sind   durch den Händler gehostet sind die Zahlungsseiten nur so sicher wie die   Händler-Website, und ein Kompromiss des Systems des Händlers konnte   führen zu einem Kompromiss von Zahlungskartendaten.   ...   Speziell für alle der oben genannten Szenarien, sollte der Händler   Überwachung für jeden Beweis, dass die Systeme geändert haben und reagieren schnell   Systeme mit einem vertrauenswürdigen Zustand wiederherzustellen, wenn nicht autorisierte Änderungen sind   detektiert. Händler, die dieses Shared-Management übernehmen Outsourcing   Modelle anwendbar PCI DSS-Anforderungen minimieren sollten beachten   die möglichen Risiken, die auf diese Art von systemimmanenten   die Architektur. Um die Wahrscheinlichkeit eines Angriffs in diesen Szenarien zu minimieren,   Händler sollten besondere Sorgfalts gelten die Bahn, um sicherzustellen,   Anwendung entwickelt wird sicher und erfährt gründliche Durchdringung   Testen.

Zum Beispiel die Stripe Payment Gateway nutzt Direkt Post über JSONP seit 2012 anstelle des iframe Ansatz haben sie verwendet vor.

Auf der anderen Seite, WePay bietet auch einen direkten post-API aber empfiehlt iframe vollständig von PCI-Anforderungen zu befreien [WP] (behauptet, dass mit dem direkten post-API „ [..] Sie sind immer noch Card Industry Data Security Standards (PCI-DSS) und die Payment Application Data Security Standards (PA-DSS), wenn anwendbar erforderlich, um mit der Zahlung kompatibel sein. “(ohne Angabe, was genau " wann immer anwendbar" bedeutet).

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

Ich habe vor kurzem durch einig PCI-Compliance-Arbeit für unseren Server gegangen, so dass diese direkt vor mir ist. Die kurze Antwort ist nein.

PCI-Compliance erfordert, dass jeder Schritt des Weges, durch die die sensible Informationen geht PCI-Anforderungen an und für sich erfüllt. Etwas kann sicher sein, aber nicht kompatibel ist, wie Sie in Bezug auf Firma B. festgestellt Da Sie bereits festgestellt, dass Unternehmen B nicht PCI-kompatibel ist, aber Unternehmen B die Kreditkarteninformationen über ihre eigene Website sammelt, dann den gesamten Prozess, logisch ist nicht konform.

Ob ein PCI-Compliance-Service verbindet tatsächlich diese Punkte und wie sie sich bestätigen, es als Bestehen oder Nichtbestehen kann eine andere Sache sein.

Unabhängig davon, ob es „technisch“ erfüllt PCI-Standards (oder nicht), würde ich nicht auf diese Weise setze mein Vertrauen, Dinge zu tun.

Wenn das Formular auf einer Seite innerhalb B Hostnamen ist, hat B vollständigen Zugang zu dem, was in den Formularfeldern ist. (B der Server ist in der Lage, den Benutzer bösartiger JavaScript senden, wenn es will.)

Der sicherste Weg, es zu tun (in Bezug auf Kreditkartennummern zu schützen) innerhalb des Host-Namen des Zahlungsdienstes das Formular vollständig zu setzen, anstatt auf einem nicht vertrauenswürdigen Hostnamen.

Hier ist die PCI Webseite

Im Grunde, möglicherweise, wenn Sie die Kartennummer oder eine identifizierende Informationen über die Karte sehen können, müssen Sie mit pci Anforderungen erfüllen. Ich bin nicht sicher, dass sie unbedingt ein juristisches Dokument ‚noch‘ ist, aber wenn Sie eine Verletzung, Ihre Fähigkeit, gefunden worden sind, oder sein kann ein Teil eines Transaktionsprozesses widerrufen werden. Weiterhin als Händler Sie eine Vereinbarung über Ihre Haftung und Opt-in einen Prozess unterzeichnen, wo die Kreditkarten-Unternehmen Sie eine Fein können. Alle für das Privileg, Kreditkarten akzeptieren.

Für Spaß ist hier ein (pdf) Link auf die Seite 38 'Quick' Führer .

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top