NIST Special Publication 800-204

概要（Abstract）

マイクロサービス・アーキテクチャは、コードベースが小さいため、コードの開発・テスト・デプロイの迅速化、マイクロサービスの種類に応じたプラットフォーム最適化、独立した開発チームの支援、各コンポーネントを個別にスケールできる能力といった利点から、アプリケーション・システムの開発にますます用いられている。マイクロサービスは一般に API（Application Programming Interfaces）を介して相互に通信するが、そのためには多数のコンポーネント間の複雑な相互作用を支えるためのいくつかの中核機能が必要となる。これらの中核機能には、認証とアクセス管理、サービス・ディスカバリ、セキュアな通信プロトコル、セキュリティ監視、可用性／レジリエンス向上技術（例：サーキットブレーカー）、負荷分散とスロットリング、新規サービス導入時の完全性保証技術、セッション永続性の取り扱いが含まれる。さらに、これらの中核機能は API ゲートウェイやサービスメッシュといったアーキテクチャ・フレームワークにバンドル／パッケージ化され得る。本書の目的は、各個別の中核機能に対して利用可能な複数の実装オプションや、アーキテクチャ・フレームワークにおける構成オプションを分析し、マイクロサービス特有の脅威に対抗するセキュリティ戦略を策定し、マイクロサービス基盤のアプリケーション全体のセキュリティ・プロファイルを強化することである。

キーワード（Keywords）

microservices; load balancing; circuit breaker; Application Programming Interface (API); API gateway; service mesh; proxy.

謝辞（Acknowledgements）

著者 Ramaswamy Chandramouli は、Synopsys の David Bohannon、Travis Biehn、John Tapp、Jamie Boote、そして Forgerock の Simon Moffatt に対し、各種トピックに関する詳細なコメントへの謝意を表する。また Wangoh Dynamics Technologies の Saa Edward Fillie、DSD Laboratories の Carlo de Guzman、StackRox の Wei Lien Dang にも感謝の意を表する。特に T-Mobile の Doug McDorman には、有益なインライン・コメントと参考文献への追補に対し特別の謝意を表する。最後に、G2-Inc の Isabel Van Wyk に対し、詳細な編集レビューに感謝する。

特許開示通知（Patent Disclosure Notice）

通知：NIST の情報技術研究所（ITL）は、本出版物の指針または要件への適合に必要となる可能性のある特許請求を保有する者に対し、当該特許請求を ITL に開示するよう要請している。しかし、特許保有者が ITL の特許要請に応じる義務はなく、また ITL は、本出版物に適用され得る特許が存在するかどうかを特定するための特許調査を実施していない。

発行日時点において、また本出版物の指針または要件への適合に必要となる可能性のある特許請求の特定に関する呼びかけの後においても、ITL にはそのような特許請求は特定されていない。

ITL は、本出版物の使用にあたり、特許侵害を回避するためのライセンスが不要であると表明または黙示するものではない。

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

マイクロサービスというパラダイムは、クラウドベースおよびエンタープライズの両インフラにおいて、大規模なアプリケーション・システムの設計・デプロイにますます用いられている。その結果としてのアプリケーション・システムは、マイクロサービスと呼ばれる比較的小さく疎結合なエンティティ（コンポーネント）から構成され、軽量な通信プロトコルを用いて相互に通信する。

マイクロサービス基盤のアプリケーション・システムを設計・デプロイする動機には、以下が含まれる。（a）各コンポーネントが通常、単一の業務機能を実装するため、相対的に小さく複雑性の低いコードベースにもとづく開発の機敏性；（b）マイクロサービスの疎結合な性質による、開発プロセスにおけるチーム間の自律性；（c）認証、アクセス制御、サービス・ディスカバリと通信、負荷分散といったインフラ・サービスを提供するデプロイメント・ツールの可用性。

オーケストレーションのような複数の補助技術が存在するにもかかわらず、マイクロサービス基盤のアプリケーションの開発・デプロイには多くの課題がある。ネットワークを介したメッセージ送受信がこの種のシステムにおけるすべてのトランザクションで発生するため、ネットワーク・セキュリティ、信頼性、レイテンシは極めて重要な要素である。さらに、複数のマイクロサービスが存在することにより、広範な攻撃面が露出する。

本書の目標は、実務上の中核機能の実装オプション、API ゲートウェイやサービスメッシュといったアーキテクチャ・フレームワークの構成オプション、ならびにマイクロサービス特有の脅威に対する対策を分析することで、マイクロサービス基盤アプリケーションの安全なデプロイ戦略を概説することである。

目次（Table of Contents）

Executive Summary — p. iv

- 1. Introduction — p. 1

1.1. Scope — p. 1
1.2. Audience — p. 1
1.3. Relationship to other NIST Guidance Documents — p. 1
1.4. Methodology and Organization — p. 2

- 2. Microservices-based Application Systems: Technology Background — p. 3

2.1. Microservices: A Conceptual View — p. 3
2.2. Microservices: Design Principles — p. 3
2.3. Business Drivers — p. 4
2.4. Building Blocks — p. 4
2.5. Microservices: Interaction Styles — p. 5
2.6. Microservices: State of the Practice Core Features — p. 7
2.7. Microservices: Architectural Frameworks — p. 9
2.7.1. API Gateway — p. 9
2.7.2. Service Mesh — p. 11
2.8. Comparison with Monolithic Architecture — p. 11
2.9. Comparison with Service-Oriented Architecture (SOA) — p. 12
2.10. Advantages of Microservices — p. 12
2.11. Disadvantages of Microservices — p. 13

- 3. Microservices: Threat Background — p. 14

3.1. Review of Threat Sources Landscape — p. 14
3.2. Microservices-specific Threats — p. 15
Service Discovery Mechanism Threats — p. 15
Internet-based Attacks — p. 15
Cascading Failure — p. 16

- 4. Security Strategies for Implementing Core Features and Countering Threats — p. 17

4.1. Strategies for Identity and Access Management — p. 17
4.2. Strategies for Service Discovery Mechanism — p. 19
4.3. Strategies for Secure Communication Protocols — p. 21
4.4. Strategies for Security Monitoring — p. 22
4.5. Availability/Resiliency Improvement Strategies — p. 22
Analysis of Circuit Breaker implementation options — p. 23
Strategies for Load Balancing — p. 24
Rate Limiting (Throttling) — p. 24
4.6. Integrity Assurance Strategies — p. 25
4.7. Countering Internet-based Attacks — p. 26

- 5. Security Strategies for Architectural Frameworks in Microservices — p. 27

Appendix A — Differences between Monolithic Application and Microservices-based Application — p. 29
A.1. Design and Deployment Differences — p. 29
A.1.1. An Example Application to Illustrate the Design and Deployment differences — p. 30
A.2. Run-time Differences — p. 31
Appendix B — Traceability of Security Strategies to Microservices Architectural Features — p. 33

1 はじめに（Introduction）

アプリケーション・システムは、アジリティ、柔軟性、スケーラビリティ、そして基盤プロセスを自動化するためのツールの可用性といった利点から、マイクロサービスというパラダイムを用いてますます開発・デプロイされている。しかし、マイクロサービス基盤のアプリケーション・システムではコンポーネント数が飛躍的に増大し、各コンポーネント間で多様な相互作用スタイルを含む複雑なネットワーク環境が組み合わさるため、API ゲートウェイやサービスメッシュといったアーキテクチャ・フレームワークに単独またはバンドル／パッケージ化されて実装される複数の中核インフラ機能の実装が求められる。本書の目的は、中核機能の実装オプション、アーキテクチャ・フレームワークの構成オプション、マイクロサービス特有の脅威に対する対策を分析し、セキュリティ戦略を概説することである。

1.1 適用範囲（Scope）

本書では、マイクロサービス基盤のアプリケーション・システムのデプロイに用いられる各種ツールについては取り上げない。中核機能およびアーキテクチャ・フレームワークの議論は、安全な実装に関わる論点の強調に限定する。主眼は、以下の 3 つの基本ステップを通じてマイクロサービス基盤アプリケーションのセキュリティ戦略を策定する方法論にある。

マイクロサービス基盤のアプリケーション・システムの背後にある技術の研究（設計原則、基本的ビルディングブロック、関連インフラに焦点）。
マイクロサービスの稼働環境に特有の脅威背景の集中的レビュー。
実務上の中核機能に関する実装オプション、API ゲートウェイやサービスメッシュといったアーキテクチャ・フレームワークに関する構成オプション、ならびにマイクロサービス特有の脅威に対する対策の分析にもとづくセキュリティ戦略の策定。

1.2 想定読者（Audience）

本書で論じるセキュリティ戦略の対象読者は以下のとおりである。

マイクロサービス・アーキテクチャに基づく分散システムをホストするエンタープライズ・インフラを構築しようとする、民間企業または政府機関の IT 部門の CSO（Chief Security Officer）または CTO（Chief Technology Officer）。
マイクロサービス基盤のアプリケーション・システムを設計しようとするアプリケーション・アーキテクト。

1.3 他の NIST ガイダンス文書との関係（Relationship to other NIST Guidance Documents）

本ガイダンス文書は、特定のアーキテクチャに基づくアプリケーションのクラスに焦点を当てている。しかし、不可欠なアーキテクチャ・コンポーネントであるマイクロサービスはコンテナ内に実装され得るため、アプリケーション・コンテナ技術に関連するセキュリティ・ガイダンスや推奨事項は、本書で論じるアプリケーション・アーキテクチャに対する関連するセキュリティ戦略ともなり得る。該当するガイダンスには以下が含まれる。

NIST Special Publication (SP) 800-190, Application Container Security Guide
NIST Interagency or Internal Report (NISTIR) 8176, Security Assurance Requirements for Linux Application Container Deployments

1.4 方法論と構成（Methodology and Organization）

マイクロサービス基盤のアプリケーション・システムは、（サーバ仮想化、コンテナ、クラウド・ミドルウェアなど）多様な技術を包含しているため、本書ではこのアプリケーション・クラスの中核機能と、それらをバンドル／パッケージ化するアーキテクチャ・フレームワークに焦点を当てる。脅威分析のアプローチとしては、マイクロサービス基盤のアプリケーション・システムのデプロイメント・スタック全体と、これらの中核機能が位置するレイヤを俯瞰する。次に、それらの機能に特有の脅威を特定し、コア機能およびアーキテクチャ・フレームワークに対する複数の実装オプションを分析し、それらがマイクロサービス特有の脅威に対抗することを確保するという全体方針にもとづいてセキュリティ戦略を策定する。この方法論に基づく資料のロードマップは次のとおりである。

マイクロサービスのインフラを構成する、実務上の中核機能の総覧（セクション 2.6）。
デプロイメント・スタックにおける各レイヤのレビュー、中核機能の所在レイヤ、およびマイクロサービス特有の脅威の特定（セクション 3）。
これらの中核機能に対する各種実装オプションの分析と、それらにもとづく中核機能の実装に関するセキュリティ戦略の概説（セクション 4）。
マイクロサービス向けインフラに必要な複数の中核機能を単一製品としてバンドルするアーキテクチャ・フレームワークの総覧と、それらのフレームワークの構成オプションにもとづくセキュリティ戦略の概説（セクション 5）。

本書各セクションの内容を、やや詳細に要約すると以下のとおりである。

セクション 2：マイクロサービス基盤のアプリケーション・システムの高レベルかつ広範な概観。概念的視点から始め、設計原則、ビジネス・ドライバ、ビルディングブロック、コンポーネントの相互作用スタイル、実務上の中核機能、アーキテクチャ・フレームワークへと続く。
セクション 3：スタック・レベルの観点からの脅威背景と、マイクロサービス環境に特有な脅威の一部。
セクション 4：マイクロサービス基盤アプリケーションを支える実務上の各種中核機能に関する分析情報と、実装オプションの分析にもとづく当該中核機能の実装に関するセキュリティ戦略の概説。
セクション 5：マイクロサービス基盤アプリケーションのインフラに必要な中核機能をバンドルするアーキテクチャ・フレームワークに関する分析情報と、それらフレームワークの構成に関するセキュリティ戦略の概説。

2 マイクロサービス基盤アプリケーション・システム：技術的背景（Technology Background）

本セクションでは、マイクロサービス基盤のアプリケーション・システムの開発・デプロイの背後にある技術を、根底にある設計ドライバ／原則、ビルディングブロックを構成するアーティファクト、そしてそれらビルディングブロックを構成して多様なデプロイメント・オプションを生み出す方法を通じて説明する。これは技術の包括的記述を意図するものではないが、マイクロサービス基盤アプリケーション・システムのセキュリティ脅威の特定および安全な実装戦略の策定を容易にするために必要十分なコンポーネントと概念に関する情報を提供する。

2.1 マイクロサービス：概念的視点（A Conceptual View）

マイクロサービス基盤のアプリケーション・システムは、同期的なリモート・プロシージャ・コール、または非同期メッセージング・システムを通じて相互に通信する複数のコンポーネント（マイクロサービス）から構成される。各マイクロサービスは通常 1（まれに複数）の独立した業務プロセスまたは機能（例：顧客詳細の保存、製品カタログの保存と表示、顧客注文処理など）を実装する。各マイクロサービスは、ビジネス・ロジックと、データベース・アクセスやメッセージングなどの機能を実行するための各種アダプタを備えたミニ・アプリケーションである。一部のマイクロサービスは、他のマイクロサービスやアプリケーションのクライアント [2] が利用する REST（Representational State Transfer）フル API [1] を公開する。他のマイクロサービスは Web ユーザー・インタフェース（UI）を実装する場合もある。実行時には、マイクロサービス・インスタンスは、アプリケーション・サーバのプロセス、仮想マシン（VM）、またはコンテナとして動作するよう構成され得る。

マイクロサービス基盤のアプリケーションは純粋にエンタープライズ・アプリケーションとして実装され、クラウド・サービスとしては実装されない場合もあり得るが、しばしばクラウド・ネイティブ・アプリケーションとして、サービス指向のアーキテクチャ、API 駆動の通信、コンテナ基盤のインフラ、そして DevOps（開発と運用の組み合わせ）プロセス（継続的改善、アジャイル開発、継続的デリバリ、開発者・品質保証・セキュリティ専門家・IT 運用・事業部門ステークホルダ間の協働）への志向性を備えたものと捉えられる [3]。この見方の一因は、オンプレミスのソフトウェア開発・デプロイが、疎結合なサービス基盤アーキテクチャや API ベースの通信ではなく、緊密に結合したアプリケーション・モジュールを備えたサーバ中心のインフラに依拠していることにある。

2.2 マイクロサービス：設計原則（Design Principles）

マイクロサービスの設計は次のドライバ [4] に基づく。

各マイクロサービスは、他のマイクロサービスから独立して、管理・複製・スケール・アップグレード・デプロイできなければならない。
各マイクロサービスは単一の機能を持ち、限定された文脈（境界づけられたコンテキスト）で動作すべきである（すなわち、限定された責務と他サービスへの依存）。
すべてのマイクロサービスは常時の故障と回復を想定して設計されるべきであり、そのため可能な限りステートレスでなければならない。
状態管理には、（データベース、キャッシュ、ディレクトリなどの）既存の信頼できるサービスを再利用すること。

これらのドライバは、マイクロサービスの設計原則として次を導く。

自律性（Autonomy）
疎結合（Loose coupling）
再利用（Re-use）
合成可能性（Composability）
フォールトトレランス（Fault tolerance）
発見可能性（Discoverability）
ビジネス・プロセスに整合した API（APIs alignment with business processes）

2.3 ビジネス・ドライバ（Business Drivers）

マイクロサービス基盤アプリケーション・システムのデプロイに対するビジネス上のドライバは、本書の主題と直接関係するのは限定的ではあるが、利用者および組織行動の観点から関連するものを明示しておく [5]。

ユビキタス・アクセス：利用者は、ブラウザやモバイル端末など複数のクライアント・デバイスからアプリケーションにアクセスしたい。
スケーラビリティ：利用者数の増加や既存利用者の利用頻度の増大に直面しても可用性を維持できる高いスケーラビリティが求められる。
アジャイル開発：組織（プロセスや構造）の変化や市場ニーズに迅速に対応するため、頻繁なアップデートが求められる。

2.4 ビルディングブロック（Building Blocks）

マイクロサービス基盤アプリケーション（例：分散エンタープライズまたは Web アプリケーション [1]）は、特定の技術に限定されないアーキテクチャ・スタイル／デザイン・パターンを用いて構築され、小さく独立したエンティティ（エンドポイント）から構成され、軽量なメカニズムを用いて相互に通信する。これらエンドポイントは、明確に定義された API によって実装される。API エンドポイントには複数のタイプがあり、SOAP（Simple Object Access Protocol）や REST（HTTP（Hypertext Transfer Protocol）プロトコル）などがある。小さく独立した各エンティティは「サービス」と呼ばれる固有のビジネス能力を提供し、独自のデータ・ストアやリポジトリを持つ場合がある。これらサービスへのアクセスは、Web ブラウザやモバイル端末などの各種プラットフォームまたはクライアント種別が、「クライアント」と呼ばれるコンポーネントを通じて提供する。サービス群とクライアントは合わせて、マイクロサービス基盤アプリケーション・システム全体を構成する。この種のシステムにおけるサービスは、次のように分類できる。

アプリケーション機能サービス。
インフラ・サービス（本書では「中核機能」と呼ぶ）。スタンドアロン機能として、または API ゲートウェイやサービスメッシュのようなアーキテクチャ・フレームワークにバンドルされて実装される。これらには、認証と認可、サービス登録とディスカバリ、セキュリティ監視などが含まれるが、これらに限定されない。

マイクロサービス基盤アプリケーション・システムでは、複数の協調するサービスのそれぞれを異なる技術で構築できる。これは技術的異種性（technical heterogeneity）の概念を推進するもので、単一のマイクロサービス基盤アプリケーション・システム内の各サービスが、異なるプログラミング言語、開発プラットフォーム、異なるデータ・ストレージ技術で記述され得ることを意味する。この概念により、開発者はサービスの種類に応じて適切なツールや言語を選択できる。したがって、単一のマイクロサービス基盤アプリケーション・システムの中で、構成するサービスが異なる言語（例：Ruby、Golang、Java）で構築され、異なるストア（例：ドキュメント・データストア、グラフ・データベース（DB）、マルチメディア DB）をホストしている場合がある。各コンポーネント・サービスは、当該サービスの開発・運用要件をすべて担う 1 つのチーム（マイクロサービス・チームまたは DevOps チーム）によって開発され、サービス機能やサービス・コントラクトが合意されている限りにおいて、開発・デプロイ技法に関して高度な自律性を有する [6]。

マイクロサービスにおいてサービスは別々のノードに個別にデプロイされる。これらの間の通信は、ローカル関数呼び出しからリモート呼び出しへと変化するため、ネットワーク通信に内在するレイテンシの影響によりシステム性能に影響を及ぼし得る。したがって、軽量な通信インフラが必要となる。

スケーリングは、CPU やメモリ資源の不足に起因するパフォーマンス・ボトルネックを抱えるサービスに選択的に適用でき、他のサービスは小規模で安価なハードウェアで稼働を続けられる。当該サービスに関連する機能は、目的に応じて異なる方法で消費され得るため、再利用性と合成可能性が促進される。例として、顧客データベース・サービスの内容は、出荷部門が船荷証券の作成に用いるとともに、売掛金管理または請求部門が請求書の送付に用いる、といった使い方が挙げられる。

2.5 マイクロサービス：相互作用スタイル（Interaction Styles）

モノリシック・アプリケーションでは、各コンポーネント（すなわち手続きや関数）は、メソッドや関数といった言語レベルの呼び出しで他のコンポーネントを起動する。マイクロサービス基盤アプリケーションでは、各サービスは一般に独自のネットワーク・ノードでプロセスとして稼働し、プロセス間通信（IPC）メカニズム [7] を通じて他サービスと通信する。さらに、サービスは Swagger/OpenAPI のようなインタフェース定義言語（IDL）で定義され、API（application programming interface）と呼ばれるアーティファクトになる。サービス開発の最初のステップはインタフェース定義の作成であり、クライアント開発者とレビューし、実装開始前に複数回の反復を経る。したがって、API はクライアントとサービス間の契約として機能する。

IPC メカニズムの選択は API の性質を規定する [7]。表 1 は各 IPC メカニズムにおける API 定義の性質を示す。

表 1：IPC メカニズムと API 種別

IPC メカニズム	API 定義の性質
非同期・メッセージ基盤（例：AMQP（Advanced Message Queuing Protocol）や STOMP（Simple/Streaming Text Oriented Messaging Protocol））	メッセージ・チャネルとメッセージ種別から構成される
同期リクエスト／レスポンス（例：HTTP ベースの REST または Thrift）	URL とリクエスト／レスポンス形式から構成される

IPC 通信で用いられるメッセージ形式には、JSON や XML のようなテキストベースで人間可読なものと、Apache Avro や Protocol Buffers のような純機械可読のバイナリ形式がある。

先に述べた自律性の原則からは、各マイクロサービスがアプリケーション・スタックのすべての機能を提供する自己完結型エンティティであることが求められるかもしれない。しかし、複数の業務プロセス能力（例：注文、出荷、請求といった業務プロセスを提供するオンライン・ショッピング・アプリケーション）を提供するマイクロサービス基盤アプリケーションでは、構成要素であるマイクロサービスは常に何らかの形で他のマイクロサービス（例：データ）に依存する。例の文脈では、出荷マイクロサービスは、出荷伝票（船荷証券）レコードを生成する機能を果たすために、注文マイクロサービスにある「未処理注文」データに依存している。したがって、自律性を維持しつつマイクロサービス間の結合が常に必要になる。ビジネス・プロセスや IT インフラのニーズにより規定されることの多い結合の方法には、相互作用パターン、メッセージング・パターン、消費モードがある。本書では「相互作用パターン」という用語を用い、主な相互作用パターンは以下のとおりである。

Request-reply（要求—応答）：リクエストには 2 種類がある。情報取得のための問い合わせと、状態を変更する業務機能のためのコマンドである [2]。前者では、マイクロサービスは特定の情報の取得または何らかの処理の実行を要求し、実質的に応答を待機する。問い合わせの目的は、提示（プレゼンテーション）目的の情報取得である。後者では、あるマイクロサービスが別のマイクロサービスに対し、（顧客がプロフィールを変更する、または注文を送信するなどの）状態を変更する業務機能の実行を依頼する。要求—応答パターンでは、関与する 2 つのマイクロサービス間に強いランタイム依存が存在し、次の 2 つの形で現れる。

一方のマイクロサービスは、もう一方のマイクロサービスが利用可能である場合にのみ自身の機能を実行できる。
リクエストを発行するマイクロサービスは、そのリクエストが対象マイクロサービスに正常に届けられたことを保証しなければならない。

要求—応答プロトコルの通信の性質上、HTTP のような同期通信プロトコルが用いられる。マイクロサービスが REST API で実装されている場合、マイクロサービス間のメッセージは HTTP REST API 呼び出しとなる。REST API はしばしば RAML（RESTful API Modeling Language）のような標準化言語を用いて定義され、マイクロサービスのインタフェース定義と公開のために開発された。HTTP はブロッキング型の通信であり、リクエストを開始したクライアントは応答を受け取って初めて処理を継続できる。

Publish-Subscribe（発行—購読）：このパターンは、複雑な業務プロセスやトランザクションの実現に向けてマイクロサービスが協調する必要がある場合に用いられる。これはビジネス・ドメイン・イベント駆動アプローチ、またはドメイン・イベント購読アプローチとも呼ばれる。このパターンでは、マイクロサービスはビジネス・ドメイン・イベント（例：特定の情報に関心がある、または特定の要求を処理できる）に自身を登録（サブスクライブ）し、イベントバス・インタフェースを通じてメッセージ・ブローカに発行される。これらのマイクロサービスはイベント駆動 API で構築され、MQTT、AMQP、Kafka Messaging といった非同期メッセージング・プロトコルを使用し、通知および購読のサポートを可能にする。非同期プロトコルでは、メッセージ送信者は通常、応答を待機せず、単にメッセージをメッセージ・エージェント（例：RabbitMQ のキュー）へ送信する。このアプローチのユースケースの一つは、特定のイベントにもとづいて複数のマイクロサービスへデータ更新を伝播することである [8]。

2.6 マイクロサービス：実務上の中核機能（State of the Practice Core Features）

マイクロサービス基盤アプリケーション環境における通信インフラの重要性から、多くのデプロイメントでは高度な機能を中核機能として提供する必要が生じる。既に述べたとおり、これらの機能はスタンドアロンとして、または API ゲートウェイやサービスメッシュのようなアーキテクチャ・フレームワークにバンドルして実装できる。API ゲートウェイ内でも、これらの機能はサービス合成を通じて、またはコードベース内で直接実装して提供できる。これらの機能には、認証、アクセス制御、サービス・ディスカバリ、負荷分散、レスポンス・キャッシング、アプリケーション認識型ヘルスチェック、監視などが含まれるが、これらに限定されない [2]。これら機能の簡潔な説明 [5] は次のとおりである。

認証とアクセス制御：マイクロサービスが公開する API の種類（パブリック API、プライベート API、ビジネス・パートナ専用のパートナ API）に応じて、認証およびアクセス・ポリシーは変わり得る。
サービス・ディスカバリ：レガシー分散システムでは、複数のサービスが所定の場所（IP アドレスとポート番号）で動作するよう構成されている。マイクロサービス基盤アプリケーションでは次の状況が存在し、堅牢なサービス・ディスカバリ機構が求められる。
a) 多数のサービスと、各サービスに関連する数多くのインスタンスがあり、その所在が動的に変化する。
b) 各マイクロサービスは VM やコンテナで実装されている場合があり、特に IaaS や SaaS のクラウド・サービス上にホストされる場合は動的 IP アドレスが割り当てられ得る。
c) オートスケーリングなどの機能により、サービスに関連するインスタンス数は負荷の変動に応じて変化し得る。
セキュリティ監視と分析：攻撃の検知や（可用性に影響し得る）サービス劣化の要因特定のため、通常のログ機能に加えて、マイクロサービスの入出力ネットワーク・トラフィックの監視および分析機能が必要である。

API ゲートウェイまたはマイクロゲートウェイは、一般に次の中核機能の実装に用いられる。

最適化されたエンドポイント：これは複数の能力から成る。
a) リクエスト／レスポンスの折り畳み：ほとんどのビジネス・トランザクションは、しばしば所定の順序で、複数のマイクロサービス呼び出しを伴う。API ゲートウェイは、必要な複数のリクエスト（呼び出し）を自動的に発行し、単一の集約レスポンスをクライアントへ返すエンドポイントを公開することで、クライアント側の状況を単純化できる。
b) API 変換（Transformation）：API ゲートウェイは、特定の要求に対応するために呼び出す個々のマイクロサービス API とは異なる公開インタフェースをクライアントに提供できる。この機能は API 変換と呼ばれ、次を可能にする。
- i) 個々のマイクロサービスの実装、さらには API インタフェース自体の変更。
- ii) 単一体型（モノリシック）アプリケーションからマイクロサービス基盤アプリケーションへの移行において、API ゲートウェイを通じてクライアントからの継続的なアクセスを可能にしつつ、バックグラウンドでモノリシック・アプリケーションを段階的に分割し、マイクロサービス API を作成し、API 変換の構成を適宜変更していくこと。
c) プロトコル翻訳：クライアントからマイクロサービスの入口点への呼び出しは HTTPS のような Web プロトコルで行われる一方で、マイクロサービス間の通信は同期プロトコル（RPC/Thrift）や非同期プロトコル（AMQP）を用いる場合がある。クライアント要求における必要なプロトコル変換は、通常 API ゲートウェイが担う。
サーキットブレーカー：あるマイクロサービス・インスタンスに対する失敗応答の閾値を設定し、失敗が閾値を超えた場合には当該インスタンスへのプロキシ要求を遮断する機能。これによりカスケード障害の可能性を回避し、ログ分析、必要な修正の実装、問題のあるインスタンスへの更新適用までの時間を確保できる。
負荷分散：同一サービスの複数インスタンスが必要となるため、これらインスタンスへの負荷を均等に分配し、過負荷による応答遅延やサービス・クラッシュを回避する必要がある。
レート制限（スロットリング）：マイクロサービスに到来するリクエスト・レートを制限し、すべてのクライアントに対するサービスの継続的可用性を確保する。
ブルー／グリーン・デプロイメント：マイクロサービスの新バージョンがデプロイされたとき、API ゲートウェイは両バージョンの所在を認識するようプログラムできるため、旧バージョンを利用している顧客からの要求を新バージョンへリダイレクトできる。
カナリア・リリース：新バージョンの正しさや性能指標が全運用シナリオで十分に把握されるまで、初期段階では当該新バージョンに送るトラフィックを限定する。十分な運用特性データが収集され次第、当該マイクロサービスへの全リクエストを新バージョンへプロキシする。

2.7 マイクロサービス：アーキテクチャ・フレームワーク（Architectural Frameworks）

マイクロサービス基盤アプリケーションにおいて、主として信頼性・レジリエンス・セキュリティを確保した通信を実現するための中核機能をバンドル／パッケージ化する 2 つの主要なアーキテクチャ・フレームワークは次のとおりである。

API ゲートウェイ（マイクロゲートウェイの有無を問わず拡張）。
サービスメッシュ。

マイクロサービス基盤アプリケーション・システムの運用環境におけるこれらフレームワークの役割は表 2 のとおりである [4]。

表 2：マイクロサービス運用におけるアーキテクチャ・フレームワークの役割

アーキテクチャ・フレームワーク	全体アーキテクチャにおける役割
API ゲートウェイ（マイクロゲートウェイの有無を問わず）	ノースサウス・トラフィックとイーストウエスト・トラフィックの双方を制御するために使用される
サービスメッシュ	マイクロサービスがコンテナで実装されている場合に純粋なイーストウエスト・トラフィック向けにデプロイされるが、VM やアプリケーション・サーバ内の場合にも利用可能

両フレームワークに共通する代表的機能には、サービス・ディスカバリ、負荷分散、障害検出、障害対応、攻撃監視がある。

2.7.1 API ゲートウェイ

API ゲートウェイは、マイクロサービス基盤アプリケーション・システムにとって一般的なアーキテクチャ・フレームワークである。モノリシック・アプリケーションではエンドポイントは単一サーバであることが多いが、マイクロサービス基盤アプリケーションは多数のきめ細かなエンドポイントから構成される。したがって、アプリケーションを構成する複数のマイクロサービスに対して、すべてのクライアントの単一入口点を提供することには合理性がある。また、モノリシックなエンタープライズ・アプリケーションからの移行の際、時間をかけてそのコンポーネントを独立したマイクロサービスへ置き換えていく場合、API ゲートウェイはフロントエンド（レガシー企業ソフトウェアに適合）としてデプロイされ、バックエンド・サービスの前段に置かれる。クライアントが複数エンドポイントに直接通信する方式は、あまりに多数のポイント・ツー・ポイント接続を生む。

API ゲートウェイの主機能は、インバウンド要求を常に正しい下流サービスへルーティングし、必要に応じてプロトコル翻訳（すなわち、HTTP や WebSocket のような Web プロトコルと、内部で使用される AMQP や Thrift バイナリ RPC のような非 Web プロトコル間の変換）を行い、場合によっては要求を合成（compose）することである。まれに、BFF（Backend for Frontend）の一部として用いられ、ブラウザやモバイル端末など異なるフォームファクタのクライアントをサポートすることもある。すべてのクライアントからの要求はまず API ゲートウェイを経由し、その後、適切なマイクロサービスへルーティングされる。API ゲートウェイは、複数のマイクロサービスを呼び出して結果を集約することで、1 つの要求を処理することが多い。

API ゲートウェイを介してアクセス可能な複数の API またはマイクロサービスは、ゲートウェイの入力ポート定義（例：mobileAPI や MobileService）の一部として指定するか、API ゲートウェイ・サービスのデプロイ操作を通じて動的に指定でき、その際のリクエスト・パラメータに、要求されたサービスと組み合わせるべきサービス名を含めることができる [9]。このように、クライアントとマイクロサービスの間に位置する API ゲートウェイは、プロキシが複数サービスを集約するパターンを表す。多くの API ゲートウェイ実装は、Jolie、JavaScript、Java など異なる言語で書かれた API をサポートできる。

API ゲートウェイはマイクロサービスへの入口点であるため、要求整形（request shaping）という主たるサービスに加え、サービス・ディスカバリ、認証とアクセス制御、負荷分散、キャッシング、クライアント種別ごとのカスタム API の提供、アプリケーション認識型ヘルスチェック、サービス監視、攻撃検知、攻撃対応、セキュリティ・ログと監視、サーキットブレーカーといった必要なインフラ・サービスを備えるべきである。これら追加機能は、API ゲートウェイ内で次の 2 つの方法で実装され得る。

当該機能のために開発された特定サービス（例：サービス・レジストリによるサービス・ディスカバリ）を合成して用いる。
これらの機能を、API ゲートウェイを利用するコードベース内部で直接実装する。

ゲートウェイ実装（Gateway implementations）

異なるクライアント種別向けの要求整形を単一のゲートウェイに過度に詰め込まないよう、ゲートウェイを複数に分割する [8]。この複数ゲートウェイ・パターンは BFF と呼ばれる。BFF では、クライアント種別ごと（例：Web アプリ BFF、モバイル・アプリ BFF）にゲートウェイを割り当て、サービス要求の集約点とする。対応するバックエンドは当該フロントエンド（クライアント）と密接に整合し、通常は同じチームが開発する。BFF が提供する機能は GraphQL でも実現でき、クライアントがレスポンスに必要なデータ型の部分を要求内で指定することで、レスポンスの形状を自ら決められる。

マイクロサービス基盤アプリケーションの API 管理は、モノリシックな API ゲートウェイ・アーキテクチャ、または分散型 API ゲートウェイ・アーキテクチャのいずれでも実装できる。モノリシックな API ゲートウェイ・アーキテクチャでは、通常エンタープライズ・ネットワークのエッジ（例：DMZ（非武装地帯））に 1 つの API ゲートウェイのみを配置し、エンタープライズ水準で API へのすべてのサービスを提供する。分散型 API ゲートウェイ・アーキテクチャでは、マイクロサービス API に近接してデプロイされる複数のマイクロゲートウェイ・インスタンスが存在する [10]。マイクロゲートウェイは、一般に軽量でスクリプト可能な API ゲートウェイであり、カスタマイズされたポリシーを定義・強制できるため、サービス固有のセキュリティ・ポリシーによる保護が求められるマイクロサービス基盤アプリケーションに適している。

マイクロゲートウェイは通常、Node.js などの開発プラットフォームを用いたスタンドアロン・コンテナとして実装される。これは、サービスメッシュ・アーキテクチャのサイドカー・プロキシ（セクション 2.7.2 参照）とは異なり、サイドカーは API エンドポイント自体で実装される。ゲートウェイにセキュリティ・ポリシーをエンコードし入力する方法はいくつかある。1 つのアプローチは、ポリシーを JSON 形式でエンコードし、グラフィカルなポリシー管理インタフェースを通じて入力することである。マイクロゲートウェイには、アプリケーションのリクエストおよびレスポンスの双方に対するポリシーを含めるべきである。ポリシーとその適用がコンテナとして実装される場合、それらは不変（immutable）であるため、偶発的または意図しない変更（それがセキュリティ侵害や競合を招き得る）に対する一定の防護を提供する。換言すれば、マイクロゲートウェイをコンテナとして実装することで、セキュリティ・ポリシーの更新にはマイクロゲートウェイの再デプロイが必要となるため、この種の変更は防止される。いずれにせよ、任意のマイクロサービス・インスタンスにデプロイされるマイクロゲートウェイは、保護対象のマイクロサービスの運用状態を追跡するために、サービス・レジストリや監視モジュールと通信することが不可欠である。

2.7.2 サービスメッシュ（Service Mesh）

サービスメッシュは、サービス間通信を促進する専用のインフラ層であり、サービス・ディスカバリ、ルーティングと内部負荷分散、トラフィック構成、暗号化、認証と認可、メトリクス、および監視を提供する。サービス・インスタンスの出入りや継続的再配置によるネットワーク・トポロジの変化する環境において、ネットワーク動作、ノード・アイデンティティ、トラフィック・フローをポリシーで宣言的に定義する能力を提供する。これは、OSI 参照モデルのトランスポート層（例：TCP/IP）よりも抽象度の高いレイヤに位置するネットワーク・モデルとして捉えることができ、サービスのセッション層（OSI モデルの第 5 層）の関心事に対処する [11]。ただし、細粒度の認可は、ビジネス・ロジックに関する完全な知識を持つ唯一のエンティティがマイクロサービスであるため、依然としてマイクロサービス側で実行する必要がある場合がある。サービスメッシュは概念的に、データ・プレーンとコントロール・プレーンという 2 つのモジュールを持つ。データ・プレーンはサービス固有のプロキシを通じてサービス・インスタンス間のアプリケーション要求トラフィックを運ぶ。コントロール・プレーンはデータ・プレーンを構成し、テレメトリの集約点を提供し、負荷分散、サーキットブレーク、レート制限などの各種機能を通じてネットワークの挙動を変更するための API を提供する。

サービスメッシュは、マイクロサービス・アプリケーション内の各サービスに対し、小さなプロキシ・サーバのインスタンスを作成する。この特殊なプロキシはサービスメッシュ用語では「サイドカー・プロキシ」と呼ばれることがある [12]。サイドカー・プロキシがデータ・プレーンを形成し、アクセス制御や通信関連などのセキュリティ強制に必要な実行時の動作は、コントロール・プレーンからサイドカー・プロキシに（例：アクセス制御ポリシーのような）ポリシーを注入することで有効化される。これにより、マイクロサービスのコードを変更せずにポリシーを動的に変更できる柔軟性も提供される。

2.8 モノリシック・アーキテクチャとの比較（Comparison with Monolithic Architecture）

マイクロサービス・アーキテクチャを、すべてのレガシー・アプリケーションに用いられてきたモノリシック・アーキテクチャと完全に比較するには、これらのアーキテクチャ・スタイルで開発されたアプリケーションの特性を比較し、特定の業務プロセスに関するアプリケーションの例を両アーキテクチャで提示する必要がある。これらに関する詳細な議論は付録 A に示す。

2.9 サービス指向アーキテクチャ（SOA）との比較（Comparison with SOA）

マイクロサービスのアーキテクチャ・スタイルは、次の共通する技術概念により、SOA（Service-Oriented Architecture）と多くの類似点を有する [13]。

サービス：アプリケーション・システムは、可視性や発見可能性、ステートレス、再利用性、合成可能性、技術的多様性などの属性を持ち得る自己完結型のエンティティ（サービス）によって、その様々な機能を提供する。
相互運用性：SOA の場合は ESB（Enterprise Service Bus）といったアーティファクトを用い、マイクロサービス環境では RPC によるネットワーク越しの呼び出しを用いるなど、サービスは任意の他サービスを呼び出すことができる。
疎結合：サービス間の依存は最小限であり、一方のサービスの変更が他方のサービスの変更を必要としない。

上記 3 つの共通技術概念にもかかわらず、SOA とマイクロサービス環境の関係についての技術的見解は、次の 3 つの立場に分かれる [13]。

マイクロサービスは独立したアーキテクチャ・スタイルである。
マイクロサービスは SOA パターンの一つを表す。
マイクロサービスは洗練された SOA である。

最も一般的な見解は、SOA とマイクロサービスの差異はアーキテクチャ・スタイル自体に関するものではなく、具体的な実現（開発やデプロイのパラダイムと技術）に関するものであるという点である [2]。

2.10 マイクロサービスの利点（Advantages of Microservices）

大規模アプリケーションでは、アプリケーションを疎結合なコンポーネントに分割することで、各コンポーネントに割り当てられた開発チーム間の自律性が高まる。各チームは、開発プラットフォーム、ツール、言語、ミドルウェア、ハードウェアを、対象コンポーネントに対する適合性にもとづいて選択し最適化できる。
各コンポーネントを個別にスケールできる。資源の選択的割当ては、資源の最大活用につながる。
コンポーネントに HTTP RESTful なインタフェースがある場合、そのインタフェースが維持される限り、実装の変更はアプリケーション全体の機能に支障をきたさない。
各コンポーネントに関わるコードベースが相対的に小さいため、開発チームはより迅速に更新を提供でき、業務プロセスや市場状況の変化に機敏に対応できる。
コンポーネント間の疎結合により、マイクロサービスの停止の影響は当該サービスに局所化され、他コンポーネントやアプリケーションの他部分へのドミノ効果を抑制できる。
コンポーネント間の連携が非同期イベント処理メカニズムで結ばれている場合、コンポーネントの停止の影響は一時的であり、当該コンポーネントが再稼働すると必要な機能が自動的に実行されるため、業務プロセス全体の整合性は維持される。
サービス定義をビジネス能力に整合させる（すなわち、全体の機能分解をビジネス・プロセス／能力にもとづいて行う）ことで、マイクロサービス基盤システムの全体アーキテクチャは組織構造と整合される。これにより、組織単位に関連するビジネス・プロセスが変化し、それに応じて関連サービスの改変とデプロイが必要になった場合にも、機敏な対応が促進される。
マイクロサービスの独立した機能的性質は、アプリケーション間でのコードの再利用性を高める。

2.11 マイクロサービスの欠点（Disadvantages of Microservices）

単一のアプリケーションではなく複数のコンポーネント（マイクロサービス）を監視する必要がある。各コンポーネントの状態とアプリケーション全体の状態を把握するための中央コンソールが必要である。したがって、分散監視と集中可視化の能力を備えたインフラを構築しなければならない。
複数コンポーネントの存在は、いずれかのコンポーネントがいつ停止してもおかしくないという可用性上の課題を生む。
あるコンポーネントは、クライアントの一部に対しては他のコンポーネントの最新バージョンを呼び出し、別のクライアント集合に対しては同じコンポーネントの旧バージョンを呼び出す必要がある場合がある（すなわち、バージョン管理）。
統合テストの実行はより困難になる。すべてのコンポーネントが動作し、相互通信しているテスト環境が必要になるためである。
マイクロサービス基盤アプリケーション内の相互作用が API 呼び出しとして設計されている場合、セキュアな API 管理に必要なすべてのプロセスを実装しなければならない。
マイクロサービス・アーキテクチャは、多層防御（defense in depth）の実践を崩しかねない。多くのアーキテクチャでは、DMZ 内で動作し侵害されることを想定した Web サーバ、その Web サーバが通信するバックエンド・サービス、そしてバックエンド・サービスが通信するデータベースという構成を採る。バックエンド・サービスは、公開された Web サーバとデータベース内の機微データの間に、より堅牢な層として機能し得る。マイクロサービス・アーキテクチャではこれが分割され、Web サーバとバックエンド・サービスがマイクロサービスへと分解され、従来モデルよりも露出が高くなる可能性がある。これは、呼び出し元と機微データの間の保護層が減少する結果を招き得る。したがって、マイクロサービス自体の安全な設計・実装に加え、サービスメッシュや API ゲートウェイのデプロイ・モデルについても安全に設計・実装することが極めて重要である。

3 マイクロサービス：脅威の背景

マイクロサービスに基づくアプリケーション・システムの脅威の背景は、セクション 2 で示した技術的背景の継続として扱われるべきである。脅威の背景を見直すにあたり、以下のアプローチを採用する。

典型的なマイクロサービス型アプリケーションのデプロイメント・スタックのすべてのレイヤを考慮し、各レイヤにおける典型的な潜在的脅威を特定する。
マイクロサービス型アプリケーション・システムに固有の、独立した脅威の集合を特定する。

3.1 脅威ソースの全体像のレビュー

[13] が示すように、典型的なマイクロサービス型アプリケーションのデプロイメント・スタックには 6 つのレイヤが存在する：ハードウェア、仮想化、クラウド、通信、サービス／アプリケーション、オーケストレーション。本書では、これらのレイヤを脅威ソースと見なし、マイクロサービス型アプリケーションにおける脅威の背景の概観を提供するために、それらに付随するいくつかのセキュリティ上の懸念事項を以下に記述する。多くの可能性のある脅威は、マイクロサービスに特有ではなく、他のアプリケーション環境にも共通することに留意が必要である。

ハードウェア層：Meltdown や Spectre [8] のようなハードウェアの欠陥が報告されてはいるものの、そのような脅威は稀である。本書の文脈では、ハードウェアは信頼できるものとみなし、この層からの脅威は考慮しない。
仮想化層：この層では、マイクロサービスやそれをホストするコンテナに対する脅威は、侵害されたハイパーバイザや、悪意のある／脆弱なコンテナ・イメージや VM イメージの利用に起因する。他の NIST 文書で扱われているため、ここでは議論しない。
クラウド環境：クラウド・プロバイダが用いる主要技術は仮想化であるため、仮想化層に対する一連の脅威が同様に当てはまる。さらに、クラウド・プロバイダのネットワーク基盤内部にも潜在的な脅威がある。例えば、すべてのマイクロサービスを単一のクラウド・プロバイダ内でホストすると、外部クライアントとクラウド内でホストされるマイクロサービス間の通信に対する制御と比べ、プロセス間通信に対するネットワーク層のセキュリティ制御が少なくなる可能性がある。クラウド・インフラ内のセキュリティ脅威は他の NIST 文書で考察されており、ここでは扱わない。
通信層：この層は、非常に多くのマイクロサービス、採用される設計パラダイム（疎結合および API コンポジション）、それらの間の多様な相互作用スタイル（同期または非同期）のため、マイクロサービス型アプリケーションに固有である。マイクロサービスの中核機能の多くはこの層に関係し、これら中核機能に対する脅威はセクション 3.2 のマイクロサービス特有の脅威として特定する。
サービス／アプリケーション層：この層における脅威は、悪意のあるコードまたは欠陥のあるコードに起因する。これは安全なアプリケーション開発手法の範疇であり、本書の対象外である。
オーケストレーション層：オーケストレーション層は、コンテナなどの技術がマイクロサービス実装に含まれる場合に関係してくる。この層の脅威は、特にサービスをホストするサーバ、コンテナ、または VM のスケジューリングやクラスタリングに関連する自動化または構成機能の改ざんに関係し、したがって本書の対象外である。

3.2 マイクロサービス特有の脅威

実務上の多くの中核機能は、マイクロサービス型アプリケーションのデプロイメント・スタックにおける通信層を指す。したがって、マイクロサービス型アプリケーションの全体的なセキュリティ戦略には、適切な実装オプションの選択、これら中核機能をパッケージ化するアーキテクチャ・フレームワークの特定、マイクロサービス特有の脅威の特定、そしてそれらの脅威に対抗するためのカバレッジを実装オプションにおいて確保することが含まれるべきである。

ただし、マイクロサービス型アプリケーションは、インジェクション、エンコーディングおよびシリアライゼーション攻撃、クロスサイト・スクリプティング（XSS）、クロスサイト・リクエスト・フォージェリ（CSRF）、HTTP 動詞の改ざん（HTTP verb tampering）[20] を含む、Web アプリケーションが受けやすい攻撃の大半に依然として脆弱であることを指摘しておく必要がある。これらの攻撃を防ぐ多くのコントロールは依然としてマイクロサービスのコード内に実装する必要があるため、開発者が API ゲートウェイやサービスメッシュが自分たちのマイクロサービスに対するセキュリティのすべてを提供してくれるという印象を抱かないようにする必要がある。

3.2.1 サービスディスカバリ機構に対する脅威

サービスディスカバリ機構の基本機能は以下である。

サービスの登録と登録解除。
サービス発見。

サービスディスカバリ機構に対する潜在的なセキュリティ脅威には次が含まれる。

システム内に悪意のあるノードを登録し、通信をそれらにリダイレクトして、結果としてサービスディスカバリを侵害すること。
サービス・レジストリ・データベースの破損により、サービス要求が誤ったサービスへリダイレクトされてサービス拒否（DoS）を引き起こす、あるいは悪意のあるサービスへリダイレクトされてアプリケーション・システム全体の侵害につながること。

3.2.2 インターネットを介した攻撃

ネットワーク化された、あるいは分散型のアプリケーションはすべてインターネットを介した攻撃に脆弱だが、以下の理由により、マイクロサービス型アプリケーションはこの種の攻撃に対してより脆弱である。

モノリシック・アプリケーションが少数の IP 到達可能なリモート・プロシージャ・コール（RPC）インタフェースを公開するのに対し、マイクロサービス・アーキテクチャはほぼ常に、より多くの IP 到達可能な RPC インタフェースの集合を公開する。これは、モノリシック・アプリケーションが広範なビジネス機能を単一コンポーネントで実装することを好み、それらすべてに対して統合されたインタフェースを公開するのが一般的であるためである。
一方で、マイクロサービス・アーキテクチャを採用するアプリケーションは、多くの小さなコンポーネントから構成され、それらが多数のインタフェースを介して連携または接続する。
マイクロサービス型アプリケーションでは、上流コンポーネントに実装されたセキュリティ制御が、下流コンポーネントへ直接アクセスすることでスキップされ、内部機能が不注意に公開されてしまうことに起因するリスクの増大がある。システムの全体的な複雑性の増大は、呼び出し元にどのような条件が課されているかを開発者が推論できず、チェックを省略してしまう可能性を高める。

この種の攻撃にはボットネット攻撃が含まれる。ボットネット攻撃の唯一の手段でも、また唯一の対象システムの分類でもないが、マイクロサービス型アプリケーションに対する被害としては、資格情報の詰め込み／濫用、アカウント乗っ取り、ページのスクレイピングやデータの収集、分散サービス拒否（DDoS）などが挙げられる。

3.2.3 連鎖的障害（Cascading Failure）

マイクロサービス型アプリケーションには多数のコンポーネントが存在するため、サービスが故障する確率が高まる。コンポーネントはデプロイメントの観点から疎結合になるよう設計されているが、多くのビジネス取引は所要の出力を提供するために複数のサービスを順次実行する必要があるため、論理的／機能的な依存関係が存在する。したがって、ビジネス取引の処理ロジックにおいて上流に位置するサービスが失敗すると、それに依存する他のサービスも応答不能になる可能性がある。この現象は連鎖的障害（cascading failure）として知られている。

4 コア機能の実装と脅威対策のためのセキュリティ戦略

マイクロサービス型アプリケーション・システムの設計とデプロイメントに関するセキュリティ戦略は、以下を網羅する。

実務上の中核機能（Appendix B にいくつかの重要な中核機能を示す）に対する実装オプションの分析：

a) アイデンティティおよびアクセス管理、
b) サービス・ディスカバリ、
c) 安全な通信プロトコル、
d) セキュリティ・モニタリング、
e) レジリエンスまたは可用性向上のための手法、
f) 完全性（インテグリティ）保証向上のための手法。

マイクロサービス特有の脅威への対策：

a) サービス・ディスカバリ機構に対する脅威、
b) インターネットを介した攻撃、
c) 連鎖的障害。

なお、サービス・ディスカバリはマイクロサービスにおける中核機能であり、実装オプションの分析ではサービス・ディスカバリ機構に対する脅威も考慮する。同様に、レジリエンスまたは可用性向上の実装オプションは、連鎖的障害に対する対抗策も扱う。そのため、これらの項目について別個のセキュリティ戦略は設けない。

4.1 アイデンティティおよびアクセス管理の戦略

マイクロサービスは API としてパッケージ化されるため、マイクロサービスへの初期の認証形態は API キー（暗号的）を用いることから始まる。Security Assertion Markup Language（SAML）でエンコードされた認証トークン、または OAuth 2.0 フレームワークの下での OpenID Connect による認証トークンは、セキュリティを強化するための選択肢を提供する [14]。認可については、サービスの数が膨大であること、サービスが API を用いて実装されていること、現実のビジネス取引（例：顧客の注文処理や出荷）を支えるためにサービスの合成が必要であることから、すべてのマイクロサービスへのアクセスを統治するアクセス・ポリシーのプロビジョニングと執行のための集中型アーキテクチャが必要である。また、各マイクロサービスが異なる言語やプラットフォーム・フレームワークで実装され得るため、標準化されたトークン（例：JSON Web Token（JWT）— その一部は JSON 形式でエンコードされた OAuth 2.0 アクセス・トークンであり得る [15]）を通じて認可決定を伝達する、標準化されプラットフォームに中立的な方法も必要となる。ポリシーのプロビジョニングとアクセス決定の計算には、認可サーバの使用が必要である。

各マイクロサービスのアクセス・ポイントでアクセス制御ポリシーを実装することの不利な点は、すべてのマイクロサービス API に適用される横断的（共通）ポリシーが一様に実装されるように、追加の労力が必要となることである。API 間でセキュリティ・ポリシーの実装に不一致があると、マイクロサービス型アプリケーション全体にセキュリティ上の影響が及ぶ。ただし、これは粗粒度のポリシーにのみ当てはまる。なぜなら、微粒度のポリシーはマイクロサービスに近い場所、あるいはマイクロサービス自体でのみ定義できるからである。さらに、各マイクロサービス・ノードでアクセス制御を実装するためのフットプリントは、いくつかのノードでパフォーマンス問題を引き起こす可能性がある。複数のマイクロサービス・ノードがトランザクションの実行に協調するため、いずれかのノードに関連するパフォーマンス問題は複数のサービスにまたがって急速に連鎖し得る。これらの要件を踏まえ、マイクロサービスに対する安全なアイデンティティおよびアクセス管理の戦略を以下に示す。

認証のためのセキュリティ戦略（MS-SS-1）

機微なデータにアクセスするマイクロサービス API に対する認証は、単に API キーを用いるだけで行ってはならない。そのような API へのアクセスには、デジタル署名された認証トークン（例：クライアント・クレデンシャル・グラント）か、信頼できる情報源で検証されるトークンが必要である。加えて、一部のサービスでは、侵害されたトークンが引き起こし得る損害を限定するため、ワンタイム・トークンまたは短命トークン（短時間で失効するトークン）が必要となる場合がある。
認証トークンは、ハンドル・ベース（最初に RP（Relying Party）にトークン参照を送る方式）、暗号学的に署名されたもの、または HMAC（Hash-based Message Authentication Code）方式で保護されたものであるべきである。
アプリケーションで使用されるすべての API キーには、当該キーを使用できるアプリケーション（例：モバイル・アプリ、IP アドレス）および API セットの双方に対する利用制限を指定すべきである。
各 API キーの機能に対する制限範囲は、身元証明（identity proofing）が提供する保証レベル（機械駆動か人手によるかを問わず）に見合ったものでなければならない。
無状態（stateless）の認証トークン（例：JSON Web Token（JWT））を、マイクロサービスに関連付けられた共有ライブラリによって用いる場合、以下のセキュリティ上の注意事項を遵守しなければならない。(a) トークンの有効期限は可能な限り短くすること。なぜなら、有効期限がセッションの継続時間を決定し、アクティブなセッションは失効させられないからである。および (b) トークンの秘密鍵をライブラリ・コードの一部としてはならないこと。秘密鍵は、環境変数として表現される動的変数、または環境データ・ファイルで指定されるべきである。鍵の値はデータ・ボールト・ソリューションに保管すべきである。
OAuth や OpenID Connect といった標準に基づく手法を実装する場合は、それらを安全にデプロイしなければならない [19]。

アクセス管理のためのセキュリティ戦略（MS-SS-2）

すべての API とそのリソースに対するアクセス・ポリシーは定義され、アクセス・サーバにプロビジョニングされるべきである。粗い粒度のポリシー（例：「所与のアドレス可能な機能集合に対する呼び出しを許可する」）は初期の API ゲートウェイで定義・強制されるべきであり、より細かい粒度（例：特定のマイクロサービスのビジネス・ロジック領域に関するもの）の認可は、マイクロサービスの位置に近い場所（例：マイクロ・ゲートウェイ）で、場合によってはマイクロサービス自体で定義・強制されるべきである。
キャッシュ機構：マイクロサービスがポリシー・データをキャッシュすることを許容してもよい。ただし、このキャッシュはアクセス・サーバが利用不能のときにのみ信頼すべきであり、環境／インフラにふさわしい期間で期限切れとなるべきである。
アクセス・サーバは、微粒度のポリシーをサポートできなければならない。
アクセス・サーバからのアクセス決定は、プラットフォームに中立的な形式でエンコードされた標準化トークン（例：JSON 形式でエンコードされた OAuth 2.0 トークン）を通じて、個々のマイクロサービスおよびマイクロサービスの集合へ伝達されるべきである。トークンはハンドル・ベースのトークンでも、アサーション保有型のトークンでもよい。
マイクロ・ゲートウェイまたは決定点により各リクエストに付与される内部認可トークンのスコープは慎重に制御すべきである。たとえばトランザクション要求では、内部認可トークンのスコープは、そのトランザクションにアクセスしなければならない API エンドポイントにのみ限定すべきである。
API ゲートウェイを活用して、すべての下流マイクロサービスに対する認証およびアクセス制御の執行を集約できる。これにより、個々のサービスごとに認証とアクセス制御を提供する必要がなくなる。この設計を選択する場合、ネットワーク上で適切に配置された任意のコンポーネントが、API ゲートウェイとその保護を迂回してサービスに匿名接続できてしまう。これを防ぐため、相互認証のような緩和策を活用して、サービスへの直接的かつ匿名の接続を防止すべきである。

4.2 サービス・ディスカバリ機構の戦略

最適な性能および負荷分散の理由から、マイクロサービスはエンタープライズまたはクラウド・インフラ内のどこにでも複製・配置される必要があるかもしれない。言い換えると、サービスは頻繁に追加・削除され、任意のネットワーク位置に動的に割り当てられ得る。したがって、マイクロサービス型アプリケーション・アーキテクチャにおいては、通常サービス・レジストリを用いて実装されるサービス・ディスカバリ機構を備えることが不可避である。サービス・レジストリ・サービスは、オンラインになりつつあるマイクロサービスが自身の位置情報を公開する（サービス登録と呼ばれる）ために用いられ、また登録済みサービスを探索しようとするマイクロサービスにも用いられる。ゆえに、サービス・レジストリは機密性、完全性、可用性の観点から構成されなければならない。

サービス指向アーキテクチャ（SOA）では、サービス・ディスカバリは集中型のエンタープライズ・サービス・バス（ESB）の一部として実装される。しかし、マイクロサービス・アーキテクチャ（ビジネス機能がコンテナ内のサービスとしてパッケージ化・デプロイされ、API 呼び出しを用いて相互に通信する）では、セクション 2.5 で述べた 3 つの相互作用スタイルすべてを実装できる軽量メッセージ・バスを実装する必要がある。さらに、サービス・レジストリ・サービスの実装方法には 2 つの次元がある：(a) クライアントがサービス・レジストリ・サービスにアクセスする方式、(b) 集中型か分散型か、である。クライアントがサービス・レジストリ・サービスにアクセスする主な方法は 2 つある：クライアント側ディスカバリ・パターンとサーバ側ディスカバリ・パターン [9]。

クライアント側サービス・ディスカバリ・パターンの分析

クライアント側の選択肢は、レジストリ認識クライアントを構築することから成る。クライアントは、リクエストを行うのに必要なすべてのサービスの位置をサービス・レジストリに問い合わせる。その後、ターゲット・サービスに直接連絡する。単純ではあるが、このサービス・ディスカバリの実装オプションでは、ディスカバリのロジック（サービス・レジストリへの問い合わせ）を、クライアント実装に使用される各プログラミング言語やフレームワークごとに実装する必要がある。

サービス側サービス・ディスカバリ・パターンの分析

サービス側ディスカバリには 2 つの実装がある：1 つは、固定位置に設定された専用のルータ・サービスにディスカバリのロジックを委譲するパターン、もう 1 つは、各マイクロサービスの前段に、動的な DNS リゾルバ（Domain Name System Security Extensions（DNSSSEC）権威サーバと連携する）としての機能を持つサーバを置くパターンである。専用ルータ方式では、クライアントはすべてのサービス・リクエストをこの専用ルータ・サービスに送信し、ルータはサービス・レジストリにクライアント要求サービスの位置を問い合わせ、その場所へリクエストを転送する。これにより、アプリケーション・サービスとサービス・レジストリ・サービスのようなインフラ・サービスとの間の強い結合が取り除かれる。DNS リゾルバ・パターンでは、各マイクロサービスが、内蔵の DNS リゾルバを用いてサービス・レジストリを問い合わせ、自身のサービス・ディスカバリを完了する。DNS リゾルバは、利用可能なサービス・インスタンスとそのエンドポイント位置（すなわち IP アドレス）のテーブルを保持する。テーブルを最新に保つため、非同期かつノンブロッキングの DNS リゾルバは、サービス・ディスカバリのために DNS サービス・レコード（例：SRV RR（Service Resource Record））を用いて、数秒ごとにサービス・レジストリへ定期的に問い合わせる。DNS リゾルバによるサービス・ディスカバリ機能はバックグラウンド・タスクとして動作するため、あるサービス・インスタンスが別のサービスへリクエストする必要が生じたとき、すべてのピア・マイクロサービスのエンドポイント（URL）が即座に利用可能である [2]。

良い戦略は、サービス側サービス・ディスカバリ・パターンとクライアント側サービス・ディスカバリ・パターンの組み合わせを用いることである [9]。前者はすべての公開 API へのアクセス提供に用いることができ、後者はクライアントがクラスター内部のすべての相互作用にアクセスできるようにする。

集中型対分散型サービス・レジストリ

集中型サービス・レジストリの実装では、公開を希望するすべてのサービスが単一点で登録を行い、これらのサービスを求めるすべてのサービスは単一のレジストリを用いてそれらを発見する。このパターンのセキュリティ上の不利は単一点障害（SPOF）である [13]。しかし、データ一貫性は問題とならない。分散型サービス・レジストリでは、複数のサービス・レジストリ・インスタンスが存在し、サービスは任意のインスタンスに登録できる。短期的には、不利な点は各サービス・レジストリ間でデータ不整合が生じることである。最終的には、あるインスタンスから他のすべてへブロードキャストするか、ピギーバッギングと呼ばれるプロセスで添付データを介して 1 つのノードから他のすべてへ伝搬することにより、これら複数のサービス・レジストリ・インスタンス間で整合性が達成される。

サービス・ディスカバリにどのパターンを用いる場合であっても、サービス・ディスカバリ機能の安全なデプロイメントは、以下のサービス・レジストリ構成要件を満たすべきである。

サービス・レジストリ構成のためのセキュリティ戦略（MS-SS-3）

サービス・レジストリの能力は、専用サーバ、またはサービス・メッシュ・アーキテクチャの一部をなすサーバによって提供されるべきである。
サービス・レジストリ・サービスは、その可用性と回復力（レジリエンス）を確保するため、特定の QoS（Quality of Service）パラメータで構成されたネットワーク内に置かれるべきである。
アプリケーション・サービスとサービス・レジストリ間の通信は、HTTPS や TLS（Transport Layer Security）といった安全な通信プロトコルを通じて行われるべきである。
サービス・レジストリは、正当なサービスのみが登録、更新（リフレッシュ）操作、およびサービス発見のためのデータベース照会を実行していることを保証するための検証チェックを備えるべきである。
サービス登録／登録解除の機能については、マイクロサービスの境界づけられたコンテキスト（bounded context）と疎結合の原則を遵守すべきである。言い換えると、アプリケーション・サービスは、サービス・レジストリ・サービスのようなインフラ・サービスと強く結合すべきではなく、サービスの自己登録／自己登録解除パターンは避けるべきである。アプリケーション・サービスがクラッシュしたり、稼働していてもリクエストを処理できない場合、そのサービスが登録解除を実行できないことは、プロセス全体の完全性に影響する。したがって、アプリケーション・サービスの登録／登録解除は第三者登録パターンを用いて有効化されるべきであり、アプリケーション・サービスはクライアント側ディスカバリ・パターンで述べたとおり、サービス位置情報の取得のためにサービス・レジストリを照会することに限定されるべきである。
第三者登録パターンを実装する場合、登録／登録解除は、アプリケーション・サービスに対するヘルス・チェックが実行された後にのみ行われるべきである。
大規模なマイクロサービス・アプリケーションには分散型サービス・レジストリをデプロイし、複数のサービス・レジストリ・インスタンス間のデータ一貫性維持に注意を払うべきである。

4.3 安全な通信プロトコルの戦略

クライアントとサービス間（ノース・サウス・トラフィック）、およびサービス間（イースト・ウエスト・トラフィック）の安全な通信は、マイクロサービス型アプリケーションの運用にとって極めて重要である。

ただし、認証や安全な接続の確立といった特定のセキュリティ・サービスの戦略は、個々のマイクロサービス・ノードで扱うこともできる。例えばファブリック・モデルでは、各マイクロサービス・インスタンスが SSL クライアントおよび SSL サーバ（すなわち各マイクロサービスが SSL/TLS エンドポイント）として機能する能力を持つ。したがって、アプリケーション全体の観点から、サービス間またはプロセス間通信に対して安全な SSL/TLS 接続が可能である。これらの接続は動的に（すなわち各サービス間リクエストの前に）作成することも、キープアライブ接続として作成することもできる。キープアライブ接続方式では、「サービス A」のインスタンスが「サービス B」のインスタンスに対して最初にリクエストを行うとき、完全な SSL/TLS ハンドシェイクの後に接続を作成する。しかし、サービス B からそのリクエストに対する応答が戻っても、いずれのサービス・インスタンスも接続を終了しない。むしろ、将来のリクエストで同じ接続が再利用される。この方式の利点は、初回の SSL/TLS ハンドシェイクに伴う高コストのオーバーヘッドを各リクエストごとに回避でき、既存の接続をその後の数千のサービス間リクエストで再利用できることである。こうして、すべてのリクエストのインスタンスに対して恒常的な安全なサービス間ネットワーク接続が利用可能となる。

安全な通信のためのセキュリティ戦略（MS-SS-4）

クライアントはターゲット・サービスを直接呼び出すようには構成せず、単一のゲートウェイ URL を指すように構成すべきである。
クライアントから API ゲートウェイへの通信、ならびにサービス間通信は、相互認証の後に実施され、暗号化されるべきである（例：mTLS（mutual TLS）プロトコルを使用）。
頻繁に相互作用するサービスは、キープアライブの TLS 接続を作成すべきである。

4.4 セキュリティ・モニタリングの戦略

（負荷分散のための複製を含む）サーバ上で稼働するモノリシック・アプリケーションのモニタリングと比べ、マイクロサービス型システムでは、多数のサービスを、それぞれ異なるサーバ上で、かつ異種のアプリケーション・プラットフォーム上で稼働している可能性がある中で監視しなければならない。さらに、システム内の意味のあるトランザクションは、少なくとも 2 つ以上のサービスを関与させる。

セキュリティ・モニタリングのためのセキュリティ戦略（MS-SS-5）

セキュリティ・モニタリングは、ゲートウェイとサービスの双方のレベルで実施し、不適切な挙動（例：ベアラー・トークンの再利用攻撃、インジェクション攻撃）を検出・警告・対応すべきである。さらに、入力検証エラーや過剰パラメータのエラー、クラッシュやコアダンプはログに記録しなければならない。これを実現できるソフトウェアの一つに、Open Web Application Security Project（OWASP）の AppSensor があり、ゲートウェイ、サービス・メッシュ、マイクロサービス自体に実装し得る。
中央ダッシュボードは、各種サービスおよびそれらを結ぶネットワーク・セグメントのステータスを表示する。最低限、ダッシュボードは、入力検証の失敗や予期しないパラメータなど、インジェクション攻撃の試行を示す明白な兆候となるセキュリティ・パラメータを表示すべきである。
ビジネス・ロジックの決定結果、接触（コンタクト）の試行、その他の挙動に関する、正常で侵害されていない状態のベースラインを作成すべきである。IDS（Intrusion Detection System）ノードの配置と能力は、このベースラインからの逸脱を検出できるようなものとすべきである。

4.5 可用性／レジリエンス向上の戦略

マイクロサービス型アプリケーションでは、アプリケーションの全体的なセキュリティ・プロファイルを強化するため、特定の重要なサービスの可用性またはレジリエンスを高めることを狙った取り組みが必要となる。一般的に導入される技術には以下が含まれる。

サーキット・ブレーカ機能、
負荷分散、
レート制限（スロットリング）。

4.5.1 サーキット・ブレーカ実装オプションの分析

連鎖的障害を防止または最小化するための一般的戦略は、サーキット・ブレーカを用いることであり、これは指定された閾値を超えて故障しているコンポーネント（マイクロサービス）へのデータ配送を禁止するものである。これは「速やかな失敗（fail fast）」の原則としても知られる。不具合のあるサービスが速やかにオフラインにされるため、連鎖的障害の発生は最小化され、その間に不具合コンポーネントのログが分析され、必要な修正が施され、マイクロサービスが更新される。サーキット・ブレーカのデプロイには 3 つの選択肢がある [9]：クライアントの内部、サービス側、クライアントとサービスの間に位置するプロキシ。

クライアント側サーキット・ブレーカの選択肢：この選択肢では、各クライアントは、クライアントが呼び出す各外部サービスごとに個別のサーキット・ブレーカを持つ。クライアント内のサーキット・ブレーカが、あるサービスへの呼び出しを停止（そのサービスに関して「オープン状態」）すると決定した場合、そのサービスへのメッセージは送信されず、その後のネットワークの通信トラフィックが削減される。さらに、サーキット・ブレーカの機能をマイクロサービスに実装する必要がないため、当該サービスの効率的な実装のために貴重なリソースが解放される。しかし、クライアントにサーキット・ブレーカを配置することは、セキュリティの観点から 2 つの不利を伴う。第一に、サーキット・ブレーカのコードが正しく実行されることについて、クライアントに大きな信頼を置かなければならない。第二に、そのサービスの利用不能の認識がクライアントに極めてローカルであり、そのクライアントからサービスへの呼び出し頻度に基づいて決定されるため、全体の運用の完全性がリスクにさらされる。これは、当該サービスに対するすべてのクライアントからの応答状況を組み合わせた全体像ではないからである。

サーバ側サーキット・ブレーカの選択肢：この選択肢では、マイクロサービス内部のサーキット・ブレーカが、すべてのクライアント呼び出しを処理し、当該呼び出しを許可すべきか否かを決定する。この選択肢のセキュリティ上の利点は、クライアントがサーキット・ブレーカ機能を実装する必要がないこと、そしてサービスがすべてのクライアントからの呼び出し頻度の全体像を把握しているため、処理可能なレベルまでリクエストをスロットルできる（例：一時的に負荷を軽減する）ことである。

プロキシ・サーキット・ブレーカの選択肢：この選択肢では、サーキット・ブレーカは、クライアントとマイクロサービスの間に位置し、すべての入出力メッセージを取り扱うプロキシ・サービスにデプロイされる。この中には 2 つの選択肢があり得る：各ターゲット・マイクロサービスごとに 1 つのプロキシを置くか、複数サービス向けに単一のプロキシ（通常は API ゲートウェイ内に実装され、プロキシ内部にクライアント側およびサービス側サーキット・ブレーカ双方を含む）を用いるかである。この選択肢のセキュリティ上の利点は、クライアント・コードやサービス・コードのいずれも変更する必要がないことであり、これにより、両者のコードおよびサーキット・ブレーカ機能に関連する信頼性と完全性保証の問題を回避できる点である。この選択肢はまた、故障しているサービスに対してクライアントをよりレジリエントにし、単一のクライアントが過剰なリクエストを送るケースからサービスを保護する（結果として、そのサービスを利用する他のクライアントに何らかのサービス拒否を招く）といった追加の保護も提供する [9]。

サーキット・ブレーカ実装のためのセキュリティ戦略（MS-SS-6）

信頼されたコンポーネントをプロキシに限定するため、プロキシ・サーキット・ブレーカの選択肢をデプロイすべきである。これにより、複数のコンポーネントにまたがる閾値設定や閾値に基づく要求遮断といった信頼を、クライアントやマイクロサービスに置く必要がなくなる。

4.5.2 負荷分散の戦略

負荷分散は、すべてのマイクロサービス型アプリケーションにおける不可欠な機能モジュールであり、その主目的はサービスへの負荷を分配することである。サービス名は、同一のサービスの複数インスタンスをサポートする名前空間に関連付けられる。言い換えると、同一サービスの多くのインスタンスが同じ名前空間を使用する [13]。サービス負荷を均衡化するため、ロード・バランサは、リクエストの名前空間内で、ラウンドロビン（サービス・インスタンスへの割当てを環状に行う）などのアルゴリズムを用いて、1 つのサービス・インスタンスを選択する。

負荷分散のためのセキュリティ戦略（MS-SS-7）

負荷分散機能を支えるすべてのプログラムは、個々のサービス・リクエストから分離（デカップル）されるべきである。例えば、ロード・バランシング・プールを決定するためのサービスに対するヘルス・チェックを実行するプログラムは、バックグラウンドで非同期に動作すべきである。
ロード・バランサとマイクロサービス・プラットフォーム間のネットワーク接続は保護しなければならない。
ソース・マイクロサービスの前段に DNS リゾルバを配置して、利用可能なターゲット・マイクロサービス・インスタンスのテーブルを提供する場合、ヘルス・チェック・プログラムと連携して、呼び出し側マイクロサービスに単一のリストを提示するようにすべきである。

4.5.3 レート制限（スロットリング）

レート制限の主目的は、可用性に影響を及ぼすようなサービスの過剰利用を防ぐことである。すなわち、あるクライアントがリクエストのレートを増加させた場合でも、サービスは他のクライアントへの応答を継続する。これは、一定の時間窓内にクライアントがサービスを呼び出せる頻度の上限を設定することで達成される。上限を超えた場合、クライアントは、アプリケーション関連の応答ではなく、許容レートを超過した旨の通知と、上限値および上限カウンタがリセットされ、リクエスト元が応答を再開できる時刻に関する追加データを受け取る。レート制限の副次的目的は、サービス拒否（DoS）攻撃の影響を軽減することである。レート制限の概念に密接に関連するのが、クォータ管理または条件付きレート制限であり、上限がインフラの制約や要件ではなく、アプリケーション要件に基づいて決定される。

レート制限のためのセキュリティ戦略（MS-SS-8）

アプリケーション利用に対するクォータや上限は、インフラ関連とアプリケーション関連の両方の要件に基づくべきである。
上限は、明確に定義された API 利用プランに基づいて決定すべきである。
高いセキュリティを要するマイクロサービスでは、リプレイ検出を実装しなければならない。リスクに基づき、この機能は 100%の検出、またはランダム検出に設定できる。

4.6 完全性（インテグリティ）保証の戦略

マイクロサービス型アプリケーションの文脈における完全性保証の要件は、2 つの状況で生じる。

マイクロサービスの新バージョンがシステムに導入されるとき。
トランザクション中のセッション永続性を支援するため。

監視された新リリースの導入：マイクロサービスの新しいバージョンがリリースされる場合、その導入は段階的なプロセスでなければならない。なぜなら、(a) すべてのクライアントが新バージョンを使用する準備ができているとは限らず、(b) 広範なテストにもかかわらず、あらゆるシナリオやユースケースにおける新バージョンの挙動が、ビジネス・プロセスの期待に合致しない可能性があるからである。この状況に対処するため、カナリア・リリースと呼ばれる手法がよく採用される [4]。この手法では、新バージョンがオンラインになった後、限られた数のリクエストのみが新バージョンにルーティングされ、残りは現行の運用バージョンにルーティングされる。観察期間を経て、新バージョンが性能および完全性のメトリクスを満たしていることに確信が得られたなら、すべてのリクエストが新バージョンにルーティングされる。

マイクロサービス新バージョン導入のためのセキュリティ（完全性保証）戦略（MS-SS-9）

既存バージョンと新バージョンの双方へのトラフィックは、API ゲートウェイのような中央ノードを経由させ、ブルー／グリーン移行が統制された方法で行われること、ならびにカナリア・リリースに伴うリスクが監視されるようにすべきである。セキュリティ・モニタリングは、既存版と新規版の両方をホストするノードを対象とすべきである。
既存バージョンの利用状況の監視に基づき、新バージョンへのトラフィックを着実に増やしていくべきである。
新バージョンの性能および機能的正しさは、新バージョンへのトラフィックを増やす際の考慮要素であるべきである。
カナリア・リリース手法を設計する際には、（既存版か新規版かという）クライアントのバージョン選好も考慮に入れるべきである。

セッション永続性：クライアントは、特定のサービスに対して複数のリクエストを通じて完全なトランザクションを実行するため、クライアント・セッション内のすべてのリクエストを同一の上流マイクロサービス・インスタンスへ送ることが極めて重要であり、そのセッションにおける全リクエストのターゲットは同じ上流サービス・インスタンスでなければならない。この要件はセッション永続性と呼ばれる。この要件が破られ得る状況としては、マイクロサービスが状態をローカルに保存し、個々のリクエストを処理するロード・バランサが、進行中のユーザ・セッションからのリクエストを別のマイクロサービス・サーバまたはインスタンスへ転送してしまう場合がある。セッション永続性を実装する方法の 1 つがスティッキー・クッキーである。この方法では、上流マイクロサービス群から特定クライアントへの最初の応答に、当該応答を生成したサーバを（エンコードされた形で）識別するセッション・クッキーを付加する仕組みがある。以降のクライアントからのリクエストにはクッキー値が含まれ、同一の仕組みにより、その値を用いて同じ上流サーバにリクエストをルーティングする [16]。

セッション永続性処理のためのセキュリティ（完全性保証）戦略（MS-SS-10）

クライアントのセッション情報は安全に保存しなければならない。
バインド先サーバ情報の伝達に用いるアーティファクトは保護しなければならない。
内部認可トークンをユーザに返してはならず、またユーザのセッション・トークンを、ポリシー決定のためにゲートウェイの先へ渡してはならない。

4.7 インターネットを介した攻撃への対抗

ボットネットを含むあらゆるタイプのインターネットを介した攻撃から完全に保護することは不可能であるが、マイクロサービスの API には、クレデンシャル詰め込み（credential stuffing）およびクレデンシャル濫用攻撃に対する検出・防止能力、ならびに悪意あるボットネットを検出する能力を備えさせなければならない。これは、各マイクロサービスが独立して呼び出し可能であり、それぞれが自身のクレデンシャル集合を持つようなアプリケーションにおいて、特に重要である。クレデンシャル濫用攻撃は、オフラインの脅威分析またはランタイムのソリューションを用いて検出できる [17]。ボットネット攻撃の検出は、専用のボット・マネージャ製品、または Web アプリケーション・ファイアウォール（WAF）の追加機能として提供される。

クレデンシャル濫用および詰め込み攻撃を防止するためのセキュリティ戦略（MS-SS-11）

クレデンシャル濫用に対するランタイムの防止戦略は、オフラインの戦略よりも望ましい。所定の時間間隔における所定の場所（例：IP アドレス）からのログイン試行回数の閾値を設定し、閾値が超過された場合には、認証／認可サーバが予防措置を起動しなければならない。ベアラー・トークンが用いられる際には、この機能はトークンの再利用を検出し、予防を強制するために必須である。
クレデンシャル詰め込み検出ソリューションは、ユーザのログインを盗まれたクレデンシャル・データベースと照合し、正当なユーザにクレデンシャルが盗まれたことを警告する能力を持つ。
IDS および境界デバイスを構成して、(a) サービスがアクセス不能となる前に DoS 攻撃を検出して警報を発すること、(b) 分散型ネットワーク・プローブを検出すること、を可能にすべきである。
サービス・ホストを構成して、ファイルのアップロードや、各コンテナのメモリおよびファイル・システムの内容をスキャンし、常駐マルウェアの脅威を検出するようにする。

5 マイクロサービスにおけるアーキテクチャ・フレームワークのセキュリティ戦略

本書でマイクロサービス型アプリケーション・システムに関して検討する主要なアーキテクチャ・フレームワークは、API ゲートウェイとサービス・メッシュである。API ゲートウェイの実装における主要なセキュリティ上の考慮事項は、適切なホスティング・プラットフォームの選択、エンタープライズ全体の認証・認可フレームワークとの適切な統合と構成、そしてゲートウェイを通過するトラフィックを安全に活用してセキュリティ監視と分析を行うことである。

API ゲートウェイ実装のためのセキュリティ戦略（MS-SS-12）

API を有効化する前にクレデンシャルをプロビジョニングできるよう、API ゲートウェイをアイデンティティ管理アプリケーションと統合する。
アイデンティティ管理が API ゲートウェイ経由で呼び出される場合、IdP（Identity Provider）と統合するためのコネクタを提供する。
API ゲートウェイは、クライアント・リクエスト向けのアクセス・トークンを生成できるアーティファクト（例：OAuth 2.0 認可サーバ）へのコネクタを備えるべきである。
すべてのトラフィック情報を、安全に監視／分析アプリケーションへチャネルし、攻撃（例：サービス拒否、悪意ある行為）を検出し、性能劣化の原因を明らかにする。
分散ゲートウェイのデプロイ（または、すべてのクライアント・アクセスを受ける初期ゲートウェイと、マイクロサービスに近いマイクロ・ゲートウェイの組み合わせ）では、ゲートウェイ間にトークン変換（交換）サービス [18] を設けるべきである。初期ゲートウェイに提示されるトークンは広いスコープの許可を持つべきである一方で、内部のゲートウェイ（またはマイクロ・ゲートウェイ）に提示されるトークンは、対象のマイクロサービス・プラットフォームに適した、より狭いスコープの特定権限、または全く別種のトークン型であるべきである。これは最小権限（least privilege）パラダイムの実装に資する。

サービス・メッシュを実装することは、各種セキュリティ・ポリシーに関連する適切な構成パラメータがコントロール・プレーンで正しく定義され、ポリシーの意図が満たされるようにし、かつサービス・メッシュ自体が新たな脆弱性を導入しないようにするうえで役立つ。

サービス・メッシュ実装のためのセキュリティ戦略（MS-SS-13）

サービスの組同士に特定の通信プロトコルを指定し、アプリケーション要件に基づいてサービスの組同士のトラフィック負荷を指定できるよう、ポリシーをサポートする。
既定の構成では、常にすべてのサービスに対してアクセス制御ポリシーを有効化しておく。
権限昇格につながり得る構成（例：サービス・ロールの権限や、サービス・ロールをサービス・ユーザ・アカウントへバインドすること）は避ける。
サービス・メッシュのデプロイでは、各コンポーネントのリソース使用上限を指定できる構成機能を備えるべきである。この機能がないと、当該コンポーネントがマイクロサービス全体のレジリエンスと可用性に影響を与える可能性が生じる。
サービス・メッシュのデプロイでは、要求メトリクスを含む環境メトリクスを収集し、監視のために集中サービスへ送信できる構成機能を備えるべきである。ポリシーは、高可用性とレジリエンスを確保するため、マルチクラスタのマイクロサービス環境において単一のサービス・メッシュか、（それぞれ独自のコントロール・プレーンを持つ）複数のサービス・メッシュかを指定できるようにすべきである。
高度に機微なマイクロサービス型アプリケーションにおいては、サービス・メッシュ層全体で達成されるレイヤ 5 のネットワーク分割を補完するため、オーケストレータ・プラットフォーム内でレイヤ 3 のネットワーク分割を構成しなければならない。これは、サービス・メッシュがファイアウォールやトラフィック遮断に用いるサイドカー・プロキシを、攻撃者が回避または迂回する脅威に対する対策である。

付録 A — モノリシック・アプリケーションとマイクロサービス型アプリケーションの相違

A.1 設計とデプロイメントの相違

概念的には、モノリシックなアプリケーション・アーキテクチャでは、全体としてデプロイしなければならない巨大なアーティファクトを 1 つ生成する。一方、マイクロサービス型アプリケーションは、サービスまたはマイクロサービスと呼ばれる、自己完結し疎結合な複数の実行可能ファイルを含む。個々のサービスは独立にデプロイ可能である。モノリシック・アプリケーションでは、アプリケーション全体のある機能に変更を加える場合、再度デプロイする前に、アプリケーション全体の再コンパイルや（場合によっては）再テストが必要となる。しかしマイクロサービスの場合、独立性により、あるサービスの変更が他のサービスの機能に論理的な影響を与えないため、該当するサービスのみを変更して再デプロイすればよい。モノリシック・アプリケーションでは、ユーザ数の増加や利用頻度の上昇によるワークロード増加に対応するには、アプリケーション全体にリソースを割り当てる必要があるのに対し、マイクロサービスでは、性能が望ましい水準に満たないサービスに選択的にリソース増強を適用でき、スケーラビリティの取り組みに柔軟性を提供する。

一部のモノリシック・アプリケーションはモジュール式に構築されていても、意味的または論理的なモジュール性を持たない場合がある。モジュール式構築とは、多数のコンポーネントやライブラリからアプリケーションが構築されることを指し、それらは異なるベンダから提供されることがあり、一部のコンポーネント（例：データベース）はネットワーク越しに分散配置されている場合がある [13]。このようなモノリシック・アプリケーションでは、API の設計と仕様がマイクロサービス・アーキテクチャの場合と類似していることがある。しかし、そのような古典的モジュール設計のモノリシック・アプリケーションとマイクロサービス型アプリケーションの違いは、後者では個々の API がネットワークに公開され、したがって独立に呼び出し可能で再利用可能である点にある。

モノリシックとマイクロサービス型アプリケーションの違いは表 3 に要約する。

表 3：モノリシックとマイクロサービス型アプリケーションの論理的相違

モノリシック・アプリケーション	マイクロサービス型アプリケーション
全体としてデプロイしなければならない。	サービスの独立または選択的なデプロイが可能。
アプリケーションの一部の小さな変更でも、アプリケーション全体の再デプロイが必要。	変更されたサービスのみを再デプロイすればよい。
スケーラビリティは、アプリケーション全体へのリソース割当てを伴う。	各個別サービスに対して、より多くのリソースを割り当て、選択的にスケールアップできる。
API 呼び出しはローカル。	ネットワークに公開された API により、独立した呼び出しと再利用が可能。

A.1.1 設計とデプロイメントの相違を例示するアプリケーション

以下の小規模なオンライン・ショッピング・アプリケーションの例は、上述の設計とデプロイメントの相違を示す。このアプリケーションの主な機能は次のとおりである。

小売業者が提供する製品カタログを、製品画像、製品番号、製品名、単価とともに表示するモジュール。
顧客（例：氏名、住所）および注文の詳細（例：カタログからの製品名、数量、単価）を収集し、そのセッションで注文されたすべての品目を含むバスケットを作成する、顧客注文を処理するモジュール。
出荷のための注文を準備するモジュール。総合船積み明細（すなわち、出荷対象の合計パッケージ、注文内の各品目の数量、出荷の希望、出荷先住所）を指定する。
顧客への請求書を発行するモジュール。クレジットカードまたは銀行口座による支払い機能を内蔵する。

このオンライン・ショッピング・アプリケーションをモノリシックとマイクロサービス型として設計した場合の相違は表 4 に示す。モノリシックおよびマイクロサービス・アーキテクチャにおける本アプリケーションの模式図は、それぞれ図 1 と図 2 に示す。

表 4：モノリシックとマイクロサービス型におけるアプリケーション構成の相違

アプリケーション構成	モノリス	マイクロサービス型
機能モジュール間の通信	すべての通信は手続き呼び出し、または何らかの内部データ構造（例：ソケット）の形で行われる。注文処理を担当するモジュールは、出荷機能を担当するモジュールに手続き呼び出しを行い、完了を待つ（ブロッキング型の同期通信）。	出荷機能と注文処理機能は、それぞれ独立したサービスとして設計される。通信は、Web プロトコルを用いるネットワーク越しの API 呼び出しとして行われる。注文処理マイクロサービスは、(a) 出荷マイクロサービスにリクエスト・レスポンス呼び出しを行い、応答を待つか、(b) 出荷対象の注文の詳細をメッセージ・キューに投入し、そのイベントを購読している出荷マイクロサービスが非同期に取り出す、のいずれかを選択できる。
変更や拡張の扱い（例：請求モジュールをデビットカード受け付けに対応させる変更）	必要な変更を行った後、アプリケーション全体を再コンパイルし、再デプロイしなければならない。	請求機能は独立したマイクロサービスとして設計されるため、そのサービスのみを再コンパイルし、再デプロイすればよい。
アプリケーションのスケーリング、リソース増強の割当て（例：注文処理モジュールに、より大きな負荷に対応するための追加リソースが必要）	注文処理機能は、出荷や請求機能に比べてトランザクション時間が長い。メモリや CPU の多いサーバを用いる垂直スケーリングを、アプリケーション全体に対して適用しなければならない。	注文処理マイクロサービスがデプロイされているハードウェアに、増強リソースを割り当てるだけで足りる。また、ロード・バランシングを改善するために、注文処理マイクロサービスのインスタンス数を増やすこともできる。
開発とデプロイメントの戦略	開発は開発チームが担当し、必要な QA チームによるテストの後、デプロイメントのタスクを、デプロイのための適切なリソース割当てを監督するインフラ・チームへ引き渡す。	各マイクロサービスについては、比較的小さな単一機能のモジュールであり、その機能に最適化された組み込みプラットフォーム（例：OS、言語、ライブラリ）を持つため、開発からデプロイまでの全ライフサイクルを単一の DevOps チームが担当する。

A.2 実行時の相違

モノリシック・アプリケーションは単一の計算ノードとして実行され、そのノードはシステム全体またはアプリケーションの状態を把握している。マイクロサービス環境では、アプリケーションはサービスを提供する複数ノードの集合として設計される。各ノードは他ノードと調整する必要なく動作するため、個々のノードにはシステム全体の状態は不明である。グローバルな情報やグローバル変数の値が存在しない場合、個々のノードはローカルに利用可能な情報に基づいて意思決定を行う。ノードの独立性は、1 つのノードの故障が他のノードに影響しないことを意味する。サービスがデータベース接続やデータ・リポジトリを共有することがあるモノリシック・アプリケーションとは異なり、マイクロサービス・アーキテクチャでは、各サービスが自身のデータ・リポジトリを持つパターンを採用する場合がある。多くの状況で、サービス間の相互作用には分散トランザクションが必要となることがあり、適切に設計されていないとデータベースの完全性に影響を及ぼし得る。

モノリシックとマイクロサービス・アプリケーションの実行時の相違と、その含意は表 5 に要約する。

表 5：モノリシックとマイクロサービス型アプリケーションのアーキテクチャ上の相違

モノリシック・アプリケーション	マイクロサービス型アプリケーション
単一の計算ノードとして実行され、全体状態の情報を完全に把握している。	複数ノードの集合として設計され、各ノードがサービスを提供する。全体システム状態は個々のノードには不明である。
グローバル情報やグローバル変数の値を活用するよう設計されている。	個々のノードは、ローカルに利用可能な情報に基づいて意思決定を行う。
ノードの障害はアプリケーションのクラッシュを意味する。	1 つのノードの障害は他のノードに影響すべきでない。

図 1：オンライン・ショッピング・アプリケーション — モノリシック・アーキテクチャ

図 2：オンライン・ショッピング・アプリケーション — マイクロサービス・アーキテクチャ

付録 B — セキュリティ戦略とマイクロサービスのアーキテクチャ機能とのトレーサビリティ

セクション 4 と 5 で論じたすべてのセキュリティ戦略（合計 13）は、表 6 に、各戦略が関連するマイクロサービスの中核機能またはアーキテクチャ・フレームワークと併せて一覧する。

表 6：マイクロサービスのためのセキュリティ戦略

セキュリティ戦略 ID	セキュリティ戦略	中核機能／アーキテクチャ・フレームワーク
MS-SS-1	・機微なデータにアクセスするマイクロサービス API に対する認証は、単に API キーを用いるだけで行ってはならない。そのような API へのアクセスには、デジタル署名された認証トークン（例：クライアント・クレデンシャル・グラント）か、信頼できる情報源で検証されるトークンが必要である。加えて、一部のサービスでは、侵害されたトークンが引き起こし得る損害を限定するため、ワンタイム・トークンまたは短命トークン（短時間で失効するトークン）が必要となる場合がある。・認証トークンは、ハンドル・ベース、暗号学的に署名されたもの、または HMAC 方式で保護されたものであるべきである。・アプリケーションで使用されるすべての API キーには、当該キーを使用できるアプリケーション（例：モバイル・アプリ、IP アドレス）および API セットの双方に対する利用制限を指定すべきである。・各 API キーの機能に対する制限範囲は、身元証明が提供する保証レベル（機械駆動か人手によるかを問わず）に見合ったものでなければならない。・無状態の認証トークン（例：JWT）を、マイクロサービスに関連付けられた共有ライブラリによって用いる場合、以下の注意事項を遵守すること：(a) トークンの有効期限は可能な限り短くすること（有効期限がセッション継続時間を決定し、アクティブ・セッションは失効させられないため）、(b) トークンの秘密鍵をライブラリ・コードの一部としてはならず、環境変数で表現される動的変数、または環境データ・ファイルに指定すること。鍵の値はデータ・ボールトに保管すること。・OAuth や OpenID Connect といった標準に基づく手法を実装する場合は、安全にデプロイしなければならない [19]。	認証
MS-SS-2	・すべての API とそのリソースに対するアクセス・ポリシーは定義され、アクセス・サーバにプロビジョニングされるべきである。粗い粒度のポリシー（例：「所与のアドレス可能な機能集合に対する呼び出しを許可する」）は初期の API ゲートウェイで定義・強制され、より細かい粒度（例：特定マイクロサービスのビジネス・ロジック領域に関するもの）の認可は、マイクロサービスの位置に近い場所（例：マイクロ・ゲートウェイ）または場合によりマイクロサービス自体で定義・強制されるべきである。・キャッシュ機構：マイクロサービスがポリシー・データをキャッシュすることを許容してもよいが、このキャッシュはアクセス・サーバが利用不能のときにのみ信頼すべきであり、環境／インフラにふさわしい期間で期限切れとなるべきである。・アクセス・サーバは微粒度のポリシーをサポートできなければならない。・アクセス・サーバからのアクセス決定は、プラットフォームに中立的な形式でエンコードされた標準化トークン（例：JSON 形式の OAuth 2.0 トークン）を通じて、個々および複数のマイクロサービスへ伝達されるべきである。トークンはハンドル・ベースでもアサーション保有型でもよい。・マイクロ・ゲートウェイまたは決定点により各リクエストに付与される内部認可トークンのスコープは慎重に制御すべきである（例：トランザクション要求では、必要な API エンドポイントのみに限定）。・API ゲートウェイを活用して、下流のすべてのマイクロサービスに対する認証・アクセス制御の執行を集約できる。この設計を選ぶ場合、ネットワーク上の適切に配置されたコンポーネントが API ゲートウェイとその保護を迂回してサービスへ匿名接続できてしまうため、相互認証などの緩和策を用いて直接かつ匿名の接続を防止すべきである。	アクセス管理
MS-SS-3	・サービス・レジストリの機能は、専用サーバまたはサービス・メッシュ・アーキテクチャの一部をなすサーバによって提供されるべきである。・サービス・レジストリ・サービスは、可用性とレジリエンスを確保するため、特定の QoS パラメータで構成されたネットワーク内に置かれるべきである。・アプリケーション・サービスとサービス・レジストリ間の通信は、HTTPS/TLS といった安全な通信プロトコルで行うべきである。・サービス・レジストリは、正当なサービスのみが登録・更新操作やサービス発見のための DB 照会を行っていることを保証する検証チェックを持つべきである。・サービス登録／登録解除機能については、境界づけられたコンテキストと疎結合の原則を遵守すべきであり、アプリケーション・サービスはサービス・レジストリのようなインフラ・サービスと強く結合すべきでない。自己登録／自己登録解除パターンは避けるべきである。さらに、アプリケーション・サービスがクラッシュしたり、稼働していてもリクエストを処理できない場合、登録解除を実行できず、プロセス全体の完全性に影響する。したがって、登録／登録解除は第三者登録パターンにより有効化し、アプリケーション・サービスはクライアント側ディスカバリ・パターンで述べたとおり、サービス位置情報の取得のための問い合わせに限定すべきである。・第三者登録パターンを実装する場合、登録／登録解除はヘルス・チェックの後にのみ行うべきである。・大規模なマイクロサービス・アプリケーションには分散型サービス・レジストリをデプロイし、複数インスタンス間のデータ一貫性維持に注意する。	サービス・レジストリ構成
MS-SS-4	・クライアントはターゲット・サービスを直接呼び出すように構成せず、単一のゲートウェイ URL を指すように構成すべきである。・クライアントから API ゲートウェイ、ならびにサービス間通信は、相互認証の後に実施し、暗号化すべきである（例：mTLS）。・頻繁に相互作用するサービスは、キープアライブの TLS 接続を作成すべきである。	安全な通信
MS-SS-5	・セキュリティ・モニタリングはゲートウェイとサービスの双方で実施し、不適切な挙動（例：ベアラー・トークン再利用攻撃、インジェクション攻撃）を検出・警告・対応する。さらに、入力検証エラーや過剰パラメータ・エラー、クラッシュ、コアダンプをログに記録する。これを実現できるソフトウェアの一例が OWASP AppSensor であり、ゲートウェイ、サービス・メッシュ、マイクロサービス自体に実装し得る。・中央ダッシュボードは各サービスおよびそれらを結ぶネットワーク・セグメントの状態を表示する。最低限、入力検証失敗や予期しないパラメータなど、インジェクション攻撃の明白な兆候となるセキュリティ・パラメータを表示すべきである。・ビジネス・ロジックの決定結果、接触試行、その他の挙動に関する、正常で侵害されていない状態のベースラインを作成する。IDS ノードの配置と能力は、このベースラインからの逸脱を検出できるようにすべきである。	セキュリティ・モニタリング
MS-SS-6	・信頼されたコンポーネントをプロキシに限定するため、プロキシ・サーキット・ブレーカをデプロイすべきである。これにより、複数コンポーネントにまたがる閾値設定や遮断判断について、クライアントやマイクロサービスに信頼を置く必要がなくなる。	サーキット・ブレーカ実装
MS-SS-7	・負荷分散機能は個々のサービス・リクエストから分離すべきである（例：負荷分散プールを決定するためのサービスのヘルス・チェック・プログラムはバックグラウンドで非同期に動作させる）。・ロード・バランサとマイクロサービス・プラットフォーム間のネットワーク接続を保護しなければならない。・ソース・マイクロサービスの前段に DNS リゾルバを配置してターゲット・マイクロサービス・インスタンスの表を提供する場合、ヘルス・チェック・プログラムと連携し、呼び出し側に単一のリストを提示するようにする。	負荷分散実装
MS-SS-8	・アプリケーション利用のクォータまたは上限は、インフラ関連およびアプリケーション関連の要件の双方に基づくべきである。・上限は、明確に定義された API 利用プランに基づいて決定すべきである。・高いセキュリティを要するマイクロサービスでは、リプレイ検出を実装しなければならない。リスクに応じて、常時検出またはランダム検出に設定できる。	レート制限（スロットリング）
MS-SS-9	・既存版と新規版の双方へのトラフィックは、API ゲートウェイのような中央ノードを経由させ、ブルー／グリーン移行が統制された方法で行われること、ならびにカナリア・リリースに伴うリスクが監視されるようにする。セキュリティ・モニタリングは、既存版と新規版の双方をホストするノードを対象とする。・既存版の利用状況の監視は、新規版へのトラフィックの「段階的増加」の速度を左右すべきである。・新規版の性能および機能的正しさは、新規版へのトラフィック増加の判断要素であるべきである。・カナリア・リリース手法の設計では、クライアントのバージョン選好（既存版か新規版か）も考慮に入れるべきである。	新バージョン導入
MS-SS-10	・クライアントのセッション情報は安全に保存しなければならない。・バインド先サーバ情報の伝達に用いるアーティファクトは保護しなければならない。・内部認可トークンをユーザに返してはならず、ユーザのセッション・トークンをポリシー決定のためにゲートウェイの先へ渡してはならない。	セッション永続性の扱い
MS-SS-11	・クレデンシャル濫用に対するランタイムの防止戦略は、オフライン戦略より望ましい。所定の時間間隔における所定の場所（例：IP アドレス）からのログイン試行回数に閾値を設け、閾値超過時には認証／認可サーバが予防措置を発動しなければならない。ベアラー・トークン使用時には、トークン再利用の検出と予防の強制のため、この機能が必須である。・クレデンシャル詰め込み検出ソリューションは、ユーザのログインを盗難クレデンシャル・データベースと照合し、正当なユーザに漏えいを警告できる。・IDS および境界デバイスを構成して、(a) サービスがアクセス不能となる前に DoS 攻撃を検出して警報を上げ、(b) 分散型ネットワーク・プローブを検出できるようにする。・サービス・ホストを構成して、ファイル・アップロードや各コンテナのメモリおよびファイル・システムの内容をスキャンし、常駐マルウェアの脅威を検出する。	クレデンシャル濫用・詰め込み攻撃の防止
MS-SS-12	・API を有効化する前にクレデンシャルをプロビジョニングできるよう、API ゲートウェイをアイデンティティ管理アプリケーションと統合する。・API ゲートウェイ経由でアイデンティティ管理を呼び出す際には、IdP と統合するためのコネクタを提供する。・API ゲートウェイは、クライアント・リクエスト向けのアクセス・トークンを生成できるアーティファクト（例：OAuth 2.0 認可サーバ）へのコネクタを備える。・攻撃（例：サービス拒否、悪意ある行為）を検出し、性能劣化の原因を明らかにするため、すべてのトラフィック情報を安全に監視／分析アプリケーションへチャネルする。・分散ゲートウェイのデプロイ（または初期ゲートウェイとマイクロ・ゲートウェイの組み合わせ）では、ゲートウェイ間にトークン変換（交換）サービス [18] を設ける。初期ゲートウェイに提示されるトークンは広いスコープの許可を持つ一方、内部ゲートウェイ（またはマイクロ・ゲートウェイ）に提示されるトークンは、対象マイクロサービス・プラットフォームに適した、より狭いスコープの特定権限、または全く別種のトークン型であるべきである。これは最小権限パラダイムの実装に資する。	API ゲートウェイ構成
MS-SS-13	・以下に対するポリシー・サポートを有効化すべきである：(a) サービスの組同士に特定の通信プロトコルを指定すること、(b) アプリケーション要件に基づいてサービスの組同士のトラフィック負荷を指定すること。・既定の構成では常に、すべてのサービスに対するアクセス制御ポリシーを有効化する。・権限昇格につながり得る構成（例：サービス・ロールの権限、サービス・ロールをサービス・ユーザ・アカウントへバインドすること）は避ける。・サービス・メッシュのデプロイでは、各コンポーネントのリソース使用上限を指定できる構成機能を備えるべきである。この機能がないと、これらのコンポーネントがアプリケーション全体のレジリエンスと可用性に影響を与える可能性が生じる。・サービス・メッシュのデプロイでは、要求メトリクスを含む環境メトリクスを収集して集中サービスに送信できる構成機能を備えるべきである。ポリシーは、マルチクラスタ環境で高可用性とレジリエンスを確保するため、単一のサービス・メッシュか複数のサービス・メッシュ（それぞれ独自のコントロール・プレーンを持つ）かを指定できるようにすべきである。・高度に機微なアプリケーションでは、サービス・メッシュ層全体で達成されるレイヤ 5 のネットワーク分割を補完するため、オーケストレータ・プラットフォーム内でレイヤ 3 のネットワーク分割を構成しなければならない。これは、サービス・メッシュのサイドカー・プロキシを回避・迂回する悪意ある行為者の脅威に対する対策である。	サービス・メッシュ構成

付録 C — 参考文献

番号	参考文献
[1]	Sill A (2016) The design and architecture of microservices. IEEE Cloud Computing 3(5):76–80. https://doi.org/10.1109/MCC.2016.111
[2]	Richardson C, Smith F (2016) Microservices: From design to deployment (NGINX Inc.). Available at https://www.nginx.com/resources/library/designing-deploying-microservices/
[3]	TechTarget (n.d.) Comparing two schools of application development: Traditional vs. Cloud-Native. Available at https://searchcloudcomputing.techtarget.com/PaaS/Comparing-Two-Schools-of-Application-Development-Traditional-vs-Cloud-Native
[4]	Richardson C (2015) Building microservices: Using an API gateway. Available at https://www.nginx.com/blog/building-microservices-using-an-api-gateway/
[5]	Palladino M (2016) Microservices and API gateway, Part 1: Why an API gateway? Available at https://shadrin.org/nginx/blog/content/microservices-api-gateways-part-1-why-an-api-gateway.html
[6]	Jander K, Braubach L, Pokahr A (2018) Defense in-depth and role authentication for microservice systems. Procedia Computer Science 130:456–463. https://doi.org/10.1016/j.procs.2018.04.047
[7]	Richardson C (2015) Building microservices: Inter-process communication in a microservices architecture. Available at https://www.nginx.com/blog/building-microservices-inter-process-communication/
[8]	Harms H, Rogowski C, Lo Iacono L (2017) Guidelines for adopting frontend architectures and patterns in microservices-based systems. Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering (ACM, Paderborn, Germany), pp 902–907. https://doi.org/10.1145/3106237.3117775
[9]	Montesi F, Weber J (2016) Circuit breakers, discovery, and API gateways in microservices. arXiv preprint. https://arxiv.org/abs/1609.05830v2
[10]	O'Neill M, Malinverno P (2018) Critical capabilities for full life cycle API management. (Gartner, Stamford, CT), ID G00334223. Available at https://www.gartner.com/doc/reprints?id=1-51SE2EK&ct=180601&st=sb
[11]	Calcote L (2018) The enterprise path to service mesh architectures (O'Reilly Media, Sebastopol, CA).
[12]	Twistlock (n.d.) Securing the service mesh: Understanding the value of service meshes, why Istio is rising in popularity, and exploring official Twistlock compliance checks for Istio. Available at https://www.twistlock.com/resources/securing-service-mesh-istio-compliance-checks/
[13]	Yarygina T, Bagge AH (2018) Overcoming security challenges in microservice architecture. Proceedings of 2018 IEEE Symposium on Service-Oriented System Engineering (IEEE, Bamberg, Germany), pp 11–20. https://doi.org/10.1109/SOSE.2018.00011
[14]	OpenID (2019) Welcome to OpenID Connect. Available at https://openid.net/connect/
[15]	Hardt D (ed.) (2012) The OAuth 2.0 authorization framework. (Internet Engineering Task Force), IETF RFC 6749. https://doi.org/10.17487/RFC6749
[16]	NGINX (n.d.) High-performance load balancing: Scale out your applications with NGINX and NGINX Plus. Available at https://www.nginx.com/products/nginx/load-balancing/
[17]	Katz O (2017) Improving credential abuse threat mitigation. Available at https://blogs.akamai.com/2017/01/improving-credential-abuse-threat-mitigation.html
[18]	Jones M, Nadalin A, Campbell B (ed.), Bradley J, Mortimore C (2018) OAuth 2.0 token exchange. IETF Internet-Draft. Available at https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
[19]	Lodderstedt T, Bradley J, Labunets A, Fett D (2019) OAuth 2.0 security best current practice. IETF Internet-Draft. Available at https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
[20]	Jain J (2015) HTTP verb tampering: Bypassing web authentication and authorization. Available at https://resources.infosecinstitute.com/http-verb-tampering-bypassing-web-authentication-and-authorization/