CISOが知っておくべきAPIセキュリティの3つの重要ポイント

F5 Global CISO の第 3 話: 擁護者による擁護者として、私のお気に入りの API ハッカーの 1 人であるCorey Ball氏に加わってもらいました。 Corey は過去 15 年間 IT とサイバー セキュリティの分野で活躍しており、このトピックに関する知識がほとんど集積されていないことに気付き、文字通り API ハッキングに関する本を執筆しました。これが私たちが初めて出会ったときです。

この本は「Hacking APIs:」です。 「Breaking Web Application Programming Interfaces」は、 Web API セキュリティ テストの短期集中講座を提供します。 Corey 氏は、API セキュリティについて学習するための無料リソースである APIsec Universityの創設者でもあり、API セキュリティと Web アプリの侵入テストを実行するhAPI Labsの創設者兼 CEO でもあります。

CoreyはAPIセキュリティの専門家なので、彼にぜひ聞きたい質問がありました。 すべてのCISOがAPIセキュリティについて押さえておくべき3つのポイントは何でしょうか？ 特に、攻撃者の視点からAPIセキュリティを分析することで、守る側が学べることが何か知りたかったのです。

API は、世界で最も価値のある資源の一つであるデータ転送を支える技術です。 「私たちはファイアウォールやWebアプリファイアウォールなどの防御層を設けてこのデータを守っていますが」とコリーは言います、「インターネットに公開されているAPIは、しばしば侵害への入り口となりえます。」 認証や承認がない無防備なAPIがあれば、犯罪者が直接そこを突いて不正なリクエストを送り込み、他の防御層で守られているデータを盗み出す危険があります。

「防御者には、API セキュリティのテストに適切なツールと手法を使う必要があると理解してほしい」と彼は言いました。 自動スキャナーをAPIに向けてただレポートが問題ないからといって、安全だと考えるだけでは不十分です。 防御者は、実際の問題を見つけ出し、存在するセキュリティの弱点に対応するために、APIリクエストを積極的にテストし、分析する必要があります。

テスターのテストをする。 Coreyによると、テストスキルやツールを確かめる効果的な方法の一つは、意図的に脆弱性を含むアプリケーションで実践することです。これは、安全に設計された対象で、テスターが一般的なAPIセキュリティの問題を体験し、再現し、理解できるようにしています。 「例えば、OWASP APIセキュリティプロジェクトが提供するcrAPIは、意図的にAPIの脆弱性を盛り込み、APIセキュリティの教育、学習、訓練を目的としたトレーニングツールです。 スキャナーをcrAPIに向けて、どのような結果が得られるか確かめてみてください。」 もし、HSTSヘッダーの欠落や不適切なクリックジャック保護のような表面的な脆弱性だけが検出された場合、テストツールはOWASP API Top 10に含まれる深刻なAPIの脆弱性を見逃している可能性があります。  「これは、使っているテストツールが思っているほど有効でないことの証明になります」とCoreyは述べています。

Coreyと私は、APIは従来のWebアプリとは異なる攻撃を受けやすいため、従来の企業向け脆弱性ツールや管理プログラムではAPIを守れないと話しました。 例えば、破損したオブジェクトレベル認可（BOLA）や破損したオブジェクトプロパティレベル認可（BOPLA）は、APIの核となるビジネスロジックに関わるAPIのセキュリティの弱点です。 Coreyに、WAFとAPIゲートウェイを導入している企業がAPIを保護する上で何が不足しているか尋ねました。

WAFやAPIゲートウェイはアプリのセキュリティとユーザー認証に不可欠だと彼は言いましたが、それだけではAPIを守り切れません。 APIを安全に保つ最大の課題は承認であり、ユーザーが自分自身のデータのみにアクセスし、閲覧し、変更し、削除できることを確実にすることです。 「ユーザーAはユーザーAのリソースだけを操作できなければなりません。 ユーザーBのリソースを変更・閲覧・更新・削除してはいけません」と彼は述べました。 「APIでの承認は確実に難しい課題です。 緻密な承認ルールがなければ、攻撃者が他者のリソースを要求する操作は正当なリクエストに見えてしまいます。」

認証制御は、複数の補完的な制御を組み合わせた多層的なAPIセキュリティの一部であり、ひとつの層が機能しなくても、他の層が引き続き保護を提供できるようにする必要があります。

組織が生成型AIやAIを活用したアプリに投資を増やすにつれて、これらの技術がAPI攻撃のリスクを拡大させることを認識する必要があります。 なぜなら、生成型AIアプリはすべてAPIを核として動いているからです。 つまり、AIの世界はAPIの世界であり、生成型AIアプリの基盤となる構造はAPIに大きく依存しており、AIシステムのほぼすべての部分がこれらのインターフェイスを通じてアクセス可能になっています。

しかし、Corey と私が話したように、API はAIアプリとアーキテクチャを守るうえでの課題の一部に過ぎません。 AIエンジンや大規模言語モデル（LLM）は、他にも多くの攻撃リスクを露呈しています。 たとえば、モデル コンテキスト プロトコル（MCP）は、LLMを外部ツールやサービスに接続するための統一フレームワークとしてオープンソースで提供されています。 MCPはAIをアプリに統合する上で多くの利点がありますが、一方で大きなセキュリティ上の課題ももたらします。 「生成AIの内部を見ると、すでに多数のAPIが使われていて、そこに認証や認可管理が弱いことが多いMCPが加わっています。しかしセキュリティ対策は確実に進化しています」とCoreyは話しています。

MCPのもう一つの重要なセキュリティ課題は、プロンプトインジェクション攻撃や自然言語を使ったハッキングです。 AIエージェントやチャットボットがあなたの会社を代表する場面では、これらがビジネスリスクをもたらす可能性があります。 攻撃者はAIエージェントに企業イメージにそぐわない不適切な発言をさせたり、チャットボットから不正な割引を引き出したりする恐れがあります。 また、チャットボットが会社の法的代理人と見なされ、その発言や行動に法的責任が問われる場合があることも理解しておく必要があります。 AIアプリがもたらすビジネスチャンスを逃さずに活用するために、正確なデータでトレーニングし、プロンプトインジェクションから確実に守るための適切な対策を講じることが重要です。

Coreyと話せるのはいつも楽しみであり、攻撃者の視点からセキュリティを見て防御側が何を学べるか一緒に考えられたことに感謝します。 防御側として、攻撃の仕組みに基づいた戦略が必要です。だからこそ、攻撃者の手口や狙いを理解し、限られたリソースを企業や省庁、機関に最適な多層防御に効果的に配分していきましょう。