AWSのセキュリティ対策では、ひとつのサービスですべてを守ろうとするより、守る対象と見つけたいリスクに合わせて役割を分けることが重要です。
AWS Shield、AWS WAF、Amazon GuardDuty、AWS Security Hubは名前が並べて語られやすいサービスですが、担当する範囲は同じではありません。大まかには、DDoS対策はShield、Webリクエストの制御はWAF、AWS環境内の不審な動きの検出はGuardDuty、検出結果やセキュリティ状態の集約はSecurity Hubが担います。
この記事では、4つのサービスの違いを整理し、どの順番で検討すると実務に落とし込みやすいかを解説します。
まず押さえたい役割の違い
最初に、4つのサービスを「何を守るか」「何を見つけるか」で分けます。
この整理をしておくと、同じセキュリティサービスでも導入目的が重ならず、設定や運用の責任範囲を決めやすくなります。
| サービス | 主な役割 | 向いている場面 | 注意したい点 |
|---|---|---|---|
| AWS Shield | DDoS攻撃からAWSリソースを守る。 | 公開Webサイト、API、ECサイトなど、停止影響が大きいサービスを保護したい場合。 | Shield StandardとShield Advancedでは、保護機能や運用支援の考え方が異なる。 |
| AWS WAF | HTTP/HTTPSリクエストを条件に応じて許可、ブロック、カウントする。 | SQLインジェクション、クロスサイトスクリプティング、悪質なボット、特定条件のアクセス制御に対応したい場合。 | ルールを強くしすぎると、正規のアクセスまで止めるおそれがある。 |
| Amazon GuardDuty | AWS環境内のログやイベントを分析し、不審な活動や侵害の兆候を検出する。 | 認証情報の悪用、通常と異なるAPI操作、マルウェアやデータ流出の兆候を早く把握したい場合。 | 検出するサービスであり、検出後の調査や対応フローを別途設計する必要がある。 |
| AWS Security Hub | 複数サービスの検出結果やセキュリティチェック結果を集約して管理する。 | 複数アカウント、複数サービスの状態を一元的に見て、優先順位を付けて対応したい場合。 | 集約しただけでは対応は完了しないため、担当者、期限、判断基準を決める必要がある。 |
用語を簡単に整理する
4つのサービスを比較する前に、混同しやすい言葉を整理します。
- DDoS攻撃は、大量の通信でサービスを使いにくくしたり、停止させたりする攻撃です。
- WAFは、Webアプリケーションに届くリクエストの内容を見て、許可やブロックなどを判断する仕組みです。
- 脅威検知は、すでに環境内で起きている不審な操作や通信を見つける考え方です。
- セキュリティ状態の集約は、複数の検出結果やチェック結果をまとめ、対応すべきものを見つけやすくする考え方です。
つまり、ShieldとWAFは外から来る攻撃やリクエストを意識した防御に近く、GuardDutyとSecurity Hubは環境内で起きたことを見つけ、整理し、対応につなげるための仕組みに近いと考えると理解しやすくなります。
使い分けの考え方
DDoS攻撃に備えるならAWS Shield
インターネットに公開しているサービスでは、DDoS攻撃によって正規ユーザーがアクセスできなくなるリスクがあります。
AWS Shieldはこの領域を担当し、AWS上で動く公開サービスをDDoSから守るために使います。
通常のAWS利用ではShield Standardが標準的な保護として利用できます。より高い可視性、専門的なサポート、追加の保護機能が必要な場合はShield Advancedを検討します。
ただし、Shield Advancedは追加費用が発生するため、すべての環境で最初から選ぶものではありません。公開サービスの重要度、停止した場合の影響、運用チームがどこまで対応できるかを踏まえて判断します。
Webリクエストを制御するならAWS WAF
AWS WAFは、アプリケーション層のリクエストを見て制御するためのサービスです。
SQLインジェクションやクロスサイトスクリプティングのような典型的なWeb攻撃に備えたい場合や、IPアドレス、国、ヘッダー、文字列、レートなどに基づいてリクエストを制御したい場合に役立ちます。
ShieldがDDoSのような大量通信のリスクを意識するのに対し、WAFは「どのような内容のリクエストを通すか」を判断する役割です。
公開Webアプリケーションでは、いきなりブロックするのではなく、まずカウントで影響を見てから段階的に制御を強めると、誤検知による業務影響を抑えやすくなります。
不審な操作や侵害の兆候を見つけるならAmazon GuardDuty
Amazon GuardDutyは、AWSアカウント内の操作や通信の傾向から、通常と異なる活動を検出するためのサービスです。
認証情報の悪用、想定外のAPI呼び出し、悪意あるIPアドレスとの通信、マルウェアの疑いなど、攻撃が始まった後の兆候を見つける用途に向いています。
GuardDutyは、境界でリクエストを止めるWAFとは役割が異なります。WAFが入口の制御を担うのに対し、GuardDutyはAWS環境内で起きている不審な動きを検知し、調査や対応のきっかけを提供します。
検出結果をまとめて運用するならAWS Security Hub
AWS Security Hubは、GuardDutyなどの検出結果やセキュリティチェックの結果を集約し、組織全体のセキュリティ状態を把握しやすくするためのサービスです。
複数アカウントや複数リージョンを運用している場合、個別サービスの画面だけで状況を追うと、対応漏れや優先順位の混乱が起こりやすくなります。
Security Hubを使うと、検出結果を標準化された形で集約し、重要度や対象リソースに基づいて整理できます。運用チームが対応すべき項目を見つけやすくなるため、日常的なセキュリティ管理や監査対応にも役立ちます。
組み合わせて使うと何がよくなるか
多層防御を設計しやすくなる
4つのサービスを組み合わせると、DDoS、Web攻撃、不審なアカウント操作、検出結果の集約という異なる層を分担できます。
たとえば、ShieldでDDoSに備え、WAFでWebリクエストを制御し、GuardDutyで侵害の兆候を検出し、Security Hubで検出結果を整理する構成です。
ひとつのサービスで全てを解決しようとするよりも、攻撃の入口、環境内の挙動、対応管理を分けて考えられるため、設計と運用の見通しがよくなります。
検出結果を対応につなげやすい
GuardDutyやWAFで見つかった情報をSecurity Hubに集約すると、個別のアラートを単発で見るだけでなく、リソース、重要度、関連する検出結果を踏まえて判断しやすくなります。
緊急度の高い検出結果を優先し、対応の抜け漏れを減らす運用に向いています。
自動化の前に運用フローを整えやすい
検出結果を起点に、通知、チケット作成、関係者へのエスカレーション、必要に応じた自動対応へつなげる設計も可能です。
ただし、自動化は誤検知時の影響も大きくなります。最初から強い遮断を行うのではなく、通知や記録から始め、十分に検証してから段階的に広げる方が現実的です。
導入順序の考え方
導入順序は、組織のリスクと公開しているシステムによって変わります。
迷う場合は、次の順に整理すると判断しやすくなります。
- 公開サービスの停止影響が大きいかを確認する。影響が大きい場合は、Shieldの利用範囲を検討する。
- WebアプリケーションやAPIを公開しているかを確認する。公開している場合は、WAFで守るリソースとルール方針を決める。
- AWS環境内の不審な操作を見つけたいかを確認する。必要であれば、GuardDutyの有効化範囲と通知先を設計する。
- 複数サービスの検出結果をまとめて管理したいかを確認する。必要であれば、Security Hubで集約と優先順位付けを行う。
- コスト、誤検知、対応フローを定期的に見直し、不要な通知や重複対応を減らす。
組み合わせる際の注意点
コストはサービスごとに確認する
複数のセキュリティサービスを有効化すると、利用量、保護対象、処理するリクエスト、検出結果の量に応じて費用が増える可能性があります。
特にWAF、GuardDuty、Security Hubは、環境規模が大きくなるほど継続的なコスト管理が重要になります。料金体系や対象範囲は変わることがあるため、導入前と運用中の両方で確認します。
ルールとアラートを増やしすぎない
WAFのルール、GuardDutyの検出結果、Security Hubのチェック結果をすべてそのまま受け取ると、アラートが多くなりすぎることがあります。
重要度の基準、通知先、対応期限、抑制ルールを決めておかないと、運用チームが本当に重要な検出結果を見落とす原因になります。
サービスごとの責任範囲を明確にする
Shield、WAF、GuardDuty、Security Hubは連携できますが、役割は同じではありません。
DDoS対策、Web攻撃対策、脅威検出、統合管理のどこに課題があるのかを整理し、必要なサービスから段階的に導入する方が、設定ミスや過剰な運用負荷を避けやすくなります。
導入前のチェックポイント
- 守りたい対象は、公開Webサイト、API、社内向けAWS環境のどれか。
- 防ぎたいリスクは、DDoS、Web攻撃、不正な操作、対応漏れのどれか。
- 検出結果を誰が確認し、どの期限で対応するか。
- 最初からブロックするのか、カウントや通知から始めるのか。
- 追加コストをどの単位で確認し、誰が定期的に見直すか。
- 誤検知が起きた場合に、誰がルールや通知条件を調整するか。
まとめ
AWS Shield、AWS WAF、Amazon GuardDuty、AWS Security Hubは、いずれもAWS環境のセキュリティを高めるサービスですが、守る対象と目的が異なります。
DDoSにはShield、Webリクエスト制御にはWAF、不審な挙動の検出にはGuardDuty、検出結果とセキュリティ状態の統合管理にはSecurity Hubを使う、と整理すると選びやすくなります。
重要なのは、すべてを一度に導入することではありません。自社のリスク、公開しているサービス、運用体制に合わせて段階的に組み合わせることです。
役割を切り分けて設計すれば、セキュリティを強化しながら、コストやアラート過多による運用負荷も抑えやすくなります。