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. 要約と結論

1. 2022年3月
Cloud Security Alliance
DevSecOps WG
「NIST SP 800-204C
サービスメッシュを利用したマイクロサービスベースの
アプリケーション向けDevSecOpsの展開」
概説

2. 2
サービスメッシュを利用したマイクロサービスアプリケーション開発
とDevSecOps展開
米国NIST 「NIST SP800-204C: Implementation of
DevSecOps for a Microservices-based Application
with Service Mesh」（2022年3月）
• 目的：
DevSecOps基礎向け参照プラットフォーム(Reference
Platform for DevSecOps Primitives)の展開のための
ガイダンスを提供する
• 参照プラットフォームの展開が、高度のセキュリティ保証のためにも
たらすベネフィットと、リスク管理ツールとダッシュボードのメトリクス
を利用して、継続的な運用権限(C-ATO)を提供するためのパイプ
ライン内におけるアーティファクト利用について記述する

3. 3
[構成]
• 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. 要約と結論

4. 4
2. DevSecOps基礎向け参照プラットフォーム
2.1 コンテナオーケストレーション・リソース管理プラットフォーム
• コンテナを導入するための論理的（抽象化レイヤーを構成する）または物理
的アーティファクトから構成される
2.1.1 オーケストレーションプラットフォームのセキュリティ上の限界
• マイクロサービスベースのアプリケーションは、様々なアプリケーションサービス
を必要とする: (例)認証・認可、個々のポッド向けのメトリクスの生成(モニタ
リング)、統合されたロギング(特定のリクエストの失敗の原因を確認するた
め)、追跡(アプリケーションリクエスト向けのサービスコールの順序)、トラ
フィックコントロール、キャッシュ、セキュアなingress、サービス対サービス(東
西トラフィック)、egress通信などのセキュリティサービス
• Kubernetesのようなプラットフォームにおけるポッド間の通信をセキュアにす
るためには、特定のコードを追加する必要があるが、通信するポッドには、ア
イデンティティ／アクセス管理が適用されない

5. 5
2.2 サービスメッシュ・ソフトウェア・アーキテクチャ
• マイクロサービスベースのアプリケーションが要求する様々なアプリケーション
サービスを見る場合、これらのサービスを提供するサービスメッシュソフトウェアのアーキテクチャ
を考慮する必要がある
• サービスメッシュソフトウェアは、コントロールプレーンとデータプレーンから構成される
2.2.1 コントロールプレーン
• コントロールプレーンのコンポーネントは、自らのポッド、ノードおよび関連するクラスター上
で稼働する
[コントロールプレーンの機能]
1. EnvoyのSidecar Proxyにおけるサービスディスカバリーと構成
2. 自動化された鍵と証明書の管理
3. ポリシー定義向けのAPIとテレメトリーデータの収集
4. サービスメッシュ・コンポーネント向けの構成の取込
5. サービスメッシュへのインバウンドコネクション管理(Ingressゲートウェイ)
6. サービスメッシュからのアウトバウンドコネクション管理(Egressゲートウェイ)
7. アプリケーションマイクロサービスコンテナがホストされたポッド、ノードまたは名前空間
への、Sidecar Proxyの注入

6. 6
2.2.2 データプレーン
• データプレーンのコンポーネントは、同じポッド内のコンテナ、ノードおよび関連するクラス
ター上で稼働する
[データプレーンの機能]
1. セキュアなネットワーク機能
• 実際のマイクロサービス間のルーティングまたはメッセージ通信に関連する機能
• サービスディスカバリー、セキュア(TLS)セッションの確立、個々のマイクロサービス
および関連リクエスト向けのネットワークパスやルーティング規則の確立、個々の
リクエストの認証、リクエストの認可 など
2. ポリシー強制機能
• 呼び出しサービスを認証するマイクロサービスのリクエストの一部であるJWTトークン
における情報の利用
• プロキシー内にあるコードを利用するか、外部認可サービスへの接続による、個々の
リクエスト向けのアクセスコントロールポリシーの強制 など
3. 可観測性機能
• テレメトリーデータの収集
• サービス関連ログのコントロールプレーン内にあるログ集約モジュールへの転送
• Sidecar Proxy：上記の3つの機能を実行するデータプレーンのコンポーネント

7. 7
3. DevSecOps – 組織的な対応準備、 重要な基礎、展開
3.1 DevSecOps向けの組織的な対応準備
• DevSecOpsの定義：
アプリケーションまたはプラットフォーム全体向けの大規模リリースから、継続的
インテグレーション、継続的デリバリー、継続的デプロイメント(CI/CD)のアプ
ローチへのシフトを含むソフトウェアの開発、デプロイメント、ライフサイクル管理
手法
• アプリケーションの個々の部分向けに、ソフトウェア開発者、セキュリティスペシャ
リスト、IT運用エキスパートから構成されるDevSecOpsチームを構成する

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

9. 9
3.3 DevSecOps – 重要な基礎と展開タスク
3.3.1 パイプラインの概念とCI/CDパイプライン
[CI／CDパイプラインのワークフロー]
[継続的インテグレーションと継続的デプロイメントの違い
出典：NIST 「NIST SP800-204C:
Implementation of DevSecOps
for a Microservices-based
Application with Service Mesh」
（2022年3月）

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

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

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

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

14. 14
4. 参照プラットフォーム向けDevSecOps基礎の展開
4.1 コードのタイプと参照プラットフォームのコンポーネントの記述
• アプリケーションコードとアプリケーションサービスコード:
• アプリケーションコード＝特定セットのビジネストランザクション向けデータとアプリケー
ションのロジックが含まれる
• アプリケーションサービスコード＝すべてのサービス向けコードが含まれる
• インフラストラクチャ・アズ・コード(IaC):
繰り返し可能で一貫した手法で、アプリケーションデプロイメントをホストする
インフラストラクチャリソースをプロビジョニングして構成するためのコード
• ポリシー・アズ・コード:
実行可能なモジュールとしてのセキュリティポリシー、ポリシー固有の動詞や
アーティファクトのコードを含む認証ポリシーなど
• オブザーバビリティ・アズ・コード：
システムの内的状態を推測し、いつ、なぜ、システム内でエラーが発生するの
かに関する実行可能なインサイトを提供する能力

15. 15
4.1 コードのタイプと参照プラットフォームのコンポーネントの記述(続き)
• コードのタイプをホスティングする参照プラットフォームのコンポーネント
1. ビジネス機能コンポーネント(コンテナとして展開されるものを備えた複数のマイクロ
サービスモジュールから構成される)
2. インフラストラクチャコンポーネント(コンピューター、ネットワーク、ストレージのリソース
を含む)
3. サービスメッシュコンポーネント(コントロールプレーンとサービスプロキシの組み合わせで
展開される)
4. モニタリングコンポーネント(アプリケーションの健康状態を示すパラメーターの確認に
含まれるモジュール)
• サービスメッシュコンポーネント内のポリシーと可観測性コードのタイプの配布
• プロキシー(Ingress、Sidecar、Egress)
• サービスメッシュのコントロールプレーン
• 外部モジュール

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

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

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

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

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

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

22. 22
4.10 継続的な運用権限(C-ATO)向けDevSecOpsの活用
• 継続的な運用権限を可能にするDevSecOpsパイプラインの活動
• 遵守コードのチェック: リスク管理フレームワークの遵守状況
(a) IaC – ネットワークルートの生成、リソースのプロビジョニング
(b) ポリシー・アズ・コード – AuthNとAuthZのポリシーをエンコードする
(c) セッション管理コード – mTLSセッション、JWTトークン
(d) 可観測性コード
• ランタイムの状態を表示するダッシュボード:新たなパイプラインを引き起こすプロセスによって、セキュリ
ティとパフォーマンスボトルネックの課題(可用性に影響を及ぼす)を解決するために必要なアラートと
フィードバックを提供する

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