[ハードウェア編] クラウドネイティブアーキテクチャとIoTセキュリティ・バイ・デザイン

クラウドネイティブアーキテクチャと
IoTセキュリティ・バイ・デザイン
2023年2月17日
Cloud Security Alliance Kansai Chapter
Secure DevSecOps/Serverless WG & IoT WG

2
AGENDA
• 1. はじめに
• 2. ハードウェア対応型コンテナセキュリティの標準化動向
• 3. マイクロサービスのセキュリティ標準化動向
• 4. Q&A

3
1. はじめに:コンテナ／マイクロサービスとは?
クラウドからアプリケーションコンテナ、マイクロサービスへの
移行
 APIを軸とする自律サービスの疎結合型アーキテクチャへ
IaaS
PaaS
SaaS
OS
ミドル
ウェア
アプリ
ケー
ション
ミドル
ウェア
アプリ
ケー
ション
アプリケーションコンテナ
コンテナ管理
ソフトウェア
APIゲートウェイ
UI/
UX
UI/
UX
UI/
UX
UI/
UX
処理A
処理B 処理C
データ
データデータ
マイクロサービス
クラウドサービス
出典：ヘルスケアクラウド研究会（2016年1月)

4
1. はじめに:DevOpsとは?
• アプリケーションの開発と配備を自動化することにフォーカスした、アプリケー
ション開発の新しい方法論であり考え方である
• 開発チームと運用チームの間の協力とコミュニケーションを改善してより深く
結びつけることを意味し、特にアプリケーション配備とインフラストラクチャ運用
の自動化に焦点を当てている
• コード堅牢化、変更管理、本番アプリケーションのセキュリティを改善するだけ
でなくセキュリティ運用全般をも強化してくれる
出典:日本クラウドセキュリティ
アライアンス「クラウドコンピュー
ティングのためのセキュリティガイ
ダンス v4.0」日本語版1.1
（2017年7月）
継続的インテグレーション／
継続的デプロイ（CI/CD）
パイプライン

5
1. はじめに:インダストリー4.0のユースケース(1)
• Tim Bayer et al. 「状態モニタリングおよびインダストリー4.0
配布向けフォグ-クラウドコンピューティング・インフラストラクチャ」
（2019年5月2-4日）
Proceedings of the 9th International Conference on
Cloud Computing and Services Science, CLOSER 2019,
Heraklion, Crete, Greece, May 2-4, 2019
https://www.scitepress.org/Papers/2019/75848/75848.pdf
• コンテナ化のアーキテクチャ
• インフラストラクチャサービス
• Kubernetesマスター
• Kubernetesノード
• ネットワーク・通信
出典:Tim Bayer et al. 「A Fog-Cloud Computing Infrastructure
for Condition Monitoring and Distributing Industry 4.0 Services」
（2019年5月2-4日）
(https://www.scitepress.org/Papers/2019/75848/75848.pdf)

6
1. はじめに:インダストリー4.0のユースケース(2)
• アプリケーション事例
出典:Tim Bayer et al. 「A Fog-Cloud Computing Infrastructure for Condition Monitoring and Distributing
Industry 4.0 Services」（2019年5月2-4日）(https://www.scitepress.org/Papers/2019/75848/75848.pdf)
無人搬送車
生産現場
クラウド
管理層

7
AGENDA
• 2.ハードウェア対応型コンテナセキュリティの標準化動向
• 2-1. クラウド／エッジコンピューティング向けハードウェア対応型
プラットフォームセキュリティ手法・技術
• 「NISTIR 8320 ハードウェア対応セキュリティ:クラウドとエッジコンピューティング
のユースケース向けプラットフォームセキュリティに対する階層化アプローチの対応」
(2022年5月4日)
• 2-2. ハードウェアを利用したコンテナプラットフォームの信頼性確保策
• 「NISTIR 8320A ハードウェア対応セキュリティ:コンテナプラットフォームの
セキュリティプロトタイプ」(2022年6月27日)
• 2-3. ハードウェアを利用したコンテナプラットフォームのガバナンス
• 「NISTIR 8320B ハードウェア対応セキュリティ:信頼されたコンテナプラット
フォームにおけるポリシーベースのガバナンス」（2022年4月8日）

8
2-1.クラウド／エッジコンピューティング向けハードウェア対応型
プラットフォームセキュリティ手法・技術(1)
米国NIST 「NISTIR 8320 ハードウェア対応セキュリティ:クラウドと
エッジコンピューティングのユースケース向けプラットフォームセキュリティに
対する階層化アプローチの対応」(2022年5月4日)
(https://csrc.nist.gov/publications/detail/nistir/8320/final)
 構成
1. イントロダクション
2. ハードウェアプラットフォームセキュリティの概要
3. プラットフォームの完全性の証明
4. ソフトウェアのランタイム保護メカニズム
5. データ保護と秘密計算
6. 遠隔証明（Attestation）サービス
7. ハードウェア対応セキュリティを活用したクラウドのユースケース、シナリオ
8. 次のステップ

9
 ハードウェアプラットフォームとハードウェア対応セキュリティの定義
用語説明
ハードウェア
プラットフォーム
データセンターまたはエッジコンピューティング施設にあるサーバー（例．アプリケーションサーバー、
ストレージサーバー、仮想サーバー）。サーバー・ハードウェアプラットフォームは、階層化セキュリティ
の第一の部分を表す。
ハードウェア対応
セキュリティ
ハードウェアプラットフォームを基礎とするセキュリティは、ソフトウェアやファームウェアが提供するもの
よりも強力な基盤を提供し、比較的容易に修正することができる。ハードウェアの信頼の起点
（Root of Trust）は、小さなコードベースによる小さな攻撃対象領域を表す。ハードウェアから
アプリケーションスペースまたは指定されたセキュリティコントロールまでの間、ソフトウェアおよび
ファームウェアの証明を結び付ける、ベース層の不変なハードウェアモジュールが、既存のセキュティ
展開を強化する。このような方法により、物理的セキュリティが欠落している場合や、攻撃がソフト
ウェア層から発生する場合でも、既存のセキュリティ・メカニズムは、侵害なしにセキュリティ目標を
達成するのに十分な信頼を得ることができる。
出典:National Institute of Standards and Technology (NIST) 「NISTIR 8320 Hardware-Enabled Security: Enabling a Layered Approach to
Platform Security for Cloud 3 and Edge Computing Use Cases」（2022年5月4日）
（https://csrc.nist.gov/publications/detail/nistir/8320/final）を基にヘルスケアクラウド研究会作成

10
 プラットフォームファームウェア／ハードウェアに対する脅威
• 機微なプラットフォームまたはユーザーデータへの不正アクセスおよび
潜在的な抽出
• プラットフォームファームウェアの修正
• 悪意のあるバージョンを持ったファームウェアやハードウェアの物理的
配置によるサプライチェーンの傍受
• 規制された地政学的またはその他の境界の外からのデータへのアクセス
やコードの実行
• ソフトウェア／ファームウェアベースのセキュリティメカニズムの回避

11
 プラットフォームの完全性の証明
 プラットフォームの完全性を証明する構成要素
• ソフトウェアおよびファームウェアの暗号測定値
• ファームウェアおよび構成の証明
• ファームウェアおよび構成の復旧
 完全性を証明する手法
• ハードウェアセキュリティモジュール（HSM）
• 信頼の連鎖（CoT:Chain of Trust）
• サプライチェーン保護

12
 ソフトウェアのランタイム攻撃に対する保護メカニズム
ランタイム攻撃対策例
リターン指向プログラミング(ROP)攻撃／
コール指向プログラミング(COP)攻撃／
ジャンプ指向プログラミング(JOP)攻撃
• Intel Control-Flow Enforcement Technology (Intel CET)
• Arm Pointer Authentication Code (PAC)
• Arm Branch Target Identification (BTI)
• IBM ROP and COP/JOP Attack Defenses
アドレストランスレーション攻撃 • Intel Hypervisor Managed Linear Address Translation (HLAT)
• Intel Supervisor Mode Execution Prevention (SMEP) and Supervisor Mode Access
Prevention (SMAP)
• AMD Supervisor Mode Execution Prevention (SMEP) and Supervisor Mode Access
Prevention (SMAP)
メモリ安全性違反 • Arm Privileged Access Never (PAN)
• Arm User (EL0) Execute Never (UXN) and Privileged (EL1/EL2) Execute Never
(PXN)
• Arm Memory Tagging Extension (MTE)
• Arm Hardware Enforced Capability-Based Architecture (Morello and CHERI)
サイドチャネル攻撃 • Arm Mitigations Against Side-Channel Attacks

13
 データ保護と秘密計算
 信頼された実行環境(TEE: Trusted Execution Environment)技術:
プロセッサ上に隔離された実行環境を用意する
TEE技術対策例
メモリ隔離 • Intel TME and Multi-Key Total Memory Encryption (Intel MKTME)
• AMD Secure Memory Encryption (SME)/Transparent Secure Memory Encryption (TSME)
• Arm Realm Memory Isolation and Protection
• Arm External Memory (DRAM) Encryption and Integrity with CCA
• IBM Memory Isolation Technology
アプリケーション隔離 • Intel Software Guard Extensions (SGX)
• Arm Confidential Compute Architecture (CCA)
• Arm TrustZone Trusted Execution Environment (TEE) for Armv8-A
• Arm Realm Memory Isolation and Protection
• IBM Application Isolation Technology
仮想マシン(VM)隔離 • Intel Trust Domain Extensions (Intel TDX)
• AMD Secure Encrypted Virtualization (SEV)
• Arm Confidential Compute Architecture (CCA)
• IBM VM Isolation Technology
暗号アクセラレーター • Intel Advanced Encryption Standard New Instructions (AES-NI)
• Intel QuickAssist Technology (QAT) with Intel Key Protection Technology (KPT)
• AMD Advanced Encryption Standard
• Arm Cryptographic Acceleration
• IBM Cryptographic Acceleration Technology

14
 遠隔証明（Attestation）サービス
• プラットフォーム証明の全体イメージ
• クラウドサービスプロバイダー
(CSP)のデータセンターサーバー
から、プラットフォーム上で稼働
する信頼性エージェント(AS)
サービスを経由して、プラット
フォームの構成情報や完全性
測定結果を収集する出典:National Institute of
Standards and Technology (NIST)
「NISTIR 8320 Hardware-Enabled
Security: Enabling a Layered
Approach to Platform Security for
Cloud and Edge Computing Use
Cases」（2022年5月4日）
（https://csrc.nist.gov/publications
/detail/nistir/8320/final）

15
• 信頼された実行環境(TEE)技術に基づく証明フローの全体イメージ
• TEEによって隔離された
領域の検証可能な暗号
化クオートを生成する
• クオートは、証明する
クライアントに送付され
クオートの署名を検証
する
• 署名が有効な場合、
証明するクライアントは
遠隔コードが、純正な
TEEの隔離領域で
稼働していると結論
付ける
出典:National Institute of
Standards and Technology
(NIST) 「NISTIR 8320
Hardware-Enabled
Security: Enabling a
Layered Approach to
Platform Security for Cloud
and Edge Computing Use
Cases」（2022年5月4日）
（https://csrc.nist.gov/pub
lications/detail/nistir/8320
/final）

16
 ハードウェア対応セキュリティを活用したクラウドのユースケース、シナリオ
ユースケース対策例
セキュリティインフラストラクチャの可視性・プラットフォームの完全性やセキュリティ構成の詳細(例.BIOS/UEFIのバー
ジョン、ロケーション情報、アプリケーションのバージョン)に関する暗号的に検証
可能なレポート
信頼済プラットフォーム上へのワークロードの配置・遠隔証明サービス内に維持されたプラットフォーム情報や検証済のファームウェア
／構成対策(例.Kubernetesのオーケストレーションスケジューリング)
アセットのタグ付けと信頼済ロケーション・ロケーション情報を特定した属性値をアセットタグとして利用し、サーバーハード
ウェアに割り当てて、プラットフォーム遠隔情報レポートに含める(例.TPM(信頼
されたプラットフォームモジュール)
ワークロードの機密性・エンドユーザーがワークロードのイメージを暗号化する機能を付与して、顧客
データや知財を保護するために保存場所で暗号隔離するとともに、暗号鍵管理ソ
リューションを提供する
鍵と秘密の保護・鍵を保存し、暗号化処理を実行するために、サーバーにハードウェアセキュリティ
モジュール(HSM)を装備し、ワークロードで利用する

17
2-2.ハードウェアを利用したコンテナプラットフォームの信頼性確保策(1)
米国NIST 「NISTIR 8320A ハードウェア対応セキュリティ:コンテナ
プラットフォームのセキュリティプロトタイプ」(2022年6月27日)
(https://csrc.nist.gov/publications/detail/nistir/8320a/final)
 構成
• 第1章．序論
• 第2章. プロトタイプの展開
• ステージ0:プラットフォームの証明と評価されたワーカーノードの設定
• ステージ1:信頼されたワークロードの配置
• ステージ2:アセットのタグ付と信頼された位置情報
• 第3章. プロトタイピングのステージ0
• 参考文献

18
• プロトタイプの展開
ステージ信頼性確保策
ステージ0:
プラットフォーム
の証明と評価
されたワーカー
ノードの設定
・コンテナ展開ソリューションの基本的要素は、コンテナの展開が稼働するプラットフォームが信頼できることを保証する仕組み
・プラットフォームが信頼できないと、テナントのアプリケーションやデータの侵害リスクが高まるだけでなく、要求された
クラウドサーバーのアセットタグが正確であることが保証されなくなる
・ステージ0の前提条件
1. 信頼されたものとして、クラウドサーバープラットフォームを構成する
2. 各コンテナのワーカーノードを設定する前に、クラウドサーバープラット
3. フォームの信頼性を検証（評価）する
4. コンテナランタイムの実行中、クラウドサーバープラットフォームの信頼性を監査する
ステージ1:
信頼された
ワークロードの
配置
・ワークロードの配置は、クラウドコンピューティングの重要な属性であり、拡張性や信頼性を向上させる
・ワークロードが配置されたサーバーについて、ワークロードのセキュリティポリシーに基づいて、セキュリティ保証の要求レベル
を満たすことが目的
1. 信頼済プラットフォームを有するクラウドサーバーのみに、ワークロードを展開する
ステージ2:
アセットのタグ
付と信頼された
位置情報
・ステージ１に基づいて、継続的にモニタリングし、アセットタグの制限を強制する機能を追加する
1. 個々の信頼済プラットフォームのインスタンス向けに、信頼されたアセットタグ情報を有する
2. アセットタグ制限の強制を含む、信頼済プラットフォーム向けの構成管理およびポリシー強制メカニズムを提供する
3. ワークロードのオーケストレーション中、アセットタグのポリシー制限に対するクラウドサーバープラットフォームの
アセットタグを定期的に監査する

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

20
ソリューションシステムアーキテクチャ
• ワーカーノード
• Kubelet（Kubernetes
のエージェント）
• コンテナランタイム
• OS
• ハードウェア
• 暗号モジュール
• コントロールプレーン
• コンテナオーケストレーション
ソフトウェア
• 証明サービス
• 管理サーバー

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

22
• ステージ2は、ガバナンス／リスク／コンプライアンス（GRC）ダッシュボードで、
評価結果のモニタリング・可視化機能を追加する
信頼済ブート・コンプライアンス・ビュー
単一サーバーの概要

23
2-3.ハードウェアを利用したコンテナプラットフォームのガバナンス(1)
米国NIST 「NISTIR 8320B ハードウェア対応セキュリティ:信頼さ
れたコンテナプラットフォームにおけるポリシーベースのガバナンス」
（2022年4月8日）
https://csrc.nist.gov/publications/detail/nistir/8320b/final
 目的:マルチテナント型クラウド環境におけるアプリケーションコンテナの展開を
保護するための手法を記述する
 構成
1. 序論
2. プロトタイプの展開
3. プロトタイピングのステージ0
参考文献
NISTIR 8320Aを前提とする

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

25
ソリューションの全体像:信頼ベースのワークロード暗号化
1. 同一サーバーAは、ハードウェアモジュールに評価結果を集約する強化されたハードウェアベースのセキュリティ機能を装備して、measured
launch機能を実行する。
2. サーバーAは、認証局に要求を送信する（要求には、様々なプラットフォームのファームウェアやOSコンポーネントに関する署名付きハッシュが
含まれる）。
3. 認証局は、署名およびハッシュ値を検証して、プラット
フォームが完全な状態であることの証明を管理サーバー
に送信する。
4. 管理サーバーは、ユーザー要件に基づいて、サーバーB
上でワークロードポリシー要件を強制する。
5. サーバーBは、信頼済と証明されたサーバープラット
フォームのみに信頼済インフラストラクチャを要求する
ワークロードを実行する。
6. サーバーAは、ワークロードのインスタンスを起動できる
ようにするために、コンテナレジストリから、暗号化された
ワークロードイメージを引き出す。
7. キーブローカーは、サーバーAが信頼済証明報告書を
有する場合のみ、ワークロード復号化鍵を発行し、
サーバーAは、ワークロードのインスタンスを起動する。
8. 各サーバープラットフォームは、それぞれの評価値に
基づいて、定期的に監査される。
出典:NIST「NISTIR 8320B Hardware-Enabled Security : Policy-Based Governance in Trusted
Container Platforms 」（2022年4月）(https://csrc.nist.gov/publications/detail/nistir/8320b/final)

26
ソリューションの全体像:信頼ベースのワークロードの情報へのアクセス
1. サーバーAは、秘密鍵を保護するハードウェアのルートオブトラストを利用した署名権限を含む中間認証局をインストールすることによって、
自動実行されてきた。
2. サーバーAが、サイドカーでワークロードのインスタンスを
インスタンス化すると、サイドカーは、このアプリケーションの
アイデンティティを定義する要求を呼び出した評価結果を
収集する。
3. ワークロードのサイドカーは秘密裏に、サーバーA上の
トークン署名サービスに評価結果を送信し、署名サービスは、
中間認証局を利用し、これらの要求に署名して、トークンを
サイドカーに戻す。
4. サイドカーは、シークレットストアから、リクエストとともに署名
済トークンを通すことによって、タグ付けシークレットを要求する。
5. シークレットストアは、トークンの署名および有効期限を検証
して、もしすべてが妥当なら、ポリシーに対して提供された要求を
利用して、シークレットを取得する。もし評価結果がポリシーに
合致したら、シークレットはアプリケーションに発行される。
6. サイドカーは、シークレットを稼働中のワークロードインスタンスに
注入する。
7. 稼働中のワークロードインスタンスは、ローカルのシークレットに
簡単にアクセスして、機微データを取得するために利用することができる。
出典:NIST「NISTIR 8320B Hardware-Enabled Security : Policy-Based
Governance in Trusted Container Platforms 」（2022年4月）
(https://csrc.nist.gov/publications/detail/nistir/8320b/final)

27
AGENDA
• 3. マイクロサービスのセキュリティ標準化動向
• 3-1. マイクロサービスアプリケーションのセキュリティ戦略
• 「NIST SP800-204: マイクロサービスベースアプリケーション向け
セキュリティ戦略」(2019年8月7日)
• 3-2. サービスメッシュを利用したマイクロサービスのセキュリティ
• 「NIST SP800-204A: サービスメッシュを利用したセキュアなマイクロサービス
ベースアプリケーションの構築」(2020年5月27日)
• 3-3.サービスメッシュを利用したマイクロサービスのアクセス制御
• 「NIST SP800-204B:サービスメッシュを利用したマイクロサービスベースアプ
リケーション向け属性ベースのアクセス制御」(2021年8月6日)
• 3-4. DevSecOpsとマイクロサービスのセキュリティ管理
• 「NIST SP800-204C: サービスメッシュを利用したマイクロサービスベース
アプリケーション向けDevSecOpsの展開」（2022年3月8日）

28
3-1.マイクロサービスアプリケーションのセキュリティ戦略(1)
米国NIST 「NIST SP800-204: マイクロサービスベース
アプリケーション向けセキュリティ戦略」(2019年8月7日)
(https://csrc.nist.gov/publications/detail/sp/800-204/final)
 マイクロサービスベースアプリケーションの利用が拡大する理由
a. 比較的小規模で簡素化されたコードベースにより開発することによる俊敏性
(Agility)
b. マイクロサービスの疎結合の特徴による開発プロセスでのチーム間の独立性
(Independence)
c. インフラストラクチャサービス(認証、アクセス制御、サービスのディスカバリーと通信、
ロードバランスなど)を提供する展開ツールの可用性(Availability)
 目的:セキュアなマイクロサービスベースアプリケーションを展開するための
戦略を概観する
• ステート・オブ・プラクティスのコア機能の展開オプションやアーキテクチャの構成オプ
ション(APIゲートウェイ、サービスメッシュ、マイクロサービス固有の脅威への対策など)
を分析

29
[構成]
• 1 序論
• 2 マイクロサービスベースアプリケーションシステム:技術的背景
• 2.1 マイクロサービス:概念的な見方
• 2.2 マイクロサービス:設計原則
• 2.3 ビジネスのドライバー
• 2.4 ビルディングブロック
• 2.5 マイクロサービス:相互作用のスタイル
• 2.6 マイクロサービス:ステート・オブ・プラクティスのコア機能
• 2.7 マイクロサービス:アーキテクチャフレームワーク
• 2.7.1 APIゲートウェイ
• 2.7.2 サービスメッシュ
• 2.8 マイクロサービス:モノリシックアーキテクチャとの比較
• 2.9 サービスオリエンテッドアーキテクチャ(SOA)との比較
• 2.10 マイクロサービスの利点
• 2.11 マイクロサービスの欠点

30
• 3 マイクロサービスベースアプリケーションシステム:脅威の背景
• 3.1 脅威ソースの概要のレビュー
• 3.2 マイクロサービス固有の脅威
• 4 コア機能と脅威対策展開のためのセキュリティ戦略
• 4.1 アイデンティティ／アクセス管理のための戦略
• 4.2 サービスディスカバリーメカニズムのための戦略
• 4.3 セキュアな通信プロトコルのための戦略
• 4.4 セキュリティモニタリングのための戦略
• 4.5 可用性／レジリエンシー向上の戦略
• 4.6 完全性保証の戦略
• 4.7 インターネットベースの攻撃への対策
• 5 マイクロサービスにおけるアーキテクチャフレームワークのためのセキュリティ戦略
• 附表A モノリシックアプリケーションとマイクロサービスベースアプリケーションの相違点
• 附表B セキュリティ戦略のマイクロサービスアーキテクチャ機能に対するトレーサビリティ
• 附表C 参考文献

31
[マイクロサービスベースアプリケーションシステム:脅威の背景]
• 3.1 脅威ソースの概要のレビュー
• マイクロサービスベースアプリケーションのディプロイメントスタック
• ハードウェア層
• 仮想化層
• クラウド環境
• 通信層
• サービス／アプリケーション層
• オーケストレーション層
• 3.2 マイクロサービス固有の脅威
• サービスディスカバリーメカニズムの脅威
• システム内における悪意あるコードのレジストリ
• サービスレジストリデータベースの不正(悪意あるサービスへのリダイレクトなど)
• インターネットベースの攻撃(ボットネット攻撃など)
• カスケード障害(複数サービスの疎結合状態に起因する)
他のアプリケーションにも
共通の脅威

32
[マイクロサービスのコア機能の展開および脅威対応に向けたセキュリティ戦略]
出典:NIST 「SP 800-204: Security Strategies for Microservices-based Application Systems」（2019年8月7日）
（https://csrc.nist.gov/publications/detail/sp/800-204/final）
脅威セキュリティ戦略
アイデンティティ／アクセス管理・認証（MS-SS-1）
・アクセス管理（MS-SS-2）
サービスディスカバリーのメカニズム・サービスレジストリ構成（MS-SS-3）
セキュアな通信プロトコル・セキュアな通信（MS-SS-4）
セキュリティモニタリング・セキュリティモニタリング（MS-SS-5）
遮断機能の展開・遮断機能の展開（MS-SS-6）
ロードバランシング・ロードバランシング（MS-SS-7）
レート制限・レート制限（MS-SS-8）
完全性の保証・マイクロサービスの最新版の導入（MS-SS-9）
・セッション維持の取扱（MS-SS-10）
ボットネット攻撃への対抗・資格情報の悪用やリスト型攻撃の防止（MS-SS-11）
マイクロサービスのアーキテクチャ
フレームワーク
・APIゲートウェイの展開（MS-SS-12）
・サービスメッシュの展開（MS-SS-13）

33
3-2.サービスメッシュを利用したマイクロサービスのセキュリティ(1)
米国NIST 「NIST SP800-204A: サービスメッシュを利用したセキュ
アなマイクロサービスベースアプリケーションの構築」(2020年5月27日)
(https://csrc.nist.gov/publications/detail/sp/800-204a/final)
[構成]
1. 序論
2. マイクロサービスベースのアプリケーション
– 背景とセキュリティ要求事項:
• 認証と認可の要求事項
• サービス・ディスカバリー
• ネットワーク・レジリエンス技術を介した
可用性の向上
• アプリケーション監視の要求事項
3. サービスメッシュ – 定義と技術的背景
• サービスメッシュのコンポーネントと機能
• Ingressコントローラー
• Egressコントローラー
• 通信ミドルウェアとしてのサービスメッシュ:相違点
• サービスメッシュ:最先端
4. サービス・メッシュ展開の推奨事項
• サービスプロキシー向け通信構成
• Ingressプレキシー向け構成
• 外部サービスへのアクセス向け構成
• アイデンティティ／アクセス管理向け構成
• 監視機能向け構成
• ネットワーク・レジリエンス向け構成
• オリジン間リソース共有(CORS)向け構成
• 管理運用向け許可の構成

34
・サービスメッシュ – 定義と技術的背景(1)
マイクロサービスの機能 • ビジネスロジック:ビジネス機能、計算処理、サービス構成／統合
• ネットワーク機能:サービス間の通信メカニズム(→サービスメッシュ)
サービスメッシュの
コンポーネント
• データプレーン:アプリケーションからのリクエストをフォワードする機能を提供するデータパス
• コントロールプレーン:メッシュに渡ってデータプレーン（プロキシ）の行動を制御・構成するために使用されるAPIツール類
サービスメッシュの機能 • 認証と権限付与
• サービスディスカバリー
• セキュアなコミュニケーション
• コミュニケーション向けのレジリエンス／安定性機能
Ingressコントローラー • サービスメッシュ内部にある実際のAPIを覆っているすべてのクライアント向けの共通API
• HTTP／HTTPSのようなwebに適したプロトコルから、RPC／gRPC／RESTのようなマイクロサービスが使用するプロト
コルへのプロトコル変換
• クライアントからのシングルコールに対応して、サービスメッシュ内部の複数サービスへのコールから受け取った結果の構成
• 負荷分散
• パブリックTLS終了
Egressコントローラー • メッシュ外にあるマイクロサービス向けのマイクロサービスから発生する内部トラフィックをコントロールするサービスプロキシ
• 外部ネットワークへの通信をホワイトリスト化する単一セットのワークロード（例．ホスト、IPアドレス）
• 資格情報の交換:外部システムの資格情報に直接アクセスするアプリケーションなしに、内部のID資格情報から外部の資
格情報（例．SSOトークン、API鍵）に変換する
• webに適したプロトコル（例．HTTP／HTTPS）から、マイクロサービスに適したプロトコル（例．RPC／gRPC／
REST）へのプロトコル変換

35
・サービスメッシュ – 定義と技術的背景(2)
通信ミドルウェアとし
てのサービスメッシュ
• 伝統的な分散システム向けミドルウェア:アプリケーションデリバリーコントローラー（ADC)、負荷分散装置、
APIゲートウェイ
• マイクロサービスの通信トラフィックの特徴:「東西」＞「南北」
• 「南北」トラフィック:クライアントとアプリケーション間の通信トラフィック
• 「東西」トラフィック:マイクロサービス間の通信トラフィック
• 軽量通信ミドルウェアとしてのサービスメッシュ:プロダクションアプリケーションとして許容できるパフォーマンス・レ
ベルが要求される
• クラウドネイティブ・アプリケーションの機能として、マイクロサービス・アプリケーションが、コンテナなしで導入される
ケース:
• サービスベース・アーキテクチャ、APIドリブン通信、コンテナベース・インフラストラクチャ、DevOpsプロセス
に関するバイアスなど
サービスメッシュ:
最先端の手法
• 各マイクロサービスをコンテナとして展開する
• アプリケーションは、コンテナ・オーケストレーション・ツールを利用して管理されるコンテナ・クラスター（可用性と
パフォーマンスの向上目的）を活用する
• クラウドプロバイダーが提供し、コンテナ管理／オーケストレーション環境に必要な展開／構成ツールを有する
Container as a Service (CaaS) 経由で、アプリケーションをホストする

36
3-3.サービスメッシュを利用したマイクロサービスのアクセス制御(1)
米国NIST 「NIST SP800-204B:サービスメッシュを利用した
マイクロサービスベースアプリケーション向け属性ベースのアクセス制御」
(2021年8月6日)
(https://csrc.nist.gov/publications/detail/sp/800-204b/final)
[構成]
1. イントロダクション
2. マイクロサービスベースアプリケーションとサービスメッシュ
向けの参照プラットフォーム
2.1 マイクロサービスベースアプリケーションのオーケスト
レーションとリソース管理向け参照プラットフォーム
2.2 サービスメッシュ参照プラットフォーム
– 概念アーキテクチャ
3. 属性ベースのアクセス制御(ABAC) – 背景
3.1 サービスメッシュを利用したマイクロサービスベース
アプリケーションのABAC実装
4. サービスメッシュにおける認証・認可ポリシーの構成
4.1 アプリケーションのオーケストレーション・リソース
管理プラットフォーム構成
4.2 サービスメッシュ構成
4.3 より高いレベルのアプリケーション向け構成
パラメータ
4.4 認証ポリシー
4.5 認可ポリシー
4.6 認可ポリシーの要素
5. サービスメッシュ向けABACの実装
5.1 認可フレームワークにおける参照モニターの概念
5.2 ABAC認可フレームワーク向けサポート
インフラストラクチャ
5.3 サービスメッシュ向けABAC認可フレームワークの
利点
5.4 プロキシにおける強制の代替手段
6. 要約と結論
参考文献

37
・XACML表現に基づくABAC機能アーキテクチャ
*XACML＝XMLベースのマークアップ言語で、インターネットを通じた情報アクセスに関する制御ポリシーを記述するための言語仕様
出典:NIST 「SP 800-204B: Attribute-based Access Control for Microservices-based Applications using a
Service Mesh」 (2021年8月6日) (https://csrc.nist.gov/publications/detail/sp/800-204b/final)

38
・NGAC表現に基づくABAC機能アーキテクチャ
*NGAC＝次世代アクセス制御
出典:NIST 「SP 800-204B: Attribute-based Access Control for Microservices-based Applications using a
Service Mesh」 (2021年8月6日) (https://csrc.nist.gov/publications/detail/sp/800-204b/final)

39
3-4.DevSecOpsとマイクロサービスのセキュリティ管理(1)
米国NIST 「NIST SP800-204C: サービスメッシュを利用
したマイクロサービスベースアプリケーション向けDevSecOpsの展開」
（2022年3月8日）(https://csrc.nist.gov/publications/detail/sp/800-204c/final)
 目的:
DevSecOps基礎向け参照プラットフォーム(Reference Platform for
DevSecOps Primitives)の展開のためのガイダンスを提供する
 参照プラットフォームの展開が、高度のセキュリティ保証のためにもたらす
ベネフィットと、リスク管理ツールとダッシュボードのメトリクスを利用して、
継続的な運用権限(C-ATO)を提供するためのパイプライン内における
アーティファクト利用について記述する

40
• 1 序論
• 2 DevSecOps基礎向け参照プラットフォーム
• 2.1 コンテナオーケストレーションとリソース管理プラットフォーム
• 2.2 サービスメッシュ・ソフトウェア・アーキテクチャ
• 3 DevSecOps – 組織的な対応準備、重要な基礎、展開
• 3.1 DevSecOps向けの組織的な対応準備
• 3.2 DevSecOpsプラットフォーム
• 3.3 DevSecOps – 重要な基礎と展開タスク
• 4. 参照プラットフォーム向けDevSecOps基礎の展開
• 4.1 コードのタイプと参照プラットフォームのコンポーネントの記述
• 4.2 アプリケーションコードとアプリケーションサービスコード向けのCI/CDパイプライン
• 4.3 インフラストラクチャ・アズ・コード向けのCI/CDパイプライン
• 4.4 ポリシー・アズ・コード向けのCI/CDパイプライン
• 4.5 オブザーバビリティ・アズ・コード向けのCI/CDパイプライン
• 4.6 CI/CDパイプラインのセキュア化
• 4.7 CI/CDパイプラインにおけるワークフローモデル
• 4.8 セキュリティテスト - すべてのコード向けのCI/CDパイプライン共通要求事項
• 4.9 サービスメッシュのアプリケーションセキュリティに対するDevSecOps基礎のベネフィット
• 4.10 継続的な運用権限(C-ATO)向けDevSecOpsの活用
• 5. 要約と結論

41
 DevSecOpsの定義:
• アプリケーションまたはプラットフォーム全体向けの大規模リリースから、継続
的インテグレーション、継続的デリバリー、継続的デプロイメント(CI/CD)の
アプローチへのシフトを含む、ソフトウェアの開発、デプロイメント、ライフ
サイクル管理手法
• アプリケーションの個々の部分向けに、ソフトウェア開発者、セキュリティ
スペシャリスト、IT運用エキスパートから成るDevSecOpsチームを構成する

42
 DevSecOpsプラットフォーム
(a) パイプラインソフトウェア
- CIソフトウェア – コードレポジトリからコードを取り寄せ、構築ソフトウェアを引き出し、検証ツールを引き出して、
検証済アーティファクトをイメージレジストリに戻して保存する
- CDソフトウェア – アーティファクトやパッケージを引き出し、インフラストラクチャ・アズ・コード(IaC)における
計算処理、ネットワーク、ストレージのリソースの記述に基づいて、パッケージをデプロイする
(b) ソフトウェア開発ライフサイクル（SDLC）ソフトウェア
- 構築ツール (例. IDEs)
- 検証 (SAST、DAST、SCA)
(c) レポジトリ
- ソースコード・レポジトリ (例. GitHub)
- コンテナイメージ・レポジトリまたはレジストリ
(d) 可観測性またはモニタリングツール
- ロギング・ログ集約ツール
- メトリクスを生成するツール
- トレーシングツール (アプリケーションコールのシーケンス)
- 可視化ツール (ダッシュボード/アラートを生成するために上記からのデータを組み合わせる)

43
 パイプラインの概念とCI/CDパイプライン
[CI／CDパイプラインのワークフロー]
[継続的インテグレーションと継続的デプロイメントの違い]
出典:NIST 「NIST SP800-204C:
Implementation of DevSecOps
for a Microservices-based
Application with Service Mesh」
（2022年3月8日）
出典:NIST 「NIST SP800-204C:
Implementation of DevSecOps
for a Microservices-based
Application with Service Mesh」
（2022年3月8日）

44
 CI／CD向けのビルディングブロック
• アプリケーションホスティングプラットフォームのネイティブなCI／CDを
利用する利点
・CI／CDツール自体のデプロイ、維持、管理が容易になる
・CI／CDツールによって定義されたパイプラインすべてが、別のプラットフォームの
ネイティブなリソースとなり、同様の方法で管理される
・CI／CDツールの中には、アプリケーションコードをスキャン／調査するために、
コードレポジトリと統合するものがある
・CI／CDツールの中には、ネイティブなプラットフォーム(例．Kubernetesプ
ラットフォーム向けJenkins X)向け、または複数の技術スタック(例．マルチクラ
ウドデプロイメント向けSpinnaker)向けのみに、CD機能を実行するものがある

45
 CI／CDパイプラインの準備と導入
• 準備タスク
• 導入タスク
(1)DevSecOpsプラットフォーム(パイプラインソフトウェア、SDLCソフトウェア、コードレポジトリ、可観測性ツールなど)の個々
のコンポーネントが利用可能なことを保証する
(2)これらのコンポーネントが、認証、検証、カスタマイズしたテストのいずれかを通して、セキュアであることを保証する
(3)CI／CDツールとSDLCツールと統合する – アクセストークン、呼び出しスクリプト、パイプライン定義
(4)デプロイメント環境(例．オンプレミスまたはクラウドのアプリケーションホスティングプラットフォーム)に基づく(GitOpsを
備えた)IaCツールに、構成の詳細を設定する
(5)ランタイムツールをデプロイメント環境に統合する
(6)ダッシュボードを設計し、モニターするイベントや、生成されるアラート、ログアグリゲーター、メトリックジェネレーター、トレース
ジェネレーターなどのツールへの接続を通してモニターするアプリケーションの状態変数(例．メモリ使用率など)を定義する
・ソースコードレポジトリを設定する
・プロセスを構築する
・プロセスをセキュアにする
・デプロイメント環境を記述する
・デリバリーパイプラインを構築する
・コードを検証し、パイプラインを導入する
・ランタイムツールとダッシュボードを起動し、ランタイムモニタリングを開始する

46
 自動化向けの戦略
• 自動化活動の選択:検証活動自動化の対象
• 自動化対象活動のサブセットを選定する際の戦略
・法令遵守(例．PCI-DSS、HIPAA、SOX)を必要とする機能を有するモジュールの検証
・中ー高程度の頻度で繰り返されるタスク
・メッセージパブリッシャー、メッセージサブスクライバーなど、時系列的なオペレーションを実行するモジュールの検証
・複数サービスをつなぐトランザクションを含む(例．リクエスト追跡)ワークフローの検証
・リソース集約的でパフォーマンスのボトルネックとなる可能性があるサービスの検証
・自動化するプロセスを優先順位付けするために、1年間で節約された時間単位の費用便益比率を利用する
・DevSecOpsプロセスを洗練するためのマーカーとして、重要業績評価指標(KPI)を利用する
・DevSecOpsに対するリソースの割当を決定するために、アプリケーションに基づいて、インフラストラクチャ
サービスと異なる重み付けを適用する

47
 CI／CDパイプラインにおけるセキュリティ自動化ツール向け要求事項
• CI／CDパイプラインで利用される様々な機能(例．静的脆弱性分析、
動的脆弱性分析、ソフトウェア構成分析)向けのセキュリティ自動化ツー
ルは、異なるインタフェースと警告／報告要求事項を有すべきである
[要求事項]
・セキュリティ自動化ツールは、統合開発環境(IDE)ツールとともに稼働させて、
開発者が静的脆弱性を優先順位付けして低減するのに役立てるべきである
・セキュリティ自動化ツールは、特定のワークフローを支援し、セキュリティサービス
向けのスケーリング機能を提供するために、柔軟であるべきである
・構築フェーズで、静的脆弱性のチェックを実行するツールは、安全なデータフロー
を保証し、動的脆弱性のチェックを実行するツールは、ランタイム中の安全な
アプリケーション状態を保証する

48
 参照プラットフォーム向けDevSecOps基礎の展開
コードのタイプと参照プラットフォームのコンポーネントの記述
コードのタイプコンポーネントの記述
アプリケーションコード特定セットのビジネストランザクション向けデータとアプリケーションのロジックが含まれる
アプリケーションサービスコードすべてのサービス向けコードが含まれる
インフラストラクチャ・アズ・コード
(IaC)
繰り返し可能で一貫した手法で、アプリケーションデプロイメントをホストするインフラストラクチャリソースを
プロビジョニングして構成するためのコード
ポリシー・アズ・コード実行可能なモジュールとしてのセキュリティポリシー、ポリシー固有の動詞やアーティファクトのコードを含む
認証ポリシーなど
オブザーバビリティ・アズ・コードシステムの内的状態を推測し、いつ、なぜ、システム内でエラーが発生するのかに関する実行可能な
インサイトを提供する能力
コードのタイプをホスティングす
る参照プラットフォームの
コンポーネント
1. ビジネス機能コンポーネント(コンテナとして展開されるものを備えた複数のマイクロサービスモジュールから
構成される)
2. インフラストラクチャコンポーネント(コンピューター、ネットワーク、ストレージのリソースを含む)
3. サービスメッシュコンポーネント(コントロールプレーンとサービスプロキシの組み合わせで展開される)
4. モニタリングコンポーネント(アプリケーションの健康状態を示すパラメーターの確認に含まれるモジュール)
サービスメッシュコンポーネント内
のポリシーと可観測性コードの
タイプの配布
・プロキシー(Ingress、Sidecar、Egress)
・サービスメッシュのコントロールプレーン
・外部モジュール

49
 アプリケーションコードとアプリケーションサービスコード向けのCI/CD
パイプライン
• インフラストラクチャ・アズ・コード(IaC)向けのCI/CDパイプライン
・アプリケーションコードとアプリケーションサービスコードは、コンテナオーケストレーション・リソース管理プラット
フォームに組み込まれ、それに関連するワークフローを展開するCI／CDソフトウェアは通常、同一プラットフォーム
に組み込まれる
⇒ パイプラインやオーケストレーションプラットフォームを保護する必要がある
IaC向けの保護 IaCのコード内に潜在的な脆弱性となるバグやミスが含まれる可能性があるので、
GitOpsに入力しマージする前に、IaCのすべてをスキャンする必要がある
構成とインフラストラ
クチャの違い
インフラストラクチャは、コンピューターシステムやソフトウェア、依存関係、望ましい一貫した
状態の設定を維持する構成と混同されることがある

50
 ポリシー・アズ・コード向けのCI/CDパイプライン
• ポリシーのカテゴリーとポリシー事例
ポリシーのカテゴリーポリシー事例
ネットワークポリシーと
ゼロトラストポリシー
・指定されたポートのブロック
・Ingressホスト名の指定
・一般的に、すべてのネットワークアクセスポリシー
展開アーティファクトポリシー
(例.コンテナポリシー)
・サーバーのハードニング、ベースイメージ向け脆弱性スキャン
・コンテナがrootとして稼働しないことの保証
・コンテナ向け特権エスカレーションのブロック
ストレージポリシー・持続化容量サイズの設定
・持続化容量再要求ポリシー
アクセスコントロールポリシー・ポリシーがすべてのデータオブジェクトをカバーすることの保証
・ポリシーが管理者とアプリケーションアクセス向けのすべてのロールをカバーすることの
保証
・データ保護ポリシーが保存データ、転送データ、利用データをカバーすることの保証
・すべてのタイプのポリシーについてコンフリクトのないことの保証
サプライチェーンポリシー・承認されたコンテナレジストリのみの許容
・認証されたライブラリのみの許容
監査・説明責任ポリシー・監査・説明責任機能に関連したポリシーがあることの保証

51
 オブザーバビリティ・アズ・コード向けのCI/CDパイプライン
• オブザーバビリティ・アズ・コードは、データのタイプを収集し、特定のツールに送信して
比較し、分析を実行し、ダッシュボード上に分析した統合データを表示して、アプリケー
ションレベル全体の絵を提示する
 CI/CDパイプラインのセキュア化
• [セキュリティタスクの留意点]
・サーバーホスティングコードとアーティファクトのレポジトリのハードニング
・認証トークンなどのレポジトリへのアクセスや、プルリクエストの生成向けに利用される資格情報のセキュア化
・コンテナイメージレジストリに誰がチェックイン／チェックアウトできるかに関するコントロール
・すべてのコードをロギングし、更新活動を構築する
・CIパイプラインにおいてビルドまたはテストが失敗した場合、開発者にビルドレポートを送信し、さらなるパイプラインのタスクを
中止する
・監査が失敗した場合、セキュリティチームにビルドレポートを送信し、さらなるパイプラインのタスクを中止する
・開発者がアプリケーションコードのみにアクセスでき、5つのパイプラインのコードタイプにはできないことを保証する
・ビルドとリリースのプロセス中、個々の必要なCI／CDステージの間、リリースアーティファクトに署名する
・プロダクションリリース中、すべての必要な署名が、誰もパイプラインを回避できないことを保証するために、示されていることを
証明する

52
 CI／CDパイプラインにおけるワークフローモデル
 CI/CD向けGitsOpsワークフローモデル – プルベースのモデル
ワークフローモデル留意点
プッシュベースのモデル・プッシュベースのモデルをサポートするCI／CDツールでは、後続のステージ／フェーズ
の中で、1つのパイプライントリガー変更ステージ／フェーズにおいて変更が実行される
・ディプロイメントにおける変更の基盤としてCIシステムを利用すると、ディプロイメント
環境の外で、資格情報が露出する可能性がある
プルベースのモデル・ディプロイメント環境に関わるオペレーター(例．Kubernetes Operator、Flux、
ArgoCD)は、新たなイメージがレジストリに押し出されたことを確認するやいなや、
環境の内部から新たなイメージを引き出す
ワークフローモデル留意点
GitOps ・多くのCI／CDツールがサポートするプッシュベースのモデルの代わりに、プルベースの
ワークフローモデルを利用している
プルベースのモデルが利用する
セキュリティ機能
・オーケストレーションプラットフォームで定義された認可ポリシーにより認められオペレー
ションのみを実行する(Trustはクラスター内で共有され、個々に管理しない)
・すべてのオーケストレーションプラットフォームのオブジェクトに、ネイティブでバインドし、
オペレーションが完了したか、再試行が必要かを知る

53
 セキュリティテスト-すべてのコード向けCI/CDパイプライン共通要求事項
ツールと機能／要求事項留意点
アプリケーションセキュリティテス
ト(AST)ツール
・静的AST(SAST)ツール
・動的AST(DAST)ツール
・インタラクティブAST(IAST)ツール
・ソフトウェア構成分析(SCA)ツール
ASTツール向け機能・
カバレッジ要求事項
・セキュリティ、プライバシー、コンプライアンスのギャップを特定することによって、
アプリケーションリリースの品質を向上させる
・開発者がすでに利用しているツールと統合する
・必要なカバレッジのリスクを提供する最小限のテストツールとする
・APIおよびマイクロサービスのレベルでより低いレベルの結合テストが、カバレッジを
決定するのに十分な可視性を有するべきである
・より高いレベルのUI／UXとシステムテストを含む
・ランタイムフローを検知する深いコード分析機能を有する
・リリースが実行される速度を向上させる
・費用対効果がよい

54
 サービスメッシュのアプリケーションセキュリティに対するDevSecOps基礎のベネフィット
• 継続的な運用権限(C-ATO)向けDevSecOpsの活用
・DevSecOpsのベネフィット:
・様々なITチーム、特に開発者、業務・セキュリティチームおよびその他のステークホルダー間のよりよいコミュニケーションとコラボレーション
・簡素化されたソフトウェア開発、デリバリー、デプロイメントのプロセス
・横移動を制限し、攻撃のエスカレーションを防止するゼロトラストの展開による攻撃面の低減
・セキュリティのベネフィット:
・オブザーバビリティ・アズ・コードによるすべてのリクエストのモニタリング、アラート、フィードバックのメカニズムの検証を通じ
たセキュリティの向上
(a)ランタイム – 悪意のあるコンテナの破壊
(b)フィードバック – コードを更新し、パイプラインを再び引き起こす不規則なプログラムにより、正しいレポジトリへ
(c)新たに終了したサービスを監視し、関連するサービス(例．サービスプロキシー)を調整する
(d)セキュリティのアサーションを可能にする – 回避することができない – 同一空間に展開するプロキシーによって、セキュアなセッション、
堅牢な認証＆認可、セキュアな状態移行を実現する継続的な運用権限(C-ATO)を可能にする
継続的な運用権限を可能にするDevSecOpsパイプラインの活動
・遵守コードのチェック: リスク管理フレームワークの遵守状況
(a) IaC – ネットワークルートの生成、リソースのプロビジョニング
(b) ポリシー・アズ・コード – AuthNとAuthZのポリシーをエンコードする
(c) セッション管理コード – mTLSセッション、JWTトークン
(d) 可観測性コード
・ランタイムの状態を表示するダッシュボード:新たなパイプラインを引き起こすプロセスによって、セキュリティとパフォーマンスボトルネックの課題
(可用性に影響を及ぼす)を解決するために必要なアラートとフィードバックを提供する

55
 要約と結論
・本ドキュメントは、クラウドネイティブアプリケーションをホスティングする参照プラットフォーム
向けDevSecOps基礎を展開するために包括的なガイドラインを提供する。また、参照プラット
フォームの概要を含み、基本的なDevSecOps基礎(例.CI／CDパイプライン)、ビルディング
ブロック、パイプラインの設計と導入、CI／CDパイプラインのワークフローの効率的な導入に
おける自動化の役割を記述している。
・参照プラットフォームのアーキテクチャは – アプリケーションサービスを提供するためのアプリ
ケーションコードに加えて – インフラストラクチャ向けの機能的要素、ランタイムポリシー、アプリ
ケーションの健康状態の継続的モニタリングから構成され、分離したCI／CDパイプラインの
タイプを有する宣言型コードを通して、デプロイすることができる。これらのコードのランタイム
行動、高い保証レベルのセキュリティのための展開によるベネフィット、リスク管理ツールを利用
して継続的な運用権限(C-ATO)を提供するためのパイプライン内におけるアーティファクトの
利用も記述されている。

56
AGENDA
• 4. まとめ／Q&A

[ハードウェア編] クラウドネイティブアーキテクチャとIoTセキュリティ・バイ・デザイン

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a [ハードウェア編] クラウドネイティブアーキテクチャとIoTセキュリティ・バイ・デザイン

Semelhante a [ハードウェア編] クラウドネイティブアーキテクチャとIoTセキュリティ・バイ・デザイン (20)

Mais de Eiji Sasahara, Ph.D., MBA 笹原英司

Mais de Eiji Sasahara, Ph.D., MBA 笹原英司 (20)

[ハードウェア編] クラウドネイティブアーキテクチャとIoTセキュリティ・バイ・デザイン