こんにちは！インフラやセキュリティの世界へようこそ。
初めてサーバーの要塞化やWAF（Webアプリケーションファイアウォール）の話を聞くと、「なんだか難しそう…」「専門用語ばかりで自分には無理かも…」なんて尻込みしてしまいますよね。
でも、安心してください。セキュリティの基本は、私たちが普段暮らしている「家の防犯」と全く同じなんです。一歩ずつ、身近な例えから紐解いていけば、誰でも必ず理解できるようになりますよ。
今回は、Webサイトの門番である「WAF」が、どのように悪者（サイバー攻撃）を見張り、どうやって正当なお客さん（正規のトラフィック）を守っているのか、その裏側の泥臭くてリアルな仕組みを一緒に見ていきましょう！
—
1. 家の鍵と泥棒に例える「WAF（Webアプリケーションファイアウォール）」の正体
皆さんは、自分の家を出るときに鍵をかけますよね。では、その「鍵」とは一体何を防いでいるでしょうか？ そう、空き巣や泥棒の侵入ですよね。
インターネットの世界にあるWebサイトも同じです。インターネットに繋がっているということは、世界中どこからでもあなたの「お家」の玄関が見えている状態になります。ここで、従来のファイアウォール（ネットワークの門番）は、いわば「頑丈な門や玄関のドア」のようなものです。怪しいやつは通さない、という大雑把なブロックをしてくれます。
しかし、泥棒の中には、玄関のドアを無理やりこじ開けるのではなく、「郵便受けから巧みに手を突っ込んで内側の鍵を開ける」ような、巧妙な手口を使うやつもいます。これがWebアプリケーションの脆弱性を突く攻撃、つまり SQLインジェクション（SQLi） や クロスサイトスクリプティング（XSS） です。
ここで登場するのが WAF（Webアプリケーションファイアウォール） です。WAFは、いわば「家の中にいる超優秀な警備員」です。お客さんが玄関から入ってきた後、その人が喋る言葉や持ち込もうとしている荷物を一つひとつチェックし、「おい、その荷物の中身、危ないものが入っているぞ！」とその場で取り押さえてくれるのです。
—
2. 攻撃者が仕掛ける悪意の手口：SQLi と XSS を優しく解説
警備員（WAF）がどんなものを取り締まっているのか、代表的な2つの攻撃を覗いてみましょう。
データベースを乗っ取る「SQLインジェクション（SQLi）」
例えば、会員制サイトのログイン画面を想像してください。「ユーザー名」を入力する欄がありますよね。
通常、ここに私たちは yamada のような名前を入力します。
しかし、もし攻撃者がここに次のような特殊な言葉（文字列）を入力してきたらどうでしょう？
' OR '1'='1データベースの裏側では、「このユーザー名が存在するかどうか」を調べるために、SQLという専用の命令文を組み立てています。もし、入力された文字をそのままデータベースに渡してしまうと、裏側の命令文が次のように書き換わってしまいます。
「ユーザー名が入力された値、または『1=1（常に正しい）』なら、全員のパスワードデータを渡しなさい！」
結果として、パスワードなどの機密データが丸見えになってしまいます。これがSQLインジェクションという攻撃です。警備員であるWAFは、入力欄に ' や OR といった、データベースをハッキングするための怪しいキーワード（シグネチャ）が含まれていないかを常に監視しています。
画面を乗っ取る「クロスサイトスクリプティング（XSS）」
次にXSSです。これは、掲示板やお問い合わせフォームのコメント欄などに、悪意のあるプログラム（JavaScriptなど）を書き込む攻撃です。
例えば、コメント欄にこんなコードを書き込まれたとします。
<script>alert('あなたのパスワードを盗みました！');</script>もし、この書き込みを対策せずにそのままWebサイトに表示してしまうと、他の人がそのページを見た瞬間に、その人のブラウザ上でこの怪しいプログラムが勝手に実行されてしまいます。結果として、クッキー（ログイン情報）が盗まれたり、悪意のあるサイトへ強制的に飛ばされたりしてしまいます。
WAFは、こうした <script> といった危険なHTMLタグが送信されてくると、「危ない！」と検知してブロックしてくれます。
—
3. シグネチャベース防御の「悩みどころ」：誤検知（False Positive）との戦い
「じゃあ、WAFを導入すれば、怪しい文字を全部シャットアウトしてくれて完璧だね！」……と言いたいところですが、実務の世界はそう甘くありません。ここからがインエンジニアの腕の見せどころ、泥臭いチューニングの話になります。
WAFは、あらかじめ登録された「攻撃のパターン集（シグネチャ）」と照らし合わせて怪しいかどうかを判断します。しかし、このシグネチャが真面目すぎるがああまりに、大切なお客さんまで追い払ってしまうことがあるのです。これをセキュリティの用語で「誤検知（フォールス・ポジティブ）」と呼びます。
リアルな誤検知の現場
例えば、あなたの会社が運営するブログサイトで、あるユーザーが次のような記事を投稿しようとしました。
> 「今日はデータベースの勉強会でした。SQLの SELECT 文や OR 条件の使い方について学びました。」
この文章、開発者やエンジニアにとってはなんてことのない日常の技術ブログの一節ですよね。
しかし、WAFのシグネチャの目から見ると、こう映ります。
- 「おっ、『
SELECT』って書いてあるぞ！」 - 「おっ、『
OR』っていう怪しいキーワードが入っているぞ！」
結果、WAFは「これはSQLインジェクションの攻撃だ！」と勘違いし、一般ユーザーの正常な投稿をバッサリと遮断（403 Forbiddenなど）してしまうのです。これが、現場のインフラ担当者を悩ませる誤検知の正体です。
—
4. 実務で役立つ！例外設定（チューニング）の具体的なアプローチ
正規のユーザーを追い払わず、かつ攻撃だけをしっかり防ぐためには、WAFの「例外設定（チューニング）」を行う必要があります。ここからは、実務で使える具体的な考え方と、設定のサンプルを見ていきましょう。
チューニングの基本ステップ
1. ログの分析（監査モードの活用）: 最初から完全にブロック（ブロックモード）するのではなく、怪しい通信を記録するだけ（検知・ログモード）の状態で動かし、どこで誤検知が起きているかを徹底的に調べます。
2. 影響範囲の特定: 誤検知しているリクエストが「どのURL（パス）」へのもので、「どのパラメータ」に反応しているのかを特定します。
3. 適切な例外ルールの適用: 全体の防御力を下げるのではなく、「この特定のページで、この特定のパラメータに限り、このルール（シグネチャID）のチェックをバイパス（除外）する」というピンポイントな例外設定を行います。
例外設定のイメージ（疑似コード・設定サンプル）
一般的なWAF（クラウド型WAFやModSecurityなどのオープンソースWAF）では、次のような形式で特定のルールを特定のURLパスに対して除外・緩和します。
{
"rule_exclusion_config": {
"target_path": "/blog/articles/create",
"ignored_parameters": ["article_body"],
"bypassed_signatures": [
"942100",
"942120"
],
"comment": "社内ブログ機能の投稿フォームにおいて、SQL関連の技術用語が含まれる正常な記事投稿が誤検知されるため、該当シグネチャの検査を一部除外する。"
}
}この設定では、/blog/articles/create というURLへのリクエストのうち、記事の本文が入る article_body というパラメータに対してのみ、SQLインジェクションを検知する特定のルール（例: ルールID 942100 や 942120）の適用を一時的に除外しています。これにより、技術ブログとしての正常な投稿を受け付けつつ、ログイン画面など他の重要な場所では引き続き厳重にSQLiを防御することが可能になります。
—
5. まとめ：セキュリティに「完璧」はない。だからこそ対話と改善を続けよう
いかがでしたでしょうか？
WAFの導入とチューニングは、頑丈な鍵をかけることだけでなく、「自分たちのお客さん（正規ユーザー）の顔」をしっかりと理解し、警備員（WAF）と人間（開発者・インフラエンジニア）の間で絶妙なバランスを取っていく泥臭い作業です。
新人のうちは、アラートが出るたびにドキッとしてしまうかもしれません。「私の書いたコードが悪いのかな？」と不安になることもあるでしょう。でも大丈夫です。セキュリティは一度設定したら終わりではなく、日々のトラフィックを観察し、誤検知を一つずつ丁寧に潰していく「終わりなき育成ゲーム」のようなものです。
一歩ずつ、焦らずに。あなたの手で、安全で快適なWebの世界を作っていきましょう！応援しています。
コメント