Question

J'ai cette idée, mais je ne suis pas sûr si elle est conforme PCI. Je suis nouveau dans l'arène de la conformité PCI et je suis curieux de savoir si ce scénario constitue une violation PCI.

Alors, configurons le scénario. La société A est conforme PCI et dispose d'un service Web sur https exposant les bits de fonctionnalité dans le traitement des paiements. La société B est non conforme, mais leur site est sécurisé.

Voici les étapes du scénario.

  1. Les contacts du site de B de webservice de A via le code côté serveur. Ce service renvoie un jeton authetication crypté.
  2. B injecte ce jeton dans une page contenant un formulaire pour recevoir des informations de carte de crédit.
  3. L'utilisateur saisit leurs informations de carte de crédit sur le site de B.
  4. Les informations de forme, ainsi que le jeton, sont envoyés via un appel ajax au webservice de A.
  5. Le webservice de A traite les données et recrache un statut (approuvé / Refusé / etc)

La question est, puisque le javascript va directement de la machine de l'utilisateur aux serveurs conformes de la société A, est-il conforme aux normes PCI? Je suis très intéressé de savoir ce que les experts dans ce domaine pensent.

Était-ce utile?

La solution

brochure sur PCI DSS Tous les normes PCI

PCI DSS (Payment Card Industry Les données standard de sécurité) a le concept de "portée" -. Déterminer quels systèmes sont chapeautées PCI

vous êtes un commerçant ou un fournisseur de logiciel? Si le PAN (numéro de compte primaire), long numéro de carte de crédit, n'est jamais envoyé à votre site Web, votre site Web est généralement pas dans le champ PCI. - En supposant que vous êtes le commerçant. Si vous êtes un fournisseur de logiciels, votre logiciel serait probablement dans le cadre de la PA-DSS (voir ci-dessous).

PAN transitant votre serveur La vieille idée était que le PAN sera envoyé à votre site Web (par une soumission de formulaire de navigateur), votre site tournerait autour et l'envoyer à une passerelle de paiement (par exemple Authorize.Net). Dans ce scénario, le PAN n'a jamais été stocké sur votre serveur, mais a fait transport votre serveur. Cela sert à signifier que vos systèmes marchands ne seraient pas sous la portée PCI DSS car ils ne stockaient le PAN. Mais ces jours se terminent rapidement ou sont déjà partis. (Qui dépend de la façon dont le fournisseur agressif de votre acquéreur / compte marchand est sur le PCI.)

Le contrôle de votre page web Depuis votre page Web ne transmet pas de PAN sur votre serveur, vous n'êtes pas dans le champ d'application PCI. Mais comment savez-vous que quelqu'un n'a pas changé votre page Web pour transmettre le dos PAN sur votre serveur (ou ailleurs, en utilisant des techniques JSONP)? La réponse est que vous devez vous assurer que personne ne va trafiquer vos formulaires de paiement page.

Comment vous vous assurer de cela est à vous. Vous pouvez utiliser les techniques PCI ou d'autres techniques. Ceci est une question de votre sécurité informatique interne et de l'audit.

Paiement Application Data Security standard (PA-DSS) Si vous vendez votre sw pour les commerçants il serait alors probablement dans le cadre de la norme PA-DSS. Voir la norme .

PCI est politique, et non technique Rappelez-vous que portée PCI est à vous. Si vous êtes un marchand assez grand, alors vous aurez également besoin de travailler avec un QSA (Qualified Security Assessor) qui examinera et ok votre conformité PCI et le plan de la portée.

Il est certainement possible qu'un QSA pourrait dire que puisque vous contrôlez votre page web, il doit être sous PCI car il pourrait être corrompu par quelqu'un. Mais ce serait un argument arrivistes. Après tout, vous pouvez alors dire que chaque page web de tous les besoins de marchands d'Internet d'être sous PCI depuis une page Web pourrait être endommagée pour demander aux gens un PAN puis faire mal quelque chose avec elle. D'autre part, c'est exactement le genre d'argument que Visa utilise pour augmenter la portée du PCI pour les franchiseurs d'entreprise. Article .

certification PCI est pas une excuse Notez également que les associations de cartes se réservent le droit de vous lancer si vous avez une entrée par effraction - même si vous étiez conforme aux normes PCI. Donc, vous voulez être sûr que vous êtes une cible beaucoup plus difficile que quelqu'un d'autre sur votre bloc.

Ajouté: En savoir plus sur la portée Comme vous pouvez le dire de ce qui précède, une question clé est que les systèmes sont ou hors de portée PCI. Le Conseil PCI dispose désormais d'un groupe d'intérêt spécial (SIG de) l'examen de cette question de ce qui est et ce qui est hors de portée de PCI. Et je pense qu'ils vont vouloir l'enveloppe à croître, pas rétrécir.

Ajout: Il est entre vous et votre avocat Votre scénario a le début du traitement PAN fait sur les navigateurs de vos clients. Le PAN n'a jamais atteint vos systems, pas même pour un instant. Donc, mon interprétation est que vous êtes hors de portée PCI DSS Merchant. Mais vous êtes une signature de la déclaration de conformité PCI qui est un contrat entre vous et votre acquéreur. Il est donc à vous et votre avocat pour interpréter la norme PCI DSS, pas moi.

Bottom line Vous devriez jamais stocker des données PAN sur vos systèmes. Vous ne devriez pas avoir même le transport de vos systèmes. De nouveaux protocoles de passerelle de paiement de Authorize.Net et Braintree permettent la technique sans transit. En fonction de votre volume de transactions par carte de crédit, la conformité PCI varie d'une liste de contrôle auto-administré à un énorme projet.

Pour plus de PCI guerre des histoires, consultez StorefrontBacktalk blog et leur couverture PCI .

Autres conseils

La réponse de Larry K est bon. Il est surtout une chose politique / couche.

Il semble que l'utilisation d'un iframe pour l'affichage de B à A est une solution acceptée, tout en utilisant Ajax - avec CORS ou JSONP - est un peu plus discutable, mais encore, au moins pour quelques grands joueurs, acceptable

.

Le Complément d'information: PCI DSS pliures E-commerce v2 Lignes directrices pour dire que cette solution (directe post API) est OK, mais que vous prendre soin au code en toute sécurité (bien que PCI DSS ne béton rien ne prescrira pas vous devez faire) - voir la section 3.4.3.1 tiers API intégrées avec direct post et les liés 3.4.3.4 Considérations sur la sécurité pour Implémentations E-commerce partagée gestion , qui se lit ainsi:

  

API Direct post approche : Avec l'approche de l'API directe après, la   marchand est toujours responsable de la page Web qui est présenté à   la consommation, et les hôtes de marchands les champs sur la page de paiement   qui acceptent les données seules les données des détenteurs de cartes sont affichées directement de   le consommateur au fournisseur de services. Étant donné que les pages de paiement sont   hébergé par le commerçant, les pages de paiement sont aussi sûr que la   site web marchand, et un compromis du système du marchand pourrait   conduire à un compromis des données de carte de paiement.   ...   Plus précisément, pour tous les scénarios ci-dessus, le marchand doit   surveiller toute preuve que les systèmes ont changé et répondre rapidement   pour restaurer les systèmes à un état de confiance lorsque des changements non autorisés   détectée. Les commerçants qui adoptent ces gestion partagée sous-traitées   modèles pour minimiser les exigences applicables PCI DSS doivent être conscients   les risques potentiels inhérents à ce type de système   architecture. Pour réduire les risques d'attaque dans ces scénarios,   les commerçants devraient appliquer une diligence raisonnable supplémentaire pour assurer le web   application est développée en toute sécurité, et subit une pénétration complète   test.

Par exemple, le passerelle de paiement utilise Stripe post direct sur JSONP depuis 2012 au lieu de l'approche qu'ils ont iframe utilisé avant.

Par contre, WePay fournit également une API directe post mais iframe recommande de se débarrasser complètement des exigences PCI [WP] (affirmant que l'API directe après « [..] vous êtes toujours nécessaire pour être conforme à l'industrie des cartes de paiement normes de sécurité des données (PCI-DSS) et l'application de paiement normes de sécurité des données (PA-DSS) le cas échéant. »(sans préciser exactement « signifie à chaque fois applicables »).

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

Je suis récemment passé par un travail PCI-conformité pour nos serveurs, donc cela est juste devant moi. La réponse courte est non.

conformité PCI exige que chaque étape de la voie à travers laquelle passe l'information sensible répond aux exigences PCI en soi. Quelque chose peut être sécurisé, mais non conforme, comme vous l'avez dit au sujet de la société B. Comme vous avez déjà déclaré que la société B ne sont pas conformes aux normes PCI, mais la société B recueille les informations de carte de crédit via leur propre site web, l'ensemble du processus, est logiquement non conforme.

Que ce soit un service PCI-conformité relie effectivement ces points et comment ils certifierait comme passage ou ne peut être une autre affaire.

Peu importe si elle « techniquement » est conforme aux normes PCI (ou non), je ne serais pas mis ma confiance dans cette façon de faire.

Si le formulaire est sur une page dans le nom d'hôte B, B a un accès complet à ce qui est dans les champs de formulaire. (Le serveur B est capable d'envoyer l'utilisateur JavaScript malveillant si elle veut.)

La façon la plus sûre de le faire (en termes de protection des numéros de carte de crédit) est de mettre la forme complètement dans le nom d'hôte du service de traitement des paiements plutôt que sur un nom d'hôte non sécurisé.

Voici le site PCI

Fondamentalement, si vous pouviez voir le numéro de carte ou de toute information permettant d'identifier la carte, vous aurez besoin de se conformer aux exigences pci. Je ne suis pas sûr qu'ils ne sont pas nécessairement un document juridique « encore », mais si vous êtes en violation trouvé, votre capacité à traiter, ou être peut être révoqué une partie d'un processus de transaction. En outre, comme un marchand que vous signez un accord au sujet de votre responsabilité et opt-dans un processus où les sociétés de cartes de crédit peuvent vous infliger une amende. Tout pour le privilège d'accepter les cartes de crédit.

Pour le plaisir ici est un (pdf) lien vers la page 38 Guide 'rapide' .

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top