アプリ vs. API セキュリティ? ボットは気にしません。 デジタル資産を守る
クイズの時間です。 これらのエンドポイントのうち、どれが API に属し、どれがアプリに属していますか?
https://www.example.com/product
https://www.example.com/product
混乱して決められない場合でも大丈夫です。 それがポイントです。 アプリと API エンドポイントはほぼ同じように見えます。 これは、技術的に言えば、RESTful である場合 (ほとんどがそうです)、HTTPS 経由で、通常は GET メソッドを使用して同じように呼び出されるためです。 多くの場合、異なるのはリクエストとともに送信されるペイロードです。 API には通常 JSON または XML 形式のデータが含まれますが、Web アプリのリクエストには何も含まれない場合があります。
それでも、当社の年次調査から得られた重要な知見の 1 つは、セキュリティに関しては組織が API をアプリケーションとは異なるものとして扱っていることを示唆しています。 これは、組織の 41% がアプリケーションと同数以上の API を保有しているにもかかわらず、それらを保護する同じセキュリティ サービスにあまり価値を置いていないという調査結果に基づいて推測されます。
組織がアプリよりも多くの API を所有することになるのはなぜかと疑問に思うかもしれません。 質問してくれてありがとう！ 内部のサービス間通信（マイクロサービスなど）に使用される API は、サポートするサービスと密接に結合されていますが、API が外部インターフェースの提示に使用される場合は必ずしもそうとは限りません。
API はどこから来るのでしょうか?
2021 年の調査では、回答者の 61% が、モダナイゼーションの方法として「最新のユーザー インターフェイスを有効にするために API レイヤーを追加している」と回答しています。 2022年にはその数は45％になりました。 つまり、最新のユーザー インターフェイスを実現する API は、必ずしもアプリケーションに直接接続された成果物ではないということです。 これらは、モバイル アプリやデジタル サービスなどの最新のユーザー インターフェイスやアプリケーションを容易にするファサードである場合もあれば、パートナーやサプライ チェーンの通信を可能にするために設計されたファサードである場合もあります。 これらのユースケースは、API ゲートウェイとロード バランサーのレイヤー 7 ルーティングによってサポートされています。これらは、多くの場合、API エンドポイントからアプリ エンドポイントへの変換を可能にする一定レベルの変換機能を提供するため、古いアメリカ西部の建物を実際よりもはるかに印象的に見せるような API ファサードが可能になります。
そしてもちろん、かなりの数の API はアプリに接続され、Web (通常は HTTPS) 経由でアクセスされる公開エンティティです。
どのようにしてそこに到達したかに関係なく、公開 API はアプリケーションと同じ多くの攻撃の対象となります。 これはボットが関係している場合に特に当てはまります。適切なドキュメントを備えた API を使用すると、攻撃者が大規模な攻撃をスクリプト化することが容易になるからです。
たとえば、2023 年にF5 Distributed Cloud Bot Defenseによって保護されたトランザクションの 13% 強が自動化されました。 つまり、Web ブラウザやモバイル アプリを使用する人間の代わりに、スクリプトやソフトウェアが使用されました。これらのトランザクションは、API とアプリの両方を介して行われます。 それらの自動取引の一定割合は確かに「悪質なボット」であり、当社のセキュリティ サービスの存在により、それらが行おうとしていた悪事を阻止できました。 （このF5 Labs レポートで、彼らが何をしようとしていたのかを詳しく調べることができます）
そこで、回答者が自己申告した API の数に基づいてボット管理をどのように認識しているかを調べたところ、ボット管理の重要性がかなり低いことがわかり、少しショックを受けました。
これらの気の利いた棒グラフから、API ゲートウェイに置かれている重要性は管理下にある API の数に適切であるように見えますが、ボット管理については同じことが当てはまらないことがわかります。 実際はまったく逆です！ API の数が増えるにつれて、ボット管理の重要性は低下するようです。 急速に。
確かに、それらの API の大部分は内部的なものになる可能性はあります。 つまり、これらは、悪意のあるボットである可能性のある外部のアクターに公開されない、マイクロサービス間の East-West API です。
しかし、そうかもしれない。 過去 1 年間に読んだ、API 経由でアクセスする攻撃者に関する記事の数を考えると、私たちが考えているよりも外部からの攻撃者の方がはるかに多いのではないかと思います。
そこで、需要の高い商品をむさぼり食ってビジネスを混乱させる、グリンチ ボットやスニーカー ボットなどの迷惑なボットが数多く存在する一方で、脆弱性を嗅ぎつけて攻撃することだけを目的とするボットも相当数存在することを皆さんに思い出していただきたいと思います。 API とアプリケーションの両方で。
したがって、組織は API と最終的にはビジネスを保護するために、幅広いセキュリティ オプションを採用することが賢明です。 ボット管理は確かにそのようなセキュリティ オプションの 1 つであり、あらゆるセキュリティ戦略の重要な要素として考慮する必要があります。
結局のところ、ボットはエンドポイントがアプリに属しているか API に属しているかを気にしません。ボットは両方を攻撃するのです。
つまり、組織はボットを検出し、ボットが実行しようとしている不正行為を阻止することで、アプリと API の両方を保護する必要があります。
ボット防御の実際の動作を確認したい場合は、このデモをご覧ください。