NIST SP 800-207A（ドラフト）マルチクラウド環境におけるクラウドネイティブ・アプリケーションにおけるアクセス制御のためのゼロトラストアーキテクチャモデル
こんにちは、丸山満彦です。
NISTが、SP 800-207A（ドラフト）マルチクラウド環境におけるクラウドネイティブ・アプリケーションにおけるアクセス制御のためのゼロトラストアーキテクチャモデルを公表し、意見募集をしています。。。
⚫︎ NIST - ITL
ニュース...
| A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Location Environments: NIST SP 800-207A Available for Comment | 多拠点環境におけるクラウドネイティブ・アプリケーションのアクセス制御のためのゼロトラストアーキテクチャ・モデル： NIST SP 800-207Aのコメントを受け付けている。 |
| The initial public draft of NIST Special Publication (SP) 800-207A, A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Location Environments, is now available for public comment. | NIST Special Publication (SP) 800-207A「多拠点環境におけるクラウド型アプリケーションのアクセス制御のためのゼロトラストアーキテクチャモデル」の初期公開ドラフトが、現在パブリックコメント用に公開されている。 |
| Enterprise application environments consist of geographically distributed and loosely coupled microservices that span multiple cloud and on-premises environments. They are accessed by a userbase from different locations through different devices. This scenario calls for establishing trust in all enterprise access entities, data sources, and computing services through secure communication and the validation of access policies. | エンタープライズのアプリケーション環境は、複数のクラウドやオンプレミス環境にまたがる、地理的に分散した疎結合のマイクロサービスから構成されている。これらのアプリケーションには、さまざまな場所からさまざまなデバイスを介してユーザーベースがアクセスする。このシナリオでは、安全な通信とアクセスポリシーの検証を通じて、すべてのエンタープライズアクセスエンティティ、データソース、コンピューティングサービスに対する信頼を確立する必要がある。 |
| Zero trust architecture (ZTA) and the principles on which it is built have been accepted as the state of practice for obtaining necessary security assurances, often enabled by an integrated application service infrastructure, such as a service mesh. ZTA can only be realized through a comprehensive policy framework that dynamically governs the authentication and authorization of all entities through status assessments (e.g., user, service, and requested resource. This guidance recommends: | ゼロトラストアーキテクチャ（ZTA）とその原理は、必要なセキュリティ保証を得るための実践状態として受け入れられており、多くの場合、サービスメッシュのような統合アプリケーションサービスインフラによって実現されている。ZTA は、ステータス評価（ユーザー、サービス、要求されたリソースなど）を通じて、すべてのエンティティの認証と認可を動的に管理する包括的なポリシーフレームワークによってのみ実現することができる。本ガイダンスでは、以下を推奨する： |
| ・The formulation of network-tier and identity-tier policies and | ・ネットワーク層および アイデンティティ層ポリシーの策定。 |
| ・The configuration of technology components that will enable the deployment and enforcement of different policies (e.g., gateways, infrastructure for service identities, authentication, and authorization tokens with the help of a central coordination infrastructure). | ・さまざまなポリシーの実装と実施を可能にする技術コンポーネントの構成（例：ゲートウェイ、中央調整基盤の助けを借りたサービスID、認証、認可トークンのための基盤など）。 |
文書
・[PDF] SP 800-207A (Draft)
エグゼクティブサマリー...
| Executive Summary | エグゼクティブサマリー |
| The principles of zero trust, as described in NIST Special Publication (SP) 800-207, have become the guiding markers for developing secure zero trust architecture. A well-established class of applications are cloud-native applications. The generally accepted characterization of a cloud native application includes the following: | NIST Special Publication (SP) 800-207に記載されているゼロトラストの原則は、安全なゼロトラストアーキテクチャを開発するための指針となる指標となっている。確立されたアプリケーションのクラスは、クラウドネイティブ・アプリケーションである。一般的に受け入れられているクラウドネイティブ・アプリケーションの特徴は、以下の通りである： |
| • The application is made up of a set of loosely coupled components called microservices. Each of the microservices can be hosted on different physical or virtual machines (VMs) and even be geographically distributed (e.g., within several facilities that belong to the enterprise, such as the headquarters, branch offices, and in various cloud service provider environments). | ・アプリケーションは、マイクロサービスと呼ばれる疎結合のコンポーネントの集合で構成されている。アプリケーションは、マイクロサービスと呼ばれる疎結合コンポーネントのセットで構成されている。マイクロサービスのそれぞれは、異なる物理マシンまたは仮想マシン（VM）でホストすることができ、地理的に分散していることもある（例えば、本社、支社、およびさまざまなクラウドサービスプロバイダ環境など、エンタープライズに属する複数の施設内など）。 |
| • Any transaction involving the application may also involve one or more inter-service (microservice) calls across the network. | ・また、アプリケーションを含むあらゆるトランザクションは、ネットワークを介した1つまたは複数のサービス間（マイクロサービス）コールを含む可能性がある。 |
| • A widespread feature (though not necessarily a requirement for cloud-native application) is the presence of a software platform called the service mesh that provides an integrated set of all application services (e.g., services discovery, networking connections, communication resilience, and security services like authentication and authorization). | ・クラウドネイティブ・アプリケーションの要件とは限らないが）広く普及している特徴は、すべてのアプリケーションサービス（サービス発見、ネットワーク接続、通信回復力、認証や認可などのセキュリティサービスなど）の統合セットを提供する、サービスメッシュと呼ばれるソフトウェアプラットフォームの存在である。 |
| The realization of a zero trust architecture for the above class of cloud-native applications requires a robust policy framework. In order to follow zero trust principles, the constituent polices in the framework should consider the following scenario: | 上記のようなクラスのクラウドネイティブ・アプリケーションに対してゼロトラストアーキテクチャを実現するには、強固なポリシーフレームワークが必要である。ゼロトラスト原則に従うためには、フレームワークの構成ポリシーは以下のシナリオを考慮する必要がある： |
| • There should not be implicit trust in users, services, or devices based exclusively on their network location, affiliation, or ownership. Hence, policy definitions and associated security controls based on the segmentation or isolation of networks using network parameters (e.g., IP addresses, subnets, perimeter) are insufficient. These policies fall under the classification of network-tier policies. | ・ネットワークの場所、所属、所有権にのみ基づいて、ユーザー、サービス、デバイスを暗黙のうちに信頼してはならない。したがって、ネットワークパラメータ（IPアドレス、サブネット、境界線など）を使用したネットワークの分割や分離に基づくポリシー定義や関連するセキュリティ制御は不十分である。これらのポリシーは、ネットワーク層ポリシーの分類に該当する。 |
| • To ensure the presence of zero trust principles throughout the entire application, networktier policies must be augmented with policies that establish trust in the identity of the various participating entities (e.g., users and services) irrespective of the location of the services or applications, whether on-premises or on multiple clouds. | ・アプリケーション全体を通してゼロトラスト原則が存在することを保証するために、ネットワーク層ポリシーは、オンプレミスまたは複数のクラウド上のサービスやアプリケーションの場所に関係なく、様々な参加エンティティ（ユーザーやサービスなど）のアイデンティティに対する信頼を確立するポリシーで補強する必要がある。 |
| This document provides guidance for realizing a zero trust architecture that can enforce granular application-level policies for cloud-native applications. The guidance is anchored in the following: | 本書は、クラウドネイティブ・アプリケーションにきめ細かいアプリケーションレベルのポリシーを適用できるゼロトラストアーキテクチャを実現するためのガイダンスを提供する。このガイダンスは、以下の点に軸足を置いている： |
| • A combination of network-tier and identity-tier policies | ・ネットワーク層とアイデンティティ層のポリシーの組み合わせ |
| • The components of cloud-native applications that enable the definition and deployment of those policies, such as edge, ingress, sidecar, and egress gateways; the creation, issuance, and maintenance of service identities; the issuance of authentication and authorization tokens that carry user identities in the enterprise application infrastructure that encompasses multi-cloud and hybrid environments | ・エッジ,イングレス,サイドカー、エグレスゲートウェイなどのポリシーの定義と実装を可能にするクラウドネイティブ・アプリケーションのコンポーネント、サービスIDの作成、発行、維持、マルチクラウドやハイブリッド環境を包含するエンタープライズアプリケーションインフラにおけるユーザーIDを運ぶ認証・認可トークンの発行など。 |
目次...
| Executive Summary | エグゼクティブサマリー |
| 1. Introduction | 1. はじめに |
| 1.1. Background – Zero Trust Principles and Zero Trust Architecture | 1.1. 背景：ゼロトラスト原則とゼロトラスト・アーキテクチャ |
| 1.2. Relationship to Other NIST Guidance Documents | 1.2. 他のNISTガイダンス文書との関係 |
| 1.3. Scope | 1.3. 適用範囲 |
| 1.4. Target Audience | 1.4. 想定読者 |
| 1.5. Organization of This Document | 1.5. 本書の構成 |
| 2. The Enterprise Cloud-Native Platform and its Components | 2. エンタープライズ・クラウドネイティブ・プラットフォームとその構成要素 |
| 2.1. Enterprise Infrastructure Layer | 2.1. エンタープライズ基盤層 |
| 3. Designing a Policy Framework for ZTA for Cloud-Native Application Environments | 3. クラウドネイティブ・アプリケーション環境におけるZTAのポリシーフレームワークの設計 |
| 3.1. Functional Components of Identity-Based Segmentation Policies for ZTA | 3.1. ZTAのアイデンティティに基づくセグメンテーション・ポリシーの機能的構成要素 |
| 3.2. Shortcomings of Identity-Based Segmentation Policies for Enterprise ZTA | 3.2. エンタープライズ向けZTAにおけるアイデンティティに基づくセグメンテーションポリシーの欠点 |
| 3.3. Multi-Tier Policies for Enterprise ZTA | 3.3. エンタープライズZTAの多層ポリシー |
| 4. Implementing Multi-Tier Policies for ZTA for Cloud-Native Application Environments | 4. クラウドネイティブ・アプリケーション環境向けZTAの多層ポリシーの実装 |
| 4.1. Reference Application Infrastructure Scenario | 4.1. 参照アプリケーション基盤のシナリオ |
| 4.2. Role of the Service Mesh in Policy Deployment, Enforcement, and Updates | 4.2. ポリシーの実装、施行、更新におけるサービスメッシュの役割 |
| 4.3. Policy Deployment for Reference Application Infrastructure. | 4.3. 参照アプリケーション基盤のポリシー実装 |
| 4.4. Another Application Infrastructure Scenario | 4.4. 別のアプリケーション基盤のシナリオ |
| 4.5. Functional Roles of Application Infrastructure Elements in Enforcing Policies | 4.5. ポリシーの適用におけるアプリケーション基盤要素の機能的役割 |
| 4.6. Comparison of Identity-Tier and Network-Tier Policies | 4.6. アイデンティティ層とネットワーク層のポリシーの比較 |
| 4.6.1. Approaches for Deployment and the Limitations of Network-Tier Policies | 4.6.1. ネットワーク層ポリシーの実装の考え方と限界について |
| 4.6.2. Prerequisites for the Deployment of Identity-Tier Policies | 4.6.2. アイデンティティ層ポリシーの実装に関する前提条件 |
| 4.6.3. Advantages of Identity-Tier Policies | 4.6.3. アイデンティティ層ポリシーの利点 |
| 5. Summary and Conclusions | 5. まとめと結論 |
| References | 参考文献 |
⚫︎ まるちゃんの情報セキュリティ気まぐれ日記
・2022.03.15 米国 CISA 意見募集 ゼロトラスト原則のエンタープライズ・モビリティへの適用 (2022.03.07)
・2021.09.09 米国 CISA 意見募集 ゼロトラスト成熟度モデル
・2021.06.30 金融庁 「ゼロトラストの現状調査と事例分析に関する調査報告書」の公表
・2021.03.01 米国国家安全保障局 (NSA) ゼロトラストセキュリティモデルに関するガイダンス
・2020.12.14 PwC Japanが「NIST SP800-207 「ゼロトラスト・アーキテクチャ」の解説と日本語訳」を公表していますね。。。
・2020.08.14 NIST SP 800-207 Zero Trust Architecture
・2020.02.14 NIST SP 800-207(Draft) Zero Trust Architecture (2nd Draft)
| Table of Contents | 目次 |
| Executive Summary | エグゼクティブサマリー |
| 1. Introduction | 1. はじめに |
| 1.1. Background – Zero Trust Principles and Zero Trust Architecture | 1.1. 背景：ゼロトラスト原則とゼロトラスト・アーキテクチャ |
| 1.2. Relationship to Other NIST Guidance Documents | 1.2. 他のNISTガイダンス文書との関係 |
| 1.3. Scope | 1.3. 適用範囲 |
| 1.4. Target Audience | 1.4. 想定読者 |
| 1.5. Organization of This Document | 1.5. 本書の構成 |
| 2. The Enterprise Cloud-Native Platform and its Components | 2. エンタープライズ・クラウドネイティブ・プラットフォームとその構成要素 |
| 2.1. Enterprise Infrastructure Layer | 2.1. エンタープライズ基盤層 |
| 3. Designing a Policy Framework for ZTA for Cloud-Native Application Environments | 3. クラウドネイティブ・アプリケーション環境におけるZTAのポリシーフレームワークの設計 |
| 3.1. Functional Components of Identity-Based Segmentation Policies for ZTA | 3.1. ZTAのアイデンティティに基づくセグメンテーション・ポリシーの機能的構成要素 |
| 3.2. Shortcomings of Identity-Based Segmentation Policies for Enterprise ZTA | 3.2. エンタープライズ向けZTAにおけるアイデンティティに基づくセグメンテーションポリシーの欠点 |
| 3.3. Multi-Tier Policies for Enterprise ZTA | 3.3. エンタープライズZTAの多層ポリシー |
| 4. Implementing Multi-Tier Policies for ZTA for Cloud-Native Application Environments | 4. クラウドネイティブ・アプリケーション環境向けZTAの多層ポリシーの実装 |
| 4.1. Reference Application Infrastructure Scenario | 4.1. 参照アプリケーション基盤のシナリオ |
| 4.2. Role of the Service Mesh in Policy Deployment, Enforcement, and Updates | 4.2. ポリシーの実装、施行、更新におけるサービスメッシュの役割 |
| 4.3. Policy Deployment for Reference Application Infrastructure. | 4.3. 参照アプリケーション基盤のポリシー実装 |
| 4.4. Another Application Infrastructure Scenario | 4.4. 別のアプリケーション基盤のシナリオ |
| 4.5. Functional Roles of Application Infrastructure Elements in Enforcing Policies | 4.5. ポリシーの適用におけるアプリケーション基盤要素の機能的役割 |
| 4.6. Comparison of Identity-Tier and Network-Tier Policies | 4.6. アイデンティティ層とネットワーク層のポリシーの比較 |
| 4.6.1. Approaches for Deployment and the Limitations of Network-Tier Policies | 4.6.1. ネットワーク層ポリシーの実装の考え方と限界について |
| 4.6.2. Prerequisites for the Deployment of Identity-Tier Policies | 4.6.2. アイデンティティ層ポリシーの実装に関する前提条件 |
| 4.6.3. Advantages of Identity-Tier Policies | 4.6.3. アイデンティティ層ポリシーの利点 |
| 5. Summary and Conclusions | 5. まとめと結論 |
| References | 参考文献 |
| List of Figures | 図表の一覧 |
| Fig. 1. Enterprise infrastructure layer for uniform policy deployment | 図1. 統一的なポリシー実装のためのエンタープライズ基盤層 |
| Fig. 2. Flexibility provided by multi-tier policies | 図2. 多層ポリシーがもたらす柔軟性 |
| Fig. 3. Multi-tier Policies for a Hybrid Application Environment | 図3. ハイブリッドアプリケーション環境における多層ポリシー |
| Fig. 4. An Istio Authorization Policy that allows Service 1 to Service 2 on port 443 but only allows it to execute the GET HTTP verb on the “/public” path | 図4. サービス1がポート443でサービス2にアクセスすることは許可するが、「/public」パスでのGET HTTP動詞の実行だけは許可するIstio Authorization Policy |
| Fig. 5. Policy Deployment for a Three-tier Application | 図5. 3層アプリケーションのためのポリシー実装 |
| Acknowledgments | 謝辞 |
| The author would like to express his thanks to Isabel Van Wyk of NIST for her detailed editorial review of the public comment version as well as the final publication. | また、パブリックコメント版および最終的な出版物の詳細な編集レビューを行ったNISTのIsabel Van Wykに感謝の意を表する。 |
| Executive Summary | エグゼクティブサマリー |
| The principles of zero trust, as described in NIST Special Publication (SP) 800-207, have become the guiding markers for developing secure zero trust architecture. A well-established class of applications are cloud-native applications. The generally accepted characterization of a cloud native application includes the following: | NIST Special Publication (SP) 800-207に記載されているゼロトラストの原則は、安全なゼロトラストアーキテクチャを開発するための指針となる指標となっている。確立されたアプリケーションのクラスは、クラウドネイティブ・アプリケーションである。一般的に受け入れられているクラウドネイティブ・アプリケーションの特徴は、以下の通りである： |
| • The application is made up of a set of loosely coupled components called microservices. Each of the microservices can be hosted on different physical or virtual machines (VMs) and even be geographically distributed (e.g., within several facilities that belong to the enterprise, such as the headquarters, branch offices, and in various cloud service provider environments). | ・アプリケーションは、マイクロサービスと呼ばれる疎結合のコンポーネントの集合で構成されている。アプリケーションは、マイクロサービスと呼ばれる疎結合コンポーネントのセットで構成されている。マイクロサービスのそれぞれは、異なる物理マシンまたは仮想マシン（VM）でホストすることができ、地理的に分散していることもある（例えば、本社、支社、およびさまざまなクラウドサービスプロバイダ環境など、エンタープライズに属する複数の施設内など）。 |
| • Any transaction involving the application may also involve one or more inter-service (microservice) calls across the network. | ・また、アプリケーションを含むあらゆるトランザクションは、ネットワークを介した1つまたは複数のサービス間（マイクロサービス）コールを含む可能性がある。 |
| • A widespread feature (though not necessarily a requirement for cloud-native application) is the presence of a software platform called the service mesh that provides an integrated set of all application services (e.g., services discovery, networking connections, communication resilience, and security services like authentication and authorization). | ・クラウドネイティブ・アプリケーションの要件とは限らないが）広く普及している特徴は、すべてのアプリケーションサービス（サービス発見、ネットワーク接続、通信回復力、認証や認可などのセキュリティサービスなど）の統合セットを提供する、サービスメッシュと呼ばれるソフトウェアプラットフォームの存在である。 |
| The realization of a zero trust architecture for the above class of cloud-native applications requires a robust policy framework. In order to follow zero trust principles, the constituent polices in the framework should consider the following scenario: | 上記のようなクラスのクラウドネイティブ・アプリケーションに対してゼロトラストアーキテクチャを実現するには、強固なポリシーフレームワークが必要である。ゼロトラスト原則に従うためには、フレームワークの構成ポリシーは以下のシナリオを考慮する必要がある： |
| • There should not be implicit trust in users, services, or devices based exclusively on their network location, affiliation, or ownership. Hence, policy definitions and associated security controls based on the segmentation or isolation of networks using network parameters (e.g., IP addresses, subnets, perimeter) are insufficient. These policies fall under the classification of network-tier policies. | ・ネットワークの場所、所属、所有権にのみ基づいて、ユーザー、サービス、デバイスを暗黙のうちに信頼してはならない。したがって、ネットワークパラメータ（IPアドレス、サブネット、境界線など）を使用したネットワークの分割や分離に基づくポリシー定義や関連するセキュリティ制御は不十分である。これらのポリシーは、ネットワーク層ポリシーの分類に該当する。 |
| • To ensure the presence of zero trust principles throughout the entire application, networktier policies must be augmented with policies that establish trust in the identity of the various participating entities (e.g., users and services) irrespective of the location of the services or applications, whether on-premises or on multiple clouds. | ・アプリケーション全体を通してゼロトラスト原則が存在することを保証するために、ネットワーク層ポリシーは、オンプレミスまたは複数のクラウド上のサービスやアプリケーションの場所に関係なく、様々な参加エンティティ（ユーザーやサービスなど）のアイデンティティに対する信頼を確立するポリシーで補強する必要がある。 |
| This document provides guidance for realizing a zero trust architecture that can enforce granular application-level policies for cloud-native applications. The guidance is anchored in the following: | 本書は、クラウドネイティブ・アプリケーションにきめ細かいアプリケーションレベルのポリシーを適用できるゼロトラストアーキテクチャを実現するためのガイダンスを提供する。このガイダンスは、以下の点に軸足を置いている： |
| • A combination of network-tier and identity-tier policies | ・ネットワーク層とアイデンティティ層のポリシーの組み合わせ |
| • The components of cloud-native applications that enable the definition and deployment of those policies, such as edge, ingress, sidecar, and egress gateways; the creation, issuance, and maintenance of service identities; the issuance of authentication and authorization tokens that carry user identities in the enterprise application infrastructure that encompasses multi-cloud and hybrid environments | ・エッジ,イングレス,サイドカー、エグレスゲートウェイなどのポリシーの定義と実装を可能にするクラウドネイティブ・アプリケーションのコンポーネント、サービスIDの作成、発行、維持、マルチクラウドやハイブリッド環境を包含するエンタープライズアプリケーションインフラにおけるユーザーIDを運ぶ認証・認可トークンの発行など。 |
| 1. Introduction | 1. はじめに |
| Zero trust (ZT) tenets or principles have been accepted as the guide markers for architecting all applications. There are several reasons why adherence to these tenets is critical for obtaining necessary security assurances, especially for cloud-native applications. The enterprise application environments for this class of applications is highly geographically distributed and span multiple cloud and on-premises environments (e.g., headquarters, enterprise-operated data centers, branch offices, etc.). Further, the user base consists of both remote and on-premises employees. These two features call for establishing trust in all of the data sources and computing services of the enterprise – irrespective of their location – through secure communication and the validation of access policies. | ゼロトラスト（ZT）の考え方や原則は、すべてのアプリケーションをアーキテクトするためのガイドマーカーとして受け入れられてきた。特にクラウドネイティブ・アプリケーションにおいて、必要なセキュリティ保証を得るために、これらの原則を遵守することが重要である理由はいくつかある。このクラスのアプリケーションのエンタープライズアプリケーション環境は、地理的に高度に分散しており、複数のクラウド環境やオンプレミス環境（本社、エンタープライズが運営するデータセンター、支社など）にまたがっている。さらに、ユーザーベースは、リモートとオンプレミスの両方の従業員で構成されている。この2つの特徴から、安全な通信とアクセスポリシーの検証を通じて、場所に関係なく、エンタープライズのすべてのデータソースとコンピューティングサービスに対する信頼を確立することが求められている。 |
| Apart from geographic distribution, another common feature of cloud-native applications is the presence of many microservices that are loosely coupled and collectively support business processes through extensive inter-service calls. This is augmented with an integrated infrastructure for providing all application services called the service mesh. These features emphasize the concept of identity for the various components of the application in the form of microservices as well as the users who access them through direct calls or clients (other services). This in turn highlights the critical need for authenticating these identities and for providing legitimate access on a per-session basis through a dynamic policy that takes the current status of the user, service, and requested asset into account. | 地理的な分布とは別に、クラウドネイティブ・アプリケーションのもう一つの共通点は、疎結合で、大規模なサービス間呼び出しによってビジネスプロセスをまとめてサポートする多数のマイクロサービスの存在である。これは、サービスメッシュと呼ばれるすべてのアプリケーションサービスを提供するための統合インフラで補強されている。これらの特徴は、マイクロサービスの形をしたアプリケーションの様々なコンポーネントと、直接の呼び出しやクライアント（他のサービス）を通じてそれらにアクセスするユーザーのアイデンティティの概念を強調するものである。そして、これらの本人認証と、ユーザー、サービス、要求されたアセットの現在の状態を考慮した動的なポリシーによって、セッション単位で正当なアクセスを提供することの重要な必要性が強調されているのである。 |
| The above requirements can only be met through a comprehensive policy framework. This document provides guidance for developing a policy framework that will form the foundation for realizing a zero trust architecture (ZTA) while incorporating zero trust principles into its design for cloud-native applications. The policy framework should also consist of a comprehensive set of policies that span all critical entities and resources in the application stack, including the network, network devices, users, and services. | 上記の要件は、包括的なポリシーフレームワークによってのみ満たすことができる。本書では、クラウドネイティブ・アプリケーションの設計にゼロトラスト原則を取り入れながら、ゼロトラストアーキテクチャ（ZTA）を実現するための基盤となるポリシーフレームワークを開発するためのガイダンスを提供する。また、ポリシーフレームワークは、ネットワーク、ネットワークデバイス、ユーザー、サービスなど、アプリケーションスタック内のすべての重要なエンティティやリソースにまたがる包括的なポリシーセットで構成する必要がある。 |
| 1.1. Background – Zero Trust Principles and Zero Trust Architecture | 1.1. 背景：ゼロトラスト原則とゼロトラスト・アーキテクチャ |
| A summary of the zero trust principles and the definition of a zero trust architecture, as described in NIST SP 800-207 [1], are: | NIST SP 800-207 [1]に記載されているゼロトラスト原則の概要とゼロトラストアーキテクチャの定義である： |
| • Zero trust is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources. It is a set of security primitives rather than a particular set of technologies. Zero trust assumes that there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or on asset ownership (e.g., enterprise or personally owned). Zero trust focuses on protecting resources (e.g., assets, services, workflows, network accounts) rather than network segments, as the network location is no longer seen as the prime component to the security posture of the resource. | ・ゼロトラストとは、防御を静的なネットワークベースの境界線から、ユーザ、資産、リソースに焦点を当て るようにする、進化する一連のサイバーセキュリティパラダイムを指す言葉である。これは、特定の技術セットではなく、セキュリティのプリミティブのセットである。ゼロトラストは、資産やユーザーアカウントに、物理的またはネットワーク上の場所（ローカルエリアネットワークとインターネットなど）や資産の所有権（エンタープライズ所有と個人所有など）に基づく暗黙の信頼がないことを前提としている。ゼロトラストは、ネットワークセグメントではなく、リソース（資産、サービス、ワークフロー、ネットワークアカウントなど）の保護に重点を置いており、ネットワークの位置がリソースのセキュリティ態勢の主要な構成要素とは見なされなくなる。 |
| • A zero trust architecture uses zero trust principles to plan industrial and enterprise infrastructures and workflows. | ・ゼロトラストアーキテクチャは,ゼロトラストの原則を使用して、産業およびエンタープライズの基盤とワークフローを計画する。 |
| NIST’s guidance on zero trust also contains an abstract definition of zero trust architecture and gives general deployment models and use cases with which zero trust could improve an enterprise’s overall information technology security posture. | ゼロトラストに関するNISTのガイダンスには、ゼロトラストアーキテクチャの抽象的な定義も含まれており、ゼロトラストがエンタープライズの全体的な情報技術セキュリティ姿勢を改善するための一般的な実装モデルや使用事例が示されている。 |
| 1.2. Relationship to Other NIST Guidance Documents | 1.2. 他のNISTガイダンス文書との関係 |
| Since the current document provides guidance for the realization of ZTA for cloud-native applications hosted in multiple locations (on-premises and multiple clouds) and the enforcement of ZT principles requires policies that are associated with various security services, it will be useful to refer to the following documents. These documents provide background information for the architecture of a microservices-based application with service mesh as well as guidance for configuring specific security services. The current document expands the reference environment to one where the IT application infrastructure of an enterprise spans multiple premises and multiple cloud provider locations as well as addresses the range of policies that are required for comprehensive security assurance. | 今回の文書では、複数の場所（オンプレミスや複数のクラウド）でホストされるクラウドネイティブ・アプリケーションのZTAを実現するためのガイダンスを提供しており、ZTの原則を実施するには、様々なセキュリティサービスに関連するポリシーが必要であるため、以下の文書を参照することが有用である。これらの文書は、サービスメッシュを備えたマイクロサービスベースのアプリケーションのアーキテクチャに関する背景情報と、特定のセキュリティサービスを構成するためのガイダンスを提供している。今回の文書では、参照環境を、エンタープライズのITアプリケーションインフラが複数の構内や複数のクラウドプロバイダーにまたがるものに拡大し、包括的なセキュリティ保証に必要なポリシーの範囲にも言及している。 |
| • NIST SP 800-204A, Building Secure Microservices-based Applications Using ServiceMesh Architecture [2], provides deployment guidance for various security services (e.g., establishment of secure sessions, security monitoring, etc.) for a microservices-based application using a dedicated infrastructure (i.e., a service mesh) based on service proxies that operate independently of the application code. | ・NIST SP 800-204A「サービスメッシュ・アーキテクチャによる安全なマイクロサービスベースのアプリケーションの構築」［2］は、アプリケーションコードから独立して動作するサービスプロキシに基づく専用インフラ（すなわち、サービスメッシュ）を使用して、マイクロサービスベースのアプリケーションに対する様々なセキュリティサービス（例えば、セキュリティセッションの確立、セキュリティモニタリングなど）の実装ガイダンスを提供している。 |
| • NIST SP 800-204B [3], Attribute-based Access Control for Microservices-based Applications Using a Service Mesh, provides deployment guidance for building an authentication and authorization framework within the service mesh that meets the security requirements. This may include establishing (1) zero trust by enabling mutual authentication in communication between any pair of services and (2) a robust access control mechanism based on an access control model (e.g., the attribute-based access control [ABAC] model) that can be used to express a wide set of policies and is scalable in terms of user base, objects (resources), and deployment environment. | ・NIST SP 800-204B 「サービスメッシュを用いたマイクロサービスベースのアプリケーションのための属性ベースのアクセス制御」[3]は、セキュリティ要件を満たすサービスメッシュ内の認証と認可のフレームワークを構築するための導入ガイダンスを提供する。これには、(1)任意のサービスペア間の通信で本人認証を可能にすることによるゼロトラストの確立、(2)幅広いポリシーを表現するために使用でき、ユーザーベース、オブジェクト（リソース）、実装環境の点で拡張可能なアクセス制御モデル（例えば、属性ベースのアクセス制御［ABAC］モデル）に基づく堅牢なアクセス制御メカニズム、が含まれると考えられる。 |
| 1.3. Scope | 1.3. 適用範囲 |
| The scope of this document includes: | 本書のスコープは以下の通りである： |
| • Identifying the requirements for realizing a ZTA for granular access control in microservices-based application platforms that include a service mesh infrastructure | ・サービスメッシュ基盤を含むマイクロサービスベースのアプリケーションプラットフォームにおいて、きめ細かなアクセス制御を実現するためのZTAを実現するための要件を特定すること。 |
| • Identifying the infrastructural elements that should be part of the platform in order to configure and implement ZT principles | ・ZTの原則を構成し実装するために、プラットフォームの一部となるべき基盤要素を特定する。 |
| • Guidance for deploying a ZTA in the above platform and outlining the security assurances that the deployment can provide | ・上記のプラットフォームにZTAを実装するためのガイダンスと、実装によって提供できるセキュリティ保証の概要を説明する。 |
| 1.4. Target Audience | 1.4. 想定読者 |
| This guidance is intended for security architects and infrastructure designers in organizations with a hybrid IT environment (consisting of both on-premises and multiple cloud-based applications) with a combination of legacy and microservices-based (i.e., cloud-native) applications with a built-in application services infrastructure, such as a service mesh. | このガイダンスは、レガシーアプリケーションとマイクロサービスベース（すなわち、クラウドネイティブ）アプリケーションの組み合わせで、サービスメッシュなどのアプリケーションサービス基盤が組み込まれたハイブリッドIT環境（オンプレミスと複数のクラウドベースアプリケーションの両方からなる）を持つ組織におけるセキュリティ設計者とインフラ設計者向けである。 |
| 1.5. Organization of This Document | 1.5. 本書の構成 |
| The organization of this document is as follows: | 本書の構成は、以下のとおりである： |
| • Section 2 describes a modern enterprise cloud-native application platform that includes a dedicated infrastructure for providing all application services as well as a management plane when the application spans both on-premises and multiple cloud service provider locations. | ・セクション2では、アプリケーションがオンプレミスと複数のクラウドサービスプロバイダーの両方にまたがっている場合の管理プレーンと同様に,すべてのアプリケーションサービスを提供するための専用基盤を含む最新のエンタープライズ・クラウドネイティブ・アプリケーションプラットフォームについて説明する。 |
| • Section 3 introduces the basic concepts of a policy framework for ZTA for the platform described in the previous section in terms of drivers and design requirements. It also provides an analysis of identity-based policies and introduces the concept of multi-tier policies. | ・セクション3では、前セクションで説明したプラットフォーム向けのZTA用ポリシーフレームワークの基本概念を、ドライバーと設計要件の観点から紹介する。また、IDベースのポリシーの分析を行い、多層ポリシーの概念も紹介する。 |
| • Section 4 describes the implementation approach for deploying multi-tier policies for two enterprise application infrastructure scenarios by outlining the roles of the service mesh, the functional components involved, and the advantages of identity-tier policies, which provide service-level segmentation and play a critical role in the security assurance of an application ecosystem to conform to zero trust principles or tenets. | ・セクション4では、サービスメッシュの役割、関係する機能コンポーネント、およびサービスレベルのセグメンテーションを提供し、ゼロトラスト原則または信条に適合するアプリケーションエコシステムのセキュリティ保証において重要な役割を果たすアイデンティティ層ポリシーの利点を概説し、2つのエンタープライズアプリケーション基盤シナリオに対して多層ポリシーを実装する実装アプローチを説明する。 |
| • Section 5 provides a summary and conclusion. | ・セクション5では、要約と結論を述べる。 |
| 2. The Enterprise Cloud-Native Platform and its Components | 2. エンタープライズ・クラウドネイティブ・プラットフォームとその構成要素 |
| An enterprise cloud-native platform is increasingly made up of microservices that are implemented as containers and hosted on a container orchestration platform. In addition, it has a dedicated infrastructure layer called a service mesh, which provides a comprehensive set of application services (e.g., network connectivity, network resilience, observability, and security). The application services provided by a service mesh are enabled by the following: | エンタープライズ・クラウドネイティブ・プラットフォームは、コンテナとして実装され、コンテナオーケストレーション・プラットフォーム上でホストされるマイクロサービスで構成されるようになってきている。さらに、サービスメッシュと呼ばれる専用の基盤層を持ち、アプリケーションサービス（ネットワーク接続性、ネットワーク回復力、観測性、セキュリティなど）を包括的に提供する。サービスメッシュが提供するアプリケーションサービスは、以下によって実現される： |
| • A built-in infrastructure for (a) providing service identities, (b) service discovery, and (c) external policy-based authorization engines based on Next Generation Access Control (NGAC), Attribute-based Access Control (ABAC), and Open Policy Agent (OPA) | ・(a)サービスIDの提供、(b)サービスの発見、(c)次世代アクセスコントロール（NGAC）、属性ベースアクセスコントロール（ABAC）、オープンポリシーエージェント（OPA）に基づく外部ポリシーベースの認可エンジンのための組み込みインフラ。 |
| • Code for performing network-related functions (e.g., traffic routing) and for ensuring network resiliency through functions such as retries, timeouts, blue-green deployments, and circuit breaking | ・ネットワーク関連機能（トラフィックルーティングなど）を実行し、再試行、タイムアウト、ブルーグリーン実装、回線切断などの機能によりネットワークの回復力を確保するためのコード。 |
| • Code for ensuring application integrity and confidentiality through service-to-service and user-to-resource authentications and authorizations | ・サービス間およびユーザー間の認証と権限付与により,アプリケーションの整合性と機密性を確保するためのコード |
| More details on the container orchestration platform with an integrated service mesh can be found in [2], and an access control implementation in that platform is described extensively in [3]. | サービスメッシュを統合したコンテナオーケストレーションプラットフォームの詳細は[2]に、同プラットフォームにおけるアクセスコントロールの実装は[3]に幅広く記載されている。 |
| In the modern enterprise, the platform described above is present in both on-premises data centers and multiple cloud service locations. Assuming that a service mesh instance is deployed for managing a single cluster that consists of the above platforms, there will be multiple clusters spread over multiple on-premises sites and multiple availability zones in different clouds. Consequently, there will be multiple service mesh instances. | 現代のエンタープライズでは、上記のようなプラットフォームがオンプレミスのデータセンターと複数のクラウドサービスの両方に存在する。上記のプラットフォームで構成される1つのクラスタを管理するためにサービスメッシュ・インスタンスが導入されると仮定すると、複数のオンプレミスサイトと異なるクラウドの複数の可用性ゾーンに複数のクラスタが散在することになる。その結果、複数のサービスメッシュ・インスタンスが存在することになる。 |
| Each service mesh instance has two main logical components: 1) a control plane that implements the APIs needed to define various configurations and policies that govern access between various microservices in that cluster and 2) a data plane that enforces those policies at runtime. However, a uniform set of policies is also needed to govern access between any pair of microservices or services in the enterprise irrespective of their location or the service mesh instance of which they are a part. This requires a global control plane that can define a uniform set of policies applicable to the entire set of services that operate in the enterprise and disseminate them to the control planes of the individual service mesh instances. | 各サービスメッシュ・インスタンスには、主に2つの論理コンポーネントがある： 1）クラスタ内のさまざまなマイクロサービス間のアクセスを制御するさまざまな設定やポリシーを定義するために必要なAPIを実装する制御プレーンと、2）実行時にこれらのポリシーを実行するデータプレーンである。しかし、エンタープライズ内のあらゆるマイクロサービスやサービスのペア間のアクセスを、それらの位置やそれらが属するサービスメッシュ・インスタンスに関係なく制御するために、統一されたポリシーのセットも必要である。このため、エンタープライズ内で動作するサービスのセット全体に適用されるポリシーの統一セットを定義し、個々のサービスメッシュ・インスタンスの制御プレーンにそれを配布できるグローバル制御プレーンが必要である。 |
| It is technically possible to have a single service mesh control plane instance (i.e., single service mesh instance) that manages multiple clusters spanning multiple environments (i.e., on-premises and on clouds). However, this architecture may make the multiple clusters a single failure domain and potentially defeat the very purpose of designing a multi-cluster configuration (i.e., availability). Thus, running a service mesh control plane instance for each cluster isolates the failure domain and improves availability and scalability. Further, providing the required underlying network connectivity to facilitate every workload (since each workload or application instance has an associated sidecar proxy that forms the data plane) to communicate with a single control plane instance is untenable in most enterprise environments and impossible in many government ones (e.g., air-gapped systems). | 複数の環境（すなわち、オンプレミスとクラウド上）にまたがる複数のクラスタを管理する単一のサービスメッシュ制御プレーンインスタンス（すなわち、単一のサービスメッシュ・インスタンス）を持つことは、技術的に可能である。しかし、このアーキテクチャでは、複数のクラスタが単一障害ドメインとなり、マルチクラスタ構成を設計する目的（すなわち、可用性）そのものが失われる可能性がある。そこで、各クラスタに対してサービスメッシュの制御プレーン・インスタンスを実行することで、障害領域を分離し、可用性と拡張性を向上させることができる。さらに、すべてのワークロード（各ワークロードまたはアプリケーションインスタンスには、データプレーンを形成する関連するサイドカープロキシがあるため）が単一の制御プレーンインスタンスと通信できるように、必要な基礎的ネットワーク接続を提供することは、ほとんどのエンタープライズ環境では不可能であり、多くの政府環境（例えば、エアギャップシステム）では不可能である。 |
| 2.1. Enterprise Infrastructure Layer | 2.1. エンタープライズ基盤層 |
| The global control plane forms an integral part of the enterprise infrastructure layer. The management plane that contains the various interfaces is hosted within the global control plane. The roles of the global control plane and the management plane are as follows: | グローバル制御プレーンは、エンタープライズ基盤層の不可欠な部分を形成している。様々なインタフェースを含む管理プレーンは、グローバル制御プレーン内でホストされる。グローバル制御プレーンと管理プレーンの役割は次のとおりである： |
| • The global control plane can be leveraged to perform the functions of individual control planes at the enterprise level rather than at the cluster level (e.g., issuing identities to all services in the enterprise by leveraging the enterprise PKI system). | ・グローバル制御プレーンは、個々の制御プレーンの機能をクラスタレベルではなく、エンタープライズレベルで実行するために活用できる（例えば、エンタープライズPKIシステムを活用して、エンタープライズ内のすべてのサービスにIDを発行することができるなど）。 |
| • The management plane provides the human-computer interfaces (e.g., user interfaces, such as command line interfaces and APIs) that enable enterprise-level systems to work by encoding organizational processes related to the usage of various tools (e.g., policy definition and evaluation tools, telemetry tools, etc.) at the lower layer. | ・管理プレーンは、下位層の各種ツール（ポリシー定義・評価ツール、テレメトリツールなど）の使用に関する組織プロセスをコード化することで、エンタープライズレベルのシステムを機能させるためのヒューマン・コンピュータ・インターフェース（コマンドラインインターフェースやAPIなどのユーザーインターフェースなど）を提供する。 |
| In short, the management plane enables the definition and deployment of consistent and uniform policies for all services throughout the enterprise. In addition to the global control plane and management plane, the enterprise infrastructure for a ZTA consists of local control planes (associated with service mesh instances) and a set of various types of proxies that form part of their respective data planes. The proxies act as the policy enforcement points (PEPs) and have three types: | つまり、管理プレーンは、エンタープライズ内のすべてのサービスに対して、一貫性のある統一されたポリシーを定義し、実装することを可能にする。グローバル制御プレーンと管理プレーンに加えて、ZTAのエンタープライズ基盤は、ローカル制御プレーン（サービスメッシュ・インスタンスに関連）と、それぞれのデータプレーンの一部を形成する様々なタイプのプロキシセットで構成されている。プロキシは、ポリシー実施ポイント（PEP）として機能し、3つのタイプがある： |
| 1. Ingress proxies enforce policies for entering user or service requests from client applications that originate outside of the cluster into any service within the cluster. | 1. イングレスプロキシは、クラスタの外部で発生したクライアントアプリケーションからのユーザーまたはサービス要求を、クラスタ内の任意のサービスに入力するためのポリシーを実施する。 |
| 2. Side-car proxies enforce policies between intra-cluster services. | 2. サイドカープロキシは、クラスタ内のサービス間でポリシーを実施する。 |
| 3. Egress proxies enforce policies for requests that emanate from any service within the cluster to an external application that is outside of the cluster. | 3. イグレスプロキシは、クラスタ内の任意のサービスからクラスタの外部にある外部アプリケーションに発せられるリクエストに対してポリシーを適用する。 |
| Figure 1 shows a schematic diagram of the entire infrastructure layer for uniform (enterprisewide) policy deployment for realizing a ZTA: | 図1は、ZTAを実現するための統一的な（全社的な）ポリシー実装のためのインフラ層全体の模式図である： |
 |
|
| Fig. 1. Enterprise infrastructure layer for uniform policy deployment | 図1. 統一的なポリシー実装のためのエンタープライズ基盤層 |
| 3. Designing a Policy Framework for ZTA for Cloud-Native Application Environments | 3. クラウドネイティブ・アプリケーション環境におけるZTAのポリシーフレームワークの設計 |
| Based on the set of zero trust principles and some strawman ZTAs provided in [1], the following driver assumptions were formulated for realizing a ZTA for an enterprise cloud-native application environment (i.e., a set of microservices in various clusters with each cluster managed by a service mesh and augmented with an enterprise-level infrastructure that consists of a global control plane and management plane). These driver assumptions are: | [1]で提供された一連のゼロトラスト原則といくつかのストローマンZTAに基づき、エンタープライズのクラウドネイティブ・アプリケーション環境（すなわち、各クラスタがサービスメッシュによって管理され、グローバル制御プレーンと管理プレーンからなるエンタープライズレベルのインフラで強化された、さまざまなクラスタ内の一連のマイクロサービス）用のZTAを実現するための次のドライバー前提が策定されました。これらのドライバーの前提は以下の通りである： |
| • Trust can no longer be based on a network perimeter as perimeters can always be breached. | ・ネットワーク境界は常に破られる可能性があるため、信頼はもはやネットワーク境界に基づくことができない。 |
| • Policies have to be defined based on the assumption that the attacker is already inside of the corporate network. | ・攻撃者はすでにエンタープライズネットワークの内部にいるという前提でポリシーを定義する必要がある。 |
| • All access decisions have to rely on least-privilege, per-request, and context-based principles and on identities associated with users, services, and devices. This results in a form of runtime isolation for applications, which this document refers to as “identitybased segmentation.” | ・すべてのアクセス判断は、最小特権。リクエスト単位。コンテキストベースの原則とユーザー、サービス、デバイスに関連付けられたアイデンティティに依存しなければならない。この結果、アプリケーションのランタイム分離が行われ、本文書では「IDベースのセグメンテーション」と呼んでいる。 |
| The above driver assumptions provide the design requirements for a ZTA as follows: | 上記のドライバーの仮定は、以下のようにZTAの設計要件を提供する： |
| • No single component or function is sufficient to implement ZTA. Rather, they must collectively enforce zero trust principles across all applications in the infrastructure. | ・ZTAを実装するには,単一のコンポーネントや機能では不十分である。ZTAを実装するのに十分な単一のコンポーネントや機能はなく、基盤内のすべてのアプリケーションにゼロトラスト原則を一括して適用する必要がある。 |
| • ZTA component functions should be clearly articulated, including their interrelationships and workflows. | ・ZTAを実装するには,単一のコンポーネントや機能では不十分であり、基盤内のすべてのアプリケーションにゼロトラスト原則を一括して適用しなければならない。ZTAコンポーネント機能は相互関係やワークフローを含めて明確に表現されるべきである。 |
| The enforcement infrastructure that implements the security controls (mainly consisting of PEPs) should satisfy the properties of a security kernel – always invoked (nonbypassable), verifiable, and independent of the application code. | セキュリティ管理（主にPEPで構成）を実施する実施基盤は、セキュリティカーネルの特性（常に起動され（バイパス不可能）、検証可能で、アプリケーションコードから独立している）を満たす必要がある。 |
| • The core tenant or primary function of ZTA at runtime is implementing an identity-based segmentation of applications that leverages the enforcement infrastructure. | ・実行時のZTAのコアテナントまたは主要機能は,実施インフラを活用したアプリケーションのIDベースのセグメンテーションを実装することである。 |
| 3.1. Functional Components of Identity-Based Segmentation Policies for ZTA | 3.1. ZTAのアイデンティティに基づくセグメンテーション・ポリシーの機能的構成要素 |
| The following policy checks should be implemented at runtime through the deployment of identity-tier policies in order to realize identity-based segmentation: | ID ベースのセグメンテーションを実現するために、アイデンティティ層ポリシーの実装により、以下のポリシーチェックを実行時に実装する必要がある： |
| • ID-SEG-REC-1: Encrypted connection between service endpoints – Service endpoints can be located in different subnets, different availability zones or regions in a cloud provider environment, in different clouds, or on-premises. Wherever they are located, communication between any two should be encrypted to ensure eavesdropping protection and message authenticity. | ・ID-SEG-REC-1: サービスエンドポイント間の暗号化接続 ・サービスエンドポイントは、クラウドプロバイダー環境内の異なるサブネット、異なるアベイラビリティゾーンまたはリージョン、異なるクラウド、またはオンプレミスに配置することができる。どのような場所であっても、両者間の通信は、盗聴防止とメッセージの認証を確保するために暗号化されるべきである。 |
| • ID-SEG-REC-2: Service authentication – Each service should present a short-lived cryptographically verifiable identity to other services that is authenticated per connection and reauthenticated regularly. | ・ID-SEG-REC-2: サービス認証 ・各サービスは、接続ごとに認証され、定期的に再認証される、短命の暗号的に検証可能なIDを他のサービスに提示す必要がある。 |
| Note on the above recommendation: In an ideal situation, services would be authenticated for each service request. Since this is highly disruptive from the point of view of application transaction response, this authentication is accomplished at the connection level via mutual TLS (mTLS) when a service makes an initial connection establishment as part of its inter-service call. This authentication is not performed again in subsequent calls. However, the security of this operation is ensured by not allowing the connections to be very long (usually as long as the TTL of the service’s identity certificate or as short as 15-30 minutes, depending on the configuration). | 上記の推奨事項に関する注意事項： 理想的な状況では、サービスはサービス要求ごとに認証される。これはアプリケーションのトランザクションレスポンスの観点から非常に破壊的であるため、この認証は、サービスがサービス間呼び出しの一部として最初の接続確立を行う際に、相互TLS（mTLS）を介して接続レベルで達成される。この本人認証は、その後の呼び出しでは再び実行されることはない。ただし、この操作のセキュリティは、接続があまり長くならないようにすることで確保される（通常、サービスのID証明書のTTLと同じか、構成によっては15～30分と短い）。 |
| • ID-SEG-REC-3: Service to service authorization – Services should leverage runtime service identity (ID-SEG-REC-2) to enforce granular policies and have the capability to call external authorization services if the mesh level proxies are insufficient to enforce dynamic authorization policies. | ・ID-SEG-REC-3: サービス間の認可 ・サービスは、ランタイムサービスアイデンティティ（ID-SEG-REC-2）を活用してきめ細かいポリシーを実施し、メッシュレベルのプロキシでは動的認可ポリシーを実施するには不十分な場合に外部の認可サービスを呼び出す機能を持つべきである。 |
| • ID-SEG-REC-4: End-user authentication – Since all application requests are triggered by user actions, a robust identity management system is required to assign and maintain user identities and enforce robust protocols with phishing-resistant multi-factor (MFA) authentication. This system should be used to issue a cryptographically verifiable runtime token that represents the user principal to the rest of the infrastructure (e.g., a JSON Web Token [JWT]), and services should authenticate the credential at each hop. | ・ID-SEG-REC-4：エンドユーザー認証 ・すべてのアプリケーションのリクエストはユーザーのアクションによって引き起こされるため、ユーザーIDを割り当て、維持し、フィッシングに強い多要素（MFA）認証で堅牢なプロトコルを実施するために堅牢なID管理システムが必要である。このシステムは、基盤の他の部分に対して、ユーザープリンシパルを表す暗号的に検証可能な実行時トークン（例えば、JSON Web Token [JWT]）を発行するために使用されるべきで、サービスは各ホップでクレデンシャルを認証する必要がある。 |
| Note on the above recommendation: Authenticating the user in session at every hop is impractical at scale. Therefore, NIST recommends using short-lived end-user credentials (e.g., OAuth 2.0 tokens) for external users and exchanging them for a locally authenticatable token, like a JWT, that is authenticated at each hop. | 上記の推奨事項に関する注意事項： 各ホップでセッション中のユーザーを認証することは、規模的に非現実的である。したがって、NISTは、外部ユーザーには短命のエンドユーザー認証情報（OAuth 2.0トークンなど）を使用し、各ホップで認証されるJWTのようなローカルに認証可能なトークンと交換することを推奨する。 |
| • ID-SEG-REC-5: End-user to resource authorization – As part of each service access request, the system must ensure that the authenticated end user principal (ID-SEG-REC4) is authorized to act on the resources designated in the request. This authorization may be performed by the application itself or checked locally (e.g., by checking against a set of claims in a JWT) or externally against an authorization system’s policy decision point. Enforcing end user authorization via the service mesh’s sidecar PEP is particularly effective [3]. | ・ID-SEG-REC-5: エンドユーザからリソースへの認可 ・各サービスアクセス要求の一部として、システムは認証されたエンドユーザ本人（ID-SEG-REC4）が要求で指定されたリソース上で行動することを認可されていることを確認しなければならない。この認可は、アプリケーション自体によって実行されるか、ローカルにチェックされるか（例えば、JWT内の一連のクレームと照合することによって）、認可システムのポリシー決定ポイントに対して外部にチェックされるかもしれない。サービスメッシュのサイドカーPEPを介してエンドユーザの認可を強制することは、特に効果的である[3]。 |
| Context for the application of these policy recommendations and the improved security assurance that emanates from their deployment and enforcement are explained in [2] and [3]. | これらのポリシー勧告の適用に関するコンテキストと、その実装と実施から生じるセキュリティ保証の改善については、[2]と[3]で説明されている。 |
| 3.2. Shortcomings of Identity-Based Segmentation Policies for Enterprise ZTA | 3.2. エンタープライズ向けZTAにおけるアイデンティティに基づくセグメンテーションポリシーの欠点 |
| While identity-based segmentation is powerful, purely identity-based policies cannot currently be adopted due to the following scenarios: | IDベースのセグメンテーションは強力であるが、以下のようなシナリオがあるため、純粋なIDベースのポリシーは現在採用できない： |
| • Identity-based segmentation policies can include access scenarios that cover all origins, such as users, services, and all target resources that consist of services and data. However, enterprise scenarios that involve both on-premises and cloud-based applications require identification of the location of those resources using network parameters. Purely identity-based enforcement should by augmented by other factors (e.g., network location) to evaluate risk when performing context-based authorization. | ・アイデンティティベースのセグメンテーションポリシーは、ユーザー、サービス、サービスやデータからなるすべての対象リソースなど、すべての起点をカバーするアクセスシナリオを含むことができる。しかし、オンプレミスとクラウドベースのアプリケーションの両方を含むエンタープライズシナリオでは、ネットワークパラメータを使用してこれらのリソースの場所を特定する必要がある。コンテキストベースの認可を実行する際には、リスクを評価するために他の要因（ネットワークの場所など）により、純粋なIDベースの施行が補強される必要がある。 |
| • A subset of identity-based segmentation policies (i.e., service identity-based) can be difficult to administer since service identity assignments are often based on specific domains, which makes consistent policy deployment difficult across on-premises systems, cloud-based systems, and different compute runtimes. However, this is mitigated by adopting consistent service names across the infrastructure using the concept of a universal identity domain, as recommended in SM-DR11 of [2]. | ・サービス ID の割り当てが特定のドメインに基づいていることが多いため、オンプレミスシステム、クラウドベースのシステム、および異なるコンピュートランタイム間で一貫したポリシーの実装が難しく、ID ベースのセグメント化ポリシーのサブセット（すなわち、サービス ID ベース）の管理が困難な場合がある。しかし、[2]のSM-DR11で推奨されているように、ユニバーサル・アイデンティティ・ドメインの概念を用いてインフラ全体で一貫したサービス名を採用することで、これを緩和することができる。 |
| • Having network-level policies alone requires high maintenance due to the continuous changes to their location parameters as containers and virtualized workloads are frequently migrated for availability and performance reasons (e.g., migration to different VMs or to a different pod in containerized applications). | ・ネットワークレベルのポリシーを持つだけでは,コンテナや仮想化ワークロードが可用性とパフォーマンスの理由で頻繁に移行されるため(例えば,コンテナ化アプリケーションにおける異なるVMや異なるポッドへの移行),その位置パラメータが継続的に変更され,高いメンテナンスが必要となる。 |
| Network-oriented policies cannot be completely eliminated given current compliance requirements and regulations. However, relaxing requirements at the network level in exchange for introducing more descriptive policy at the identity level could lead to an improved overall security posture compared to network-oriented security alone. | 現在のコンプライアンス要件や規制を考えると、ネットワーク指向のポリシーを完全に排除することはできません。しかし、ID レベルでより記述的なポリシーを導入する代わりに、ネットワーク・レベルの要件を緩和することで、ネットワーク指向のセキュリティだけと比較して、全体的なセキュリティ態勢を改善することができる。 |
| 3.3. Multi-Tier Policies for Enterprise ZTA | 3.3. エンタープライズZTAの多層ポリシー |
| A successful enterprise ZTA requires multi-tier policies: | エンタープライズZTAを成功させるには、多層のポリシーが必要である： |
| • Network-tier policies – Allowed communication between enterprise network elements (e.g., firewall rules, which are relatively static) | ・ネットワーク層ポリシー ・エンタープライズネットワーク要素間の通信を許可（例：ファイアウォールルール、比較的静的なもの）。 |
| Identity-tier policies – Access scope for services and resources based on service and user identities (e.g., dynamic application-to-application communication rules based on identities through a dedicated infrastructure layer, such as user identity provided by an enterprise IAM provider and service identity provided by a standard-based Secure Production Identity Framework for Everyone [SPIFFE] server [4]) | アイデンティティ層ポリシー ・サービスとユーザーのアイデンティティに基づくサービスとリソースのアクセス範囲（例えば、エンタープライズのIAMプロバイダーが提供するユーザーアイデンティティと標準ベースのSecure Production Identity Framework for Everyone［SPIFFE］サーバー［4］が提供するサービスアイデンティティなど、専用インフラ層を通じたアイデンティティに基づく動的アプリケーション間通信規則）。 |
| Multi-tier policies can be implemented realistically and are non-disruptive to current compliance practices. Other tiers of policy also exist. For example, in the context of the service mesh, there are “application-tier” policies, which apply to the application payload itself. These include coarse-grained WAF rules, fine-grained rules like Spring Cloud Gateway payload validation, and the validation of request semantics via tools like the Open Policy Agent (OPA). Many can even be enforced by a service mesh, but those policies are beyond the scope of this document. | 多層ポリシーは現実的に実装することができ、現在のコンプライアンス慣行を破壊することはない。ポリシーの他の層も存在する。例えば、サービスメッシュの文脈では、アプリケーションペイロード自体に適用される「アプリケーション層」ポリシーが存在する。これには、粗い粒度のWAFルール、Spring Cloud Gatewayのペイロード検証のような細かいルール、Open Policy Agent（OPA）のようなツールによるリクエストセマンティックの検証などがある。多くはサービスメッシュによって強制されることもあるが、これらのポリシーは本文書の範囲外である。 |
| The difficulty with having all network-tier policies is that policies expressed through firewall rules have to be continuously changed, depending on the application pair behind those firewalls. The flexibility in having multi-tier policies is that network-tier policies can be relatively static while identity-tier policies higher up in the stack (e.g., service to service) can be dynamic, as illustrated in Fig. 2. | すべてのネットワーク層ポリシーを持つことの難しさは、ファイアウォールルールで表現されたポリシーが、ファイアウォールの背後にあるアプリケーションペアによって、継続的に変更されなければならないことである。多層ポリシーを持つことの柔軟性は、図2に示すように、ネットワーク層のポリシーは比較的静的である一方、スタックの上位にあるアイデンティティ層のポリシー（たとえば、サービス間）は動的であることができることである。 |
 |
|
| Fig. 2. Flexibility provided by multi-tier policies | 図2. 多層ポリシーがもたらす柔軟性 |
| Implementing identity-tier policies is also a more agile process that allows for new policy capabilities, such as writing policy in terms of identity and application-level action and verb. For example, a network-tier policy would describe the subnets that contain application instances of the client being allowed to call the subnet on a specific port. In contrast, an identity-tier policy would allow the client application identity to communicate with the server application identity via HTTPS on port 443 and execute only the GET method on the /public path. The full range of policies that an enterprise ZTA implemented via a service mesh can enable is outlined in [2] and [3]. | アイデンティティ層ポリシーの実装は、IDおよびアプリケーションレベルのアクションと動詞の観点からポリシーを記述するなど、新しいポリシー機能を可能にする、より俊敏なプロセスでもある。たとえば、ネットワーク層ポリシーでは、クライアントのアプリケーションインスタンスが特定のポートでサブネットを呼び出すことを許可されているサブネットを記述することになる。一方、アイデンティティ層ポリシーでは、クライアントアプリケーション ID がポート 443 で HTTPS を介してサーバアプリケーション ID と通信し、/public パスで GET メソッドのみを実行できるようにする。サービスメッシュを介して実装されたエンタープライズZTAが実現できるポリシーの全範囲については、[2]と[3]に概説されている。 |
| Implementing multi-tier policies by relaxing network-tier policies (e.g., by allowing communication across a set of gateways) while introducing identity-tier policies with advanced | ネットワーク層ポリシーを緩和し（例えば、ゲートウェイのセット間での通信を許可する）、高度なアイデンティティ層ポリシーを導入することで、多層ポリシーを実装する。 |
| layer seven controls results in a better overall security posture than either a purely identity-tier or purely network-tier approach. | レイヤ 7 の制御は、純粋な アイデンティティ層または純粋なネットワーク層のアプローチよりも、全体的なセキュリ ティ態勢を向上させるものである。 |
| 4. Implementing Multi-Tier Policies for ZTA for Cloud-Native Application Environments | 4. クラウドネイティブ・アプリケーション環境向けZTAの多層ポリシーの実装 |
| This section will consider the implementation of multi-tier policies for realizing an enterprise ZTA using a reference enterprise scenario in which an enterprise hosts microservices applications in several clusters. Each cluster is serviced with a service mesh instance, and clusters are spread out both on-premises and in multiple clouds. | ここでは、あるエンタープライズが複数のクラスターでマイクロサービス・アプリケーションをホストしているという参照・エンタープライズ・シナリオを用いて、エンタープライズZTAを実現するための多層ポリシーの実装を検討する。各クラスタはサービスメッシュ・インスタンスでサービスされ、クラスタはオンプレミスと複数のクラウドに分散している。 |
| Section 4.1 outlines a simple application infrastructure scenario, and Section 4.2 presents a sample set of associated policies that are relevant for that context. Section 4.3 shows how the same set of policies can be defined and deployed for a realistic application infrastructure scenario in which the incoming traffic comes through a DMZ. | セクション4.1では、単純なアプリケーション基盤のシナリオを概説し、セクション4.2では、そのコンテキストに関連する関連ポリシーのサンプルセットを提示す。セクション4.3では、受信トラフィックがDMZを経由する現実的なアプリケーションインフラシナリオにおいて、同じポリシーセットをどのように定義し実装できるかを示す。 |
| 4.1. Reference Application Infrastructure Scenario | 4.1. 参照アプリケーション基盤のシナリオ |
| Consider an application infrastructure of an enterprise where the application topology spans a cloud and on-premises environment. The applications are implemented as microservices with a service mesh instance for each cluster. Hence, a sidecar proxy is associated with each service. At the entry and exit points of each cluster are ingress and egress gateways, respectively. The same data plane (e.g., open-source Envoy) can be used to implement both the sidecar proxy and the transit gateways. | アプリケーションのトポロジーがクラウドとオンプレミスの環境にまたがっている、あるエンタープライズのアプリケーションインフラを考えてみましょう。アプリケーションはマイクロサービスとして実装され、各クラスタにはサービスメッシュ・インスタンスがある。したがって、サイドカープロキシは各サービスに関連付けられます。各クラスタの入口と出口には、それぞれイングレスゲートウェイとイグレスゲートウェイがある。サイドカープロキシとトランジットゲートウェイの両方を実装するために、同じデータプレーン（例えば、オープンソースのEnvoy）を使用することができる。 |
| Next, consider establishing policies for a scenario that involves two services – Service 1 and Service 2 – that reside in clusters in a cloud and on-premises, respectively. Service 1 in the cloud cluster can interact with services outside of the cluster through an egress gateway. Similarly, all services that attempt to access Service 2 from outside of the cluster have to go through an ingress gateway. All traffic coming out of the cloud has to go through an outbound firewall, and all traffic coming on-premises have to come through an inbound firewall. The paired egress-ingress proxies and the firewall rules that allow them connectivity are collectively referred to as a “transit gateway.” The network location for the two services are each designated by a subnet address. The application topology and policies described so far is shown in Fig. 3. | 次に、クラウドとオンプレミスのクラスタにそれぞれ存在する 2 つのサービス（サービス 1 とサービス 2）が関係するシナリオのポリシーを確立することを考えます。クラウドクラスター内のサービス1は、イグレスゲートウェイを通じてクラスター外のサービスと対話することができる。同様に、クラスタの外からサービス2にアクセスしようとするすべてのサービスは、イングレスゲートウェイを経由する必要がある。クラウドから出るすべてのトラフィックはアウトバウンド・ファイアウォールを経由し、オンプレミスから来るすべてのトラフィックはインバウンド・ファイアウォールを経由する必要がある。イグレスとイングレスのプロキシと、それらの接続を許可するファイアウォールルールを総称して、"トランジットゲートウェイ "と呼ぶ。2つのサービスのネットワーク位置は、それぞれサブネットアドレスで指定される。ここまで説明したアプリケーションのトポロジーとポリシーを図3に示す。 |
 |
|
| Fig. 3. Multi-tier Policies for a Hybrid Application Environment | 図3. ハイブリッドアプリケーション環境における多層ポリシー |
| 4.2. Role of the Service Mesh in Policy Deployment, Enforcement, and Updates | 4.2. ポリシーの実装、施行、更新におけるサービスメッシュの役割 |
| The service mesh has a unique role within the overall policy life cycle activities of policy definition, deployment, enforcement, and update. As already stated, the service mesh is a dedicated infrastructure that provides all application services, including security controls like secure communication and application-level access control. These services are only possible if there are also policies to enforce them during application runtime. | サービスメッシュは、ポリシーの定義、実装、実施、更新といったポリシーのライフサイクル活動全般の中で、独自の役割を担っている。すでに述べたように、サービスメッシュは、安全な通信やアプリケーションレベルのアクセス制御などのセキュリティ制御を含む、すべてのアプリケーションサービスを提供する専用基盤である。これらのサービスは、アプリケーションの実行時にそれらを強制するポリシーが存在する場合にのみ可能である。 |
| Based on the discussion of the control plane in previous sections, it should clear that this component of the service mesh provides access to the interfaces of various policy definition tools through which policies can be defined and updated. Thus, the control plane of the service mesh acts as the policy administration point, while the underlying policy tools become the policy decision point. In addition, the control plane also enables those policies to be distributed to the various proxies described in the previous section. Once distributed, these proxies intercept all traffic in and out of the applications, where it acts as a universal policy enforcement point. This allows the service mesh – which centrally manages a fleet of the applications’ proxies – to become the modern cloud-native security kernel [3]. | 前のセクションの制御プレーンの議論に基づけば、サービスメッシュのこのコンポーネントは、ポリシーを定義し更新することができる様々なポリシー定義ツールのインタフェースへのアクセスを提供することが明らかである。このように、サービスメッシュの制御プレーンはポリシー管理ポイントとして機能し、基礎となるポリシーツールはポリシー決定ポイントになる。さらに、制御プレーンは、これらのポリシーを前のセクションで説明した様々なプロキシに配布することも可能にしている。分散されると、これらのプロキシはアプリケーションに出入りするすべてのトラフィックを傍受し、普遍的なポリシー実施ポイントとして機能する。これにより、アプリケーションのプロキシ群を一元管理するサービスメッシュが、最新のクラウドネイティブセキュリティカーネルとなる[3]。 |
| The proxies – especially the sidecars – can enforce security and traffic policies and generate telemetry data to allow operators to close the loop on policy changes by authoring a change, observing its effect on the runtime, and making additional changes as needed in a real-time feedback control loop. In other words, the mesh provides the needed capabilities to implement the runtime controls and achieve a zero trust posture. | プロキシ（特にサイドカー）は、セキュリティとトラフィックのポリシーを実施し、テレメトリデータを生成することができる。言い換えれば、メッシュは、ランタイムコントロールを実装し、ゼロトラストポスチャーを達成するために必要な機能を提供する。 |
| 4.3. Policy Deployment for Reference Application Infrastructure | 4.3. 参照アプリケーション基盤のポリシー実装 |
| Connectivity (between network elements) and access policies (between service instances) are network-tier policies and identity-tier policies, respectively. | 接続性（ネットワーク要素間）とアクセスポリシー（サービスインスタンス間）は、それぞれネットワーク層ポリシーとアイデンティティ層ポリシーである。 |
| Consider the following example set of policies that contain a combination of network-tier and identity-tier policies. Network-tier policies can be further categorized into coarse-grained and fine-grained policies. | 以下に、ネットワーク層ポリシーとアイデンティティ層ポリシーの組み合わせを含むポリシーセットを例示す。ネットワーク層ポリシーは、さらに粗視化ポリシーと細視化ポリシーに分類することができる。 |
| • Coarse-grained network-tier policies – These perimeter control policies are informally called firewall rules and are mostly static as they specify: | ・粗視化ネットワーク層ポリシー ・これらの境界制御ポリシーは、非公式にファイアウォール規則と呼ばれ、ほとんど静的であるため、指定する： |
| o The network location of the egress gateway from which the network edge element at the exit point of a cloud network (e.g., outbound firewall, such as the one at the edge of a cloud) can receive traffic | o クラウドネットワークの出口にあるネットワークエッジ要素（例えば、クラウドのエッジにあるようなアウトバウンドファイアウォール）がトラフィックを受信することができるイグレスゲートウェイのネットワーク位置 |
| o The network location of the ingress gateway to which the incoming traffic that lands at the entry point of the on-premises network edge (e.g., inbound firewall at the entry point to an on-premises network) should be routed: | o オンプレミスネットワークエッジのエントリポイント（オンプレミスネットワークのエントリポイントにあるインバウンドファイアウォールなど）に着地した受信トラフィックをルーティングすべきイングレスゲートウェイのネットワーク位置： |
| Firewall: allow 10.100.2.3/30 15443 to 10.1.2.3/30:15443 | ファイアウォール： 10.100.2.3/30 15443 を 10.1.2.3/30:15443 へ許可する。 |
| • Fine-grained network-tier policies – These microsegmentation policies specify the pathways for traffic flowing into and out of the services located within the network subnets at the cloud location or on-premises location. | ・きめ細かいネットワーク層ポリシー ・これらのマイクロセグメンテーションポリシーは,クラウドまたはオンプレミスのネットワークサブネット内にあるサービスに流入・流出するトラフィックの経路を指定する。 |
| o Specify the path on which the outbound traffic from a service or an application (e.g., app 1) can flow. The elements in the path that are specified include the egress gateway at the edge of the cluster and, subsequently, the outbound firewall for the network (cloud network in this example). | o サービスまたはアプリケーション（例：アプリ 1）からのアウトバウンドトラフィックが流れる経路を指定する。指定されるパスの要素には、クラスタのエッジにあるイグレスゲートウェイと、それに続くネットワーク（この例ではクラウドネットワーク）のアウトバウンドファイアウォールが含まれる。 |
| o Specify the path for the inbound traffic into the on-premises network to reach the target application. The elements in the path start from the inbound firewall at the edge of the on-premises network to the ingress gateway in an on-premises cluster to the network subnet where the target service is located. | o オンプレミスネットワークへのインバウンドトラフィックがターゲットアプリケーションに到達するためのパスを指定する。パスの要素は、オンプレミスネットワークのエッジにあるインバウンドファイアウォールから、オンプレミスクラスターのイングレスゲートウェイ、ターゲットサービスが配置されているネットワークサブネットまでとなる。 |
| o Notably, they specify how traffic can flow “east-west”(i.e., inside of the perimeter). This is in contrast to coarse-grained policies, which specify how traffic can flow “north-south” (i.e., from an external to internal network). | o 注目すべきは、トラフィックが「東西」（つまり境界の内側）に流れる方法を規定していることである。これは、粗視化ポリシーとは対照的で、トラフィックが「南北」（すなわち、外部ネットワークから内部ネットワークへ）に流れる方法を指定するものである。 |
| • Identity-tier policies – These are also called mesh-level policies as they are deployed and enforced at the data plane of the service mesh in the reference platform. In the context of the application infrastructure and the example policies that cover traffic flows from Service 1 to Service 2, these are: | ・アイデンティティ層ポリシー ・参照プラットフォームのサービスメッシュのデータプレーンで実装され、実施されるため、メッシュレベルのポリシーとも呼ばれる。アプリケーションインフラと、サービス1からサービス2へのトラフィックフローをカバーするポリシーの例では、次のようになる： |
| selector: matchLabels: app: service-2 action: ALLOW rules: | |
| - from: | |
| - source: | |
| principals: ["cluster.local/ns/service-1/sa/service-1"] to: | |
| - operation: | |
| ports: ["443"] methods: ["GET"] paths: ["/public"] | |
| Fig. 4. An Istio Authorization Policy that allows Service 1 to Service 2 on port 443 but only allows it to execute the GET HTTP verb on the “/public” path | 図4. サービス1がポート443でサービス2にアクセスすることは許可するが、「/public」パスでのGET HTTP動詞の実行だけは許可するIstio Authorization Policy |
| This simple example shows some of the advanced capabilities that identity-tier policies can achieve by limiting access based on the application request context. Specifically, this policy limits the application actions to a single HTTP verb on a specific path, but much more sophisticated policy can be implemented as well. See [2] and [3] for detailed overviews. | この単純な例は、アプリケーション要求コンテキストに基づいてアクセスを制限することで、ID-Tier ポリシーが実現できる高度な機能の一部を示している。具体的には、このポリシーはアプリケーションのアクションを特定のパス上の単一の HTTP 動詞に制限しているが、はるかに洗練されたポリシーを実装することも可能である。詳細な概要については、[2]と[3]を参照すること。 |
| 4.4. Another Application Infrastructure Scenario | 4.4. 別のアプリケーション基盤のシナリオ |
| Consider another common application scenario in which there is an internal (i.e., within a cluster in the enterprise data center) three-tier application. This application is accessed from outside (through a mobile app or website) through a DMZ. This scenario consists of edge gateways present in the DMZ – an ingress gateway and an egress gateway at the entrance and exit points to and from the data center with firewalls at either side of the gateways. Each of the services that represent the front end and back end (application logic) of the three-tier application have to have a sidecar proxy to enforce policies that pertain to inter-service call requests. This scenario requires the definition and deployment of a combination of network-tier and identity-tier policies that span the various types of gateways and the sidecar proxies. Deploying policies at these multiple locations requires an enterprise-level infrastructure that plays the role of a global control plane, as described in Section 2.1. This is designated as a central coordination infrastructure, as shown in Fig. 5. | 別の一般的なアプリケーションシナリオとして、内部（すなわち、エンタープライズデータセンター内のクラスタ内）の3層アプリケーションを考えてみましょう。このアプリケーションは、外部からDMZを通じて（モバイルアプリやウェブサイトを通じて）アクセスされる。このシナリオでは、DMZに存在するエッジゲートウェイ（データセンターへの入口と出口にあるイングレスゲートウェイとイグレスゲートウェイ、ゲートウェイの両脇にファイアウォール）で構成されている。3層アプリケーションのフロントエンドとバックエンド（アプリケーションロジック）を表す各サービスは、サービス間のコールリクエストに関連するポリシーを適用するためのサイドカープロキシを持っていなければなりません。このシナリオでは、さまざまなタイプのゲートウェイとサイドカー・プロキシにまたがるネットワーク層とアイデンティティ層のポリシーの組み合わせを定義して実装する必要がある。これらの複数の場所でポリシーを実装するには、セクション 2.1 で説明したように、グローバル制御プレーンの役割を果たすエンタープライズレベルの基盤が必要である。これを図5に示すように、中央調整インフラとする。 |
 |
|
| Fig. 5. Policy Deployment for a Three-tier Application | 図5. 3層アプリケーションのためのポリシー実装 |
| 4.5. Functional Roles of Application Infrastructure Elements in Enforcing Policies | 4.5. ポリシーの適用におけるアプリケーション基盤要素の機能的役割 |
| This section will show the functionality of each of the application infrastructure elements involved in the policies (e.g., firewalls, gateways, sidecar, transit, and edge proxies) in detail. Since the functionality of firewalls that take part in this context for coarse network-tier policies are well known, this section will focus on the functionality of gateways that take part in finegrained and identity-tier policies: | このセクションでは、ポリシーに関与する各アプリケーションインフラ要素（ファイアウォール、ゲートウェイ、サイドカー、トランジット、エッジプロキシなど）の機能を詳細に示す。この文脈では、粗いネットワーク層のポリシーに関与するファイアウォールの機能はよく知られているため、このセクションでは、細かいアイデンティティ層のポリシーに関与するゲートウェイの機能に焦点を当てる： |
| • Sidecar – Beside each application instance to intercept all traffic into and out of the application and handles “east-west” internal communication between services in the infrastructure. This is the primary use case of the service mesh. | ・Sidecar ・各アプリケーションインスタンスの横で,アプリケーションに出入りするすべてのトラフィックを遮断し,基盤のサービス間の「東西」内部通信を処理する。これは,サービスメッシュの主な使用例である。 |
| • Ingress gateway – Controls how applications in the cluster are exposed outside (e.g., managing what names, certificates, ports, protocols, and application endpoints are served to the world outside of the cluster). Think of this as the service mesh control plane that manages a traditional reverse proxy similar to Spring Cloud Gateway, NGINX, or HAProxy. | ・イングレスゲートウェイ ・クラスタ内のアプリケーションが外部に公開される方法を制御する（例えば、クラスタの外部に提供される名前、証明書、ポート、プロトコル、アプリケーションエンドポイントを管理する）。Spring Cloud Gateway、NGINX、HAProxyのような従来のリバースプロキシーを管理するサービスメッシュの制御プレーンと考えること。 |
| • Egress gateway – Controls how applications in the cluster communicate with the outside world. This can be used for traditional egress filtering and logging, like a Squid proxy, but can also implement identity-based policy for what is allowed to call out and perform credential exchange, or presenting a set of credentials (e.g., an mTLS certificate for a partner API), on behalf of the application so that the application does not need to handle them (e.g., communicating via mTLS with the partner API). Think of this as a nextgeneration identity-aware Squid proxy. | ・Egress Gateway ・クラスタ内のアプリケーションが外界と通信する方法を制御する。Squidプロキシのように従来のegressフィルタリングとロギングに使用することもできるが、呼び出しを許可するもののアイデンティティベースのポリシーを実装し、クレデンシャル交換を実行したり、アプリケーションに代わってクレデンシャルセット（パートナーAPIのmTLS証明書など）を提示して、アプリケーションがそれらを処理（パートナーAPIとmTLSで通信するなど）しなくてもいいようにすることも可能である。これは、次世代ID対応Squidプロキシと考えること。 |
| • Edge gateway – Accepts external traffic before the ingress gateway and performs finegrained load balancing across clusters or sites. It is used to terminate external traffic, enable infrastructure-level failover, deploy blue-green clusters, and facilitate ingressgateway-per-team deployments without requiring each of those teams to have publicly routable ingress gateways. Think of this as a modern software-based local traffic manager, like F5, that can apply policy per-request rather than per-connection. | ・エッジゲートウェイ ・イングレスゲートウェイの前で外部トラフィックを受け入れ、クラスタまたはサイト間できめ細かい負荷分散を実行する。外部トラフィックの終端、インフラレベルのフェイルオーバー、ブルーグリーンクラスターの導入、各チームが公開ルーティング可能なイングレスゲートウェイを持つ必要がないチームごとのイングレスゲートウェイ導入の促進に使用される。これは、F5のような最新のソフトウェアベースのローカルトラフィックマネージャーであり、接続ごとではなく、リクエストごとにポリシーを適用することができると考えること。 |
| 4.6. Comparison of Identity-Tier and Network-Tier Policies | 4.6. アイデンティティ層とネットワーク層のポリシーの比較 |
| While network-tier policies are necessary for geographically distributed application infrastructures and for meeting the compliance requirements of regulators, having a combination of network-tier and identity-tier policies allows for some relaxation of the network-tier policies as any unauthorized traffic flow due to an overlooked network element in the path can be addressed through flexible service identity-tier policies. In order to appreciate the need for the coexistence of both policy tiers, it is necessary to know the characteristics of both tiers of policies. This layering of policies, whose strictness can be tuned per organizational needs at each tier, provides agility and operational ease over status quo perimeter-based models while enhancing the overall security posture of the organization. | ネットワーク層ポリシーは、地理的に分散したアプリケーションインフラや規制当局のコンプライアンス要件を満たすために必要であるが、ネットワーク層ポリシーとアイデンティティ層ポリシーの組み合わせを持つことで、パス内のネットワーク要素の見落としによる不正なトラフィックフローは、柔軟なサービスアイデンティティ層ポリシーによって対処できるため、ネットワーク層ポリシーをある程度緩和することができる。両ポリシー層の共存の必要性を理解するためには、両ポリシー層の特徴を知ることが必要である。各層で組織のニーズに応じて厳格さを調整できるこのポリシーのレイヤリングは、組織の全体的なセキュリティ態勢を強化しながら、現状の境界ベースのモデルよりも俊敏性と運用のしやすさを提供する。 |
| 4.6.1. Approaches for Deployment and the Limitations of Network-Tier Policies | 4.6.1. ネットワーク層ポリシーの実装の考え方と限界について |
| In this approach, applications and service resources with similar security requirements are grouped into a unique segment, and firewall rules are created to block or allow communication with each group or segment [5]. The segments are created using network layer abstractions (e.g., VLAN IDs or some other tagging approaches), while policies are defined using network address constructs (e.g., IP addresses and ports). Policies apply to subnets (e.g., VLANs) rather than to individual hosts. The assignment of applications to a particular segment can be based on different criteria, such as “all applications with similar security requirements” or “all tiers (web front end, application logic servers, and database servers) associated with a particular application should run in a single segment.” | このアプローチでは、同様のセキュリティ要件を持つアプリケーションやサービスリソースを一意のセグメントにグループ化し、各グループやセグメントとの通信をブロックまたは許可するファイアウォールルールを作成する[5]。セグメントは、ネットワーク層の抽象化（VLAN IDやその他のタグ付けアプローチなど）を使用して作成され、ポリシーはネットワークアドレス構造（IPアドレスやポートなど）を使用して定義される。ポリシーは、個々のホストではなく、サブネット（VLANなど）に適用される。特定のセグメントへのアプリケーションの割り当ては、"同様のセキュリティ要件を持つすべてのアプリケーション"、"特定のアプリケーションに関連するすべての層（Webフロントエンド、アプリケーションロジックサーバ、データベースサーバ）は、単一のセグメントで実行されるべきである "など、異なる基準に基づいて行うことができる。 |
| Each segment is protected by gateway devices, such as intelligent switches and routers or nextgeneration firewalls, which should have the capacity to react and adapt in response to the threats and changes in the application workflows. Segmentation gateways monitor traffic, stop threats, and enforce granular access across east-west traffic (rarely for north-south traffic) within onpremises data centers or cloud regions. The main difficulty with this approach is in mapping the applications’ security requirements-based segments to corresponding network segments. Another difficulty is change management. The mapping between applications and network identities that are being statically maintained has to continuously be kept in sync with the operational scenario in which the application’s network locations are continuously changing due to performance and security. | 各セグメントは、インテリジェントスイッチやルーター、次世代ファイアウォールなどのゲートウェイ機器によって保護され、脅威やアプリケーションワークフローの変化に応じて反応・適応する能力を持つ必要がある。セグメンテーションゲートウェイはトラフィックを監視し、脅威を阻止し、オンプレミスのデータセンターまたはクラウド領域内の東西トラフィック（まれに南北トラフィック）に対してきめ細かいアクセスを強制する。このアプローチの主な難点は、アプリケーションのセキュリティ要件に基づくセグメントを、対応するネットワークセグメントにマッピングすることである。もう一つの難点は、変更管理である。静的に維持されているアプリケーションとネットワークIDのマッピングは、パフォーマンスやセキュリティのためにアプリケーションのネットワークロケーションが絶えず変化する運用シナリオと常に同期させる必要がある。 |
| More modern cloud-native deployments that leverage techniques like container network interface-driven network policy are good improvements because they provide identity-tier style policies (i.e., policy in terms of identities and non-network-oriented nouns) while implementing that policy at the network layer (e.g., via eBPF policy or BGP propagation rules). These are a strong upgrade from traditional microsegmentation because they tend to result in finer-grained policies that are easier for the organization to manage over time. However, they typically lack the ability to apply policy per request in the context of the application, which is needed to achieve identity-based segmentation. | コンテナ・ネットワーク・インターフェース駆動型ネットワーク・ポリシーのような技術を活用した、より最新のクラウドネイティブ・実装は、アイデンティティ層スタイルのポリシー（すなわち、アイデンティティと非ネットワーク指向の名詞の観点からのポリシー）を提供しながら、ネットワーク層で（例えば、eBPFポリシーやBGP伝搬ルールによって）そのポリシーを実装するので、良い改善である。これらは、従来のマイクロセグメンテーションから強力にアップグレードされたもので、組織が長期的に管理しやすい、よりきめ細かいポリシーになる傾向がある。しかし、一般的に、ID ベースのセグメンテーションを実現するために必要な、アプリケーションのコン テキストでリクエストごとにポリシーを適用する機能が欠けている。 |
| 4.6.2. Prerequisites for the Deployment of Identity-Tier Policies | 4.6.2. アイデンティティ層ポリシーの実装に関する前提条件 |
| Identity-tier policies use contextual, application-driven identifiers (e.g., “order processing frontend service can communicate with inventory back-end service”) instead of network parameters (e.g., “permit calls from 192.168.10.x subnet to 10.0.0.31”). The identifiers assigned to services at runtime are cryptographic identities, which are used for mutual authentication and authorization during each service request and response. | アイデンティティ層ポリシーは、ネットワークパラメータ（「192.168.10.x サブネットから 10.0.0.31 への呼び出しを許可する」など）の代わりに、コンテキストに応じたアプリケーション駆動型の識別子（「注文処理フロントエンドサービスは在庫バックエンドサービスと通信できる」など）を使用する。実行時にサービスに割り当てられる識別子は暗号化されたIDであり、各サービスのリクエストとレスポンス時に相互認証と認可のために使用される。 |
| Deploying identity-tier policies requires a standardized infrastructure for creating, issuing, and maintaining tamper-proof service identities. Some of the components of this infrastructure are outlined below and are also discussed in [5]: | アイデンティティ層ポリシーを実装するには、改ざん防止されたサービスIDを作成、発行、維持するための標準化された基盤が必要である。この基盤のコンポーネントの一部を以下に概説し、[5]でも説明している： |
| • Creation of application identity: The fundamental requirement to enable this is the assignment of a unique identity to each application or service, just like how each user carries a unique identity (e.g., userid). Prior to the era of cloud-based applications, application requests were validated based on the IP subnet or IP address from which they originated. Since ubiquitous access and multi-clouds have eliminated the concept of network perimeters, authentication and authorization based on those parameters are neither feasible nor scalable. Further, the presence of proxies, network address translations, dynamic infrastructures (e.g., migration of applications between VMs), and load balancers make it impossible for the called application to know the IP address of the calling application in order to make authentication or authorization decisions. A unique application identity is required. | ・アプリケーション ID の作成： アプリケーションIDの作成：これを実現するための基本的な要件は、各ユーザーが固有のID（useridなど）を持つのと同様に、各アプリケーションまたはサービスに固有のIDを割り当てることである。クラウドベースのアプリケーションの時代以前は、アプリケーションのリクエストは、発信元のIPサブネットやIPアドレスに基づいて検証されました。ユビキタスアクセスとマルチクラウドにより、ネットワーク境界の概念がなくなったため、これらのパラメータに基づく認証と認可は、実現不可能であり、拡張性もありません。さらに、プロキシ、ネットワークアドレス変換、ダイナミック基盤（VM間のアプリケーションの移行など）、ロードバランサーの存在により、呼び出し側のアプリケーションが認証や認可を決定するために呼び出し側アプリケーションのIPアドレスを知ることは不可能である。一意のアプリケーションIDが必要である。 |
| • Establishment of trust in application identity: The created application (workload or service) identity should not be subject to spoofing and should be continuously verifiable. An example of workload identity is a SPIFFE ID [4], which is a string that uniquely and specifically identifies a workload and is encoded as a Uniform Resource Identifier (URI). The SPIFFE ID is carried in a cryptographically verifiable document called a SPIFFE Verifiable Identity Document (SVID). SPIFFE supports multiple SVID formats, but the most commonly used is an X.509 certificate. | ・アプリケーションIDの信頼の確立 作成されたアプリケーション（ワークロードまたはサービス）IDは、なりすましの対象とならず、継続的に検証可能であるべきである。ワークロードIDの例としては、SPIFFE ID［4］がある。これは、ワークロードを一意的かつ具体的に識別する文字列であり、統一資源識別子（URI）として符号化されるものである。SPIFFE IDは、SPIFFE Verifiable Identity Document（SVID）と呼ばれる暗号的に検証可能な文書で運ばれる。SPIFFEは複数のSVID形式をサポートしているが、最も一般的に使用されるのはX.509証明書である。 |
| • Discovery of application resources: There should be a robust and secure method for discovering all of the application dependencies consumed over the network (e.g., services, SaaS endpoints, network appliances, etc.). This capability is enabled through an authenticated service registry. | ・アプリケーションリソースの発見： ネットワーク上で消費されるすべてのアプリケーション依存関係（サービス、SaaSエンドポイント、ネットワークアプライアンスなど）を発見するための堅牢かつ安全な方法が必要である。この機能は、本人認証されたサービスレジストリによって実現される。 |
| These allowable flows can be based on either (a) the structure of the application (i.e., “the front end of application 1 can call the back end of application 1”) or (b) a legitimate business transaction (e.g., “order processing application can call the shipping application”). Often, organizations do not know all of the allowable service requests in their infrastructure. However, the observability capabilities of the infrastructure (e.g., the metrics provided by the service mesh) can be leveraged to build a view of “requests made today.” From that view, the organization can begin to create fine-grained policies for allowable service requests. Utilizing this observe-andlock-down methodology builds the organizational processes required to maintain the life cycle of these policies over time. | これらの許容フローは、（a）アプリケーションの構造（すなわち、「アプリケーション1のフロントエンドは、アプリケーション1のバックエンドを呼び出すことができる」）または（b）正当なビジネストランザクション（例えば、「注文処理アプリケーションは、出荷アプリケーションを呼び出すことができる」）のいずれかに基づいていることができる。多くの場合、組織は、その基盤で許容されるサービス要求のすべてを知っているわけではありません。しかし、基盤の観測可能な機能（例えば、サービスメッシュによって提供されるメトリクス）を活用することで、「今日行われた要求」のビューを構築することができる。このビューから、組織は許容されるサービス要求に対するきめ細かなポリシーを作成し始めることができる。このオブザーブ＆ロックダウン手法を活用することで、これらのポリシーのライフサイクルを長期的に維持するために必要な組織的プロセスを構築することができる。 |
| 4.6.3. Advantages of Identity-Tier Policies | 4.6.3. アイデンティティ層ポリシーの利点 |
| Policies based on service and application identities do not use any infrastructure-related variables (e.g., IP addresses, subnets), so they are environment-agnostic and provide the freedom for the services and applications to be migrated to different environments and still maintain the same policies. In other words, there can be a consistent set of policies across cloud providers and onpremises because the policy follows the application rather than the network. | サービスやアプリケーションのアイデンティティに基づくポリシーは、インフラ関連の変数（IPアドレスやサブネットなど）を使用しないため、環境にとらわれず、サービスやアプリケーションが異なる環境に移行しても、同じポリシーを維持できる自由度を提供する。言い換えれば、ポリシーはネットワークではなくアプリケーションに従うため、クラウドプロバイダとオンプレミスの間で一貫したポリシーのセットが存在することができる。 |
| • Identity-tier policies enable the automated testing of policies. Policies that are independent of infrastructure can be tested by merely exercising the application and observing the outcomes (e.g., trace the sequence of service calls and requests or responses instead of configuring the infrastructure correctly for test runs). | ・アイデンティティ層ポリシーは、ポリシーの自動テストを可能にする。基盤に依存しないポリシーは、アプリケーションを実行して結果を観察するだけでテストできる（たとえば、テスト実行のために基盤を正しく構成する代わりに、サービスコールとリクエストまたはレスポンスのシーケンスをトレースする）。 |
| • Identity-tier policies enable “policy as code” (PaC). With the availability of tools for the declarative specification of policies through PaC, identity-tier policies can be defined and implemented by incorporating the code into automated workflows, such as CI/CD pipelines. | ・アイデンティティ層ポリシーは、「コードとしてのポリシー」（PaC）を可能にする。PaCによるポリシーの宣言的な仕様のためのツールが利用できるようになると、CI/CDパイプラインなどの自動化されたワークフローにコードを組み込むことによって、アイデンティティ層ポリシーを定義し実装することができる。 |
| • Identity-tier policies enable granular (fine-grained) access control by providing visibility into application call sequences/interdependencies and data flows through request-level tracking, which enables the enforcement of security policies for application traffic that is both north-south and east-west, irrespective of the environment (e.g., corporate data center or cloud infrastructure). | ・アイデンティティ層ポリシーは、アプリケーションのコールシーケンス/相互依存関係やリクエストレベルのトラッキングによるデータフローを可視化することで、きめ細かいアクセス制御を可能にし、エンタープライズのデータセンターやクラウド基盤などの環境に関係なく、南北と東西の両方にあるアプリケーショントラフィックに対してセキュリティポリシーを実施することができる。 |
| Additional advantages include: | さらに、以下のようなメリットもある： |
| • Write once, enforce everywhere – This means that policy can span environments and topologies (i.e., write a policy once, and enforce it everywhere) rather than bespoke policies per environment. | ・一度書いたら、どこでも適用できる ・つまり、環境ごとにポリシーを特注するのではなく、環境やトポロジーにまたがってポリシーを適用できる（つまり、一度ポリシーを書いたら、どこでも適用できる）。 |
| • Human-readable primitives – The written policies use human-understandable primitives | ・人間が読めるプリミティブ ・書かれたポリシーは,人間が理解できるプリミティブを使用している。 |
| (e.g., “service A can call service B”) rather than network-oriented primitives (e.g., “10.1.2.3/30 is allowed to call 10.100.2.3/30 on port 8080”). This context is critical since the lack of context for rules is a key reason for the lack of agility around traditional network policy. | (ネットワーク指向のプリミティブ（「10.1.2.3/30はポート8080で10.100.2.3/30を呼び出すことができる」など）ではなく、（「サービスAはサービスBを呼び出せる」など）のように。ルールにコンテキストがないことが、従来のネットワークポリシーに俊敏性がない主な理由であるため、このコンテキストは重要である。 |
| • Contextual intent is codified in a single policy – There is a single policy, not a set of policies that need to be pieced together to understand their intent. A human can read a policy like “the front-end service is allowed to call ‘GET /foo’ on the back-end service” and understand the access that the policy intends to convey even if, for example, the front end is deployed in the cloud and the back end is deployed on-premises. It is significantly harder to read a set of network peering and firewall rules that allow communication across the DMZ for a set of subnets and understand the access that the policy intends to convey. In turn, this means it is harder to write the wrong policy and easier for a human to understand when a policy is incorrect. | ・コンテキストの意図は1つのポリシーに体系化されている ・ポリシーの意図を理解するためにつなぎ合わせる必要のあるポリシーのセットではなく、1つのポリシーが存在する。例えば、フロントエンドがクラウドに、バックエンドがオンプレミスに配置されていても、人間は「フロントエンドサービスはバックエンドサービスに対して『GET /foo』を呼び出すことを許可される」といったポリシーを読み、そのポリシーが意図するアクセスを理解することができる。あるサブネットのDMZを越えた通信を許可するネットワークピアリングとファイアウォールのルールを読み、そのポリシーが意図するアクセスを理解するのは、かなり困難である。これは、間違ったポリシーを書くのが難しく、ポリシーが正しくない場合に人間が理解しやすいことを意味する。 |
| Identity-tier policies enable only valid network traffic between the various component services of the application due to the mutual authentication and authorization of the service identities, thus enabling the goals of ZTNA to be met. | アイデンティティ層ポリシーは、サービスアイデンティティの相互認証と承認により、アプリケーションのさまざまなコンポーネントサービス間の有効なネットワークトラフィックのみを可能にし、ZTNAの目標を達成することを可能にする。 |
| 5. Summary and Conclusions | 5. まとめと結論 |
| This document provides guidance for realizing a ZTA for cloud-native application platforms (microservices with a service mesh infrastructure) in the context of an enterprise environment in which applications are hosted in multi-cluster and multi-cloud deployments. A ZTA consists of deployment artifacts that enforce zero trust principles, which is only possible with robust, flexible, scalable, and granular policies that cover all enterprise resources. A policy framework that consists of network-tier and identity-tier policies to meet these goals has been proposed in this document. | 本書は、アプリケーションがマルチクラスターおよびマルチクラウドの実装でホストされているエンタープライズ環境のコンテキストで、クラウドネイティブなアプリケーションプラットフォーム（サービスメッシュ基盤を持つマイクロサービス）のためのZTAを実現するためのガイダンスを提供する。ZTAは、ゼロトラスト原則を実施する実装アーティファクトで構成され、これは、すべてのエンタープライズリソースをカバーする堅牢で柔軟、スケーラブル、かつ粒度の細かいポリシーによってのみ可能である。このような目標を達成するために、ネットワーク層とアイデンティティ層のポリシーからなるポリシーフレームワークが本書で提案されている。 |
| The artifacts needed for the definition, deployment, and enforcement of these policies have been discussed along with examples of network-tier policies and identity-tier policies. The applicability of these policies in modern enterprise application infrastructures is also illustrated. Finally, the policies that belong to the two tiers are compared in terms of their advantages and limitations, and the critical role of identity-tier policies for realizing a ZTA in the context of modern cloud-native application infrastructures is emphasized. | これらのポリシーの定義、実装、および実施に必要な成果物について、ネットワーク層ポリシーと アイデンティティ層ポリシーの例とともに説明した。また、最新のエンタープライズアプリケーション基盤におけるこれらのポリシーの適用可能性も説明されている。最後に、2つの層に属するポリシーの利点と限界を比較し、最新のクラウドネイティブ・アプリケーションインフラの文脈でZTAを実現するためのアイデンティティ層ポリシーの重要な役割を強調する。 |
| 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) NIST SP 800-207. https://doi.org/10.6028/NIST.SP.800-207 | |
| [2] 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) NIST SP 800-204A. https://doi.org/10.6028/NIST.SP.800-204A | |
| [3] Chandramouli R, Butcher Z, Aradhna C (2021) Attribute-based Access Control for Microservices-based Applications using a Service Mesh. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-204B. https://doi.org/10.6028/NIST.SP.800-204B | |
| [4] SPIFFE (2022) SPIFFE Concepts. Available at https://spiffe.io/docs/latest/spiffeabout/spiffe-concepts/ | |
| [5] Chandramouli R (2022) Guide to a Secure Enterprise Network Landscape. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-215. https://doi.org/10.6028/NIST.SP.800-215 | |
Comments