米国 NIST SP 800-228 更新版 クラウドネイティブシステム向けAPI防御ガイドライン (2026.03.13)
こんにちは、丸山満彦です。
NISTが、SP 800-228 クラウドネイティブシステム向けAPI防御ガイドライン。昨年６月に公開されたバージョンの更新版。附属書D：リスクカテゴリー別APIリスク一覧、附属書E：API ライフサイクル段階別推奨セキュリティ制御リストが追加されています...
API はソフトウェアの一部だけど、外から見える場合も多いし、攻撃面が広いから、DevSecOps を高いレベルで徹底しないと危ないよということですかね...
● NIST - ITL
・2026.03.13 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-upd1
エグゼクティブサマリー...
| 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によって接続されたアプリケーションシステムのセキュリティ態勢を脅かす恐れがある。 これらの脆弱性を識別し対処するための体系的かつ効果的な手段は、APIの開発と展開を、開発、セキュリティ、運用（DevSecOps）といったパラダイムを用いた反復的なライフサイクルとして扱うことによってのみ可能となる。 |
| 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を対象とするべきである。 |
| • 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) 実行時防御に分類されるべきであり、実行時防御はさらに基本防御と高度な防御に細分化され、リスクベースの段階的な導入を可能にする必要がある。 |
目次...
| 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を含むリクエスト |
| 2.7.5. Reaching Out to Other Systems | 2.7.5. 他のシステムへの接続 |
| 2.7.6. Mitigating the Confused Deputy | 2.7.6. 「Confused Deputy」の緩和 |
| 2.7.7. Identity Canonicalization | 2.7.7. アイデンティティの正規化 |
| 3. Recommended Controls for APIs | 3. API に対する推奨対策 |
| 3.1. Pre-Runtime Protections All API controls must be well-defined and inventoried. | 3.1. 実行前防御すべてのAPI制御は明確に定義され、一覧化されなければならない。 |
| 3.1.1. Basic Pre-Runtime Protections | 3.1.1. 基本的な実行前防御 |
| 3.1.2. Advanced Pre-Runtime Protections | 3.1.2. 実行前の高度な防御措置 |
| 3.2. Runtime Protections For runtime protections for APIs, apply zero trust principles as a baseline, and augment them with additional policy on requests and their payloads. | 3.2. 実行時防御APIの実行時防御については、ゼロトラストの原則を基本とし、リクエストとそのペイロードに対する追加のポリシーでこれを補強する。 |
| 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. Webアプリケーションファイアウォール |
| 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. Webアプリケーションおよび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. 実行時に設定される制限タイプ |
| Appendix D. List of API Risks by Risk Categories | 附属書D. リスクカテゴリー別APIリスク一覧 |
| Appendix E. List of Recommended Security Controls by API Lifecycle Stage | 附属書 E. API ライフサイクル段階別推奨セキュリティ制御リスト |
| Appendix F. Change Log | 附属書F. 変更履歴 |
● まるちゃんの情報セキュリティ気まぐれ日記
・2025.07.04 米国 NIST SP 800-228 クラウドネイティブシステムのための API 保護に関するガイドライン (2025.06.27)
・2025.03.26 米国 NIST SP 800-228（初期公開ドラフト）クラウドネイティブシステムのAPI防御ガイドライン
Comments