コンテナプラットフォームのハードウェア対応セキュリティ 米国NIST 「NISTIR 8320B Hardware-Enabled Security: Policy-Based Governance in Trusted Container Platforms」（2022年4月）[構成] 序論 プロトタイプの展開 プロトタイピングのステージ0 プロトタイピングのステージ1 プロトタイピングのステージ2 プロトタイピングのステージ3 プロトタイピングのステージ4 参考文献

1. 2022年5月
Cloud Security Alliance
Application Containers and Microservices WG

「NISTIR 8320B ハードウェア対応セキュリティ:
信頼されたコンテナプラットフォームにおける
ポリシーベースのガバナンス」概説

2. 2
コンテナプラットフォームのハードウェア対応セキュリティ
米国NIST 「NISTIR 8320B Hardware-Enabled Security:
Policy-Based Governance in Trusted Container
Platforms」（2022年4月）
[構成]
1. 序論
2. プロトタイプの展開
3. プロトタイピングのステージ0
4. プロトタイピングのステージ1
5. プロトタイピングのステージ2
6. プロトタイピングのステージ3
7. プロトタイピングのステージ4
参考文献

3. 3
1. 序論
• 目的とスコープ:
マルチテナント型クラウド環境におけるアプリケーションコンテナの
展開を保護するための手法を記述する
• NISTIR 8320Aで議論されたIaaS（Infrastructure as a
Service）クラウドコンピューティング技術や、リソースアセットのタグ付け
フォームにおける位置情報など、セキュリティの課題を前提とする
• プロトタイピングのステージ0(信頼された計算処理プールの構築)
• プロトタイピングのステージ1(信頼されたワークロード配置の展開)
• プロトタイピングのステージ2(信頼ベース／アセットタグベースの
セキュアなワークロード配置の展開)
• 用語:「NIST IR 8320, Hardware-Enabled Security: Enabling
a Layered Approach to Platform Security for Cloud and Edge
Computing Use Cases」で記述された用語および概念に基づく

4. 4
2. プロトタイプの展開
• 目標:信頼された計算処理プール運用の原則
1. ユーザーの明確で変化するセキュリティ要求事項を充足するクラウド部分を構築する
2. 正しいアプリケーション(ワークロード)がそこに展開されるように、クラウドの該当部分への
アクセスを制御する
3. ユーザーが法令遵守を検証できるように、クラウドの該当部分の監査を可能にする
4. ワークロードイメージを暗号化し、特定のサーバーだけが復号化できることを保証する
5. 位置ベースの制限が強制された特定のアプリケーションだけが機微なデータにアクセス
できることを保証する
• プロトタイピングのステージ
• ステージ0: プラットフォームの証明と評価されたワーカーノードの設定
• ステージ1: 信頼されたワークロードの配置
• ステージ2: アセットのタグ付と信頼された位置情報
• ステージ3: 信頼ベースのワークロードの暗号化
• ステージ4: 信頼ベースのワークロードの情報へのアクセス

5. 5
• 追加リソース:
• NIST SP 800-128, Guide for Security-Focused Configuration
Management of Information Systems
https://doi.org/10.6028/NIST.SP.800-128
• NIST SP 800-137, Information Security Continuous Monitoring
(ISCM) for Federal Information Systems and Organizations
https://doi.org/10.6028/NIST.SP.800-137
• NIST SP 800-144, Guidelines on Security and Privacy in Public
Cloud Computing https://doi.org/10.6028/NIST.SP.800-144
• NIST SP 800-147B, BIOS Protection Guidelines for Servers
https://doi.org/10.6028/NIST.SP.800-147B
• Draft NIST SP 800-155, BIOS Integrity Measurement Guidelines
https://csrc.nist.gov/publications/detail/sp/800-155/draft
• NIST IR 8320, Hardware-Enabled Security: Enabling a Layered
Approach to Platform Security for Cloud and Edge Computing Use
Cases https://doi.org/10.6028/NIST.IR.8320
• NIST IR 8320A, Hardware-Enabled Security: Container Platform
Security Prototype https://doi.org/10.6028/NIST.IR.8320A

6. 6
3. プロトタイピングのステージ0
• ソリューションの全体像:信頼された計算処理プールの概念
(*NISTIR 8320A参照)
• 証明（Attestation）
ハードウェアにセキュアに保存
された一連の評価結果の
デジタル証明を提供し、依頼者
に署名および評価の妥当性を
確認
させる
• 証明のためには、信頼の起点
（Roots of Trust)が必要
出典:NIST「NISTIR 8320B Hardware-Enabled Security : Policy-Based Governance in Trusted
Container Platforms 」（2022年4月）(https://csrc.nist.gov/publications/detail/nistir/8320b/final)

7. 7
4. プロトタイピングのステージ1
• ソリューションの全体像:信頼されたワークロードの配置
同一クラウド内にサーバーAとサーバーBがあると想定(*NISTIR 8320A参照)
出典:NIST「NISTIR 8320B Hardware-Enabled Security : Policy-Based Governance in Trusted
Container Platforms 」（2022年4月）(https://csrc.nist.gov/publications/detail/nistir/8320b/final)

8. 8
• ステージ1のステップ:
1. サーバーAは、ハードウェアモジュールに評価結果を追加する、強化された
ハードウェアベースのセキュリティ機能を装備して、measured launch
機能を実行する。
2. サーバーAは、認証局に要求を送信する（要求には、様々なプラットフォーム
のファームウェアやOSコンポーネントに関する署名付きハッシュが含まれる）。
3. 認証局は、署名およびハッシュ値を検証して、プラットフォームが完全な状態
であることの証明を管理サーバーに送信する。
4. 管理サーバーは、ユーザー要件に基づいて、サーバーB上でワークロード
ポリシー要件を強制する。
5. サーバーBは、信頼済と証明されたサーバープラットフォームのみに信頼済
インフラストラクチャを要求するワークロードを実行する。
6. 各サーバープラットフォームは、それぞれの評価値に基づいて、定期的に
監査される。

9. 9
5. プロトタイピングのステージ2
• ソリューションの全体像:アセットのタグ付と信頼された位置情報
(*NISTIR 8320A参照)
• ステージ１に基づいて、継続的にモニタリングし、アセットタグの制限を強制
する機能を追加する
• ステージ2の前提条件
1. 個々の信頼済プラットフォームのインスタンス向けに、信頼された
アセットタグ情報を有する
2. アセットタグ制限の強制を含む、信頼済プラットフォーム向けの構成管理
およびポリシー強制メカニズムを提供する
3. ワークロードのオーケストレーション中、アセットタグのポリシー制限に対す
るクラウドサーバープラットフォームのアセットタグを定期的に監査する

10. 10
6. プロトタイピングのステージ3
ソリューションの全体像:信頼ベースのワークロード暗号化
• 同一クラウド内にサーバーAとサーバーBがあると想定
• ステージ1&2のベースアーキテクチャに、コンテナレジストリとキーブローカーを
追加
出典:NIST「NISTIR 8320B Hardware-Enabled Security : Policy-Based Governance in Trusted
Container Platforms 」（2022年4月）(https://csrc.nist.gov/publications/detail/nistir/8320b/final)

11. 11
• ステージ3のステップ:
1. サーバーAは、ハードウェアモジュールに評価結果を集約する強化されたハードウェア
ベースのセキュリティ機能を装備して、measured launch機能を実行する。
2. サーバーAは、認証局に要求を送信する（要求には、様々なプラットフォームのファーム
ウェアやOSコンポーネントに関する署名付きハッシュが含まれる）。
3. 認証局は、署名およびハッシュ値を検証して、プラットフォームが完全な状態であることの
証明を管理サーバーに送信する。
4. 管理サーバーは、ユーザー要件に基づいて、サーバーB上でワークロードポリシー要件を
強制する。
5. サーバーBは、信頼済と証明されたサーバープラットフォームのみに信頼済
インフラストラクチャを要求するワークロードを実行する。
6. サーバーAは、ワークロードのインスタンスを起動できるようにするために、コンテナ
レジストリから、暗号化されたワークロードイメージを引き出す。
7. キーブローカーは、サーバーAが信頼済証明報告書を有する場合のみ、ワークロード復号
化鍵を発行し、サーバーAは、ワークロードのインスタンスを起動する。
8. 各サーバープラットフォームは、それぞれの評価値に基づいて、定期的に監査される。

12. 12
7. プロトタイピングのステージ4
ソリューションの全体像:信頼ベースのワークロードの情報へのアクセス
• ステージ3のすべてのステップが完了し、ステージ4のステップ開始前に、ワーク
ロードがワーカーノードに展開されていることを想定
出典:NIST「NISTIR 8320B Hardware-Enabled Security : Policy-Based Governance in Trusted
Container Platforms 」（2022年4月）(https://csrc.nist.gov/publications/detail/nistir/8320b/final)

13. 13
• ステージ4のステップ:
1. サーバーAは、秘密鍵を保護するハードウェアのルートオブトラストを利用した署名権限を
含む中間認証局をインストールすることによって、自動実行されてきた。
2. サーバーAが、サイドカーでワークロードのインスタンスをインスタンス化すると、サイドカー
は、このアプリケーションのアイデンティティを定義する要求を呼び出した評価結果を収集
する。
3. ワークロードのサイドカーは秘密裏に、サーバーA上のトークン署名サービスに評価結果を
送信し、署名サービスは、中間認証局を利用し、これらの要求に署名して、トークンを
サイドカーに戻す。
4. サイドカーは、シークレットストアから、リクエストとともに署名済トークンを通すことによって、
タグ付けシークレットを要求する。
5. シークレットストアは、トークンの署名および有効期限を検証して、もしすべてが妥当なら、
ポリシーに対して提供された要求を利用して、シークレットを取得する。もし評価結果が
ポリシーに合致したら、シークレットはアプリケーションに発行される。
6. サイドカーは、シークレットを稼働中のワークロードインスタンスに注入する。
7. 稼働中のワークロードインスタンスは、ローカルのシークレットに簡単にアクセスして、機微
データを取得するために利用することができる。

14. 14
• 附属書A – ハードウェアルートオブトラストの展開
• 附属書B – ワークロードオーケストレーションの展開:
OpenShift
• 附属書C – ワークロード暗号化の展開
• 附属書D – 信頼されたサービスアイデンティティ(TSI)
• 附属書E – NIST SP 800-53のセキュリティコントロールおよび
文書のサポート
• 附属書F – サイバーセキュリティフレームワークのサブカテゴリーの
マッピング
• 附属書G – 頭字語およびその他の略語