Si j'ai une application Web et que je reçois des données de carte de crédit transmises via une requête de courrier par un navigateur Web via HTTPS et ouvrez instantanément une prise (SSL) à un processeur de carte de compilant PCI distant pour transférer les données et attendre une réponse , suis-je autorisé à faire ça? ou est-ce que cela reçoit les données avec ma candidature et le transférer déjà de «traitement des données de carte de crédit»?
Si je crée un iframe qui est affiché dans un navigateur client pour saisir des données CC et que cette iframe publie les données via HTTPS vers le processeur de carte distante (directement!) Est-ce déjà un cas de traitement des données de carte de crédit? Même si mon code d'application "ne touche pas" les données saisies avec des gestionnaires d'événements?
Je suis intéressé par la définition "Traitement des données de carte de crédit". Quand commence-t-il à être une application de traitement de données CC? Quelqu'un peut-être peut-être signaler à cette section de la norme PCI-DSS qui définit clairement lorsque vous commencez à «être une application de traitement»?
merci,
4 Réponses :
Vous transmettez les données, même si vous ne faites rien avec elle vous-même. Par conséquent, vous tombez sous des règles de conformité PCI.
PCI DSS v .2.1, page 5, sous les informations d'applicabilité DSS PCI:
Les exigences DSS PCI sont applicables si un numéro de compte principal (PAN) est stocké, traité ou transmis. Si une casserole n'est pas stockée, traitée, ou transmis, les exigences PCI DSS ne s'appliquent pas.
Section PCI DSS 4.1, par exemple, nécessite un cryptage lors de la transmission de réseaux publics / ouverts, que vous avez couverts par SSL et HTTPS aux deux extrémités.
Mais il n'y a pas que les exigences concernant les transactions directes avec les données de la carte. Il existe également des contrôles d'authentification utilisateur, tels que la section PCI DSS 8.x, en particulier pour les utilisateurs ayant accès aux données de titulaire de carte ou aux capacités administratives.
Bien que vous puissiez ignorer puisque vous ne stockez pas les données de la carte, d'autres sections traitent des éléments tels que la sécurité du réseau, les pare-feu, l'antivirus, le contrôle d'accès, la surveillance et le suivi, les tests, etc.
C'est une bonne question, et j'aimerais entendre des réponses faisant autorité - de quelqu'un représentant directement les PCI-DSS ou au moins une QSA avec accès aux membres PCI.
Ma réponse non autorité serait que le serveur Web héberge que l'IFrame serait en mesure de PCI et que vous seriez classé en tant que fournisseur de services. Ceci est basé sur mon interprétation de la norme PCI, où le glossaire états:
Fournisseur de service Entité commerciale qui n'est pas une marque de cartes de paiement membre ou un commerçant directement impliqué dans le traitement, le stockage, transmission, et commutation ou Données de transaction et titulaire de la carte informations ou les deux (* 1). Ça aussi comprend des entreprises qui fournissent Services aux marchands, services prestataires ou membres qui contrôlent ou pourrait avoir une incidence sur la sécurité de Données du titulaire de la carte (* 2). Les exemples comprennent fournisseurs de services gérés qui Fournir des pare-feu, des identifiants gérés et d'autres services ainsi que l'hébergement prestataires et autres entités. Entités telles que les télécommunications entreprises qui fournissent seulement Liens de communication sans accès à la couche d'application du Le lien de communication est exclu (* 3)
* 1. Vous n'êtes clairement pas une marque de cartes de paiement (telle que VISA), vous n'êtes pas un commerçant (à qui vous fournissez ce service)
* 2. C'est assez clair votre rôle, comme fournissant un service
* 3. Malheureusement, je ne pense pas que vous rencontrez cette exclusion, car vous avez accès aux données de la couche d'application.La bonne nouvelle est que l'approche que vous avez prise est probablement la meilleure que vous puissiez faire pour minimiser vos maux de tête.
Idéalement, vous vous partez ce serveur afin que l'accès à un réseau plus large (interne) soit très restreint. Assurez-vous que la seule «application» du serveur Web fournit est cette iframe (c.-à-d. N'exagorez pas d'autres pages Web du serveur). Assurez-vous que la journalisation que le serveur / iframe / etc génère ne contienne pas de données liées à la carte
Malheureusement, je crois que cela signifie que une QSA doit être impliquée, car vous traitez des transactions Web.
Oui, tu as raison. offrant tout mode de paiement accepte une carte de crédit même si vous n'avez pas créé le HTML pour le champ de formulaire (en cas d'iframe), a besoin d'une attention pci (pas de PCI-DSS), mais si vous créez le HTML vous-même même si vous ne le transmettez pas à un Serveur de votre système mais directement à la passerelle distante, les PCI-DSS s'appliquent.
Oui, votre application se présente sous la portée d'un audit PCI. Toutefois, étant donné la nature de l'application est très simple, il serait plus facile (par rapport aux demandes de paiement épanouies pour être conforme à la norme PCI-DSS). Enfin, si vous utilisez la technique mentionnée iframe, vous ne serez pas en train de traiter / transmettre une partie des informations relatives à la carte et ainsi, peut être considéré comme un fournisseur d'applications de paiement à la place.
Pensez comme un pirate informatique - Si un pirate informatique a gagné un accès à votre site / serveur, pourrait-ils altérer de manière à ce que l'IFrame passe à une passerelle de paiement malveillante. Il existe des QSAS (auditeurs PCI) qui insistent dans la portée et tout ce qui tourne autour du site Web (développement, support, test, opérations) doit être effectué de manière compatible PCI.
simple - si le numéro CC est toujours n'importe où sur votre serveur, même de la mémoire, vous le traiterez et soumis à ces exigences PCI.