自社WebサーバにAWS WAFを適用しました(1) ～構成編～

ホーム
AWS/Azure, 実践記事
自社WebサーバにAWS WAFを適用しました(1) ～構成編～

2024.06.14

この記事は投稿日から1年以上経過しています。

こんにちは。
タイトルの通り、自社WebサーバにAWS WAFを適用して、
正常に稼働していることが確認できた頃合いだったので、
社内への技術的な共有も兼ねて寄稿することにしました。
全5回以下のような構成となります。

きっかけ

過去に弊社のWebサーバへDoSと思われるアタックやBotと思しきリクエストがありました。
重要な情報はWebサーバにはアップロードしていないものの、外部のお客様からのお問い合わせなどもあり、
攻撃を受けてのサーバのダウンなどは避けたいため、本件対応することになりました。

AWS WAF適用にあたっての構成

旧構成は以下のように、EC2インスタンスをそのまま外部に公開していました。
※イメージとなります。

新構成は以下のようになっています。

構成についての解説

Application Load Balancerについて
L7レベルで機能するLoad Balancerです。
AWS WAFを適用するほか、トラフィックの復号をするために必要です。
Application Load Balancer 配下のサーバが1台しかありませんが、
これはデータの同期方法などを理由に負荷分散ができる見込みがはっきりと立たなかったほか、
今回の目的より特段その必要性がないと思ったので、負荷分散はしていません。
（※CloudFrontをALBの外側に立てることも考えていましたが、
収まりがつかない可能性があったため、やめました。）サーバへの影響を考えると、TLS終端をしないで、再暗号化する選択肢もあったのですが、
証明書の管理がAWS Certificate Manager(ACM)とサーバの二重で必要になるほか、
サーバの負荷も軽減したいという狙いもあったため、終端することにしました。
AWS Certificate Managerについて
証明書の管理をするためのサービスです。HTTPS通信を復号するために、
それに必要なサーバ証明書と秘密鍵、中間証明書をインポートします。
ACMにインポートした証明書をALBに適用することで、復号できるようになります。
Amazon S3
オブジェクトストレージサービスです。
Application Load BalancerのログはS3に飛ばすことしかできないため利用します。
Amazon CloudWatch
説明が難しいので、公式の文章を引用します。
（以下引用）
Amazon CloudWatch は、アプリケーションを監視し、パフォーマンスの変化に応答し、
リソースの使用を最適化し、運用状態に関するインサイトを提供するサービスです。
AWS リソース全体でデータを収集することで、CloudWatch はシステム全体のパフォーマンスを可視化し、ユーザーはアラームを設定したり、変更に自動的に対応したり、運用状態を一元的に把握したりできます。

CloudWatchを利用すると、サービスの統計情報を活用することが可能になりますが、
今回はCloudWatchのログ収集機能を利用します。
AWS WAFのログを取得するために使用します。
Lambda
コード実行ができるサービスです。
S3へ飛ばされるALBのアクセスログをCloudWatch Logに出力するために利用します。
LogStare Collector / LogStare Quint
弊社グループ会社が開発している、
「ネットワーク機器に対して、監視、ログを収集・解析するための製品」です。
LogStare CollectorからCloudWatch Logsへログを取得しに行き、
それをLogStare Quintで解析をします。
ここでは詳細を説明しませんので、下記の記事を参照ください。
LogStare を活用した AWS サービスのログ分析の効率化と標準化
(https://aws.amazon.com/jp/blogs/psa/logstare-waf/)
LogStare CollectorでのAWS WAFログの取得方法とログレポート
(https://www.secuavail.com/kb/aws-azure/tb-221017-01/)
AWS ALBのログを管理するためのCloudWatch Logs設定方法
(https://www.secuavail.com/kb/aws-azure/aws-alb-log-collect/)