多くのクレジット カード情報を格納するデータベースは、完成したばかりのシステムに不可欠な部分です。私が望んでいるのは、カード番号の究極のセキュリティであり、暗号化と復号化のメカニズムをセットアップしますが、特定の番号を復号化することはできません.
私が求めているのは、この情報をデータベース レベルで保護して、誰もカード番号のファイルを作成できないようにする方法です。他の人はこの問題をどのように克服しましたか? これに対する「標準」アプローチとは何ですか?
データの使用に関しては、リンクはすべて非公開で安全であり、レコードが作成されて暗号化される場合を除いてカード番号の送信は行われないため、バックエンドだけでフロントエンドについて心配する必要はありません.
データベースは ORACLE なので、PL/SQL と Java で遊ぶことができます。
CC 情報を保存し、保存された番号に対して請求できるトークンと交換することをいとわないプロセッサが不足することはありません。これにより、PCI コンプライアンスから外れますが、オンデマンド請求は可能です。CC を保存する必要がある理由によっては、それがより良い代替手段になる場合があります。
ほとんどの企業はこれを「顧客プロファイル管理」のようなものと呼んでおり、実際にはかなり妥当な料金です。
私が知っているいくつかのプロバイダー (順不同):
あなたが支払い処理業者でない限り、どんな種類の CC 情報も保存する必要はありません。
要件を確認してください。CC 情報を保存する必要があるケースは実際には多くありません。
クレジット カード番号を保存しないでください。代わりにハッシュを保存してください。新しい番号が保存されている番号と一致するかどうかを確認する必要がある場合は、新しい番号のハッシュを取得し、保存されているハッシュと比較します。それらが一致する場合、数は (理論的には) 同じです。
または、カード番号を入力するユーザーにパスフレーズを入力させることで、データを暗号化することもできます。これを暗号化/復号化キーとして使用します。
ただし、データベースとソースコードにアクセスできる人 (つまり、あなたとあなたのチーム) は、そのデータを復号化するのは簡単だと思います (つまり、ライブ コードを変更して、入力された復号化キーを使い捨ての Hotmail アカウントに電子メールで送信するなど)。
ユーザーがクレジットカード情報を再入力する必要がないためにクレジットカード情報を保存している場合は、フォームのハッシュは役に立ちません。
クレジットカード番号に基づいて行動する必要があるのはいつですか？
クレジットカード番号をより安全なデータベースに保存し、メインデータベースにユーザーに表示するのに十分な情報とカードへの参照を保存することができます。バックエンドシステムはさらにロックダウンされ、注文処理のためだけに実際のクレジットカード情報を使用できます。必要に応じて、これらの番号をマスターパスワードで暗号化することもできますが、パスワードは、番号を取得する必要のあるコードによって認識されている必要があります。
はい、問題をある程度回避しただけですが、多くのセキュリティは、攻撃のフットプリントを排除することではなく、削減することを目的としています。それを排除したい場合は、クレジットカード番号をどこにも保存しないでください！
Oracleを使用している場合は、透過的データ暗号化に関心があるかもしれません。ただし、エンタープライズライセンスでのみ利用できます。
Oracleには、 DBMS_OBFUSCATION_TOOLKITなどの暗号化（復号化）用のユーティリティもあります。
「標準」に関して、関心のある適切な標準は、クレジットカードの機密情報を保護するために実行する必要のある対策を説明するPCIDSS標準です。
e コマース タイプのユース ケース (Amazon 1-Click を考えてください) の場合、ユーザーの既存の強力なパスワードを使用して CC (またはキー) を暗号化できます。パスワードのハッシュのみを保存すると仮定すると、ユーザー（またはレインボーテーブル-ただし、各ユーザーで実行する必要があり、同じパスワードを作成しないと機能しません-だけでなく1 が同じものをハッシュしたもの) を復号化できます。
パスワードが変更されたときにデータを再暗号化するように注意する必要があり、パスワードを忘れた場合、データは価値がありません (ユーザーが再入力する必要があります)。ただし、支払いがユーザーによって開始された場合、それならうまくいくでしょう。
安全なソルトハッシュ（SHA-256 +ソルト）を対称的に暗号化（AES）します。ソルトハッシュは大きなソルトで十分ですが、コードがリークせず、データベースがリークした場合に備えて、暗号化によって少し余分に追加され、それまでにソルトハッシュ用のレインボーテーブルまたはその他の手段があります。もちろん、データベースではなく、コードにキーを保存します。
曲がったチームメイトからあなたを保護するものは何もないことに注意してください。たとえば、ハッシュする前に日付のコピーを保存することもできます。コードリポジトリに十分注意し、クレジットカード処理パス内のすべてのコードに対して頻繁にコードを改訂する必要があります。また、データを受信して暗号化/ハッシュ化するまでの時間を最小限に抑え、データが保存されている変数がメモリからクリアされるように手動で確認してください。
DBサーバーと言語/プラットフォームのタイプを知っておくと、より具体的に知ることができますが、私はSHAを調べています。