デジタルイノベーションラボのIです。 今回はクオカードペイシステムのAWS WAFをClassicからv2へ移行した件について書こうと思います。
背景
クオカードペイではインフラにAWSを使用しており、外部に公開しているALBにはWAF Classicを適用していました。その名の通りこのWAFは旧世代扱いで、現在ではWAF(v2)の使用が推奨されています。
※ 正確には旧世代のWAFは「AWS WAF Classic」、現世代のWAFは「AWS WAF」という名称なのですが、わかりやすく区別するためにこのエントリでは現世代のWAFをAWSのAPIのように「v2」と呼ぶことにします。
botからのアクセスを弾くために、WAF bot controlを使いたいというのが移行を考え始めた直接のきっかけでしたが、更にカスタムレスポンス機能だったり、Log4jの脆弱性に対応したマネージドルールだったり、v2にしかない機能を使いたいというケースが増えてきました。
また今後もWAFの新機能はv2でしか実装されないと思われるため、このままClassicを使用していてはその恩恵も受けられません。
このような経緯でv2への移行を決めました。
移行方法
Classicからv2への移行にはAWS公式の手段が存在します。
—------------------------------------------------------------------------------------------------------------------------
1.自動移行では、既存のウェブ ACL に関連するすべての内容が読み込まれます。AWS WAF Classic で変更または削除される内容はありません。ウェブ ACL とその関連リソースの表現を作成します。この表現は、AWS WAF と互換性があります。新しいウェブ ACL の AWS CloudFormation テンプレートを生成し、Amazon S3 バケットに保存します。
2.AWS WAF でウェブ ACL および関連リソースを再作成するために、テンプレートを AWS CloudFormation にデプロイします。
3.ウェブ ACL を確認して手動で移行を完了し、新しいウェブ ACL が最新の AWS WAF の機能を最大限に活用するようにします
4.保護されたリソースを新しいウェブ ACL に手動で切り替えます。
—------------------------------------------------------------------------------------------------------------------------
上記引用の通り、既存のClassic ACLの各種設定をもとに、新規でv2 ACLを作成するCloudFormation stackがデプロイされます。
検証環境で一度実際に試してみた結果、主に以下の理由からこの方法は採用しないことにしました。
- 結局手動での追加作業が必要な部分が多い
- 新しく作成されるv2 ACLの名前を指定できない(どうやら、「<移行元Classic ACL名>+<自動で付与されるuuid>」となる様子)
- そもそもクオカードペイのAWS環境は基本的にTerraformで管理しているため、できるだけCloudFormationでのリソース管理は避けたい
よって、完全に一からv2関連リソースを新規作成することにしました。
ルール設定
移行前のClassicではAWS Marketplaceの「Fortinet Managed Rules for AWS WAF Classic - Complete OWASP Top 10」を利用していました。
v2ではそれに代えて、AWS標準のマネージドルールグループを使うことにしました。WCUを1500以内に収める必要があるため、以下のマネージドルールをACLに追加しました。
—-------------------------------------------------------------------- AWSManagedRulesCommonRuleSet AWSManagedRulesKnownBadInputsRuleSet AWSManagedRulesSQLiRuleSet AWS-AWSManagedRulesLinuxRuleSet AWS-AWSManagedRulesUnixRuleSet AWS-AWSManagedRulesAmazonIpReputationList AWSManagedRulesBotControlRuleSet 計1475WCU —--------------------------------------------------------------------
また、IPセットも使用してIPアドレスでの制御も実施しました。これはClassicと大差ありません。
チューニング
AWS標準のマネージドルールは特にブラックボックス的なので、実際の動作をみながらのルールのチューニングが必須です。
まずは検証環境に適用し、また本番環境でもルールのアクションを最初はCount状態にして動作確認・ログ分析をしました。WAFのログ出力先はいくつか選択肢がありますが、今回は直接S3に出力してAthenaで分析することにしました。
確認の大きな観点は以下の2点です。
WAFに期待しているのは当然前者の機能ですが、ある意味後者の確認のほうがより重要だと思います。正常なユーザアクセスに影響があっては本末転倒です。(実際、検証が不十分でトラブルを起こしてしまいました...)
ブロックの原因となっていたルールをログから特定し、ルールグループから除外しました。
まとめと今後の展望
以上、大まかではありますがWAFの移行に関して実施したことを記載しました。 そもそも移行元のWAF Classicのほうでも沢山のルール設定はしておらず、移行すべきものは少なかったため、実質一から構築したものの作業量はそれほど大きくはなりませんでした。もし複雑なルールを多数設定していたら移行ももっと大変だったと思います。
今後についてですが、現在は正常なリクエストが引っ掛かったルールはルールグループから単純に除外しているのみですが、特にWAF Bot Controlに関してはより細かい制御ができるので時機を見てチューニングをしていきたいです。
