銀行情報をデータベースに保存するためのベスト プラクティス
https://stackoverflow.com/questions/596706
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
回答の要約:
やめてください。法的、経済的影響は悲惨なものとなるだろう。確立されたサードパーティのソリューションを探すか、専門家を雇ってください。機密情報を共有サーバーに保存しないでください。最適な暗号化メカニズムの研究。
直接入金のために顧客の銀行情報 (ルーティング + 口座番号) をデータベースに保存する必要がある顧客向けの Web サイトを構築しています。具体的には次のとおりです。
1) Web サイトは最初は共有ホスティング サーバー上にあります (これが私の最初の懸念事項です)。
2) PHP/MySQL を使用しています。
3) mcrypt を使用する予定です。
4) キーは Web ルートの外側に配置されます。
あなたの考えを教えてください。可能であれば、ACH 処理に関するリソースを提供してください。
ありがとう！
編集：私もセキュリティ問題を恐れているので、そのような反応を期待していました。お客様に懸念を表明しましたので、これは良いサポートになると思います。
編集2:このことから立ち去ります。そもそもそのアイデアに満足していませんでした！PayPal の Mass Payment API を調査します。
解決
次のようなものを使用することで、自分で銀行情報を保存せずにこの問題を解決できると思います Paypalの一括決済API. 。そうすれば、クライアントは人々に支払いを行うことができ、PayPal がすべての情報を保存するので、あなたはその必要がなくなります。
クライアントの機密財務データを安全に保護するために必要なすべての手順を知りたい場合は、Google で検索してください。PCI コンプライアンス'
財務データをオンラインに保存することを死ぬほど恐れていないとしたら、あなたはひどく世間知らずです。
他のヒント
1) Web サイトは最初は共有ホスティング サーバー上にあります (これが私の最初の懸念事項です)。 - すごく悪い。サーバーに対する絶対的な管理制御を持たず、他のユーザーのアクセスを遮断できないことは、非常に大きな問題です。
フロントエンド Web サーバーからデータベースに直接アクセスしているのではないかと非常に心配です。これは財務データに関しては絶対に禁物です。
たとえ史上最強の暗号化アルゴリズムを持っていたとしても、誰かがあなたのシステムを乗っ取り、それを使ってデータを復号化することを防ぐにはどうすればよいでしょうか。彼らはキーを必要とせず、あなたのアプリケーションが彼らに代わって作業を行うことだけを必要とします。これは、データの暗号化と復号化に単一のキーを使用しているか、システムのユーザーに表示するためにデータベースからデータを取得していることを前提としています。
さて、ここからが問題です。これらの質問をしなければならない場合、あなたにはこれを正しく行うための技術的専門知識がありません。意地悪を言っているつもりはありません、それは単なる事実です。私なら、最初にこれを専門的に行う経験豊富な人々のグループと一緒に仕事をします。ここで言及されていないことも考慮する必要があることがたくさんあります。セキュリティについては、それ自体が文書化されていないことがたくさんあります。本を読んでも分からないこと。金融システムに侵入した人には大きな報酬があるため、これを構築するのは非常に困難です。
やめてください。
ただし、必要に応じて、公開/秘密キー暗号化を使用してください。データベースに入るデータを暗号化するために公開キーのみを保存および使用します。秘密キーを安全な場所に保管します (意味:ホストされているサーバーではなく、適切なアクセス制御を備えた「安全な」ローカル マシンです)。必要に応じて、データをローカル マシンにダウンロードし、秘密キーを使用して復号化すれば、すぐに使用できます。
しかし真剣に、可能であればこれを回避する方法を見つけてください。
続行する前に、潜在的な責任について弁護士に相談してください。個人の銀行取引データを共有ホスティング サーバーに保存すると、そのデータ全体に危険が伴います。最終的に誰がデータを入手できるのかを制御することはできません。
さらに懸念されるのは、それは顧客のデータではなく、顧客のデータであるということです。 クライアントの データ！顧客との間で補償する契約を結ぶことはできるかもしれませんが、顧客が関与している場合はそうはいきません。データが侵害されると、彼らはすぐにあなたのところに戻ってきて、顧客を引き連れて息を呑むでしょう。
銀行情報については、サーバーが共有されるのではなく管理下にある必要があります。
また、mcrypt はあまり安全ではありません。組み込まれていることは知っていますが、RSA などのそれほどハッキングされにくいものをお勧めします。誰かが情報を入手したとしても、秘密鍵がなければハッキングできないはずです。
私も他の意見に同意します。これは非常に悪い考えです。
専用サーバーは月額 79 ドルから 99 ドルで利用できますが、それが手頃でないなら、そもそもなぜ銀行情報を処理しているのか本当に疑問に思います。この場合も、データベースを Web ボックスから分離することが推奨される方法です。できれば、いくつかのファイアウォールとそれらの間に他の保護を配置します (つまり、2 つのファイアウォール、1 つは Web サーバーの前に、もう 1 つは Web サーバーとデータベースの間にあります)。
しかし、共有ホスティングを使用するよりも優れたものは何もありません。つまり、SQL サーバーに直接接続して、利用可能なすべてのデータベースを確認できるのです。最小限のハッキングですぐに利用できるとしたら、どれほど簡単でしょうか?
また、私がサインアップして銀行情報をサイトに登録しないように、サイトの名前も教えてください。:)
また、共有ホスティングを進める前に、エラーや不作為に対する保険がかかっていることを確認してください。
私もあなたと同じような状況に直面していましたが、この方法で解決しました。
- ACH 処理を実行しないので、ACH 処理 API に顧客を作成する機能があるかどうかを確認します。
- はいの場合、この顧客オブジェクトには通常、アカウント番号、ルーティング番号などが含まれ、トークンをデータベースに保存します。(そのため、ユーザーが自分の情報を提供すると、それを HTTPS 経由で ACH プロセッサに直接渡し、トークンを保存します)。
- 相手の口座から引き落としをする必要があるときは、このトークンをプロセッサーに渡すだけで完了です。
この方法では、データベースにアカウントやルーティング番号を保存することはありません。また、誰かが DB をハッキングしたとしても、トークンが表示されるだけで、まったく役に立ちません。ACH プロセッサー固有のものであるため、トークンを使って何もすることはできません。
Stripe を使用してクレジット カードに対しても同様のことを行いました。
幸運を！
この分野では経験がありませんし、倉庫クラブでもこれほど大きなワームの缶を見つけることはできません。これは、顧客がドメインの専門家を雇う必要がある場合です。将来この種の仕事に興味がある場合は、専門家と緊密に連携して、できるだけ多くの知識を吸収するようにしてください。
ここにいる誰もがこの状況に対する嫌悪感を十分に表明していると思いますので、あらゆる種類の暗号通貨を実行するときの別の問題についてヒントをドロップします（これは必要であることに同意します）。
データはどこかで暗号化する必要があります。
サーバー上でそれを行う場合、侵害されたサーバーは暗号化を実行し、暗号化せずに送信します。
クライアント上でこれを行う場合、これはもう少し安全ですが、誰かがサーバーにアクセスした場合にドアが大きく開いたままになります。理論的には、単純に XSS ホールを開けることができます (つまり、リモート スクリプトをページに挿入します...) 暗号化する前にコピーをボックスに送信します...
最後に：110% 安全ではない可能性のあるサーバーでこれを実行することを本当に検討している場合は、 歩いて行ってしまう.
