ここでクイズです。これらのエンドポイントのうち、APIに属するものとアプリに属するものはどれでしょうか？
https://www.example.com/product
https://www.example.com/product
混乱して判断できなくても、問題ありません。まさにそこがポイントです。アプリとAPIのエンドポイントは、ほとんど同じように見えます。技術的には、RESTfulであれば（そのほとんどが該当します）、どちらもHTTPS経由で、通常はGETメソッドを使用して同じ方法で呼び出されるためです。多くの場合、異なるのはリクエストとともに送信されるペイロードです。APIの場合、通常はJSONまたはXML形式のデータが含まれますが、Webアプリのリクエストには何も含まれないこともあります。
それでも、F5の年次調査の主要な調査結果の1つから、組織はセキュリティに関してAPIをアプリケーションとは異なるものとして扱っていることが示唆されます。この推論は、組織の41%がアプリケーションと同数またはそれ以上のAPIを保有しているにもかかわらず、それらを保護する同じセキュリティサービスをそれほど重視していないという調査結果に基づいています。
組織がアプリケーションよりも多くのAPIを持つことになるのはなぜか、と疑問に思われるかもしれません。よくぞ聞いてくださいました。内部のサービス間通信（マイクロサービスなど）に使用されるAPIは、それが支えるサービスと密接に結び付いています。一方、外部向けインターフェースを提供するためにAPIを使用する場合は、必ずしもそうとは限りません。
APIはどこから生まれるのか？
F5が2021年に実施した調査では、モダナイゼーションの手法として「最新のユーザーインターフェースを実現するためにAPIレイヤーを追加している」と回答した割合は61%でした。2022年には、この割合が45%となりました。つまり、最新のユーザーインターフェースを実現するAPIは、必ずしもアプリケーションに直接付随するものではありません。モバイルアプリやデジタルサービスなど、最新のユーザーインターフェースやアプリケーションを実現するファサードの場合もあれば、パートナーやサプライチェーンとの通信を可能にするために設計されたファサードの場合もあります。こうしたユースケースは、API Gatewayやロードバランサーのレイヤー7ルーティングによってサポートされます。これらは多くの場合、APIエンドポイントからアプリケーションエンドポイントへの変換を可能にする一定の変換機能を備えています。これにより、実物以上に立派に見せる米国西部開拓時代の建物の正面装飾のようなAPIファサードを実現できます。
もちろん、かなりの数のAPIはアプリに接続された外部公開エンティティであり、Web（通常はHTTPS）経由でアクセスされます。
どのような経緯で公開されたかにかかわらず、外部公開APIはアプリケーションと同様の攻撃の多くにさらされます。特にボットが関与する場合、十分に文書化されたAPIは、攻撃者が大規模な攻撃をスクリプト化しやすくするため、この傾向が顕著です。
たとえば、F5 Distributed Cloud Bot Defenseが2023年に保護したトランザクションのうち、13%強が自動化されたものでした。つまり、Webブラウザやモバイルアプリを人が操作する代わりに、スクリプトやソフトウェアが使用されていました。こうしたトランザクションは、APIとアプリの両方を介して発生します。これらの自動化されたトランザクションの一部は、間違いなく「悪性ボット」によるものであり、F5のセキュリティサービスによって、その不正な試みは阻止されました。（どのような不正行為を試みていたのかについては、こちらのF5 Labsレポートで詳しくご覧いただけます）
そこで、回答者が自己申告したAPI数に基づいて、ボット管理をどのように捉えているかを調べたところ、ボット管理の重要度がかなり低いことが分かり、やや驚きました。
これらの見やすい棒グラフから、API Gatewaysの重要度は管理対象のAPI数に見合っているように見える一方、ボット管理についてはそうではないことがわかります。実際、まったく逆です。API数が増えるにつれて、ボット管理の重要度は急速に低下しているように見えます。
それらのAPIの大半が内部向けである可能性は十分にあります。つまり、マイクロサービス間でやり取りされるEast-West APIであり、悪意のあるボットである可能性のある外部アクターには公開されていないということです。
しかし、実際には外部に公開されている可能性もあります。この1年間に、攻撃者がAPI経由でアクセスした事例についての記事を数多く読んだことを踏まえると、外部APIは私たちが考えているよりもはるかに多いのではないでしょうか。
そこで、改めて認識しておく必要があります。世の中には、グリンチボットやスニーカーボットなど、需要の高い商品を買い占めてビジネスを妨害する厄介なボットが数多く存在します。その一方で、脆弱性を探し出して攻撃することだけを目的としたボットも相当数存在します。しかも、APIとアプリケーションの両方が標的です。
したがって、組織はAPI、ひいては事業を保護するために、幅広いセキュリティ対策を講じることが望まれます。ボット管理はそのようなセキュリティ対策の1つであり、あらゆるセキュリティ戦略に不可欠な要素として検討すべきです。
結局のところ、ボットにとって、そのエンドポイントがアプリとAPIのどちらに属するかは関係ありません。どちらも攻撃対象になります。
つまり、組織はボットを検知し、その不正な行為を阻止することで、アプリとAPIの両方を保護する必要があります。
ボット対策の実際の動作については、こちらのデモをご覧ください。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
SOAS 2025：足並みの乱れが凡庸さを招く
AI導入における方針の不一致は、非効率を招きます。セキュリティ、自動化、導入の各戦略を整合させ、AIの可能性を最大限に引き出す方法をご紹介します。
WebAssemblyが重要な理由
WebAssembly（Wasm）は、あらゆるプラットフォームで高性能なアプリケーションを実現する、ポータブルで高速かつセキュアなバイナリ命令セットです。
インフラストラクチャは依然として格好の攻撃経路
クラウドコンピューティングでは、APIやドラッグ＆ドロップ式の設定ツールを活用し、ネットワークやインフラストラクチャを敬遠する人がそれらを直接扱わずに済むようにすることで、インフラストラクチャへの対応を不要にすることが長年追求されてきました。しかし、インフラストラクチャを無視することも、攻撃の主要な標的であるという事実を見過ごすこともできません。
堅牢なデータアーキテクチャがもたらす戦略的メリット
適切に構築されたデータアーキテクチャがもたらす効果は、業務プロセスの改善にとどまりません。戦略的な業務効率の向上、より深いビジネスインサイトの獲得、隣接するビジネス機会への展開にもつながり、これらすべてをより俊敏に実行できるようになります。
デジタルワークフローにおける不正検知には、データだけでは不十分
2019年には、業界全体でクレジットカード詐欺の試みが約25万件確認されました。これは約2分に1件の割合です。今日、不正を検知するには、デジタルワークフロー上のできるだけ多くのポイントから収集したデータを相互に関連付け、手作業によるデータ処理をはるかに上回る速度で分析する能力が求められます。