米国 NIST SP 800-228 クラウドネイティブシステムのための API 保護に関するガイドライン (2025.06.27)
こんにちは、丸山満彦です。
クラウドネイティブ時代になり、システムの連携にAPIが多用され、不可欠となっている状況で、外部との接点をもつAPIが適切に設計、保護されていることは、サイバー攻撃から組織内外のプロセスを保護する上でも重要となっていますよね...
ということで、APIに特化したセキュリティのガイダンス...
● NIST - ITL
・2025.06.27 NIST SP 800-228 Guidelines for API Protection for Cloud-Native Systems
| NIST SP 800-228 Guidelines for API Protection for Cloud-Native Systems | NIST SP 800-228 クラウドネイティブシステムのための API 保護に関するガイドライン |
| Abstract | 要約 |
| Modern enterprise IT systems rely on a family of application programming interfaces (APIs) for integration to support organizational business processes. Hence, a secure deployment of APIs is critical for overall enterprise security. This, in turn, requires the identification of risk factors or vulnerabilities in various phases of the API life cycle and the development of controls or protection measures. This document addresses the following aspects of achieving that goal: (a) the identification and analysis of risk factors or vulnerabilities during various activities of API development and runtime, (b) recommended basic and advanced controls and protection measures during the pre-runtime and runtime stages of APIs, and (c) an analysis of the advantages and disadvantages of various implementation options for those controls to enable security practitioners to adopt an incremental, risk-based approach to securing their APIs. | 現代のエンタープライズ IT システムは、組織のビジネスプロセスをサポートするための統合に、一連のアプリケーション・プログラミング・インターフェース(API)に依存している。したがって、API の安全な展開は、エンタープライズ全体のセキュリティにとって極めて重要だ。そのためには、API ライフサイクルのさまざまな段階でリスク要因や脆弱性を特定し、制御や保護手段を開発する必要がある。この文書では、その目標を達成するための以下の側面について取り上げる。(a) API の開発および実行のさまざまな活動におけるリスク要因や脆弱性の特定と分析、(b) API の実行前および実行段階における推奨される基本および高度な制御および保護対策、(c) セキュリティ担当者が API のセキュリティ確保のために、リスクベースの段階的なアプローチを採用できるようにするための、これらの制御のさまざまな実装オプションの長所と短所の分析。 |
・[PDF] NIST.SP.800-228
・[DOCX][PDF] 仮訳
目次...
| Executive Summary | エグゼクティブサマリー |
| 1. Introduction | 1. 序論 |
| 1.1. Zero Trust and APIs: The Vanishing Perimeter | 1.1. ゼロ・トラストとAPI消えゆく境界 |
| 1.2. API Life Cycle | 1.2. APIのライフサイクル |
| 1.3. Document Goals | 1.3. 文書の目標 |
| 1.4. Relationship to Other NIST Documents | 1.4. 他の NIST 文書との関係 |
| 1.5. Document Structure | 1.5. 文書の構成 |
| 2. API Risks: Vulnerabilities and Exploits | 2. API リスク:脆弱性と悪用 |
| 2.1. Lack of Visibility of APIs in the Enterprise Inventory | 2.1. エンタープライズインベントリにおける API の可視性の欠如 |
| 2.2. Missing, Incorrect, or Insufficient Authorization | 2.2. 認可の欠落、不正確、不十分 |
| 2.3. Broken Authentication | 2.3. 壊れた認証 |
| 2.4. Unrestricted Resource Consumption | 2.4. 無制限のリソース消費 |
| 2.4.1. Unrestricted Compute Resource Consumption | 2.4.1. 無制限の計算消費 |
| 2.4.2. Unrestricted Physical Resource Consumption | 2.4.2. 無制限の物理リソース消費 |
| 2.5. Leaking Sensitive Information to Unauthorized Callers | 2.5. 権限のない発信者への機密情報の漏えい |
| 2.6. Insufficient Verification of Input Data | 2.6. 入力データの不十分な検証 |
| 2.6.1. Input Validation | 2.6.1. 入力の妥当性確認 |
| 2.6.2. Malicious Input Protection | 2.6.2. 悪意のある入力防御 |
| 2.7. Credential Canonicalization: Preparatory Step for Controls | 2.7. クレデンシャルの正規化: コントロールの準備段階 |
| 2.7.1. Gateways Straddle Boundaries | 2.7.1. ゲートウェイは境界をまたぐ |
| 2.7.2. Requests With a Service Identity But No User Identity | 2.7.2. サービスIDはあるがユーザーIDがないリクエスト |
| 2.7.3. Requests With a User Identity But No Service Identity | 2.7.3. ユーザーIDを持つがサービスIDを持たないリクエスト |
| 2.7.4. Requests With Both User and Service Identities | 2.7.4. ユーザーIDとサービスIDの両方を持つリクエスト |
| 2.7.5. Reaching Out to Other Systems | 2.7.5. 他のシステムへのリーチアウト |
| 2.7.6. Mitigating the Confused Deputy | 2.7.6. 混乱した代理の緩和 |
| 2.7.7. Identity Canonicalization | 2.7.7. ID の正規化 |
| 3. Recommended Controls for APIs | 3. API に対する推奨コントロール |
| 3.1. Pre-Runtime Protections | 3.1. ランタイム前の防御 |
| 3.1.1. Basic Pre-Runtime Protections | 3.1.1. 基本的なランタイム前の防御 |
| 3.1.2. Advanced Pre-Runtime Protections | 3.1.2. 高度なランタイム前の防御 |
| 3.2. Runtime Protections | 3.2. ランタイム防御 |
| 3.2.1. Basic Runtime Protections | 3.2.1. 基本的なランタイム防御 |
| 3.2.2. Advanced Runtime Protections | 3.2.2. 高度なランタイム防御 |
| 4. Implementation Patterns and Trade-Offs for API Protections | 4. API保護の実装パターンとトレードオフ |
| 4.1. Centralized API Gateway | 4.1. 集中型APIゲートウェイ |
| 4.2. Hybrid Deployments | 4.2. ハイブリッド展開 |
| 4.3. Distributed Gateway Pattern | 4.3. 分散ゲートウェイパターン |
| 4.4. Related Technologies | 4.4. 関連技術 |
| 4.4.1. Web Application Firewalls | 4.4.1. ウェブアプリケーションファイアウォール |
| 4.4.2. Bot Detection | 4.4.2. ボット検知 |
| 4.4.3. Distributed Denial of Service (DDoS) Mitigation | 4.4.3. 分散サービス拒否(DDoS)の緩和 |
| 4.4.4. API Endpoint Protection | 4.4.4. API エンドポイントの防御 |
| 4.4.5. Web Application and API Protection (WAAP) | 4.4.5. ウェブアプリケーションとAPIの防御(WAAP) |
| 4.5. Summary of Implementation Patterns | 4.5. 実装パターンのまとめ |
| 5. Conclusions and Summary | 5. 結論とまとめ |
| References | 参考文献 |
| Appendix A. API Classification Taxonomy | 附属書A.API分類の分類法 |
| A.1. API Classification Based on Degree of Exposure | A.1. エクスポージャーの程度に基づくAPIの分類 |
| A.2. API Classification Based on Communication Patterns | A.2. コミュニケーションパターンに基づくAPIの分類 |
| A.3. API Classification Based on Architectural Style or Pattern (API Types) | A.3. アーキテクチャのスタイルやパターンに基づくAPIの分類(APIタイプ) |
| A.4 API Classification Based on Data Sensitivity | A.4 データ機密性に基づくAPI分類 |
| Appendix B. DevSecOps Phases and Associated Classes of API Controls | 附属書B. DevSecOpsフェーズとAPIコントロールの関連クラス |
| Appendix C. Limit Types Configured During Runtime | 附属書C. ランタイム中に設定されるリミットタイプ |
| List of Figures | 図一覧 |
| Fig. 1. API, API endpoint, service, and service instance | 図1. API、APIエンドポイント、サービス、サービスインスタンス |
| Fig. 2. Service API, facade API, and application (monolithic) | 図2. サービスAPI、ファサードAPI、アプリケーション(モノリシック) |
| Fig. 3. DevSecOps life cycle phases | 図3. DevSecOpsライフサイクルのフェーズ |
| Fig. 4. Handling API calls with user identity but no service identity | 図4 .ユーザーIDはあるがサービスIDがないAPIコールの処理 |
| Fig. 5. Identity canonicalization for handling API calls | 図5. API 呼び出しを処理するための ID の正規化 |
| Fig. 6. API gateway patterns | 図6 .APIゲートウェイのパターン |
| Fig. 7. Centralized API gateway pattern | 図7. 集中型APIゲートウェイのパターン |
| Fig. 8. Hybrid gateway pattern | 図8. ハイブリッド・ゲートウェイ・パターン |
| Fig. 9. Distributed API gateway pattern | 図9. 分散APIゲートウェイパターン |
| Fig. 10. Service-to-service traffic flows in distributed API gateway pattern | 図10. 分散APIゲートウェイパターンにおけるサービス間トラフィックの流れ |
エグゼクティブサマリー...
| Executive Summary | エグゼクティブサマリー |
| Application programming interfaces (APIs) provide the means to integrate and communicate with the modern enterprise IT application systems that support business processes. However, a lack of due diligence can introduce vulnerabilities and risk factors that exploit the connectivity and accessibility features of APIs. If these vulnerabilities are not identified, analyzed, and addressed through control measures, attack vectors could threaten the security posture of the application systems spanned by these APIs. A systematic and effective means of identifying and addressing these vulnerabilities is only possible by treating the development and deployment of APIs as an iterative life cycle using paradigms like development, security, and operations (DevSecOps). | アプリケーション・プログラミング・インターフェース(API)は、ビジネス・プロセスをサポートする最新のエンタープライズITアプリケーション・システムと統合し、コミュニケーションするための手段を提供する。しかし、デューディリジェンスの欠如は、API の接続性とアクセシビリティの特徴を悪用する脆弱性とリスク要因を導入する可能性がある。これらの脆弱性が識別され、分析され、管理策を通じて対処されない場合、攻撃ベクトルは、APIによってスパンされるアプリケーションシステムのセキュリティ体制を脅かす可能性がある。これらの脆弱性を識別し、対処する体系的で効果的な手段は、開発、セキュリティ、及び、運用(DevSecOps) のようなパラダイムを使用して、API の開発と展開を反復的なライフサイクルとして扱うことによってのみ可能である。 |
| This document provides guidelines and recommendations on controls and protection measures for secure API deployments in the enterprise. In addition, an analysis of the advantages and disadvantages of various implementation options (called patterns) for those controls enable security practitioners to choose the most effective option for their IT ecosystem. | この文書は、エンタープライズにおける安全なAPI展開のためのコントロールと保護対策に関するガイドラインと推奨事項を提供する。加えて、これらのコントロールの様々な実装オプション(パターンと呼ばれる)の長所と短所を分析することで、セキュリティ担当者が、その IT エコシステムに最も効果的なオプションを選択できるようにする。 |
| Developing these controls and analyzing their implementation options should be guided by several overarching principles: | このような管理策の策定と実装オプションの分析は、いくつかの包括的な原則によって導かれなければならない: |
| • The guidance for controls should cover all APIs, regardless of whether they are exposed to customers/partners or used internally within the enterprise. | • 管理策のガイダンスは、API が顧客/パートナーに公開されているか、エンタープライズ内部で使用されているかに関係なく、すべての API を対象とすべきである。 |
| • With the vanishing of perimeters in modern enterprise IT applications, all controls should incorporate the concept of zero trust. | • 現代のエンタープライズITアプリケーションでは境界がなくなりつつあるため、全ての管理はゼロトラストの概念を取り入れるべきである。 |
| • The controls should span the entire API life cycle and be classified into (a) pre-runtime protections and (b) runtime protections that are then subdivided into basic and advanced protections to enable incremental risk-based adoption. | • コントロールはAPIのライフサイクル全体に及び、(a)実行前の防御と(b)実行時の防御に分類され、さらにリスクベースの段階的な導入を可能にするために基本的な防御と高度な防御に細分化されるべきである。 |
● まるちゃんの情報セキュリティ気まぐれ日記
・2025.03.26 米国 NIST SP 800-228(初期公開ドラフト)クラウドネイティブシステムのAPI防御ガイドライン
« ドイツ データ保護会議 安全保障についての意見「安全なくして自由はない – 自由なくして安全はない」と「AIシステムの開発と運用のための推奨される技術的・組織的措置に関するガイダンス」(2025.06.17) | Main | 経済産業省 「半導体デバイス工場におけるOTセキュリティガイドライン(案)」(2025.06.27) »

Comments