PCI暗号化キー管理
（完全な開示：私はすでにこことStackOverflowで積極的に参加していますが、当然のことながら、この特定の質問を匿名で行うことを選択しています）。
私は現在、いくつかのかなり専門的な業界で中小規模のビジネスを管理するために商業的に販売されているソフトウェアを製造している小さなソフトウェアショップで働いています。これらの業界は顧客向けであるため、ソフトウェアの大部分は顧客情報の保存と管理に関連しています。特に、顧客のクレジットカード情報の保存（およびセキュリティ保護）。もちろん、これにはPCIコンプライアンスも含まれます。
長い話を簡単に言うと、なぜ特定のことが彼らのやり方で行われたのかについていくつかの質問が残されており、残念ながら現時点では多くのリソースがありません。これはvery小さなお店（他のフルタイムの唯一の従業員と同様に、私はオーナーに直接報告します）であり、オーナーはこれらの質問に対する答えを持っていません。以前の開発者は...エラー...利用できません。
問題1：定期的な再暗号化
現在のところ、これらの条件のいずれかが当てはまる場合、ソフトウェアはユーザーにデータベース内のすべての機密情報（基本的にクレジットカード番号とユーザーパスワード）の完全な再暗号化を行うように求めます。
データベースには、暗号化されていない機密情報が含まれています（たとえば、ビジネスオブジェクトではなく、手動のデータベースステートメントによって追加されます）。これは、ソフトウェアの通常の使用中には発生しません。
現在のキーは、特定の期間以上使用されています。 12ヶ月だと思いますが、よくわかりません。ここでのポイントは、キーが「期限切れ」であることです。
これは、PCIを扱う商用ソリューション開発への私の最初の進出です。そのため、残念ながら関連するプラクティスについては知識がありません。定期的なキーの更新を義務付ける（または強く推奨する）PCIコンプライアンスの側面はありますか？
これは、エンドユーザーが実行するように求められている理由を尋ねられた場合にエンドユーザーに説明する適切な説明がないのを除いて、私にとって大きな問題ではありません。
質問1：キーの有効期限標準の概念はありますか？そうであれば、それは単に業界標準ですか、それともPCIの要素ですか？
問題2：キーストレージ
これが私の本当の問題です...暗号化キーはデータベースにに保存されていますが、難読化されています。キーの左側と右側に数バイトのガベージバイトが埋め込まれ、一部のビットがいじられていますが、基本的には、企業内の人が（dotfuscated）コードを調べて、格納されたキーを実際のキーに変換するために使用されるパターンを決定することを妨げるものは何もありません。次に、そのキーを使用してamokを実行します。これは私には恐ろしい慣行のように思えますが、これがこの業界の人々が取っている「にっこりと耐える」慣行の1つだけではないことを確認したいと思います。私はそのような攻撃を防ぐ代替アプローチを開発しましたが、私はここで健全性チェックを探しています。
質問2：このキーの保存方法は、つまり、クライアントコードに存在する難読化メソッドを使用してデータベースにキーを保存するものですか？
私を信じて、私は無料のアドバイスが私がそれを支払ったすべてのペニーの価値があることを知っています、ここに誰も弁護士はありません（または少なくとも法的アドバイスを提供していません）、警告の大法廷などなどですが、私は探していますすべてのユーザーが提供できる入力について。前もって感謝します！
問題1：パスワードの暗号化について言及しています。まず、パスワードのソルトハッシュではなく、なぜパスワードが使用されるのですか？キーのローテーション/有効期限に関しては、そのようなポリシーを見てきました（そしてコード化されています）。キーの使用期間が長いほど（使用される回数が多いほど）、キーが含まれたり発見されたりするリスクが高くなります。一部のシステム、たとえばWindows DPAPIはキーを自動的に期限切れにします。SSL証明書には有効期限があり、それ以降は多くのシステムが新しいデータの暗号化などにそれらを使用しなくなります。
問題2：はい、それは悪いことです。信じられないほど悪い。
PCIコンプライアンス 監査仕様 PAN状態の場合 "トリプルDES 128ビットまたはAES 256ビットなどの強力な暗号化、および関連するキー管理プロセスと手順」
ローテーションはキー管理プロセスの一部であると主張される可能性があり、データから安全にキーを安全に保存することは、キー管理プロセスの一部です。
監査仕様のセクション3.6.4はさらに進んで述べています
定期的なキーの変更
- 関連するアプリケーションで必要かつ推奨されていると見なされる場合（例：鍵の再作成）;
- できれば自動的に、少なくとも毎年
まだ情報がない場合は、 PA-DSSおよびPCI-DSSのドキュメント を参照することをお勧めします。要件について。お使いのソフトウェアがPA-DSSの認定を受けている場合、これらの要件を通過するための期待についてより具体的な情報を持っているはずのQSAがいると思います。
データの暗号化の管理に関しては、アプリケーションレベルの暗号を取得する際に使用しているデータベースエンジンの組み込み機能を使用することをお勧めします。右は非常にトリッキーになる可能性があります。オプションについてのよい論文 here があります。
問題＃1：定期的な再暗号化
（別名キーイング）。はい、これは正常ですが、必須ではありません。
具体的には、期限切れのキーが必要であり、PCIで必要です。少なくとも年に1回、より早く実行することもできます。
どう対処するかは別問題です。たとえば、2010のキーの有効期限が切れた後、そのキーで暗号化されたすべてのデータをどのように処理しますか？
1つの解決策は、すべての鍵の履歴と各データの「鍵バージョン」を保存して、復号化するときに使用する鍵がわかるようにすることです。 （もちろん、新しい鍵のみを使用して暗号化します。）別の解決策は、前述の鍵の再生成です。各点に1つだけ（鍵の再生成中を除く...）があり、期限切れになると、古い鍵で復号化し、新しい鍵で再暗号化します。 1。
問題＃2：キーストレージ
かなり単純に、それは悪いことであり、暗号化を（まったくではないが、ほぼ）意味のないものにします。
一般的な適切な鍵管理技術、特にPCIは、厳密な鍵管理ポリシーと手順を定義します。一部は技術的です。暗号化キー（EK）は、強力な暗号化を使用して暗号化する必要があります。 DPAPI;一部は手続き型です。たとえば、キー暗号化キー（KEK）へのアクセスを文書化する必要があります。一部は手動です。知識の分割/ KEKの二重制御。
@Roryが言ったように、PA QSAに相談してください。PAQSAがない場合は取得してください。
2番目の質問に最も興味があります。キー暗号化キーを使用して暗号化して保存した場合でも、暗号化キーを暗号化データに非常に近い場所に保存する理由を理解するのに苦労しました。
私が考えることができる唯一の理由は、透過的な暗号化/復号化を実行するためにデータベース暗号化インフラストラクチャ/機能を使用することです。ただし、これは非常にデータベースベンダー固有です（以前の投稿でリンクされたドキュメントでも説明されています）。
キーを別のストレージに保管し、パスワードまたはHSMデバイスで保護することをお勧めします。
問題1：12か月が過ぎた後だと思います。私たちのサーバーは3か月ごとに新しいキー/パスワードを必要とします。クレジットカード関連はありませんが、まだです。 PCIに準拠していることは確かではありませんが、これは賢明な方法だと思いますが、準拠していない場合は準拠しているはずです。
問題2：非常に正気に聞こえます。データのすぐ隣にキーを保管したり、難読化したりすることはありません。それは単なるオープンチャレンジです。「私を試してみて、ハックしてください」。