Well-Architected、Trusted Advisor、Security Hub、Config、Inspector、GuardDuty——どれも「セキュリティ」を名乗り、機能説明を読むほど区別がつかなくなる。混乱の正体は明快です。これらは答えている「問い」が違う。そして本当に難しいのは、ツールを並べることではなく、出てきた大量の指摘を前に何を許容し、何を守るかを決めること——それは上司の仕事です。
各サービスの機能一覧はAWSのドキュメントにいくらでもあります。本記事が示すのはその手前の地図——「どれがどの問いに答える道具なのか」という配置と、その上で管理職が下すべき意思決定です。個別サービスの運用の作り込み(トリアージ、自動対応、アラート疲れ対策)はGuardDuty / Security Hub の運用で、予防的なガードレールはOrganizations と SCPで扱っています。本記事はそれらを束ねる「全体像と判断」に絞ります。
01なぜ全部わからなくなるのか — 名前が「セキュリティ」で揃っているから
混乱の原因は、これらのサービスが異なる問いへの答えなのに、同じ「セキュリティ」という看板を掲げていることです。「バックアップ」という言葉が世代管理と復旧手順を同時に指してしまうのと同じ構図で、区別は機能の細部ではなく「どんな問いに答える道具か」で付きます。実務で意味のある問いは、たった4つです。
- 設計は良いか？(そもそもの作りが安全か)
- 設定は正しいか？(ベストプラクティスから外れていないか)
- 脆弱性はあるか？(既知の弱点を抱えたソフトが動いていないか)
- 攻撃されているか？(いま不審な動きが起きていないか)
各サービスをこの4問のどれに答える道具かで仕分けると、いっぺんに整理されます。そして5つ目の役割——それら全部を束ねて優先順位を付けるのがSecurity Hubで、すべての土台に監査ログのCloudTrailがある、という構造です。
02一枚早見表 — どれが何に答える道具か
まず全体を一覧にします。「この道具は何の問いに答えるのか」「点検(点)なのか継続監視なのか」「誰が動くのか」を押さえれば、会議で名前が飛び交っても迷いません。
| サービス | 答える問い | 点検 / 継続 | 主に誰が使う |
|---|---|---|---|
| Well-Architected (Framework/Tool) | 設計は良いか | 点(レビュー時) | 設計者・PM・経営 |
| Trusted Advisor | 横断で明白な改善点はないか | 継続(定期チェック) | 運用・情シス |
| AWS Config | 設定は今どうなっているか・ルールに沿うか | 継続(記録＋評価) | 統制・監査・運用 |
| Security Hub CSPM(旧Security Hub) | 設定がベストプラクティス標準に沿うか | 継続(標準チェック) | セキュリティ運用 |
| Amazon Inspector | 既知の脆弱性(CVE)はあるか | 継続(自動スキャン) | セキュリティ・開発 |
| GuardDuty | いま攻撃されているか | 継続(脅威検知) | セキュリティ運用・SOC |
| Security Hub(2025刷新) | 結局どれから直すべきか | 継続(相関・優先度) | セキュリティ責任者・上司 |
この表の一番下、2025年に刷新された「新しいSecurity Hub」が、本記事のテーマ「何を守るべきか」に直接答えようとする役割です。まず紛らわしい上4つ(設計・設定系)をほどき、次に脆弱性と脅威の違い、最後に新Security Hubと上司の判断へ進みます。
03「設計・設定」系の4つ — Well-Architected / Trusted Advisor / Config / Security Hub CSPM
最も混同されるのがこの4つです。どれも「ちゃんとできているか確認する」道具に見えますが、確認の粒度と役割が違います。
- Well-Architectedは設計思想の健康診断です。6つの柱(運用・セキュリティ・信頼性・性能・コスト・持続可能性)に沿った質問に答え、設計の弱点を洗い出すレビュー手法。継続監視ではなく節目に人がやる点検で、セキュリティはそのうちの1本の柱にすぎません。「作りとして正しい方向か」を問う、最も上流の道具です。
- Trusted Advisorは横断の健康チェック。セキュリティに限らずコスト・性能・耐障害性・サービス上限まで、明白な改善点を広く浅く指摘します。深掘りより「取りこぼしの発見」向き。利用範囲がサポートプランに依存する点が固有の注意で、全チェックとAPIはBusinessサポートやEnterpriseサポートが前提です(近年は無料のBasicでも一定数が開放)。
- AWS Configは設定の真実源(source of truth)。全リソースの設定を時系列で記録し、「今どうなっているか」「いつ誰が変えたか」「定めたルールに沿うか(準拠/非準拠)」を継続評価します。設定変更の履歴とドリフト(あるべき姿からのズレ)を押さえる土台で、実は次のSecurity Hub CSPMの多くのチェックはConfigルールの上で動いています。統制・監査の背骨です。
- Security Hub CSPM(2025年に旧Security Hubから改称)は、セキュリティのベストプラクティス標準(FSBP・CIS・PCI DSS・NISTなど)を「コントロール」として一括評価し、準拠状況をスコア化します。Configが「設定の記録と任意ルール」なら、こちらは「セキュリティ標準への適合」に特化した継続チェック。CSPM＝Cloud Security Posture Management(クラウドの設定姿勢の管理)という分野名そのものです。
04Inspector と GuardDuty — 「弱点」と「攻撃」は別物
もうひとつの二大混同がこれです。どちらも脅威っぽく聞こえますが、見ているものが根本的に違います。
| Amazon Inspector | Amazon GuardDuty | |
|---|---|---|
| 問い | 既知の弱点を抱えていないか | いま攻撃されていないか |
| 見るもの | ソフトのバージョン・CVE・到達性 | ログ・通信・振る舞いの異常 |
| 時間軸 | 攻撃される前(予防的) | 攻撃の最中(検知的) |
| 対象 | EC2・ECRイメージ・Lambda(コードも) | CloudTrail・VPC/DNS・EKS・S3・マルウェア等 |
| たとえ | 建物の耐震診断(壊れやすい箇所) | 侵入センサー(いま誰か入った) |
Inspectorは「あなたのサーバーで動くApacheに既知の脆弱性がある」「このコンテナイメージのライブラリにCVEがある」と、攻撃される前の弱点を継続スキャンで洗い出します。対処は「パッチを当てる・更新する」。GuardDutyは「見慣れない国から管理APIが叩かれた」「暗号通貨採掘の通信が出ている」と、いま起きている異常を検知します。対処は「隔離・調査・遮断」。耐震診断と侵入センサーの両方が要るのと同じで、どちらかで代替はできません。この2つの findings が、後述のSecurity Hubで設定の弱点と突き合わされて、初めて「本当に危ない箇所」が浮かびます。
052025年の答え — Security Hub の Exposure Findings
ここまでの道具は、それぞれ大量の指摘(findings)を吐き出します。設定の非準拠が数百、CVEが数千、脅威検知が日々——全部は直せません。「で、結局どれから守ればいいのか」。この現場の悲鳴に、AWSが2025年の刷新で出した答えが、新しいSecurity HubのExposure Findings(エクスポージャー・findings)です。
これは単なる集約ではありません。Security Hub CSPM(設定)・Inspector(脆弱性)・GuardDuty(脅威)・Macie(機微データ)からの信号を相関し、さらにネットワーク到達性とIAM権限の関係を評価して、「個々では軽微でも、組み合わさると危険」な露出を1件のfindingに束ねます。公式ドキュメントによれば、各Exposure Findingは深刻度(Critical〜Low)に加えて、想定される攻撃経路と影響範囲(blast radius)を図で可視化し、具体的な修正手順まで提示します。
06脇を固める道具たち — 一言ずつ
4つの問いと集約が主役ですが、周辺にも役割の異なる道具があります。名前が出たときに迷わないよう、一言で位置づけます。
| サービス | 一言でいうと | どの問いの隣か |
|---|---|---|
| CloudTrail | 誰が何のAPIを叩いたかの監査ログ。すべての土台 | 全部の原材料 |
| Amazon Macie | S3の中に機微データ(個人情報等)がないか探す | 設定＋データ |
| Amazon Detective | 検知の「なぜ・どこから」を関連づけて調査する | 攻撃(の深掘り) |
| IAM Access Analyzer | 外部公開・使われていない過剰権限を洗い出す | 設定(権限) |
| AWS Audit Manager | 監査対応の証拠を枠組み(PCI等)に沿って自動収集 | 設定(証跡化) |
| Security Lake | 各種ログを標準形式(OCSF)で集約する保管庫・SIEM連携 | 土台(長期保管) |
ログの集約とSIEM連携の現代的な組み方はS3からSecurity Lakeへ、権限設計の現実解はIAM設計の現実解で掘り下げています。Audit Managerは「守る」道具というより「守れていることを監査人に示す」証跡化の道具で、防御そのものと混同しないのがコツです。
07上司の仕事① — 何を許容してよいか
ここからが本題です。ここまでの道具は全部、指摘を出すだけ——何を直し、何を見送るかは決めてくれません。それを決めるのが管理職の役割で、出発点は「全部は直せない」を受け入れることです。良いセキュリティ運用は、指摘をゼロにすることではなく、各指摘に『どうするか』の判断と担当と期限を付けることです。
許容(リスク受容)してよい典型は次のようなものです。ただし「許容＝放置」ではありません。許容には必ず理由と記録が要ります。
- 影響が限定的なもの：隔離された検証環境、外部到達性のないリソース、代替の防御(補償統制)が効いている箇所の指摘。
- 誤検知・仕様：意図した構成が「非準拠」と出るケース。これは理由を明記して抑制(suppress)します。黙って消すのではなく「なぜ許容か」を残すのが分かれ目です。
- 費用対効果が見合わないもの：修正コストが守る価値を上回る低リスク項目。ただし期限付きで再評価する。
08上司の仕事② — 何を守るべきか、そして予防を検知より優先する
裏返しの「絶対に守るべき」防衛線は、業種を問わずおおむね共通です。ここに指摘が出たら、許容の議論をせず即対応する——という線引きを、あらかじめ引いておきます。
| 絶対防衛線 | なぜ最優先か | 主に見る道具 |
|---|---|---|
| インターネット直結 × 機微データ | 攻撃者から最短距離。露出が即被害に直結 | Exposure Findings / Macie / Config |
| ID・認証・鍵(IAM/ルート/アクセスキー) | ここを取られると全部を取られる。影響範囲が最大 | Access Analyzer / GuardDuty / Config |
| 監査ログ(CloudTrail)の完全性 | 消されると侵害の証拠と復旧の起点を失う | Config / CloudTrail(改ざん防止) |
| バックアップ(消せない・戻せる) | ランサムの最後の砦。ここが無傷なら生き残れる | AWS Backup / Vault Lock |
この防衛線を守る上で、上司が持つべき大原則が3つあります。
- 予防 > 検知 > 対応：検知の仕組みをいくら増やしても、鳴った後に人が動く前提です。それよりそもそも危険な操作を組織的に禁止するガードレール(SCPやPolicy as Code)の方が、安く・確実に効きます。まず予防で塞げるものを塞ぎ、塞げない残りを検知で見る。この順序が投資効率を決めます。
- ツールを買うことと、守れることは違う：Security HubもGuardDutyも、有効化しただけでは findings が増えるだけです。指摘に対処する運用(トリアージ・担当・期限)が無ければ、コストと「対策した気」だけが積み上がる。アラート疲れの設計的な潰し方は運用編を参照してください。
- 責任共有モデルを忘れない：AWSが守るのは「クラウドのセキュリティ」(基盤)、あなたが守るのは「クラウドにおけるセキュリティ」(設定・データ・権限)。本記事の道具は全部あなたの責任範囲を見るものです。「AWSだから安全」と「自社の設定が安全」は別の話——ここを取り違えないことが、上司の最初の一歩です。
—まとめ
名前で混乱したら、問いに戻れば整理できます。
- 4つの問いで仕分ける：設計(Well-Architected)／設定(Config・Trusted Advisor・Security Hub CSPM)／脆弱性(Inspector)／脅威(GuardDuty)。土台はCloudTrail
- InspectorとGuardDutyは別物：既知の弱点(耐震診断)と進行中の攻撃(侵入センサー)。両方要る
- 2025年の答えはExposure Findings：設定・脆弱性・脅威・到達性を相関し、「本当に危ない組み合わせ」をリスク順に。旧Security Hubは「CSPM」に改称され部品化
- findingは候補、決めるのは人：深刻度≠優先度。事業価値の重み付けは機械にできない上司の仕事
- 何を守るか＝絶対防衛線：ネット直結×機微データ／ID・鍵／監査ログ／バックアップ。そして予防>検知>対応、責任共有モデルを忘れない
ツールの選定・有効化は入口にすぎません。EMWがご一緒するのは、findingを「守る/許容/延期」に捌く運用の設計と、絶対防衛線の線引き、そして予防的ガードレールへの投資配分です。「たくさん入れたが、結局何から手を付ければ」の段階にいる方は、お問い合わせください。関連する具体策はクラウド設計ガイドラインとGuardDuty/Security Hub運用もどうぞ。
—参考(一次情報)
- Exposure findings in Security Hub (相関・到達性・攻撃経路の可視化) - AWS Security Hub
- AWS Security Hub now generally available with near real-time analytics and risk prioritization (2025刷新GA) - AWS News Blog
- Amazon Inspector scan types (EC2/ECR/Lambda・CVE) - Amazon Inspector
- What is Amazon GuardDuty? (脅威検知) - Amazon GuardDuty
- What Is AWS Config? (設定の記録と評価) - AWS Config
- Security Pillar - AWS Well-Architected Framework
- AWS Trusted Advisor (サポートプランと利用範囲) - AWS Support