「暗号ストレージのチートシート」の版間の差分
(→ルール - 許可された暗号モードを利用する) |
|||
| (同じ利用者による、間の3版が非表示) | |||
| 行8: | 行8: | ||
== 概要 == | == 概要 == | ||
[[暗号]]は、攻撃者からデータを守ったり、運用者からデータを保護したり、といった目的で利用されます。[[暗号]]は、注意すべきポイントがいくつもあります。そのポイントを知りたい方は、この文章を読んで下さい。 | [[暗号]]は、攻撃者からデータを守ったり、運用者からデータを保護したり、といった目的で利用されます。[[暗号]]は、注意すべきポイントがいくつもあります。そのポイントを知りたい方は、この文章を読んで下さい。 | ||
| − | + | ||
| − | + | [[暗号]]は、ウェブサービスやITシステムでは、通信経路の暗号化、保存データの暗号化といったように、いろいろなところで利用されています。Eコマースのサービスでは、個人情報や決済情報([[クレジットカードの番号|クレジットカード番号]]や銀行口座番号)などを扱うことになります。個人情報や決済情報を預かる場合には、本当に必要なものだけを保存し、そして、その情報を暗号化するなどの対策を実施する必要があります。 | |
| − | + | == 暗号の機能の提供 == | |
| − | + | === セキュアな暗号ストレージのデザイン === | |
| − | おおくの Eコマースビジネスは、自動継続請求(recurring billing) | + | ==== ルール - 必要なセンシティブデータのみ保存する ==== |
| − | + | おおくの Eコマースビジネスは、自動継続請求(recurring billing)のために[[クレジットカード]]情報を保存するための 3rd party プロバイダを利用します。これは、クレジットカード番号を安全に保つための義務を押し付けます。 | |
| + | ==== ルール - 強力な許可された Authenticated Encryption (認証付き暗号)を利用する ==== | ||
例: CCM(Counter with CBC-MAC モード)やGCM(Galois/Counter Mode)は、[[AES暗号|AES]]アルゴリズムに基づいた Authenticated Encryption (認証付き暗号) モードです。 | 例: CCM(Counter with CBC-MAC モード)やGCM(Galois/Counter Mode)は、[[AES暗号|AES]]アルゴリズムに基づいた Authenticated Encryption (認証付き暗号) モードです。 | ||
| − | + | ===== ルール - 強力な許可された暗号アルゴリズムを利用する ===== | |
たとえ、簡単だったとしても、自分自身で既存の暗号アルゴリズムを実装しません。その代わり、広く許可されたアルゴリズムや広く許可された実装を利用します。 | たとえ、簡単だったとしても、自分自身で既存の暗号アルゴリズムを実装しません。その代わり、広く許可されたアルゴリズムや広く許可された実装を利用します。 | ||
| 行40: | 行41: | ||
もし、鍵を守るためのパスワードを利用するなら、パスワードの強度は、守りたい鍵の強度のために十分でなければなりません。 | もし、鍵を守るためのパスワードを利用するなら、パスワードの強度は、守りたい鍵の強度のために十分でなければなりません。 | ||
| − | ===== | + | ===== ルール - 許可された暗号モードを利用する ===== |
| − | 一般に、[[AES]]や[[DES]] | + | 一般に、[[AES]]や[[DES]]や対称暗号のプリミティブを直接利用してはいけません。 [http://csrc.nist.gov/groups/ST/toolkit/BCM/current_modes.html NIST が許可しているモード]を使います。 |
注意: データの暗号化には、ECB モードを使いません(ほかのモードのほうが安全です。なぜなら、それらは、データ・セキュリティの改善のために、データのブロックをチェインしています。)。 | 注意: データの暗号化には、ECB モードを使いません(ほかのモードのほうが安全です。なぜなら、それらは、データ・セキュリティの改善のために、データのブロックをチェインしています。)。 | ||
| − | + | ||
| − | すべての[[乱数]]、とくに、暗号パラメータでの利用( | + | ===== ルール - 強力な乱数を利用する ===== |
| + | すべての[[乱数]]、とくに、暗号パラメータでの利用([[鍵]]、[[初期ベクトル]](IV)、MAC tags)、ランダムファイル名、ランダム GUID 、ランダム文字列は、暗号法論的に強度のあるファッションで生成されなければなりません。 | ||
ランダムアルゴリズムは、十分なエントロピーによって、生成されていることを保証します。 | ランダムアルゴリズムは、十分なエントロピーによって、生成されていることを保証します。 | ||
[http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html NIST PNG テストツール](PCI PTS Derived Test Requirement で利用される)のようなツールは、乱数ジェネレーターの包括的な品質評価で利用されます。例えば、PNG ソースから128MBのデータを読み、ツールで、偶然性のプロパティの評価を行います。 | [http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html NIST PNG テストツール](PCI PTS Derived Test Requirement で利用される)のようなツールは、乱数ジェネレーターの包括的な品質評価で利用されます。例えば、PNG ソースから128MBのデータを読み、ツールで、偶然性のプロパティの評価を行います。 | ||
| − | + | ===== ルール - データの Authenticated Encryption (認証付き暗号) を利用する ===== | |
一定のAPIの元で AE(Authenticated Encryption)モードを使用します。CCMやGCMなどを含むモードを推奨します。 | 一定のAPIの元で AE(Authenticated Encryption)モードを使用します。CCMやGCMなどを含むモードを推奨します。 | ||
| 行65: | 行67: | ||
Note: [[ディスク暗号化]]は、[[Data at Rest]]の特別なケースです。例: ハードディスクドライブ上の暗号ファイルシステム。 XTS-AES モードは、[[ディスク暗号化]]に最適化されていて、NIST の approved モードの１つです。これは、機密性とデータマニピュレーションに対するいくつもの保護を提供します(しかし、AE ほど強力ではありません)。 | Note: [[ディスク暗号化]]は、[[Data at Rest]]の特別なケースです。例: ハードディスクドライブ上の暗号ファイルシステム。 XTS-AES モードは、[[ディスク暗号化]]に最適化されていて、NIST の approved モードの１つです。これは、機密性とデータマニピュレーションに対するいくつもの保護を提供します(しかし、AE ほど強力ではありません)。 | ||
| − | + | ==== ルール - パスワードは、ソルトを利用し、一方向で保存する ==== | |
| − | パスワードストレージでは、PBKDF2,bcrypt,scryptを使用します。パスワードストレージに関する詳しい情報は、[ | + | パスワードストレージでは、PBKDF2,bcrypt,scryptを使用します。パスワードストレージに関する詳しい情報は、[[パスワードストレージのチートシート]](Password Storage Cheat Sheet)を参照してください。 |
| − | + | ==== ルール - アクセスコントロールが失敗しても、暗号による保護がセキュアに保たれることを確保する ==== | |
| − | このルールは、[[多層防御]]の原則をサポートします。アクセスコントロール( | + | このルールは、[[多層防御]]の原則をサポートします。アクセスコントロール(ユーザ名、[[パスワード]]、権限、など)は、あるレイヤーで保護されます。 |
たとえ攻撃者がデータベースアクセスコントロール層を突破しても、データが保護され続けるように、Storage encryption は、追加の保護のレイヤーを加えるべきです。 | たとえ攻撃者がデータベースアクセスコントロール層を突破しても、データが保護され続けるように、Storage encryption は、追加の保護のレイヤーを加えるべきです。 | ||
| − | ==== | + | ==== ルール - 不正アクセスから秘密鍵が保護されることを確保する ==== |
unauthorized access = 不正アクセス | unauthorized access = 不正アクセス | ||
| − | ===== | + | ===== ルール - 鍵のライフサイクルを定義する ===== |
鍵のライフサイクルは、鍵のライフの間でさまざまな状態になります。 | 鍵のライフサイクルは、鍵のライフの間でさまざまな状態になります。 | ||
ライフサイクルを明記すると、以下の通りです。 | ライフサイクルを明記すると、以下の通りです。 | ||
| 行80: | 行82: | ||
* 新しい鍵が導入されたときに、データが暗号鍵を変更されたかどうか | * 新しい鍵が導入されたときに、データが暗号鍵を変更されたかどうか | ||
* 同時にすべての鍵を削除しなければならないとき | * 同時にすべての鍵を削除しなければならないとき | ||
| − | ===== | + | ===== ルール - 暗号化されたデータ（暗号文）から離して復号キーを保存する ===== |
鍵をデータと共に保存している場合、データの侵害は、さらに簡単に鍵を侵害できます。復号キー(復号鍵)は、データと同じマシンやクラスタに保存してはなりません。 | 鍵をデータと共に保存している場合、データの侵害は、さらに簡単に鍵を侵害できます。復号キー(復号鍵)は、データと同じマシンやクラスタに保存してはなりません。 | ||
| − | + | ===== ルール - 複数の鍵が要求されたときに依存しない鍵を利用する ===== | |
キーマテリアルは、独立であることを確保します。ファイ書のキーに関連する簡単なセカンドキーを選択してはいけません。 | キーマテリアルは、独立であることを確保します。ファイ書のキーに関連する簡単なセカンドキーを選択してはいけません。 | ||
| − | + | ===== ルール - key vault で鍵を保護する ===== | |
鍵は、常時、保護された key vault で管理すべきです。 | 鍵は、常時、保護された key vault で管理すべきです。 | ||
とくに、 「データへ直接アクセスできる脅威ベクトル(threat vector)」と「鍵へ直接アクセスできる脅威ベクトル(threat vector)」の間のギャップを保証にします。これは、鍵は、アプリケーションやウェブサーバに鍵を保存しない、ということをほのめかしています(アプリケーション攻撃者は、適切な脅威モデルの一部であると仮定します)。 | とくに、 「データへ直接アクセスできる脅威ベクトル(threat vector)」と「鍵へ直接アクセスできる脅威ベクトル(threat vector)」の間のギャップを保証にします。これは、鍵は、アプリケーションやウェブサーバに鍵を保存しない、ということをほのめかしています(アプリケーション攻撃者は、適切な脅威モデルの一部であると仮定します)。 | ||
| − | + | ===== ルール - 鍵管理のライフサイクルの具体的な手順をドキュメントにする ===== | |
これらの手続きは、書き出されなければなりません。鍵の管理者は、十分に訓練されてなければなりません。 | これらの手続きは、書き出されなければなりません。鍵の管理者は、十分に訓練されてなければなりません。 | ||
| − | + | ===== ルール - 定期的な鍵交換をサポートする ===== | |
鍵のローテーションは、すべての良い鍵は、失効(expiration)、取消(廃止, revocation)を通して、終わらなければなりません。開発者は、いくつかのポイントで、鍵のローテーションを扱わなければなりません。 | 鍵のローテーションは、すべての良い鍵は、失効(expiration)、取消(廃止, revocation)を通して、終わらなければなりません。開発者は、いくつかのポイントで、鍵のローテーションを扱わなければなりません。 | ||
| − | + | ===== ルール - 鍵の漏えい(鍵の危殆化?)をハンドルするための具体的な手順をドキュメントにする ===== | |
| − | + | ===== ルール - 少なくとも３年ですべての鍵を変える ===== | |
鍵の再作成([[rekeying]])は、「データの復号」と「新しい鍵を用いた再暗号化」のプロセスを指します。定期的に、鍵の再作成は、古い鍵の未検出の侵害からのデータの保護の助けになります。適切な、鍵の再作成の期間は、鍵のセキュリティに依存します。専用のハードウェアセキュリティモジュール([[HSM]])によって保護される鍵によってデータが保護されるなら、３年おきに鍵の再作成が必要です。２つのアプリケーションサーバに分割して保持している鍵によってデータが保護されているなら、毎年、鍵を交換すべきです。 | 鍵の再作成([[rekeying]])は、「データの復号」と「新しい鍵を用いた再暗号化」のプロセスを指します。定期的に、鍵の再作成は、古い鍵の未検出の侵害からのデータの保護の助けになります。適切な、鍵の再作成の期間は、鍵のセキュリティに依存します。専用のハードウェアセキュリティモジュール([[HSM]])によって保護される鍵によってデータが保護されるなら、３年おきに鍵の再作成が必要です。２つのアプリケーションサーバに分割して保持している鍵によってデータが保護されているなら、毎年、鍵を交換すべきです。 | ||
| − | + | ==== ルール - 暗号の利用において適用できる規制に従う ==== | |
| − | + | ===== ルール - PCI DSS リクワイアメント 3 において、カード所有者のデータを保護しなければならない ===== | |
Payment Card Industry (PCI) Data Security Standard (DSS) は、カード保持者のデータ・セキュリティを推進し、高めめ、地球規模で、一環したデータ・セキュリティを測定の幅広い採用を用意にするために、作られました。この標準は 2005 年に導入され、Visa, マスターカード(Mastercard), Amex, JCB や DIners で個々のコンプライアンススタンダードと置き代わりました。 | Payment Card Industry (PCI) Data Security Standard (DSS) は、カード保持者のデータ・セキュリティを推進し、高めめ、地球規模で、一環したデータ・セキュリティを測定の幅広い採用を用意にするために、作られました。この標準は 2005 年に導入され、Visa, マスターカード(Mastercard), Amex, JCB や DIners で個々のコンプライアンススタンダードと置き代わりました。 | ||
| 行101: | 行103: | ||
== 関連項目 == | == 関連項目 == | ||
* [[暗号]] | * [[暗号]] | ||
| + | * [[ソルト]] | ||
<!-- vim: filetype=mediawiki | <!-- vim: filetype=mediawiki | ||
--> | --> | ||
2015年8月2日 (日) 23:15時点における最新版
暗号ストレージのチートシートは、OWASPのCryptographic Storage Cheat Sheetの Last revision (mm/dd/yy): 07/18/2015 です。暗号は、情報セキュリティにおいて、非常に重要な技術の１つです。暗号は、データを守るために利用されます。データの機密性、完全性を保つために利用されます。暗号では、使うべきアルゴリズム、使うべき実装、使うべき暗号鍵の鍵長、暗号鍵のライフサイクルマネジメントとローテーションなど考慮すべきポイントが多数あります。このドキュメントは、そういった大切なことをルール化したものです。
読み方
- 暗号
- あんごう
- Cryptographic Storage Cheat Sheet
- くりぷとぐらふぃっく すとれーじ ちーとしーと
目次
- 1 概要
- 2 暗号の機能の提供
- 2.1 セキュアな暗号ストレージのデザイン
- 2.1.1 ルール - 必要なセンシティブデータのみ保存する
- 2.1.2 ルール - 強力な許可された Authenticated Encryption (認証付き暗号)を利用する
- 2.1.3 ルール - パスワードは、ソルトを利用し、一方向で保存する
- 2.1.4 ルール - アクセスコントロールが失敗しても、暗号による保護がセキュアに保たれることを確保する
- 2.1.5 ルール - 不正アクセスから秘密鍵が保護されることを確保する
- 2.1.5.1 ルール - 鍵のライフサイクルを定義する
- 2.1.5.2 ルール - 暗号化されたデータ（暗号文）から離して復号キーを保存する
- 2.1.5.3 ルール - 複数の鍵が要求されたときに依存しない鍵を利用する
- 2.1.5.4 ルール - key vault で鍵を保護する
- 2.1.5.5 ルール - 鍵管理のライフサイクルの具体的な手順をドキュメントにする
- 2.1.5.6 ルール - 定期的な鍵交換をサポートする
- 2.1.5.7 ルール - 鍵の漏えい(鍵の危殆化?)をハンドルするための具体的な手順をドキュメントにする
- 2.1.5.8 ルール - 少なくとも３年ですべての鍵を変える
- 2.1.6 ルール - 暗号の利用において適用できる規制に従う
- 2.1 セキュアな暗号ストレージのデザイン
- 3 関連項目
概要
暗号は、攻撃者からデータを守ったり、運用者からデータを保護したり、といった目的で利用されます。暗号は、注意すべきポイントがいくつもあります。そのポイントを知りたい方は、この文章を読んで下さい。
暗号は、ウェブサービスやITシステムでは、通信経路の暗号化、保存データの暗号化といったように、いろいろなところで利用されています。Eコマースのサービスでは、個人情報や決済情報(クレジットカード番号や銀行口座番号)などを扱うことになります。個人情報や決済情報を預かる場合には、本当に必要なものだけを保存し、そして、その情報を暗号化するなどの対策を実施する必要があります。
暗号の機能の提供
セキュアな暗号ストレージのデザイン
ルール - 必要なセンシティブデータのみ保存する
おおくの Eコマースビジネスは、自動継続請求(recurring billing)のためにクレジットカード情報を保存するための 3rd party プロバイダを利用します。これは、クレジットカード番号を安全に保つための義務を押し付けます。
ルール - 強力な許可された Authenticated Encryption (認証付き暗号)を利用する
例: CCM(Counter with CBC-MAC モード)やGCM(Galois/Counter Mode)は、AESアルゴリズムに基づいた Authenticated Encryption (認証付き暗号) モードです。
ルール - 強力な許可された暗号アルゴリズムを利用する
たとえ、簡単だったとしても、自分自身で既存の暗号アルゴリズムを実装しません。その代わり、広く許可されたアルゴリズムや広く許可された実装を利用します。
AES、RSA 公開鍵暗号や SHA-256 やそれ以上のハッシングのような許可された公のアルゴリズムだけを利用します。MD5やSHA-1のような弱いアルゴリズムを利用してはいけません。
パスワードストレージのためのハッシングを避け、その代わりに、PBKDF2(鍵導出関数), bcrypt や scrypt を利用します。 「強い」と分類される暗号アルゴリズムは、時間とともに変化します。
以下の文章を参考にしてください。
- NIST approved algorithms
- ISO TR 14742 “Recommendations on Cryptographic Algorithms and their use”
- Algorithms, key size and parameters report – 2014
- AES暗号
- RSA
- SHA
実装は、その作成のために暗号専門家の複雑さを持ちます。もし、可能であれば、FIPS 140-2 certified の実装を利用してください。
異なるアルゴリズムと鍵長(Key length)でどのようにお互いを比較するかについては、 NIST approved algorithms 表2 "Comparable strengths" for the strength("security bits") を参照してください。
- 一般には、異なるアルゴリズムを利用するところで、それらは、匹敵する強度をもたなければなりません。例えば、AES-128 key で暗号化されることになっているなら、暗号化には、 AES-128 key 以上やRSA-3072 以上が使用できます。
- 一般には、ハッシュ長は、対称/非対称アルゴリズムによって提供されるセキュリティビットの２倍です。 例: SHA-224 for 3TDEA(112 security bits) ( Birthday Attack のために )。
もし、鍵を守るためのパスワードを利用するなら、パスワードの強度は、守りたい鍵の強度のために十分でなければなりません。
ルール - 許可された暗号モードを利用する
一般に、AESやDESや対称暗号のプリミティブを直接利用してはいけません。 NIST が許可しているモードを使います。
注意: データの暗号化には、ECB モードを使いません(ほかのモードのほうが安全です。なぜなら、それらは、データ・セキュリティの改善のために、データのブロックをチェインしています。)。
ルール - 強力な乱数を利用する
すべての乱数、とくに、暗号パラメータでの利用(鍵、初期ベクトル(IV)、MAC tags)、ランダムファイル名、ランダム GUID 、ランダム文字列は、暗号法論的に強度のあるファッションで生成されなければなりません。
ランダムアルゴリズムは、十分なエントロピーによって、生成されていることを保証します。
NIST PNG テストツール(PCI PTS Derived Test Requirement で利用される)のようなツールは、乱数ジェネレーターの包括的な品質評価で利用されます。例えば、PNG ソースから128MBのデータを読み、ツールで、偶然性のプロパティの評価を行います。
ルール - データの Authenticated Encryption (認証付き暗号) を利用する
一定のAPIの元で AE(Authenticated Encryption)モードを使用します。CCMやGCMなどを含むモードを推奨します。
- Authenticated Encryption は、機密性、完全性、真正性(authenticity) を提供します。暗号単体では、機密性だけを提供します。暗号は、メッセージ完全性と真正性の保護と常に結合されなければなりません。さもなければ、暗号文は、特に信頼できないチャンネル(例えば、URLやcookie)を通して、引き渡される場合、プレーンテキストデータでの変更を引き起こす操作で脆弱かもしれません。
- これらのモードは、単一のキーを要求します。一般に、tag size や IV サイズは、最大値をセットしなければなりません。
もしれ、これらの推奨 AE モードが利用できないなら
- HMACやCMAC のような(Encrypt-then-MAC, 暗号化してからMAC) post-encryption message authentication code(暗号後のメッセージ認証符号) と cipher-block chaining(CBC)モードでの結合暗号
- ２つのオペレーションが独立させるために、２つの独立した鍵を使用します。
- 様々なデータ長に CBC MAC を利用しません。
- CCMやEAX, CMACのような 機密性や真正性を提供する AESやそれにかわる Authenticated Encryption モードがない場合に、CAVP program は、暗号アルゴリズムの検証のために良いデフォルトの場所です。Java の場合で、 SunJCE を利用しているケースです。JDK 1.5以上で暗号モードは、CBC, CFB, CFBx, CTR, CTS, ECB, OFB, OFBx, PCBC がサポートされています。いずれの暗号モードも Authenticated Mode ではありません。 Bouncy Castle, RSA JSafe, IAIK, のような 交互の JCE provider を利用しているならば、 Authenticated Encryption モードを使用しなければなりません。
Note: ディスク暗号化は、Data at Restの特別なケースです。例: ハードディスクドライブ上の暗号ファイルシステム。 XTS-AES モードは、ディスク暗号化に最適化されていて、NIST の approved モードの１つです。これは、機密性とデータマニピュレーションに対するいくつもの保護を提供します(しかし、AE ほど強力ではありません)。
ルール - パスワードは、ソルトを利用し、一方向で保存する
パスワードストレージでは、PBKDF2,bcrypt,scryptを使用します。パスワードストレージに関する詳しい情報は、パスワードストレージのチートシート(Password Storage Cheat Sheet)を参照してください。
ルール - アクセスコントロールが失敗しても、暗号による保護がセキュアに保たれることを確保する
このルールは、多層防御の原則をサポートします。アクセスコントロール(ユーザ名、パスワード、権限、など)は、あるレイヤーで保護されます。
たとえ攻撃者がデータベースアクセスコントロール層を突破しても、データが保護され続けるように、Storage encryption は、追加の保護のレイヤーを加えるべきです。
ルール - 不正アクセスから秘密鍵が保護されることを確保する
unauthorized access = 不正アクセス
ルール - 鍵のライフサイクルを定義する
鍵のライフサイクルは、鍵のライフの間でさまざまな状態になります。 ライフサイクルを明記すると、以下の通りです。
- 鍵が暗号でもう使われなくなったとき
- 鍵が復号のためにもう使われなくなったとき(かならずしも同時に起こる必要はない)
- 新しい鍵が導入されたときに、データが暗号鍵を変更されたかどうか
- 同時にすべての鍵を削除しなければならないとき
ルール - 暗号化されたデータ（暗号文）から離して復号キーを保存する
鍵をデータと共に保存している場合、データの侵害は、さらに簡単に鍵を侵害できます。復号キー(復号鍵)は、データと同じマシンやクラスタに保存してはなりません。
ルール - 複数の鍵が要求されたときに依存しない鍵を利用する
キーマテリアルは、独立であることを確保します。ファイ書のキーに関連する簡単なセカンドキーを選択してはいけません。
ルール - key vault で鍵を保護する
鍵は、常時、保護された key vault で管理すべきです。 とくに、 「データへ直接アクセスできる脅威ベクトル(threat vector)」と「鍵へ直接アクセスできる脅威ベクトル(threat vector)」の間のギャップを保証にします。これは、鍵は、アプリケーションやウェブサーバに鍵を保存しない、ということをほのめかしています(アプリケーション攻撃者は、適切な脅威モデルの一部であると仮定します)。
ルール - 鍵管理のライフサイクルの具体的な手順をドキュメントにする
これらの手続きは、書き出されなければなりません。鍵の管理者は、十分に訓練されてなければなりません。
ルール - 定期的な鍵交換をサポートする
鍵のローテーションは、すべての良い鍵は、失効(expiration)、取消(廃止, revocation)を通して、終わらなければなりません。開発者は、いくつかのポイントで、鍵のローテーションを扱わなければなりません。
ルール - 鍵の漏えい(鍵の危殆化?)をハンドルするための具体的な手順をドキュメントにする
ルール - 少なくとも３年ですべての鍵を変える
鍵の再作成(rekeying)は、「データの復号」と「新しい鍵を用いた再暗号化」のプロセスを指します。定期的に、鍵の再作成は、古い鍵の未検出の侵害からのデータの保護の助けになります。適切な、鍵の再作成の期間は、鍵のセキュリティに依存します。専用のハードウェアセキュリティモジュール(HSM)によって保護される鍵によってデータが保護されるなら、３年おきに鍵の再作成が必要です。２つのアプリケーションサーバに分割して保持している鍵によってデータが保護されているなら、毎年、鍵を交換すべきです。
ルール - 暗号の利用において適用できる規制に従う
ルール - PCI DSS リクワイアメント 3 において、カード所有者のデータを保護しなければならない
Payment Card Industry (PCI) Data Security Standard (DSS) は、カード保持者のデータ・セキュリティを推進し、高めめ、地球規模で、一環したデータ・セキュリティを測定の幅広い採用を用意にするために、作られました。この標準は 2005 年に導入され、Visa, マスターカード(Mastercard), Amex, JCB や DIners で個々のコンプライアンススタンダードと置き代わりました。
PCI DSS requirement 3 は、クレジットカードデータのセキュアストレージをカバーしています。この要件は、セキュアストレージのいくつかの側面をカバーしています。保存してはならないデータがあるが、要件 3.4, 3.5 と 3.6 で暗号ストレージがカバーしています。