需要に応じたリソースの拡張性の高さや利用開始までに必要な時間の短さといった利便性から、企業はWebアプリケーションプラットフォームをオンプレミス環境からクラウド環境へ、積極的に移行を推進しています。また、開発の効率化やコスト削減などを目的とし、Web APIもより活用されるようになりました。
これらはセキュリティニーズの変化をもたらします。今日のWebアプリケーションセキュリティの花形といえばWAF(Web Application Firewall)です。事実、WAFはWebアプリケーションの脆弱性を狙う数多の攻撃を防いでおり、Webアプリケーションの保護において重要な役割を果たしています。
ですが、高度化するサイバー攻撃に対し、単にWAFがあれば十分なのでしょうか。
今回はIT分野を中心としたリサーチ企業である「Gartner, Inc.」が提唱した「WAAP」についてご紹介したいと思います。
WAAPとは「Web Application and API Protection」の略で、2017年にGartnerが提唱しました。WAAPは「クラウド型WAAPサービス」のことを指し、「クラウド型WAFサービス」の進化形であると言えます。
WAAPには以下４つのコア機能が含まれます。
クラウド型サービスとして展開するメリットは、リバースプロキシのように機能することで暗号化されたHTTPS通信を復号しリソースを気にすることなく検査を行うことができること、上記4つのコア機能を大規模かつ容易に展開することが可能な点が挙げられます。
また、コア機能以外にもDNSセキュリティやCDNといった、オプション機能が付随されるサービスもあります。
これからのWebアプリケーション保護において、WAF以外にも必要とされるコア機能である、
APIセキュリティ、Bot対策、DDoS対策の3つについて、ここではもう少し掘り下げてみたいと思います。
Web APIを活用したマッシュアップサービスの普及、ビジネスとAPIをつなぐAPIエコノミーが注目されるなど、APIに対する期待はますます大きなものとなっています。
飲食店情報サイトが「Google Map」のAPIを活用することで、自社の専門領域や新規事業の開発に注力できるといった例は、皆さまも聞かれたことがあるかもしれません。また、APIの利活用は金融業界でも活発であり、クレジットカードデータや決済データなどを取り扱う「FinTech」が大きなトレンドとなっています。
このように、Web APIでは機微な情報のやり取りも行われることから、APIエコノミーの市場規模が拡大するにつれ、攻撃者の標的として見なされ始めています。
ではこれらの脅威に対し、従来型のWAFでは対応できないのでしょうか。
結論から述べますと、WAFでのAPI保護は可能です。
Web APIはHTTP通信を用いるため、もちろんWAFの検査対象となります。
なお、ここでは従来型WAFの定義を「シグネチャマッチングを行うブラックリスト管理型」とさせて頂いた上で、気をつけなければならない点をご説明します。
そもそもWAFはWebアプリケーションの脆弱性を狙う攻撃を防ぐものです。
Webアプリケーションの脆弱性とは、Webアプリケーションを構成するシステムやプログラムの実装上の不備を指します。種類はあれど、これらの不備を突く攻撃は長年のノウハウが蓄積され、現在はある程度パターン化されています。これが膨大なシグネチャとしてWAFに登録されており、シグネチャにマッチングした不正なリクエストを検出し、保護を行うことができます。
一方、Web APIは取得したい情報や処理して欲しい内容をパラメータとして付与し通信を行いますが、このパラメータやリクエストボディ部分の設計はAPI提供元の仕様に依存します。すなわち、外部サービスとのAPI連携の数だけ仕様が存在することを意味します。API実装上の不備は、API提供元の開発力に依存するとも言えます。
また、これらの機能拡張や仕様変更は自社にてコントロールができない領域となります。特定の外部サービスのAPI脆弱性に対応するシグネチャをせっせと作成しても、ある日仕様が変更され突然使えないものになることも考えられます。
これらの理由により、一般的に外部サービスのAPI脆弱性に対応する一意なシグネチャを作成することは難しいと言われています。
では、Web APIの脆弱性を狙う攻撃に対し、どのようなアプローチを取ればよいのでしょうか。
APIに対する認証・認可、そしてクォータ管理といった対策はAPI Gatewayというソリューションがありますが、一般的には不正リクエストへの対応までは含まれません（含まれているソリューションもあります）。サイバーキルチェーンに則り、偵察フェーズ、攻撃フェーズ、そして目的実行フェーズ(目的情報の持ち出し)のそれぞれにて脅威を検出する機能を備えてなくてはなりません。
偵察フェーズでは攻撃者はAPIの脆弱性を調査するため、例えばパラメータを変えたリクエストを大量に送りつけ、レスポンスの内容から脆弱性に結びつく情報を得ようとします。このような一般ユーザとは異なる挙動について検出し、アラートを上げる機能が求められます。
攻撃フェーズではAPI通信における正常な動作を、AIを用いベースラインを自動学習させ、このベースラインから乖離している通信についてアノマリー検出を行う機能が有効です。自動化を行うことで、シグネチャメンテナンスの負担を軽減させることができます。
目的実行フェーズではデータの流出を検出する必要があります。通常よりも大きなレスポンスサイズが返されていることや、単一のクライアントに大量のレスポンスを返していることなど、ここでも通常のユーザのふるまいとは異なる挙動を検出する機能が求められます。
このように従来型のWAF（シグネチャマッチング）では検知が難しい部分について、サイバーキルチェーンの観点からWeb APIの保護に必要なセキュリティ機能を洗い出すことをおすすめします。
Bot対策もDDoS対策も考え方は同じです。一つ一つのリクエストはWebアプリケーションの脆弱性を狙うものではありませんので、WAFでの保護の対象外となります。
しかし、このようなWebアプリケーションを運営するビジネスにとって不要なリクエストを、いかにエッジ(境界)にてふるい落とせられるかが求められます。とはいえ考え方は同じですがBot対策機能とDDoS対策機能に求められる性質は異なっており、Bot対策は質的側面、DDoS対策は量的側面からのアプローチとなります。
Bot対策はリクエストの「質」からのアプローチです。
とある航空会社の予約サイトではアクセスの約86%がBotであったとの報道があり、また、あるチケット購入サイトでは9割超がBotであったという報道がありました。Botが蔓延ることにより、本来ターゲットとしているユーザ層への機会損失を招くことが懸念されます。
しかし、ひとえにBotといえど悪意のあるBotだけではなく、Webクローラやシステム運用のための死活監視通信など、一概に害とは言えないものも多く存在します。
そこでBot対策に求められるのは、「悪意のあるBot」、「通しても問題のないBot」、「判断のつかないグレーなBot」の3つに振り分けられる機能となります。この実装方法は各社がしのぎを削って競い合っていますが、単一のルールだけではなく、多角的な視点からAIやふるまい検知を活用した技術を取り入れ、精度の向上は著しいものとなっています。
DDoS対策はリクエストの「量」からアプローチをします。前述のBot対策機能を用いることでBotの善悪の判断は行われますが、そもそも処理しきれないほどの大量のリクエストが届いた場合は、その前段にて止める必要があります。
近年、ブラックマーケットでは「DDoS as a Service」の名の通り、非常に安価でメニュー化されたDDoS攻撃産業が成立しています。「Mirai」と呼ばれるマルウェアにより感染した、大量のIoTデバイスで形成されたボットネットを用いた攻撃では、その攻撃トラフィック容量は1.5Tbpsにもなると言われています。
また、現在DDoS攻撃のトレンドは大容量化攻撃(bits/second)だけではなく、アプリケーションレイヤに対する高負荷攻撃(requests/second)、瞬間的な高トランザクション攻撃(packets/second)、そして繰り返し・長期間に渡り執拗に狙われるケースが増加しています。これらの非常に洗練された攻撃からWebアプリケーションを保護するためには大容量のキャパシティが必要となり、世界各地のアクセスポイントにて分散処理を行うことが有効です。
Webアプリケーションを狙う攻撃は多角化しており、WAF機能のみではなく、APIセキュリティ、Bot対策、DDoS対策機能を含めた検討を行う必要が求められます。これらは統合型クラウドWAAPサービスとして提供されることが多いですが、機能ごとに代替となるテクノロジーが存在します。
「WAAP」の概念を参考にし、自社に必要なセキュリティ機能を検討し、Webアプリケーションの保護に努めてみてはいかがでしょうか。