米国 NIST SP 800-233(初期公開ドラフト) クラウドネイティブアプリケーションのサービスメッシュプロキシモデル (2024.07.19)
こんにちは、丸山満彦です。
NISTが、クラウドネイティブアプリケーションのサービスメッシュプロキシモデルについての初期公開ドラフトを公表し、意見募集をしていますね...
これからはこっちですかね...
● NIST - ITL
・2024.07.19 NIST SP 800-233 (Initial Public Draft) Service Mesh Proxy Models for Cloud-Native Applications
NIST SP 800-233 (Initial Public Draft) Service Mesh Proxy Models for Cloud-Native Applications | NIST SP 800-233(初期公開ドラフト) クラウドネイティブアプリケーションのサービスメッシュプロキシモデル |
Announcement | 発表 |
The service mesh has become the de facto application services infrastructure for cloud-native applications. It enables an application’s runtime functions (e.g., network connectivity, access control, etc.) through proxies that form the data plane of the service mesh. Different proxy models or data plane architectures have emerged, depending on the distribution of the network layer functions (i.e., L4 and L7) and the granularity of association of the proxies to individual services/computing nodes. | サービスメッシュは、クラウドネイティブ・アプリケーションのための事実上のアプリケーション・サービス・インフラとなっている。サービスメッシュは、サービスメッシュのデータプレーンを形成するプロキシを通じて、アプリケーションのランタイム機能(ネットワーク接続、アクセス管理など)を実現する。ネットワークレイヤー機能(L4とL7)の配分と、個々のサービス/コンピューティングノードへのプロキシの関連付けの粒度に応じて、異なるプロキシモデルやデータプレーンアーキテクチャが出現している。 |
The purposes of this document are two-fold: | この文書の目的は2つある: |
Develop a threat profile for each of the data plane architectures by considering a set of potential threats to various proxy functions and assign scores to the impacts and likelihoods of their exploits. | 様々なプロキシ機能に対する潜在的な脅威のセットを考慮することによって、 各データプレーンアーキテクチャの脅威プロファイルを作成し、その悪用の 影響と可能性にスコアを割り当てる。 |
Analyze the service mesh capabilities that are required for each class of cloud-native applications with different risk profiles (i.e., low, medium, and high) and provide recommendations for the data plane architectures or proxy models that are appropriate and applicable for each class. | 異なるリスクプロファイル(低、中、高)を持つクラウドネイティブアプリケーションの各クラスに必要なサービスメッシュ機能を分析し、各クラスに適切で適用可能なデータプレーンアーキテクチャまたはプロキシモデルの推奨を提供する。 |
Abstract | 概要 |
The service mesh has become the de-facto application services infrastructure for cloud-native applications. It enables the various runtime functions (network connectivity, access control etc.) of an application through proxies which thus form the data plane of the service mesh. Depending upon the distribution of the network layer functions (L4 & L7) and the granularity of association of the proxies to individual services/computing nodes, different proxy models or data plane architectures have emerged. The purpose of this document is to develop a threat profile for each of the data plane architectures through a detailed threat analysis in order to make recommendations for their applicability (usage) for cloud-native applications with different security risk profiles. | サービスメッシュは、クラウドネイティブアプリケーションの事実上のアプリケーションサービスインフラとなっている。サービスメッシュは、サービスメッシュのデータプレーンを形成するプロキシを通じて、アプリケーションの様々な実行時機能(ネットワーク接続、アクセス管理など)を実現する。ネットワークレイヤー機能(L4とL7)の配分と、個々のサービス/コンピューティングノードへのプロキシの関連付けの粒度に応じて、異なるプロキシモデルやデータプレーンアーキテクチャが出現している。この文書の目的は、詳細な脅威分析を通じて、それぞれのデータプレーンアーキテクチャの脅威プロ ファイルを作成し、異なるセキュリティリスクプロファイルを持つクラウドネイティブアプリケーショ ンに適用(使用)するための推奨を行うことである。 |
・[PDF] NIST.SP.800-233.ipd
エグゼクティブサマリー...
Executive Summary | エグゼクティブサマリー |
Run-time services for Cloud-native applications, consisting of multiple loosely coupled components called microservices, are sometimes provided through a centralized infrastructure called a service mesh. These services include secure communication, service discovery, resiliency, and authorization of application communication. These services are mainly provided through Proxies that form the data plane of the service mesh, the layer that handles application traffic at runtime and enforces policy. | マイクロサービスと呼ばれる複数の疎結合コンポーネントで構成されるクラウドネイティブ・アプリケーションのランタイム・サービスは、サービス・メッシュと呼ばれる集中型インフラを通じてプロバイダされることがある。これらのサービスには、セキュアなコミュニケーション、サービス・ディスカバリ、レジリエンス、アプリケーション・コミュニケーションの認可などが含まれる。これらのサービスは主に、サービスメッシュのデータプレーンを形成するプロキシ(実行時にアプリケーションのトラフィックを処理し、ポリシーを実施するレイヤー)を通じて提供される。 |
The functions that the proxies provide can be broadly categorized into two groups, based on the OSI model’s network layer to which those functions pertain to. These groups are: Layer 4 (“L4”) and Layer 7 (“L7”). In majority of deployments of service mesh in production environments today, all proxy functions (providing services in both L4 and L7 layers) are packed into a single proxy that is assigned to a single microservice. This service mesh proxy model is called a sidecar proxy model since the proxy is not only associated with a single service but is implemented to execute in the same network space as the service. | プロキシが提供する機能は、OSIモデルのネットワークレイヤーに基づき、2つのグループに大別できる。これらのグループは以下の通りである: レイヤー4(「L4」)とレイヤー7(「L7」)である。今日、本番環境におけるサービスメッシュのデプロイメントの大部分 では、すべてのプロキシ機能(L4とL7の両方のレイヤーのサービスを提供する)は、単一のマイクロサービスに割り当てられる単一のプロキシにまとめられる。このサービスメッシュのプロキシモデルは、プロキシが一つのサービ スに関連付けられるだけでなく、サービスと同じネットワーク空間で実行されるように実装されるので、サイドカープロキシモデルと呼ばれる。 |
However, performance and resource considerations have led to the exploration of alternate proxy models which involve not only splitting up of L4 and L7 functions into different proxies (instead of a single proxy) but also the association or assignments of these proxies to either a single service or a group of services, thus enabling the proxies to be implemented at different locations - at the granularity of a node rather than at the level of services. Though different models are theoretically possible, we consider only those service mesh proxy models in the data plane implementation of commonly used service mesh offerings, at different stages. | しかしながら、パフォーマンスとリソースを考慮した結果、L4とL7機能を(単一 のプロキシの代わりに)異なるプロキシに分割するだけでなく、これらのプロキシを単一 のサービスまたはサービスグループのいずれかに関連付けたり割り当てたりするこ とで、プロキシを異なる場所(サービスレベルではなくノードの粒度)で実装することを 可能にする、別のプロキシモデルの探究につながった。理論的には様々なモデルが可能であるが、ここでは、一般的に使用され ているサービスメッシュのデータプレーンの実装において、様々な段階のサービスメッシュプロキシモデルのみを考察する。 |
We then consider a set of potential/likely threats to various proxy functions. Each of the threats may result in different types of exploits in different proxy models. This variation is due to several factors such as: attack surface (communication patterns to which a particular proxy is exposed), number of clients (services) served and OSI layer functions they provide (e.g., L7 functions are more complicated and likely to have more vulnerabilities than L4 functions). The two main contributions of this document are as follows: | 次に、様々なプロキシ機能に対する潜在的/可能性のある一連の脅 威について考察する。各脅威は、異なるプロキシモデルにおいて異なるタイプのエクスプロイトをもたらすかもしれない。この変化は、攻撃対象領域(特定のプロキシがさらされるコミュニケーションパターン)、提供されるクライアント(サービス)の数、お よびそれらが提供するOSIレイヤーの機能(例えば、L7機能はL4機 能よりも複雑で、より多くの脆弱性を持つ可能性が高い)などのいくつかの要因によるものである。 本文書の2つの主要な貢献は以下のとおりである: |
1. The nature of exploits possible for each threat in each of the proxy models are characterized by assigning scores to the impact and likelihood of each of these threats in each of the proxy models or architectural patterns resulting in a threat profile associated with each architectural pattern or proxy model of service mesh. | 1. 各プロキシモデルにおける各脅威の影響度と可能性にスコアを割り当てることで、各プロキシモデルにおいて可能な悪用の性質を特徴づけ、その結果、サービスメッシュの各アーキテクチャパターンまたはプロキシモデルに関連付けられた脅威プロファイルを作成する。 |
2. Each threat profile inherently has a built-in set of security tradeoffs at an architectural level. The implications of these tradeoffs in meeting the requirements associated with security risk profile of different cloud-native applications are analyzed to make a broad set of recommendations towards specific architectural patterns that are appropriate for applications with different security risk profiles. | 2. 各脅威プロファイルには、アーキテクチャレベルでのセキュリティトレードオ フのセットが本質的に組み込まれている。さまざまなクラウドネイティブアプリケーションのセキュリ ティリスクプロファイルに関連する要件を満たす上で、これらのトレードオフが持つ意味を分析し、さまざまなセキュリティリスクプロファイルを持つアプリケーションに適した特定のアーキテクチャパターンに向 けて、幅広い推奨を行う。 |
目次...
Executive Summary | エグゼクティブサマリー |
1. Introduction | 1. 序文 |
1.1. L4 and L7 Functions of Proxies | 1.1. プロキシのL4とL7の機能 |
1.2. Objective & Target Audience | 1.2. 目的と対象読者 |
1.3. Relationship to Other NIST Documents | 1.3. 他のNIST文書との関係 |
1.4. Document Structure | 1.4. 文書の構造 |
2. Typical Service Mesh Data Plane Capabilities and Associated Proxy Functions | 2. 典型的なサービスメッシュのデータプレーン機能と関連するプロキシ機能 |
3. Proxy Models (Data plane Architectures) in Service Mesh Implementations | 3. サービスメッシュ実装におけるプロキシモデル(データプレーンアーキテクチャ |
3.1. L4 and L7 Proxy per Service Instance - Sidecar Model (DPA-1) | 3.1. サービスインスタンスごとのL4およびL7プロキシ - サイドカーモデル(DPA-1) |
3.2. Shared L4 - L7 per Service Model (DPA-2) | 3.2. サービスごとの共有L4-L7モデル(DPA-2) |
3.3. Shared L4 and L7 Model (DPA-3) | 3.3. 共有L4およびL7モデル(DPA-3) |
3.4. L4 and L7 Part of the Application Model (DPA-4) | 3.4. アプリケーションモデルのL4とL7部分(DPA-4) |
4. Data Plane Architectures Threat Scenarios and Analysis Methodology | 4. データプレーンアーキテクチャ 脅威シナリオと分析手法 |
4.1. Threat analysis Methodology | 4.1. 脅威分析手法 |
5. Detailed Threat Analysis for Data Plane Architectures | 5. データプレーンアーキテクチャの詳細脅威分析 |
5.1. Threat Analysis for L4 and L7 Proxy per Service Instance - Sidecar Model (DPA-1) | 5.1. サービスインスタンスごとの L4 および L7 プロキシの脅威分析 - サイドカーモデル(DPA-1) |
5.1.1. Compromised L4 Proxy (TR-1) | 5.1.1. 侵害された L4 プロキシ(TR-1) |
5.1.2. Compromised Application Container (TR-2) | 5.1.2. 侵害されたアプリケーションコンテナ(TR-2) |
5.1.3. Compromise of Business Data (TR-3) | 5.1.3. 業務データの漏洩 (TR-3) |
5.1.4. Compromised L7 Proxy (TR-4) | 5.1.4. 侵害された L7 プロキシ(TR-4) |
5.1.5. Compromise of Shared L7 Proxy (TR-5) | 5.1.5. 共有 L7 プロキシの侵害(TR-5) |
5.1.6. Outdated Client Libraries in Applications (TR-6) | 5.1.6. アプリケーションの古いクライアントライブラリ (TR-6) |
5.1.7. Denial of Service (TR-7) | 5.1.7. サービス拒否 (TR-7) |
5.1.8. Resource Consumption (TR-8) | 5.1.8. リソースの消費 (TR-8) |
5.1.9. Privileged L4 Proxy (TR-9) | 5.1.9. 特権 L4 プロキシ (TR-9) |
5.1.10. Data Plane (Service Mesh) Bypassed (TR-10) | 5.1.10. データプレーン(サービスメッシュ)のバイパス(TR-10) |
5.2. Threat Analysis for Shared L4 - L7 per Service Model (DPA-2) | 5.2. サービスモデル(DPA-2)ごとの共有 L4 - L7 の脅威分析 |
5.2.1. Compromised L4 Proxy (TR-1) | 5.2.1. 侵害された L4 プロキシ(TR-1) |
5.2.2. Compromised Application Container (TR-2) | 5.2.2. 侵害されたアプリケーションコンテナ(TR-2) |
5.2.3. Compromise of Business Data (TR-3) | 5.2.3. 業務データの漏洩 (TR-3) |
5.2.4. Compromised L7 Proxy (TR-4) | 5.2.4. 侵害された L7 プロキシ(TR-4) |
5.2.5. Compromise of Shared L7 Proxy (TR-5) | 5.2.5. 共有 L7 プロキシの侵害(TR-5) |
5.2.6. Outdated Client Libraries in Applications (TR-6) | 5.2.6. アプリケーションの古いクライアントライブラリ (TR-6) |
5.2.7. Denial of Service (TR-7) | 5.2.7. サービス拒否 (TR-7) |
5.2.8. Resource Consumption (TR-8) | 5.2.8. リソースの消費 (TR-8) |
5.2.9. Privileged L4 Proxy (TR-9) | 5.2.9. 特権 L4 プロキシ (TR-9) |
5.2.10. Data Plane (Service Mesh) Bypassed (TR-10) | 5.2.10. データプレーン(サービスメッシュ)のバイパス(TR-10) |
5.3. Threat Analysis for Shared L4 and L7 Model (DPA-3) | 5.3. 共有 L4 及び L7 モデルの脅威分析(DPA-3) |
5.3.1. Compromised L4 Proxy (TR-1) | 5.3.1. 侵害された L4 プロキシ(TR-1) |
5.3.2. Compromised Application Container (TR-2) | 5.3.2. 侵害されたアプリケーションコンテナ(TR-2) |
5.3.3. Compromise of Business Data (TR-3) | 5.3.3. 業務データの漏洩 (TR-3) |
5.3.4. Compromised L7 Proxy (TR-4) | 5.3.4. 侵害された L7 プロキシ(TR-4) |
5.3.5. Compromise of Shared L7 Proxy (TR-5) | 5.3.5. 共有 L7 プロキシの侵害(TR-5) |
5.3.6. Outdated Client Libraries in Applications (TR-6) | 5.3.6. アプリケーションの古いクライアントライブラリ (TR-6) |
5.3.7. Denial of Service (TR-7) | 5.3.7. サービス拒否 (TR-7) |
5.3.8. Resource Consumption (TR-8) | 5.3.8. リソースの消費 (TR-8) |
5.3.9. Privileged L4 Proxy (TR-9) | 5.3.9. 特権 L4 プロキシ (TR-9) |
5.3.10. Data Plane (Service Mesh) Bypassed (TR-10) | 5.3.10. データプレーン(サービスメッシュ)のバイパス (TR-10) |
5.4. Threat Analysis for L4 and L7 within Application Model (gRPC proxyless Model (DPA-4)) | 5.4. アプリケーションモデル(gRPC プロキシレスモデル(DPA-4))内の L4 及び L7 の脅威分析 |
5.4.1. Compromised L4 Proxy (TR-1) | 5.4.1. 侵害された L4 プロキシ(TR-1) |
5.4.2. Compromised Application Container (TR-2) | 5.4.2. 侵害されたアプリケーションコンテナ(TR-2) |
5.4.3. Compromise of Business Data (TR-3) | 5.4.3. 業務データの漏洩 (TR-3) |
5.4.4. Compromised L7 Proxy (TR-4) | 5.4.4. 侵害された L7 プロキシ(TR-4) |
5.4.5. Compromise of Shared L7 Proxy (TR-5) | 5.4.5. 共有 L7 プロキシの侵害(TR-5) |
5.4.6. Outdated Client Libraries in Applications (TR-6) | 5.4.6. アプリケーションの古いクライアントライブラリ (TR-6) |
5.4.7. Denial of Service (TR-7) | 5.4.7. サービス拒否 (TR-7) |
5.4.8. Resource Consumption (TR-8) | 5.4.8. リソースの消費 (TR-8) |
5.4.9 Privileged L4 Proxy (TR-9) | 5.4.9 特権 L4 プロキシ (TR-9) |
5.4.10 Data Plane (Service Mesh) Bypassed (TR-10) | 5.4.10 データプレーン(サービスメッシュ)のバイパス(TR-10) |
6. Recommendations Based on Application Security Risk Profile | 6. アプリケーションセキュリティリスクプロファイルに基づく推奨事項 |
6.1. Cloud-Native Applications with Low Risk Profile | 6.1. リスクプロファイルが低いクラウドネイティブアプリケーション |
6.2. Cloud-Native Applications with Medium Risk Profile … | 6.2. リスクプロファイルが中程度のクラウドネイティブ・アプリケーション |
6.3. Cloud-Native Applications with High Risk Profile | 6.3. 高リスクプロファイルのクラウドネイティブアプリケーション |
7. Summary and Conclusions | 7. まとめと結論 |
References | 参考文献 |
Figure 1 – L4 and L7 Proxy per Service Instance (Side Car Model) (DPA-1)
図1 - サービスインスタンスごとのL4およびL7プロキシ(サイドカーモデル)(DPA-1)
Figure 2 – Shared L4 - L7 per Service Model (DPA-2)
図2 - サービスごとの共有L4 - L7 モデル(DPA-2)
Figure 3 – Shared L4 - L7 Model (DPA-3)
図3 - 共有L4 - L7モデル(DPA-3)
Figure 4 – L4 and L7 Part of the Application Model (gRPC proxyless Model) (DPA-4)
図4-アプリケーションモデル(gRPCプロキシレスモデル)のL4とL7の部分(DPA-4)
« 欧州 Europol インターネット組織犯罪脅威アセスメント(IOCTA)2024年版 | Main | 米国 CISA インフラ・レジリエンス計画のためのプレイブック (2024.07.17) »
Comments