この記事は 【ReviCo】 Advent Calendar 2025 の 2日目 の記事です。
昨日はkamuriさんの「初めての複数チーム体制の開発にしたことで得られたこと」でした！
はじめに
こんにちは！ReviCoでエンジニアをしているむーたです。
今回は 「私がWAF大臣と呼ばれるようになるまで」 ということでAWS WAF ClassicをAWS WAFv2へ移行していたらWAF大臣となっていたことを記事にしたいと思います！
WAFについて
そもそもWAFとはなんでしょうか。
下記にAWS公式ドキュメントより抜粋したものを記載します。
WAF（Web アプリケーションファイアウォール）とは、Web アプリケーションの通信をフィルター、監視、ブロックするためのソフトウェアまたは、ハードウェアのセキュリティ対策です。WAF の代表的な用途には、SQL インジェクション、クロスサイトスクリプティングなど、アプリケーションの脆弱性を悪用した攻撃の遮断やアプリケーション層の DDoS 対策、不正なボットによるアクセスの遮断などがあります。
つまり、いわゆるIP・ポート・プロトコルのようなL3/L4層を見るファイアウォールに対して、HTTPリクエストのようなL7層を見るファイアウォールということです。
AWSではこのWAFをマネージドサービスとして提供してくれています。
なぜ移行するのか
これまでもReviCoではAWS WAFを利用していましたが、AWS WAF Classicというものを利用していました。
しかし、2025年9月末でAWS WAF Classicのサポートが終了してしまい、それ以降は2019年11月にリリースされたAWS WAF v2への移行が必要となりました。
したがって、ReviCoでも移行しなければ・・となりました。
どのように進めたか
AWS WAFv2移行作業の担当になった私は当初、WAF・AWS WAFに関する知識が全くなかったためキャッチアップから始まりました。
しかし、WAF関連のドキュメントや技術記事はすでに十分世の中にあったことや、生成AIと対話しながら進めることであまり苦労せず進めることができました。
一番の問題は、個々のルールに対してどこまで緩和するのかというところでした。
AWS WAFでは、マネージドルールというAWSが用意してくれているお手軽WAFルールセットのようなものがあります。
AWS Classicを利用していたときは、Marketplaceから提供されるセキュリティベンダーのマネージドルールを利用していましたが、これはAWS WAFv2で利用するAWS独自のマネージドルールと完全に互換性があるものではありません。
したがって、AWS WAF Classicで利用していたマネージドルールをそのままAWS WAFv2に適用！みたいなことができませんでした。
色々と悩みましたが、こちらから全てのリクエストに対してどれがどのルールに抵触してブロックされるかを完全に予測するのは不可能なので、テスト環境・ステージング環境でルール適用後にある程度泳がせて、その過程で本来通したいリクエストなのにブロックされているものがあれば、適宜該当ルールを緩和する方針としました。
今回はWAF大臣と呼ばれるようになるまでという話なので、一番の問題を「個々のルールをどこまで緩和するか」としていますが、移行に当たって全面的にCloudFormationでIaC化するほうが辛かったかもしれません・・（笑）
403の波
先ほど記載したように、テスト環境・ステージング環境でAWS WAFv2を適用して泳がせていましたが、案の定403 Forbiddenがそこそこの頻度で起きました。
基本的な対応としては、「WAFのせいでブロックされちゃってるかも！」と声をかけてもらったら、随時私が対応するという形を取っていました。
しかし、カスタマーサポートなどの技術畑ではない人からしたらWAFとはなんのこっちゃという話で、社内のTeamsで「これ動かないです！」と会話しているところに首を突っ込んでいって、「これはWAFですね・・」と不意に現れて対応することもありました。
ですので、WAF移行期間は社内のTeams全体をいつもより見ていた気がします（笑）
このように色々なWAF対応をおこなうことを通じて、WAFのことはむーたに聞こうという流れができました。
WAF大臣と呼ばれるようになったのはここが一番大きいですね。
さいごに
こうして晴れてWAF大臣となることができました。
↑かなっぺさんが生成AIで作ってくれたWAF大臣の図
明日はかなっぺさんの「ReviCoサポートチームのチームビルティング」です！
お楽しみに！