今回のブログでは、APIのセキュリティについて考えるためにクラウドネイティブシステムのAPI保護に関するガイドラインであるNIST SP800-228 Guidelines for API Protection for Cloud-Native Systemsを紹介します。

はじめに

現在の多様なIT環境において、API（Application Programming Interface）はサービス間の連携や結合を実現するにあたり、必要不可欠なものとなっています。また、APIは各種生成AIサービスのようにAPI自体がサービスとして公開・利用されていたり、アプリケーション内部の連携において利用されていたりと様々な用途で利用されています。
APIを利用することで、開発の高速化やアプリケーションの拡張性、柔軟性の向上などといった様々な利益を得ることができます。一方で、APIの適切な開発や管理、利用に失敗してしまった場合には、情報漏洩やサービス停止などといった大きな被害につながる可能性があります。そのため、APIの利点を最大限に生かした上でAPIを安全に開発や管理、利用するには、APIのリスクについて理解した上で適切なセキュリティ上の対策を実施することが重要となります。

NIST SP800-228 Guidelines for API Protection for Cloud-Native Systems

本章では、APIのセキュリティについて考えるために「NIST SP800-228 Guidelines for API Protection for Cloud-Native Systems」[1]を紹介します。

ガイドラインの概要

本ガイドラインは、2025年6月に米国のNIST（National Institute of Standards and Technology）から発行されたAPIの保護に関するガイドラインです。本ガイドライン内では、クラウドネイティブシステムのAPIのライフサイクル全体に関するリスクや管理策、また保護のための実装パターンについて体系的にまとめられています。
また、本ガイドラインは以下に示す全5章で構成されています。

• 1章：ガイドラインの目的や概要等のガイドラインについて
• 2章：APIに関連するリスクについて
• 3章：APIを保護するための管理策について
• 4章：3章の管理策の実装方法について
• 5章：結論と要約

一般的なWebアプリケーションとの比較を交えたガイドライン中のリスクについて

本ブログでは、NIST SP800-228内の2章に記されているAPIに関連するリスクに焦点を当てて、APIのセキュリティについて見ていこうと思います。NIST SP800-228内では、APIに関するリスクとして以下が挙げられています。

表1 NIST SP800-228ガイドライン中で挙げられているリスク一覧

API固有のリスクや特別な注意が必要なリスクもありますが、基本的にはAPIのリスクは一般的なWebアプリケーションのリスクに類似するものが多いため、同様のセキュリティ対策をすることになります。ここでは、一般的なWebアプリケーションと比較しつつ、NIST SP800-228中で挙げられているリスクについて見ていこうと思います。

2.1 API資産の可視性欠如

リスクの説明

本リスクの概要を図1に示します。

本リスクは、組織内で提供、利用しているAPIを完全に把握して管理できていない場合において、管理されていないAPIが攻撃対象になって悪用されてしまうリスクです。本リスクはWebアプリケーションというよりは、一般的なシャドーITのリスクと類似したものになります。
NIST SP800-228内では本リスクの一般的な原因として、以下を挙げています。

• 組織内の多数のチームによりAPIが構築されることにより、正確な管理の維持が困難になるため
• テストやデバッグなどの内部利用目的で構築されたAPIは適切に文書化されないことがあるため（シャドーAPI）
• 置き換えや更新されたAPIが完全に削除されず残っていることがあるため（ゾンビAPI）

対策

対策としては、適切なガバナンスを効かせることが有効になります。新たに構築されたAPIが適切に文書化され管理されることやAPIのバージョン管理や廃止のポリシーを定めること、ツールによる自動スキャンによりすべてのAPIの利用状況を確認すること等により、不要なAPIが残らないようにすることを徹底することが重要です。

2.2 認可の不備

リスクの説明

本リスクの概要を図2に示します。

本リスクは、ユーザやサービスのアクセス権の検証がそもそも実装されていない場合に加えて、認可の処理が不適切または範囲が不十分である場合に不要な情報や本来開示すべきでない情報をAPIの呼び出し元へ返してしまうリスクです。本リスクは一般的なWebアプリケーションでも同様に起こりうるリスクです。しかし、APIはエンドポイントが直接公開されるため、Webアプリケーションよりもリスクを悪用される可能性が高く、より注意が必要であると考えます。

対策

対策としては、まずは認可を実装した上で、APIを実行する権限があるのかどうか、またAPIがアクセスするデータに対する権限があるのかをAPI呼び出しごとに確認することが有効です。加えて、認可機能が適切に機能しているのかを定期的に確認し、問題があれば是正することも重要です。

2.3 認証の不備

リスクの説明

本リスクの概要を図3に示します。

本リスクは、API呼び出し時の認証がブルートフォースやクレデンシャルスタッフィングに対する耐性がないこと、また弱いパスワードやトークンを利用することにより不正アクセスや情報漏洩につながるリスクです。認証については当然Webアプリケーションでも同様のリスクがあり、OWASP Top 10[2]内でも「A07:2021 – 識別と認証の失敗」としてリスクの1つとして挙げられています。ただし、APIはその特徴としてサービスにより自動で呼び出されることが多く多要素認証（MFA）を用いづらい点や認証にはトークンを利用することが多いといった点があるため、適用する対策が少し異なる場合があります。

対策

対策としては、認証失敗時のアカウントロックや呼び出し元とAPI側の双方の認証などの一般的な認証に対する対策が挙げられます。APIキーやJWT（JSON Web Token）といったトークンを用いて認証する場合は、強度の高い署名アルゴリズムの利用やトークン漏洩時の影響を低減するために適切な有効期限設定などの対策が重要です。

2.4 無制限のリソース消費

リスクの説明

本リスクの概要を図4に示します。

本リスクは、大量のリクエストを許可してしまった結果、計算資源や物理資源を無制限に消費してしまい性能や従量課金のコスト等への影響に加えて、呼び出されたAPIが他のサービスを利用していた場合にそのサービスに対しても同様の影響を与える可能性のあるリスクです。APIは自動化された呼び出しをされることが多く、Webアプリケーションに比べて多くのリクエストを受け取ることが多いため、より注意が必要なリスクです。また、NIST SP800-228内では本リスクについて、外部攻撃者が悪意をもって攻撃を引き起こすよりも、開発者が誤って内部サービスにDoS（Denial of Service）を引き起こす方が容易であると述べられています。そのため、意図しないミスでのサービス停止やコスト増加に備えるためにも本リスクの対策は重要です。

対策

対策としては、API呼び出しに適切なレート制限をユーザごとやIPアドレス、トークン単位などに対して細かく設定することやタイムアウトの設定をすることが重要です。加えて、ボットやDDoS（Distributed Denial of Service）対策などでの保護、監視やログ蓄積による異常の発生に気づき即時対応できるような備えも有効です。

2.5 機密情報の漏洩

リスクの説明

本リスクの概要を図5に示します。

本リスクは、認可やエラーハンドリングの不備により、レスポンスコードやエラー情報といったサイドチャネルから本来非公開の情報が漏洩してしまうリスクです。一般的なWebアプリケーションでも存在するリスクですが、APIは一般的にUIを介さずに情報を返すことからより現れやすいリスクになります。

対策

対策としては、呼び出し元に不要な情報を返さないようなAPI設計が重要になります。例えば、リソースに対する権限エラーの場合であってもリソースの有無は開示しないことや、エラー情報についても呼び出し元には必要最低限だけを返し、詳細はログに記録するといったことが適切な対応になります。

2.6 入力データの検証不足

リスクの説明

本リスクの概要を図6に示します。

本リスクは、APIが受け取る外部からの入力が正しいことを検証せずに受け入れることにより、DoS攻撃によるサービス停止やクラッシュ、インジェクションによる情報漏洩が発生する可能性があるリスクです。Webアプリケーションでも同様のリスクがあり、OWASP Top 10内でも「A03:2021–インジェクション」としてリスクの1つとして挙げられています。

対策

対策としては、一般的なWebアプリケーションと同じく入力のバリデーションチェックやサニタイズを適切に行い、適合しないものや悪意のあるものは拒否することが重要です。また、一般的なインジェクションやXSS（Cross Site Scripting）などの対策としてはWAF（Web Application Firewall）を導入することも有効です。

2.7 認証情報の正規化不足

リスクの説明

本リスクの概要を図7に示します。

本リスクは、クライアントからのAPI呼び出しリクエストをバックエンドへ中継する機能を持つAPIゲートウェイにおいてユーザから受け取る認証情報が様々な形式であることから生じるリスクです。内部の相互通信では認証・認可を省略してAPIゲートウェイのみで認証・認可を行う形にしてしまうと、内部での通信で認証・認可の漏れや不備が生じて不正アクセスのような被害につながる可能性があります。一般的なアプリケーションでは多様なサービス間認証や多くの種類の認証情報の管理はAPIに比べると少ないと考えられるため、APIのリスクとして注意する必要があります。

対策

対策としては、利用する認証情報の正規化をNIST SP800-228では推奨しています。具体的には、APIゲートウェイを境界として内部で期待される統一された形式の認証情報に変換し、内部のサービスでは統一された形式の認証情報のみを取り扱うようにします。これにより、認証・認可における漏れや不備、例外に対処することが可能になります。

まとめ

今回はAPIのセキュリティについて考えるために、APIの保護に関するガイドラインであるNIST SP800-228 Guidelines for API Protection for Cloud-Native Systemsを紹介しました。また、本ガイドライン内で挙げられているリスクについて、一般的なWebアプリケーションのリスクと比較しながら見てきました。
本ブログ内で触れたAPIのリスクに関する対策について以外にも、NIST SP800-228中には様々な対策や推奨事項が記載されているので、ぜひ参考にしながら安全なAPIの開発や運用の実現につなげていただければと思います。

参考文献

[1] Chandramouli R, Butcher Z (2025) Guidelines for API Protection for Cloud-Native Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-228.
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-228.pdf

[2] OWASP Top 10 – 2021
https://owasp.org/Top10/ja/

執筆者プロフィール

浦川　侑之介（うらかわ　ゆうのすけ）
担当領域：セキュア技術開発
専門分野：セキュア開発、DevSecOps

NECグループ社内向けのセキュリティ関連サービスの開発に従事。
CISSP、CCSP、CISA、GIAC GCSA、情報処理安全確保支援士(RISS)を保持。