近年サイバー攻撃が増々増えていますね。特に昨年末頃からDDoS攻撃の被害が増えており、
AWSでのセキュリティ対策をどうやっているのか？と問い合わせを受ける機会が増えてきました。
そこで今回はAWSのALBとECSを利用したWebサーバにおけるAWSサービスを利用したセキュリティ対策と被害を受けた時の運用について纏めてみました。
■AWS構成図
今回の記事で説明するAWSの簡単な構成図は下記になります。
■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 | データイベントのモニタリングと検出結果の生成 |
■攻撃検知時の対応
攻撃を受けた時の運用フローは事前に取り決めておくことが大事です。
障害を受けてから考えてるとその間攻撃を受け続けてしまうことになります。
システムの要件によって、対処に必要な期限／対処できることが違うので完全な正解はありません。
いくつかの運用例を紹介しようと思います。
①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レイヤのセキュリティ監視、改ざん検知を行う製品
また、記事のボリュームが大きくなってしまい、セキュリティアラームを通知の実装(Cloudwatch アラーム、Eventbridge、SNS等)の部分ついては
今回あまり詳細に触れられなかったので、余力ができた時に纏めようと思います。