アプリケーションファイアウォールについて人々が話すとき、さまざまなものを一つの傘の下にまとめてしまう傾向があります。しかし、すべてのファイアウォールが同じというわけではなく、特にアプリケーションが実際に必要とする保護を把握しようとする場合、それらの違いを理解することが重要です。
では、分解してみましょう。アプリケーションセキュリティには主に3つの層があります：WAF、アプリ内、カーネル内です。RASPや一部のADRはアプリ内に属し、より低レベルのeBPFベースのADRはカーネル内に属します。いずれもアプリへの悪影響を防ぐという大まかな目標は同じですが、その手法は大きく異なります。 端的に言えば、WAFはリクエストを、アプリ内セキュリティはコードを、カーネル内セキュリティはOSを監視します。
どれが必要ですか？ そうですね、可能な限り最強のセキュリティ態勢を求めるなら、おそらく複数が必要です。本記事では、WAF、RASP、ADR、eBPFがそれぞれ何であるか、各技術が最も効果を発揮する領域を説明し、どれが必要か判断するお手伝いをします。
WAF VS RASP VS ASP：アプリケーションセキュリティの3層構造はどのように機能するのか？
アプリケーションセキュリティツールは3つの異なるレベルで動作し、それぞれが他のツールでは検出できない脅威を捕捉します。
WAF：エッジセキュリティ
WAFはアプリケーションの外側に完全に配置され、アプリに到達する前の着信HTTPトラフィックを検査します。アプリケーションのコンテキストは持ちませんが、大量の脅威に対して非常に有効です。
アプリ内ランタイムセキュリティ：アプリ内部
アプリ内セキュリティツールはアプリケーションに直接組み込まれます。コードの実行に組み込まれ、ユーザー入力がアプリ内を流れる経路を追跡し、悪意のあるペイロードがデータベースドライバーに到達したりシェルを生成したりする前に、攻撃が危険となる正確な時点でブロックできます。完全なアプリケーションコンテキストを保持するため、その動作は精密です。ADRのサブカテゴリであるRASPツールはこのカテゴリーに分類されます。
カーネル内ランタイムセキュリティ：アプリケーションの下位層
カーネル内ランタイムセキュリティツールは、アプリケーションの完全下位、OSレベルに位置します。アプリケーションコードにフックする代わりに、ホスト上の全プロセスが行うシステムコールを監視します。アプリケーションロジックの動作内容は把握しませんが、OSレベルで全てを可視化します。攻撃者が既に侵入した後の動作も含みます。eBPFベースのADRツールはこのカテゴリーに該当します。
まずWAFを検証し、次にRASPとADRの観点からアプリ内およびカーネル内を検証します。
WAFとは何ですか？
WAF（Webアプリケーションファイアウォール）はアプリケーションの外側、境界に配置されます。リクエストがアプリケーションに到達する前に、WAFがこれを遮断し、SQLインジェクション文字列、悪意のあるヘッダー、不審なURLなど既知の攻撃パターンのリストと照合します。パターンに一致するものがあれば、ブロックされます。
WAFが真に代替不可能な領域は、DDoSトラフィック、ボットによるフラッド攻撃、スクレイパーといったボリューム型攻撃です。WAFは大量のブルートフォース攻撃を想定して設計されています。 例えばCloudflareは、大規模な攻撃がインフラに到達する前に吸収する能力に極めて優れています。導入も容易で、主にDNS設定やプロキシ変更のみで、コードの記述やアプリ内へのインストールは不要です。WAFはカスタムルール・許可リスト・ルール調整による柔軟な設定が可能で、不審な動作をブロックするか検知のみするかを選択できます。
問題は、WAFがリクエストが通過した後の動作を把握できない点です。不審なペイロードを検知することはできても、そのペイロードが実際に危険な動作を行うかどうかは判断できません。なぜなら、アプリケーションがリクエストをどう処理するかをWAFは知らないからです。WAFは流入するトラフィックを監視し、設定されたブロック対象とのパターン照合を行い、ブロックするかどうかを判断するだけです。
その結果、誤検知は深刻な問題となり、リクエストを過剰にブロックしてしまう可能性があります。ユーザーがたまたまSQLのように見えるものを検索するとブロックされる一方で、巧妙な攻撃者はペイロードを異なる方法でエンコードして突破します。また、WAFが悪意のあるユーザーを阻止しようとIPをブロックすると、攻撃者はVPNを使用してこれを回避できます。しかし、VPNからの全トラフィックをブロックしようとすると、正当なユーザーも同時にブロックされてしまいます。
その結果、WAFのチューニングは継続的なプロセスとなり、ルールを厳格化し、誤検知に注意を払い、必要に応じて緩和します。これが、WAFがRASPに比べてメンテナンス負荷が高い理由の一つです。RASPはアプリケーションのコンテキストを把握しているため、手動介入なしに適切な判断が可能であり、継続的なチューニングがはるかに少なくて済むからです。
例：Cloudflare、AWS WAF、Imperva
オープンソース: ModSecurity (OWASP経由)
RASPとは何ですか？
RASP（ランタイムアプリケーション自己保護）とアプリ内ADRは、WAPのように外部から流入トラフィックを検査するのではなく、アプリ内部に存在し、実行中に内部から監視するランタイムセキュリティです。
この重要性を理解するには、シンクについて知る必要があります。シンクとは、ユーザー入力が単なるデータではなく、意味のある何かとして実行されるようになる関数です。コード内、ライブラリ、組み込みモジュールに存在します。SQLインジェクションを例に考えてみましょう。攻撃者はフォームフィールドに悪意のあるコードを埋め込み、それがアプリケーション内を流れ、データベースドライバ（例： db.query()その時点で、それはテキストではなくコマンドとなる。そのクエリ関数がシンクである。RASPのようなアプリ内セキュリティツールは、これらのシンクにフックし、入力がアプリ内を移動する過程を監視し、危険な関数に至るまでの全経路を追跡する。
これらのアプリ内ツールは、文字通りアプリ内部で動作しているため、入力内容やその発生元、行き先を把握しています。推測する代わりに ' OR 1=1-- 攻撃か正当な検索文字列か、アプリ内ツールはこの特定の文字列がどこから来たかを把握している req.body.user, は検証されずに連結され、まもなく pg.query() 電話だ。遮断しろ！
誤検知率はWAFやeBPFベースのADRよりもはるかに低い。単純なパターンマッチングではないためだ。IPアドレスだけでなくユーザーIDもブロックできるため、攻撃者がVPNを利用するだけでは防げない。既知のシグネチャと照合するのではなくデータフローを追跡するため、これまで誰も見たことのない新たな攻撃ペイロードも捕捉可能だ。インジェクション型攻撃に対する確固たるゼロデイ対策を実現！
RASPとアプリ内ADRはサード依存関係カバーします。自身のコードを完全にサニタイズできても、使用しているライブラリに脆弱性あれば制御不能です（SCA スキャナーも検出SCA 場合）。RASPはコードの出所に関わらずシンクレベルで動作します。
アプリ内セキュリティの主な制限は、攻撃者がネイティブアドオンや直接的なシステムコールを通じてランタイムを完全に迂回した場合、フックが一切発動しない点です。また、シェルが生成されると、RASPは最初の呼び出しは検知できても、そのシェル内部でその後発生する事象は把握できません。そこで第三の層が機能するのです。
例: Aikido Zen （オープンソース版と有料版）
ADRとは何ですか？
ADR（アプリケーション検知・対応）は、RASPが属するより広範な現代的なカテゴリーである。全てのRASPはADRであるが、全てのADRがRASPであるとは限らない。ADRという用語は、アプリケーション内部からの攻撃であれ、アプリケーションの下位レイヤーからの攻撃であれ、実行時に攻撃を監視し対応するあらゆるツールを包括する。
実際には、ADRツールは2種類に分類されます。 アプリ内ADR（RASPが従来から提供してきたもの）はアプリケーション内に直接配置され、完全なコードレベルのコンテキストを保持します。上記のRASPセクションで説明したアプリ内セキュリティに関する内容は全てここに適用されます。ADRはRASPよりも広範な範囲をカバーすることを意味します。RASPが主にブロックツールであるのに対し、ADRは検知、可視化、インシデント対応機能も包含します。全てのADRツールがこれら全てを実現するわけではありませんが、このカテゴリーが向かっている方向性です。
もう1つのADR方式であるカーネル内ADR（eBPFベースのADR）は、アプリケーション保護において異なるアプローチを取る。アプリケーションにフックする代わりに、Linuxカーネルレベルに配置され、ホスト上の全プロセスが行うシステムコールを監視する。アプリケーションのロジックについては何も知らないが、OSレベルでは全てを把握している。
攻撃者がシェルを生成すると、カーネル内ADRはアプリ内ADRでは検知できない、侵入後の次のレベルの可視性を提供します。カーネル内ADRは、ファイル読み取り、ネットワーク呼び出し、横方向移動など、そのシェル内で実行されるすべてのコマンドを検知します。攻撃者がランタイムを完全にバイパスした場合でも、ADRは依然として execve トリガーされた方法にかかわらず。実際のところ、Node.js アプリケーションで最も一般的なシナリオは、サプライチェーン攻撃（ランタイムが検査しないネイティブコードを含む侵害された依存関係）を通じて侵入する悪意のあるネイティブアドオンです。
eBPF（Extended Berkeley Packet Filter）は、カーネル内部のADRツールを支える基盤となるカーネル技術です。eBPFを使用すると、Linuxカーネル自体に触れることなく、OSレベルで発生する特定のイベントを監視できる安全な監視プログラムをカーネルにアタッチできます。 通常、カーネルレベルでカスタム監視やロジックを追加するには、カーネルのソースコードを直接修正する（リスクが高く複雑）か、カーネルモジュールを記述する（バグでシステム全体がクラッシュするリスクがある）必要がありました。eBPFは、サンドボックス環境で動作する小さなプログラムをカーネルに注入できるようにすることで、この問題を回避します。 これらのプログラムは特定のシステムコールを監視し、ADRツールに報告します。ADRツールはそれに基づいてアクションを許可するかブロックするかを決定します。
カーネル内ADR（WAFと同様）のトレードオフは、アプリケーションコンテキストを持たない点である。 「プロセス4821がプログラムを実行した」といった生のシステムコールは認識できるが、どのHTTPリクエストやユーザーがトリガーしたかは把握できない。このコンテキストがないため、カーネル内セキュリティは代わりにポリシー（例：「このプロセスはシェルを生成してはならない」「このコンテナはこのディレクトリに書き込みしてはならない」といったルール）に基づいて動作せざるを得ない。明らかな違反を捕捉するには有効だが、これが非常に二値的になるため、ニュアンスを捉えられない。
SQLインジェクションのようなインジェクション型攻撃に対しては、カーネル内ADRはほぼ無力である。攻撃がシステムコール層に到達する段階では、SQLペイロードはネットワークバッファ内の生バイト列に過ぎない。ランタイム攻撃もまた盲点だ。言語ランタイム内で完全に実行される攻撃もあり、手遅れになるまでOSレベルでの異常な操作を生成しない。
従来のRASPツールとは異なり、この種のADRは設定にアプリケーションコードの変更を必要としません。ただし、ADRツールは一般的に比較的新しいLinuxカーネルと昇格されたシステム特権を必要とするため、WAFやRASPよりも設定や要件が多くなります。
例：テトラゴン、ファルコ、キューブアーマー（オープンソース）
オリゴADR（商業用）
WAF、RASP、ADR、eBPF：どれが必要か？
これまで、WAF、RASP、ADR、eBPF、アプリ内、カーネル内など、多くの用語を扱ってきました。簡潔に言えば、複数のレイヤーでの保護が求められます。詳細な答えは、どのレイヤーに保護を適用するかによって異なります。RASPとADRの比較においては、RASPはADRのサブカテゴリです。したがって、重要なのは「アプリ内セキュリティ」「カーネル内セキュリティ」、あるいはその両方を求めるかということです。
各層は互いに補完し合う関係にあり、競合するものではない。なぜなら、各層が他の層では捉えられない要素を捕捉するからだ。だからこそ「WAFかRASPか？」という問いへの答えは通常「両方」であり、その上にカーネル内ADRを追加することで、ポストエクスプロイト対策とカーネルレベルのカバー範囲が得られ、全体像が完成するのだ。
三つの層は根本的に異なる問いを投げかけている：
- WAF: 「このHTTPリクエストは既知の攻撃パターンに一致しますか？」
- アプリ内セキュリティ（RASPとADR）：「このユーザー入力は、私のアプリ内の危険な関数に到達しようとしているのか？」
- カーネル内セキュリティ（ADR）：「このプロセスはOSレベルで許可されていない操作を実行したか？」
要約：まずWAFとアプリ内セキュリティツールを導入してください。特定のカーネルレベル処理が必要な場合に限り、後からeBPF対応のADRを導入してください。
RASPのようなアプリ内セキュリティは、データが特定のアプリとどのように相互作用しているかについて文脈を把握できる唯一の層であるため、真に精密なブロックを実現できる唯一の層です。 当然ながら、他の2つと比較して誤検知が最も少ない。アプリ内ランタイム保護はアプリケーションレベルやインジェクション攻撃の大半に対応できる一方、DDoSのような高ボリューム攻撃にはWAFが必要だ。WAFはアプリケーション外部に配置されるため、アプリケーションに到達してリソースに触れる前に数千のボットリクエストを処理でき、動作に大量のコンテキストを必要としない。アプリ内セキュリティ（例： Aikido Zen といったアプリ内セキュリティとWAFを組み合わせることで、遭遇する問題の大部分をカバーできます。
完全なポストエクスプロイト可視性が必要な段階、横方向の移動を懸念している場合、あるいは複数プロセスにわたるカーネルレベルでのポリシー適用が必要な場合、それがカーネル内ADRの導入を検討すべきタイミングです。これはより成熟したセキュリティ環境に適したツールですが、必ずしも最初に導入すべきものではありません。アプリ内ADRツールの中には、他よりも広範な機能を備えているものもあります。 Aikido Zen、アプリケーションが行うアウトバウンド活動（SQLクエリ、シェルコマンド、ファイル読み取り、アウトバウンドHTTP呼び出し）を監視します。より複雑なカーネル内ADR設定と比較して、チームZen 一Zen npm install そして一行のコード。
カーネル内ADRZen を超えてカバーする唯一の領域は、シェルが既に生成され攻撃者がOSレベルで動作している後のZen したがって、全プロセスにわたる完全なポストエクスプロイト可視性とカーネルレベルでのポリシー適用が必要な場合、Zen eBPFの代替Zen しかし大半のチームにとって、最も重要な攻撃対象領域（インジェクション攻撃、ゼロデイ攻撃、認可ロジック）はカバーされています。ただし、アウトバウンド活動やSQLインジェクションをカバーしない別のRASPを導入している場合、eBPFの導入が早まる可能性があります。
Zen Aikido：現代のアプリ内ADR
目標は似ているものの、すべてのアプリ内セキュリティツールが同じというわけではない。Zen（Aikidoオープンソースアプリ内ファイアウォール）のような新しいADRは、アプリ内セキュリティ領域に位置しながらも、標準的なRASPツールではカバーできない領域をカバーしている。
Zen 、従来のRASPs（アプリケーションセキュリティリソースプロバイダー）が持つ完全なアプリケーションコンテキスト（汚染トレース、シンクレベルブロック、ユーザーID認識、低い誤検知率など）Zen 。しかし、現代的なADR（アプリケーションセキュリティリソース）として、Zen カーネル内ADRと同様にZen ウンドZen 監視します。 これには、アプリケーションが実行するすべてのSQLクエリ、シェルコマンド、ファイル読み取り、およびアウトバウンドHTTP呼び出しが含まれます。その脆弱性 最初のリクエストから決定論的であるため、コールドスタート問題が発生せず、他のRASPsに見られる継続的なルールメンテナンスも不要です。
Zen インジェクションクラスの攻撃を超えたZen 提供します。Rustで構築された完全なSQLパーサーを用いて、実行時にすべてのSQLクエリを解析し、テナントスコープを自動的に強制します。 テナントフィルターが欠落しているクエリや誤ったテナントIDを使用するクエリの場合、Zen 送信前にエラーをZen 。IDOR（不安全な直接オブジェクト参照）はマルチテナントSaaSにおけるクロステナントデータ漏洩の最も一般的な原因であり、コードレビューで検出するのが非常に困難なことで知られています。Zen 、こうした問題が誤ってデプロイされることを不可能Zen 。
関連資料：ZenZenによるNode.jsのゼロデイ攻撃対策
よくある質問
WAFとは何ですか？
WAF（Webアプリケーションファイアウォール）はアプリケーションの外側に配置され、着信HTTPトラフィックを既知の攻撃パターンに対して検査します。DDoS攻撃やボットトラフィックといったボリューム型脅威の処理に特に優れていますが、リクエストに対してアプリケーションが実際に何を行うかについては可視性がありません。
RASPセキュリティとは何ですか？
RASP（ランタイムアプリケーション自己保護）は、アプリケーション内部で動作するセキュリティツールです。ユーザー入力がコード内を流れる様子を監視し、攻撃が危険となるポイントであるシンクでブロックします。アプリケーションのコンテキスト全体を把握しているため、インジェクション型攻撃に対してはWAFよりもはるかに高い精度を発揮します。
WAFとRASPの違いは何ですか？
WAFはアプリケーションの外側に配置され、パターンに基づいてトラフィックをブロックします。RASPはアプリケーション内部に配置され、ユーザー入力に対してコードが実際に実行しようとしている内容に基づいて攻撃をブロックします。WAFは導入が容易で、大量攻撃への対策に優れています。RASPは誤検知率が低く、インジェクション攻撃やゼロデイ攻撃に対する防御範囲が広いです。
WAFとRASPの両方が必要ですか？
はい、両者は競合ではなく補完関係にあります。WAFはエッジレベルの保護とボリューム型トラフィックを処理します。RASPはWAFが日常的に見逃すインジェクション型攻撃やゼロデイ攻撃を処理します。成熟したセキュリティ環境では、両方を併用するのが一般的です。
ADRとRASPの違いは何ですか？
一般的に、ADRはアプリ内またはカーネル内のセキュリティを提供するツールを包括します。RASPはアプリ内ツールを指し、ADRのサブセットです。RASPとアプリ内ADRは技術的には同じアプローチであり、時代によってラベルが異なるだけです。 ADRという呼称はより新しく、より広範な概念です。場合によっては、ADRはeBPF（カーネルベースのADRツール）の略語として、あるいは同義語として使用されることもあります。RASPとADRの用語は、誰に尋ねるかによって若干異なります。この点を念頭に置きながら、このテーマについてさらに調査を進めてください。
アプリケーションセキュリティにおけるADR/eBPFとは何か？
ADR（アプリケーション検知と対応）は、アプリケーション内とカーネル内の両方のセキュリティをカバーします。 TetragonやFalcoのようなカーネル内ARDツールはLinuxカーネルレベルで動作し、ホスト上の全プロセスにおけるあらゆるシステムコールを監視します。これらはポストエクスプロイトの可視性とカーネルレベル回避の検知に優れていますが、アプリケーションコンテキストを持たないため、RASPの代替ではなく補完的な存在です。カーネル内ADRツールを支える基盤技術がeBPF（拡張バークレーパケットフィルタ）です。
すべての入力を正しくサニタイズすれば、それでもRASPは必要ですか？
はい。常に完璧なサニタイズを実行するのは困難です。特に開発SAST コード品質ツールSAST 欠けている場合、セキュリティ上の欠陥がコードベースに潜り込む可能性があります。これは優れたセキュアコーディング手法の代替というより、それらの手法が完璧でない場合（実際には決して完璧ではないのですが）のランタイム上の安全装置と捉えるべきでしょう。RASPは依存関係に起因する問題も阻止します。
