SP 800-204A (JA)

NIST 特別刊行物 800-204A

サービス・メッシュ・アーキテクチャを用いた安全なマイクロサービス型アプリケーションの構築

ラーマスワミー・チャンドラムーリ　ザック・ブッチャー

本刊行物は無償で入手可能: https://doi.org/10.6028/NIST.SP.800-204A

COMPUTER SECURITY

NIST 特別刊行物 800-204A

サービス・メッシュ・アーキテクチャを用いた安全なマイクロサービス型アプリケーションの構築

ラーマスワミー・チャンドラムーリコンピュータセキュリティ部門　情報技術研究所

ザック・ブッチャー Tetrate（米国カリフォルニア州サンフランシスコ）

本刊行物は無償で入手可能: https://doi.org/10.6028/NIST.SP.800-204A

2020 年 5 月

米国商務省　ウィルバー・L・ロス・ジュニア長官国立標準技術研究所（NIST）

権限（Authority）

本刊行物は、2014 年連邦情報セキュリティ近代化法（FISMA、44 U.S.C. § 3551 以降、公共法 113-283）に基づく NIST の法定責務に従って作成された。NIST は、連邦情報システムの最小要件を含む情報セキュリティの標準およびガイドラインの策定に責任を負うが、これらの標準およびガイドラインは、当該システムに対して政策権限を行使する適切な連邦当局の明示的な承認がない限り、国家安全保障システムには適用されない。本ガイドラインは、行政管理予算局（OMB）サーキュラー A-130 の要件と整合している。

本刊行物のいかなる内容も、法定権限に基づき商務長官によって連邦機関に義務付けられ拘束力を持つ標準およびガイドラインに反するものとして解釈されてはならない。また、本ガイドラインが、商務長官、OMB 長官、その他の連邦当局者の既存の権限を変更または優越するものとして解釈されてはならない。本刊行物は、米国外の著作権の対象外であり、米国においては民間組織が任意に使用できる。ただし、NIST としては出典を明示いただけるとありがたい。

National Institute of Standards and Technology Special Publication 800-204A Natl. Inst. Stand. Technol. Spec. Publ. 800-204A, 27 pages (May 2020) CODEN: NSPUE2

本刊行物は無償で入手可能: https://doi.org/10.6028/NIST.SP.800-204A

本書においては、実験手順または概念を適切に記述する目的で、特定の商用企業、機器、または材料を指し示す場合がある。かかる記載は、NIST による推奨や支持を暗示する意図はなく、また当該企業、材料、機器が当該目的にとって必ずしも最良であることを意味するものではない。

本刊行物には、NIST が法定責務に基づき現在策定中の他の刊行物への参照が含まれている場合がある。本刊行物に含まれる情報（概念や方法論を含む）は、当該刊行物が完成する前であっても、連邦機関が使用できる。したがって、各刊行物が完成するまでは、既存の要件、ガイドライン、手続きが存する箇所においては、有効なままである。企画および移行目的のため、連邦機関は NIST によるこれら新刊行物の策定状況を注視することが望ましい。

公開パブリック・コメント期間中にすべてのドラフト刊行物をレビューし、NIST にフィードバックを提供することを推奨する。上記以外の多くの NIST サイバーセキュリティ刊行物は https://csrc.nist.gov/publications にて入手可能である。

本刊行物へのコメント送付先

National Institute of Standards and Technology 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930

宛先: Computer Security Division, Information Technology Laboratory E メール: sp800-204a-comments@nist.gov

すべてのコメントは情報自由法（FOIA）に基づき公開対象となる。

コンピュータ・システム技術に関する報告

国立標準技術研究所（NIST）の情報技術研究所（ITL）は、国家の計測および規格インフラに対する技術的リーダーシップを提供することで、米国経済と公共の福祉を促進している。ITL は、情報技術の開発と生産的な利用を推進するため、試験、試験方法、参照データ、概念実証実装、および技術分析を開発する。ITL の責務には、連邦情報システムにおける（国家安全保障関連以外の）情報の、費用対効果の高いセキュリティとプライバシーのための管理的、運用的、技術的、物理的な標準およびガイドラインの策定が含まれる。スペシャルパブリケーション 800 シリーズは、情報システム・セキュリティに関する ITL の研究、ガイドライン、アウトリーチ活動、そして産官学との協働的取り組みを報告するものである。

要旨（Abstract）

マイクロサービス型アプリケーションの構築は増加傾向にあり、その固有の特性により、サービス間相互作用のあらゆる側面においてセキュリティに対処する必要がある。マイクロサービスの分散・クロスドメイン性は、認証と認可のためのセキュア・トークン・サービス（STS）、鍵管理と暗号化サービス、ならびに安全な通信プロトコルを必要とする。マイクロサービスが実装されるクラスター化コンテナの短命性は、安全なサービス・ディスカバリを要求する。可用性要件は、(a) 負荷分散、サーキット・ブレーク、スロットリングといったレジリエンス技術、(b)（サービスの健全性の）継続的な監視、を要求する。サービス・メッシュは、これらの要件を抽象化されたレベルで規定でき、個々のマイクロサービスのコード変更なしに、統一的かつ一貫した定義と効果的な実装を可能にする、最も知られたアプローチである。本書の目的は、マイクロサービス型アプリケーションを支える堅牢なセキュリティ基盤を構成する、プロキシ型サービス・メッシュ・コンポーネントのデプロイメント指針を提供することにある。

キーワード（Keywords）

API ゲートウェイ；アプリケーション・プログラミング・インタフェース（API）；サーキット・ブレーカ；負荷分散；マイクロサービス；サービス・メッシュ；サービス・プロキシ。

謝辞（Acknowledgements）

著者らは、IBM トーマス・J・ワトソン研究所のシニア・ソフトウェア・エンジニアである Brandon Lum 氏の広範かつ洞察に富むフィードバックに心より感謝する。また、G2-Inc の Isabel Van Wyk 氏および Tetrate Inc. の Tia Louden 氏による詳細な編集レビューにも感謝する。

特許開示に関する通知（Patent Disclosure Notice）

通知: 情報技術研究所（ITL）は、本刊行物の指針または要件の遵守に必要となり得る特許クレームを保有する者に対し、当該特許クレームを ITL に開示するよう要請している。しかし、特許保有者は ITL による特許情報の呼びかけに応じる義務はなく、また ITL は本刊行物に適用され得る特許を特定するための特許調査を実施していない。

刊行時点において、ならびに当該指針または要件の遵守に必要となり得る特許クレームの特定に関する呼びかけの後も、当該特許クレームは ITL により特定されていない。

本刊行物の使用に際して特許侵害を回避するためのライセンスが不要であると、ITL が表明または示唆するものではない。

エグゼクティブサマリー（Executive Summary）

マイクロサービス型アプリケーション・アーキテクチャは、その本質的なスケーラビリティ、デプロイの俊敏性、ツールの利用可能性により、クラウドベースおよび大規模エンタープライズ・アプリケーションの構築における規範となりつつある。同時に、マイクロサービス型アプリケーションの特性は、変更／強化されたセキュリティ要件をもたらす。

これらの特性とセキュリティへの影響の例として、以下が挙げられる。

a. マイクロサービスの数が非常に多いため、保護すべき相互接続と通信リンクが増加する。
b. マイクロサービスの短命性により、安全なサービス・ディスカバリ機構が必要となる。
c. マイクロサービスのきめ細かさにより、きめ細かな認可ポリシーをサポートする能力が必要となる。

マイクロサービス型アプリケーションの支援サービス（例：認証／認可、セキュリティ監視など）は、サービス・メッシュのような専用インフラを通じて厳密に連携されなければならない。サービス・メッシュのコンポーネントをデプロイする方法はいくつかあり、アプリケーション（マイクロサービス）・コードに埋め込む、ライブラリとして実装してアプリケーション・コードに結合する、またはアプリケーション・コードから独立したサービス・プロキシとして実装する方法がある。マイクロサービス型アプリケーションの支援インフラを実装する多くのシナリオにおいて、最後のプロキシ型のデプロイ手法が、スケーラビリティと柔軟性の点で最も効率的であることが分かっている。

本書の目的は、サービス・プロキシ型アプローチにおけるサービス・メッシュ・コンポーネントのデプロイメント指針を提供することである。サービス・メッシュのデプロイ推奨事項は、以下の側面にまたがる。

サービス・プロキシ間通信の構成
イングレス・プロキシの構成
外部サービスへのアクセス構成
アイデンティティ管理・アクセス管理の構成
監視機能の構成
ネットワーク・レジリエンスの構成
オリジン間リソース共有（CORS）の構成
管理操作の権限構成

目次（Table of Contents）

Executive Summary	Executive Summary	v
1 Introduction	1 Introduction	1
1.1	Why Service Mesh	1
1.2	Scope	2
1.3	Target Audience	2
1.4	Relationship to other NIST Guidance Documents	2
1.5	Organization of this Document	2
2 Microservices-based Application - Background and Security Requirements	2 Microservices-based Application - Background and Security Requirements	4
2.1	Authentication and Authorization Requirements	4
2.2	Service Discovery	4
2.3	Improving Availability through Network Resilience Techniques	4
2.4	Application Monitoring Requirement	5
3	Service Mesh - Definitions and Technology Background	6
3.1	Service Mesh Components & Capabilities	7
3.1.1 Ingress Controller	3.1.1 Ingress Controller	8
3.1.2 Egress Controller	3.1.2 Egress Controller	8
3.2	Service Mesh as Communication Middleware: What is Different	9
3.3	Service Mesh: State of the Art	10
4 Service Mesh Deployment Recommendations	4 Service Mesh Deployment Recommendations	11
4.1	Communication Configuration for Service Proxies	11
4.2	Configuration for Ingress Proxies	12
4.3	Configuration for Access to External Services	12
4.4	Configuration for Identity and Access Management	12
4.5	Configuration for Monitoring Capabilities	14
4.6	Configuration for Network Resilience Techniques	16
4.7	Configuration for Cross-Origin Resource Sharing (CORS)	16
4.8	Configuration of Permissions for Administrative Operations	16
5 Summary and Conclusions	5 Summary and Conclusions	17
References	References	18

1 はじめに（Introduction）

マイクロサービス・アーキテクチャは、次の理由により、エンタープライズおよびクラウドベース・アプリケーションの構築における確立されたアプローチとなっている。

俊敏性 — マイクロサービスの疎結合と高いモジュール性により、他のコンポーネント（マイクロサービス）に影響を与えることなく、独立かつ迅速な変更・デプロイが可能になった。
スケーラビリティ — マイクロサービスの特性により、それぞれを独立にスケールできる。
利用容易性 — 定義の明確なアプリケーション・プログラミング・インタフェース（API）の利用により、さまざまなマイクロサービスの統合やオンボーディングが容易になる。
ツールの利用可能性 — 自動化ツールの利用可能性が高まり、誤りのない構成とデプロイを促進する。

上記の利点にもかかわらず、マイクロサービス型アプリケーションのアーキテクチャには、変更／強化されたセキュリティ要件という課題がある。例えば、次のとおりである。

マイクロサービスが増えるほど、これらのコンポーネント間の相互接続が増え、保護すべき通信リンクも増える。
コンポーネント（マイクロサービス）は動的に出入りする可能性があるため、環境は安全なサービス・ディスカバリ要件を必要とする。
ネットワーク・ペリメータという概念が存在しない。
すべてのマイクロサービスは信頼できないものとして扱わなければならない。
マイクロサービスのきめ細かさゆえに、各マイクロサービスでのきめ細かな認可が必要となる。ただし、すべてのマイクロサービスにわたり統一的かつ一貫した執行を可能にするため、セキュリティ・ポリシーは中央で定義され、その反映となる構成が各マイクロサービスに定義される必要があるかもしれない。

1.1 なぜサービス・メッシュか（Why Service Mesh）

上述のマイクロサービス型アプリケーションに対するセキュリティ要件のため、アプリケーションを支えるインフラと、そのインフラに付随するサービス（例：セキュリティ）は厳密に連携されるべきである。そのような専用インフラの 1 つがサービス・メッシュである。サービス・メッシュを実装するコードは、マイクロサービス型アプリケーション・アーキテクチャのコンポーネントとの関係において、次のように編成できる（各アーキテクチャ・パターンは SM-ARx という頭字語で表す。SM は Service Mesh、AR は architecture、x は通し番号）。

SM-AR1: サービス・メッシュのコードをマイクロサービス・アプリケーション・コードに埋め込み、サービス・メッシュをアプリケーション開発フレームワークの不可欠な一部とする。
SM-AR2: サービス・メッシュのコードをライブラリとして実装し、アプリケーションは API 呼び出しを介してサービス・メッシュの提供するサービスに結合する。
SM-AR3: サービス・メッシュの機能をプロキシで実装し、各プロキシをマイクロサービス・インスタンスの前段にデプロイして、集合的にマイクロサービス型アプリケーションのためのインフラ・サービスを提供する。これらのプロキシは「サイドカー・プロキシ」と呼ばれ、アプリケーション・コードから独立して実装・運用できる。サイドカー・プロキシは、最小公分母となる API（すなわちネットワーク）を採用することで、異種プラットフォーム（異なる言語やアプリケーション開発フレームワーク）を一貫して制御することを可能にする。
SM-AR4: サービス・メッシュの機能をプロキシで実装し、各マイクロサービス・インスタンスごと（SM-AR3 のように）ではなく、ノード（物理ホスト）ごとに 1 つのプロキシをデプロイする。

1.2 範囲（Scope）

本書では、サービス・メッシュ・アーキテクチャとして SM-AR3 のみを対象とする。ここでは、専用のインフラ層が、アプリケーション・サービスのコードに一切の変更を加えることなく、マイクロサービス型アプリケーションに対するすべてのセキュリティ機能を提供する。SM-AR4 と比較すると、SM-AR3 は、各マイクロサービス・インスタンスごとに 1 つのサービス・プロキシをデプロイし、基盤プラットフォームの分離保証に依拠してアプリケーションのトラフィックが専用プロキシのみによって仲介されることを確実にすることで、特権昇格やノイジー・ネイバーの問題の幅広い範囲を回避する。SM-AR1 および SM-AR2 と比較すると、SM-AR3 は、サービス・メッシュ機能を提供するモジュールとアプリケーション・ライフサイクルを分離し、SM-AR2 で起こり得る、言語横断で複数のライブラリ・バージョンを維持管理する組合せ爆発を回避する。この文脈に基づき、本書の観点から見たサービス・メッシュの主要な機能は、クライアント対マイクロサービス、およびマイクロサービス相互間の通信を仲介・仲裁することであり、その仲介・仲裁の主体または機能モジュールはマイクロサービスのコードと強く結合していない。

1.3 対象読者（Target Audience）

サービス・メッシュ・フレームワークを用いてマイクロサービス型アプリケーションを支援するための本ガイダンスの対象読者は、マイクロサービス型アプリケーションのためのセキュリティ・フレームワークを設計しようとするセキュリティ・ソリューション・アーキテクト、ならびに企業やクラウドに存在する異なるマイクロサービス型アプリケーションのために共通インフラ・サービス・フレームワークを構築するシステム・インテグレータである。

1.4 他の NIST ガイダンス文書との関係

本ガイダンス文書は、マイクロサービス型アプリケーションのための特定のセキュリティ・フレームワークまたはインフラの構築に焦点を当てる。マイクロサービス型アプリケーションの特性、ならびにその全般的なセキュリティ要件と戦略を理解することは有益であり、その情報は NIST 特別刊行物（SP）800-204『Security Strategies for Microservices-based Application Systems』[1] に記載されている。

1.5 本書の構成（Organization of this Document）

本書の構成は次のとおりである。

第 2 章では、[1] で論じたマイクロサービス型アプリケーションのセキュリティ要件を再掲する。
第 3 章では、サービス・メッシュを紹介し、そのコンポーネント、機能、マイクロサービス型アプリケーションにおける通信ミドルウェアとしての独自の役割を簡潔に説明する。
第 4 章では、サービス・メッシュ・コンポーネントの詳細なデプロイ推奨事項を提供し、サービス・プロキシ、イングレス・プロキシ、エグレス・プロキシ、アイデンティティおよびアクセス管理、監視機能、ネットワーク・レジリエンス技法、オリジン間リソース共有などの構成領域にまたがる。
第 5 章では、要約と結論を示す。

2 マイクロサービス型アプリケーション — 背景とセキュリティ要件

マイクロサービス型アプリケーションの定義と記述、脅威、およびそれらの脅威に対抗するセキュリティ戦略は、NIST SP 800-204『Security Strategies for Microservices-based Application Systems』[1] に記載されている。本章の目的は、この種のアプリケーションに対するセキュリティ要件を再掲・詳述し、第 3 章で説明するサービス・メッシュの機能がそれらの要件をどのように満たすかの文脈を与えることである。これは、第 4 章で、これらの要件を満たすためのサービス・メッシュ・コンポーネントのデプロイ推奨事項を策定するうえで役立つ。

2.1 認証と認可の要件

マイクロサービスが公開する API の種類（一般公開 API、プライベート API、ビジネス・パートナーのみが利用可能なパートナー API）に応じて、認証とアクセス・ポリシーは異なり得る。多数のマイクロサービスが存在するため、それらすべてをカバーするよう認証ポリシーを定義すべきである。さらに、証明書ベースの認証には、証明書の発行／管理および鍵管理のための公開鍵基盤（PKI）が必要である。加えて、すべてのマイクロサービスにわたるリソースを対象とするきめ細かな認可を、すべてのサービス・リクエストで提供するための認可モジュールを構築しなければならない。

2.2 サービス・ディスカバリ

レガシーな分散システムでは、複数のサービスが所定の場所（IP アドレスとポート番号）で動作するよう構成されている。マイクロサービス型アプリケーションでは、次の状況が存在し、堅牢なサービス・ディスカバリ機構が求められる。

a) 多数のサービスが存在し、各サービスには多数のインスタンスが紐づき、それらの位置は動的に変化する。
b) 各マイクロサービスは VM（仮想マシン）またはコンテナとして実装される場合があり、とりわけ IaaS や PaaS のクラウド・サービス上にホストされる場合には動的 IP アドレスが割り当てられ得る。
c) 自動スケーリング等の機能により、サービスに紐づくインスタンス数は負荷の変動に応じて変化し得る。

上記の特性に基づき、サービス・リクエスト時にサービスを見つける機能は必須要件である。この機能の一般的な実装アプローチがサービス・レジストリの利用である。サービス・レジストリは、マイクロサービス型アプリケーションのために新規に作成されたサービス・インスタンスが自身を登録し、オフラインとなったサービス・インスタンスがそこから削除されるディレクトリで構成される。

2.3 ネットワーク・レジリエンス技法による可用性の向上

負荷分散: 同一サービスの複数インスタンスが必要であり、これらのインスタンスへの負荷は均等に分配して、過負荷による応答遅延やサービスのクラッシュを回避しなければならない。
サーキット・ブレーカ: 大規模分散システムは、どのようにアーキテクチャ化されていても、1 つの決定的特徴を有する—小さな局所的障害が、システム全体の壊滅的障害へと拡大する機会が多数存在する。サービス・メッシュは、基盤システムがその限界に近づいた際に負荷を遮断し迅速に失敗させることで、こうした拡大を防ぐよう設計されるべきである。サーキット・ブレークとは、あるマイクロサービス・インスタンスからの失敗応答に閾値を設定し、失敗が閾値を上回ったとき（すなわちサーキットがトリップしたとき）に、そのインスタンスへのフォワーディングを遮断することである。これは、カスケード障害の可能性を低減し、ログの分析、必要な修正の実施、および失敗インスタンスの更新をプッシュするための時間を与える。したがって、サーキット・ブレークは、サービス要求への応答が全面停止することを防ぐ一時的措置である。サービスが再び応答可能になれば、当該インスタンスへのリクエスト転送は復旧する。
レート制限（スロットリング）: マイクロサービスに到来するリクエストのレートは、すべてのクライアントに対する継続的なサービス提供を確保するため、制限されなければならない。
ブルー／グリーン・デプロイメント: 新しいバージョンのマイクロサービスがデプロイされる際、旧バージョンを利用する顧客からのリクエストは、新旧双方の場所を把握するようプログラムされた API ゲートウェイを用いて、新バージョンへリダイレクトできる。
カナリア・リリース: 新しいバージョンのマイクロサービスには、当初、限られたトラフィックのみを送る。これは、あらゆる運用シナリオ下での応答の正しさや性能指標が十分に分かっていないためである。運用特性に関する十分なデータが収集されたら、すべてのリクエストを新バージョンへプロキシできる。

2.4 アプリケーション監視の要件

攻撃を検出し、サービス劣化の要因（可用性に影響を及ぼし得る）を特定するため、分散ログ、メトリクス生成、分析、トレースを通じて、マイクロサービスの入出力ネットワーク・トラフィックを監視する必要がある。

3 サービス・メッシュ ― 定義と技術的背景

前章のマイクロサービスの説明から、マイクロサービスには大きく 2 つの機能があることは明らかである [2]。

ビジネス・ロジック：業務機能、計算、サービス合成／統合ロジックを実装する。
ネットワーク機能：サービス間通信の仕組み（例：所定プロトコルによる基本的なサービス呼び出し、レジリエンス／安定性パターンの適用、サービス・ディスカバリ等）を担う。これらのネットワーク機能は、基盤 OS レベルのネットワーク・スタックの上に構築される。

ビジネス・ロジック機能は、そのサービスが業務プロセスを実行または支援する当事者であるため、マイクロサービスのコードの不可欠な一部でなければならない。マイクロサービスがネットワーク機能を直接実行することの難しさは、そのマイクロサービスが記述言語やホストする開発フレームワークに応じて異なるライブラリを使用する点にある。開発や実行の最適化のため、同一アプリケーション内で複数言語（例：Java、JavaScript、Python など）でマイクロサービスが記述されるのが実情であり、各サービス・ノードに通信機能を提供する作業は骨が折れる。

サービス・メッシュは、サービス・ディスカバリ、ルーティングと内部ロードバランシング、トラフィック構成、暗号化、認証、認可、メトリクス、監視を通じてサービス間通信を容易にする、配備済みインフラ機能の集合からなる専用のインフラ層である。これは、サービス・インスタンスの停止／起動や再配置によりネットワーク・トポロジが変化する環境において、ポリシーによりネットワーク挙動、マイクロサービス・インスタンスのアイデンティティ、トラフィック・フローを宣言的に定義する能力を提供する。これは、オープン・システム間相互接続（OSI）モデルのトランスポート層（例：TCP/IP）より抽象度の高い層に位置するネットワーキング・モデルと見なせ、サービスのセッション層（OSI 第 5 層）の懸念に対処する。ただし、きめ細かな認可は、業務ロジックを完全に把握している唯一の主体がマイクロサービスであるため、依然としてマイクロサービス側で行う必要がある場合がある。

別の定義として、サービス・メッシュは「アプリケーション・サービス間の通信を最適化する分散コンピューティング・ミドルウェア」であるとも言える [3]。サービス間通信は、プロキシを用いるのが最も効果的である（1.1 節参照）。サービス・メッシュは通常、アプリケーションが意識することなくアプリケーション・コードの横に配備される軽量ネットワーク・プロキシ群として実装される [4]。

加えて、サービス・メッシュは通信の監視と保護にも活用できる。クラスタ・トラフィックのすべてをインターセプトしてルーティングし、ヘルス・メトリクスを収集するため、サービス・メッシュは学習し、インテリジェントにトラフィックをルーティングできる。こうした高機能の例として、A/B テスト、カナリア・デプロイ、ベータ・チャネル、自動リトライ、サーキット・ブレーカー、フォールト注入がある。サービス・メッシュがクラスタ全体のトラフィックを観測・学習できるからこそ、これらの機能が可能になる。

アプリケーション内のマイクロサービス数が数百〜数千規模の場合、サービス・メッシュの配備は経済的と見なされる。一方で、サービス・メッシュにも欠点がある。各マイクロサービスに専用のサービス・プロキシが必要となるため、実行時インスタンスの数とアプリケーション全体の攻撃面が増加する。サービス・プロキシに盛り込む機能が増えるほど、通信のボトルネックとなるおそれもある。

3.1 サービス・メッシュの構成要素と機能

サービス・メッシュは、主に 2 つのアーキテクチャ層（コンポーネント）から成る。

データ・プレーン
コントロール・プレーン

サービス間通信を制御するサービス・メッシュ内の相互接続されたプロキシ集合がデータ・プレーンを構成する。データ・プレーンはデータの経路であり、アプリケーションからの要求を転送する機能を提供する。データ・プレーンは、ヘルス・チェック、ロードバランシング、サーキット・ブレーク、タイムアウト、リトライ、認証、認可など、より高度な機能を提供する場合もある [5]。各サービス・インスタンスごとに作成される専用プロキシ（サイドカー・プロキシ）は、コントロール・プレーンからプロキシへポリシー（例：アクセス制御ポリシー）を注入することで有効化される、セキュリティ（例：アクセス制御、通信関連）を執行するための実行時処理を行う。これにより、マイクロサービスのコードを変更せずにポリシーを動的に変更する柔軟性も得られる。

コントロール・プレーンは、メッシュ全体にわたってデータ・プレーン（プロキシ）の挙動を制御・構成するための API とツールの集合である。サービス・メッシュのコントロール・プレーンは、オーケストレータのコントロール・プレーンとは別物であり、前者はサービス・メッシュを、後者はクラスタを制御する。コントロール・プレーンは、ユーザが認証ポリシーや命名情報を指定し、メトリクス（一般にテレメトリ収集）を集約し、データ・プレーン全体を構成する場所である [6]。すべてのセキュリティ機能を実装するために必要なインテリジェンス、データ、およびその他の成果物はコントロール・プレーンに存在する。これには、認証証明書の生成ソフトウェアとその保管リポジトリ、認証用ポリシー、認可エンジン、各マイクロサービスに関するテレメトリ／監視データの受信・集約ソフトウェア、ロードバランシングやサーキット・ブレーク、レート制限などの機能を通じてネットワークの挙動を変更するための API が含まれる。サービス・メッシュ・プラットフォームのコントロール・プレーンは、マイクロサービス型アプリケーションのオーケストレーション・プラットフォーム（サービス・レジストリなどの重要データを取得する）と統合される必要があり、有用であるために必要な統合能力を備えるべきである。コントロール・プレーンはサービス・メッシュの中核コンポーネントであるため、高可用かつ分散化されていなければならない。コントロール・プレーンは、設定ファイル、API 呼び出し、ユーザインタフェースを通じて実装できる [7]。

通信機能の提供過程の一部として、次の機能がサポートされる [1,2]。

認証と認可：証明書生成、鍵管理、ホワイトリスト／ブラックリスト、シングルサインオン（SSO）トークン、API キー
セキュアなサービス・ディスカバリ：専用のサービス・レジストリを通じたサービス・エンドポイントの発見
セキュア通信：相互 TLS、暗号化、動的ルート生成、複数プロトコルのサポート（必要に応じたプロトコル変換を含む。例：HTTP/1.x、HTTP/2、gRPC 等）
通信のレジリエンス／安定性機能：サーキット・ブレーク、リトライ、タイムアウト、フォールト注入／処理、ロードバランシング、フェイルオーバ、レート制限、リクエスト・シャドーイング
可観測性／監視機能：ログ、メトリクス、分散トレーシング

3.1.1 イングレス・コントローラ

サービス・メッシュのサービス・プロキシは、イングレス・トラフィック（マイクロサービス間通信ではなく、外部からマイクロサービス・アプリケーションへ流入するトラフィック）の制御のために配備できる。この意味で、API ゲートウェイの機能を実現する。概念的には、イングレス・コントローラは外部クライアント向けのサイドカー・プロキシと見なせる。イングレス・コントローラ（フロント・プロキシと呼ばれることもある）は、次の機能を提供する。

すべてのクライアントに対する共通 API（サービス・メッシュ内部の実 API を隠蔽）
Web フレンドリなプロトコル（HTTP/HTTPS）から、マイクロサービスが用いるプロトコル（RPC/gRPC/REST）への変換
クライアントからの単一呼び出しに応じ、メッシュ内部の複数サービスへの呼び出しで得た結果の合成
ロードバランシング
公開 TLS 終端

3.1.2 エグレス・コントローラ

サービス・メッシュのサービス・プロキシは、エグレス・トラフィック（メッシュ内のマイクロサービスからメッシュ外のマイクロサービスへ向かう内部トラフィック）の制御のためにも配備できる。この意味で、エグレス専用ゲートウェイとして機能する。概念的には、エグレス・コントローラは 1 台以上の外部サーバ向けのサイドカー・プロキシと見なせる。エグレス・プロキシは次の機能を提供する。

外部ネットワークとの通信のためにホワイトリストすべき単一のワークロード集合（例：ファイアウォールを、ローカル・ネットワークからの外向きトラフィックはエグレス・プロキシからのみ許可するよう構成できる）
資格情報の交換：アプリケーションが外部システムの資格情報に直接アクセスすることなく、内部（メッシュ）アイデンティティ資格情報から外部資格情報（例：SSO トークンや API キー）への変換
マイクロサービス向きプロトコル（例：RPC/gRPC/REST）から Web フレンドリなプロトコル（例：HTTP/HTTPS）への変換

3.2 通信ミドルウェアとしてのサービス・メッシュ：何が異なるか

サービス・メッシュ以前は、分散システム（マイクロサービス型アプリケーション等）にインフラ機能（サービス・ディスカバリ、ロードバランシング、サーキット・ブレーク、フォールト注入、セキュリティ監視、認可、分散トレーシング等）を提供するため、それらの機能を提供するコンポーネントやフレームワークの組み合わせを慎重に選定する必要があった。コンポーネントの中には特定フレームワーク内でしか機能しないものがあり、フレームワーク自体も特定言語に結び付いている。また、アプリケーション・サービスのコードは、これらコンポーネントと連携または統合できるよう修正が必要だった [8]。

サービス・メッシュの場合、個々のマイクロサービスが記述された技術や言語は問題にならない。動作はネットワーク層で行われるためである。例えば、マイクロサービス・アプリケーションの開発者が HTTP サーバを開発する場合、Java、C++、Rust、Go、JavaScript、Python など、任意の言語を自由に選択できる。サービス・メッシュは、アプリケーション・コードをサービス間通信の管理から切り離す。アプリケーション・コードは、ネットワーク・トポロジ、サービス・ディスカバリ、ロードバランシング、コネクション管理ロジックを知る必要がない [9]。テレメトリ、トラフィック・シェーピング、サービス・ディスカバリ、ネットワーク・ポリシー制御といった機能も、すぐに利用できる。

サービス・メッシュは通信ミドルウェアと定義されるが、では「他の分散システム向けミドルウェア」と何が違うのか。従来のミドルウェアには、アプリケーション・デリバリ・コントローラ（ADC）、ロードバランサ、API ゲートウェイが含まれる。これらのアプライアンスは高コストかつ運用負荷が大きいだけでなく、疎結合なモジュール式マイクロサービスという形態のアプリケーション・コンポーネントを扱う文脈では不向きである。こうしたコンポーネントは、モノリシック・アプリケーションのモジュールには不要な、動的ディスカバリのようなきめ細かな機能と能力を必要とするからである。

分散システム向けの従来型通信ミドルウェアが不適で、マイクロサービス型アプリケーション・システムに軽量な解決策が必要となる理由を理解するために、そのようなシステムにおける通信の性質を考える。多様な種類のクライアントが、膨大な数のマイクロサービスで構成されたアプリケーションに接続する。クライアントと任意のアプリケーション・サービス間の通信は「南北（north-south）」トラフィックと呼ばれ、マイクロサービス間の通信は「東西（east-west）」トラフィックと呼ばれる。モノリシック・アプリケーションに比べ、マイクロサービス型アプリケーションではコンポーネントとなるマイクロサービスの数が相対的に多いため、東西トラフィックの量が非常に多くなる。したがって、本番アプリケーションに受容可能な性能を提供するには、サービス・メッシュのような軽量通信ミドルウェアが必要である。

マイクロサービス型アプリケーションは、コンテナや付随するオーケストレーション・サービスを使わずに実装することも可能だが、一般に、サービス指向のアーキテクチャ、API 駆動の通信、コンテナ基盤インフラ、開発と運用（DevOps）プロセス（継続的改善、アジャイル開発、継続的デリバリ、開発者・品質保証・セキュリティ・IT 運用・事業部門ステークホルダの協働など [3]）を備えたクラウド・ネイティブ・アプリケーションと見なされる。この見方の一因は、モノリシックなソフトウェア開発・デプロイが、疎結合のサービス指向アーキテクチャや API ベースの通信ではなく、密に統合されたアプリケーション・モジュールを持つサーバ中心のインフラに依存していることにある。

3.3 サービス・メッシュ：最先端動向

概念的には、サービス・メッシュは、数百のサービスと各サービスに数十のインスタンスが存在するようなマイクロサービス・アーキテクチャに基づくすべてのアプリケーションに対して、インフラ・サービスを提供するために用いられ得る。しかし、現在入手可能な市販実装（Off-the-Shelf）に基づけば、サービス・メッシュが最も適して生産的なのは、次の構成を持つアプリケーション・プラットフォームである。

各マイクロサービスがコンテナとして実装されている。
アプリケーションは、（可用性と性能向上のための）コンテナ・クラスターを使用し、コンテナ・オーケストレーション・ツールで管理されている。
アプリケーションは、クラウド・プロバイダが提供する CaaS（Container-as-a-Service）でホストされ、コンテナ管理／オーケストレーション環境に見られる必要なデプロイおよび構成ツールを備えている。

4 サービス・メッシュのデプロイ推奨事項

本章では、サービス・メッシュにおけるデプロイの選択肢を検討し、各種アプリケーション・シナリオに対する安全なマイクロサービス型アプリケーション向け推奨事項を示す。実行時の主機能はプロキシによって実施されるため、まずプロキシ機能の各側面の構成に関する推奨事項を示す。各推奨事項は記号 SM-DRx で識別する。SM は Service Mesh、DR は deployment recommendation、x は通し番号である。

4.1 サービス・プロキシの通信構成

許可トラフィックに関する推奨（SM-DR1）：サービス・プロキシが、関連付けられたサービス向けに受け付けるトラフィックのプロトコルおよびポートの集合を指定できる機能を備えるべきである。デフォルトでは、当該構成で指定されたもの以外のトラフィックをサービス・プロキシが許可してはならない。

到達可能性に関する推奨（SM-DR2）：サービス・プロキシが到達できるサービスの集合は制限されなければならない。名前空間、所与の名前空間内の特定の名前付きサービス、またはサービスの実行時アイデンティティに基づいてアクセスを制限する機能を備えるべきである。ディスカバリ、各種ポリシー、テレメトリ・データを中継するため、サービス・メッシュのコントロール・プレーンへのアクセスは常に提供されなければならない。

プロトコル変換能力に関する推奨（SM-DR3）：サービス・プロキシは、ターゲット・マイクロサービスと異なるプロトコルで通信するクライアントをサポートできる組み込み能力（例：REST/HTTP を gRPC に変換、HTTP/1.1 を HTTP/2 にアップグレード）を有すべきである。これは、クライアント・プロトコルごとに別サーバを構築する必要を避け、攻撃面の増加を防ぐために必要である。

ユーザ拡張性に関する推奨（SM-DR4）：サービス・プロキシは、ネットワーク機能を処理する組み込みロジックに加え、カスタム・ロジックを定義できる機能を備えるべきである。これは、ユースケース固有のポリシー（例：既存／自家製のポリシー・エンジン）を実装するために、サービス・プロキシを拡張可能にするため必要である。実装は、サンドボックス化、使用言語の API／ランタイムの制限、安全性を確保する事前解析（例：WASM や eBPF）など、拡張性のリスクを制御する手段を提供すべきである。

プロキシの動的構成に関する推奨（SM-DR5）：静的構成に加え、動的にプロキシを構成するオプション（例：イベント駆動の構成更新）を備えるべきである。言い換えれば、配備時点では既知でなく動的と想定されるエンティティに対しては、ディスカバリ・サービスが存在すべきである。さらに、プロキシは、以前の構成下で未処理の要求を効率的に処理（完了または終了）しつつ、実行時に新しい動的構成へアトミックに切り替えるべきである。これは、ユーザ・トラフィックの劣化や停止（すなわちサービス・プロキシの再起動なし）を伴うことなく、実行時にタイムリーにポリシー変更を適用するために必要である。

アプリケーション・サービスとそのプロキシ間の通信構成に関する推奨（SM-DR6）：アプリケーション・サービスとその関連プロキシは、ループバック・チャネル（例：localhost の IP アドレス、UNIX ドメイン・ソケット等）経由でのみ通信すべきである。さらに、サービス・プロキシ同士は、相互 TLS（mTLS）セッションを確立し、交換されるすべてのデータ・パケットを暗号化したうえでのみ通信すべきである。

4.2 イングレス・プロキシの構成

イングレス・プロキシに関する推奨（SM-DR7）：スタンドアロンのイングレス・プロキシについても、サービス・プロキシと同様に、トラフィックのルーティング・ルールを構成できる機能を備えるべきである。これは、配備のエッジまで一貫したルーティング・ポリシーの適用が必要なためである。

4.3 外部サービスへのアクセス構成

マイクロサービス型アプリケーションの一部のサービスは、公開または非公開の Web API、サードパーティ・サービス、レガシー・アプリケーション、あるいは VM や異なるクラスタ（サービス・メッシュが稼働するクラスタとは別）といった仮想化基盤上のアプリケーションへアクセスしなければならない場合がある。これらリソースへのアクセスについても同等のセキュリティ保証を提供するため、以下の推奨を示す。

外部リソースへのアクセス制限に関する推奨（SM-DR8）：メッシュ外の外部リソースまたはサービスへのアクセスはデフォルトで無効とし、明示的に指定した宛先へのアクセスのみを許可するポリシーによってのみ許可すべきである。加えて、当該外部リソース／サービスはサービス・メッシュ自身の中でサービスとしてモデリングされるべきである（例：サービス・メッシュのサービス・ディスカバリ機構に含める）。

外部リソースへの安全なアクセスに関する推奨（SM-DR9）：サービス・メッシュ内部のサービス向けに構成された可用性向上機能（例：リトライ、タイムアウト、サーキット・ブレーク等）を、外部リソースおよびサービスへのアクセスにも同様に提供しなければならない。

エグレス・プロキシに関する推奨（SM-DR10）：スタンドアロンのエグレス・プロキシについても、サービスおよびイングレス・プロキシと同様に、トラフィックのルーティング・ルールを構成できる機能を備えるべきである。配備時には、外部リソースおよびサービスへのアクセスはこれらのエグレス・プロキシにより仲介されるべきである。エグレス・プロキシは、アクセスおよび可用性ポリシー（SM-DR8）を実装すべきである。これは、従来のネットワーク指向のセキュリティ・モデルと連携するのに有用である。例えば、インターネットへの送信トラフィックがネットワーク内の特定 IP からのみ許可されている場合、メッシュ内の複数サービスのトラフィックをプロキシしつつ、そのアドレスで動作するようエグレス・プロキシを構成できる。

4.4 アイデンティティおよびアクセス管理の構成

マイクロサービス型アプリケーションの 3 つの主要な通信主体は、クライアント、マイクロサービス、外部サービスである。任意の組（クライアント対マイクロサービス、マイクロサービス相互、マイクロサービス対エグレス・サービス）の通信イベントでは、双方が固有のアイデンティティを持ち、相互認証を行う必要がある。相互 TLS（mTLS）がその事実上の仕組みであるため、クライアントまたはマイクロサービスが保持する認証証明書には、その「サブジェクト名」または「サブジェクト代替名」フィールドにアイデンティティが含まれているべきである。このアイデンティティは、サーバ・アイデンティティ（ホスト名／ドメインとも）またはサービス・アイデンティティ（通常はサービス・アカウント ID）であり得る。証明書配備に関する推奨は次のとおり。

ユニバーサル・アイデンティティ・ドメインに関する推奨（SM-DR11）：マイクロサービスのすべてのインスタンスのアイデンティティは、一貫していてかつ一意でなければならない—一貫しているとは、サービスがどこで稼働していようと同じ名称を持つこと、一意とは、システム全体にわたりその名称が当該サービスのみに対応することを意味する。これは、場所の異なる別個の論理サービスを意味するものではない。典型的な DNS の用法（各サービスに独自の DNS 名を割り当てる）で本推奨を満たせる。サービスの名称（アイデンティティ）を一貫させることは、システム・ポリシーを管理可能にするために必要である。

署名用証明書の配備に関する推奨（SM-DR12）：サービス・メッシュのコントロール・プレーンの証明書管理システムは、自己署名証明書を生成できる能力を無効化すべきである。この機能は、しばしばサービス・メッシュ内の他のすべてのアイデンティティ証明書の初期署名証明書をブートストラップするために用いられる。代わりに、メッシュのコントロール・プレーンが用いる署名証明書は、常に企業既存の PKI の信頼の基点（root of trust）に連なるものであり、起動時に安全にコントロール・プレーンへ提供されるべきである。これにより、既存の PKI による証明書管理（例：失効や監査）が容易になる。さらに、異なるドメインごとに個別の中間署名証明書を生成し、ローテーションの単純化ときめ細かな失効を可能にすることを推奨する。

アイデンティティ証明書のローテーションに関する推奨（SM-DR13）：マイクロサービスのアイデンティティ証明書の有効期間は、インフラ内で管理可能な限り短くすべきであり、望ましくは数時間程度とする。これは、攻撃者が資格情報を用いてサービスをなりすませる期間を、有効期限までに限定する助けとなり、資格情報の再盗取を成功させ続ける必要性を高め、攻撃者の困難度を増す。

アイデンティティ変更時の接続入れ替えに関する推奨（SM-DR14）：サービス・プロキシのアイデンティティ証明書がローテーションされた場合、当該プロキシは既存接続を効率的に退役させ、新証明書で新たな全接続を確立すべきである。証明書の検証は mTLS のハンドシェイク時にのみ行われるため、新証明書の発行時に既存接続を置き換えることは厳密には必須ではないが、時間的に攻撃を制限するうえで重要である。

署名不可のアイデンティティ証明書に関する推奨（SM-DR15）：マイクロサービスの識別に用いる証明書は、署名用証明書であってはならない。

証明書発行前のワークロード認証に関する推奨（SM-DR16）：サービス・メッシュのコントロール・プレーンの証明書管理システムは、アイデンティティ証明書を発行する前にサービス・インスタンスの認証を実施すべきである。多くのシステムでは、オーケストレーション・エンジンに対するインスタンスのアテステーションや、その他のローカルな証憑（例：HSM から取得したシークレット）により実現できる。

同様の配慮は、サービス・メッシュのコントロール・プレーンの証明書管理システムに署名用証明書をプロビジョニングする際にも必要である。署名用証明書は、サービス・メッシュのコントロール・プレーンにより、何らかのアテステーションを経た後にのみ取得可能であるべきである。

セキュア・ネーミング・サービスに関する推奨（SM-DR17）：mTLS に用いる証明書がサーバ・アイデンティティを保持する場合、サービス・メッシュは、セキュア・ディスカバリ・サービスまたは DNS により提供されるマイクロサービス名へ、サーバ・アイデンティティをマップするセキュア・ネーミング・サービスを提供すべきである。これは、当該サーバがマイクロサービスの正当な所在であることを保証し、ネットワーク乗っ取りから保護するために必要である。

mTLS に用いる証明書がサービス・アイデンティティを保持する場合、追加のセキュア・ネーミング・サービスは不要である。この方式では、マイクロサービスを別のネットワーク・ドメイン（別クラスタや別クラウド・ロケーション）に移設した際も、アイデンティティと関連するアクセス制御ポリシーを新しい場所向けに再定義する必要がない。

サービス・アイデンティティに基づいてマイクロサービスの証明書を設定すると、通信する 2 つのサービスがセキュアな通信チャネルを確立できるようになるが、それらがそもそも通信を許可されているかどうかは規定しない。これを規定するには、各マイクロサービス・ノードに対し、許可される受信／送信トラフィックを定義するポリシーを設定する機能が必要である。

粒度の細かいアイデンティティに関する推奨（SM-DR18）：各マイクロサービスは独自のアイデンティティを持ち、当該サービスのすべてのインスタンスは実行時に同一のアイデンティティを提示すべきである。これにより、所与の名前空間内でマイクロサービス単位のアクセス・ポリシーを可能にする。一般的なマイクロサービス・ランタイムは、デフォルトでサービス単位ではなく名前空間単位でアイデンティティを発行し、同一名前空間のすべてのサービスが明示しない限り同一の実行時アイデンティティを提示するため、この推奨が必要である。加えて、ラベルを用いてサービス名（アイデンティティ）を拡張し、きめ細かなログ構成や認可ポリシーの細分化を支援できる。

認証ポリシーのスコープに関する推奨（SM-DR19）：認証ポリシーのスコープを指定する機能は、少なくとも次の選択肢を備えるべきである。（a）すべての名前空間のすべてのマイクロサービス、（b）特定の名前空間のすべてのマイクロサービス、（c）所与の名前空間における特定のマイクロサービス（SM-DR17 で言及した実行時アイデンティティを使用）。

上記のアプローチは、静的パラメータ（サービス・アイデンティティと事前定義ポリシー）による認証を可能にする。さらに、シナリオによっては、コンテキスト情報（例：マイクロサービスを呼び出すユーザ）を取り込む能力が必要となる場合がある。その仕組みの一つが、プラットフォーム中立形式でエンコードされたトークン（例：JSON Web Token（JWT））の利用である。トークンの要件は以下のとおり。

認証トークンに関する推奨（SM-DR20）：トークンは電子署名され、暗号化されているべきである。トークンに含まれるクレームは、認証済みアイデンティティを補強したり、その一部となってアクセス制御判断を構築するために用いられ得るため、その真正性の保証が必要である。さらに、これらのトークンは、ループバック・デバイス（ネットワーク経路が関与しないことを保証）経由、または暗号化されたチャネルでのみ中継されなければならない。

4.5 監視機能の構成

すべてのプロキシ（イングレス、エグレス、サービス）は、監視データを収集する機能を備えるべきである。ソフトウェア・システムにおける監視データは、Peter Bourgon が示したとおり、ログ、メトリクス、トレースの 3 区分に分類される [10]。この能力は、上記のデータ区分の 1 つ以上を生成できる専門ツールとの統合をサービス・メッシュで有効化することで実現される。例として、イベント・ログ用の AppSensor と Fluentd、集約可能なメトリクス用の Prometheus、分散トレーシング用の Jaeger [11] と Zipkin [12] が挙げられる。これにより、サービス・メッシュのデプロイ・チームはデータ収集パイプラインの構築作業を最小化し、データ分析に注力できる。ユースケースの文脈に応じて、イベント・マイニング、異常検知、サービス依存関係抽出などが例として挙げられる。

攻撃の一部を検出するため、少なくとも次のイベントはログとして記録されるべきである。

ログ・イベントに関する推奨（SM-DR21）：プロキシは、入力バリデーションエラーおよび余分（想定外）パラメータのエラー、クラッシュ、コアダンプを記録すべきである。一般的な攻撃検出能力として、ベアラ・トークン再利用攻撃およびインジェクション攻撃を含むべきである。

要求のログ記録に関する推奨（SM-DR22）：プロキシは、少なくとも不正な要求（例：HTTP 利用時の非 200 応答）について Common Log Format のフィールドを記録すべきである。メトリクスが利用できる場合、成功要求（例：200 応答）のログ記録は価値が低い傾向にある。

ログ・メッセージ内容に関する推奨（SM-DR22）：ログ・メッセージには、最低限、イベントの日付／時刻、マイクロサービス名またはアイデンティティ、リクエスト・トレース ID、メッセージ、その他のコンテキスト情報（例：要求元ユーザのアイデンティティと URL）を含めるべきである。ただし、ベアラ・トークンなどの機微情報はマスクすること。

メトリクスの側面では、業務ロジック判断の結果、接触試行、その他の挙動に関する通常・無侵害状態のベースラインを作成すべきである。これを可能にするために：

必須メトリクスに関する推奨（SM-DR23）：サービス・メッシュを用いて外部クライアントおよびマイクロサービスの呼び出しに関するメトリクスを収集する構成には、最低限、次を含めるべきである。（a）所定期間のクライアント／サービス要求数、（b）失敗コード別のクライアント／サービス要求の失敗数、（c）サービスごとの平均レイテンシおよび要求ライフサイクル全体の平均総レイテンシ（理想的にはヒストグラム形式。失敗コード別も）。

トレースとは、分散システムを横断するエンドツーエンドの要求フローを符号化する、一連の因果関係を持つ分散イベントの表現である [13]。トレースは、要求が通過した経路（関与した各種マイクロサービス）と、要求の構造（分岐ロジック、同期／非同期の別）の双方に可視性を提供できる。マイクロサービス型アプリケーションとサービス・メッシュの文脈では、分散トレーシングと呼ばれる。これは、各種アプリケーション・サービスとそれらに紐づくサービス・プロキシの組み合わせによってトレーシング機能が有効化されるためである。定常状態の問題のデバッグおよびキャパシティ・プランニングのためのデータ提供に用いられることから、分散トレーシング機能はアプリケーション・システムの可用性に直接影響する。

分散トレーシング実装に関する推奨（SM-DR24）：分散トレーシングを実装するためにサービス・プロキシを構成する際、アプリケーション・サービスが、受信した通信パケットのヘッダを転送するよう計装されていることを確実にすべきである。

上記の推奨を実施するには、サービス・メッシュ・アーキテクチャの他のインフラ機能とは異なり、アプリケーション・サービスに対する最小限の計装が必要であることに留意する [14]。

4.6 ネットワーク・レジリエンス技法の構成

ネットワーク・レジリエンス実装データの保管に関する推奨（SM-DR25）：リトライ、タイムアウト、サーキット・ブレーク設定、カナリア・デプロイ（一般に、すべてのコントロール・プレーン構成データ）に関するデータは、Key/Value ストアのような堅牢なデータストアに保管すべきである。

サービス・インスタンスのヘルス・チェック実装に関する推奨（SM-DR26）：サービス・インスタンスのヘルス・チェック機能は、ロードバランシングに用いる情報の整合性を維持するため、サービス・ディスカバリ機能と密接に統合されるべきである。

このヘルス・データは、中央のヘルス・チェック・サービス（または中央のサービス・ディスカバリ・システム）に報告できるが、ローカルのみに用いることもある（例：サービス・プロキシが維持するオープン接続のヘルス・チェックを実施し、ローカルでロードバランシング判断を行い、不健全と見なすホストを回避する）。

4.7 オリジン間リソース共有（CORS）の構成

CORS に関する推奨（SM-DR27）：エッジ・サービス（マイクロサービスのエントリ・ポイント）は、Web UI クライアント・サービスなど外部サービスとの通信に際し、CORS の構成が必要となる場合が多い [15]。エッジ・サービスに対する CORS ポリシーは、マイクロサービスのアプリケーション・サービス・コードではなく、サービス・メッシュの機能（例：Istio における VirtualService リソースの CorsPolicy 構成）を用いて構成すべきである。

4.8 管理操作の権限構成

管理操作のアクセス制御に関する推奨（SM-DR28）：サービス・メッシュにおけるすべての管理操作（例：ポリシー仕様、サービス・レジリエンス・パラメータの構成、カナリア・デプロイ、リトライ等）に対して、きめ細かなアクセス制御権限が存在すべきであり、名前空間内の全サービス単位、当該名前空間内の特定の名前付きサービス単位などのレベルで指定可能であるべきである。一般に、この機能を行使するためのインタフェースは、サービス・メッシュそのものではなく、アプリケーション・サービス・クラスタの構成に用いるインストール・ソフトウェアまたはオーケストレーション・ソフトウェアの一部である場合がある。

5 まとめと結論

クラウドおよび大規模エンタープライズ環境におけるマイクロサービス型アプリケーションの採用拡大により、包括的で一貫性があり協調のとれた支援サービス群を提供するインフラの特定が促された。サービス・メッシュはそのようなインフラの 1 つであり、サービス・メッシュ・コンポーネントの配備における実践的手法は、アプリケーション・コードを一切変更することなく、すべての支援サービスを提供できるプロキシ重視のアプローチである。

プロキシ重視のサービス・メッシュは、セキュアなサービス・ディスカバリ、認証・認可ポリシーの定義と執行、ネットワーク・レジリエンス機能、性能およびセキュリティ監視機能を提供する支援サービス・コンポーネントを構築・統合するよう設計できる。本書の主たる貢献は、上記領域にわたる各サービス・メッシュ・コンポーネントに対し、詳細なデプロイ指針を提供することにある。

参考文献（References）

References	References
[1]	Chandramouli R (2019) Security Strategies for Microservices-based Application Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-204. https://doi.org/10.6028/NIST.SP.800-204
[2]	Indrasiri K (2017) Service Mesh for Microservices. Available at https://medium.com/microservices-in-practice/service-mesh-for-microservices-2953109a3c9a
[3]	Lerner A, Thomas A (2018) Innovation Insight for Service Mesh. Available at https://www.gartner.com/en/documents/3894156/innovation-insight-for-service-mesh
[4]	Morgan W (2017) What's a service mesh? And why do I need one? Available at https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one
[5]	Mishra A (2017) Smart Networking with Consul and Service Meshes. Available at https://www.hashicorp.com/blog/smart-networking-with-consul-and-service-meshes/
[6]	Schiesser M (2019) Comparing Service Meshes: Linkerd vs. Istio. Available at https://medium.com/glasnostic/comparing-service-meshes-linkerd-vs-istio-c7e0132578a8
[7]	Bryant D (2018) The Importance of Control Planes with Service Meshes and Front Proxies. Available at https://blog.getambassador.io/the-importance-of-control-planes-with-service-meshes-and-front-proxies-665f90c80b3d
[8]	Kirschner E (2017) Proxy Based Service Mesh. Available at https://medium.com/@entzik/proxy-based-service-mesh-96cd4b74c198
[9]	Tiwari A (2017) A sidecar for your service mesh. Available at https://www.abhishek-tiwari.com/a-sidecar-for-your-service-mesh/
[10]	Sridharan C (2018) The Three Pillars of Observability. Distributed Systems Observability (O'Reilly Media, Inc., Sebastopol, CA), Chapter 4. Available at https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431/ch04.html
[11]	Jaeger Project (2020) Jaeger: open source, end-to-end distributed tracing. Available at https://www.jaegertracing.io/
[12]	Zipkin Project (2020) Zipkin. Available at https://zipkin.io/
[13]	Leong A (2019) A guide to distributed tracing with Linkerd. Available at https://linkerd.io/2019/10/07/a-guide-to-distributed-tracing-with-linkerd/
[14]	Stafford GA (2019) Kubernetes-based Microservice Observability with Istio Service Mesh: Part 1 (ITNEXT). Available at https://itnext.io/kubernetes-based-microservice-observability-with-istio-service-mesh-part-1-bed3dd0fac0b
[15]	Stafford GA (2019) Istio Observability with Go, gRPC, and Protocol Buffers-based Microservices (ITNEXT). Available at https://itnext.io/istio-observability-with-go-grpc-and-protocol-buffers-based-microservices-d09e34c1255a