マネージドサービス部 佐竹です。
サバソックに関連する案件で Advanced Rule ポリシーの WafCharm を導入することになりましたため、改めて環境構成図を紹介しますと共に、押さえておきたいポイントも記載していきます。
- はじめに
- 公式ドキュメントのご案内
- WafCharm (Advanced) の AWS 環境構成図
- WafCharm の Advanced と Legacy の違い
- マルチアカウント環境下での Advanced 実装時の注意点
- まとめ
はじめに
以前、以下に紹介します「WafCharm (Legacy) の AWS 環境構成図」のブログ記事の通り、WafCharm の AWS 環境構成図の例を紹介しました。
このブログは2020年8月10日に記述されているものであり、現在この構成は「Legacy」となっています。
また私は過去複数回、様々なお客様案件で「Legacy」の WafCharm を構築してきましたが、今回はじめて「Advanced」に触れたこともあり、大きな違いを感じました。
というわけで、今回は WafCharm の Advanced Rule ポリシーでの構成図のご紹介と、それに加えて実装に関して「押さえておきたいポイント」も記載します。
念のための補足
現在、WafCharm の設定には以下の3つのパターンが存在していますが、本ブログにおいては「3」のパターンは今回取り扱っていません。
- AWS WAF v2 × Advanced Rule ポリシー
- AWS WAF v2 × Legacy Rule ポリシー
- AWS WAF Classic × Legacy Rule ポリシー
公式ドキュメントのご案内
WafCharm の Advanced Rule ポリシーの理解には、WafCharm の公式ドキュメントを見るのがベストです。ということで、最初に WafCharm 公式ドキュメントのご案内をしておきます。
- はじめに (AWS WAF v2)
- WafCharmルールについて (AWS WAF v2)
- Advanced RuleポリシーとLegacy Ruleポリシーの違い
- WafCharmのご利用方法 (AWS WAF v2)
と言いましても、簡単に違いを知りたいという方向けに私の視点から見た概要を以下に記します。
WafCharm (Advanced) の AWS 環境構成図
最初に全体構成を紹介します。今回は都合 CloudFront 構成で記載しています。
Legacy Rule ポリシーと比べ、非常にシンプルな構成図になりました。
WafCharm (Legacy) の AWS 環境構成図
比較のため、以前のブログより Legacy Rule ポリシーでの構成図も以下に掲載します。
補足：現時点では AWS WAF は S3 バケットへの直接のログ出力に対応しているため、本構成図に掲載されている Amazon Data Firehose (旧 Amazon Kinesis Data Firehose) は必須ではなくオプションとなっています
WafCharm の Advanced と Legacy の違い
WafCharm には Advanced Rule ポリシーと Legacy Rule ポリシーの2つがあります。この2つの違いについて以下でざっと述べます。
Advanced Rule ポリシーの使用が推奨される
プランについてはここで詳しくは説明しませんが、Advanced Rule ポリシーが利用できるのは「新プラン」のみです。
そして Advanced Rule ポリシーは、Legacy Rule ポリシーに比べ、ルール設定の柔軟性、WAF ログの詳細度、カスタマイズの自由度など、多くの点で優れています 。このため、WafCharm の機能を最大限に活用するために、新プランを選択し、Advanced Rule ポリシーを使用することが推奨されます。
具体的な差は、「Advanced RuleポリシーとLegacy Ruleポリシーの違い」に詳しいですが、百聞は一見に如かずということで WafCharm のコンソールをお見せします。
上画像 がAdvanced Rule ポリシーにおけるルール設定の画面です。
比較して、Legacy の場合は、「GEO、Ratebase、Bot、正規表現」がグレーアウトしており、設定ができないようになっています。
この通り、WafCharm のコンソールから設定できる項目が複数増えており、これまで WafCharm のコンソールからできることが少なかった Legacy と比較すると Advanced で大きく機能が追加されていることがわかるでしょう。
Advanced では実装が非常に楽になっている
これは我々のような実装担当にこそ非常に嬉しいメリットなのですが、全体的に実装作業が減少しており、実装にかかる時間が短縮されます。
ログの連携と月次レポート
まずレポートです。
Legacy Rule ポリシーでは、レポートのための Lambda を含むログ転送の実装が手間のかかるものとなっていました。IAM Role の数も増えてしまい、リソースの管理も煩雑でした。
しかし、Advanced とすればWAFログ連携方式が新方式となり「WAFログをWafCharmに連携する」というチェックボックスに順にチェックを入れ、設定を有効とするだけで設定が完了します。一度でも Legacy のレポート出力設定を実装された方なら、この設定改善には驚きを隠せないのではと想像するほどです。
構成図では右下に「ログ連携」とだけ記載しておりますが、これは先の設定を表しています。
CloudFormation Stack による IAM Role の作成
権限周りは Credentials のキーペアではなく IAM Role で管理できる上に、その IAM Role の実装も WafCharm のコンソールから簡単に実行できる CloudFormation Stack で実装できるようになっています。
またこの IAM Role に付与される権限（IAM ポリシー）は以下の通りです。
- AmazonS3ReadOnlyAccess
- AWSWAFFullAccess
- CloudWatchReadOnlyAccess
設定が楽な反面、これらのポリシーの付与は、場合によっては少々権限が強い傾向にあります。
特に AmazonS3ReadOnlyAccess が不適切な場合が多いと想像します。そのような場合には、本ポリシーを適切な権限に修正されると良いでしょう*1。例えば、特定の aws-waf-logs- プレフィックスを持つ S3 バケットのみにアクセスを限定するなどの修正が考えられます。
付け加えると Legacy Rule ポリシーとは異なり、Advanced Rule ポリシーでは1つの IAM Role (WafCharm でいうところの Credential) があれば良く、AWS WAF のログのみを分析し、月次レポートへもそれを利用するという設計になっています。
マルチアカウント環境下での Advanced 実装時の注意点
ではここから、Advanced Rule ポリシーを採用した場合の実装時の注意点（ポイント）を記載します。
AWS WAF のログ出力は S3 バケットへの直接出力にのみ対応
上図の通り AWS WAF のログ出力先として「S3 バケットへの直接出力」を採用し実装していますが、これは Advanced Rule ポリシーの実装における前提となっております。
Advancedの場合、S3バケットへ直接出力してください。
https://console.wafcharm.com/en/help/configuring_waf_logs_aws_v2_advanced_ja
引用の通り、これは WafCharm 公式ドキュメントにも記載のある仕様となっております。
ウェブ ACL トラフィックログを Amazon S3 に送信するには、ウェブ ACL を管理するのと同じアカウントから Amazon S3 バケットを設定し、バケットに
aws-waf-logs-で始まる名前を付けます。https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/logging-s3.html
なお、AWS WAF を直接 S3 バケットへ出力する場合はバケットに aws-waf-logs- で始まる名前を付けなければならない点に注意してください。
ガイドライン等の命名規則がある場合に、規定の命名規則が順守できるかは要検討です*2。
一元化されたログアカウントへのログ集約をどう実装するか
WafCharm サポートに確認したところ、現時点で WafCharm Advanced Rule ポリシーでは「AWS WAF の Web ACL と S3 バケットは同アカウント内に存在していることが前提となっている」とのことです。
よって、上記 re:Post の記事のように「一元化されたログアカウントの Amazon S3 バケットに AWS WAF ログを送信する」といった構成には WafCharm (Advanced) 側が対応しておりません*3。
ログ保管専用のアカウントがあり、そこに「aws-waf-logs-central-bucket」を作成・集約しようとしていたとしても、そのような構成では WafCharm (Advanced) がログを分析できないため、直接出力を断念せざるを得ないでしょう。
このような構成での回避策としては、AWS WAF から同アカウントの S3 バケット aws-waf-logs-for-wafcharm に直接出力されたログを、何らかの方法で aws-waf-logs-central-bucket へと複製（コピー）する回避策があげられます。
具体的な機能名としては「S3 クロスアカウントレプリケーション」を設定することや「s3 sync」を必要なタイミングで実行するなどがあげられます。
特に AWS Organizations や AWS Control Tower で管理されているマルチアカウント環境をご利用されている場合、ログの集約・保管に関する独自のガイドラインが厳格に運用されている可能性があります。WafCharm (Advanced) を導入する前に、関連するガイドラインを確認し、本記事で解説したログ出力の仕様（※同一アカウント内 S3 バケットへのログ直接出力）と整合性が取れるか、要件として確認・検討される方が良いでしょう。
まとめ
本記事では、WafCharm Advanced Rule ポリシーの AWS 環境における構成と実装に焦点を当て、Advanced の環境構成図を具体的に示しました。
また従来の Legacy Rule ポリシーとの違いを明確にしながら、実装を成功させるために押さえておきたい重要なポイントを解説しました。
再掲となりますが、本構成図が WafCharm Advanced Rule ポリシーの AWS 環境構成図（例）です。
また以下の2点は十分に注意して設計＆実装ください。
- AWS WAF のログ出力は Web ACL と同一アカウントの S3 バケットへの直接出力にのみ対応している点
- その前提で、マルチアカウント環境下において、ログ保管アカウントへのログ集約をどう実装するか
本ブログが AWS WAF と WafCharm 実装の手助けになれば幸いです。
では、またお会いしましょう。
*1:我々も WafCharm 実装時にはこの権限をより弱い権限へと置き換え、実装する場合があります。これは S3 バケットに存在する他のオブジェクトが get されることを防ぐためです
*2:Amazon Data Firehose であれば S3 バケットの命名規則がなく、どのようなバケットにも出力できました
*3:あくまで、WafCharm (Advanced) 側の仕様であり、AWS WAF 自体は re:Post の記事の通り実装が可能です
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
セキュリティサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。
