アプリケーションファイアウォールについて語られる際、多くの異なるものが一括りにされる傾向があります。しかし、すべてのファイアウォールが同じではなく、それらの違いを理解することは重要です。特に、アプリケーションが実際にどのような保護を必要としているのかを把握しようとしている場合には。
では、詳しく見ていきましょう。知っておくべきアプリケーションセキュリティの主要な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 Application Firewall) は、アプリケーションの外部、エッジに配置されます。リクエストがアプリケーションに到達する前に、WAFがそれを傍受し、SQLインジェクション文字列、悪意のあるヘッダー、疑わしいURLなどの既知の攻撃パターンリストと照合してチェックします。いずれかのパターンに一致した場合、ブロックされます。
WAFが真に不可欠となるのは、DDoSトラフィック、ボットフラッド、スクレイパーなどの大量攻撃です。WAFは、大量かつブルートフォース的な攻撃に対応するために構築されています。例えばCloudflareは、大規模な攻撃がインフラストラクチャとやり取りする前に吸収することに非常に優れています。また、デプロイも簡単です。ほとんどの場合、DNSまたはプロキシの変更のみで、コードを記述したり、アプリケーション内に何もインストールしたりする必要はありません。WAFは、カスタムルール、許可リスト、ルールチューニングにより非常に柔軟に設定でき、不審なものをブロックするか、検出するだけにするかを決定することもできます。
問題は、リクエストがWAFを通過した後に何が起こるかをWAFが把握できないことです。疑わしいペイロードを検出することはできますが、アプリケーションがそのリクエストで実際に何をするかを知らないため、そのペイロードが実際に危険なことをするかどうかを判断することはできません。WAFは、受信トラフィックを監視し、停止するように設定されたパターンと照合し、ブロックするかどうかを決定します。
その結果、誤検知は深刻な問題であり、リクエストを過剰にブロックしてしまう可能性があります。ユーザーがSQLのように見えるものを検索してブロックされる一方で、巧妙な攻撃者はペイロードを異なる方法でエンコードして通過させることができます。また、WAFが悪意のあるユーザーを停止させたい場合、そのIPをブロックします。しかし、攻撃者はVPNを使用してそれを回避できます。その後、VPNからのすべてのトラフィックをブロックしようとすると、正規のユーザーもブロックしてしまいます。
その結果、WAFのチューニングは、ルールを厳しくし、誤検知を監視し、必要に応じて緩めるという継続的なプロセスになります。これは、WAFがRASPと比較してメンテナンスに手間がかかる理由の1つです。RASPは、手動介入なしにより良い決定を下すためのアプリケーションコンテキストを持つため、継続的なチューニングがはるかに少なくて済みます。
例: Cloudflare, AWS WAF, Imperva
オープンソース: ModSecurity (OWASP経由)
RASPとは？
RASP (Runtime Application Self-Protection) およびアプリ内ADRは、WAFのようにアプリケーションの外部に配置されて受信トラフィックを検査するのではなく、アプリケーションの内部に存在し、実行中に内部から監視するランタイムセキュリティです。
これがなぜ重要なのかを理解するには、「シンク」について知る必要があります。シンクとは、コード、ライブラリ、または組み込みモジュール内の関数であり、ユーザー入力がデータであることをやめ、意味のあるものとして実行される場所です。SQLインジェクションを例に見てみましょう。攻撃者はフォームフィールドに悪意のあるコードを挿入し、それがアプリケーションを流れ、データベースドライバーに到達します（一部の db.query()）、その時点でテキストではなくコマンドになります。そのクエリ関数がシンクです。RASPのようなアプリ内セキュリティツールは、これらのシンクにフックし、入力がアプリケーション内を移動するのを監視し、危険な関数まで追跡します。
これらのアプリ内ツールはアプリケーションの内部で実行されるため、入力が何であるか、どこから来たか、どこへ向かうかを知っています。～かどうかを推測するのではなく、 ' OR 1=1-- 攻撃なのか、正当な検索文字列なのかを判断する際、アプリ内ツールは、この特定の文字列がどこから来たかを知っています。 req.body.user、サニタイズされずに連結され、 pg.query() 呼び出しに到達しようとしています。ブロックします！
誤検知率はWAFやeBPFベースのADRよりもはるかに低いです。これは、単にパターンマッチングを盲目的に行うだけではないためです。IPアドレスだけでなくユーザーIDをブロックできるため、攻撃者がVPNを使用するだけでは回避できません。また、既知のシグネチャに一致させるのではなく、データフローを追跡するため、これまで誰も見たことのない新しい攻撃ペイロードを捕捉できます。インジェクションクラスの攻撃に対して堅牢なゼロデイカバレッジを提供します！
RASPとインアプリADRは、サードパーティの依存関係もカバーします。自社のコードを完璧にサニタイズできたとしても、使用しているライブラリに脆弱性がある場合（SCAスキャナーでも捕捉できなかった場合）、それは制御できません。RASPは、コードの出所に関わらずシンクレベルで動作します。
インアプリセキュリティの主な制限の1つは、攻撃者がネイティブアドオンや直接的なシステムコールを通じてランタイムを完全にバイパスした場合、フックが起動しないことです。また、シェルが生成されると、RASPは最初の呼び出しは認識しますが、そのシェル内でその後何が起こるかは認識しません。ここで第3のレイヤーが登場します。
例：Aikido Zen （オープンソースと有償版）
ADRとは何ですか？
ADR（Application Detection and Response）は、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を使用すると、カーネル自体に触れることなく、OSレベルで発生する特定のイベントを監視できる安全な監視プログラムをLinuxカーネルにアタッチできます。通常、カーネルレベルでカスタム監視やロジックを追加したい場合、カーネルのソースコードを直接変更するか（リスクが高く、複雑）、カーネルモジュールを記述する（バグがシステム全体をクラッシュさせる可能性があるため、これもリスクが高い）必要がありました。eBPFは、サンドボックス化された環境で実行される小さなプログラムをカーネルに注入することで、この問題を回避します。これらのプログラムは特定のシステムコールを監視し、ADRツールに報告します。ADRツールはその後、そのアクションを許可するかブロックするかを決定します。
WAFと同様に、カーネル内ADRのトレードオフは、アプリケーションコンテキストがないことです。「プロセス4821がプログラムを実行した」といった生のシステムコールは認識しますが、どのHTTPリクエストやユーザーがそれをトリガーしたかはわかりません。そのコンテキストがないため、カーネル内セキュリティは代わりにポリシーに基づいて動作する必要があります。これは、「このプロセスはシェルを生成してはならない」や「このコンテナはこのディレクトリに書き込んではならない」といったルールです。これは明確な違反を捕捉するのには役立ちますが、非常に二元的であるため、ニュアンスがありません。
SQLインジェクションのようなインジェクションクラスの攻撃に対して、カーネル内ADRはほとんど盲目です。攻撃がシステムコール層に到達する頃には、SQLペイロードはネットワークバッファ内の単なる生バイトです。ランタイム内のエクスプロイトも別の盲点です。一部の攻撃は言語ランタイム内で完全に実行されるため、手遅れになるまで異常なOSレベルの操作を生成することはありません。
従来のRASPツールとは異なり、このタイプのADRはセットアップのためにアプリケーションコードの変更を必要としません。しかし、ADRツールは一般的に比較的新しいLinuxカーネルと昇格されたシステム権限を必要とするため、WAFやRASPよりも多くのセットアップと要件があります。
例：Tetragon, Falco, KubeArmor（オープンソース）
Oligo ADR（商用）
WAF、RASP、ADR、eBPF：どれが必要ですか？
これまでに、WAF、RASP、ADR、eBPF、インアプリ、インカーネルといった多くの用語を説明してきました。簡潔に言えば、複数のレイヤーでの保護が必要だということです。より詳細な答えは、どのレイヤーかによって異なります。RASPとADRに関して言えば、RASPはADRのサブカテゴリであるため、問題はインアプリセキュリティ、カーネル内セキュリティ、あるいはその両方が必要かどうかになります。
異なるレイヤーは競合するものではなく、補完し合うものです。なぜなら、それぞれが他のレイヤーでは捕捉できないものを捉えるからです。だからこそ、「WAFかRASPか？」という問いに対する答えは通常「両方」であり、さらにカーネル内ADRを追加することで、エクスプロイト後およびカーネルレベルのカバレッジが補完されます。
これら3つのレイヤーは、根本的に異なる問いを投げかけます：
- 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を単一の npm install と1行のコードで設定できます。
インカーネルADRがZenを超えてカバーする唯一の点は、シェルがすでに生成され、攻撃者がOSレベルで操作している場合に何が起こるかです。したがって、完全なポストエクスプロイトの可視性とすべてのプロセスにわたるカーネルレベルのポリシー適用が必要な場合、ZenはeBPFの代わりにはなりませんが、ほとんどのチームにとって、最も重要な攻撃対象領域（インジェクション攻撃、ゼロデイ、認証ロジック）をカバーします。ただし、アウトバウンドアクティビティやSQLインジェクションをカバーしない別のRASPを使用している場合は、より早くeBPFが必要になる可能性があります。
AikidoのZen：最新のインアプリADR
目的は似ていますが、すべてのインアプリセキュリティツールが同じではありません。AikidoのオープンソースインアプリファイアウォールであるZenのような新しいADRは、インアプリセキュリティの領域に位置しますが、標準的なRASPツールではカバーできない範囲をカバーします。
Zenは、テイントトレース、シンクレベルブロッキング、ユーザーID認識、低誤検知など、従来のRASPの完全なアプリケーションコンテキストを提供しますが、最新のADRとして、インカーネルADRと同様にアウトバウンドアクティビティも監視します。これには、アプリケーションが行うすべてのSQLクエリ、シェルコマンド、ファイル読み取り、およびアウトバウンドHTTPコールが含まれます。その脆弱性アルゴリズムは最初のリクエストから決定論的であるため、コールドスタートの問題や、他のRASPにあるような継続的なルールメンテナンスは必要ありません。
Zenはインジェクションクラスの攻撃も超えて対応します。フルSQLパーサー（Rustで構築）を使用して実行時にすべてのSQLクエリを解析し、テナントスコープを自動的に適用します。クエリにテナントフィルターが欠けているか、誤ったテナントIDを使用している場合、Zenは出荷前にエラーをスローします。IDOR（不安全な直接オブジェクト参照）は、マルチテナントSaaSにおけるテナント間のデータ漏洩の最も一般的な原因であり、コードレビューで発見するのが非常に困難です。Zenは、それらが誤ってデプロイされるのを不可能にします。
参考文献: Aikido ZenによるNode.jsのゼロデイ攻撃防止
よくある質問
WAFとは何ですか？
WAF（Web Application Firewall）はアプリケーションの外部に位置し、既知の攻撃パターンについて受信HTTPトラフィックを検査します。DDoS攻撃やボットトラフィックのような大量の脅威の処理に特に優れていますが、アプリケーションがリクエストで実際に何をするかについては可視性がありません。
RASPセキュリティとは何ですか？
RASP（Runtime Application Self-Protection）は、アプリケーション内で動作するセキュリティツールです。ユーザー入力がコードをどのように流れるかを監視し、危険になるポイントであるシンクで攻撃をブロックします。完全なアプリケーションコンテキストを持つため、インジェクションクラスの攻撃に対しては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（Application Detection and Response）は、インアプリセキュリティとインカーネルセキュリティの両方をカバーします。TetragonやFalcoのようなインカーネルADRツールは、Linuxカーネルレベルで動作し、ホスト上のすべてのプロセスにわたるすべてのシステムコールを監視します。これらはポストエクスプロイトの可視性とカーネルレベルのバイパスの捕捉に優れていますが、アプリケーションコンテキストを持たないため、RASPの代替ではなく補完的な関係にあります。eBPF（Extended Berkeley Packet Filter）は、インカーネルADRツールを支える基盤となるカーネルテクノロジーです。
すべての入力を正しくサニタイズした場合でも、RASPはまだ必要ですか？
はい、サニタイズを常に完璧に行うことは困難です。特に開発中にSASTやコード品質ツールが導入されていない場合、セキュリティ上の脆弱性がコードベースに紛れ込む可能性があります。これは、優れたセキュアコーディングプラクティスの代替と考えるのではなく、それらのプラクティスが完璧ではない（実際には常に完璧ではない）場合のランタイムバックストップとして捉えるべきです。RASPは、サードパーティの依存関係に起因する問題も阻止します。
