[Sponsored]

WAFでも防げないAPI攻撃が増加、適切な対策と開発者の負担軽減を両立させるにはどうすればいい？

2025年2月5日(水)

リスト

モバイルアプリやIoTデータ連携など、様々な場面でWeb APIが使われている。Webブラウザから明示的にアクセスするWebアプリケーションと比べると、APIは一般的にセキュリティ対策が甘めで、認可の仕組みの不備をついた成りすましによる情報漏えいなどが起こりやすい。一方でリリースサイクルの短縮が求められる開発の現場では、機能実装が優先され、セキュリティ対策に十分なリソースを割けず、開発者のセキュリティスキルも不足、という課題を抱えている。API攻撃への対策が難しい理由、開発者に負担をかけずに有効な対策を講じる方法について、アカマイ・テクノロジーズのキーパーソンに聞いた。
提供：アカマイ・テクノロジーズ合同会社

認可の不備を突くことで、権限のない情報を搾取

　APIに特化した攻撃の典型的な手法をランキング形式で示したものが、「OWASP API Security Top10」としてまとめられている（図2）。OWASP（Open Worldwide Application Security Project）は、Webアプリケーションのセキュリティ向上を目指すオープンコミュニティであり、同ランキングは、SQLインジェクションのようなWebシステム全般に共通する脆弱性よりも、API専門の攻撃に軸足を置いている。現行版のTop 10リストは2023年に4年ぶりに更新された。

図2：APIのリスクをランキング形式でリスト化した「OWASP API Security」上位10項目
拡大画像表示

　ランキングの構成を見ると、認証・認可の情報をJSON形式でやり取りする「JSON Web Token」（JWT）仕様で構築したシステムの脆弱性を突くケースが多い。API攻撃で一番多いリスクは、BOLA（Broken Object Level Authorization、オブジェクトレベルの認可の不備）による認可の乗っ取りである（図3）。

図3：APIの脆弱性でもっとも多いBOLA（オブジェクトレベルの認可の不備）の例
拡大画像表示

　BOLAとは、攻撃者がリクエスト内の送信オブジェクトのIDを操作し、本来であればアクセスが許可されていないオブジェクトにアクセスできてしまう脆弱性のこと。例えば、APIの利用者を識別するための情報を入手されてしまったり推定されてしまったりすることにより、正規の利用者に成りすましてアクセスを許してしまう。

　BOLAによる脆弱性の例として中西氏が示した事例が、ドイツの学習アプリである。あるGETリクエストを渡すと、同じ地域からアクセスしているユーザーIDのリスト500人分を返す実装になっていた。アプリ内でこれらのデータを活用しているが、ユーザーIDが分かってしまうと、別のGETメソッドのURIに埋め込んでリクエストするだけで該当ユーザーの個人情報（メールアドレスや生年月日など）が取得できてしまうようになっていた。この例のようにアプリを便利にするために良かれと思って開発したAPIが思わぬ脆弱性を生んでいることが多い。

正当なAPIリクエストとの見極めが困難、WAFでは防げない

　「BOLAのリクエストは正当なトラフィックと似ているため、WAFでは見極めは困難」と中西氏は言う。これには幾つかの理由がある。前述したWAFのルールで未知の脆弱性は検知できない原則のほかに、ペイロードの解析能力が弱いこと、さらに１リクエスト単位で攻撃か否かを判定してブロックする仕組みのWAFでは、「いつもと違うデータを読み出そうとする攻撃」が来ていることを検知できない。これを可能にするには、蓄積したデータを分析する機械学習（AI）の力が必要になる。

　APIのリスクは、ポスチャ（態勢）リスクとランタイム（実行時）リスクの2つに分類できる。ポスチャリスクは、組織の管理体制面のリスクであり、未管理のシャドーAPIの存在や、脆弱なAPI設計などが該当する。ここでは、組織運用面および設計面の欠陥を無くすことが大事である。一方のランタイムリスクは、APIの実運用時に脆弱性を突かれるリスクである。認可の仕組みを改善することや、何らかの方法でAPI攻撃を検出することが必要になる。

トラフィックを収集・分析してAPIを棚卸、攻撃も検出

　こうした中、アカマイ・テクノロジーズは、API攻撃の対策として「Akamai API Security」を提供している（図4）。買収したNoname Securityの技術を用いており、APIトラフィックを分析するアプローチをとっている。これにより、未管理のシャドーAPIを可視化し、脆弱なAPIを検出し、APIの悪用を検知する。大きく4つの機能（APIの発見と棚卸管理、脆弱性の検出、攻撃の検出、API開発時のテスト）を提供する。

図4：Akamai API Securityの全体像
拡大画像表示

　まず、使われているAPIを検出して資産管理する。APIを検出するためのデータソースとして、APIのトラフィックデータを利用する。CDN（コンテンツ配信ネットワーク）型WAFのエッジサーバー、パブリッククラウドのトラフィックミラーリング機能、コンテナ基盤（Kubernetes）、MuleSoftなどのAPI Gatewayなどから取り込む。この段階で「どのようなAPIへのアクセスがあったか」が分かるので、未管理のシャドーAPIを可視化できる。

　次に、APIトラフィックデータからAPIの脆弱性（欠陥のある実装）を発見する（図5）。リクエストの内容（パラメータの規則性など）を分析することで、APIの脆弱性を検出できる。また、一定期間蓄積したAPIトラフィックデータを機械学習で分析することで、いつもと異なるパターンのアクセス（攻撃の可能性のあるアクセス）を検出可能である。「検出したリスクの対策方法も文章で示すので、API開発者に情報を渡して修正してもらうための資料として利用できる」（中西氏）。

図5：APIトラフィックデータの分析により、APIの脆弱性を検出して報告する
拡大画像表示

　APIの実運用時も、実際のAPIトラフィックをリアルタイムに分析し、攻撃の可能性が高いトラフィックを検出可能である。必要に応じて、セキュリティゲートウェイなどの外部サービスとWebhookで連携し、トラフィックをブロックして塞き止めるといった運用がとれる。

　API開発のライフサイクル（CI/CDのパイプライン）に組み込んで、開発工程の初期段階で脆弱性をテスト可能なスキャナツールも、オプションで用意している。

環境に合わせてデータ処理の流れを柔軟に構成可能

　他社ツールと比べたAkamai API Securityのアドバンテージの1つは、コネクタなどを介して取り込めるデータソースが豊富で、なお分析後のデータによる外部連携が容易なこと。簡単なものはクリック1つでデータ連携が完了する。要件に応じて、オンプレミス環境にデータ収集・変換の仕組みを個別に構築することも可能である。

　トラフィックデータをローカルとクラウドの2段構えで解析する仕組みも提供する。データのすべてを直接クラウドに送るのではなく、オンプレミスに置いた解析エンジンで前処理し、メタデータと攻撃検出時の詳細データだけをクラウドに送る。「外に出したくないセンシティブなデータをクラウドに転送するリスクを低減できるほか、モニタリングしたデータの転送量を減らせる」（中西氏）。

　Akamai API Securityのユーザーは幅広い。同社は一例として、EC（電子商取引）サイト、予約サイト、金融ペイメント、製造業の機器メンテナンス、などのユースケースを挙げている（Akamai お客様事例）。特に、重要インフラのIoTシステムなどは、攻撃者に制御されてしまうとインパクトが大きいため、APIセキュリティを確保する需要は大きい。

　APIセキュリティの需要の高まりを受けてアカマイ・テクノロジーズは、「APIのセキュリティを高めるために何をすべきか」を解説するウェビナーを、月に2回開催している。「APIの存在を意識することは少ないが、APIはアプリやシステムに組み込まれており、実際にはよく使われている。しかし、一般的なWebシステムと比べるとセキュリティが甘いケースが多い。いま対策しないことによるビジネスへの悪影響は致命的なものになる可能性があります。まずはどんなリスクが裏で起きているか可視化することが重要です」（中西氏）。