顧客の完全なクレジット カードの詳細 (番号、名前、有効期限、CVV2) を短期間保存する必要があるビジネス要件があります。
理論的根拠: 顧客が製品を注文するために電話をかけ、そのクレジット カードがその場で拒否された場合、販売を失う可能性があります。詳細を聞いて、取引に感謝し、カードが拒否されたことがわかった場合は、電話をかけ直すことができ、製品の別の支払い方法を見つける可能性が高くなります. クレジット カードが受け入れられた場合は、注文の詳細を消去します。
これを変更することはできません。既存のシステムはクレジット カードの詳細をクリア テキストで保存します。これを置き換えるために構築している新しいシステムでは、明らかにこれを複製するつもりはありません。
私の質問は、クレジットカードを短期間安全に保管するにはどうすればよいかということです。明らかに何らかの暗号化が必要ですが、これを行うための最良の方法は何ですか?
環境: C#、WinForms、SQL-Server。
基本的には、CC の詳細を自分で保存する責任を負うことは絶対に避けてください。ただし、PayPal/Verisign などのトランザクションを行うためにサードパーティのサービスを使用していると推測できます。それらのほとんどには、CC を保存できる API があります。資格情報を側に置いて、後でトランザクションを完了または開始するために使用できるキーを返します。そのため、面倒な部分は処理されますが、この文字列キーを DB に保存するだけです。
CVV 情報を保存することが実際に違法であるとは思いませんが (法律に違反しているという意味で)、クレジット カード業界の規則に違反しており、さまざまな制裁を課す可能性があります。したがって、要件によっては、実際にはクレジット カードを受け入れることができなくなる可能性があります ;-(
アンドリュー、あなたはPCI-DSSを理解する必要があります。簡単な仕事ではありません。個人的には非常に漠然としていますが、ここで私が理解していることは次のとおりです。
まず、あなたが説明したシナリオから、カードを全額承認しようとし、それが失敗した場合は、顧客の情報 (カード所有者のデータではなく) を保存して、誰かがユーザーに連絡できるようにします。私が働いていた場所では、カードが有効であることを確認するためだけに、1.00 ドルだけを請求し、すぐに取引を無効にする顧客もいました。その後、すべての注文を手動で処理します。
番号を保存する必要がある場所は、認証が成功した場合です。その場合に必要な唯一の番号は、クレジット カード番号とトランザクション コードです (少なくとも、これまでに使用したすべてのゲートウェイで)。
私が最後に見たときの標準は、暗号化アルゴリズムに固有のものではなく、代わりに、現在解読できない暗号化であるべきであることを明確にしています。
ここで、許可後に CCV を保存することはできません。私の理解では、承認前にそれを保存することはできますが、それを書面に残す人を得ることができませんでした. 基本的に、カードを承認したら、ワイプした方がよいでしょう。
現時点では違法ではありませんが、釘付けになるとハンマーで叩かれます。彼らはあなたに対して重い罰金を課す権限を持っていますが、彼らが通常行うことはあなたを是正することです. あなたが従わない場合、私は何が起こるか分かりません。しかし、その後、彼らは実際に顕微鏡であなたの戦利品を調べます.
最終的に、彼らが本当に持っている唯一の手段は、あなたがクレジットカードを受け入れないようにすることだと私は信じています. 私が一緒に働いたほとんどの商人は、まさにそれを恐れていました。
文字列をメモリに短時間保存するだけの場合は、System.Security.SecureStringを参照してください。
この回答から取得：
SecureString の値は暗号化されて (むしろ難読化されて) 保存されますが、最も重要なことは、それらがディスクにスワップされることはなく、使い終わったらすぐに破棄できることです。
一度に 1 文字しか作成できないため (ユーザーがパスワードを入力するときにキーストロークをキャプチャして作成することを奨励するため)、3 行のコードを復元してプレーンテキストを消去する必要があるため、使いにくいです。しかし、適切に使用すれば、仮想メモリの脆弱性を回避してプログラムをより安全にすることができます。
例の最後で、SecureString は通常のマネージド文字列に変換されるため、再び脆弱になります (処理が終わったら、必ず try-catch-finally パターンを使用して文字列をゼロにします)。SecureString の用途は、ガベージ コレクターが作成する値のコピーの数を制限することによって攻撃の対象領域を減らし、スワップ ファイルに書き込まれる可能性を減らすことです。
// Make a SecureString
SecureString sPassphrase = new SecureString();
Console.WriteLine("Please enter your passphrase");
ConsoleKeyInfo input = Console.ReadKey(true);
while (input.Key != ConsoleKey.Enter)
{
sPassphrase.AppendChar(input.KeyChar);
Console.Write('*');
input = Console.ReadKey(true);
}
sPassphrase.MakeReadOnly();
// Recover plaintext from a SecureString
// Marshal is in the System.Runtime.InteropServices namespace
try {
IntPtr ptrPassphrase = Marshal.SecureStringToBSTR(sPassphrase);
string uPassphrase = Marshal.PtrToStringUni(ptrPassphrase);
// ... use the string ...
}
catch {
// error handling
}
finally {
Marshal.ZeroFreeBSTR(ptrPassphrase);
}
クレジット カード情報を保存する場合は、本当に PCI に準拠する必要があります。そうしないと、問題が発生するだけです。
そうは言っても、SQL Server 2005 以降で利用可能なセル レベルの暗号化を見てください。偶然にも :) 私は最近、SQL Server 2005/2008 を使用した暗号化に関する T-SQL サンプルを使用したプレゼンテーションを行いました。 2008 年 12 月 23 日）
適切に準拠し、そのようなことを実行できるようになるには、30,000 ドル程度の費用がかかります。サードパーティの支払いサービスを使用することをお勧めします。個人的には、Element Express をお勧めします。Element Express には、PCI-DSS PAPDB 準拠をバイパスする「ホスト型」ソリューションがあります。POS マシンでさえ、自分のアプリケーションのためにこれに変換する必要がありました!!! それは大きな苦痛ですが、私たちは小さな会社です。
上記のリンクには、準拠するためのコストに関する有益な情報が含まれています。顧客からクレジット カード番号の保存を依頼されましたが、罰金を科される可能性があるため、保存しません。良くない。責任を負わないでください。
編集：
さらに、クレジット カード情報を保存する場合は、使用する暗号化の形式を考慮する必要があります。対称？非対称？
対称暗号化 (パスキー) を使用すると、キー (暗号化する必要がある) を持つサーバー (サイト) が何らかの形で危険にさらされると、深刻なセキュリティの脆弱性にさらされることになります。コンパイルされたコードでもテキスト キーは隠されません。
非対称暗号化 (公開/秘密鍵ペア) を使用すると、いくつかの追加の問題が発生しますが、公開されているプライマリ サーバーが侵害された場合、それらは公開鍵のみを持ち、データベースにもアクセスする場合..それらはありません。内容を解読できます。
問題は、秘密鍵をどこに保管するかということです。管理機能を実行しているときに、誰かにローカル コンピューターから貼り付けてもらいますか?デスクトップで実行して注文などを表示する別のアプリケーションを用意します。
考慮すべき点はたくさんあります。
最後の注意: 支払いゲートウェイ (Element Express、Authorize.NET、Paypal など) を使用し、クレジット カード情報をローカルに保存しないでください。:P
C# での X509 非対称暗号化の使用に関するリンクは次のとおりです: http://www.csharpbydesign.com/2008/04/asymmetric-key-encryption-with.html
可能であれば、データの保存を避けるべきであることに同意しました。しかし、もしかしてあなたはその第三者ですか？その場合は、 PCI 標準に慣れてください。このサイトを少し調べてみると、実装が必要なセキュリティ対策が見つかります。
t ログを考慮してください。
顧客に完全な影響 (およびコンプライアンス違反が見つかった場合の是正要件) を説明すれば、私を信じてください。あなたの「ビジネス要件」はすぐに変わります。
クレジット カード番号を保存する必要があり (保存する必要がある合理的なシナリオは存在しないという考えを進めます)、データベースに組み込まれているネイティブ暗号化を使用する場合は、次のことを考慮してください: トランザクション ログはどうしますか?
トランザクション ログが平文でクレジット カード番号を反映している可能性がある場合は、コンプライアンス違反であり、見つかった場合にサイトで 10,000 ドルから 50,000 ドルのフォレンジック監査の予算を立てる必要があります。このようなことをすべて知っているはずだったので、顧客があなたを訴えた場合に備えて、あなた自身の弁護士のための予算。
そのため、クレジット カード番号を保存する場合は、暗号化をコードで実行して、トランザクション ログ (挿入または更新) が平文のカード番号ではなく、暗号化された文字列を反映するようにします。
また、データベースに CVV 用のフィールドや列を持たないでください (暗号化されているかどうかに関係なく)。フォレンジック監査でこれが明らかになり (ログも同様です)、顧客は大きな問題に直面します。彼らは罰金を支払い、クレジットカードを受け入れる能力を失う可能性があります. あなたの弁護士はとても幸せです。
要件を少し違った方法で見てみましょう。現在、次のようになっています。
Web サイト X の製品所有者として、システムに顧客の CC の詳細を一時的に保存して、CC 会社によって拒否された販売を回復できるようにしたい
Ppl はそのように考え、そのように機能を要求する傾向があります。今、私はあなたの要件がより便利に次のように説明されていると思います:
ユーザーとして、私はウェブサイト X が購入の支払いを再試行できるようにしたいので、チェックアウトプロセスを再度行う必要がありません.
それで、何かを保存するための明示的な要件はありません（あなたの側に）ありますか？その唯一の暗示
支払いプロバイダーは、マーチャント アカウントにプログラム API を提供し、拒否された場合に再認証を試みる機能を提供できます。@bashmohandesはこれを以前に回避したと思います
すべての支払いプロバイダーがこれを実行できるわけではありませんが、関連する銀行との関係に依存していると思います. それはあなたが避けたいものです。銀行との関係が深い。
シナリオ 1: 私が言ったことはすべて真実であると仮定する
認証試行への参照以外は何も保存する必要はありません。一部の支払いプロバイダーは、再認証を行うために独自のツールを作成する必要がないように、優れたバックオフィス ツールを提供しています。ペイゲートはこれを行うと思います
私が信じている最善の策は、多くの支払いプロバイダーにインタビューすることです. 彼らは手の甲のようにこのことを知っているべきです。これは潜在的にゼロコード ソリューションです
シナリオ 2: 私が完全に間違っていると仮定しますが、法的にはこの CC の保存は問題ありません
そのため、そのデータを一時的にどこかに保存する必要があります。私はアドバイスします：
シナリオ 2 で提案したのはハードルだけですが、最終的には永続性がデータを取得するための競争に勝ちます。データを完全に保護する唯一の方法は、サーバーをイーサから切り離すことですが、そのオプションは少し急進的です:-)
シナリオ1はいいだろう。そうじゃない？
機密データをデータベースに保存するというまさにこの状況を扱ったブログ投稿があります。ブログの投稿では、Triple DES アルゴリズムを使用して作成した String Encryptor クラスを使用していますが、必要に応じて独自のものをプラグインすることもできます。
ブログ投稿には、使用されたビデオとソース コードが含まれています。http://www.wrightin.gs/2008/11/how-to-encryptdecrypt-sensitive-column-contents-in-nhibernateactive-record-video.htmlで確認できます。あなたの問題を確実に解決してくれると思います。