Scribble at 2023-11-14 09:43:21 Last modified: unmodified

ウェブ・サーバのセキュリティ対策として、既に安物のレンタル・サーバですら簡単に導入できるようになった WAF (web application firewall) だが、上記のように問題はある。それは、僕も実務家の一人として承知している。しかし、いまのところは上記の記事で指摘されている各点については、アクセスの少ないサイトばかりであるからか、さほど問題を感じていない。いや、アクセスが多かったキャンペーンのサイトでも、大して問題は感じなかった。ひとまず記事で指摘されている点を一つずつご紹介しよう。

第一に、WAF はウェブ・サーバに対するリクエストを個々にスキャンするのだから、レイテンシ（処理の所用時間）が長くなるのは当然である。ウェブ・サーバで稼働するタイプの WAF なら、サーバの負荷も上がる。

WAF には大別して三つの種類、つまりアプライアンス型、ソフトウェア型、そしてクラウド型がある。アプライアンス型は FortiGate のような UTM に（名前の通り）統合されて稼働したりするし、クライアント側のネットワークにあったりする。ソフトウェア型はウェブ・サーバに実装するタイプのもので、IDS と混同されやすいが、WAF は通信の仕方というよりもリクエストというペイロードを監査するのが主眼だ。そして最後にクラウド型はルーティングや DNS 情報を変更して、いったんリクエストをクラウドのサービスに引き受けさせるという仕方で利用する。AWS なら CloudFront や Application Load Balancer などに連携させる。もちろん、僕は仕事でもプライベートでもこれら全てのタイプの WAF を使ってきて、それぞれのタイプごとにも色々な競合があるのだけれど、使い勝手はそれなりに知っている。

まず、レイテンシが伸びるとかサーバの負荷が上がるというのは、当たり前のことであって、セキュリティ対策が当たり前であるという "security by design" のポリシーでシステムを設計するのであれば、そういう負荷を最初から考慮してサーバやネットワークのスペックを選定するのが自然だろう。そのために、コーダではなく僕らのような「アーキテクト」という職能の、ソフトウェアもネットワークもデータベースも扱えて、要求開発や仕様設計もできる人材がいるのだ。

第二に、WAF こそが脆弱性を生み出すリスク要因となりえる。これも、紹介されている事例でおわかりのとおり設定が間違っていたり検査の基準が甘いと、そういうリスクがあろう。

記事の中で紹介されているアマゾンの元従業員が起こした事件では、特定の WAF の設定ミスや通信内容の特性が悪用されたわけだが、これはどういう WAF にも当てはまりうる問題だ。扱いを間違えば、セキュリティ対策は新しい弱点になってしまう。しかし、これも情報セキュリティの実務家であれば承知していることだろう。特に、AWS のように資格試験まで運用されているようなインフラ・サービスだと、資格試験の勉強をするうちに、AWS の仕様、あるいはそこでの「ベスト・プラクティス」が一般論としても客観的にベストだという思い込みに陥りやすい。しかし、これは他の分野でもシスコのルータを使う技能にすぎないネットワーク技術の資格だとか、あるいはプライバシーマークのような認証制度にすら言えることだが、所定のフレームワークの中での「正しさ」を相対化するような体系的で自律した観点とか判断の基準を持つということが「プロフェッショナル」と言いうるための一つの条件なのである。

そして第三に、WAF が偽陽性（第一種過誤）によって正当なリクエストを遮断してしまうことがあるという問題も、結局は WAF そのものの仕様とか動作原理の問題というよりも、設定や運用の技能や知識が不足していることから生じる問題にすぎないと思う。寧ろ、こういう機能を WAF の判定にフリーハンドで委ねてしまうことこそ、情報セキュリティ・マネジメントとして問題があると思う。