Meilleures pratiques pour stocker des informations bancaires dans une base de données
Résumé des réponses:
Ne le fais pas. Les implications juridiques et financières seront désastreuses. Recherchez des solutions tierces établies ou faites appel à un expert. Ne stockez jamais d'informations sensibles sur un serveur partagé. Recherche du mécanisme de cryptage le plus approprié.
Je crée un site Web pour un client qui doit stocker les informations bancaires de ses clients (numéro d'acheminement + numéro de compte) dans la base de données pour le dépôt direct. Voici quelques détails:
1) Le site Web sera initialement sur un serveur d'hébergement partagé (ceci est ma première préoccupation).
2) J'utilise PHP/MySQL.
3) Je prévois d’utiliser mcrypt.
4) La clé sera située en dehors de la racine Web.
S'il vous plaît laissez-moi savoir vos pensées. Si possible, merci de me fournir des informations sur le traitement ACH.
Merci!
EDIT: Je m'attendais à une telle réponse car je suis terrifié par les problèmes de sécurité là-bas aussi. J'ai exprimé mon inquiétude à mon client et ce sera un bon support.
EDIT 2: ira loin de cela. Était pas heureux avec l'idée en premier lieu! Enquêter sur l'API de paiement en masse de Paypal.
Je pense que vous pouvez résoudre ce problème sans stocker aucune information bancaire vous-même en utilisant quelque chose comme API de paiement en masse de Paypal . De cette façon, votre client peut payer des personnes et Paypal stocke toutes les informations pour vous éviter de le faire.
Si vous souhaitez en savoir plus sur toutes les étapes à suivre pour sécuriser à distance les données financières sensibles de votre client, consultez la page " Conformité PCI ".
Si vous n'avez pas peur de stocker des données financières en ligne, vous êtes horriblement naïf.
1) Le site Web sera initialement sur un serveur d'hébergement partagé (ceci est ma première préoccupation). - REALY BAD. Le fait de ne pas avoir de contrôle administratif absolu sur le serveur et de pouvoir garder les autres personnes à l’écart est un très gros problème.
Je serais vraiment préoccupé par le fait que vous accédez directement à la base de données à partir du serveur Web frontal. C'est un gros non-non avec des données financières.
Même si vous avez le meilleur algorithme de cryptage, empêchez quelqu'un de détourner votre système et de l'utiliser pour déchiffrer les données. Ils n'auront pas besoin de la clé, ils auront juste besoin de votre application pour faire le travail à leur place. Cela suppose que vous utilisez une clé unique pour chiffrer et déchiffrer les données ou que vous récupérez les données de la base de données pour les montrer aux utilisateurs du système.
Ok voici la chose. Si vous devez poser ces questions, vous ne disposez pas de l'expertise technique pour le faire correctement. Je n'essaye pas de paraître méchant, c'est juste un fait. J'irais travailler avec un groupe de personnes expérimentées qui le font en premier. Beaucoup de choses qui ne sont pas mentionnées ici devront être prises en compte. il y a beaucoup de choses sur la sécurité qui ne sont pas écrites en soi. Des choses que vous ne remarquerez pas en lisant un livre. C'est une chose vraiment difficile à construire, car les personnes qui s'introduisent dans les systèmes financiers tirent de grands avantages.
Ne le fais pas.
Toutefois, si vous devez le faire, utilisez un crypto à clé publique/privée. Stockez et utilisez uniquement la clé publique pour chiffrer les données stockées dans la base de données. Stockez la clé privée dans un emplacement sécurisé (ce qui signifie: pas le serveur hébergé, mais une machine locale "sécurisée" avec les contrôles d'accès appropriés). Si nécessaire, téléchargez les données sur la machine locale, utilisez la clé privée pour les déchiffrer, et c'est parti.
Mais sérieusement, trouvez un moyen d'éviter de le faire si vous le pouvez.
Parlez à un avocat de vos responsabilités potentielles avant de continuer. Le fait que des données bancaires personnelles soient stockées sur un serveur d'hébergement partagé crée un danger. Vous ne contrôlez pas qui peut en fin de compte mettre la main sur les données.
La préoccupation supplémentaire est que ce ne sont pas les données de vos clients, mais celles de client ! Vous pourrez peut-être conclure un accord avec votre client pour vous indemniser, mais pas lorsque leurs clients sont impliqués. Une fois que les données sont compromises, ils reviennent vers vous avec des clients qui respirent par le cou!
Pour les informations bancaires, votre serveur doit être sous leur contrôle et ne pas être partagé.
De plus, mcrypt n'est pas très sécurisé. Je sais que c'est intégré, mais je suggérerais quelque chose qui ne soit pas aussi piratable, tel que RSA. Si quelqu'un récupère les informations, il ne devrait pas être en mesure de les pirater sans clé privée.
Je suis d'accord avec les autres - c'est une très mauvaise idée.
Les serveurs dédiés peuvent coûter entre 79 et 99 dollars par mois. Si cela n’est pas abordable, je me demande vraiment pourquoi ils traitent les informations bancaires pour commencer. La méthode préférée serait que la base de données soit séparée de la boîte Web dans ce cas également. De préférence, avec quelques pare-feu et autres protections (c’est-à-dire deux pare-feu, un devant le serveur Web et l’autre entre le serveur Web et la base de données).
Mais tout serait mieux que d’utiliser un hébergement partagé. Je veux dire, vous pouvez vous connecter directement au serveur SQL et voir toutes les bases de données disponibles - comment serait-il facile d’intervenir directement avec un piratage minimal?
Aussi, s'il vous plaît dites-moi le nom du site afin que je ne m'inscris jamais et que je mette mes informations bancaires dessus !!! :)
Assurez-vous également que vous avez une assurance contre les erreurs et la mise en service avant de procéder à l'hébergement mutualisé.
Je faisais face à une situation similaire à la vôtre, et je l'ai résolue de cette façon.
- Puisque vous ne ferez pas de traitement ACH, déterminez si l'API de traitement ACH est capable de créer un client.
- Si oui, cet objet client comprendra normalement le numéro de compte, le numéro de routage, etc., et stockera le jeton dans votre base de données. (Ainsi, lorsque l'utilisateur donne ses informations, vous les transmettez directement à votre processeur ACH via HTTPS et vous enregistrez le jeton).
- Chaque fois que vous devez débiter leur compte, transmettez ce jeton au processeur, et c'est tout!
De cette façon, vous n'enregistrez aucun numéro de compte ni de numéro de routage dans votre base de données, et même si quelqu'un pirate la base de données, il ne voit que les jetons, ce qui est plutôt inutile. Ils ne peuvent rien en faire, car il s'agit d'un processeur ACH spécifique.
J'ai fait la même chose pour les cartes de crédit avec Stripe.
Bonne chance!
Vous n'avez pas d'expérience dans ce domaine, et vous ne pouvez même pas trouver des boîtes de conserve de cette taille dans un club-entrepôt. Dans ce cas, votre client doit faire appel à un expert du domaine. si vous souhaitez faire ce type de travail à l'avenir, essayez de travailler en étroite collaboration avec l'expert et absorbez autant de connaissances que possible.
Je pense que tout le monde ici a assez manifesté son dégoût pour la situation. Je vais donc laisser tomber un soupçon sur un autre problème lorsque vous utilisez un type de crypto (ce dont nous conviendrons que cela est nécessaire):
Les données doivent être cryptées quelque part!
Si vous le faites sur le serveur, un serveur compromis se chargera simplement de votre chiffrement et les transmettra sans les chiffrer.
Si vous le faites sur le client, ceci est un peu plus sécurisé, mais laisse toujours la porte grande ouverte si quelqu'un a accès à votre serveur: il peut en théorie simplement ouvrir un trou XSS (c'est-à-dire insérer un script distant dans votre page .. .) qui envoie une copie à leur boîte avant de chiffrer ...
En fin de compte: si vous envisagez réellement de le faire sur un serveur qui pourrait ne pas être sécurisé à 110%, WALK AWAY .