Convaincre l'entreprise de ne pas stocker les numéros de carte de crédit dans notre webapp
L'entreprise pour laquelle je travaille a besoin d'un système pour effectuer des débits mensuels par carte de crédit sur les comptes clients. Les clients pourront mettre à jour leurs informations de carte de crédit à partir d'une interface en ligne écrite en PHP (qui sera présentée via HTTP sur SSL). Les frais mensuels seront exécutés manuellement via un administrateur protégé par mot de passe zone de la même interface, ce qui équivaut essentiellement à un appel par lots à l'API Authorize.Net.
Mes collègues veulent stocker les informations de carte de crédit (cryptées) dans une base de données MySQL. Ils prévoient de crypter les numéros de carte de crédit avec l'extension mcrypt de PHP , probablement en utilisant Rijndael/AES ou Twofish. Le sujet de la gestion des clés a été passé sous silence, mais les deux options suivantes ont été mentionnées:
stocker les clés dans la base de données, avec une clé distincte pour chaque entrée de carte de crédit; ou
stocker une seule clé de cryptage pour toutes les entrées de carte de crédit dans un fichier PHP en tant que variable (similaire à la façon dont PHP des applications telles que WordPress et les informations d'identification de la base de données du magasin MediaWiki).
Comment puis-je les convaincre de ne pas suivre cette voie? Nous utiliserons Authorize.net pour le traitement des paiements, alors j'ai mentionné leur service Customer Information Manager comme alternative au stockage des informations de carte de crédit nous-mêmes. Cependant, je ne connais pas suffisamment le sujet pour faire un argument convaincant (mes arguments étaient "aucun de nous n'est expert en sécurité" et "je ne me sentirais pas à l'aise avec une entreprise qui stocke mes informations de carte de crédit de cette manière").
Si je n'arrive pas à les convaincre d'utiliser un service tiers comme Customer Information Manager, que dois-je conserver l'esprit afin de protéger les informations de carte de crédit des clients? En particulier, comment gérer les clés de chiffrement? Devrait-il y avoir une clé de cryptage distincte pour chaque entrée client? Où puis-je stocker les clés afin de pouvoir décrypter les informations de carte de crédit avant d'envoyer les transactions à Authorize.Net? Les deux options mentionnées ci-dessus ne me semblent pas très judicieuses (mais encore une fois, je ne connais pas assez bien le sujet pour faire un argument convaincant contre l'une ou l'autre).
Mise à jour : J'ai trouvé quelqu'un dans l'entreprise familier avec la conformité PCI DSS, donc je travaille avec lui pour faire Bien sûr, cela se fait correctement. Cependant, j'apprécierais toujours les réponses à mes questions ci-dessus (à la fois pour améliorer mes connaissances et pour aider les autres dans une situation similaire).
Mise à jour 2 : Succès! Un autre développeur s'est assis et a lu la directive PCI DSS et a décidé que c'était une mauvaise idée de stocker les informations nous-mêmes après tout. Nous allons utiliser Authorize.Net's Customer Information Manager service.
Le stockage des numéros de carte signifie que vous devez vous conformer aux exigences de la norme PCI-DSS, sinon vous risquez des amendes et une violation de votre contrat de compte marchand. PCI-DSS a un ensemble énorme d'exigences - certaines raisonnables, certaines onéreuses, d'autres d'une utilité douteuse - et le coût de sa conformité et de la certification que vous vous y êtes conformé peut être très élevé.
Téléchargez la norme PCI-DSS 2. et ayez peur.
En particulier, aucune des approches suggérées n'est compatible PCI-DSS. Les clés ne doivent pas être stockées sans protection ou au même endroit que les données du titulaire de carte qu'elles protègent.
Si vous devez l'implémenter en interne, vous devez isoler les composants qui touchent les numéros de carte de tout le reste, de sorte que PCI-DSS ne s'applique qu'à un nombre limité de systèmes. Regardez les solutions de tokenisation pour vous aider à réduire au minimum l'exposition des données de vos titulaires de carte. Si vous ne le faites pas correctement, vous pouvez facilement déposer tous vos serveurs (ou même tous vos postes de travail d'entreprise!) Dans la portée PCI, auquel cas la conformité devient difficile, voire impossible.
Authorize.net propose des services de facturation récurrente automatisée. Pour l'amour de la raison, utilisez-le.
"Aucun de nous n'est un expert en sécurité" et "je ne me sentirais pas à l'aise avec une entreprise qui stocke mes informations de carte de crédit de cette manière" sont des arguments tout à fait valables. D'un point de vue technique (sur le fond), ils devraient mettre fin à la discussion. Mais si vous discutez avec des gens qui ne sont pas des experts en sécurité, ils ne sont peut-être pas en mesure de reconnaître de bons arguments.
Donc, si vous trouvez que discuter sur le fond ne vous mène nulle part, retirez-vous The Sledgehammer of Compliance (fait +20 dégâts contre les bureaucrates). En particulier, rappelez-leur PCI DSS. Demandez-leur s'ils ont évalué le coût de la mise en conformité PCI DSS. Demandez-leur une analyse coûts-avantages du montant des revenus supplémentaires que cette fonctionnalité fournira (généralement, la réponse est: 0 ) et combien coûtera l'entreprise (généralement, la réponse est: grande). Dans la plupart des situations, ce sera la fin du jeu.
Ou, au moins, cela devrait mettre fin à la discussion. Si ce n'est pas le cas, parlez-en à vos gestionnaires, car il s'agit en fin de compte d'une décision commerciale, et ils devraient reconnaître très rapidement le bon appel.
Et si vos gestionnaires ne comprennent pas - eh bien, tout ce que je peux suggérer est: obtenir de nouveaux gestionnaires. Il est peut-être temps de mettre à jour votre CV.
Il ne semble pas que votre entreprise ait subi une évaluation PCI DSS sur place avant ou même essayé de répondre à toutes les questions de la SAQ D.Pour presque toutes les entreprises qui en ont, elles sont à la recherche d'un moyen de se débarrasser des données des titulaires de carte et en espérant que cela ne leur coûte pas trop cher. Si vous êtes à un point où il n'est pas encore coûteux de mettre en œuvre une solution, vous devez absolument stocker vos données avec Authorize.net ou un autre tiers.
Le meilleur argument que vous pouvez faire à vos collègues est d'expliquer la taille d'un PCI sans tracas et combien ce tracas est réduit si vous ne stockez pas vous-même les données du titulaire de la carte. Le maintien de la conformité PCI est un travail à temps plein. Si vous stockez des données de titulaire de carte, il y a tellement plus d'exigences que vous devez satisfaire afin de maintenir la conformité (le PCI DSS SAQ D est deux fois plus long que le SAQ C). Le déchargement des données est la façon la plus simple de procéder. Honnêtement, je n'envisagerais même pas de stocker les données vous-même.
La plupart des patrons/collègues ne comprennent pas nécessairement tous les problèmes "techniques" que vous pourriez leur présenter.
Par conséquent, vous devez les aborder dans un domaine qu'ils peuvent parfaitement comprendre - coût/argent.
L'une des choses que je trouve utiles pour expliquer cela est que si vous vous faites pirater et que des informations de carte de crédit sont volées, elles seront responsables non seulement des amendes, mais également des frais de réémission d'une nouvelle carte de crédit.
Par exemple: si votre entreprise possède 100 000 numéros de carte de crédit, cela leur coûterait un million de dollars pour remplacer ces cartes AVANT de payer des amendes, etc. (oh et par la manière dont le directeur financier peut aller en prison s'il n'est pas conforme à la norme PCI)
Tout comme ils ont une assurance pour leur propriété