この文書は2016年以降更新されていません
暗号化ストレージに関するチートシート
|
最終改訂日 (yy/mm/dd): 2015/11/26 はじめに
この資料では、保存データを保護するソリューションの実装時に基準となるシンプルなモデルを紹介します。 アーキテクチャの決定保存データを適切に保護する方法を判断するには、アーキテクチャを決定する必要があります。暗号化ストレージには、さまざまな製品、方法、およびメカニズムがあります。このチートシートは、暗号化ソリューションを実装する開発者およびアーキテクトに向けて、詳細レベルのガイダンスを示すことに焦点を合わせています。具体的なベンダーのソリューションや、暗号化アルゴリズムの設計については取り上げません。 暗号化機能の提供セキュアな暗号化ストレージの設計ルール - 必要な機密データのみを保存する多くの電子商取引ビジネスでは、定期請求のためのクレジットカード情報の保存に、サードパーティの支払プロバイダーを利用しています。それにより、クレジットカード番号を安全に維持するという負担を負わずにすみます。 ルール - 強力な公認の認証付き暗号を使用するたとえば、CCM や GCM は、AES アルゴリズムに基づいた公認の認証付き暗号モードです。 ルール - 強力な公認の暗号化アルゴリズムを使用するたとえ簡単そうであっても、 既存の暗号化アルゴリズムを独自に実装してはいけません。広く受け入れられているアルゴリズムと、広く受け入れられている実装を使用します。 公認の公開アルゴリズム (共有鍵暗号 AES、公開鍵暗号 RSA、SHA-256 以上のハッシングなど) のみを使用します。脆弱なアルゴリズム (MD5 や SHA1 など) は使用してはなりません。パスワードの保存にはハッシングを避けて、PBKDF2、bcrypt または scrypt を使用します。"強力" に区分される暗号化アルゴリズムは、時間の経過とともに変化する点に注意してください。NIST 公認のアルゴリズム、ISO TR 14742 「暗号化アルゴリズム及びその使用に関する勧告」、欧州連合ネットワーク情報セキュリティ庁の「Algorithms, key size and parameters report – 2014」を参照してください。 たとえば、AES 128、RSA 3072、SHA 256 など。 実装には、少なくとも作成段階では暗号の専門家が関わるようにします。可能な場合は、FIPS 140-2 認定の実装を使用します。 各アルゴリズムと鍵長の強度 (セキュリティのビット数)、およびそれらの比較方法については、NIST 公認のアルゴリズムの表 2「Comparable strengths」を参照してください。
鍵の保護にパスワードを使用する場合は、保護する鍵の強度に相当するパスワード強度が必要になります。 ルール - 公認の暗号化モードを使用する一般に、AES や DES などの対称暗号プリミティブを直接使用してはいけません。代わりに、NIST 公認のモードを使用する必要があります。 注: 大量データの暗号化に ECB モードを使用してはなりません (その他のモードは、データのブロックを 1 つにつなげてデータセキュリティを向上させているため、より良い選択肢です)。 ルール - 強力な乱数を使用するすべての乱数、特に暗号化パラメーター (鍵、IV、MAC タグ)、ランダムなファイル名、ランダムな GUID、およびランダムな文字列に使用される乱数が、暗号強度の高い形で生成されるようにします。 乱数のアルゴリズムでは、十分なエントロピーのシード値が使用されるようにします。 NIST RNG テストツール (PCI PTS Derived Test Requirements に使用) のようなツールは、乱数ジェネレーターの包括的な品質評価に使用できます。たとえば、RNG ソースから 128MB のデータを読み込んで、このツールを使用して、当該データのランダム性を評価します。 ルール - データの認証付き暗号化を使用する一定の API で (AE) モードを使用します。推奨モードには、CCM や GCM などがあります。2014 年 11 月以降は、これらのみが NIST 公認のモードに規定されています。ISO IEC 19772 (2009) 「Information technology — Security techniques — Authenticated encryption」、および「IEEE P1619 Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices」を参照してください。
前述の推奨 AE モードが使用できない場合は、次のようにします。
注: ディスク暗号化は、特殊な保存データのケースです (ハードディスクドライブ上の暗号化ファイルシステムなど)。XTS-AES モードは、ディスク暗号化に最適化された、NIST 公認のモードの 1 つです。このモードでは、機密性とデータ改ざんに対するある程度の防御が提供されます (ただし、AE NIST 公認のモードほど強力ではありません)。これについても、「IEEE P1619 Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices」で規定されています。 ルール - パスワードは一方向の salt 値を保存するパスワードの保存には、PBKDF2、bcrypt、または scrypt を使用します。パスワードの保存の詳細については、「パスワードの保存に関するチートシート」を参照してください。 ルール - アクセス制御が適切になされていない場合でも暗号保護が安全に維持されるようにするこのルールにより、多層防御の原則をサポートします。(ユーザー名、パスワード、権限 などによる) アクセス制御は、1 つの防御層です。ストレージ暗号化は、攻撃者がデータベースアクセス制御層を侵害したとしても、データを保護し続ける追加の保護層になります。 ルール - あらゆる秘密鍵が不正なアクセスから保護されるようにするルール - 鍵のライフサイクルを定義する鍵のライフサイクルでは、鍵が有効期間中に推移するさまざまな状態を詳しく記述します。鍵のライフサイクルでは、暗号化使用の有効期限、復号化使用の有効期限 (この2つの有効期限は必ずしも一致するとは限らない)、新しい鍵の導入時にデータを暗号化し直すかどうか、そして鍵を全面使用停止にする時期を指定します。 ルール - 暗号化されたデータと暗号化されていない鍵を離して保存するデータとともに鍵を保存していると、データの侵害によって、簡単に鍵も侵害されてしまいます。暗号化されていない鍵は、データと同じマシンやクラスターに存在しないようにする必要があります。 ルール - 複数の鍵が必要な場合は独立した鍵を使用する鍵マテリアルは、独立的なものにします。つまり、最初の鍵 (または以前の鍵) との関連が容易にわかるような 2 番目の鍵を選んではいけません。 ルール - Key Vault で鍵を保護する鍵は、常に保護された Key Vault に収めておく必要があります。特に、データに直接アクセスされる脅威ベクトルと、鍵に直接アクセスされる脅威ベクトルとの間に隔たりを設けるようにします。つまり、(アプリケーションの攻撃者が関連する脅威モデルに含まれるとの前提に立てば) アプリケーションや Web サーバーに鍵を保存してはならないことを意味します。 ルール - ライフサイクル全体を通した鍵管理の具体的な手順を文書化するこれら手順は文書に記録しておく必要があり、鍵の管理者は適切なトレーニングを受けている必要があります。 ルール - アルゴリズムと鍵を必要時に変更するためのサポートを構築する鍵が侵害された場合や、外部機関が鍵を期限切れにした場合は、鍵の変更が必要になります。アプリケーションポリシーや緊急の必要性により、アプリケーション管理者はどこかの時点で鍵のローテーションや、場合によっては新たな鍵によるデータの再暗号化 が必要になります。このような状況に素早く対処できるように準備しておくのが適切です。暗号化したデータに鍵のバージョンと暗号化アルゴリズムのバージョンを含めておくと役に立つでしょう。たとえば、暗号化したデータの前に " ルール - 鍵の危殆化を処理するための具体的な手順を文書化する暗号鍵のローテーションの実行が必要になったときに、運用担当者が必要情報にすぐにアクセスして利用できるようにしておきます。鍵のローテーションでは、ソースコードへの変更や危険を伴う展開方法への変更を要求してはなりません。これをインシデントの最中に行うことは、当該担当者に多大なストレスをかけることになります。 ルール - 1 つの鍵で暗号化するデータの量を制限する暗号化したデータの量が特定のしきい値を超えた場合は、新しい鍵を使用する必要があります。この特定のしきい値は、どの暗号化アルゴリズムを使用しているかによって異なりますが、一般に、64 ビットのブロック暗号 (DES、3DES、Blowfish、RC5 など) の場合は 235 バイト (～ 34 ギガバイト)、128 ビットのブロック暗号 (AES、TwoFish、Serpent) の場合は 268 バイト (～ 295,147,905 テラバイト) になります。最新の暗号で暗号化している場合、このしきい値に達する可能性はほとんどありませんが、アルゴリズムとローテーションの手順を評価する際には考慮に入れておく必要があります。 ルール - 暗号の使用に適用される法規に従うルール - PCI DSS 要件 3 によれば、カード所有者データを保護しなければならないPCI (Payment Card Industry) DSS (Data Security Standard) は、カード所有者データセキュリティの奨励と改善、および世界的に一貫したデータセキュリティ対策の広範な採用を促進するために制定されました。この標準は、それまでの Visa、Mastercard、Amex、JCB および Diners による個別の基準に代わるものとして、2005 年に発表されました。現行バージョンは、2015 年 4 月に発行された 3.1 です。 PCI DSS 要件 3 は、クレジットカードデータの安全な保存を対象範囲にしています。この要件では、絶対に保存してはならないデータなど安全な保存に関するいくつかの側面について規定しています。ここでは、次に示す要件 3.4、3.5 および 3.6 で規定されている暗号化ストレージについて説明します。 3.4 PAN (カード所有者番号) は、どこに保存するとしても少なくとも判読不能な状態にしておく 要件 3.4 への準拠は、この標準で説明されている 4 種類の安全な保存のいずれかを実装することで満たされるようになります。その安全な保存には、データの暗号化とハッシングが含まれています。これら 2 つのアプローチは、選択肢のリストから最もよく選ばれるものです。標準では、特定のアルゴリズムを取り上げていませんが、強力な暗号化技術の使用を要求しています。PCI Council の用語集では、強力な暗号化技術は次のように定義されています。 業界で認められたテスト済みのアルゴリズムに、十分な鍵の長さと適切な鍵管理の実践が伴った暗号化技術です。暗号化技術とは、データを保護する方法で、暗号化 (復号可能) とハッシング (復号不能な "一方向") の両方を含みます。SHA-1 は、業界で認められたテスト済みのハッシュアルゴリズムの一例です。業界で認められているテスト済みの暗号化の標準およびアルゴリズムの例として、AES (128 ビット以上)、TDES (最小倍長鍵)、RSA (1024 ビット以上)、ECC (160 ビット以上)、および ElGamal (1024 ビット以上) が挙げられます。 このチートシートの 2 番目のルールを実施している場合は、PCI DSS 要件 3.4 以上に準拠している強力な暗号化アルゴリズムを実装していることになります。カードデータが保存される可能性のあるすべての場所 (ログなども含む) を特定して、適切なレベルの保護を適用する必要があります。この範囲は、データの暗号化から、ログ内のカード番号の置換にまで及ぶ可能性があります。 この要件は、ファイルまたは列レベルの暗号化ではなく、ディスクの暗号化を実装することで満たすこともできます。強力な暗号化技術の要件は、ディスク暗号化とバックアップメディアにも当てはまります。カードデータは決してプレーンテキストで保存してはなりません。また、このチートシートのガイダンスに従うことで、PCI DSS 要件 3.4 に準拠した方法で安全にデータを保存できるようになります。 3.5 カード所有者データのセキュリティ保護に使用される鍵を開示や誤使用から保護する この要件名が示しているように、暗号鍵自体を安全に保存することが求められています。これは、鍵に対する強力なアクセス制御、監査、およびロギングの実施を意味します。鍵は安全な場所に保存する必要があります。さらに、暗号化されたデータとは "異なる" 場所に保存する必要もあります。つまり、鍵データは Web サーバーやデータベースサーバーに保存してはならないということです。 鍵へのアクセスは、必要最小限のユーザーに制限します。理想を言えば、このユーザーグループは、鍵管理者の責務を遂行するだけの高い信頼性と十分なトレーニングを積んだユーザーであるべきです。当然ながら、データの暗号化 / 復号化を実行するために鍵データにアクセスするシステム / サービスアカウントには要件があります。 鍵自体をプレーンテキストで保存してはなりません。KEK (鍵暗号鍵) を使用して暗号化します。KEK は、それを暗号化している暗号鍵と同じ場所に保存してはなりません。 3.6 カード所有者データの暗号化に使用される暗号鍵の鍵管理プロセスおよび手順をすべて文書化して実施する 要件 3.6 は、PCI に準拠する会社の鍵管理プロセスでは、次に示す 8 つの具体的な鍵ライフサイクルの段階をカバーするよう義務付けています。 3.6.1 強力な暗号鍵の生成 このチートシートで前述したように、高度なデータセキュリティを実現するアルゴリズムを使用する必要があります。また、強力な鍵を生成することで、脆弱な暗号鍵によるデータセキュリティの侵害を防ぐようにします。強力な鍵は、データセキュリティ要件を十分に満たし、PCI DSS に準拠する鍵長を使用することで生成されます。鍵サイズ単独では、鍵の強さの基準にはなりません。鍵の生成に使用するデータには、十分な無作為性が必要です ("十分" かどうかは通常、データセキュリティ要件によって決まります)。また、鍵データ自体のエントロピーも高くする必要があります。 3.6.2 暗号鍵の安全な配布 鍵の配布に使用する方法は、転送中に鍵が盗難されないように安全にする必要があります。Diffie Hellman などのプロトコルの使用は、鍵の安全な配布に役立ちます。また、TLS や SSHv2 などの安全なトランスポートを使用することも、転送中の鍵の安全確保につながります。SSLv3 などの古いプロトコルは、使用してはいけません。 3.6.3 暗号鍵の安全な保存 暗号鍵の安全な保存については、KEK も含めて、要件 3.5 の説明の中で触れています (上記参照)。 3.6.4 定期的な暗号鍵の変更 PCI DSS 標準では、暗号に使用する鍵は少なくとも毎年 1 回ローテーションする必要があると規定しています。鍵のローテーションプロセスでは、暗号 / 復号プロセスから古い鍵を削除して、新しい鍵に置き換える必要があります。システムに入力する新しいデータは、すべて新しい鍵で暗号化する必要があります。少なくとも 1 年から 3 年ごとにデータの鍵を更新するという上記のルールでは、既存データを新しい鍵で更新することが推奨されていますが、これを求める明確な規定は PCI DSS にはありません。 3.6.5 鍵の完全性が脆弱になっている場合、または鍵の侵害が疑われる場合に必要と考えられる鍵の破棄や更新 鍵管理プロセスでは、鍵のアーカイブ、廃棄、または侵害への対応が必要です。このような鍵の安全な保存と更新のプロセスは、要件 3.6.2、3.6.3、および 3.6.4 のプロセスで対応できるはずです。 3.6.6 暗号鍵の知識分割と二重管理の確立 鍵管理に対する知識分割や二重管理の要件により、鍵のローテーションや削除などの鍵管理タスクが単独ユーザーでは実行できないようにします。このシステムでは、2 人のユーザーがアクション (自分の OTP の値を入力するなど) を実行してそれぞれ異なる値を生成してから、これらの値を連結することにより完全な鍵データを生成します。 3.6.7 暗号鍵の不正置換の禁止 要件 3.6.6 への準拠を実施しているシステムは、鍵データの不正な置換を十分に防止できます。二重管理プロセスに加えて、強力なアクセス制御、鍵データの監査とロギングを実施して、不正なアクセス試行を阻止し、記録する必要があります。 3.6.8 暗号鍵管理者が、鍵管理者としての職責を理解して受諾したことを示す書面に署名することを義務付け 要件 3.6 に示された強力な鍵管理の職務を果たすには、鍵管理の責務を果たす方法について理解している、信頼性の高いトレーニングを積んだ鍵管理者が必要になります。また、鍵管理者は、この役割に付随する職責について理解していることを示す書面に署名することも必要です。 関連資料OWASP - Testing for SSL-TLS、および OWASP Guide to Cryptography Authors and Primary EditorsKevin Kenan - kevin[at]k2dd.com Other CheatsheetsDeveloper Cheat Sheets (Builder)
Assessment Cheat Sheets (Breaker)
Mobile Cheat Sheets OpSec Cheat Sheets (Defender) Draft Cheat Sheets
|
