54

回答の要約：
それをしないでください。法的および財政的影響は悲惨なものになります。確立されたサードパーティのソリューションを探すか、専門家を雇ってください。機密情報を共有サーバーに保存しないでください。最も適切な暗号化メカニズムを研究します。

直接預金のために、クライアントの銀行情報（ルーティング+アカウント番号）をデータベースに保存する必要がある顧客向けのWebサイトを構築しています。ここにいくつかの詳細があります：

1）Webサイトは最初は共有ホスティングサーバー上にあります（これが私の最初の懸念事項です）。
2）PHP/MySQLを使用しています。
3）mcryptを使用する予定です。
4）キーはWebルートの外側に配置されます。

感想を聞かせてください。可能であれば、ACH処理に関するリソースを教えてください。

ありがとう！

編集：私はそこにあるセキュリティの問題も恐れているので、そのような応答を期待していました。私はお客様に懸念を表明しました。これは良いサポートになります。

編集2：これから離れます。そもそもアイデアに満足していませんでした！PayPalの一括支払いAPIを調査します。

4

9 に答える 9

79

この問題は、 Paypal の Mass Payment APIなどを使用して、銀行情報を自分で保存しなくても解決できると思います。そうすれば、クライアントは人々に支払いを行うことができ、PayPal はすべての情報を保存するので、あなたはその必要がありません。

クライアントの機密財務データを保護する可能性を少しでも確保するために必要なすべての手順についてお読みになりたい場合は、「PCI コンプライアンス」を検索してください。

財務データをオンラインで保存することを恐れていないのであれば、あなたは恐ろしくナイーブです。

于 2009-02-27T21:32:30.127 に答える
15

1）Webサイトは最初は共有ホスティングサーバー上にあります（これが私の最初の懸念事項です）。 - すごく悪い。サーバーを完全に管理できないこと、および他の人を締め出すことができないことは、非常に大きな問題です。

フロントエンドWebサーバーからデータベースに直接アクセスしているのではないかと心配しています。これは、財務データでは大したことではありません。

これまでで最も強力な暗号化アルゴリズムを使用している場合でも、誰かがシステムを乗っ取って、それを使用してデータを復号化するのを防ぐにはどうすればよいですか。彼らは鍵を必要としません、彼らは彼らのために仕事をするためにあなたのアプリケーションを必要とするでしょう。これは、単一のキーを使用してデータを暗号化および復号化するか、データベースからデータを取得してシステムのユーザーに表示することを前提としています。

わかりました、これが問題です。これらの質問をする必要がある場合、これを正しく行うための技術的な専門知識がありません。私は意地悪に聞こえようとはしていません、それはただの事実です。私は最初にこれを専門的に行うベテランの人々のグループと一緒に仕事に行きます。ここで言及されていないことを考慮する必要があることがたくさんあります。セキュリティについては、それ自体は書き留められていないものがたくさんあります。あなたが本を読むことからあなたが拾わないであろうこと。金融システムに侵入した人々には大きな報酬があるため、これを構築するのは非常に困難です。

于 2009-02-27T21:14:15.130 に答える
14

しないでください。

Bu、必要に応じて、公開/秘密鍵暗号を使用してください。データベースに入力されるデータを暗号化するには、公開鍵のみを保存して使用します。秘密鍵を安全な場所に保管します（つまり、ホストされたサーバーではなく、適切なアクセス制御を備えた「安全な」ローカルマシン）。必要に応じて、データをローカルマシンにダウンロードし、秘密鍵を使用して復号化すれば、すぐに使用できます。

しかし、真剣に、可能であればこれを回避する方法を見つけてください。

于 2009-02-27T21:16:19.183 に答える
5

続行する前に、潜在的な責任について弁護士に相談してください。個人の銀行データを共有ホスティングサーバーに保存すると、その全体に危険が書き込まれます。最終的に誰がデータを入手できるかを制御することはできません。

さらに懸念されるのは、それは顧客のデータではなく、顧客のクライアントのデータです。あなたはあなたを補償するためにあなたの顧客と合意を結ぶことができるかもしれませんが、彼らの顧客が関与しているときはそうではありません。データが危険にさらされると、クライアントは首を絞めて息を吐きながら、すぐにあなたに戻ります。

于 2009-02-27T21:22:39.167 に答える
3

銀行情報については、サーバーは共有ではなく管理下にある必要があります。

また、mcryptはあまり安全ではありません。組み込まれていることは知っていますが、RSAなどのハッキング可能ではないものを提案します。誰かが情報を入手した場合、秘密鍵なしでそれをハッキングすることはできません。

于 2009-02-27T21:18:16.540 に答える
2

私は他の人たちに同意します-これは非常に悪い考えです。

専用サーバーは月額79ドルから99ドルの間で利用できますが、それが手頃な価格でない場合は、そもそもなぜそれらが銀行情報を処理しているのか疑問に思います。この場合も、データベースをWebボックスから分離することをお勧めします。できれば、いくつかのファイアウォールとそれらの間のその他の保護を使用します（つまり、2つのファイアウォール、1つはWebサーバーの前、もう1つはWebサーバーとデータベースの間にあります）。

しかし、共有ホスティングを使用するよりも何でも良いでしょう。つまり、SQLサーバーに直接接続して、利用可能なすべてのデータベースを確認できます。最小限のハッキングですぐにアクセスできるのはどれほど簡単でしょうか。

また、サイトの名前を教えてください。私がサインアップして銀行情報を載せることは決してありません!!! :)

また、共有ホスティングを進める前に、エラーと脱落保険があることを確認してください。

于 2009-02-27T21:24:07.183 に答える
2

私はあなたと同じような状況に直面していて、この方法で解決しました。

  1. ACH 処理は行わないため、ACH 処理 API に顧客を作成する機能があるかどうかを確認してください。
  2. はいの場合、この顧客オブジェクトには通常、アカウント番号、ルーティング番号などが含まれ、データベースにトークンが保存されます。(したがって、ユーザーが自分の情報を提供すると、HTTPS 経由で ACH プロセッサに直接渡し、トークンを保存します)。
  3. 彼らの口座から引き落とす必要があるときはいつでも、このトークンをプロセッサーに渡してください。

この方法では、データベースにアカウントとルーティング番号を保存することはありません。また、誰かが DB をハッキングしたとしても、トークンが表示されるだけです。これはまったく役に立ちません。ACH プロセッサ固有であるため、何もできません。

Stripe を使用して、クレジット カードについても同様のことを行いました。

幸運を！

于 2015-08-25T13:10:27.100 に答える
0

ここの誰もが状況に対する嫌悪感を十分に発表していると思うので、あらゆる種類の暗号化を行うときに別の問題についてヒントを落とします（これは必要であることに同意します）：

データはどこかで暗号化する必要があります！

サーバー上でそれを行う場合、侵害されたサーバーは暗号化を行い、暗号化せずにそれらを渡します。

クライアントでこれを行う場合、これはもう少し安全ですが、誰かがサーバーにアクセスできる場合でもドアを大きく開いたままにします。理論的には、XSSホールを開く（つまり、ページにリモートスクリプトを挿入する）ことができます。 。）暗号化する前にボックスにコピーを送信します。

結局のところ、110％安全ではない可能性のあるサーバーでこれを行うことを本当に検討している場合は、ウォークアウェイしてください。

于 2009-02-27T21:52:18.470 に答える