銀行情報をデータベースに保存するためのベストプラクティス
回答の要約：
それをしないでください。法的および財政的影響は悲惨なものになります。確立されたサードパーティのソリューションを探すか、専門家を雇います。機密情報を共有サーバーに保存しないでください。最も適切な暗号化メカニズムの研究。
私は、顧客の銀行情報（ルーティング+アカウント番号）を直接預金のためにデータベースに保存する必要がある顧客向けのWebサイトを構築しています。ここにいくつかの詳細があります：
1）Webサイトは、最初は共有ホスティングサーバー上にあります（これが私の最初の懸念事項です）。
2）PHP/MySQLを使用しています。
3）mcryptを使用する予定です。
4）キーはWebルートの外側に配置されます。
考えを教えてください。できれば、ACH処理に関するリソースを提供してください。
ありがとう！
編集：そこにあるセキュリティ問題も怖いので、私はそのような応答を期待していました。顧客に懸念を表明しました。これは良いサポートになります。
編集2：これから離れます。そもそもアイデアに満足していませんでした。Paypalの一括支払いAPIを調査します。
PaypalのMass Payment API のようなものを使用して、銀行情報を自分で保存せずにこの問題を解決できると思います。そうすることで、クライアントは人に支払うことができ、Paypalはすべての情報を保存するので、必要はありません。
クライアントの機密財務データを保護するリモートの可能性さえも持つために必要なすべてのステップについて読みたい場合は、google ' PCI Compliance '
財務データをオンラインで保存することを恐れていないのであれば、あなたはひどく初心者です。
1）Webサイトは、最初は共有ホスティングサーバー上にあります（これが私の最初の懸念事項です）。 - すごく悪い。サーバーに対する絶対的な管理制御を持たず、他の人を締め出すことができないことは、本当に大きな問題です。
フロントエンドWebサーバーからデータベースに直接アクセスしているのではないかと心配になります。これは、財務データに関しては大きな問題です。
これまでで最も強力な暗号化アルゴリズムを使用している場合でも、誰かがシステムを乗っ取り、それを使用してデータを解読するのを防ぐにはどうすればよいでしょうか。彼らはキーを必要としないでしょう、彼らは彼らのために仕事をするためにあなたのアプリケーションを必要とするだけです。これは、単一のキーを使用してデータを暗号化および復号化するか、システムのユーザーに表示するためにデータベースからデータを取得することを想定しています。
わかりました。これらの質問をする必要がある場合、これを正しく行うための技術的な専門知識がありません。私は卑劣に聞こえようとしているのではなく、それは単なる事実です。私は最初にこれを専門的に行うベテランの人々のグループと一緒に仕事に行きます。ここで言及されていないことを考慮に入れる必要のあることがたくさんあります。それ自体は書き留められていないセキュリティに関する多くのことが存在します。本を読んで得られないもの。金融システムに侵入した人には大きな報酬があるので、これは構築するのが本当に難しいものです。
しないでください。
Bu、もし必要なら、公開鍵/秘密鍵暗号を使用してください。公開鍵のみを保存して使用し、データベースに送られるデータを暗号化します。秘密鍵を安全な場所に保管します（つまり、ホストされたサーバーではなく、適切なアクセス制御を備えた「安全な」ローカルマシン）。必要に応じて、データをローカルマシンにダウンロードし、秘密鍵を使用してデータを復号化します。
しかし、真剣に、可能であればこれを回避する方法を見つけてください。
続行する前に、あなたの潜在的な責任について弁護士に相談してください。個人の銀行データを共有ホスティングサーバーに保存すると、そのすべてに危険が伴います。最終的に誰がデータを手に入れることができるかについて、あなたは制御できません。
さらに懸念されるのは、それが顧客のデータではなく、顧客のクライアントのデータであることです。あなたはあなたとあなたの顧客との契約を結ぶことであなたを補償することができるかもしれませんが、彼らのクライアントが関与しているときはできません。データが危険にさらされると、クライアントは首をかしげて呼吸を再開します。
銀行情報については、サーバーを共有せずに管理する必要があります。
また、mcryptはあまり安全ではありません。私はそれが組み込まれていることを知っていますが、RSAのようにそれほどハッキングできないものを提案します。誰かが情報を手に入れても、秘密鍵なしではハッキングできないはずです。
私は他の人に同意します-これは非常に悪い考えです。
専用サーバーは月額79〜99ドルですが、それが手頃な価格でない場合は、そもそもなぜ銀行情報を処理しているのでしょうか。この場合も、データベースをWebボックスから分離することをお勧めします。いくつかのファイアウォールとそれらの間の他の保護（つまり、2つのファイアウォール、1つはWebサーバーの前、もう1つはWebサーバーとデータベースの間にある）が望ましい。
しかし、何でも共有ホスティングを使用するより良いでしょう。つまり、SQLサーバーに直接接続して、利用可能なすべてのデータベースを表示できます。最小限のハッキングですぐにジャンプするのはどれほど簡単でしょうか。
また、サイトの名前を教えてください。サインアップして銀行情報を記載することはありません。 :)
また、共有ホスティングに進む前に、エラーと省略保険があることを確認してください。
私はあなたと同じような状況に直面していて、このように解決しました。
- ACH処理は行わないので、ACH処理APIが顧客を作成できるかどうかを確認します。
- はいの場合、この顧客オブジェクトには通常、アカウント番号、ルーティング番号などが含まれ、トークンがデータベースに格納されます。 （したがって、ユーザーが情報を提供すると、HTTPS経由でACHプロセッサーに直接渡して、トークンを保存します）。
- あなたが彼らの口座から引き落とさなければならないときはいつでも、このトークンをプロセッサーに渡してください、そしてそれだけです！
この方法では、アカウントとルーティング番号をデータベースに保存せず、誰かがDBをハッキングした場合でも、トークンは表示されますが、これはかなり役に立ちません。
Stripeを使用したクレジットカードについても同様です。
幸運を！
あなたはこの分野での経験がなく、倉庫クラブでこれほど大きなワームの缶を見つけることさえできません。これは、顧客がドメインの専門家を雇う必要がある場合です。将来この種の作業を行うことに興味がある場合は、専門家と緊密に協力して、できるだけ多くの知識を吸収してください。
私はここの誰もが十分に嫌悪感を表明していると思うので、何らかの暗号化を行うときは、別の問題のヒントをドロップします（同意する必要があります）。
データはどこかで暗号化する必要があります！
サーバーでそれを行う場合、侵害されたサーバーは暗号化を行い、暗号化せずに渡すだけです。
クライアントでこれを行うと、これはもう少し安全ですが、誰かがサーバーにアクセスできる場合はドアを開いたままにしておきます。理論的には、XSSホールを開けるだけです（つまり、リモートスクリプトをページに挿入します）。 。）暗号化する前にボックスにコピーを送信します...
結局のところ、110％安全ではない可能性があるサーバーでこれを行うことを本当に検討する場合は、WALK AWAYを使用してください。