BOLAの「認可ギャップ」にランタイム戦略が必要な理由

Chaim Peerシニアプロダクトマネージャー | F5

Ian Dinnoシニアプロダクトマーケティングマネージャー | F5

OWASP API Security Top 10に挙げられる脆弱性の1つであるオブジェクトレベル認可の不備（BOLA）に対しては、シフトレフトだけでは戦略として不十分です。BOLAは入力ミスのような単純なコーディングエラーではなく、ビジネスロジックの根本的な不備です。

広範なマイクロサービス環境で、すべての所有権ルールを開発者が手作業で確認することに頼るのは、極めてリスクの高い賭けです。2026年には、米国証券取引委員会（SEC）の厳格な開示規則と一般データ保護規則（GDPR）の強力な執行により、「ロジックのバグ」が瞬く間に重大な財務上の損失につながる可能性があります。

認可ギャップの構造

モノリシックアーキテクチャの時代には、認可は暗黙的に行われていました。サーバーはセッションを自身のメモリに保持し、ログインしているユーザーを正確に把握したうえで、単一の集中型プロセスによってデータベースクエリを制御していました。

最新のクラウドアーキテクチャによって、このモデルは崩壊しました。現在では、外部プロバイダーが管理するアイデンティティと、数百もの個別サービスに分散するデータが切り離されています。入口ではユーザーが誰であるかを検証しますが、そのユーザーが何を所有し、何にアクセスできるかの検証は、バックエンド開発者に委ねられることが少なくありません。

「認可ギャップ」とは、ログインには成功しているものの、所有権の確認が行われていない状態を指します。最新のサービスはステートレスであるため、受信したリクエストを本質的に信頼します。リクエストに「注文7788」が含まれていても、その注文がリクエスト元のユーザーに属することをコードで明示的に検証しなければ、データが盗まれます。

認可ギャップの可視化

Webアプリケーションファイアウォール（WAF）だけではBOLA脆弱性から十分に保護できない理由を理解するには、最新のステートレスAPIにおける認証とリソース所有権の技術的な分断に目を向ける必要があります。WAFはSQLインジェクションなどの「不正な」構文を検出しますが、BOLAの悪用では、通常のリクエストに見える「正しい」構文が使用されます。BOLAを阻止するには、防御をアイデンティティ対応にし、ユーザーがリクエストしている特定のオブジェクトに対して、そのユーザーを検証する必要があります。

銀行アプリケーションを例に考えてみましょう。攻撃者であるユーザーAが自分のアカウント（ユーザーID：8899）にログインし、有効なセッショントークンを取得します。これでユーザーAは認証済みとなり、/api/v1/accounts/1234/balanceにリクエストを送信することで、別のユーザーBのデータへのアクセスを試みることができます。

WAFは、SQLインジェクションや悪意のあるスクリプトがないかを確認します。1234は完全に有効な整数であり、構文にも問題がないため、WAFはリクエストを通過させます。

APIゲートウェイは、セッショントークンが有効で、期限切れになっていないことを確認します。攻撃者であるユーザーAは、正規にログインしているユーザーであるため、ゲートウェイはリクエストを認証済みと判断し、バックエンドの内部システムに転送します。

その結果、バックエンドサービスは「信頼済み」のリクエストを受信し、口座1234の残高を返します。ゲートウェイは攻撃者が誰であるかを確認したものの、アクセスを許可されている対象が何かを一度も確認しなかったため、攻撃者はセキュリティを回避することに成功しました。

「導入前」のシナリオ：破綻した信頼モデル

多くの最新アーキテクチャでは、APIゲートウェイは入口で身分証明書を確認するだけの「用心棒」のような役割を果たします。ユーザーが有効なJWTまたはセッションCookieを提示すると、ゲートウェイは以降のそのユーザーからのリクエストをすべて正当なものと見なします。

ユーザーAがログインし、有効なトークンを受け取ります。続いて、GET/api/v1/data/1234にリクエストを送信します。次のステップでは構文とセッションをチェックします。標準WAFはリクエストに問題がないこと（SQLインジェクションがないこと）を確認し、APIゲートウェイはセッションが有効であることを確認します。

ここで認証の不備が生じます。WAFもゲートウェイも、リソース1234が実際にユーザーAに属しているかどうかを確認しません。さらに、バックエンドサービスはゲートウェイからの「検証済み」リクエストを無条件に信頼し、ユーザーBの非公開データをユーザーAに提供します。この時点で侵害が発生します。

しかし、高度なAPIセキュリティソリューションを導入すれば、この新たな「門番」は入口でユーザーのIDを確認するだけではありません。ユーザーが入ろうとする個々の部屋について、入室権限があるかどうかも検証します。

「導入後」のシナリオ：アイデンティティを認識した適用

高度なAPIセキュリティソリューションは、認証のギャップを解消し、ログイン中のユーザーが要求されたオブジェクトに対して要求された操作を実行する権限を持っていることを検証するために、次の手順を実行します。

最初のステップでは、システムがトークンからID（ユーザーA）を、リクエストからリソースID（1234）を抽出します。次に、学習済みのBusiness Logic Mapを使用して、リソース1234の所有者がユーザーAではなくユーザーBであることを特定します。

第3のステップでは、IDとリソースのマッピングがロジックチェックに合格しないため、リクエストは内部システムとのやり取りが許可される前に、アプリケーションのエッジで破棄されます。その結果、不正なリクエストがデータの保存先であるアプリケーションのバックエンドに到達することはなく、データ流出を未然に防ぎます。

シフトレフトではBOLAを阻止できない理由

セキュリティチェックとテストを開発ライフサイクルの早い段階に移行するだけでは、この問題は解決できません。シフトレフトの手法にはコンテキストが欠けているためです。静的解析（SAST）などのツールが確認するのはデータではなくコードです。そのため、ユーザーAにはユーザーBの請求書を閲覧する権限がないことを認識できません。この関係はソースコードではなく、データベースで定義されているためです。

さらに、ほとんどの動的解析（DAST）ツールは、単一ユーザーのコンテキスト内でしかスキャンしません。「200 OK」レスポンスを確認すると合格と判定するため、そのユーザーが別のユーザーの非公開レコードにアクセスしていることを認識できません。

一方、標準的なAPIテストではコンテキストが考慮されません。つまり、実環境から切り離された状態でテストするようなものです。実際のトラフィックデータを無視するため、適切なテストにはなりません。本番環境でIdentity AがResource Bにどのように対応しているかをテストで把握できなければ、検証できるのは構文だけであり、ロジックではありません。それでは、ビジネスをテストしていることにはなりません。

エッジでの適用

この問題を解決するには、組織は以下の3層で構成されるランタイム戦略を導入する必要があります。

1. ユーザーとリソースのマッピング。 APIセキュリティソリューションは、トークンからID情報を抽出し、HTTPリクエストメッセージ（ヘッダー、Cookie、パス、または本文）内のリソースIDと照合します。
2. Open Policy Agent（OPA）サイドカー。 何百人もの開発者に個別のチェック処理を任せるのではなく、OPAを使用して、認可ルールを1か所で一元管理します。 OPAサイドカーは、アプリケーションコンテナと並行して実行されるデプロイパターンです。低レイテンシーかつ高パフォーマンスのローカル認可判定を実現し、マイクロサービスとAPIセキュリティのポリシーをリアルタイムで評価できます。
3. 振る舞いの監視。BOLA攻撃を阻止するには、ライブトラフィックからアイデンティティ（誰が）、コンテキスト（どのように）、リソース（何を）を抽出し、通常の関係性のベースラインを構築する必要があります。たとえば、1人のユーザーが1分間に50個の異なるIDへのアクセスを試みるなど、確立されたベースラインから逸脱した場合、システムはこの異常を特定します。これは人間ではなくスクレイパーによる明確な兆候であり、直ちにブロックする必要があります。

F5がどのように支援するか

F5 Distributed Cloud API Securityは、可視性がまったくない状態から、ランタイム保護を適用する段階までの明確な道筋を提供します。F5 Distributed Cloud Servicesの一部として、アプリケーションデリバリとセキュリティを1つのプラットフォームに統合し、一元化されたセキュリティを提供します。分散型サービス拒否（DDoS）攻撃の緩和、ボット対策、APIセキュリティ、WAFなどのコンポーネント間でインテリジェンスを相関させ、自動化を活用することで、単一のお客さまからのリクエストと、連携して行われるマルチベクトル攻撃を識別します。

製品のAPIディスカバリ機能は、「シャドーAPI」を含むすべてのAPIを自動的に検出し、本番トラフィックを継続的に分析して、アプリケーションの実際のビジネスロジックを学習するとともに、ユーザーが特定のデータオブジェクトをどのように操作しているかをマッピングします。コンテキスト認識型テストでは、これらのインサイトを活用して本番前環境で対象を絞った「マトリックステスト」を実行し、コードをデプロイする前にIDとオブジェクトのマッピングにおける脆弱な箇所を特定します。

Distributed Cloud API Securityは、BOLA攻撃の検知機能も提供します。学習した行動ベースラインと受信リクエストを相関分析して不審なアクティビティを検知することで、さまざまなBOLAシナリオを特定し、ランタイム保護に役立つ情報を提供します。

2026年、BOLA攻撃はデータ侵害を極めて短時間で引き起こす攻撃手法の1つです。シフトレフトは技術的なバグの発見に有効ですが、破綻したビジネスロジックを修正する唯一の方法は「右側にとどまる」ことです。認可処理をエッジに移行し、今すぐデータ漏えいを阻止しましょう。

組織のAPI保護にF5がどのように役立つかをご確認いただくか、実際の動作をご覧ください。

著者について

Chaim Peerシニアプロダクトマネージャー | F5

Chaim Peerのその他のブログ記事

Ian Dinnoシニアプロダクトマーケティングマネージャー | F5

Ian Dinnoのその他のブログ記事