クレジット カード情報を安全かつ合法的に保管することは非常に困難であり、試みるべきではありません。クレジットカードデータを保存するつもりはありませんが、次のことを理解したいと思っています:
私のクレジット カード情報は、世界のどこかのサーバーに保存されています。このデータは (うまくいけば) マーチャントのサーバーには保存されませんが、マーチャントが送信したデータによって識別されるアカウントを確認して課金するために、ある時点で保存する必要があります。
私の質問は次のとおりです。クレジット カード データの保存を任された場合、ディスク上のデータを保護するためにどの暗号化戦略を使用しますか? 送信されたクレジットカード情報は、多かれ少なかれリアルタイムでチェックされていることがわかります。データを保護するために使用される暗号化キーが手動で入力されているとは思えないため、復号化はオンザフライで行われます。これは、キー自体がディスク上に保存されていることを意味します。このような自動化されたシステムでデータとキーをどのように保護しますか?
番号を保存していたら、大規模なデータベースを持つ巨大なサービス プロバイダーになってしまいます。そのデータベースは、SAN で接続された、別々の部屋または理想的には地理的に離れた場所にある複数のキャビネットで構成される高度に冗長なストレージ アレイに分散されています。内部関係者による私の最大の脅威は、分散した物理プラント、使い古されたドライブの絶え間ない流れ、および技術者、管理者、およびエンジニアの毎日のシフトです。それは大きな脅威です。
したがって、ネットワーク経由で大容量ストレージに接続する、物理的に分離されたコンピューターでデータを暗号化します。ソフトウェアは、暗号化と番号の検証など、可能な限りシンプルなものにする必要があります。パブリック インターフェイスとビジネス ロジックは別の場所に配置されます。アクセスは別の SAN に記録されます。
AES などで暗号化します。生の AES キーは、RAM にのみ保存されます。キーは、サーバーを有効にするための独自のパスフレーズを持つ各管理者の PGP ファイルにラップされます。信頼度の低い担当者には、パスフレーズの一部を提供して災害復旧に使用するか、パスフレーズをどこかのボールトに保管することができます。暗号化のために、カード番号ごとに一意の初期化ベクトル (IV) を選択し、その IV を使用して番号を AES 暗号化し、IV と暗号化された番号を SAN に保存します。復号化は、特権クライアント インターフェイスを使用してのみ行われます。購入に使用される通常のクライアント接続では、復号化を取得できません。
ベンダーがクレジット カード情報を処理および保存するには、通常、PCI 認定を受ける必要があります。要件は、ここで概説する必要があります。要件には非常に単純なものもあれば、あいまいで解釈の余地があるものもあります。プロセスを実行するのは楽しいことではありません。企業が認証を取得しているからといって、データが安全であるとは限りません。
しかし、何もないよりはましだと思います。
It's quite easy to store a salted hash of a credit card number rather than the number itself for secure lookups. For 99% of the scenarios out there, this would be sufficient credit card for storage -- fast and very secure.
If you really need reversible encryption of a credit card for some scenario (continued billing, for example), I would go with a symmetric key stored in a secure location other than the database. It's been a while since I looked at PCI specs, but I'm fairly certain that's PCI compliant.
If you need fast lookups along with reversible encryption, use both options: a hash and an encryption.
Edit: There seems to be some controversy over my answer. I would like to point out the following very interesting essay from Integrity.com (PDF):
Hashing Credit Card Numbers: Unsafe Application Practices
It details many of the issues involved in storing a hash of credit card data, but its conclusion confirms my suggestion.
Yes, a raw hash of the card is not secure; that's why we salt our hashes! But a static salt is also not secure, they allow the creation of rainbow tables for known static salts. So it's best to make our salts vary in some way that is unpredictable. In the case of passwords, it's sufficient to use a separate, random hash for each password being checked; it can even reside in the same table/row as the hashed password. For the case of credit cards, this should be the same -- a random salt for each instance of the credit card being hashed. If the credit card number is stored per transaction, a separate salt for each transaction.
There are pros and cons to this approach, but it's sufficiently secure. The pros are the lack of key management; the salt and hash are right there, and don't need to change while still allowing for audit checks of the hash; e.g. does that credit card hash match this known credit card number?
The cons are in search; it's not possible to effectively search for a particular credit card number across many transactions.
Of course, you'll have this issue with external encryption anyway; unless the database is itself encrypted (something only some databases support), you won't be able to search very well. Even then, encrypting at the database or even the table level reduces search effectiveness significantly.
ここ数回、クレジット カードでの支払いを扱っていましたが、実際の CC 情報を自分のサーバーに実際に保存することはありませんでした。支払いゲートウェイにそれを処理させます。最終的に得られたのは、クレジットカードがまだ有効であり、要求された金額の現金が利用可能であることを確認するために使用できる transactionID でした。次に、購入した商品を実際に梱包したら、Payment Gateway にキャプチャ コマンドを発行します。
このアプローチにより、特定の顧客のトランザクション ID だけを知る必要があったため、サイトに CC 支払いを統合するプロセスが大幅に簡素化されました。もちろん、これでは、ワンクリック ショッピングのために CC 情報を保持するという Amazon の「トリック」を行うことはできませんでした。transactionID が侵害された場合、それを使用できるのは、支払いを早期に回収するか、トランザクションを完全にキャンセルすることだけでした (この場合、出荷前に承認がまだ有効であることを確認したときにわかります)。このトランザクションを使用して、顧客が既に承認した金額よりも大きな金額を収集することはできません。また、「ショップ」が構成されているものとは異なるアカウントに誰かが収集することもできません。
探していた正確な答えではないかもしれませんが、セキュリティ ベンダーに大金を費やすことなく、全体的な問題を解決できる可能性があります。
まず、クレジット カード番号を扱う場合は、PCI-DSSに準拠する必要があります。番号を保存すると、PCI-DSS 仕様の 12 のセクションすべてが適用されます。これは、ほとんどの組織にとって大きなコストです。時間、リソース、および財政的手段がない場合は、クレジット カード番号を保存する道をたどるべきではありません。
クレジット カードを保管する Windows ベースの電子商取引システムで PCI-DSS 準拠を取得しました。256 ビット AES 暗号化を使用します。キー自体はWindows DPAPIを使用して暗号化されます。つまり、キーを暗号化したユーザー アカウントと同じユーザー アカウントで実行されているプロセスによってのみ復号化できます。暗号化されたキーはレジストリに格納されます。
キーは 12 か月ごとにローテーションされ、バックアップ キーのコピーが 3 つの部分 A、B、C に分割されて保存され、3 つの USB ドライブに分散され、それぞれ別の人が保持します。ドライブ 1 には A+B、ドライブ 2 には B+C、ドライブ 3 には A+C があります。したがって、完全なキー (A+B+C) を構築するには、任意の 2 つのドライブが必要です。このスキームは、ドライブのいずれか 1 つが失われても許容されます。キー部分自体は、ドライブの所有者だけが知っているパスワードで暗号化されています。
場合によっては、暗号化キーがディスクではなくハードウェア デバイスに保存されることがあります。特別な暗号化サーバーを使用して暗号化/復号化を行うか、ハードウェア ドングルなどに保存されているキーを使用して復号化を行います。このようにして、ハッカーは復号化キーを含む物理デバイスを盗まなければ復号化キーを盗むことができません (キーがデバイスから離れることはないため)。
私が見たもう 1 つの方法は、暗号化されたデータを、外部の世界に直接接続されていないデータベース/データセンターに格納することです (アクセスできないものをハッキングすることはできません)。インターフェイス サーバーは、ネットワークの「安全な」部分とネットワークの「インターネットに面した」/「安全でない」部分の間にプロキシとして配置されます。安全なトラフィックがこのセキュリティ チョーク ポイントを通過するように強制すると、侵入者が保護されたデータにアクセスすることがより困難になる可能性があります。
もちろん、これらのどちらも、データが完全に安全であることを意味するものではありません。
クレジット カードを盗むという頭痛の種を排除したい場合は、(データベースに保存されているソルト値に加えて) データベースに保存されていないソルト値を使用してハッシュします。最新のハッシュ アルゴリズムでそれらをハッシュ化すると、クレジット カードの盗難に関するほとんどの問題が解決されますが、消費者は購入のたびにクレジット カードを再入力する必要があります。クレジット カード番号の保存を扱うプロジェクトに携わった経験から、クレジット カード番号をハッシュ化することで、セキュリティ レビューのコストが 1 桁削減されることがわかりました (ただし、そのプロジェクトは PII の懸念よりも前のことでした)。
対称暗号化を使用する場合は、すべてが復号化キーの管理と制御に帰着する複雑な新しい領域に入ります。クレジット カード番号をハッシュしても、すべての PII (個人を特定できる情報) を暗号化する必要があるため、可逆暗号化を処理する必要があります。SQL Server 2008 には、サードパーティ ベンダー プログラムを使用して、分割キーを含む復号化キーの制御を管理できる、新しい Extensible Key Mangement プラグイン アーキテクチャがあります。
特定の質問に答えるために、暗号化されたクレジット カード暗号化キーをディスクに保存することができます。キー暗号化キーは、サーバーの起動時に入力する必要があるパスフレーズから導出できます。Shamir の秘密分割スキームを使用すると、キー暗号化キーとして使用される秘密を構築するために N 共有のうち k が必要になります。復号化された暗号化キー/シークレットはメモリに保存されます。サーバーを再起動する必要がある場合は、k 個の共有が必要です。もちろん、これは大きなオーバーヘッドであり、私が知っているほとんどのマーチャントはこれを実装していません。ただし、通常、中間セキュリティのために暗号化されたデータとは別にキーを保存するため、一方へのアクセスが自動的にもう一方への完全なアクセスを意味するわけではありません (それでも非常に悪いですが)。
質問に直接答えていないため、元の投稿の内容を削除しました。鍵の管理と正しい暗号化は重要な部分ですが、それでも話の小さな部分であると言えば十分です.
PCI 監査人は、すべてが正しく行われていることを保証できない可能性があります。
any automated system for decrypting encrypted information is going to be completly insecure. By automating the process you are defeating the encryption. Any encrypted data should only be decrypted by a user entered secret key.