米国 NIST SP 800-228（初期公開ドラフト）クラウドネイティブシステムのAPI防御ガイドライン

こんにちは、丸山満彦です。

NISTがSP 800-228（初期公開ドラフト）クラウドネイティブシステムのAPI保護ガイドライを公表し、意見募集をしていますね...

組織のシステムがクラウドに移行に、各システムの連携がAPIを通じて行われるようになると、APIをいかに守るかということは開発者にとっても、利用者にとっても重要となりますよね...

● NIST - ITL

・2025.03.25 NIST SP 800-228 (Initial Public Draft) Guidelines for API Protection for Cloud-Native Systems

NIST SP 800-228 (Initial Public Draft) Guidelines for API Protection for Cloud-Native Systems	NIST SP 800-228（初期公開ドラフト）クラウドネイティブシステムのAPI保護ガイドライ
Announcement	発表
Modern enterprise IT systems rely on a family of application programming interfaces (APIs) for integration to support organizational business processes. Hence, a secure development and 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 to prevent their exploits.	現代のエンタープライズITシステムは、組織のビジネスプロセスをサポートする統合のために、アプリケーション・プログラミング・インターフェース（API）ファミリーに依存している。したがって、APIの安全な開発と展開は、エンタープライズ全体のセキュリティにとって極めて重要である。そのためには、APIのライフサイクルの様々な段階におけるリスク要因や脆弱性を特定し、その悪用を防ぐための管理策や防御策を開発する必要がある。
This document addresses the following aspects for achieving that goal:	この文書では、その目標を達成するために、次の側面を取り上げる：
a. The identification and analysis of risk factors or vulnerabilities introduced during various activities of API development and runtime,	a. API の開発と実行時の様々な活動中に導入されるリスク要因や脆弱性の特定と分析、
b. Recommended basic and advanced controls and protection measures during the pre-runtime and runtime stages of APIs, and	b. API の実行前と実行時の段階における、推奨される基本的で高度な制御と保護対策、
c. An analysis of the advantages and disadvantages of various implementation options (i.e., patterns) for those controls to enable security practitioners to adopt an incremental, risk-based approach to securing their APIs.	c. セキュリティ担当者が、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 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.ipd

目次...

Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序文
1.1. Building Blocks and Structures	1.1. ビルディングブロックと構造
1.2. Zero Trust and APis: The Vanishing Perimeter	1.2. ゼロトラストとAPI：
1.3. API Life Cycle	1.3. APIのライフサイクル
1.4. Document Goals…	1.4. 文書の目標...
1.5. Relationship to Other NIST Documents	1.5. 他の NIST 文書との関係
1.6. Document Structure	1.6. 文書構造
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 ldentity	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. アイデンティティの正規化
3. Recommended Controls for APls	3. APls
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. Decentralized Gateways	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分類
Appendix B. DevSecOps Phase and Associated Class of API Controls	附属書B. DevSecOpsのフェーズと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 DevSecOps.	アプリケーションプログラミングインタフェース（API）は、ビジネスプロセスをサポートする最新のエンタープライズITアプリケーションシステムと統合し、コミュニ ケーションするための手段を提供する。しかし、デューディリジェンスの欠如は、APIの接続性とアクセシビリティ機能を悪用する脆弱性とリスク要因を導入する可能性がある。これらの脆弱性が特定され、分析され、管理策を通じて対処されない場合、攻撃ベクトルは、これらのAPIによってスパンされるアプリケーションシステムのセキュリティ体制を脅かす可能性がある。これらの脆弱性を特定し、対処する体系的で効果的な手段は、DevSecOps のようなパラダイムを使用して、 API の開発と展開を反復的なライフサイクルとして扱うことによってのみ可能である。
This document provides guidance 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)実行時の防御に分類され、さらにリスクベースの段階的な導入を可能にするために、基本的な防御と高度な防御に細分化されるべきである。
1. Introduction	1. 序文
Application programming interfaces (APIs) represent an abstraction of the underlying implementation of a digital enterprise. Given the spatial (e.g., on-premises, multiple clouds) and logical (e.g., microservices) nature of current enterprise applications, APIs are needed to integrate and establish communication pathways between internal and third-party services and applications. Informally, APIs are the lingua franca of modern IT systems: they describe what actions users are allowed to take. They are also used in every type of application, including server-based monolithic, microservices-based, browser-based client, and IoT.	アプリケーション・プログラミング・インターフェース（API）は、デジタル・エ ンタープライズの基本的な実装を抽象化した代表者である。現在のエンタープライズ・アプリケーションの空間的（例：オンプレミス、複数のクラウド）かつ論理的（例：マイクロサービス）な性質を考慮すると、APIは内部とサードパーティ・サービスおよびアプリケーション間のコミュニケーション経路を統合し確立するために必要である。非公式に言えば、APIは現代のITシステムの共通語であり、ユーザーがどのようなアクションを取ることができるかを記述している。また、サーバーベースのモノリシック、マイクロサービスベース、ブラウザベースのクライアント、IoTなど、あらゆるタイプのアプリケーションで使用されている。
1.1. Building Blocks and Structures	1.1. ビルディング・ブロックと構造
An Application Programming Interface (API) defines how any two pieces of software communicate – they are ubiquitous in software. An API is a collection of commands or endpoints that operate on data or objects via some protocol. Network-based APIs are APIs built to be consumed by remote applications over the network. Because they’re exposed and consumed over the network, they present a unique set of challenges. The growth of (micro-) service-oriented architectures, coupled with Software-as-a-Service (SaaS) becoming commonplace – which are nearly always delivered via APIs – has resulted in an explosion in network-based APIs across organizations. This document focuses on controls for network-based APIs.	アプリケーション・プログラミング・インターフェース（API）は、2つのソフトウェアがどのようにコミュニケーションするかを定義する。APIは、何らかのプロトコルを介してデータやオブジェクトを操作するコマンドやエンドポイントの集合体である。ネットワークベースのAPIは、ネットワークを介してリモート・アプリケーションから消費されるように作られたAPIだ。ネットワーク上で公開され、消費されるため、APIには独特の課題がある。(マイクロ)サービス指向アーキテクチャの成長と、SaaS(Software-as-a-Service)の一般化(これらはほぼ常にAPI経由で提供される)が相まって、組織全体でネットワークベースのAPIが爆発的に増加した。この文書では、ネットワークベースの API のコントロールに焦点を当てる。
Before we can discuss API controls, we need a common understanding and language for the building blocks, and how they relate to each other. The taxonomy is: an API is composed of a set of API Endpoints; API Endpoints are implemented by Services; at runtime, Requests to a specific API Endpoint are served by Service Instances. An API Gateway hosts many APIs and is responsible for mapping each Request to its target API Endpoint, applying policy for that Endpoint (e.g. authentication and rate limiting), then routing that Request to a Service Instance which implements that API Endpoint.	APIのコントロールについて議論する前に、構成要素とそれらがどのように互いに関連しているかについての共通の理解と言語が必要である。APIはAPIエンドポイントのセットで構成され、APIエンドポイントはサービスによって実装され、実行時に特定のAPIエンドポイントへのリクエストはサービスインスタンスによって処理される。APIゲートウェイは多くのAPIをホストし、各リクエストをターゲットのAPIエンドポイントにマッピングし、そのエンドポイントのポリシー（認証やレート制限など）を適用し、そのAPIエンドポイントを実装するサービスインスタンスにそのリクエストをルーティングする。
Fig. 1. API, API Endpoint, Service and Service Instance	Fig. API、APIエンドポイント、サービス、サービスインスタンス
Traditionally, we think of network-based APIs as being customer-oriented, partner-oriented, or internal – often called “third-party”, “second-party”, and “first-party” APIs, respectively. Second- and third-party APIs are typically exposed to callers outside of the organization via an API gateway. First-party APIs can be exposed to callers inside of the organization on the same API gateway, but they are also often consumed directly by internal callers without traversing a dedicated API serving stack.	伝統的に、我々はネットワークベースのAPIを顧客指向、パートナー指向、内部指向、それぞれ「サードパーティ」、「セカンドパーティ」、「ファーストパーティ」APIと呼ばれることが多いと考える。セカンドパーティとサードパーティのAPIは通常、APIゲートウェイを介して組織外の呼び出し元に公開される。ファーストパーティAPIは同じAPIゲートウェイ上で組織内部の呼び出し元に公開されることもあるが、専用のAPIサービングスタックを経由せずに内部の呼び出し元によって直接消費されることも多い。
An API is a set of API Endpoints, and a Service implements a set of API Endpoints – so every Service implements some API. We call these Service APIs. Most first-party API integrations happen via the Service API, i.e. they map to a single service. On the other hand, APIs hosted by the API gateway typically have Endpoints that map to many different Services. This is especially common for second- and third-party APIs. We call these Facade APIs, because they present a single facade to an outside caller over (potentially many) different Service APIs. Finally, it’s common that multiple Services are grouped together into an Application – typically along organizational lines (often an Application maps to a team). Schematic diagrams of a Service API, Façade API and an Application (Monolithic) API are given below:	APIはAPIエンドポイントの集合であり、サービスはAPIエンドポイントの集合を実装する。私たちはこれらをサービスAPIと呼んでいる。ほとんどのファーストパーティAPI統合はサービスAPIを介して行われる。一方、APIゲートウェイによってホストされるAPIは通常、多くの異なるサービスにマッピングされるエンドポイントを持っている。これは特にセカンドパーティやサードパーティのAPIによく見られる。このようなAPIをファサードAPIと呼ぶ。なぜなら、ファサードAPIは、（潜在的に多くの）異なるサービスAPI上の単一のファサードを外部の呼び出し元に提示するからである。最後に、複数のサービスがアプリケーションにグループ化されるのはよくあることで、通常は組織的な線に沿っている（多くの場合、アプリケーションはチームにマッピングされる）。サービスAPI、ファサードAPI、アプリケーション（モノリシック）APIの概略図を以下に示す：
Fig. 2. (Top to Bottom) Service API, Façade API, Service and Application (Monolithic)	図2（上から下へ）サービスAPI、ファサードAPI、サービス、アプリケーション（モノリシック）
Less formally: we can think of the APIs we expose outside the organization as a facade over a set of Services. Those Services implement internal APIs (Service APIs). Services in the organization communicate with each other via those internal APIs – sometimes directly, and sometimes via an API gateway. The API Gateway is responsible for some policies, like authentication and rate limiting, as well as being responsible for mapping the facade APIs for external clients to internal APIs. Then, to get a handle on things organizationally, we often group related Services into a bucket called an Application.	あまり形式的ではないが、組織の外部に公開するAPIは、一連のサービスを覆うファサードと考えることができる。これらのサービスは内部API（サービスAPI）を実装する。組織内のサービスは、これらの内部APIを介して、時には直接、時にはAPIゲートウェイを介して相互にコミュニケーションする。APIゲートウェイは、認証やレート制限のようなポリシーを担当し、外部クライアントのためのファサードAPIを内部APIにマッピングする役割も担っている。それから、組織的に物事を把握するために、関連するサービスをアプリケーションと呼ばれるバケットにグループ化することが多い。
While we tend to think of APIs in the context of exposing functionality to clients or partners, APIs don’t exist solely at the edge of our infrastructure. Any time systems communicate, there’s some API involved. Even if that API is something like CSV over FTP. The examples in SP focus primarily on “modern” APIs exposed via mechanisms like HTTP/REST, gRPC, or SOAP, but we believe the principals in this SP are universal and should be applied to all APIs.	APIというと、クライアントやパートナーに機能を公開するという文脈で考えがちだが、APIはインフラの端だけに存在するわけではない。システムがコミュニケーションするときには、必ずAPIが関係している。たとえそのAPIがFTP経由のCSVのようなものであってもだ。SPの例は、主にHTTP/REST、gRPC、SOAPのようなメカニズムで公開される 「最新の 」APIに焦点を当てているが、このSPの原則は普遍的であり、すべてのAPIに適用されるべきだと考えている。
1.2. Zero Trust and APIs: The Vanishing Perimeter	1.2. ゼロトラストとAPI 消滅する境界
APIs are built out of services that communicate with each other via APIs, similar to how the internet is a “network of networks.” One of the most important implications of zero trust is that there is no meaningful distinction between an “internal” and “external” caller because the perimeter is the service instance itself. Rather, all callers are trusted if they are authorized to be trusted. This contrasts with traditional approaches to API security in which the only “APIs” are those exposed to “external” callers, and API-oriented controls are only enforced at the perimeter, typically via an API gateway.	APIは、インターネットが 「ネットワークのネットワーク 」であるのと同様に、APIを介して相互にコミュニケーショ ンするサービスから構築される。ゼロトラストの最も重要な意味の1つは、境界がサービスインスタンスそのものであるため、「内部」と「外部」の呼び出し者の間に意味のある区別がないということである。むしろ、すべての呼び出し元は、信頼されることが認可されていれば信頼される。これは、「API」だけが「外部」呼び出し元に公開され、API指向の制御が境界でのみ、典型的にはAPIゲートウェイを介して実施される、APIセキュリティへの従来のアプローチとは対照的である。
NIST Special Publication (SP) 800-207A [6] discusses zero trust at runtime and the principle of shrinking the perimeter to the service instance using the five runtime controls of identity-based segmentation:	NIST 特別刊行物（SP）800-207A [6]は、実行時のゼロトラストと、ID ベースのセグメンテーションの 5 つの実行時コントロールを使用して、境界をサービスインスタンスに縮小する原則について論じている：
1. Encryption in transit — To ensure message authenticity and prevent eavesdropping, thus preserving confidentiality	1. 転送中の暗号化 - メッセージの認証を保証し、盗聴を防止することで、機密性を保持する
2. Authenticate the calling service — Verify the identity of the software sending requests	2. 呼び出し元サービスの認証 - リクエストを送信するソフトウェアのIDを検証する
3. Authorize the service — Using that authenticated identity, check that the action or communication being performed by the service is allowed	3. サービスを認可する - 認証されたIDを使用して、サービスによって実行され るアクションまたはコミュニケーションが許可されていることを確認する
4. Authenticate the end user — Verify the identity of the entity triggering the software to send the request, often a non-person entity (NPE) (e.g., service account, system account)	4. エンドユーザーを認可する - リクエストを送信するソフトウェアのトリガーとなる事業体（多くの場 合、非人間事業体(NPE)（サービスアカウント、システムアカウントなど）のIDを検証する
5. Authorize the end user to resource access — Using the authenticated end-user identity, check that they are allowed to perform the requested action on the target resource	5. エンドユーザーをリソースアクセスに認可する - 認証されたエンドユーザーアイデンティティを使用して、ターゲッ トリソース上で要求されたアクションを実行することが許可されていることを確認する
Achieving a zero-trust runtime requires applying these five controls to all API communications. This guidance further describes additional controls that are necessary for safe and secure API operations beyond identity-based segmentation. These controls should be enforced on all APIs in a system, including those exposed to the outside world (i.e., public APIs) and those intended only for other applications in a given infrastructure (i.e., internal APIs).	ゼロトラストランタイムを達成するには、これら5つの制御をすべてのAPIコミュニケーションに適用する必要がある。本ガイダンスではさらに、ID ベースのセグメンテーションを超えた、安全でセキュアな API 操作に必要な追加のコントロールについて説明する。これらの管理は、外部に公開されるAPI（すなわち公開API）や、特定のインフラストラクチャー内の他のアプリケーショ ンだけを対象とするAPI（すなわち内部API）を含め、システム内のすべてのAPIに対して実施されるべきである。
1.3. API Life Cycle	1.3. APIのライフサイクル
Like all software, APIs grow and change over time as requirements drift and usage patterns change. They also go through a continuous, iterative life cycle, including:	すべてのソフトウェアと同様に、APIは、要求が変化し、使用パターンが変わるにつれて、時間とともに成長し、変化する。APIもまた、以下のような、継続的で反復的なライフサイクルを経る：
• Plan, Develop, Build, Test, Release — These “pre-runtime” life cycle phases lead to a service that can be deployed in production.	- 計画、開発、ビルド、テスト、リリース - これらの 「プレランタイム 」ライフサイクルのフェーズは、本番環境に展開できるサービスにつながる。
• Deploy, Operate, Monitor, Feedback — These “runtime” life cycle phases involve running and operating a service in production.	- デプロイ、運用、監視、フィードバック - これらの「ランタイム」ライフサイクルフェーズでは、本番環境でのサービスの実行と運用を行う。
DoD Enterprise DevSecOps Fundamentals [1] provides a detailed description of each phase of the software development life cycle. Application of the DevSecOps paradigm in the context of cloud-native applications can be found in [4][5].	DoD Enterprise DevSecOps Fundamentals [1]は、ソフトウェア開発ライフサイクルの各フェーズの詳細な説明を提供する。クラウドネイティブアプリケーションのコンテキストにおける DevSecOps パラダイムの適用については、[4][5]を参照されたい。
Fig. 3. DevSecOps life cycle phases	図3. DevSecOps ライフサイクルのフェーズ
1.4. Document Goals	1.4. 文書の目標
The goal of this document is to recommend guidance or controls for API protection. These controls are classified into two categories:	この文書の目標は、API 保護のためのガイダンスやコントロールを推奨することである。これらのコントロールは2つのカテゴリーに分類される：
1. Pre-runtime API protections — These controls need to be applied when designing and building APIs.	1. ランタイム前のAPI防御 - これらの防御は、APIを設計・構築する際に適用する必要がある。
2. Runtime API protections — These controls need to be applied to every API request that an infrastructure serves, not just at the perimeter.	2. ランタイムAPI防御 - これらの防御は、インフラが提供する全てのAPIリクエストに適用される必要がある。
Each of these two categories is further divided into two subcategories based on organizational maturity (i.e., basic and advanced), which enables enterprises to adopt them based on an incremental risk-based approach.	これら2つのカテゴリーはそれぞれ、組織の成熟度（ベーシックとアドバンス）に基づいてさらに2つのサブカテゴリーに分けられ、エンタープライズがリスクベースのアプローチに基づいて段階的に導入できるようになっている。
A prerequisite for defining any API protection measure or policy irrespective of its category or sub-category is that the protections must be expressed in terms of nouns and verbs that pertain to API components, API endpoint components, API requests, and API responses that in turn contain references to resources/data and operations on those resources. These nouns and verbs form the fundamental surface that is exposed to the consumers of APIs and API endpoints.	カテゴリーやサブカテゴリーに関係なく、API 保護対策やポリシーを定義するための前提条件は、保護が API コンポーネント、API エンドポイントコンポーネント、API リクエスト、API レスポンスに関連する名詞と動詞で表現されなければならないことである。これらの名詞と動詞は、APIとAPIエンドポイントの消費者に公開される基本的な表面を形成する。
1.5. Relationship to Other NIST Documents	1.5. 他のNIST文書との関係
Today, most enterprise software development and integration are based on APIs. Section 1.3 articulated the close relationship between software and APIs, demonstrated that API development and deployment follow the same iterative life cycle as the software, and provided NIST guidance on DevSecOps.	今日、ほとんどのエンタープライズソフトウェアの開発と統合はAPIに基づいている。セクション1.3は、ソフトウェアとAPIの密接な関係を明確にし、APIの開発と展開がソフトウェアと同じ反復的なライフサイクルに従うことを示し、DevSecOpsに関するNISTのガイダンスを提供した。
Another distinguishing feature of the controls recommended for protecting APIs is the capacity to provide assurance for conforming to the principles of zero trust. This is because there is no distinction between internal and external API requests/calls due to the absence of an identifiable network perimeter and the distributed nature of applications on-premises and multiple clouds. This security assurance can be achieved using authentication and authorization controls using identity-based segmentation [2]. Documents that provide recommendations on the configuration of authentication and authorization controls in the context of cloud-native applications (e.g., [2][3]) are also relevant in the context of configuring controls for API protection.	APIを保護するために推奨される防御のもう一つの特徴は、ゼロトラストの原則に適合する保証を提供する能力である。これは、識別可能なネットワーク境界が存在せず、オンプレミスや複数のクラウドに分散したアプリケーションの性質のため、内部と外部のAPIリクエスト／コールの区別がないためである。このセキュリティ保証は、ID ベースのセグメンテーションを使用した認証と認可のコントロールを使用して達成することができる [2]。クラウドネイティブアプリケーションの文脈における認証と認可の制御の構成に関する推奨を提供する文書（例えば、 [2][3]）は、API 保護のための制御の構成の文脈にも関連する。
1.6. Document Structure	1.6. 文書構成
This document is organized as follows:	本文書の構成は以下の通りである：
• Section 2 looks at the risk factors and vulnerabilities associated with APIs and the attack vectors that could exploit those vulnerabilities.	・セクション 2 は、API に関連するリスク要因と脆弱性、及び、それらの脆弱性を悪用する攻撃ベクターについて見ている。
• Section 3 recommends controls to protect APIs and classifies them into basic and advanced categories that need to be applied prior to runtime or enforced during runtime.	・セクション 3 は、API を保護するための防御策を推奨し、実行前に適用する必要がある、あるいは実行中に強制 する必要がある、基本的なカテゴリーと高度なカテゴリーに分類する。
• Section 4 provides a detailed analysis of implementation options or patterns for the controls described in Sec. 3 and outlines the advantages and disadvantages of each pattern.	・セクション4は、セクション3で説明したコントロールの実装オプションやパターンを詳細に分析し,各パターンの長所と短所を概説する。
• Section 5 provides the summary and conclusions.	・セクション5は、要約と結論を提供する。
• Appendix A provides the classification taxonomy for APIs.	・附属書Aは、APIの分類分類法を提供する。
• Appendix B illustrates the API controls related to each DevSecOps phase	・附属書Bは、DevSecOps の各フェーズに関連する API の管理方法を示している。