F5 Distributed Cloud Services で始める API Security

API Securityを構築するためには、考慮しなければならない3つのセキュリティ要素があります。

Network Security/Application Securityに関しては、通常のWebアプリですでに対策されているセキュリティだと思います。APIの場合はこれにAccess Controlが加わります。誤解無きよう、Webアプリ向けでも当然Access Controlは必要です。ただしこれがAPIになると「より一層注視しなければなりません」という意味でこの3つのせキュリティ要素をピックアップしています。

それではこの3つのセキュリティ要素で、具体的にどういった脅威を防げるのでしょうか。APIに関してもOWASP API Security TOP10（2019/2023年度版）というものがありますので、これをマッピングしてみます。

APIの脆弱性に関しては、認証認可の不備を突いた攻撃が多く見られます。よってAPI環境に対してはAccess Controlが他のセキュリティ同様に重要になってくるのです。

それでは次に、この3つのセキュリティ要素を実現する環境について見てみます。

多くの皆様は既にWebアプリ向けのセキュリティとして、Network Security/Application Securityを組み込んだ環境を構築されていると思います。API Securityに関してもまったく変わった環境が必要、ということではなく、同じような環境で実現することができます。ここではGartner社が提唱するDistributed Enforcement Modelに基づいた環境についてご説明します。

上図にて、セキュリティの適用ポイントは大きく２つに分かれています。

左側のF5 Distributed Cloud Services（以下F5XC）でNetwork Security/Application Securityを適用します。F5の技術をSaaSにて利用できるF5XC WAAPaaSであり、API環境に入ってくる前に、量的なネットワーク攻撃やアプリに対する攻撃に対して対策を行い、ここでAPIに特化した対策も行います。皆様自身のアプリで提供しているAPIの可視化（API Discovery）や防御を行います。

ここで1つ、OWASP API Security TOP10のAPI-1番に該当する脆弱性であるBroken Object Level Authorization（以下BOLA）を例にあげてみます。下図の通りBOLAには2つの攻撃フェーズがあります。

この「（１）偵察フェーズ」の攻撃に対処するのがF5XC WAAPになります。ネットワークの状況やエラーレート、振る舞い検知等の技術により、普段とは異なる怪しい動きを検知し、防御します。

「（２）実際の攻撃」に対処するのが右側のAPI Gatewayになります。右側ではAccess Controlを実現する事になりますが、適切にアクセストークンを実装し、アプリ自身でもAPI Securityを意識した実装が必要になります。例えば「他人の情報の参照」を要求するAPIリクエストに対して、レスポンスとして「エラーにする」「管理者からのリクエストなので情報を返す」「重要情報はマスクして返す」のように、情報を返すのかエラーを返すのか、は、完全にアプリの仕様に依存します。よってAPI Securityは、セキュリティやインフラチームだけでなく、開発チームとも密に連携して実現する必要があるのです。

すべての開発者にAPI Securityを意識して開発を進めてもらうのは簡単なことではありません。セキュリティ教育やガイドライン作成は必須ではありますが、それだけですべてのアプリをセキュアにすることは非常に大変なことです。アプリがセキュアな状態かどうか、常に監視し、可視化する必要があります。

F5XCでは、ライブトラフィックをチェックしてセキュリティを適用するShield-rightな対策と、Shift-leftにより開発の早い段階からAPI Securityを意識して開発することができる機能を提供しています。

Shift-leftでは、ソースコードのスキャンや脆弱性診断、ペネトレーションテストを実行します。スキャンや診断を開発の早い段階からプロセスに組み込んでアプリ開発を進めるとともに、アプリリリース後も自動的・定期的に実行することで、常にアプリがセキュアかどうかを監視することができます。

BOLAの「（２）実際の攻撃」を防ぐためにはアプリ側での対策が必須となりますが、APIのロジックベースでのスキャンや診断を自動的に行いながら開発を進めることで、BOLAの脆弱性を排除したアプリ開発が可能となります。

Shield-rightはF5XC WAAPの機能であり、F5が創業以来得意としている領域になります。BOLAの「（１）偵察フェーズ」の攻撃に対処するための機能になりますが、スキャンや診断の機能と組み合わせることで、アプリに合わせたセキュリティの設定が自動生成され、それをそのままF5XC WAAPに適用することができるようになります。

Shift-leftとShield-rightの機能を組み合わせることで、セキュリティの状況を常に可視化し、対策を漏れなく行うことができます。

API Securityに必要な3つの要素と、それを実現するF5XCについて概要をご理解頂けたかと思います。それでは最後に、まずは何を意識してAPI Securityを始めるべきか、について考えてみます。

まず皆様、API Securityで実際に守るべきAPIを把握されていますか？何を守るべきか、明確に把握していないと対策を打つことができません。よって筆者が考えるAPI Securityの始め方は下記3つの順番になると思います。

（１）API Discovery

（２）OWASP API Security TOP10に対する対策

（３）継続的な監視

まずは「（１）API Discovery」にて皆様自身のAPIエンドポイントを可視化しましょう。「うちのAPI、増えてきているけど大丈夫だろうか・・」とヒヤヒヤされている方、まずは可視化することでそのヒヤヒヤを解消しましょう。

ヒヤヒヤを解消すると対策すべき対象が明確化され、今度は「対策はどうしよう・・」となります。セキュリティ対策はすべてを一度に行うのは非常に大変だと思います。まずは「（２）OWASP API Security TOP10」を参考に対策を考えてみてください。F5XC WAAPやスキャン、診断の機能を活用し、通常のWebアプリセキュリティだけでなくAPI Securityも組み込まれたF5XCで対策が可能です。もちろん開発ガイドラインの作成やセキュリティ教育の実施等も必要です。

そして最後に、継続することが重要です。「（３）継続的な監視」を行う必要がありますが、複雑なシステムですと継続することも難しくなります。F5XCでは、すべての機能を1つのダッシュボードから操作することができ、脆弱性の分析、ライブトラフィックの脅威分析、ネットワークの監視とそれぞれの設定について簡単に行うことができます。いかに簡単に構築して運用していくか、これが継続するために非常に重要になります。

残念ながらセキュリティに終わりはありません。かといって無視できるものでもありません。また、セキュリティはコストではありません。「安心」をユーザや投資家、経営層にアピールし、ブランド価値を向上させる役割もあります。

今回はAPI Securityの始め方について述べさせて頂きましたが、皆様のお考えに少しでも良いインパクトを与えられたとしたら幸いです。