★2025/6/18 追記
AWS re:Inforce 2025内でAWS WAFのコンソール画面を一新したというアナウンスがありました。
それに伴い、新しいWAFコンソールに対応した版のブログを下記に執筆してます。
https://qiita.com/tkazuaki0820/items/be667159134b7614b9e5
本ブログでは、2025/6/17以前の旧WAFコンソールでの解説にｎ
近年サイバー攻撃が増々増えていますね。特に昨年末頃からDDoS攻撃の被害が増えており、
AWSでのセキュリティ対策をどうやっているのか？と問い合わせを受ける機会が増えてきました。
そこで今回はAWSのALBとECSを利用したWebサーバにおけるAWSサービスを利用したセキュリティ対策と被害を受けた時の運用について纏めてみました。
■AWS構成図
今回の記事で説明するAWSの簡単な構成図は下記になります。※2025/6/16 監視アラームの設定を追加
■ALB+ECSでのWebサーバの構築
セキュリティの話にをする前にWebサーバ部分の構成を簡単に解説します。
※本題じゃないのでサラっと説明します。
下記の手順でALB+ECSでのWebサーバを構築しています。
①WebサーバのURLドメインを取得
②WebサーバのURLドメインをAmazon Route53のホストゾーンに登録
③ACMでURLドメインに紐づく証明書を発行
④②のAmazon Route53ホストゾーンのレコードにApplication Load Balancerを追加
⑤Application Load BalancerのターゲットグループにAmazon ECSを紐づけ
※Amazon ECSでApacheやNginx等のWebサーバを動かすことを想定してます。
■セキュリティ対策
まず、今回説明するセキュリティ対策用のAWSサービスの概要を下記の表にまとめました。
| AWS WAF | AWS Shield | Amazon GuardDuty | |
|---|---|---|---|
| できること(抜粋) | クライアントIPアドレスの制限／SQL インジェクションやクロスサイトスクリプティングなどの一般的な攻撃からウェブアプリケーションを保護 | DDoS攻撃からの保護／検知／緩和 | AWS内での不正アクティビティ(不正APIコール発行)検知、ECS等のランタイムモニタリング |
まず、大事な前提として各AWSサービスごとに対策できる攻撃、防御できるAWSリソースは違います。
適切な個所に適切な対策となるセキュリティ用サービスを複数組み合わせて導入していくことが必要です。
(たまに、セキュリティ対策はどれか一つだけやってればOKと誤解してる方がいますが、そんなことはありません。)
①AWS WAF
AWS WAFはクライアントIPアドレスの制限／SQL インジェクションやクロスサイトスクリプティングなどの一般的な攻撃からウェブアプリケーションを保護できるAWSサービスになります。
AWS WAFにてルールベースでWeb ACLs(アクセスコントロールリスト)を作成し、各AWSリソースに紐づけることでAWSリソースの保護ができます。
また、一つのAWS WAFのWeb ACLsを複数のAWSリソースに紐づけることも可能であるため、セキュリティルールの一元管理を行うことができます。
現時点で、Application Load Balancer、Amazon API Gateway REST API、Amazon App Runner service、AWS AppSync API、Amazon Cognito user pool、AWS Verified Accessに紐づけることが可能です。
AWS WAFのWeb ACLsは下記のように作成します。Priority 0～5のルールはAWSが提供してるルールで、一般的なサイバー攻撃の対策を行うためのルールです。
これらのAWSが提供してる管理ルールを利用することで、サイバーセキュリティの知識が余りない場合でも安全なセキュリティ対策を実装することができます。
Priorityが6のルールはこちらで作成したルールです。
WebサーバにアクセスできるクライアントIPのCIDR範囲を指定するためのルールになってます。
Webサーバを利用するクライアントが固定で決まってる場合、このルールを設定することで、WebサーバにアクセスできるクライアントIPのCIDR範囲を指定することができます。
設定の方法は、「IP-Set」の画面で、接続を許可するIPアドレスのリストの作成を行います。
その後、接続を許可するIPアドレスのリストを利用したWebACLsの作成を行います。Actionは「Allow」にすることで、IPアドレスのホワイトリスト形式によるアクセス許可ルールを作成することができます。
②AWS Shiled
AWS ShiledにはStandardとAdvancedの二種類あります。
二つの比較を簡単にまとめると下記になります。
| AWS Shiled Standard | AWS Shield Advanced | |
|---|---|---|
| 料金 | 無償 | 有償 月額3,000USD |
| できること | AWSインフラストラクチャの保護 | 固有のアプリケーション／AWSリソース保護 |
| 保護されるNWレイヤ | レイヤ3／レイヤ4 | レイヤ3／レイヤ4／レイヤ7 |
| 特定のAWSリソースの保護 | できない | できる |
| AWS WAFの料金 | 追加ルール毎に追加課金が発生 | AWS WAF使用料金が免除 |
| サポート体制 | 通常のサポート体制 | AWS Shield レスポンスチーム (SRT) による 24 時間365 ⽇のサポート、アラート通知 |
AWS Shiled Standardは無償で全てのユーザが利用できるサービスです。
レイヤ3ネットワーク層／レイヤ4トランスポート層 の DDoS 攻撃の⾃動緩和を提供しています。
AWS Shiled Standard自体は無償ですが、AWS WAFを利用する場合。追加ルール毎に追加課金が発生します。
AWS Shield Advancedでは、レイヤ3ネットワーク層／レイヤ4トランスポート層に加えてレイヤ7アプリケーション層の保護を提供しています。
AWS Shield Advanced の方は月額料金として 3,000 USD が月末に発生します。これはAWS Organizations単位の課金になります。
Advanced契約するとAWS WAF使用料金が免除になるので、大規模な組織にて一括でAdvanced契約をしてる場合はお得な料金になると思います。
ただし、小規模な組織や個人アカウントだと結構な高額になるので、まずは自身のAWSアカウントが所属してるOrganizations組織がAWS Shield Advanced契約済みかを確認た上で有効化の判断をしましょう。
※一度個人のAWSアカウントで誤操作により、Advanced有効化してしまった時はAWS社サポート問合せ経由でキャンセルしてもらいました。。
AWS Shield Advancedでは特定のAWSリソースの保護の設定を行うこともできるようになります。
※2025/5月時点で東京リージョンでは、Cloudfront distribution、Route 53 Hosted Zone、Global Accelerator、Application load balancer、Classic load balancer、Elastic IP addressの保護が可能
特定のAWSリソースのDDoS攻撃からの保護の設定は、AWS Shield Advancedを有効化した後、「Protected resources」の項目から監視対象のAWSリソースを選択することで設定できます。
※Elastic IP addressやApplication Load Balancer等が対応しています。
また、AWS Shield Advancedを有効化すると実際に攻撃を受けた時のアラームの設定を行うこともできるようになります。
設定はCloudwachメトリクスの「AWS/DDoSProtection」の「DDoSDetected」の値で監視しています。
「DDoSDetected」の値が０以外であれば、アラーム出力するようにしています。
※Cloudwachメトリクスの詳細は下記のサイトを参考
https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/shield-metrics.html
最後に、AWS Shield Advancedを有効化すると、AWS Shield レスポンスチーム (SRT) による 24 時間365 ⽇のサポートを受けることができるようになります。
設定の⾒直しやシグネチャの更新の対応また、攻撃発生時に自動防御で対応できない場合は、 Shield レスポンスチームが介在し対処を行ってくれるようになります。
③Amazon GuardDuty
Amazon GuardDutyではAWS内での不正アクティビティ(不正APIコール発行)検知、ECS等のランタイムモニタリング、EC2/S3内ファイルのマルウェア検出、RDS、Lambdaの保護ができます。
ECSを利用したWebサーバでよくあるのが、通常時と比較して、不正にAPIコールの呼び出しをされたことを検知し、
不正に情報漏洩をされた可能性の有無／AWSリソースの乗っ取りの有無の検知をすることができます。
Amazon GuardDutyで保護できるAWSリソースと検知できるイベントを纏めると下記の表になります。
| No | 保護するAWSサービス | 検知できること |
|---|---|---|
| 1 | EC2 | マルウェアスキャンの脆弱性診断、ランタイムモニタリング |
| 2 | EKS | EKS クラスター内の API アクティビティをキャプチャして、脅威を検出する Kubernetes 監査ログのモニタリング、ランタイムモニタリング |
| 3 | AWS Fargate (ECSのみ) | ESSのランタイムモニタリング |
| 4 | S3 | データイベントのモニタリングと検出結果の生成、アップロードされたファイルのマルウェアスキャン |
| 5 | RDS | アカウントの RDS ログインアクティビティを表示およびモニタリング |
| 6 | Lambda | アカウントの Lambda 関数からのネットワークアクティビティログを表示およびモニタリング |
| 7 | S3 | データイベントのモニタリングと検出結果の生成 |
■監視アラームの実装
監視アラームの実装方法イメージは下記になります。今回はシステム運用者(operator)にメールで通知をする例について解説します。
システムの実装イメージ図は下記になります。
AWS ShieldはCloudWtachアラーム、Amazon SNSを経由での通知、
Amazon GuardDutyはAmazon EventBridge、Amazon SNSを経由しての通知になります。
①共通設定(Amazon SNS)の設定
まずは、Amazon SNSのトピックの作成を行います。
トピックのタイプは「スタンダード」を選択します。その他の設定はデフォルトのままにして作成します。
次に、通知方法／通知先の設定を行います。
先ほど作成したSNSトピックからサブスクリプションの作成から行うことができます。
今回はメールで受信をしたいため、「プロトコル」を「Eメール」、「エンドポイント」を「通知したい人のメールアドレス」にしています。
設定を行うと「AWS Notification - Subscription Confirmation」というタイトルでAWSからメールが届きます。
メール本文の「Confirm subscription」をクリックするとAmazon SNSの設定は完了です
②AWS Shieldの監視アラームの実装
AWS ShieldはCloudWtachアラーム経由での通知になります。
Cloudwachメトリクスの「AWS/DDoSProtection」の「DDoSDetected」の値のアラームを設定します。
※Cloudwachメトリクスの詳細は下記のサイトを参考
https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/shield-metrics.html
設定はCloudWtachアラームで行います。
まず、AWS Shield監視対象のAWSリソースの「AWS/DDoSProtection」の「DDoSDetected」の値を選択します。
※今回はApplication load balancer
次に閾値を選択します。今回は1分以内に1件以上DDoS攻撃を検知した場合にアラームを発行する設定にします。
次に通知先の設定を行います。今回は最初に作ったAmazon SNSを設定します。
その他の設定はデフォルトのまま次へを選択します。
次にCloudewtachアラームのアラーム名を入力して、次へをクリックします。
プレビューと作成画面で、入力内容を再確認し、「アラームの作成」をクリックします。
これで、AWS Shiledの監視アラームの設定が完了です。
③Amazon GuardDutyの監視アラームの実装
Amazon GuardDutyはAmazon EventBridge、Amazon SNSを経由しての通知になります。
Amazon EventBridgeの設定をします。「パス」の項目から「ルールを作成」をクリックして設定を行います。
ルールの名前を選択して次へを選択します。
次にイベントパターンを選択します。
「AWSサービス」-「GuardDuty」-「すべてのイベント」を選択して次へを選択します。
Amazon EventBridgeのターゲットを選択します。今回は最初に作ったAmazon SNSを選択します。
タグの設定が必要であれば、次の画面で入力します。今回特に必要がないので、
そのまま次の画面へ進み。設定を確認した後、ルールの作成を選択します。
これで、Amazon GuardDutyの監視アラームの設定は完了です。
最後に、監視アラームが正しく設定されているかをテストします。
Amazon GuardDutyの画面の「設定」の項目から「検出結果サンプルの作成」をクリックすることで、テストが行います。
※注意点として、このテストを行うとAWSからの通知が数百通届きます！
テストする際はSNSの設定で捨てメールアドレスのみ登録してから実行するのを推奨します。
AWSからのAmazon GuardDutyに関する通知メールが届いていたら設定は完了です
■攻撃検知時の対応
攻撃を受けた時の運用フローは事前に取り決めておくことが大事です。
障害を受けてから考えるでは遅すぎます。その間攻撃を受け続けてしまうことになります。
私のプロジェクトでは攻撃を受けた時の一時対処あらかじめ決めて、運用フローのマニュアルを作成してます。
本番リリース前に、検証環境で運用フローマニュアルのテスト実行も行い、攻撃を受けた時にいつでも対応可能な状態にしておきます。
運用フローはシステムの要件によって、対処に必要な期限／対処できることが違うので完全な正解はありません。
いくつかの運用例を紹介しようと思います。
①AWS WAFでの異常検知時／AWS ShiledでのDDoS攻撃検知
攻撃者の接続元IPが特定できる場合は、AWS WAFのルールを更新してアクセスをブロックしましょう。
やりかたはまず「IP-Set」の画面でアクセス拒否用のIPアドレスリストを作成します。
次にAWS WAFのWeb ACLsに、アクセス拒否用のIPアドレスリストを利用した接続拒否のルールを設定します。
Actionの項目を「Block」に設定することで、特定のIPアドレスからのアクセスを拒否するルールを作成することができます。
攻撃者の接続元IPを特定できない／時間が掛かりそうな場合は、
必要に応じて入り口のInternetGWをVPCからデタッチしてアクセスできないようにしましょう。
→当然ですが、InternetGWをデタッチすると正常なクライアントからの通信も含め
インターネット接続がすべて不可になるので最終手段です。
重要な情報が漏洩するくらいだったら業務全停止したほうがマシと判断した時に実施します。
※事象復旧／対策完了した後はVPCの再アタッチは忘れずに！
InternetGWのデタッチはInternetGWの画面から実施することができます。
また、アタッチも同じくInternetGWの画面から実施することができます。
②Amazon GuardDutyによる IAMユーザ／ロールの不正アクティビティ検知
検知されたIAMユーザ／ロールを確認し、必要に応じて攻撃を受けているIAMユーザの無効化／IAMロールのセッション無効化／一時的な削除の検討を実施します。
注意点として実際には攻撃を受けてないのに通常運用の中で攻撃として誤検知する場合もあることを念頭に入れておく必要があります。
よくある例として、新規に払い出したIAMユーザの初回ログイン時や、リリース作業で普段使わないシェルスクリプトの実行をした際などに、Amazon GuardDutyのセキュリティアラートが発行されたりします。
セキュリティアラートがでたら毎回IAMユーザ／ロールの無効化を対応するのでなく、メッセージを見て要否を判断するのも大切です。
判断に困る場合は、Severity(検出結果の重要度レベル)をチェックして実施する手順を変えていくフローにするのも有効です。
https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty_findings-severity.html
IAMユーザを無効化したい場合は、下記の手順で対応できます。
①コンソール経由でのログインの無効化
無効化したいIAMユーザの管理画面の「コンソールアクセスを管理」からコンソールアクセスの無効化
②CLI経由でのアクセス無効化
同じく無効化したい「IAMユーザの管理画面のアクセスキー」の項目の「アクション」から無効化を実行
また、IAMロールが乗っ取られた場合はIAMロールの画面から「アクティブなセッションの無効化」を選択し、ロールにが使用してるセッションを一度全て削除することが可能です。
アクティブセッションの無効化を実施しても攻撃が続く場合は一度IAMロールの削除も検討が必要です。
■最後に
今回はAWSのALB+ECSを使ったWebサーバでのセキュリティ対策について解説しました。
実際にはサイバー攻撃の種類は日々多種多様に増えており、セキュリティ対策としてはこれだけやったら大丈夫とは言い切れないので、常に最新セキュリティ対策を検討/改善し続けることが大事だと思います。
また、今回はAWSサービスによるセキュリティ対策のみを解説しましたが、
実際にはAWSサービスだけでは不十分な領域の対策をAWS以外のセキュリティ製品にて対策を行ってます。
例、VPCフローログをリアルタイム解析して、異常な振る舞いを検知する製品
EC2のゲストOSレイヤのセキュリティ監視、改ざん検知を行う製品