Les meilleures pratiques pour le stockage des informations bancaires dans une base de données

Question

Résumé des réponses:
Ne pas le faire. Les conséquences juridiques et financières seront désastreuses. Recherchez des solutions de tiers établies ou d'embaucher un expert. Ne jamais stocker des informations sensibles sur un serveur partagé. La recherche pour le mécanisme de chiffrement le plus approprié.

Je suis un site Web pour buiding un client qui a besoin de stocker l'information bancaire de ses clients (routage + numéro de compte) dans le db pour le dépôt direct. Voici quelques particularités:

1) Le site sera d'abord sur un serveur d'hébergement partagé (ce qui est ma première préoccupation).
2) J'utilise PHP / MySQL.
3) Je prévois d'utiliser mcrypt.
4) La clé sera situé en dehors de la racine web.

S'il vous plaît laissez-moi savoir vos pensées. Si possible, s'il vous plaît me fournir des ressources sur le traitement ACH.

Merci!

EDIT: Je m'y attendais telle réponse que je suis terrifiée à l'idée des problèmes de sécurité là-bas aussi. J'ai exprimé mon inquiétude à mon client et ce sera un bon soutien.

EDIT 2: repartirez de cette situation. Était pas heureux avec l'idée en premier lieu! Enquêterons de masse API de paiement de PayPal.

Answer 1

Je pense que vous pouvez résoudre ce problème sans enregistrer les informations bancaires vous-même en utilisant quelque chose comme Mass API de paiement de Paypal . De cette façon, votre client peut payer les gens, et les magasins PayPal toutes les informations afin que vous n'avez pas.

Si vous voulez lire sur toutes les étapes que vous devez prendre pour avoir même une possibilité à distance de sécurisation des données financières sensibles de votre client, google « conformité PCI '

Si vous n'êtes pas peur de stocker cadavérique des données financières en ligne, vous êtes horriblement naïf.

Answer 2

1) Le site sera d'abord sur un serveur d'hébergement partagé (ce qui est ma première préoccupation).    --VRAIMENT MAUVAIS. Ne pas avoir le contrôle administratif absolu sur le serveur, et être en mesure de garder d'autres gens est vraiment un gros problème.

Je serais vraiment inquiet que vous accédez directement à la base de données à partir du serveur Web frontal. C'est un grand non-non avec des données financières.

Même si vous avez l'algorithme de cryptage le plus puissant jamais, ce qui est d'empêcher quelqu'un de détournement de votre système et l'utiliser pour déchiffrer les données pour eux. Ils ne seront pas besoin de la clé, ils ont juste besoin de votre application pour faire le travail pour eux. Cela suppose que vous utilisez une seule clé pour chiffrer et déchiffrer les données ou vous récupérez les données du db pour montrer aux utilisateurs du système.

Ok, voici la chose. Si vous devez poser ces questions, vous n'avez pas l'expertise technique pour le faire correctement. Je ne cherche pas à son moyen, il est juste un fait. Je voudrais aller travailler avec un groupe de personnes chevronnés qui font professionaly premier. Il y aura beaucoup de choses qui ne sont pas mentionnés ici qui devront être pris en considération. il y a beaucoup de choses au sujet de la sécurité qui ne sont pas écrit en tant que tel. Les choses que vous ne détectera pas sur la lecture d'un livre. Ceci est une chose vraiment difficile à construire, becuase il y a de grandes récompenses aux personnes qui rompent dans les systèmes financiers.

Answer 3

Ne pas le faire.

Bu, si vous devez, utiliser Crypto clé publique / privée. Stocker et utiliser uniquement la clé publique pour chiffrer les données entrant dans la base de données. Rangez la clé privée dans un endroit sûr (ce qui signifie: pas le serveur hébergé, mais une machine locale « sécurisé » avec des contrôles d'accès appropriés). Si nécessaire, télécharger les données sur la machine locale, utilisez la clé privée pour le déchiffrer, et vous allez loin.

Mais sérieusement, trouver un moyen d'éviter de faire cela si vous le pouvez.

Answer 4

Parlez-en à un avocat au sujet de vos engagements potentiels avant de poursuivre. Avoir des données bancaires personnelles stockées sur un serveur d'hébergement partagé a danger écrit sur elle. Vous avez aucun contrôle sur qui peut finalement mettre la main sur les données.

autre préoccupation est ce n'est pas les données de votre client, il est de votre client du client données! Vous pourriez être en mesure de faire un accord avec votre client de vous indemniser, mais pas quand leurs clients sont impliqués. Une fois que les données sont compromis, ils vont tourner à droite vers vous avec les clients respiration dans leur cou en remorque!

Answer 5

Pour la banque d'informations, votre serveur doit être dans leur contrôle partagé.

En outre, mcrypt est pas très sûr. Je sais qu'il est construit, mais je dirais quelque chose qui est pas piratable tel que RSA. Si quelqu'un obtenir une prise de l'information, ils ne devraient pas être en mesure de pirater sans une clé privée.

Answer 6

Je suis d'accord avec les autres - ce qui est une très mauvaise idée

.

Les serveurs dédiés peuvent être eu pour entre $ 79- $ 99 par mois, si ce n'est pas abordable, je me demande vraiment pourquoi ils traitement de l'information bancaire pour commencer. Le meilleur moyen serait d'avoir la base de données séparée dans la zone Web dans ce cas aussi. De préférence, avec certains pare-feu et une autre protection entre eux (soit 2 pare-feu, une à l'avant du serveur web et une entre le serveur Web et la base de données).

Mais tout serait mieux que d'utiliser l'hébergement mutualisé. Je veux dire, vous pouvez connecter à droite au serveur SQL et de voir toutes les bases de données disponibles - comment serait-il facile de sauter à droite avec un minimum hacking

En outre, s'il vous plaît me dire le nom du site, donc je ne signerais jamais et mettre mes informations bancaires sur elle !!! :)

Aussi, assurez-vous que vous avez une assurance erreurs et ommission avant d'aller de l'avant avec hébergement mutualisé.

Answer 7

Je faisais face à une situation similaire comme vous, et résolu de cette façon.

1. Puisque vous ne serez pas en train de faire le traitement ACH, savoir si l'API de traitement ACH a la capacité de créer un client.
2. Si oui, cet objet client, comprendra normalement le numéro de compte, numéro de routage, etc, et stocker le jeton dans votre base de données. (Ainsi, lorsque l'utilisateur donne son information, vous passez directement à votre processeur ACH via HTTPS, et de sauvegarder le jeton).
3. Chaque fois que vous avez à débiter leur compte, transmettre ce jeton au processeur, et c'est tout !!

De cette façon, vous n'êtes pas enregistrer les numéros de compte et de routage sur votre base de données, et même si quelqu'un hacks la DB, ils voient juste des années jeton, ce qui est assez inutile - ils ne peuvent rien faire avec, comme il est ACH processeur spécifique.

Je l'ai fait la même pour les cartes de crédit en utilisant Stripe.

Bonne chance!

Answer 8

Vous n'avez pas d'expérience dans ce domaine, et vous ne pouvez pas trouver même des boîtes de vers ce grand dans un club d'entrepôt. Ceci est un cas où votre client a besoin d'embaucher un expert de domaine; si vous êtes intéressés à faire ce genre de travail à l'avenir, essayer de travailler en étroite collaboration avec l'expert et d'absorber autant de connaissances que vous pouvez.

Answer 9

Je pense que tout le monde ici a annoncé leur dégoût de la situation de assez, alors je vais simplement laisser tomber un soupçon sur un autre problème lorsque vous faites une sorte de Crypto (dont nous conviendrons est nécessaire):

Les données doivent être quelque part crypté!

Si vous le faites sur le serveur, bien un serveur compromis fera juste votre cryptage et les transmettre w / o les chiffrant.

Si vous le faites sur le client, cela est un peu plus sûr, mais laisse toujours la porte ouverte si quelqu'un a accès à votre serveur: Ils peuvent, en théorie, il suffit d'ouvrir un trou XSS (c.-à insérer un script à distance dans votre page ...) qui envoie une copie à leur boîte avant de le chiffrer ...

En fin de compte. Si vous considérez vraiment faire cela sur un serveur qui pourrait ne pas être 110% sûr, à pied