1. 2020年6月
Cloud Security Alliance
Application Containers and Microservices WG
NIST SP 800-240A
サービス・メッシュ・アーキテクチャを利用した
セキュアなマイクロサービス・ベース・
アプリケーション構築の概説

2. 2
クラウドセキュリティアライアンス
アプリケーションコンテナ／マイクロサービスWGのご紹介
[目的]
セキュアなアプリケーションコンテナおよびマイクロサービス利用の
ためのガイダンスやベストプラクティスを発行する
アプリケーションコンテナおよびマイクロサービスのセキュリティに
関する啓発活動を行う
[WGリーダー]
Anil Karmel（NIST SP 800-180(Draft) 筆頭著者）
Andrew Wild（QTS Data Centers・CISO)

3. 3
クラウドセキュリティアライアンス
アプリケーションコンテナ／マイクロサービスWGの
作成ドキュメント例
「Challenges in Securing Application
Containers and Microservices」
(2019年7月発行）
「Best Practices for Implementing a Secure
Application Container Architecture」
(2019年7月発行）
「Best Practices in Implementing a Secure
Microservices Architecture」
（2020年2月発行）

4. 4
サービス・メッシュを利用したマイクロサービスのセキュリティ
米国NIST 「SP 800-204A: Building Secure
Microservices-based Applications Using Service-Mesh
Architecture」（2020年5月）
• サービス・プロキシーに基づく手法におけるサービス・メッシュの
コンポーネント向け展開ガイドラインを提供する:
• サービス・プロキシー向け通信構成
• Ingressプレキシー向け構成
• 外部サービスへのアクセス向け構成
• アイデンティティ／アクセス管理向け構成
• 監視機能向け構成
• ネットワーク・レジリエンス向け構成
• オリジン間リソース共有(CORS)向け構成

5. 5
[構成](1)
• 1. 序論
• 2. マイクロサービス・ベースのアプリケーション
– 背景とセキュリティ要求事項:
• 認証と権限付与の要求事項
• サービス・ディスカバリー
• ネットワーク・レジリエンス技術を介した可用性の向上
• アプリケーション監視の要求事項
• 3. サービス・メッシュ – 定義と技術的背景
• サービス・メッシュのコンポーネントと機能
• Ingressコントローラー
• Egressコントローラー
• 通信ミドルウェアとしてのサービス・メッシュ：相違点
• サービス・メッシュ：最先端

6. 6
[構成](2)
• 4. サービス・メッシュ展開の推奨事項
• サービス・プロキシー向け通信構成
• Ingressプレキシー向け構成
• 外部サービスへのアクセス向け構成
• アイデンティティ／アクセス管理向け構成
• 監視機能向け構成
• ネットワーク・レジリエンス向け構成
• オリジン間リソース共有(CORS)向け構成
• 管理運用向け許可の構成

7. 7
1. 序論
なぜサービス・メッシュか？
• SM-AR1：サービス・メッシュ・コードをマイクロサービス・アプリケーション・
コードに組込んで、サービス・メッシュが、アプリケーション開発フレームワーク
で重要な役割を果たすようにすることができる
• SM-AR2：サービス・メッシュ・コードがライブラリとして展開されると、アプリ
ケーションは、APIコール経由でサービス・メッシュにより提供されるサービスに
結合される
• SM-AR3：サービス・メッシュ機能は、マイクロサービス・インスタンスの前に
デプロイされた各プロキシとともにプロキシに展開され、マイクロサービスベー
ス・アプリケーション向けのインフラストラクチャサービスを集合的に提供する
（サイドカー・プロキシ）
• SM-AR4：サービス・メッシュ機能は、マイクロサービス・インスタンスごとでは
なく、ノードごとにデプロイされたプロキシ（例．物理的ホスト）とともにプロ
キシに展開される

8. 8
2. マイクロサービス・ベースのアプリケーション
– 背景とセキュリティ要求事項
• 認証と権限付与の要求事項
• 認証／アクセスポリシーは、マイクロサービスが呼び出すAPIの種類に依
存する
• 証明に基づく認証は、公開鍵インフラストラクチャ（PKI)と鍵管理を要
求する
• サービス・ディスカバリー
• 動的に変わるロケーションを持った各サービスに関連して、相当数の
サービスと多くのインスタンスが存在する
• 各マイクロサービスには、仮想マシン（VM)またはコンテナとして展開
されたものがあり、動的にIPアドレスが割り当てられた可能性がある
• サービスに関連するインスタンスの数は、負荷変動によって異なる
*サービス・レジストリ＝サービスリクエストの間にサービスを発見する機能

9. 9
2. 続き
• ネットワーク・レジリエンス技術を介した可用性の向上
• ロードバランサー（負荷分散）
• サーキットブレーカー（遮断機能）
• レート制限／調整
• ブルー／グリーン・デプロイメント
• カナリア・リリース
• アプリケーション監視の要求事項
• 分散ロギング、メトリクス生成、分析パフォーマンス、追跡を介した
マイクロサービスの内外のネットワークトラフィックのモニタリング

10. 10
3. サービス・メッシュ – 定義と技術的背景
• マイクロサービスの機能
• ビジネスロジック：ビジネス機能、計算処理、サービス構成／統合
• ネットワーク機能：サービス間の通信メカニズム(→サービスメッシュ)
• サービス・メッシュのコンポーネント
• データプレーン：アプリケーションからのリクエストをフォワードする機能
を提供するデータパス
• コントロールプレーン：メッシュに渡ってデータプレーン（プロキシ）の
行動を制御・構成するために使用されるAPIツール類
• サービス・メッシュの機能
• 認証と権限付与
• サービスディスカバリー
• セキュアなコミュニケーション
• コミュニケーション向けのレジリエンス／安定性機能

11. 11
3. 続き（1）
• Ingressコントローラー
• サービスメッシュ内部にある実際のAPIを覆っているすべての
クライアント向けの共通API
• HTTP／HTTPSのようなwebに適したプロトコルから、RPC／
gRPC／RESTのようなマイクロサービスが使用するプロトコルへの
プロトコル変換
• クライアントからのシングルコールに対応して、サービスメッシュ内部の
複数サービスへのコールから受け取った結果の構成
• 負荷分散
• パブリックTLS終了

12. 12
3. 続き（2）
• Egressコントローラー
• メッシュ外にあるマイクロサービス向けのマイクロサービスから発生する
内部トラフィックをコントロールするサービス・プロキシ
• 外部ネットワークへの通信をホワイトリスト化する単一セットのワーク
ロード（例．ホスト、IPアドレス）
• 資格情報の交換：外部システムの資格情報に直接アクセスするアプ
リケーションなしに、内部のID資格情報から外部の資格情報（例．
SSOトークン、API鍵）に変換する
• webに適したプロトコル（例．HTTP／HTTPS）から、マイクロ
サービスに適したプロトコル（例．RPC／gRPC／REST）への
プロトコル変換

13. 13
3. 続き（3）
• 通信ミドルウェアとしてのサービス・メッシュ：相違点
• 伝統的な分散システム向けミドルウェア：アプリケーションデリバリー・
コントローラー（ADC)、負荷分散装置、APIゲートウェイ
• マイクロサービスの通信トラフィックの特徴：「東西」＞「南北」
• 「南北」トラフィック：クライアントとアプリケーション間の通信
トラフィック
• 「東西」トラフィック：マイクロサービス間の通信トラフィック
• 軽量通信ミドルウェアとしてのサービス・メッシュ：プロダクションアプリ
ケーションとして許容できるパフォーマンス・レベルが要求される
• クラウドネイティブ・アプリケーションの機能として、マイクロサービス・
アプリケーションが、コンテナなしで導入されるケース：
サービスベース・アーキテクチャ、APIドリブン通信、コンテナベース・イン
フラストラクチャ、DevOpsプロセスに関するバイアスなど

14. 14
3. 続き（4）
• サービス・メッシュ：最先端の手法
• 各マイクロサービスをコンテナとして展開する
• アプリケーションは、コンテナ・オーケストレーション・ツールを利用して管
理されるコンテナ・クラスター（可用性とパフォーマンスの向上目的）
を活用する
• クラウドプロバイダーが提供し、コンテナ管理／オーケストレーション環
境に必要な展開／構成ツールを有するContainer as a Service
(CaaS) 経由で、アプリケーションをホストする

15. 15
4. サービス・メッシュ展開の推奨事項
• サービス・プロキシー向け通信構成（1）
項目 推奨事項 概要
SM-
DR1
サービス・プロキシーに
許容されたトラフィック
に関する推奨事項
サービス・プロキシーが関連サービス向けのトラフィックを受容できるプロトコルおよびポートの
セットを指定する機能があるべきである。デフォルトで、サービス・プロキシは、この構成により
指定された通り、トラフィックの例外を許容スべきでない。
SM-
DR2
サービス・プロキシーの
到達可能性に関する
推奨事項
サービス・プロキシーが到達できるサービス・セットは制限されるべきである。名前空間、すなわ
ち所与の名前空間またはサービスのランタイム・アイデンティティ内で特別に命名されたサービ
スに基づいてアクセスを制限する機能があるべきである。サービス・メッシュのコントロール・プ
レーンへのアクセスは、常に、リレー・ディスカバリー、異なるポリシー、テレメトリーデータに提
供されるべきである。
SM-
DR3
プロトコル転送機能に
関する推奨事項
サービス・プロキシーは、ターゲットのマイクロサービスよりも、クライアントの異なるプロトコル
との通信を支援する組込み機能を有するべきである（例．REST／HTTPリクエストからｇ
RPCリクエストへの変換またはHTTP／1.1からHTTP／2への更新）。これにより、攻撃表
面を増加させる、クライアントごとに分離したサーバー構築へのニーズを回避することが要求
される。

16. 16
• サービス・プロキシー向け通信構成（2）
項目 推奨事項 概要
SM-
DR4
ユーザーの拡張可能
性に関する推奨事項
サービス・プロキシは、ネットワーク機能を処理する組込ロジックに加えて、カスタム・ロジックを
定義するための機能を有するべきである。これにより、ユースケース固有のポリシー（例．予
め存在するまたは自家製のポリシー・エンジン）を展開するために、サービス・プロキシを拡張
できることの保証が要求される。この展開では、サンドボックス化、使用する言語のAPI／ラ
ンタイム制限、または安全を保証する事前分析の実行（例．WASM、eBPF）など、拡張
性のリスクをコントールする手段を提供すべきである。
SM-
DR5
プロキシー向け動的構
成機能に関する推奨
事項
静的構成に加えて、動的にプロキシを構成する（例．イベント・ドリブン構成アップデート）
選択肢があるべきである。言い換えれば、既知の展開時よりも、動的であることが見込まれ
る主体向けのディスカバリー・サービスがあるべきである。さらに、従来の構成下で未解決のリ
クエストを効率的に処理する（例．完了または終了）一方、プロキシはランタイム時、新た
な動的構成へ原子的に交換すべきである。これにより、ユーザートラフィックの劣化やダウンタ
イムなく（例．サービス・プロキシを再起動することなく）、ランタイム時、迅速にポリシー変更
を強制することが要求される。
SM-
DR6
アプリケーション・サー
ビスとプロキシ間の通
信構成に関する推奨
事項
アプリケーション・サービスおよびその関連プロキシは、ループバック・チャンネル（例．ローカ
ルホストIPアドレス、UNIXドメイン・ソケットなど）経由のみで通信すべきである。さらに、
サービス・プロキシは、すべての交換データ・パケットが暗号化された相互TLS（mTLS）セッ
ションを設定することによってのみ個々の通信を行うべきである。

17. 17
• Ingressプレキシー向け構成
項目 推奨事項 概要
SM-
DR7
Ingressプレキシー
に関する推奨事項
サービス・プロキシのように、Ingress（スタンドアロン）プロキシ向けにトラフィック・ルーティ
ング・ポリシーを構成する機能を有すべきである。アプリケーション・ディプロイメントのエッジま
で幅広くルーティング・ポリシーの一貫した強制が要求されるため、これが必要とされる。

18. 18
• 外部サービスへのアクセス向け構成
項目 推奨事項 概要
SM-
DR8
外部リソースへのアク
セス制限に関する推
奨事項
外部リソースまたはメッシュ外部のサービスへのアクセスは、デフォルトで無効化し、特定の目
的地へのアクセスを制限する明示的ポリシーよってのみ許容されるべきである。加えて、外部
リソースまたはサービスは、サービス・メッシュ自体のサービス（例．サービス・メッシュのサービ
ス・ディスカバリー・メカニズムに含まれる）としてモデル化すべきである。
SM-
DR9
外部リソースへのセ
キュアなアクセスに関
する推奨事項
サービス・メッシュ内部のサービス向けに構成される、同様の可用性向上機能（例．タイムア
ウト、サーキットブレーカー）が、外部リソースおよびサービスへのアクセス向けに提供される
べきである。
SM-
DR10
Egressプロキシーに
関する推奨事項
サービスおよびIngressプロキシのように、Egress（スタンドアロン）プロキシ向けにトラ
フィック・ルーティング・ポリシーを構成する機能を有すべきである。ディプロイされた時、外部リ
ソースおよびサービスへのアクセスは、これらEgressプロキシにより調整されるべきである。
Egressプロキシは、アクセスおよび可用性のポリシー（SM-DR8）を展開スべきである。こ
れは、伝統的なネットワークに基づくセキュリティ・モデルとともに作業するのに役立つ。たとえ
ば、インターネットへのアウトバウンド・トラフィックが、ネットワーク内の特定のIPからのみ許
容されると仮定する；Egressプロキシは、メッシュにおける一連のサービス向けのトラフィック
を代理する一方、そのアドレスとともに稼働するよう構成することができる。

19. 19
• アイデンティティ／アクセス管理向け構成（1）
項目 推奨事項 概要
SM-
DR11
ユニバーサル・アイデ
ンティティ・ドメインに
関する推奨事項
マイクロサービスのすべてのインスタンスのアイデンティティは、一貫性があり一意であるべきで
ある－稼働場所に関係なく共通の名前を有すべきであるという点で一貫性があり、システム
全体に渡ってという点で一意であり、サービス名がそのサービスに対応してさえすればよい。こ
れは、異なるロケーションに異なる論理的サービスがあることを意味しているのではない；
個々のサービスに各自のDNS名が割り当てられた、典型的なドメインネームシステム
（DNS)の利用は、この推奨事項を満たしている。サービス向けの一貫した名前（アイデン
ティティ）では、システムポリシーが管理可能であることが要求される。
SM-
DR12
証明書の展開の署
名に関する推奨事項
サービス・メッシュのコントロールプレーン証明管理システムでは、自己署名により証明を生成
する機能を停止すべきである。この機能は、サービス・メッシュにおいて、他のすべてのアイデン
ティティ証明向けにイニシャルサインを自動実行するために、しばしば利用される。その代わり、
メッシュのコントロールプレーンで利用される署名証明が、常に企業の既存のPKIの信頼の
基点（Root of Trust）に根付いたものである必要がある。これは、既存のPKI（例．
失効または監査向け）により、証明の管理を簡素化するものである。さらに、我々は、ロー
テーションを簡素化し、きめの細かい失効を可能にするために、別個の中間署名証明が異な
るドメイン向けに生成されるべきことを推奨している。
SM-
DR13
アイデンティティ証明
書の更新に関する推
奨事項
マイクロサービスのアイデンティティ証明の有効期間は、インフラストラクチャ内部で管理可能
なように、可能な限り短く－できれば時間の順序に従うべきである。攻撃者は、資格情報が
失効するまでの間、資格情報を利用しさえすればサービスになりすますことができるが、資格
情報を成功裏に再び奪うことは、攻撃者にとってますます難しくなっているので、この方法は
攻撃を制限するのに役立つ。

20. 20
• アイデンティティ／アクセス管理向け構成（2）
項目 推奨事項 概要
SM-
DR14
アイデンティティ変更
におけるサービス・プ
ロキシーのサイクル接
続に関する推奨事項
サービス・プロキシのアイデンティティ証明がローテーションしている時、サービス・プロキシは、
既存のコネクションを効率的に終了して、新たな証明とともに、すべての新たなコネクションを
設定すべきである。証明書は、mTLSのハンドシェイクの間のみ有効なので、新たな証明が
発行された時に既存のコネクションを置き換えることは厳格に要求されない；むしろ、遅れず
に攻撃を制限するために重要である。
SM-
DR15
アイデンティティ証明
書に署名しない場合
の推奨事項
マイクロサービスを識別するために利用される証明書は、署名認証であってはならない。
SM-
DR16
証明書発行前の
ワークロード認証に
関する推奨事項
サービス・メッシュのコントロールプレーンの証明管理システムは、アイデンティティ証明を発行
する前に、サービス・インスタンスの認証を実行すべきである。多くのシステムでは、システムの
オーケストレーション・エンジンに対するインスタンスを証明し、他のローカル証明（例．HSM
から収集した鍵）を利用することによって、これが達成可能となる。
SM-
DR17
セキュアなネーミング
サービスに関する推
奨事項
mTLSに利用される証明が、サーバー・アイデンティティを実行したら、サーバー・メッシュは、
セキュアなディスカバリー・サービスまたはDNSによって提供されるマイクロサービス名に、サー
バー・アイデンティティをマッピングするセキュアな命名サービスを提供スべきである。この要求
事項は、サーバーがマイクロサービス向けに認可されたロケーションであることを保証し、ネット
ワークハイジャックから保護するために必要である。

21. 21
• アイデンティティ／アクセス管理向け構成（3）
項目 推奨事項 概要
SM-
DR18
きめ細かいアイデン
ティティに関する推奨
事項
個々のマイクロサービスは、各自のアイデンティティを有すべきであり、このサービスのすべての
インスタンスは、ランタイム時に同じアイデンティティを示すべきである。これにより、所与の名
前空間において、マイクロサービスのレベルでアクセスポリシーが適用されることが可能となる。
これが要求されることによって、サービスごとでなく、名前空間ごとにアイデンティティを発行す
ることが、共通のマイクロサービスのランタイムにおけるデフォルトとなり、同一の名前空間にあ
るすべてのサービスが、特に指定されない限り、共通のランタイムのアイデンティティとなる。加
えて、ラベルは、サービス名（アイデンティティ）を増大させて、きめの細かいロギング構成を
可能にし、きめの細かい認可ポリシーをサポートするために、利用することができる。
SM-
DR19
認証ポリシーのス
コープに関する推奨
事項
認証のポリシー・スコープを指定する機能は、最低限、以下の選択肢を有すべきである：
(a)すべての名前空間におけるすべてのマイクロサービス、(b)特別な名前空間におけるすべ
てのマイクロサービス、(c)所与の名前空間における特定のマイクロサービス（SM-DR17で
参照したランタイム・アイデンティティを利用）。
SM-
DR20
認証トークンに関す
る推奨事項
トークンは、その中に含まれる要求が認証を保証するように、デジタル的に署名・暗号化され
るべきであり、アクセスコントロールに関する意思決定を構築するために、認証されたアイデン
ティティの増強またはその一部として利用することができる。さらに、これらのトークンは、ルー
プバック・デバイス経由（ネットワーク・パスが含まれていないことを保証するため）または暗
号化されたチャンネル経由のみで通過させるべきである。

22. 22
• 監視機能向け構成
項目 推奨事項 概要
SM-
DR21
イベントのロギングに
関する推奨事項
プロキシは、入力の妥当性エラーおよび特別な（予期しない）パラメーターのエラー、クラッ
シュ、コアダンプをロギングすべきである。共通の攻撃検知機能には、Bearerトークン再利
用攻撃およびインジェクション攻撃が含まれるべきである。
SM-
DR22
リクエストのロギング
に関する推奨事項
プロキシは、少なくとも、不規則なリクエスト（例．HTTP使用時の200番以外のレスポン
ス）向けの共通ログ形式フィールドをロギングすべきである。成功したリクエスト（例．200
番レスポンス）のロギングは、メトリックが利用可能な時、ほとんど意味がない傾向がある。
SM-
DR22
ログメッセージのコン
テンツに関する推奨
事項
ログメッセージは、最低限、イベントの日時、マイクロサービス名またはアイデンティティ、リクエ
ストトレースID、メッセージおよびその他コンテキスト情報（例．ユーザー識別子とURLのリ
クエスト時）を含むべきである。しかしながら、たとえばBearerトークンなど、機微な情報を
覆うために注意を払うべきである。
SM-
DR23
必須指標に関する推
奨事項
外部クライアントおよびマイクロサービスの呼び出し向けにサービス・メッシュを使用してメト
リックを収集するための構成には、最低限、(a)所与の期間におけるクライアント／サービス
のリクエスト数、(b)failureコードによる失敗したクライアント／サービスのリクエスト数、
(c)サービス当たりの平均レーテンシーおよび完了リクエストのライフサイクル当たり平均総
レーテンシー（理想的にはヒストグラム；またはfailureコードによる）を含むべきである。
SM-
DR24
分散トレーシングの
展開に関する推奨事
項
分散トレーシングの展開向けにサービス・プロキシを構成する時、アプリケーション・サービスが、
受け取った通信パケットのヘッダーを転送するように設定されていることを確認するよう注意を
払うべきである。

23. 23
• ネットワーク・レジリエンス向け構成
項目 推奨事項 概要
SM-
DR25
サービス・インスタンス
のヘルスチェックの展開
に関する推奨事項
再試行、タイムアウト、サーキットブレーカーまたはカナリア・デプロイメントに関連するデータ
（一般的にすべてのコントロールプレーン構成データ）は、キーバリューストアのような、堅
牢なデータストアに保存スべきである。
SM-
DR26
サービス・インスタンス
のヘルスチェックの展開
に関する推奨事項
再試行、タイムアウト、サーキットブレーカーまたはカナリア・デプロイメントに関連するデータ
（一般的にすべてのコントロールプレーン構成データ）は、キーバリューストアのような、堅
牢なデータストアに保存スべきである。
項目 推奨事項 概要
SM-
DR27
オリジン間リソース共
有(CORS)に関する
推奨事項
エッジサービス（例．マイクロサービスのエントリーポイント）は、web UIクライアント・サー
ビスとしてのように、外部サービスと通信するCORS向けに構成されることがしばしばあり得る。
エッジサービス向けのCORSポリシーは、マイクロサービス・アプリケーション・サービスのコード
を経由して処理するよりも、サービス・メッシュ機能（例．」IstioにおけるVirtualService
リソースのCorsPolicy構成）を利用して構成されるべきである。
• オリジン間リソース共有(CORS)向け構成

24. 24
• 管理運用向け許可の構成
項目 推奨事項 概要
SM-
DR28
管理運用向けアクセ
ス・コントロールに関
する推奨事項
名前空間、名前空間内で命名されたサービスなど、すべてのサービスレベルで指定可能な、
サービス・メッシュにおける全管理運用向けの粒度の細かいアクセス・コントロール許可（例．
ポリシー指定、サービス・レジリエンシー・パラメーター向けの構成パラメーター、カナリア・デプ
ロイメント、再試行など）を有すべきである。一般的に、この機能を実行するインタフェースは、
サービス・メッシュ自体の一部でなく、アプリケーションサービス・クラスターの構成に利用され
るインストール用ソフトウェアまたはオーケストレーション・ソフトウェアの一部であることがある。