プロキシベースのWebアプリケーションファイアウォール（WAF）は、アプリケーション保護に不可欠な要素です。WAFはPCI-DSSへの準拠に必要なだけでなく、OWASP Top 10に挙げられるリスクからの保護にも優れています。また、シグネチャ更新を迅速にリリースすることでゼロデイ脆弱性に対処できるほか、場合によっては、長期的な解決策を導入するまでの間、プログラム可能な機能を使用してアプリケーションに仮想パッチを適用するための有力なソリューションにもなります。
では、このような保護機能をどこに配置すべきでしょうか。
もちろん、選択肢はいくつかあります。データパスには、WAFを導入できるポイントが複数存在します。しかし、どの導入ポイントを選んでもよいわけではありません。効率が劣るものもあれば、許容できない単一障害点を生じさせるものや、時間の経過とともに大きな代償を伴うアーキテクチャ上の負債を生むものもあります。
WAFは、ロードバランシング層の背後に配置するのが理想的です。これにより、利用効率、パフォーマンス、信頼性を最適化しながら、すべてのアプリ、特にインターネットに公開されているアプリに必要な保護を提供できます。
使用率
負荷分散の判断に必要なリソース（CPUなど）はごくわずかです。一般に、LBが数百万人のユーザーを同時にサポートできる一方で、WAFのリソース使用率が高くなるのはこのためです。WAFはペイロード全体を検査し、シグネチャやポリシーと照合して、リクエストが正当かつ安全かどうかを評価します。
最新のデータセンターモデルは、クラウドとその使用量ベースのコスト構造を大幅に取り入れています。そのため、リソース使用率は運用コストを左右する重要な要素となります。使用率が高まると追加のリソースが必要になり、予算を圧迫します。したがって、リソース使用率の最適化は、データセンターとパブリッククラウド環境の両方でコストを抑えるための有効な戦略です。
信頼性
WAFを水平スケーリングするのは一般的です。つまり、LBを使用してWAFをスケーリングします。このアーキテクチャ上の判断は、リソース使用率に直接関係します。多くのWAFは高いスケーラビリティを備えていますが、突発的なトラフィックや攻撃によって処理能力を超える可能性があります。WAFをLBの前段に配置する場合、WAFを個別にスケーリングするために別のLB階層が必要になります。そうしなければ、パフォーマンスと可用性に影響が及ぶおそれがあります。
パフォーマンス
パフォーマンスは、アプリケーションエコノミーにおける重要な課題です。データがデータパスを通過する間に、多数の変数やシステムがデータと相互作用するため、パフォーマンス低下の正確な原因を特定するのは容易ではありません。ましてや、ほかに影響を与えずに各要素を調整するのはさらに困難です。これまで何度も指摘されてきたように、システムの負荷が増加すると、パフォーマンスは低下します。これは、使用率を最適化していない場合に生じる意図しない結果の1つであり、経験豊富なネットワークアーキテクトがネットワークデバイスの使用率に60%というしきい値を設定する主な理由でもあります。
WAFをLB層の背後に配置すると、上流に専用のWAF負荷分散層を設ける必要がなくなり、ネットワーク層を1つ削減できます。短縮される処理時間はわずかに思えるかもしれませんが、接続の管理とWAFサービスのスケーリングを行い、さらに対象のアプリインスタンス／サーバーを選択するために同様の処理を繰り返す際の貴重な数マイクロ秒が重要です。WAFをLB層の背後に配置してこの層をなくすことで、現在のユーザーが違いを実感し、その効果を評価できるほどの貴重な数マイクロ秒を取り戻せます。
可視性
可視性は、データパス上のセキュリティソリューションにとって重要な要件です。ペイロードを含むフロー全体を検査できなければ、WAFのセキュリティ機能の多くが実質的に意味をなさなくなります。実際、悪意のあるコードの大半は、プロトコルヘッダーではなく、ペイロード内に存在します。WAFをLB層の後段に配置すると、トラフィックが検査のためにWAFへ転送される前にSSL/TLSを復号できます。ロードバランサーは、リクエストを適切にルーティングする方法を判断するため、いずれにしても暗号化されたトラフィックを可視化する必要があると考えられるため、このアーキテクチャの方が望ましいと言えます。
とはいえ、WAFはデータパス上のほぼ任意の場所に配置できます。WAFはL7のプロキシベースのセキュリティサービスであり、ネットワークパスの中継点として導入されます。必要であれば、ネットワークのエッジに配置することも可能です。ただし、パフォーマンス、信頼性、リソース使用率を同時に最適化するには、WAFをロードバランシング層の背後、つまり保護対象のアプリケーションに近い場所に配置することを推奨します。
適切なツールを使用してWAFで包括的に保護することで、リスクへの露出と運用コストを大幅に削減できます。F5のオンデマンドウェビナーでは、OWASP Top 10をはじめとする脅威からアプリを保護する方法をご紹介しています。また、F5のクラウドベースのSilverline WAFマネージドサービスなど、F5 WAF機能のさまざまな導入方法もご確認いただけます。
F5セキュリティアーキテクトのBrian McHenryと、プリンシパル脅威リサーチエバンジェリストのDavid Holmesが本記事の執筆に協力しました。2019年8月に軽微な編集を行いました。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。