こんにちは。レッドハットコンサルティングチームの木嶋です。
AI やデータ連携が進み、システム同士が API を介して連携することが当たり前になった今、API は「個別の技術要素」ではなく、「アプリケーションアーキテクチャに組み込まれるべき前提条件」になりつつあります。
一方で API の実装のご相談というと、API セキュリティのご相談が大きな割合を占めることも少なくありません。 何をどこまで実装したらいいのかは引き続き手探りの状態が続いているように思われます。
こうした背景の中、NIST は Guidelines for API Protection for Cloud-Native Systems (SP 800-228) の正式版を2025/6に公開しました。 Draft 版の段階でも実践的で優れた内容でしたが、Published 版ではさらに整理され、より幅広い層が活用しやすいドキュメントへと成熟した印象を受けました。
このドキュメントはぜひともAPIセキュリティの教科書として直接読んでいただきたい。 なぜなら、プロジェクトの現場で受けるよくある質問がほとんどカバーされているからです。
タイトルには「Cloud-Native」と書かれていますが、内容的にはオンプレであってもモノリスであってもそのまま適用できるものとなっています。
Cloud-Native では内部構造も API 化されるため、API セキュリティの重要度がより高まる、という意味でのタイトルだと理解すると読みやすいと思います。
ですが英語ですし、やはりなかなか敷居の高さを感じる方も多いはずです。 ここではこのガイドラインをどう読み解けば良いか、「読み方」をご紹介します。
想定読者
メインターゲットは、Cloud-Native かどうかに関わらず、APIを扱っているバックエンド開発者やアーキテクトです。
また次のような方々も読んでいただくと、自分たちの関心事と API セキュリティ/ガバナンスの世界がうまく接続されるようになっています。
- インフラ／ネットワーク担当者: ゼロトラスト前提でネットワークやセグメンテーションをどう設計すべきか、API Gateway・Service Mesh・WAAP それぞれの役割分担を整理する材料になります。
- プラットフォームエンジニアリングチーム: OpenShift などのコンテナ基盤の上に、どのような API セキュリティ機能を「プラットフォームとして」載せていくべきかを検討する際のベースラインになります。
- 情報セキュリティ／CSIRT 担当者: API に起因するインシデントのパターンやビジネス影響の整理、既存ポリシーの棚卸し・強化の観点で参照できます。
- プロダクトオーナー／プロジェクトマネージャー: 「どこまでやれば最低限で、どこから先が高度な取り組みか」を理解し、投資や優先順位付けを検討するための材料になります。
ガイドラインの位置付け
NIST というと難しい標準文書を想像される方も多いかもしれませんが、本ドキュメントは
API セキュリティの “教科書”
として読める内容です。 特に優れているのは、
- なぜその設計が必要なのか
- それを怠るとどんな事故につながるのか
まで丁寧に言語化されていること。
プロジェクトの現場で API セキュリティを説明していると、
「そこまで必要でしょうか？」
という質問は避けられません。
そのとき、このドキュメントは “現場の暗黙知に対して、NIST が体系的にお墨付きを与えた” と言える非常に心強い存在になるでしょう。
構成と読み方のヒント
- 第1章：APIセキュリティの前提と世界観
- 第2章：脆弱性とビジネス影響
- OWASP API Security Top 10 と強く連動
- 第3章：推奨コントロール（実装ガイド）
- Pre-Runtime（設計〜デプロイ）
- Runtime（運用）
- 各項目が Basic / Advanced に整理
- 第4章：アーキテクチャパターン
- API Gateway / WAAP / Service Mesh 等
私のような原理原則が大好きな人は1章から読むのが良いですが、プロジェクトの現場ですぐに使える知見が欲しい方には3章を軸に、時々1章や2章に遡って読むのがお勧めです。 つまりコントロール（対策）<--> 失敗パターン（事故の原因）を行き来しながら読む、というスタイルです。
英語ですし、わからないキーワードもあるかと思います。 お手持ちの生成AIにぜひ
(3章の) REC-API-Xがなぜ必要か理解したいので、2章やOWASP API Security Top 10の解説などを参考に、もしこの対策を実施しなかった場合にどんな事故が起きるか (ホラーストーリー) を教えて
と聞いてみてください。単なる仕様書の項目解説ではなく、設計判断の根拠がわかるように解説してくれるはずです。
実践にあたっての検討事項
ガイドラインそのものは私よりも生成AIの方がよっぽど上手く解説してくれます。 ですのでここでは、ドキュメントを把握した上で実践する際の検討事項をまとめておきたいと思います。
(APIだけでも) ゼロトラストの採用
このドキュメントは、いわゆる「境界防御モデル」を前提にしたものではなく、ネットワークの内側であっても、API間の通信はゼロトラスト前提で設計すべきという立場をとっています。
昨今のランサムウェア被害を見てもわかるように、一度境界が破られてしまうと、内部の横方向の移動 (ラテラルムーブメント) が容易になってしまいます。 特にAPIは機能の入り口です。APIを使って機能を実装しようということは、なんらかの処理の間にネットワークが必ず入るポイントを作るということでもあります。攻撃者から見ると、ここは非常に魅力的な侵入経路になります。
したがって、「境界の内側は無条件で信用する」のではなく、
- すべてのリクエストごとに
- 「誰から」「どのサービスから」「何をしようとしているか」
を毎回検証するという考え方が基本になっています。
コンテナ管理基盤の活用
前項で整理した通り、API セキュリティにおいてゼロトラストを実現するためのキモは大きく以下の 3 点です。
- 不要な通信経路を作らない（＝侵入経路を極力減らす）
- 通してよい通信であっても、すべて検査する
- この 2 つを、すべての API に漏れなく適用する
理屈としてはシンプルですが、これを現実のシステム全体に適用しようとすると、
- 通信経路の設計
- 認証・認可の実装
- ログ・監査・可視化
- 設定の一貫性とメンテナンス
といった観点で、かなりの運用コストがかかります。
NIST SP 800-228 の第4章では、API Gatewayの実装パターンとしてCentralized / Hybrid / Distributed の3 つのモデルが紹介されています。 特にゼロトラスト原則に最も適合する Distributed パターン（サービスメッシュ等）を実装する場合、コンテナ基盤は非常にフィットしやすい選択肢のひとつです。
この前提があると、mTLS や SPIFFE ベースのサービスアイデンティティ、粒度の細かい流量制御やアクセスコントロールといった仕組みも、「都度アプリごとに実装する特別な仕掛け」ではなく、
- プラットフォーム側で共通機能として用意し、
- 開発者が必要な項目を設定するだけで利用できる機能
として提供できるようになります。
ここまで読んで「導入や学習、移行のコストが高くつきそうだ」とお感じになった場合、おそらくそれは正しいはずです。 ただし、API の本数や関わるチームの数が増えれば増えるほど、1 本の API を安全に保つための平均コストは、むしろこうしたプラットフォーム機能をうまく活用するアプローチの方が下がっていきます。 各チームが個別にライブラリを組み込んで、都度レビューとテストを行う世界と比べると、
- セキュリティポリシーの設計・更新は中央（プラットフォームチーム）に集約し、
- 開発チームは最小限の情報を提供するだけで済むようにし、
- 配布と適用はコンテナ基盤とサービスメッシュが自動で行う
という役割分担にすることで、「人手で追いかけ続けるコスト」や「レビュー待ちのボトルネック」を大きく減らし、ガバナンスを確実に実行するためのランニングコストを抑えることができます。
アプリケーションプラットフォームの整備
もちろん、「設定するだけで安全な API が手に入る世界」を実現するためには、その裏側でかなりの設計と運用の工夫が必要です。
ここで重要になるのが、近年注目されている Platform Engineering の考え方です。 NIST SP 800-228 でも、API セキュリティを組織横断で支えるための「API プラットフォームチーム」や「セルフサービス型の基盤」が明確に言及されています。
日本でもすでに多くの組織で、インフラ/プラットフォームチームが インフラ基盤を整備し、開発チームがセルフサービスで使える形にする Platform Engineering 活動が進んでいます。
NIST SP 800-228 が求めているのは、そこから一歩踏み込んで、
- ネットワークやコンピュートといった基盤だけでなく
- API セキュリティに必要な機能一式（認証・認可、流量制御、監査・可視化など）を
まとめてプラットフォーム側で提供する、いわば 「アプリケーションプラットフォーム」として成熟した姿だと捉えることができます。
なお、このガイドラインを読んで、 「ではセキュリティレビューを強化するために、API プラットフォームチームで全件レビューをしよう！」 という方向に振り切るのは、あまりおすすめしません。
API の歴史の中で、「人手を増やしてレビューを頑張る」アプローチは、すでに多くの組織が試してきました。 しかし API の数と変更頻度の増大、そしてセキュリティ人材の確保難易度の高さから、いずれもどこかで限界を迎え、方向転換を余儀なくされています。
だからこそ本ガイドラインでも、人手による個別対応ではなく、「セルフサービス型の基盤」としてセキュリティを組み込む方向性も同時に打ち出されているのだと考えられます。
アイデンティティ管理基盤の整備
そこで忘れてはならないのが、アイデンティティ管理基盤そのものもアプリケーションプラットフォームの一部として整備されていることです。 認証・認可に必要な情報（ユーザー/サービスの属性やロール、グループ、組織情報など）が、この基盤に適切に集約されていることが前提になります。
NIST SP 800-228 では、API 側から見ると
- 「どのユーザーか」
- 「どのサービスか」
- 「どのような属性を持っているか」
といった情報が、あたかも当然のように利用できる前提で議論が進みます。
しかし現実のプロジェクトでは、この前提が満たされていないケースも少なくありません。 人事システム、ディレクトリサービス（Entra ID / AD）、各業務システムがそれぞれバラバラに属性を持っており、 どこを「認可判断のための信頼できる情報源（Source of Truth）」とするかが曖昧なままになっていることも多いのではないでしょうか。
API セキュリティの観点から見ると、
- どの属性をどこで管理し
- どの範囲までをアイデンティティ基盤でカバーし
- どこから先を各アプリケーションに委ねるか
という設計が非常に重要です。
その意味で、アイデンティティ管理基盤は単なる「認証のための仕組み」ではなく、 アプリケーションプラットフォームの中核コンポーネントとして設計・運用していく必要があります。
適切な流量制御の実装
いわゆる情報セキュリティの「CIA」のうち、A = Availability (可用性) も忘れてはいけません。 NIST SP 800-228 では、レートリミットやタイムアウト、サーキットブレーカーといった仕組みが、 性能チューニングではなく セキュリティコントロール として扱われています。
よく流量制御のご相談で、
「API Gateway とサービスメッシュ、どちらで制御すべきでしょうか？」
というご質問を頂戴しますが、NIST SP 800-228 はこの問いにも明確に答えています。
両方です。
日本語ではどちらも「流量制御」という表現になってしまいますが、もともと API Gateway が持つ Quota のコントロール と、 サービスメッシュが持つ Rate Limit のコントロール は、「守る場所」と「目的」が異なります。
昨今のシステムでは、Gateway とバックエンドの間に Camel 等による API 連携処理や、複数の処理を集約する「アグリゲーション層」 が介在することが一般的です。クライアントからの 1 つのリクエストが、アグリゲーションを経由することで複数のマイクロサービスへのリクエストに「増幅 (ファンアウト)」されたり、複雑に変換されたりします。
つまり、入り口 (Gateway) でどれだけ綺麗に整流しても、その先でアプリケーション (アグリゲーション等) がリクエストを増幅した結果、バックエンドの各サービスが過負荷に陥る、という状況は現実的に起こり得ます。
予期せぬリクエストの増幅から個々のサービスを守る「最後の防波堤」として、サービス直近 (サービスメッシュ) での制御が不可欠になるわけです。
また、API Gatewayによく実装されているQuota はどちらかというと ビジネス観点の流量制御 であり、
- 課金プラン
- フェアユースポリシー
- 顧客やパートナーごとの利用上限
といった契約条件を表現するための機能です。
対象期間も 1 日や 1 か月など、比較的長い期間を扱うのが特徴です。
一方で、API セキュリティの観点から重要なのは、Rate Limiting やバックプレッシャー、リトライ制御 の方です。これは、
- 誤実装やバグによる内部からの DoS
- 善意の業務ユーザーによる「連打」や大量実行
- 外部からの自動攻撃・クレデンシャルスタッフィング
などから、システム全体を守るための 防波堤 として機能します。
コンテナ基盤と Service Mesh、API Gateway を組み合わせることで、
- 「どのクライアント（ユーザー／サービス）から」
- 「どの API に対して」
- 「どのくらいの頻度まで許容するか」
といったルールを、一貫したポリシーとしてプラットフォーム側に実装できます。
ここでもポイントは、アプリごとに個別実装するのではなく、
プラットフォームが共通の流量制御の “ガードレール” を提供することです。
その上で、各アプリケーションチームが自分たちの特性に応じた閾値を設定していく、という分担が現実的だと考えています。
まとめ
ここで触れたのは、NIST SP 800-228 に含まれる内容のごく一部です。
- 境界防御ではなくゼロトラスト前提で API を設計すること
- コンテナ基盤と Service Mesh を活用して「設定すれば守れる」土台をつくること
- アプリケーションプラットフォームとして API セキュリティをまとめて提供すること
- それを支えるアイデンティティ管理基盤
- そして、可用性を守るための流量制御をセキュリティ要件として扱うこと
といった観点は、その中でも特に「アーキテクチャやプラットフォーム設計に効いてくる部分」です。
このほかにも、DevSecOps の確立と、それを可能にする Contract-Driven な開発（OpenAPI などの仕様を「プラットフォームへの入場チケット」とする考え方）など、内容は盛りだくさんです。 ぜひ一度、ご自身のプロジェクトの構成図や現状の課題を思い浮かべながら読んでみてください。
大事なのは、単一の API サーバーを守ることではなく、組織横断で「すべての API」をどう守るか を考えることです。 セキュリティは、どれだけ一部を厚く守っても、「一番弱いポイント」から破綻するからです。
そのための一歩は自分たちのシステムから。 現在の自分たちのシステムでどう守れるかを考える一助になりましたら幸いです。
おまけ: 「この記事本当？」を検証するためのプロンプト
Red Hat のブログなので、
これ、Red Hat に都合よく加工されてない？
と思われる方もいるかもしれません。 そのあたりは、ぜひみなさんの手元の GenAI と NIST SP 800-228 本文で好きなだけ検証していただきたいので、そのためのプロンプト例を置いておきます。
もしこの記事を読んで、
本当に NIST SP 800-228 はこんなことまで書いてあるの？
と思われた方は、お好みのモデルにガイドラインドキュメントを添付した上で、次のように投げてみてください。
あなたは NIST SP 800-228 「Guidelines for API Protection for Cloud-Native Systems」を読み込んだ API セキュリティの専門家です。 次の主張が、NIST SP 800-228 の内容とどの程度一致しているかを評価し、 根拠となる章番号・REC-API 番号とともに解説してください。 1. API セキュリティは、境界防御ではなくゼロトラスト前提で設計すべきである。 2. コンテナ基盤やサービスメッシュは、ゼロトラストな API セキュリティを 「プラットフォームとして」実現するための代表的な手段として示されている。 3. API セキュリティを組織横断で支えるために、API プラットフォームチームや セルフサービス型のアプリケーションプラットフォームのモデルが推奨されている。 4. アイデンティティ管理基盤は、認証・認可に必要な属性情報を集約し、 SSoT（Single Source of Truth）として扱える形にすることが望ましい。 5. レートリミットやタイムアウト、サーキットブレーカーなどの流量制御は、 可用性を守るためのセキュリティコントロールとして位置付けられている。 それぞれについて、 - 「おおむね正しい」「一部誤解を含む」「不正確」などの評価 - NIST SP 800-228 のどの記述が根拠になるか - 実務で適用する際の補足ポイント を日本語で教えてください。
このプロンプトをベースに、ご自身のプロジェクトで気になっている論点（例: 「Service Mesh にどこまで責務を持たせるべきか」など）を追加していくと、
「自分たちの前提や設計は、このガイドラインの観点から見てどうか？」
を中立な視点で確認する良いきっかけになると思います。
