米国NIST SP 800-233 クラウドネイティブ・アプリケーションのためのサービスメッシュ・プロキシモデル (2024.10.16)
こんにちは、丸山満彦です。
NISTが、SP 800-233 Service Mesh Proxy Models for Cloud-Native Applicationsを公表していますね...
今年の2024.07にドラフトが公開されていましたが、確定しましたね...
この考えは重要となりますね...勉強しなくては...
● NIST - ITL
・2024.10.16 NIST SP 800-233 Service Mesh Proxy Models for Cloud-Native Applications
| NIST SP 800-233 Service Mesh Proxy Models for Cloud-Native Applications | NIST SP 800-233 クラウドネイティブ・アプリケーションのためのサービスメッシュ・プロキシモデル |
| 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
| Executive Summary | エグゼクティブサマリー |
| A centralized infrastructure called a service mesh can provide run-time services for cloud-native applications that consist of multiple loosely coupled components called microservices. 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, which is 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 Open Systems Interconnection (OSI) model’s network layer to which those functions pertain: | プロキシが提供する機能は、開放型システム間相互接続（OSI）モデルのネットワークレイヤーに基づき、2つのグループに大別できる： |
| Layer 4 (“L4”) and Layer 7 (“L7”). In most service mesh deployments in production environments today, all proxy functions that provide 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. | レイヤー4（「L4」）とレイヤー7（「L7」）である。今日の本番環境のほとんどのサービスメッシュ展開では、L4とL7の両レイ ヤーのサービスを提供するすべてのプロキシ機能は、単一のマイクロ サービスに割り当てられる単一のプロキシにパックされる。このサービスメッシュのプロキシモデルは、プロキシが一つのサービ スに関連付けられるだけでなく、サービスと同じネットワーク空間で実 行されるように実装されるので、サイドカープロキシモデルと呼ばれる。 |
| However, performance and resource considerations have led to the exploration of alternate proxy models that involve splitting L4 and L7 functions into different proxies and the association or assignments of these proxies to either a single service or a group of services. This enables 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, this document only considers service mesh proxy models in the data plane implementation of commonly used service mesh offerings at different stages. | しかしながら、機能とリソースの考慮により、L4とL7機能を異なるプロキシに 分割し、これらのプロキシを単一サービスまたはサービスグループのいずれかに 関連付けまたは割り当てることを含む、代替プロキシモデルの探究が始ま った。これによって、プロキシをサービスレベルではなく、ノードの粒度で異なる場所に実装することが可能になる。理論的には様々なモデルが可能であるが、このドキュメントでは、様々な 段階で一般的に使用されるサービスメッシュのデータプレーン実装におけ るサービスメッシュプロキシモデルについてのみ考察する。 |
| Various potential or likely threats to proxy functions may result in different types of exploits in different proxy models. This variation is due to several factors, such as the attack surface (i.e., communication patterns to which a particular proxy is exposed), the number of clients (services) served, and the OSI layer functions that 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 the following: | プロキシ機能に対する様々な潜在的またはありそうな脅威は、異なるプロ キシモデルにおいて異なるタイプの悪用をもたらすかもしれない。この変化は、攻撃表面(すなわち、特定のプロキシがさらされ るコミュニケーションパターン)、サービスを提供するクライアント(サービ ス)の数、およびそれらが提供するOSIレイヤーの機能(例えば、L7機能はL4機 能よりも複雑であり、より多くの脆弱性を持つ可能性が高い)などのい くつかの要因によるものである。このドキュメントの2つの主要な貢献は以下である： |
| 1. The nature of the exploits that are possible for each threat in each of the proxy models is characterized by assigning scores to the impact and likelihood of each of the threats in each of the proxy models or architectural patterns, resulting in a threat profile that is associated with each architectural pattern or proxy model of service mesh. | 1. プロキシモデルまたはアーキテクチャパターンの各々において、各 脅威の影響度と可能性にスコアを割り当てることで、各プロキシ モデルにおいて各脅威に可能な悪用の性質を特徴付け、その結果、サービ スメッシュの各アーキテクチャパターンまたはプロキシモデルに 関連付けられた脅威プロファイルを作成する。 |
| 2. Each threat profile has an inherent set of security trade-offs at an architectural level. The implications of these trade-offs in meeting the requirements associated with the security risk profiles of different cloud-native applications are analyzed to make a broad set of recommendations toward 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 and 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 (DPA-1) - Sidecar Model | 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 as Part of the Application Model (DPA-4) | 3.4. アプリケーションモデルの一部としてのL4とL7（DPA-4） |
| 4. Data Plane Architecture 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 (DPA-1) - Sidecar Model | 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.1.11 Overall Threat Score | 5.1.11 総合脅威スコア |
| 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.2.11. Overall Threat Score | 5.2.11. 総合脅威スコア |
| 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.3.11. Overall Threat Score | 5.3.11. 総合脅威スコア |
| 5.4. Threat Analysis for L4 and L7 as Part of the 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） |
| 5.4.11. Overall Threat Score | 5.4.11. 総合脅威スコア |
| 6. Recommendations Based on the Application Security Risk Profile | 6. アプリケーションセキュリティ・リスクプロファイルに基づく推奨事項 |
| 6.1 Cloud-Native Applications With Low Risk Profiles | 6.1 低リスクプロファイルのクラウドネイティブ・アプリケーション |
| 6.2 Cloud-Native Applications with Medium Risk Profiles | 6.2 中リスクプロファイルのクラウドネイティブ・アプリケーション |
| 6.3 Cloud-Native Applications With High Risk Profiles | 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）
Fig. 4. L4 and L7 as Part of the Application Model (gRPC proxyless Model) (DPA-4)
図4.アプリケーションモデル（gRPCプロキシレスモデル）の一部としてのL4とL7（DPA-4）
● まるちゃんの情報セキュリティ気まぐれ日記
・2024.07.24 米国 NIST SP 800-233（初期公開ドラフト） クラウドネイティブアプリケーションのサービスメッシュプロキシモデル (2024.07.19)
« 米国 ホワイトハウス：2024 年「重要インフラの安全保障とレジリエンス月間」に関する宣言 | Main | 米国 NIST サイバーセッキュリティフレームワーム2.0関係のクイックスタートガイド SP 1302 CSF の階層の使用、SP 1303 エンタープライズリスクマネジメント、SP 1305 サイバーセキュリティサプライチェーンリスクマネジメント（C-SCRM） »
Comments