NIST 特別刊行物 800-204B

サービス・メッシュを用いたマイクロサービス型アプリケーションの属性ベースアクセス制御

Ramaswamy Chandramouli 　 Zack Butcher 　 Aradhna Chetal

本書は無償で入手可能: https://doi.org/10.6028/NIST.SP.800-204B

NIST 特別刊行物 800-204B

サービス・メッシュを用いたマイクロサービス型アプリケーションの属性ベースアクセス制御

Ramaswamy Chandramouli

Computer Security Division Information Technology Laboratory

Zack Butcher 　 Tetrate（サンフランシスコ、カリフォルニア）

Aradhna Chetal 　 TIAA（ニューヨーク、ニューヨーク）

本書は無償で入手可能: https://doi.org/10.6028/NIST.SP.800-204B

2021 年 8 月

米国商務省　 Gina M. Raimondo 長官

国立標準技術研究所（NIST）James K. Olthoff（基準技術担当次官・所長の非専属職務代理）

権限（Authority）

本書は、2014 年連邦情報セキュリティ近代化法（FISMA: 44 U.S.C. § 3551 以降、P.L. 113-283）に基づく NIST の法定責務に則り作成された。NIST は連邦情報システムの最低要件を含む情報セキュリティの標準とガイドラインを策定する責任を負うが、当該標準とガイドラインは、所管の連邦当局の明示承認なしに国家安全保障システムには適用されない。本ガイドラインは OMB 通達 A-130 の要件と整合する。

本書のいかなる内容も、商務長官が法定権限に基づき連邦機関に義務付けた標準やガイドラインと矛盾するものとして解してはならない。また、商務長官、OMB 長官、その他連邦当局者の既存の権限を変更または優越するものとして解してはならない。なお、本書は米国内で著作権の対象ではなく、民間団体により任意で利用できる。出典の明記は歓迎される。

National Institute of Standards and Technology Special Publication 800-204B\ Natl. Inst. Stand. Technol. Spec. Publ. 800-204B, 41 pages (August 2021) CODEN: NSPUE2

本書は無償で入手可能: https://doi.org/10.6028/NIST.SP.800-204B

本書では、実験手順や概念を十分に記述する目的で、特定の商用企業、装置、資材を挙げている場合がある。これは NIST による推奨や支持を暗示するものではなく、また目的に照らしてそれらが最良であることを意味するものでもない。

本書には、NIST の法定責務に基づき現在作成中の他刊行物への参照が含まれる場合がある。本書に含まれる情報（概念・方法論）は、関連刊行物の完成前であっても連邦機関により使用され得る。したがって、各刊行物が完成するまでは、既存の要件・ガイドライン・手順が存在する場合、それらは引き続き有効である。計画や移行の観点から、連邦機関は NIST による新刊行物の開発動向を注意深く追うことが望ましい。

パブリックコメント期間中は、全ての草案に対するレビューと NIST へのフィードバックを推奨する。上記以外の NIST Computer Security Division の刊行物は http://csrc.nist.gov/publications で入手できる。

本書へのコメント送付先

National Institute of Standards and Technology\ Attn: Computer Security Division, Information Technology Laboratory\ 100 Bureau Drive (Mail Stop 8930)\ Gaithersburg, MD 20899-8930

Email: sp800-204b-comments@nist.gov

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

コンピュータシステム技術レポート（Reports on Computer Systems Technology）

NIST の Information Technology Laboratory（ITL）は、国家の計量・標準インフラに対する技術的リーダーシップを提供することにより、米国経済と公共の福祉を促進する。ITL は、情報技術の発展と生産的な利用を推進するため、試験、試験手法、参照データ、概念実証実装、技術分析を開発する。ITL の責務には、連邦情報システムにおける、国家安全保障関連以外の情報の費用対効果の高いセキュリティとプライバシーのための管理・運用・技術・物理の標準とガイドラインの策定が含まれる。

要旨（Abstract）

クラウドネイティブ・アプリケーションにおける配備アーキテクチャは、疎結合コンポーネント（マイクロサービス）と、アプリケーション・コードから独立してアプリケーション・サービスを提供する専用インフラ（サービス・メッシュ）で構成されるようになった。このアーキテクチャにおける重要なセキュリティ要件は 2 つある。（1）任意のサービス間通信で相互認証を可能にしてゼロトラストの概念を構築すること、（2）広範なポリシーを表現でき、ユーザ基盤・オブジェクト（リソース）・配備環境の観点でスケーラブルな ABAC（属性ベースアクセス制御）などのアクセス制御に基づく堅固なアクセス制御機構を構築することである。本書は、これら要件を満たすサービス・メッシュ内の認証・認可フレームワークを構築するための配備ガイダンスを提供する。推奨事項の概念を説明し、実環境のコンポーネントという文脈を与えるため、マイクロサービス型アプリケーションおよびサービス・メッシュをホストするための参照プラットフォームも含める。

キーワード（Keywords）

属性ベースアクセス制御、認証ポリシー、認可ポリシー、CI/CD、DevSecOps、JSON Web Token、マイクロサービス型アプリケーション、相互 TLS、次世代アクセス制御、ポリシー実施点、ロールベースアクセス制御、サービス・メッシュ、サービス・プロキシ、ゼロトラスト。

謝辞（Acknowledgments）

本書の枠組み（サービス・メッシュ環境における認証・認可フレームワーク）の形で、マイクロサービス型アプリケーション保護向けのターゲット配備ガイダンスの取り組みを開始した NIST の David Ferraiolo 氏に深く感謝する。また、詳細な編集レビューを行った NIST の Isabel Van Wyk 氏にも謝意を表する。

特許開示通知

ITL は、本書のガイダンスや要件の順守に特許の使用が必要となる可能性がある場合、その特許権者に対し当該特許の開示を求めている。ただし、特許権者はこれに応じる義務を負わず、また ITL は該当する可能性のある特許の特定を目的とする特許調査を行っていない。刊行時点までに、上記要請に応じて ITL が特定した当該特許はない。本書の利用にあたって特許侵害を回避するためにライセンスが不要であると ITL が表明・黙示するものではない。

エグゼクティブサマリ

新たなクラウドネイティブ・アプリケーション環境の 2 つの重要な特徴は次のとおりである。

マイクロサービス：アプリケーションは複数の疎結合コンポーネント（マイクロサービス）から成り、ネットワーク越しに相互通信する。
サービス・メッシュ：アプリケーション・コードから独立して配備できる専用インフラ（サービス・メッシュ）が、認証・認可・ルーティング・ネットワーク・レジリエンス・セキュリティ監視等のサービスを提供する。

多様な端末を用いた複数の遠隔地点からのアプリケーションへの遍在的アクセスの必要性によりネットワーク境界が消失したため、アプリケーション環境にゼロトラストの概念を組み込む必要がある。さらに、クラウドネイティブ・アプリケーションは複数ドメインにまたがるため、（サービスや名前空間など）多数の変数を考慮した精緻なポリシー指定が求められる。サービス・メッシュは、これらおよびその他の運用上の保証を構築するための枠組みを提供する。

この枠組みには次が含まれる。

サービスの実行時アイデンティティを認証可能にし、個々のエンドユーザ資格情報を認証可能にし、サービス間通信を暗号化すること。
アプリケーションから独立して配備・制御可能な PEP（ポリシー実施点）。PDP（ポリシー決定点）の役割は、サービス・メッシュのサイドカー・プロキシまたは外部サービスが担いうる。
ポリシー実施を監視するためのログとメトリクス。

サービス・メッシュのネイティブ機能である、要求に付与されたエンドユーザ資格情報（例：JWT）の認証は、多くの製品で拡張され、アプリケーションに代わって外部の認証・認可システムを呼び出す能力が提供される。これらの認証・認可システムをメッシュ内のサービスとして配備できることは、転送中の暗号化、アイデンティティ、PEP、エンドユーザ・アイデンティティの認証と認可といった運用上の保証も提供する。

本書の目的は、上記機能を活用して、マイクロサービス型アプリケーション向けにサービス・メッシュ内で認証・認可フレームワークを配備するためのガイダンスを提供することである。実運用で用いられるコンポーネントという文脈を与えるため、アプリケーションおよびサービス・メッシュの参照プラットフォームも併載する。

目次（Table of Contents）

- Executive Summary …… iv

Introduction …… 1
1.1 Service Mesh Capabilities …… 2
1.2 Candidate Applications …… 3
1.3 Scope and Approach …… 3
1.4 Target Audience …… 3
1.5 Relationship to Other NIST Guidance Documents …… 4
1.6 Organization of This Document …… 4
Reference Platform for Microservices-based Application and Service Mesh …… 5
2.1 Reference Platform for Orchestration and Resource Management of a Microservices-based Application …… 5
2.1.1 Limitations of Reference Orchestration and Resource Management Platform for Security …… 6
2.2 Service Mesh Reference Platform – Conceptual Architecture …… 7
2.2.1 Service Mesh Functions for Reference Orchestration and Resource Management Platform …… 8 -
Attribute-based Access Control (ABAC) – Background …… 9
3.1 ABAC Deployment for Microservices-based Applications Using Service Mesh …… 12 -
Authentication and Authorization Policy Configuration in Service Mesh …… 13
4.1 Application Orchestration and Resource Management Platform Configuration …… 13
4.2 Service Mesh Configuration …… 13
4.3 Higher-level Security Configuration Parameters for Applications …… 15
4.4 Authentication Policies …… 15
- 4.4.1 Specifying Authentication Policies …… 16
- 4.4.2 Service-level Authentication …… 16
- 4.4.3 End User Authentication …… 17
4.5 Authorization Policies …… 18
- 4.5.1 Service-level Authorization Policies …… 18
- 4.5.2 End-user Level Authorization Policies …… 19
- 4.5.3 Model-based Authorization Policies …… 21
4.6 Authorization Policy Elements …… 22
- 4.6.1 Policy Types …… 22
- 4.6.2 Policy Target or Authorization Scope …… 22
- 4.6.3 Policy Sources …… 23
- 4.6.4 Policy Operations …… 23
- 4.6.5 Policy Conditions …… 23
- 4.6.6 Default Authorization Policy …… 24
ABAC Deployment for Service Mesh …… 25
5.1 Reference Monitor Concept in Authorization Framework …… 25
5.2 Supporting Infrastructure for ABAC Authorization Framework …… 25
- 5.2.1 Service-to-Service Request (SVC-SVC) – Supporting Infrastructure …… 25
- 5.2.2 End User + Service-to-Service Request (EU+SVC-SVC) Infrastructure …… 26
5.3 Advantages of ABAC Authorization Framework for Service Mesh …… 26
5.4 Enforcement Alternatives in Proxies …… 27
Summary and Conclusions …… 28
Appendix A: List of Recommendations for deployment of an ABAC-based authentication and authorization framework for microservices-based applications using a service mesh …… 31
References …… 29

1 はじめに（Introduction）

マイクロサービス型アーキテクチャと、サービス・プロキシを介して各種セキュリティ・サービスを提供するサービス・メッシュのアプリケーション基盤は、クラウドネイティブ・アプリケーションに広く普及した。多地点・多端末からの遍在的アクセスの必要性によりネットワーク境界が消失したため、この環境にゼロトラスト [1] を組み込む必要がある。ゼロトラストとは、物理的・ネットワーク上の位置（LAN vs. インターネット）や資産の所有形態（企業所有か個人所有か）のみに基づいて資産やユーザ・アカウントに暗黙の信頼を与えないとする考え方である [1]。ゼロトラストは、ネットワーク・セグメントではなくリソース（資産、サービス、ワークフロー、ネットワーク・アカウント等）の保護に焦点を当てる。さらに、疎結合なコンポーネント（マイクロサービス）の性質は、構成マイクロサービスの独立した設計・開発・アジャイルな配備（例：CI/CD [2]）を促進し、DevSecOps [3] のようなパラダイムの活用を可能にする。

マイクロサービス型アプリケーションのセキュリティ要件は [4] で詳述されており、ここでは議論の前提として要約する。

複数の疎結合マイクロサービスがネットワーク呼び出しで通信し、これら通信リンクは保護されなければならない（モノリシックでは手続き呼び出し）。
ネットワーク全体とすべてのマイクロサービスは信頼しない前提である。したがって、相互 TLS（mTLS）等の仕組みによる相互認証とセキュア・チャネルが必要である。
各マイクロサービスに関するログ・データは統合し、フォレンジクス、監査、分析によりアプリケーション全体の健全性を評価できるようにする必要がある。

複数のセキュリティ・ドメインや複数クラウドで動作するクラウドネイティブ・アプリケーションには、セキュアな認証・認可フレームワークが必要である。これをサービス・メッシュ内で実装する場合、フレームワークの重要要件は以下のとおり。

当該フレームワークのコードは検証可能で、かつバイパス不可能（常に呼び出される）であること。すなわちセキュリティ・カーネルの要件を満たすこと。
サービス・レベルとエンドユーザ・レベルの双方で認証・認可サービスを提供すること。
多様な認可ポリシーをサポートできること。

これら要件を満たす運用上の保証は、サービス・メッシュが提供する。次節で、それを可能にするサービス・メッシュの具体的機能を述べる。

1.1 サービス・メッシュの機能

サービス・メッシュは、その機能とそれらが有効にする各種コントロールにより、アプリケーション向けの運用上の保証の枠組みを提供する。具体的には、サービスの実行時アイデンティティ、エンドユーザ資格情報の認証、サービス間通信の暗号化、アプリケーションから独立して配備・制御可能な PEP（例：サイドカー・プロキシ）、およびポリシー実施の監視用ログとメトリクスが含まれる。これら機能を用いて、メッシュに属するすべてのアプリケーションに共通のコントロール（例：すべてのトラフィックは暗号化、アプリへのトラフィックは必ずサイドカー・プロキシ［PEP］を経由）を構築できる。

サービス・メッシュの大きな利点は、これらコントロールを実現する鍵となる部品――各アプリの横に配備されるサイドカー・プロキシ――が、アプリ・コードに直接保証を実装する従来手法より多くのセキュリティ上の利点を持つことである。第一に、サイドカーのライフサイクルはアプリから独立しており、フリート全体での管理（更新配布、バージョンの統一）が容易である。第二に、Istio などの最新実装は動的構成を可能にし、ポリシー更新はアプリの再配備なしに即時に近い形で反映される。最後に、メッシュの集中管理により、セキュリティ・チームは組織全体に適用されるポリシーを構築でき、ビジネス価値を生むアプリ開発者は既定で安全な状態となる。

サービス・メッシュは、要求に付与されたエンドユーザ資格情報（例：JSON Web Token）を認証できる。多くのメッシュ（例：Istio）はさらに、サイドカーがアプリに代わって外部の認証・認可システムを呼び出す機能を提供する。これにより、リクエスト単位のポリシー実施をアプリ・コードから切り離し、メッシュの保証（サービスに到達する要求は、実行しようとする操作に対して認証・認可済み）に依拠できる。メッシュは、その証跡をアプリへ渡すよう構成することも可能である。集中管理と組み合わせることで、中央チームは組織横断でアプリ・レベルのセキュリティを規定・管理でき、各アプリ・チームは各操作に必要な権限だけを指定すればよい。

また、サービス・メッシュを用いるということは、認証・認可システム自体をメッシュ内のサービスとして配備できることも意味する。他のサービス同様、転送中暗号化、アイデンティティ、PEP、エンドユーザ・アイデンティティの認証・認可といった運用上の保証の恩恵を受ける。結果として、組織の認証・認可システムを安全・信頼的に運用するコストを低減できる。

アクセス制御モデルの能力もフレームワークにおいて重要である。ABAC は（上記三つ目の要件である）多様な認可ポリシーを支援する上で有望なアプローチとして浮上している。[5] によれば、ABAC とは「主体がオブジェクトに対して操作を行う要求を、主体に付与された属性、オブジェクトに付与された属性、（任意で）環境条件、およびそれらの属性・条件に基づき記述されたポリシーによって許可または拒否するアクセス制御手法」である。本書の主眼は、サービス・メッシュを用いてマイクロサービス型アプリケーションを保護するための認証・認可フレームワーク（認可には ABAC を用いる）に関するガイダンスの提供にある。

1.2 対象アプリケーション（Candidate Applications）

サービス・メッシュは今日もっとも広くコンテナ化アプリで用いられるが、ステートフル・アプリケーションなど他環境にも拡張できる。

1.3 範囲とアプローチ（Scope and Approach）

本書は、サービス・メッシュのコンポーネントを用いて、マイクロサービス型アプリのサービスを保護するためのセキュアな認証・認可フレームワークを構築するガイダンスを提供する。まずメッシュが提供する機能を示し、それら機能がメッシュ内アプリに運用上の保証を与える方法を例示し、メッシュ上で動作するアプリに最善のセキュリティ姿勢をもたらす設定／デフォルトを推奨する。組織でもっとも重要なシステムの一つであるアクセス制御システムをメッシュ上で運用する例は、これらの運用上の保証を活用することで、従来より安全で低コストな運用を可能にする。

実世界のアプリケーション成果物（コンテナや VM など）の文脈で推奨事項を説明するため、参照となるアプリ・オーケストレーション／リソース管理プラットフォームと参照サービス・メッシュ・プラットフォームを用いる。前者にはオープンソースの Kubernetes（他プラットフォームでもよい）を、後者には Istio を選定する。ルーティング、ネットワーク・レジリエンス、監視など他サービスを提供するメッシュのコンポーネントは本書の範囲外とする。

1.4 対象読者（Target Audience）

本ガイダンスの対象は次のとおり。

マイクロサービス型アプリのワークロードを保護したいセキュリティ・ソリューション・アーキテクト
自組織のプラットフォームにサービス・メッシュを組み込みたいプラットフォーム・アーキテクト
当該環境で認証・認可プラグインを開発したい開発者

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

本ガイダンスは、マイクロサービス型アプリを保護するために用いられるサービス・メッシュ内で認証・認可フレームワークを構築することに焦点を当てる。背景情報として、以下の刊行物を参照されたい。

SP 800-204『Security Strategies for Microservices-based Application Systems』[4]：マイクロサービス型アプリの特性、全体的なセキュリティ要件、およびそれに対処する戦略を論じる。
SP 800-204A『Building Secure Microservices-based Applications Using Service-Mesh Architecture』[6]：専用インフラ（サービス・メッシュ）を用いたマイクロサービス型アプリの各種セキュリティ・サービス（認証・認可、セキュリティ監視等）の配備ガイダンスを提供する。
SP 800-162『Guide to Attribute Based Access Control (ABAC) Definitions and Considerations』[17]：ABAC を、主体・オブジェクト・要求操作・（場合により）環境条件に関連付けられた属性を、ポリシー・規則・関係に照らして評価し、特定の属性集合に対して許容される操作を決定する論理的アクセス制御手法として定義する。

1.6 本書の構成（Organization of This Document）

第 2 章：マイクロサービス型アプリの概観とセキュリティ要件、参照オーケストレーション／リソース管理プラットフォームおよび参照サービス・メッシュ・プラットフォームの全体アーキテクチャと構成要素の概説。これらは配備推奨に関わるビルディング・ブロックを例示するために用いる。
第 3 章：当該アプリ環境における ABAC の利点を概説し、標準的な ABAC 表現二種の機能アーキテクチャを記述する。
第 4 章：認証・認可フレームワークの構成要素、および当該フレームワークを実装するために、参照オーケストレーション／リソース管理プラットフォームと参照サービス・メッシュ・プラットフォームで必要となるポリシー構成の要件・推奨を述べる。エンドユーザとサービスの双方の認証・認可を支援する仕組みを含み、認可ポリシーに必要な最小のポリシー要素も概説する。
第 5 章：参照モニタの機能、支援インフラ、ABAC 実装としての利点、プロキシにおける実施方式の選択肠など、フレームワークのアーキテクチャ的特徴を議論する。
第 6 章：まとめと結論。

2 マイクロサービス型アプリとサービス・メッシュの参照プラットフォーム

本書の目的は、重要なセキュリティ・サービスを含む各種サービスのインフラを提供するサービス・メッシュ内で、マイクロサービス型アプリのための認証・認可フレームワークの配備推奨を提示することである。実運用環境での概念と推奨に明確さと文脈を与えるため、アプリおよびサービス・メッシュの参照プラットフォームを示す。あわせて、それらの全体アーキテクチャと主要なビルディング・ブロックの簡潔な説明も行う。

2.1 マイクロサービス型アプリのオーケストレーションとリソース管理の参照プラットフォーム

Kubernetes は、マイクロサービス型アプリで広く用いられるオーケストレーション／リソース管理システムである。大規模アプリでは複数のマイクロサービスがあり、それぞれがコンテナとして実装される。配備・運用・サービス更新・ヘルス監視にはスケーラブルで自動化された手段が必要である。Kubernetes はそれを実現するビルディング・ブロックを提供する。

Kubernetes の基本要素は、Pod、Node、Cluster、Control Plane コンポーネントである。Pod は配備される最小オブジェクトで、実行中コンテナの集合を表し、名前／値の組からなるラベルで識別される。Node は物理または仮想マシンで、Pod 群と、それらを実行するためのインタフェースを備える。Node の集合が Cluster である。

Control Plane は、クラスタに関する全体決定（例：スケジューリング）やクラスタ事象の検知・対応（例：負荷増加時の新規 Pod 起動）を担う。主要コンポーネントには、Kubernetes API サーバ、Key/Value ストア、スケジューラ、各種コントローラがある。Node Controller はその一つで、ノードの様々な側面を管理する。

アプリ構成要素（マイクロサービス）のホストで構成されるクラスタにおいて、十分な性能と可用性を確保するには、クラスタ・レベルの仕組みが不可欠である。ホストが Kubernetes の Node で、アプリ構成要素がコンテナ内で動作し、配備成果物として Pod（コンテナ群）が用いられるシナリオを考えると、次のようなクラスタ・レベルの仕組みが必要となる。

例えば、Kubernetes のよく知られた機能に Pod レベルの水平スケーリングがある。これは、サービスへのトラフィックが増えたとき、需要に応じてインスタンス数を増減することを意味する。Kubernetes は Pod レベルの自動垂直スケーリングも支援する。したがって、クラスタは、任意のマイクロサービスの想定電力（リソース）需要により正確に合わせるため、Pod が実行されるマシンのスケールを上下させるよう構成できる。例えば、特定のノード群でピークが生じる時間帯があるなら、適切な利用分析に基づき、コスト削減と性能最適化のためにジョブをマシン間で再スケジュールできる可能性がある [7]。

同様に、Kubernetes はマイクロサービスのヘルス監視（状態・準備性の確認）機能を提供する。これらのデータは、Pod 内コンテナが待ち受けるポート等を記述した宣言的配備ドキュメント YAML に構成される。サービスが起動しない、平常動作しない、想定外終了する、といった場合の動作を指定できる。

2.1.1 セキュリティ面での参照プラットフォームの制約

マイクロサービス型アプリには、認証、認可、監視、ログ、監査、トラフィック制御、キャッシュ、セキュアなイングレス、サービス間・エグレス通信など、多数のアプリ基盤・セキュリティ・サービスが必要である。複数サービスの効率的なスケジューリングと実行のためのインタフェースを備えた参照ホスティング・プラットフォームは、一貫・協調的にアプリ基盤サービス群を運用するためのインタフェースを欠く。さらに、API アーキテクチャの次の利点が十分活用されていない [8]。

横断的関心事に一貫した方法で対応
横断的関心事に迅速に対処するための標準プラグイン
カスタム・プラグインを構築するための枠組み
単一プレーンでのセキュリティ管理
運用の複雑性の低減
サードパーティ開発者・インテグレータのガバナンス容易化
開発・運用コストの削減

既定では、Kubernetes コンテナ間通信は非セキュアであり、Pod 間で TLS を強制する容易な方法はない。これは数百の TLS 証明書を個別に管理する事態を招くためである。Pod 間通信では相互にアイデンティティとアクセス管理が適用されない。Kubernetes ネットワーク・ポリシーで Pod 間ファイアウォールを定義するツールはあるが、多くはレイヤ 3 の解であり、現代的ファイアウォールが行うレイヤ 7 の機能ではない（より高度なネットワーク・ポリシーを定義するツールも一部存在する）。すなわち、トラフィックの発信元は分かっても、パケット内容を理解することはできない。HTTP ヘッダに基づき新バージョンの Pod へルーティングする、といったメタデータ駆動の重要な判断はできない。

Kubernetes の Ingress オブジェクトはレイヤ 7 のリバース・プロキシを提供するが、単純なトラフィック・ルーティング以上の機能はない。※1\ Kubernetes には、ある種の A/B テストやカナリア・デプロイを行う手段もあるが、接続レベルでの制御であり、きめ細かな制御や迅速なフェイルバックは提供しない。例：新バージョンに 10% のトラフィックを流したい場合、少なくとも 10 個のコンテナ（旧 9、新 1）へスケールしなければならない。さらに、Kubernetes はトラフィックを賢く分割できず、Pod 間の負荷分散はラウンドロビンである。各コンテナは個別にログを持つため、収集と統合には Kubernetes の上にカスタム解を実装する必要がある。

Kubernetes ダッシュボードは Pod の監視やヘルス確認機能を提供するが、アプリ構成要素の相互作用、各 Pod を流れるトラフィック量、アプリを構成するコンテナ連鎖といったメトリクスは可視化しない。デフォルトでは Pod をまたぐトラフィックのトレーシングができないため、要求がどの連鎖で失敗したのか不明瞭である。

サービス・メッシュはこれらの制約に対処する [9]。以下では、まずサービス・メッシュのアーキテクチャを概観し、ついで参照プラットフォーム（Kubernetes）における実装を述べる。

※1 カスタム開発により Ingress コントローラ／オブジェクトを拡張して高度機能を提供することは可能。実際、一部のサービス・メッシュ実装は、特定の Kubernetes 環境でこれをトラフィック・ルーティングに活用している。なお、オーケストレーション・プラットフォーム（Kubernetes）のネットワーク構成はサービス・メッシュの不可分要素ではない。マイクロサービスはコンテナで実装されるため、ネットワーク構成は CNI 実装に依存する。したがって高度なネットワーキングの可否は、運用者がクラスタの Ingress コントローラとしてどのソフトウェアを選ぶかに左右される。

2.2 サービス・メッシュ参照プラットフォーム ― 概念アーキテクチャ

サービス・メッシュは、各種アプリ・サービスを提供し、それらの相互作用を制御するマイクロサービスのネットワークである。これは二つの主要コンポーネントでマイクロサービス型アプリの管理を支援する。

データ・プレーン：マイクロサービス間でメッセージを実際にルーティング／通信するコンポーネント。サービスの健全性・状態を監視するテレメトリも収集する。ここを流れるのはアプリ関連（ビジネス）のデータである。
コントロール・プレーン：ポリシーを定義するための API を提供するコンポーネント。多くの場合、アプリが動作するプラットフォームとは独立している。データ・プレーン（サイドカー・プロキシ）の構成を投入し、トラフィックのルーティング方法を決める。メッシュの頭脳に相当する。ここを流れるのはメッシュ構成要素間のやり取りに関するメッセージである。

コントロール・プレーンは複数モジュールからなり、機能配分は製品によって異なるが、共通の中核機能は次のとおり。

a. コントロール・プレーンで定義されたポリシー規則を解釈し、データ・プレーン（サイドカー・プロキシ）の構成パラメータへ変換するモジュール。認証・認可、サービス・ディスカバリ、トラフィック管理（ロードバランシングを含む）、インテリジェント・ルーティング、ブルーグリーン、カナリアなどに関するポリシーを扱う。タイムアウト、リトライ、サーキット・ブレーク等のレジリエンス関連パラメータも含み得る。
b. 二つのマイクロサービス間通信時の認証・認可・暗号化セッション確立のためのインフラ機能を提供するモジュール。ユーザ認証、資格情報管理、デジタル証明書管理、トラフィック暗号化などを含む。

2.2.1 参照オーケストレーション／リソース管理プラットフォームにおけるサービス・メッシュ機能

参照プラットフォーム（ここでは Kubernetes）における汎用的なサービス・メッシュ機能を述べるためには、当該プラットフォームにおけるマイクロサービス・アプリとメッシュ・コンポーネントの配備詳細を考慮する必要がある。本書の焦点は認証と認可であるため、Kubernetes 上でのそれらの機能に関する議論はサービス・メッシュの機能に限定する。

サイドカー・プロキシのコードは「コンテナとして実装」され、マイクロサービス・コンテナと同一 Pod にホストされるため、同一のネットワーク・ネームスペースを共有し、同一ノード（VM または物理マシン）に存在する。両コンテナは同一の IP アドレスを持ち、同じ IP テーブル規則を共有する。これにより、プロキシは Pod のネットワークを完全に制御し、その通過トラフィックをすべて処理できる [10]。

相互 TLS セッション確立を例にとると、プロキシは、チェーン全体を暗号化する必要があるか、バックエンド Pod と相互 TLS を確立すべきかを確認するため、サービス・メッシュのコントロール・プレーンのモジュールと連携する。mTLS を有効化するには、各 Pod が証明書（有効な資格情報）を持つ必要がある。大規模なマイクロサービス・アプリでは数百の Pod に及び、短命な証明書を多数管理することになる。従って、サービス・メッシュには堅牢なアイデンティティ／アクセス管理、証明書ストア、証明書検証が求められる。さらに、認証ポリシーを支えるため、通信当事者 2 つの Pod を識別・認証する仕組みが必要である。

サービス・メッシュは実行時に各種アプリ・サービスを提供するだけでなく、DevSecOps の開発・保守パラダイムも支援する。開発チームは、サイドカーとの相互作用や PEP を通るデータ・フローを含む安全な配備など、アプリ・アーキテクチャ（コードのモジュール化と構造化）に注力でき、全インフラ・サービス（セキュリティの多くの側面を含む）の実装（開発・配備）に煩わされない。サービス・メッシュは参照プラットフォームを認識し、Pod へのサイドカー・コンテナの自動注入を行う。サイドカーが挿入されれば、開発・運用・セキュリティの各チームはポリシーを定義・配備し、実行時の適用を監視できる。アプリの動作を妨げることなく、マイクロサービス・アプリの監視も構成できる。

3 Attribute-based Access Control (ABAC) - Background

属性ベースアクセス制御（ABAC）は、ユーザー（主体）、アプリケーションオブジェクト（資源）、および環境の属性（特性）と、それらの属性で表現されたポリシーに基づいて、ユーザーのアクセス要求に対する決定を計算する認可フレームワーク（またはエンジン）である [5]。サービスメッシュを用いたマイクロサービス型アプリケーションに対する ABAC の利点は次のとおりである。

- 1. クラウドネイティブアプリケーションは複数のドメインにまたがり、（複数の属性とその値という）多数の変数を考慮してポリシーを高い精度で指定する必要がある。属性値ストアとそれに関連するポリシーの観点でのスケーラビリティにより、ABAC はこの要件を満たすことができる。主体に関連付けられる属性とその値はシステム管理者が割り当て、アプリケーションオブジェクトおよび環境に関連付けられるものは開発者が独立して割り当てる。

- 2. ポリシーは、主体・客体・環境の属性を含む論理式であり、許可／禁止の評決が付与される。属性に基づくポリシーは、特定の主体インスタンスと客体インスタンスの間に強い関係を作らない。なぜなら、それらに関連付けられた属性は任意の値を取り得て、時間とともに変化し得るからである。要求を許可するか否かのアクセス決定は、要求時点の各インスタンスに関連付けられた属性値のみによって完全に決定される。

- 3. ポリシーは、将来的にその下で管理される可能性のある多数のユーザーやリソースについての事前知識なしに、属性で表現される。一方で、ユーザーやリソースにはポリシーの詳細を知らずとも独立して属性値が割り当てられる。この二つの特性により、ユーザー要求に対するアクセス決定を、組織全体で集中管理されたポリシーに基づかせつつ、各マイクロサービス開発チームが自らのアプリケーション（マイクロサービス）に関するすべての決定（すなわちアプリケーションオブジェクトへの属性値付与を含む）を自律的に行うという DevSecOps のアプローチも同時に支援できる。

上記の特性により、ABAC 認可フレームワークは、マイクロサービス（それぞれが独立したチームにより開発・デプロイ）を設計基盤とするクラウドネイティブアプリケーションのクラスに自然に適合する。

ABAC フレームワークには標準化された二つの表現構造が存在する。

- 1. 一つは、Open Artwork System Interchange Standard（OASIS）により標準化された、プラットフォーム中立のテキスト言語である eXtensible Access Control Markup Language（XACML）Version 3.0 を用いる。 - 2. もう一つは Next Generation Access Control（NGAC）であり、そのデータ構造および操作は InterNational Committee for Information Technology（INCITS）565-2020 [11] で標準化されている。この標準化には、機能コンポーネント（すなわち PEP、PDP、Resource Access Point（RAP））の API が含まれ、これにより異なる供給元のコンポーネント間の相互運用性が可能になる。さらに、PEP インターフェースは、アプリケーション要求とポリシー管理要求の双方に対するポリシー強制に共通である。NGAC の最大の利点は、アクセス制御の決定を計算し、ポリシーレビュー（すなわち、あるユーザーがアクセス可能なリソース集合の決定、あるリソースにアクセス可能なユーザー集合の決定）を実行するために線形時間アルゴリズムを用いる点にある [12,13]。

これら二つの表現構造に対応する機能アーキテクチャは、それぞれ図 3.1 および図 3.2 に示される。なお、Open Policy Agent（OPA）や Casbin のようなオープンソースのアクセス制御エンジンも存在し、XACML 実装と同様に ABAC ポリシーを定義し強制する能力を備えている。これら二つの機能アーキテクチャにおけるモジュールの概要は次のとおりである。

- 1. ポリシー決定点（PDP）— ABAC 機能アーキテクチャの中核モジュールであり、ユーザーがリソース（アプリケーションオブジェクト）に対して操作を行うためのアクセス要求に対し、許可または拒否の決定を計算する。要求はポリシー実施点（PEP）と呼ばれるモジュールから受け取り、応答も PEP へ返す。これは両表現に共通である。

- 2. ポリシー実施点（PEP）— アプリケーションのプラットフォームの一部であり、アプリケーションと密に統合される。あらゆるアクセス要求を捕捉し、自ら許可／拒否を行うか、外部の PDP モジュールに問い合わせる。

- 3. ポリシー情報点（PIP）

XACML 表現では、アプリケーションに関連するすべてのオブジェクト（リソース）について、属性とその値のデータベースを保持するモジュールである。ここにある情報は、アクセス要求に含まれるユーザーおよびリソースの属性とその値を抽出するために用いられる。抽出された属性値はターゲット句に照合され、これによりポリシー取得点（PRP、後述）にある適用可能なターゲットポリシーが見つかる。
NGAC 表現では、（u-ai, op-i, o-ai）という形の関連（association）関係のリポジトリであり、これはある pc-i に対して定義される。ここで u-ai と o-ai はそれぞれユーザーおよびオブジェクト（リソース）に関連付けられた属性値である [11]。op-i は許可される操作の集合、pc-i は支配的なポリシークラスのインスタンスを表す。関連関係は一般に、ポリシー要素（ユーザーおよびオブジェクトの属性値）間でアクセス権（例：読み取り、書き込み）の割り当てを定義する構成済みの関係として定義でき、一定のアクセス様式を可能にする。関連関係の数を（アプリケーション内の全ユーザーと全オブジェクトを表す三つ組を持たせるようなことなく）最小化するために、（U < u-ai）のような包含（containment）関係を用いて、関連関係で表されるユーザーグループおよびオブジェクトグループのメンバーを示す。個々のポリシー要素（例：u-ai, o-ai）を直接用いる代わりに、包含関係では、すべてのポリシー要素集合 PE の冪集合（2^PE、集合 PE のあらゆる部分集合を含む）を用いて関連関係を定式化する。さらに、同じ包含関係の集合は、各オブジェクトに適用可能なポリシー（O < pc-i）を表すためにも用いられる。あるオブジェクト O に適用可能なポリシーが分かれば、その pc-i とすべての o-ai（当該オブジェクトの属性値）に対する関連関係から、オブジェクト O に対して許されるユーザーと操作の集合が得られる。

- 4. ポリシー取得点（PRP）— XACML 表現において、これは属性値に関する述語を含む論理式として表現された認可ポリシーのリポジトリである。ポリシー表現には、当該ポリシーがカバーする対象リソースも含まれる。アクセス要求で求められたリソースはこれらのターゲットに照合され、PDP がその要求の決定を計算する際に用いる適用可能なポリシーが取得される。NGAC 表現では、このモジュールは機能アーキテクチャの一部ではない。

- 5. 属性管理点（AAP）— XACML 表現において、PIP に格納された属性を管理するためのインターフェースである。NGAC 表現では、本モジュールは不要である。なぜなら、NGAC では関連関係によって、属性値を用いてインスタンス化されるオブジェクト上のアクセス権を表現するためである。

- 6. ポリシー管理点（PAP）— PRP に格納されたポリシーを管理するためのインターフェースである。

図 3.1 XACML 表現に基づく ABAC 機能アーキテクチャ

図 3.2 NGAC 表現に基づく ABAC 機能アーキテクチャ

3.1 ABAC Deployment for Microservices-based Applications Using Service Mesh

サービスメッシュを用いるマイクロサービス型アプリケーションの文脈では、ABAC のデプロイは次の形態を取り得る。

プロキシ（例：Ingress、サイドカー、Egress）は、各クライアント・ユーザー・サービス・外部サービスから発生するすべての要求を傍受するため、PEP の役割を果たす。
PEP は、PDP が提供する評決に基づいて許可／拒否の動作を行うことで、アクセス制御ポリシーを強制する。
強制機能は、（ACL のような）ローカルな構成構造を用いてネイティブに提供することも、外部の認可サーバーを呼び出して前項のデータを取得するプロキシ拡張を用いて提供することもできる。
サービスメッシュにおける保証メカニズム（例：証明書ベース認証、安全なセッション、バイパス不能性、実行分離）は、高保証の認可フレームワークをデプロイするために活用できる。実行分離とは、各ソフトウェアコンポーネントを、マルウェアの被害を限定し、ワームやウイルスの速度と伝播を抑え、攻撃を効率的に検出する、ハードウェア仮想化を活用したサンドボックス等の閉じた環境で実行することである。

4 Authentication and Authorization Policy Configuration in Service Mesh

マイクロサービスのきめ細かなアクセス制御は、認証およびアクセス制御ポリシーの構成によって強制できる。これらのポリシーはサービスメッシュのコントロールプレーンで定義され、低レベルの構成にマッピングされ、サービスメッシュのデータプレーンを成すサイドカープロキシに配布される。これらの構成により、プロキシはアプリケーションの実行時（あるいはリクエスト時）にポリシーを強制でき、結果としてプロキシはポリシー実施点（PEP）として機能する。序文で述べたように、本書の目的は、アプリケーションの外部にあり、アプリケーションをホストするプラットフォームやアプリケーション基盤を実装するサービスメッシュ製品に依存しない認証・認可フレームワークのデプロイに関するガイダンスを提供することである。ただし、概念を具体化し、より明確で特異的な勧告を示すため、リファレンスのアプリケーションプラットフォームとして Kubernetes を、サービスメッシュ基盤として Istio を用いる。

4.1 Application Orchestration and Resource Management Platform Configuration

サービスメッシュを用いるマイクロサービス型アプリケーションにおいて、認証および認可ポリシー構成に最低限必要となる、リファレンスのアプリケーションオーケストレーションおよびリソース管理プラットフォームの構成データは次のとおりである。

アプリケーションサービス名や、そのサービスのインスタンス集合などのメタデータ（例：Kubernetes 上でホストされるもの）
サービスのプロトコルやポートなどの実行時データ
一群のサービスに対する論理的分離境界を提供するネームスペース
各サービスに固有の実行時アイデンティティ

Kubernetes というリファレンスプラットフォームでは、これは次のように実現される。

Service リソース：サービス名、プロトコル（例：TCP）、ポート（例：9080）を宣言する。
Deployment リソース：当該サービスを実装する Pod のデプロイを宣言し、ラベルやバージョンなどのメタデータを含む。
Namespace 構成と RBAC：ユーザーがどのようにネームスペースへ構成を公開できるかを管理する。
ServiceAccount：各ネームスペースに固有で、個々のサービスに紐づくアイデンティティ。

4.2 Service Mesh Configuration

任意のサービスメッシュのインストールには、以下のコンポーネントが含まれる。

Ingress Gateway：マイクロサービス型アプリケーションへの最初の入口。ここでは、アプリケーションクライアントがアプリケーションへアクセスするために必要な名前・ポート・ルートを指定する。実装によっては、サイドカー自体がその機能を果たせるため、Ingress Gateway は任意である。
Egress Gateway：アプリケーションが外部のサービスやアプリケーションを呼び出すためのゲートウェイ。Ingress Gateway と同様、サイドカー自体が機能を担えるため任意である。
サイドカープロキシの注入（コンテナの形で）。その結果、プラットフォーム上のアプリケーションの各デプロイメントには、元のマイクロサービスコンテナに加えてメッシュのサイドカープロキシという二つのコンテナが存在するようになる。これらのサイドカープロキシはアプリケーション実行時に認証・認可ポリシーを強制し、PEP として機能する。なお、エージェント（例：OPA）が、認可サービスに対する PDP の役割を担う場合がある。また、プロキシはメトリクスとログを出力し、ポリシーが存在し強制されていることを継続的に監視できるようにすべきである。
証明書局（CA）モジュール：サイドカープロキシからの証明書要求を処理するために必要である。サイドカーは、X.509 証明書として提示される実行時アイデンティティを必要とする。CA はメッシュで用いる鍵と証明書を生成・配布・管理し、メッシュが自動的に証明書ローテーションを行えるようにする。証明書の有効性の証拠は、オンライン証明書状態プロトコル（OCSP）サーバーの署名付き・日付付き応答を証明書の一部として含める（「OCSP ステープリング」）X.509 拡張により、証明書自体に内包させる。
コントロールプレーンモジュール：ホスティングプラットフォーム上の構成データを監視し、ポリシーをエンコードし、それらのポリシーを構成情報としてメッシュ内の各種プロキシ（例：Ingress、サイドカー、Egress）へ配布する。

以上のサービスメッシュの構成要素を踏まえ、Kubernetes のワークロード間通信において相互 TLS 認証 [14] を設定し、認証・認可ポリシーを構成・強制する前提条件としての最小要件を示す。これらの要件（推奨事項）は、ISMC-SR-X（ISMC は Initial Service Mesh Configuration、SR は Security Recommendation）という略号で番号付けする。以下にその一部を示す。

ISMC-SR-1：サービス呼び出しの認証に証明書ベースの認証を用いる場合、サービスメッシュの CA モジュールで用いる署名用証明書は、監査・ローテーション・失効を可能にするため、組織の既存 PKI にルート付けされているべきである。一部のサービスメッシュは、自己署名証明書を用いてトラフィックを暗号化する機能を備えるが、安全なデプロイではそのような証明書を用いるべきではない。

ISMC-SR-2：サービスメッシュのコントロールプレーンと、アプリケーションのオーケストレーションおよびリソース管理プラットフォームの構成サーバー間の通信は、認証され、かつ認可されていなければならない。このリファレンスプラットフォームでは、認証は通常、Kubernetes API サーバー（構成サーバー）による単純な TLS で達成される。クライアントの認証は Pod の ServiceAccount 資格情報に基づく。API サーバーからプラットフォーム情報を受け取るクライアントに対する認可は、Kubernetes RBAC によって強制される。

4.3 Higher-level Security Configuration Parameters for Applications

アプリケーションを構成するマイクロサービスは一般にコンテナとして実装されるため、次の上位レベルのセキュリティ構成パラメータを設定すべきである。Kubernetes というリファレンスプラットフォームでは、コンテナは Pod 内に実装され、Pod にはマイクロサービスコンテナとサイドカーコンテナが含まれる。これらの上位セキュリティ構成は、Pod Security Policies（現在は Pod Security Standards 等に置換）に属するフラグで設定する。これらのフラグ値に関する推奨は、AHLC-SR-X（AHLC は Application Higher-level Configuration、SR は Security Recommendation）という略号で番号付けする。以下にその一部を示す [5]。

AHLC-SR-1：コンテナおよびアプリケーションは root で実行すべきではない（すなわち特権コンテナ化を避ける）。Kubernetes では 'MustRunAsNonRoot' フラグを TRUE に設定する。

AHLC-SR-2：HostPath ボリュームは使用すべきではない。これは、コンテナと、そのコンテナがホストされるノードとの間に強い結合を生み、移行や柔軟なリソーススケジューリングのプロセスを制約するためである。

AHLC-SR-3：すべてのアプリケーションについて、コンテナのファイルシステムは既定で読み取り専用に構成し、基盤アプリケーション（例：データベース）がディスク書き込みを必要とする場合のみ例外とする。Kubernetes では 'readOnlyRootFilesystem' フラグを TRUE に設定する。

AHLC-SR-4：コンテナの権限昇格を明示的に防止する。Kubernetes では 'allowPrivilegeEscalation' フラグを FALSE に設定する。

4.4 Authentication Policies

認証ポリシーは、アイデンティティの検証プロセスを指定する。このプロセスの完全性と強度は、認可プロセスの完全性を規定する。なぜなら、後者は、認証済みアイデンティティの強度に依存するためである。マイクロサービス型アプリケーションでは、次の二種類のアイデンティティが必要となる。

マイクロサービス（ワークロード）のアイデンティティ
エンドユーザーのアイデンティティ

サービス（マイクロサービス）アイデンティティが重要である理由は次のとおりである。

クライアントが通信相手のサーバー（サーバーが保持する証明書で検証されるサーバーアイデンティティ）が、当該サービスの実行を許可された正当なものであることを検証できるようにするためである。この保証は、サーバーアイデンティティをサービスアイデンティティへマッピングする安全なネーミングサービスによって提供されなければならない。任意のオーケストレーションプラットフォーム（Kubernetes を含む）では、負荷分散や可用性の理由から、サービスはノード（サーバー）間で移動し得る。このマッピング情報を更新する責務はサービスメッシュのコントロールプレーンにあり、構成情報を保持する API（例：Kubernetes の API サーバー）と連携し、その情報をサービスメッシュのデータプレーンにあるサイドカープロキシへ伝える。
サービスアイデンティティは、対象サービスが適用・強制すべき認可ポリシーを選択するための基盤である。

4.4.1 Specifying Authentication Policies

これらのアイデンティティに対応して、サービスメッシュがサポートすべき認証プロセスは次のとおりである。

サービスレベル認証（またはピア認証）：サービスアイデンティティを用いる。
エンドユーザー認証（またはリクエスト認証）：エンドユーザー資格情報を用いる。

リファレンスのホスティングプラットフォームが 4.1 節で概説した上位要件で構成されていること、リファレンスのサービスメッシュプラットフォームが 4.2 節で述べた初期要件でインストール・構成されていることを前提とする。

4.4.2 Service-level Authentication

サービスレベル認証とは、通信するサービス同士の相互認証と、安全な TLS セッションの確立を指す。これを有効化するには、次の要件を満たすポリシーオブジェクトを定義できる能力が必要である。これらの要件はサービスレベル認証の実現要件であり、SAUN-SR-X（SAUN は Service-level Authentication、SR は Security Recommendation）という略号で番号付けする。

SAUN-SR-1：通信に mTLS を要求するサービスレベル認証に関するポリシーオブジェクトを定義すべきである。ポリシーオブジェクトは、下位レベルでのオーバーライドや、上位レベルで指定した要件の継承を可能にし、以下の最小レベルで定義できるだけの表現力を備えるべきである [6]。

グローバル（サービスメッシュ）レベル
名前空間レベル
ワークロードまたはマイクロサービスレベル（特定のマイクロサービス、ホスト、ポートなど、一部のトラフィックや一部のリソースに対して認証・認可ポリシーを適用）
ポートレベル（特定のトラフィックが指定ポートで通信する設計を考慮）

この種の認証には、各サービスに強いアイデンティティを付与し、そのアイデンティティをサーバーアイデンティティ（サービスがホストされるサーバー）へとマッピングして認証し、そのマッピングの真正性をデジタル署名で確立することも必要である。これを実装する一つの方法が、特別なデジタル認証証明書（SPIFFE: Secure Production Identity Framework for Everyone）である。SPIFFE 証明書に記載されたサーバーアイデンティティが、対象サービスの実行を許可された正当なもの（正当な配置先）であることを担保するため、次の要件（SP 800-204A でも規定）を必要とする。

SAUN-SR-2：mTLS に用いる証明書がサーバーアイデンティティを運ぶ場合、サービスメッシュは、サーバーアイデンティティを安全なディスカバリーサービスまたは DNS で提供されるマイクロサービス名へマッピングする安全なネーミングサービスを提供すべきである。これは、当該サーバーがマイクロサービスの正当な配置先であることを保証し、ネットワークハイジャックを防ぐために必要である。

サーバーアイデンティティからサービスへのマッピング情報は、マイクロサービス型アプリケーションをホストするプラットフォームの構成情報へアクセスすることで、サービスメッシュのコントロールプレーンが取得する。Kubernetes では、サービスメッシュのコントロールプレーンは Kubernetes の API サーバーモジュールを介してマッピング情報を取得し、その情報を安全なネーミングサービスに反映する。したがって、相互証明書検証により、クライアントサービスおよびターゲットサービス双方の関連するサービスアイデンティティの検証だけでなく、安全な mTLS セッションの作成も可能になる。Istio では、この種の認証に関するポリシーオブジェクトは「PeerAuthentication」と呼ばれる。

4.4.3 End User Authentication

メッシュがエンドユーザー資格情報（EUC）を認証するためには、アプリケーション側の協調が必要である。リクエストを行うクライアントサービスは、各リクエストに適切な資格情報（例：JWT）をリクエストヘッダへ取得・付与すべきである。エンドユーザー認証（またはリクエスト認証）とは、リクエストのメタデータから資格情報を抽出し、それを（ローカルまたは外部サーバーに対して）検証することで、リクエストを行うエンドユーザーの資格情報を検証するプロセスである。多くの組織における一般的なフローの一例として、外部の EUC（例：OAuth ベアラートークン）を Ingress で内部資格情報へ交換し、その内部資格情報を JWT にエンコードする方法がある。JWT は、カスタムの認証プロバイダでも、標準に基づく OpenID Connect プロバイダでも作成可能である。

エンドユーザー認証ポリシーにおける最小情報要件は、EAUN-SR-X（EAUN は End-user Authentication、SR は Security Recommendation）という略号で番号付けする。

EAUN-SR-1：リクエスト認証ポリシーは、少なくとも次の情報を提供し、サイドカープロキシによって強制されなければならない。

リクエストから資格情報を抽出する手順
資格情報を検証する手順

JWT の場合、これには次が含まれ得る。

ユーザーのクレームを含む JWT トークンの所在（ヘッダー名）
JWT から subject、claims、issuer を抽出する方法
JWT 検証に用いる公開鍵、またはその鍵の取得先

4.5 Authorization Policies

認可ポリシーは、対応する認証ポリシーと同様に、サービスレベルおよびエンドユーザーレベルの双方で指定できる。さらに、認可ポリシーはアクセス制御モデルの構成要素に基づいて表現され、アプリケーションの性質やエンタープライズの方針によって異なり得る。また、アクセス制御データの所在は、エンタープライズ内のアイデンティティおよびアクセス管理基盤に依存して変わり得る。これらの差異は、次の変数をもたらす。

2 つの認可レベル（サービスレベルとエンドユーザーレベル）
認可ポリシーを表現するために用いるアクセス制御モデル
アクセス制御データの所在（集中管理された外部の認可サーバー、またはヘッダデータとして運搬）

サービスメッシュでサポートされるアクセス制御は抽象化を用い、以下（4.5.1 節）で述べる 1 つ以上のポリシー構成要素をグルーピングして、サービスレベルまたはエンドユーザーレベルの認可ポリシーを指定する。マイクロサービス型アプリケーションは API（例：RESTful API）として実装されるため、キー/バリューの組で記述される認可ポリシー構成要素には、関連するネットワークプロトコルを含む API に関する属性が含まれる。認可ポリシーの種類は次のとおりである。

サービスレベル認可ポリシー
エンドユーザーレベル認可ポリシー
モデルベース認可ポリシー

4.5.1 Service-level Authorization Policies

サービスレベル認可ポリシーは、次のポリシー構成要素を伴う肯定（許可）または否定（不許可）の権限を与えるポリシーオブジェクトを用いて定義する。

a. ポリシーのスコープは、サービスメッシュ全体、名前空間レベル、または指定された 1 つ以上のアプリケーション（マイクロサービスレベル）に及び得る。
b. 権限や操作は、あるサービスの指定メソッド（例：「PRODUCT-CATALOG」というアプリケーションの「/details」パスに対する「HTTP GET」）や、アプリケーションへアクセスするための指定ポートに制限できる。
c. アクセスが可能となる条件（例：トークンの保持）を指定する。
d. 許可されたソースを、名前空間レベルまたは特定サービスレベル（サービスのランタイム ID で表現）で指定する。

サービスレベル認可ポリシーを有効化するためのポリシーオブジェクトの要件は、頭字語 SAUZ-SR-X で番号付けする。ここで SAUZ はサービスレベル認可、SR はセキュリティ勧告、X は通し番号を表す。

SAUZ-SR-1: 「すべてのサービス間アクセスを記述するポリシーオブジェクトを、メッシュ内のすべてのサービスに対して用意すべきである。最低限、これらのポリシーは名前空間レベルでアクセスを制限すべきである（例：『名前空間 A のサービスは名前空間 B のサービスを呼び出せる』）。理想的には、個別サービスへのアクセスを制限すべきである（例：『名前空間 A のサービス Foo は、名前空間 B のサービス Bar を呼び出せる』）。」

ポリシーは、アプリケーション機能に必要な最小限のアクセスを記述すべきである（例：「名前空間 A のサービス foo は、名前空間 B のサービス bar に対して『GET /bar』を実行できる」）。

4.5.2 End-user Level Authorization Policies

4.4.3 節のような認証ポリシーが与えられている場合、メッシュ内のサイドカーはリクエストから主体系（プリンシパル）を抽出し、それに対する認可を実行できる。さらに、サイドカーは通常、アクセスされるリソース（例：HTTP/REST API におけるパス）や、実行されるアクション（例：当該 API へのリクエストに含まれる HTTP 動詞 GET、PUT）など、リクエストに関する追加のコンテキストを持つ。これにより、サイドカーは PEP として機能し、ポリシー決定点（PDP）を呼び出すために十分な情報を得られる。

これは最も一般的なケースであり、従来型の IAM（Identity and Access Management）システムを外部サービスとして持ち、しばしば SDK で呼び出す組織に多い。このケースに対処するため、サービスメッシュのサイドカープロキシは通常、外部サービスを呼び出して認証および認可の評定を得ることをサポートする。例えば、参照実装である Istio は、Envoy（サイドカープロキシ）の外部認可サービスを通じてこれをサポートしている[15]。

エンドユーザーレベル認可ポリシーを有効化するための要件は、頭字語 EUAZ-SR-X で番号付けする。ここで EUAZ はエンドユーザーレベル認可、SR はセキュリティ勧告、X は通し番号を表す。

EUAZ-SR-1: サイドカーが認証または認可システムと通信する際、その通信は、メッシュ内蔵のサービス間認証・認可機能、またはサービスメッシュに含まれない既存のエンタープライズ IAM のいずれかにより保護されなければならない。

例として、Auth0 のような外部 SaaS 型 IAM がある。

EUAZ-SR-2: サイドカーは、認証・認可ポリシーが強制されていることを確実にするために、すべてのサービスリクエストについてログを生成し、可用性に影響するサービス劣化が発生しないよう、メトリクス生成のためのテレメトリーデータを中継すべきである。

外部の認可（PDP）サービスの決定エンドポイントに対しては、当該サービス（サービスポリシーの主体）が呼び出しを行うため、エンドユーザー認可は適用されない。これはまた、PDP の決定エンドポイントをすべてのユーザーに許可するデフォルトポリシーを必要としないようにする効果もある。一方で、PAP や認可システムの他の管理系エンドポイントにはエンドユーザー認可を適用すべきであり、その適用はメッシュによって容易になる。

ただし、外部認可システムが不要な別の一般的ケースもある。サービスチェーンの各ホップごとに認可サービスへネットワーク呼び出しを行うのは高コストで、中央集約的な障害の原因にもなり得る。これらの問題を緩和するため、多くの組織では、エッジ（Ingress）でエンドユーザーの資格情報を、ユーザーの主体だけでなく当該ユーザーのシステム内能力も伝達する内部の信頼できる認証可能な資格情報へ交換する。これはローカルでの真正性確認が可能で、ユーザーの主体（JWT の subject）、JWT の発行者（issuer）、組織が制御可能な任意のクレーム（アクセス制御に使用可能）を伝達できるため、JWT が頻繁に用いられる。

参照メッシュ Istio のサイドカープロキシである Envoy には、JWT に基づくエンドユーザー認可を直接実行する機能が組み込まれている。Envoy はフィルタ[16]で次の 2 段階の処理を行うように設定できる。

JWT トークン検証：リクエストヘッダからトークンを抽出し、許可された issuer および audience かを確認し、公開鍵を取得し、トークンのデジタル署名を検証する。
リクエスト内のリソースをトークン内のクレームと照合し、エンドユーザーに要求リソースへのアクセスを許可すべきか否認すべきかを判断する。

Envoy の JWT フィルタは PDP として動作し、アクセス判断を完全にローカルで行う。これは、ポリシードキュメントが個々のサイドカープロキシに格納可能なほど小さいことを要する。リソースレベルのポリシー処理には完全な ABAC が理想だが、JWT フィルタは、エッジのみによるアクセス制御から、各サービスで認証と認可を行うゼロトラストシステムへの移行段階として有用である。この方式の制限は、JWT が一度発行されるとユーザーのアクセスを取り消しにくくなる点である。OAuth2 Introspection に関する IETF RFC のようなコミュニティ標準を用いて、この課題に対処できる。

外部認可システムを呼び出すことなく、サイドカー自身が JWT のクレームに基づいてアクセス制御判断を行い、これを強制できる認可ポリシーの例を以下に示す。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: backend
  namespace: product
spec:
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - "cluster.local/ns/product/sa/frontend"
      to:
        - operation:
            methods: ["GET"]
            paths: ["/info*"]
        - operation:
            methods: ["POST"]
            paths: ["/data"]
      when:
        - key: request.auth.claims[iss]
          values:
            - "accounts.google.com"

図 4.1—Istio の認可ポリシー例

これは、フロントエンドが、リクエストに「accounts.google.com」によって発行された EUC が添付されている場合に限り、バックエンド上の特定メソッドを呼び出せるようにする。

EUAZ-SR-3: すべてのアプリケーショントラフィックはエンドユーザー資格情報を運搬すべきであり、資格情報の存在を強制するポリシーをメッシュに設定すべきである。

これは、アプリケーションがメッシュとは独立に認証・認可を実施している場合でも推奨される。組織全体の統制により、監査のような機能をメッシュ上に低コストで構築でき、コンプライアンスや統制を担う中央チームの負荷を軽減できるためである。

4.5.3 Model-based Authorization Policies

サービスレベル認可ポリシーと、JWT を用いるエンドユーザー認可ポリシーのユースケースは、プロキシ内にネイティブ実装されている。これらはリソースレベルの認可ポリシーには用いられないため、モデルベース認可ポリシーのサポートも必要となる。4.5.2 節で既述のとおり、これはプロキシから外部の認可サーバー（モデルベース認可エンジンを保持）へアクセス判断を得るための呼び出しを要する。

これらモデルベースポリシーにおけるサービスのプリンシパルは、基盤となるアプリケーションオーケストレーションプラットフォーム（例：Kubernetes）によって提供されるアイデンティティ（例：Service Account）であり、プロキシでネイティブにサポートされる認可ポリシーで用いるものと同一である。ユーザープリンシパルは通常、JWT から取得する。外部認可サーバーで一般的なアクセス制御モデルには、RBAC と ABAC がある。

4.6 Authorization Policy Elements

認可ポリシーに最低限含むべきポリシー要素を以下に示し、頭字語 APE-SR-X で番号付けする。ここで APE は認可ポリシー要素、SR はセキュリティ勧告、X は通し番号を表す。

APE-SR-1: 認可ポリシーは、少なくとも次の要素を含むべきである。

ポリシー種別：肯定（ALLOW）または否定（DENY）
ポリシーの対象（認可スコープ）：名前空間、特定サービス（アプリケーション名）、バージョン
ポリシーのソース：許可されたサービス集合
ポリシーの操作：ポリシーの対象リソースに対してカバーする操作
ポリシー条件：アプリケーションにとって、またはポリシー適用のために満たすべき、リクエストに紐づくメタデータ

4.6.1 Policy Types

肯定・否定のポリシーを指定するのは、優先関係（例：DENY が ALLOW に優先）を設定するためである。また、グループに属するすべてのサービスに対して一種のポリシーを適用し、例外を指定するような状況（例：ある名前空間内の全サービスには ALLOW ポリシーだが、特定サービスには DENY ポリシー）でも用いられる。

4.6.2 Policy Target or Authorization Scope

これは、サービス集合、バージョン、サービスが配置される名前空間の観点から、対象リソースを指す。サービスは次の方法で指定できる。

パスで指定：対象リソースの位置をパスで指定する（例：HTTP や gRPC でアクセスされるリソース）。認可ポリシーに含めるパス、および除外すべきパスの両方を定義できる。いずれも任意である。
ホスト名で指定：対象リソースを host サブ要素で指定する場合がある。認可ポリシーに含めるホスト、除外すべきホストの両方を定義できる。いずれも任意である。
ネットワークポートで指定：対象リソース（サービス）にアクセスするネットワークポートを port サブ要素で指定することが多い。認可ポリシーに含めるポート、除外すべきポートの両方を定義できる。いずれも任意である。

4.6.3 Policy Sources

ポリシーソースは、ポリシー対象（名前、パス、ホスト名、ポートで指定）上で操作を許可されるサービス集合である。通常、サービスアカウントや名前（プリンシパル）、ある論理グループ（例：名前空間）内の全サービス、あるいはネットワーク位置のグループ（例：IP ブロック）からアクセスされる全サービス、などで指定する。実装によっては、含める/除外するプリンシパル、名前空間、IP ブロックの双方を指定できる。

4.6.4 Policy Operations

APE-SR-2: ポリシーは、アプリケーション種別に属するすべての操作をカバーすべきである。例えば、アプリケーションが REST API として実装される場合、REST API に含まれるすべての操作（HTTP 動詞/HTTP メソッドとも呼ばれる）を含めなければならない。

POST：リソースの作成に相当\ GET：リソース内容の読み取りに相当\ PUT：リソースの置換による更新に相当\ PATCH：リソースの変更による更新に相当\ DELETE：リソースの削除に相当

リソースが REST ではなく gRPC でアクセスされる場合、操作（メソッド）は「POST」の 1 種類のみである。認可ポリシー定義には、除外すべき操作（メソッド）のリストを指定する機能があることも多い。認可ポリシースコープに含める操作と、除外する操作の両サブ要素はいずれも任意である。

4.6.5 Policy Conditions

ポリシー条件は、リクエストに紐づくメタデータについて、キー–バリューの形で制約を指定する。メタデータには次が含まれ得る。

ソースに関するメタデータ：サービスアカウント名、名前空間、IP ブロックなどの一部はポリシーソース指定の一部として与える。加えて、ポリシーソースの IP アドレスを CIDR 形式で列挙できる。
リクエストに関するメタデータ：特定リクエストに関するパラメータ/属性を指定する。これらには、認証情報を提示できる主体（audience。HTTP では URL 形式）、当該 audience に紐づく特定のエンドユーザー識別子、提示トークンに含まれるクレーム名が含まれ得る。さらに、HTTP リクエストではユーザーエージェント（例：ブラウザ名）に関するパラメータも指定可能である。
宛先に関するメタデータ：許容される IP アドレス範囲（CIDR 形式）や関連ポートのリストを指定できる。

4.6.6 Default Authorization Policy

APE-SR-3: 認証されていないすべてのリクエストを拒否し、すべてのリクエストにサービスおよびエンドユーザーの資格情報の存在を必須とし、アプリケーション自身の名前空間内のサービスへの通信のみを許可し、名前空間をまたぐサービス間通信は明示的なポリシーがある場合にのみ許可する、という内容のデフォルトポリシーをシステムに定義すべきである。

5 ABAC Deployment for Service Mesh

前節では、3 種類の認可ポリシーと、エンドユーザーレベル認可ポリシーの 2 つのユースケースを紹介した。本節では、それらのアーキテクチャ選択を踏まえ、サービスメッシュにおける ABAC ベースの認可フレームワークを記述する。

認可フレームワーク強制のためのセキュリティ保証
認可要求を支える基盤
サービスメッシュにおける ABAC 認可フレームワークの利点
プロキシでの強制方式の選択肢

5.1 Reference Monitor Concept in Authorization Framework

マイクロサービス型アプリケーションのためにサービスメッシュで実装される認可ポリシー強制機構は、リファレンスモニタ概念の 3 要件を満たさねばならない。すなわち、1）バイパス不可能、2）改変からの保護、3）正しさの検証・試験が可能、である。これら 3 要件は次で担保できる。

クライアントからマイクロサービス型アプリケーションへのリクエスト、サービス間（相互）呼び出し、マイクロサービスから外部アプリケーションへのリクエストのいずれも、順に Ingress ゲートウェイ、サイドカープロキシ、Egress プロキシによってインターセプトされる。これらの PEP はバイパス不可能である。
ポリシー強制モジュールはアプリケーションロジックから分離された独立実行体であり、改変不可能である。
それらの結果は、シャドウ運用と本番リクエストの双方で独立に検証・試験できる。

要するに、サービスメッシュのデータプレーンで動作するプロキシは、認可強制に関するリファレンスモニタである。認可ポリシーエンジン（例：NGAC ベースの ABAC ポリシーエンジン）は、プロキシのメモリ空間でネイティブに実行されるか、プロキシ内の対応フィルタモジュールから呼び出されるコンテナとして実行されるが、いずれにしても呼び出し元アプリケーションとメモリ空間を共有しない別プロセスとして動作する。したがって、セキュリティカーネルの要件を満たす。

5.2 Supporting Infrastructure for ABAC Authorization Framework

ここでは、サービス間（SVC-SVC）およびエンドユーザー＋サービス間（EU+SVC-SVC）リクエストのための基盤構成要素を概観する。

5.2.1 Service-to-Service Request (SVC-SVC) - Supporting Infrastructure

この種のリクエストに用いるポリシーオブジェクトは 4.5.1 節で述べた。サービス間リクエストは、呼び出し元サービスと呼び出し先サービスの両アイデンティティに基づいて認可されねばならない。サービスのアイデンティティを運搬する信頼できる文書は X.509 証明書であり、サービスメッシュのコントロールプレーン構成要素の 1 つが、アイデンティティレジストリを参照して要求されたアイデンティティがそのマイクロサービスに妥当かを検証した上で発行する。プロキシはローカルエージェントを介してこのコントロールプレーン構成要素と通信し、証明書を取得してプロキシへ送る。プロキシは、各サービスリクエスト時に呼び出し元サービスまたはクライアントに代わって証明書検証処理を行う。アイデンティティは URI としてエンコードされ、証明書の SAN（Subject Alternative Name）フィールドに格納される。サービスアカウントのアイデンティティを運ぶ証明書は、従来の HTTPS TLS 終端証明書（数か月有効）とは異なり、短命（1〜数時間でローテーション）である点に留意する。

5.2.2 End User + Service-to-Service Request (EU+SVC-SVC) - Supporting Infrastructure

この種のリクエストに用いるポリシーオブジェクトは 4.5.2 節で述べた。このリクエストタイプでは、呼び出しユーザーのアイデンティティとサービスのアイデンティティという 2 つのアイデンティティの検証を要する。前節で述べたように、サービスメッシュはサービスアイデンティティに基づく認可をサポートする機能を提供する。これは標準機能であるため、この種の認可のためにサービスメッシュ基盤に追加の構成要素を構築する必要はない。しかし、認可にエンドユーザーアイデンティティを導入する場合、認可フレームワークは次のアーキテクチャ構成要素と密接に統合されるべきである。

サービスオーケストレーションのコントロールプレーン：アプリケーションオブジェクト属性および登録済みアプリケーションユーザーの属性（ユーザー資格情報を含む）を取得する。ABAC の PIP としての役割を担う。
サービスメッシュのコントロールプレーン：アクセス判断に基づくクレームをエンコードしたトークンを取得する。
サービスメッシュのデータプレーン（サービスプロキシ）：認可エンジン（単なる別サービス）を呼び出してアクセス判断を取得し、サービス間認可ポリシーを強制し、コントロールプレーンに認可トークン（例：JWT）を要求し、トークンをサービスリクエストに添付する。

EU+SVC-SVC の処理方式の利点は、メソッドレベルより細粒度の認可を指定でき、適合するクレームを認可トークンに含められる点である。欠点は、SVC-SVC ポリシーに基づく層と EU+SVC-SVC ポリシーに基づく層という 2 層の認可強制に伴うオーバーヘッドである。第 2 層に基づくアクセス制御ロジックは、サービスプロキシからの複数の呼び出し（1）オーケストレーションシステムからユーザー属性（資格情報を含む）とアプリケーションオブジェクト属性を取得した後に認可エンジンサービスへアクセス判断を問い合わせ、（2）アクセス判断に基づいてサービスメッシュのコントロールプレーンから認可トークンを取得し、（3）そのトークンをサービスリクエストに添付する、を含む。

5.3 Advantages of ABAC Authorization Framework for Service Mesh

本節では、認可フレームワーク（例：サービスメッシュと NGAC ベースの ABAC モデル）における各構成要素の正当性を示し、プロキシ API や NGAC 認可エンジンのスケーラビリティや柔軟性を強調する。

a. 認可ポリシーの強制にサービスメッシュを用いるのが適切である。アプリケーションから分離された空間で構成要素を実行し、検証可能なセキュリティカーネルを形成できるためである。
b. SVC-SVC および EU+SVC-SVC の両認可要求は、オーケストレーションプラットフォームのコントロールプレーン、サービスメッシュのコントロールプレーン、メッシュのデータプレーンを認可エンジンへ結合する実行時基盤により処理できる。
c. プロキシの拡張 API を用いれば、任意のアクセス制御モデルの任意の認可エンジンを統合できる。ABAC は、主体・客体・環境に関連する属性を任意の数・種類で取り込めるため、最も柔軟でスケーラブルなアクセス制御モデルの 1 つである。
d. NGAC ベースの ABAC モデルはグラフに基づく線形時間の処理速度をもつため、認可エンジンの性能要件を満たす。
e. （c）の柔軟性を活用し、データ保護モデルを認可サーバーの一部として取り込むことで、アプリケーション保護とデータ保護の両モデルを組み込める。

5.4 Enforcement Alternatives in Proxies

認可は、当該サービスメッシュのバージョンがサポートするネイティブの構造（例：認可ポリシー）で強制するか、外部認可サーバーを呼び出して強制するかのいずれかである。外部認可サーバーは、任意のアクセス制御モデルやポリシー表現（論理規則や非循環グラフ表現）を用い得るが、プロキシへ到来するリクエストの仲裁は次の方法で行える。

a. 各リクエストをプロキシの外部認可フィルタを通じて外部認可サーバーへ転送し、サーバーの応答（ALLOW または DENY）を用いてリクエストを仲裁する。
b. 事前保存した ACL をプロキシ内で用いる。この ACL は認可サーバーへの呼び出しによって生成する。認可サーバーがエンタープライズ全体のアクセス制御モデルを用いる場合、管理 API が必要となることがある。この API は、プロキシがサービスする対象に合わせ、エンタープライズのリソースを当該サービスのリソース・ユーザー・グループへ写像して ACL を生成する機能を担う。

6 Summary and Conclusions

本書は、サービスメッシュを用いてマイクロサービス型アプリケーションを保護するための ABAC ベースの認可フレームワークの展開ガイダンスを提供した。2 章では、マイクロサービス型アプリケーションのオーケストレーションおよびリソース管理用の参照プラットフォームについて、その構成要素と機能に関する背景情報を示した。同章では、サービスメッシュ参照プラットフォームのアーキテクチャ層と機能についても記述した。3 章では、ABAC の背景情報を提供し、2 つの表現構造と関連する機能アーキテクチャを論じた。

4 章では、認証・認可フレームワークの構成要素—すなわち、アプリケーションに対する運用上の保証を提供するサービスメッシュ機能の設定/デフォルトに関する一連の勧告—を示し、特に認証・認可ポリシーの実装に焦点を当てた。勧告は、エンドユーザーおよびサービスレベルの両方の認証・認可ポリシーをサポートする仕組みにまたがる。さらに、認可ポリシーに最低限必要なポリシー要素も概説した。

5 章では、認可フレームワークにおけるリファレンスモニタ概念の存在、フレームワーク実装を支える基盤の記述、サービスメッシュが ABAC 認可フレームワークの実装に提供する利点、およびプロキシにおける強制方式の選択肢について述べた。

サービスメッシュを用いたマイクロサービス型アプリケーション向け ABAC ベースの認証・認可フレームワーク展開に関する全勧告一覧は、付録 A に示す。

参考文献 (References)

[1] Rose S, Borchert O, Mitchell S, Connelly S (2020) Zero Trust Architecture. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-207. https://doi.org/10.6028/NIST.SP.800-207
[2] Red Hat (2021) What is CI/CD? 入手先: https://www.redhat.com/en/topics/devops/what-is-cicd#:~:text=CI%2FCD%20is%20a%20method,continuous%20delivery%2C%20and%2 0continuous%20deployment
[3] Red Hat (2021) What is DevSecOps? 入手先: https://www.redhat.com/en/topics/devops/what-is-devsecops
[4] 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
[5] Hu VC, Ferraiolo DF, Chandramouli R, Kuhn DR (2018) Attribute-Based Access Control (Artech House, Boston USA).
[6] Chandramouli R, Butcher Z (2020) Building Secure Microservices-based Applications using Service-Mesh Architecture. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-204A. https://doi.org/10.6028/NIST.SP.800-204A
[7] McEvoy E (2019) Cordanetes: Combining Corda and Kubernetes (Medium.com). 入手先: https://medium.com/corda/combining-corda-and-kubernetes-4e2ba54494c7
[8] Ramakani A (2020) Kong API Gateway - From Zero to Production (Medium.com). 入手先: https://medium.com/swlh/kong-api-gateway-zero-to-production5b8431495ee
[9] Agarwal G (2020) How to Manage Microservices on Kubernetes With Istio (Medium.com). 入手先: https://medium.com/better-programming/how-to-managemicroservices-on-kubernetes-with-istio-c25e97a60a59
[10] Agarwal G (2020) How Istio Works Behind the Scenes on Kubernetes (Medium.com). 入手先: https://medium.com/better-programming/how-istio-works-behind-thescenes-on-kubernetes-aeb8003f2cb5
[11] InterNational Committee for Information Technology Standards (2020) INCITS 565-2020 - Information technology - Next Generation Access Control (INCITS, Washington, DC). 入手先: https://standards.incits.org/apps/group_public/project/details.php?project_id=2328
[12] Mell P, Shook J, Harang R, Gavrila S (2017) Linear Time Algorithms to Restrict Insider Access using Multi-Policy Access Control Systems. Journal of Wireless Mobile Networks, Ubiquitous Computing, and Dependable Applications 8(1):4-25. https://doi.org/10.22667/JOWUA.2017.03.31.004
[13] Ferraiolo D, Chandramouli R, Hu V, Kuhn R (2016) A Comparison of Attribute Based Access Control (ABAC) Standards for Data Service Applications: Extensible Access Control Markup Language (XACML) and Next Generation Access Control (NGAC) (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-178. https://doi.org/10.6028/NIST.SP.800-178
[14] Agarwal G (2020) Enable Mutual TLS Authentication between your Kubernetes Workloads Using Istio (Medium.com). 入手先: https://medium.com/betterprogramming/enable-mutual-tls-authentication-between-your-kubernetes-workloadsusing-istio-65338c8adf82
[15] Envoy (2021) External Authorization. 入手先: https://www.envoyproxy.io/docs/envoy/v1.17.0/intro/arch_overview/security/ext_authz_filter#arch-overview-ext-authz
[16] Envoy (2021) JWT Authentication. 入手先: https://www.envoyproxy.io/docs/envoy/v1.17.0/configuration/http/http_filters/jwt_authn_filter#config-http-filters-jwt-authn
[17] Hu VC, Ferraiolo DF, Kuhn DR, Schnitzer A, Sandlin K, Miller R, Scarfone K (2014) Guide to Attribute Based Access Control (ABAC) Definitions and Considerations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-162. https://doi.org/10.6028/NIST.SP.800-162

付録 A: サービスメッシュを用いたマイクロサービス型アプリケーション向け ABAC ベースの認証・認可フレームワーク展開に関する勧告一覧 (Appendix A)

TAG	勧告本文 (RECOMMENDATION TEXT)	フレームワーク領域 (FRAMEWORK AREA)
ISMC-SR-1	サービス呼び出しの認証に証明書ベースの認証を用いる場合、サービスメッシュの CA モジュールで用いる署名用証明書は、監査・ローテーション・失効を可能にするため、組織の既存 PKI にルート付けされているべきである。	初期サービスメッシュ構成 (Initial Service Mesh Configuration)
ISMC-SR-2	サービスメッシュのコントロールプレーンと、アプリケーションのオーケストレーション/リソース管理プラットフォームの構成サーバー間の通信は、認証され、かつ認可されていなければならない。	初期サービスメッシュ構成 (Initial Service Mesh Configuration)
A HLC-SR-1	コンテナおよびアプリケーションは root で実行すべきではない（特権コンテナ化を避ける）。Kubernetes では、'MustRunAsNonRoot' フラグを TRUE に設定する。	アプリケーション向け上位セキュリティ構成項目 (Higher-level Security Configuration Parameters for Applications)
A HLC-SR-2	HostPath ボリュームは使用すべきでない。これは、コンテナとホストノードの間に強い結合を生み、移行や柔軟なリソーススケジューリングを制約するためである。	アプリケーション向け上位セキュリティ構成項目 (Higher-level Security Configuration Parameters for Applications)
A HLC-SR-3	すべてのアプリケーションについて、コンテナのファイルシステムは既定で読み取り専用に構成すべきである（基盤アプリケーション、例：データベースがディスク書き込みを必要とする場合のみ例外とする）。Kubernetes では 'readOnlyRootFilesystem' フラグを TRUE に設定する。	アプリケーション向け上位セキュリティ構成項目 (Higher-level Security Configuration Parameters for Applications)
AHLC-SR-4	コンテナの権限昇格を明示的に防止する。Kubernetes では 'allowPrivilegeEscalation' フラグを FALSE に設定する。	アプリケーション向け上位セキュリティ構成項目 (Higher-level Security Configuration Parameters for Applications)

SAUN-SR-1	通信に mTLS を要求するサービスレベル認証に関するポリシーオブジェクトを定義すべきである。ポリシーオブジェクトは、下位レベルでのオーバーライドや上位レベルの要件の継承を可能にし、以下の最小レベルで定義できるだけの表現力を備えるべきである [6]。• グローバル（サービスメッシュ）レベル • 名前空間レベル • ワークロードまたはマイクロサービスレベル（特定のマイクロサービス、ホスト、ポートなど一部のトラフィック/リソースに認証・認可ポリシーを適用） • ポートレベル（特定のトラフィックが指定ポートで通信する設計を考慮）	サービスレベル認証 (Service-level Authentication)
SAUN-SR-2	mTLS に用いる証明書がサーバーアイデンティティを運ぶ場合、サービスメッシュは、サーバーアイデンティティを安全なディスカバリーサービスまたは DNS で提供されるマイクロサービス名へマッピングする安全なネーミングサービスを提供すべきである。これは、当該サーバーがマイクロサービスの正当な配置先であることを保証し、ネットワークハイジャックから保護するために必要である。	サービスレベル認証 (Service-level Authentication)
EAUN-SR-1	リクエスト認証ポリシーは、最低限、以下の情報を提供し、サイドカープロキシによって強制されなければならない。● 資格情報をリクエストから抽出する手順 ● 資格情報を検証する手順	エンドユーザーレベル認証 (End-user level Authentication)
SAUZ-SR-1	メッシュ内のすべてのサービスについて、サービス間アクセスを記述するポリシーオブジェクトを用意すべきである。最低限、これらのポリシーは名前空間レベルでアクセスを制限すべきであり（例：「名前空間 A のサービスは名前空間 B のサービスを呼び出せる」）、理想的には個々のサービスへのアクセスを制限すべきである（例：「名前空間 A のサービス Foo は名前空間 B のサービス Bar を呼び出せる」）。	サービスレベル認可 (Service-level Authorization)
EUAZ-SR-1	サイドカーが認証または認可システムと通信する場合、その通信は、メッシュ組み込みのサービス間認証・認可機能、またはサービスメッシュに含まれない既存のエンタープライズ IAM のいずれかによって保護されなければならない。	エンドユーザーレベル認可 (End-user level Authorization)

EUAZ-SR-2	サイドカーは、認証・認可ポリシーが強制されていることを確実にするため、すべてのサービスリクエストについてログを生成し、可用性に影響するサービス劣化が発生しないよう、メトリクス生成のためのテレメトリーデータを中継すべきである。	エンドユーザーレベル認可 (End-user level Authorization)
EUAZ-SR-3	すべてのアプリケーショントラフィックはエンドユーザーの資格情報を運搬すべきであり、資格情報の存在を強制するポリシーをメッシュに設定すべきである。	エンドユーザーレベル認可 (End-user level Authorization)
APE-SR-1	認可ポリシーは、少なくとも次の要素を含むべきである。● ポリシー種別（肯定：ALLOW／否定：DENY） ● ポリシー対象（認可スコープ：名前空間、特定サービス［アプリケーション名］、バージョン） ● ポリシーソース（許可されたサービス集合） ● ポリシー操作（対象リソースに対してカバーする操作） ● ポリシー条件（アプリケーションまたはポリシー適用のために満たすべき、リクエストに紐づくメタデータ）	認可ポリシー要素 (Authorization Policy Elements)
APE-SR-2	ポリシーはアプリケーション種別に属するすべての操作をカバーすべきである。例えば、アプリケーションが REST API として実装される場合、REST API に含まれるすべての操作（HTTP 動詞／HTTP メソッド）を含めなければならない：POST（作成）、GET（読み取り）、PUT（置換による更新）、PATCH（変更による更新）、DELETE（削除）。	認可ポリシー要素 (Authorization Policy Elements)
APE-SR-3	システムにはデフォルトポリシーを定義すべきである。これは、認証されていないすべてのリクエストを拒否し、すべてのリクエストでサービスおよびエンドユーザーの資格情報の存在を必須とし、アプリケーション自身の名前空間内のサービス間通信のみを許可し、名前空間をまたぐ通信は明示的ポリシーがある場合にのみ許可する、という内容である。	認可ポリシー要素 (Authorization Policy Elements)

NIST 特別刊行物 800-204B

サービス・メッシュを用いたマイクロサービス型アプリケーションの属性ベースアクセス制御