セキュリティ分析・検出サービスの役割

1. 最初に「何を検出したいか」を決める

AWSには複数のセキュリティ分析サービスがあります。しかし「セキュリティを強化したいから全部有効化する」だけではアーキテクチャ判断になりません。まず、何を知りたいのかを分けます。

重要なのは、各サービスが異なる根拠からセキュリティリスクを判断していることです。

2. IAM Access Analyzerは「誰がアクセスできるか」を分析する

IAM Access AnalyzerはIAM ポリシーやリソースベースのポリシーなどを分析し、「このリソースへ誰がアクセス可能か」を判断します。

リソース
   │
   ├─ リソースベースのポリシー
   ├─ アイデンティティベースのポリシー
   └─ ガードレール
        │
        ▼
IAM Access Analyzer
        │
        ▼
実効アクセス / 検出結果

現行仕様では、IAM Access Analyzerは外部アクセス・内部アクセス・未使用アクセスについて検出結果を生成できます。

3. 外部アクセスは信頼境界の外を探す

外部IAM Access Analyzerでは、AWSアカウントまたはAWS Organizationsを信頼ゾーンとして定義し、その外部プリンシパルへリソースアクセスが許可されている場合に検出結果を生成します。

信頼済みゾーン
AWS 組織
     │
     ▼
リソースポリシー
     │
     └── 組織外プリンシパル
             ↓
      外部アクセスの検出結果

S3 バケット、KMSキー、IAMロール、SQS キュー、Secrets Manager シークレットなど、対応リソースのポリシーを分析できます。ここで重要なのは、実際に攻撃されたことを検出するのではなく、ポリシー上成立するアクセス経路を分析していることです。

4. 内部アクセスは組織内部のアクセス経路を見る

現在 IAM Access Analyzerでは、組織やアカウント内部のIAMユーザー / ロールから、指定したリソースへどのアクセスが成立するかも分析できます。

内部プリンシパル
      │
      ├─ アイデンティティポリシー
      ├─ リソースポリシー
      ├─ SCP / RCP
      └─ 権限 境界
              │
              ▼
       実効アクセス 経路

したがって、外部アクセスは信頼境界の外側、内部アクセスは信頼境界の内側という違いで整理します。

5. 未使用アクセスは最小権限の改善に使う

IAM Access Analyzerの未使用アクセス分析では、未使用ロール、未使用アクセスキー / パスワード、未使用権限などを検出結果として確認できます。

アプリケーションロール
↓
s3:*
ec2:*
rds:*

実際に使用
↓
s3:GetObjectのみ

↓
未使用権限を削減候補へ

つまり、誰がアクセスできるかは外部 / 内部アクセス、与えた権限を本当に使っているかは未使用アクセスとして判断します。

現在AWS Security Hubでも未使用アクセス検出結果を生成できます。AWS Security Hubを有効化すると、サービスにリンクされたIAM Access Analyzerが自動的に作成され、AWS CloudTrailのアクティビティデータを使って90日間の固定参照期間で未使用アクセスを評価します。対象は未使用IAMロール、未使用IAMユーザーアクセスキー、未使用IAMユーザーパスワード、未使用権限です。このサービスにリンクされたアナライザーは、自分で作成するカスタマーマネージド IAM Access Analyzerとは別のアナライザーです。

したがって、現在アーキテクチャでは「未使用アクセス分析はIAM Access Analyzerだけで確認し、AWS Security Hubは関係しない」とは判断しません。AWS Security Hub自身もIAM Access Analyzerを利用して未使用アクセス検出結果を提供します。

6. Amazon Inspectorは脆弱性管理

Amazon Inspectorは、ソフトウェアに既知の脆弱性があるか、またはワークロードが意図せずネットワークから到達可能になっていないかを継続的に評価する脆弱性管理サービスです。

現在のAmazon Inspectorにはコードセキュリティもあります。アーキテクチャ選択では、EC2・ECRコンテナイメージ・Lambdaなどのワークロードの脆弱性とEC2のネットワーク到達可能性を評価する責任をまず押さえます。

7. ソフトウェア脆弱性を継続的に検出する

例えばEC2インスタンス、ECR イメージ、Lambda 依存関係に既知のCVEが含まれている場合、Amazon Inspectorは脆弱性検出結果を生成できます。

ワークロード
   │
   ├─ OS パッケージ
   ├─ 言語パッケージ
   └─ コンテナ / Lambda 依存関係
          │
          ▼
     Amazon Inspector
          │
          ▼
    脆弱性 検出結果

ここで判断しているのは「不審なアクティビティが起きたか」ではなく、ワークロードに攻撃へ利用され得る弱点が存在するかです。

8. InspectorはEC2のネットワーク到達可能性も評価する

Amazon InspectorはEC2について、インターネットゲートウェイ、ロードバランサー、VPC ピアリング、VPNなどVPC境界から開放されたネットワーク経路が存在するかも評価できます。

インターネット / VPC境界
        │
        │ TCP 22へ到達可能
        ▼
       EC2
        │
        ▼
ネットワーク到達可能性の検出結果

ルートテーブル、セキュリティグループ、ネットワークACLなどの設定結果として、EC2へ意図しない経路が成立していないかを確認する用途です。

9. IAM Access Analyzerの外部アクセスとInspectorのネットワーク到達可能性は違う

「公開されている」という日本語だけでサービスを決めず、ポリシーによるアクセスなのか、ネットワーク経路による到達可能性なのかを見分けます。

10. Amazon GuardDutyは脅威検知

Amazon GuardDutyは、AWS環境で発生している潜在的に悪意のある / 不正なアクティビティを検出する脅威検知サービスです。

セキュリティテレメトリ
      │
      ▼
Amazon GuardDuty
      │
      ▼
脅威検出結果

例えば、通常と異なるAPI利用、既知の悪意あるIPとの通信、不審なDNSクエリ、認証情報侵害の兆候などを検出します。

11. GuardDutyはセキュリティテレメトリを分析する

GuardDutyの基本データソースには現在、AWS CloudTrail管理イベント、VPC フローログ、Route 53 Resolver DNSクエリログがあります。

CloudTrail管理イベント ─┐
VPCフローログ ────────────────┼─→ GuardDuty
Route 53 Resolver DNS ────────┘
                                ↓
                           脅威検出結果

GuardDutyはこれらを独立したデータストリームとして分析します。CloudTrailやVPC フローログを自分のS3 バケットへ保存しておかないとGuardDutyが動かない、という関係ではありません。

12. 脆弱性と脅威を分ける

前者は攻撃可能な弱点、後者は脅威らしいアクティビティを見ています。Inspector 検出結果は侵害済みの証拠ではなく、GuardDuty 検出結果もソフトウェア CVEの存在を意味するわけではありません。

13. 検出結果はサービスごとに意味が違う

「検出結果」という言葉は共通していますが、中身は同じではありません。

したがって、「セキュリティ検出結果を集めたい」と書かれていても、まずどの検出結果を生成するサービスが必要なのかを判断します。

14. 現行仕様ではAWS Security HubとSecurity Hub CSPMを分ける

現在のAWS公式では、AWS Security HubとAWS Security Hub CSPMが補完関係にある別サービスとして整理されています。

Security Hub CSPM
→ セキュリティ状態
→ 標準 / 制御
→ コンプライアンス可視性

AWS Security Hub
→ 複数セキュリティシグナルを相関
→ 露出の検出結果
→ リスクの優先順位付け

Security Hub CSPMの検出結果はAWS Security Hubへ自動的に送られ、InspectorやGuardDutyなどのシグナルと組み合わせて露出の検出結果を生成できます。SAP-C02で旧来の「AWS Security Hub」という表記が出ても、現在の責任分離を理解したうえで要件から判断します。

検出結果の標準形式も区別します。Security Hub CSPMはAWS Security Finding Format（ASFF）を使用し、AWS Security HubはOpen Cybersecurity Schema Framework（OCSF）を標準形式として使用します。同じ「Security Hub」という名称でも、現行サービスとCSPMで形式を混同しないことが重要です。

15. Security Hub CSPMはコンプライアンス可視性を提供する

Security Hub CSPMではセキュリティ標準を有効化すると、その標準に含まれるセキュリティ制御を評価し、制御検出結果を生成します。

セキュリティ標準
      │
      ▼
セキュリティ制御
      │
      ▼
合格 / 不合格の検出結果
      │
      ▼
セキュリティ状態 / コンプライアンス可視性

AWS Foundational Security Best PracticesやCISなどに対するセキュリティ状態を継続確認したい場合は、Security Hub CSPMが中心です。

16. Security Hub CSPMは検出結果を標準形式へ統合する

Security Hub CSPMは自身の制御検出結果に加え、Amazon GuardDuty、Amazon Inspector、IAM Access Analyzerの対応する外部アクセス / 未使用アクセス検出結果など、複数のAWSセキュリティサービスから検出結果を受け取れます。

IAM Access Analyzerについて、Security Hub CSPMとの統合対象として明示されているのは外部アクセス検出結果と未使用アクセス検出結果です。内部アクセス検出結果まで同じ扱いになるとは判断しません。

GuardDuty 検出結果 ─────┐
Inspector 検出結果 ─────┼─→ Security Hub CSPM
IAM Access Analyzer 外部 / 未使用アクセス検出結果┘          │
                                  ▼
                                 ASFF

受信した検出結果はAWSセキュリティ検出結果形式（ASFF）へ正規化されます。ただし、Security Hub CSPMへ集約したから元サービスの検知機能が不要になるわけではありません。

17. AWS Security Hubは複数シグナルを相関して露出を優先する

現在AWS Security Hubでは露出の検出結果があります。同じリソースに脆弱性、設定ミス、脅威など複数のシグナルが存在する場合、それらとリソースとの関係を相関して潜在的なセキュリティリスクを優先します。

Inspector
→ 重要な脆弱性

Security Hub CSPM
→ 設定ミス

GuardDuty
→ 不審なアクティビティ

        ↓ 相関

AWS Security Hub
→ 露出の検出結果
→ リスクの優先順位付け

「検出結果を1件ずつ見る」だけではなく、複数シグナルを組み合わせたとき何が最も危険かを判断する役割です。

18. 「公開」とSecurity Hubの「露出」を分ける

サービスごとに「公開」や「露出」が示す範囲は異なります。Security Hubの露出は、単にインターネットへ公開されていることだけを意味しません。

ポリシー上の組織外アクセス
→ IAM Access Analyzer

EC2のネットワーク到達可能性
→ Amazon Inspector

アクティブな脅威シグナル
→ Amazon GuardDuty

セキュリティ制御 / コンプライアンス
→ Security Hub CSPM

脆弱性・設定・ネットワーク・権限・脅威・リソース関係などを相関
→ AWS Security Hubの露出の検出結果

AWS Security Hubでは、複数のシグナルを相関し、潜在的な攻撃経路や影響範囲を含めて優先順位付けします。したがって、露出 = インターネット公開と短絡しないことが重要です。

19. AWS Security Hubは検知サービスの代わりではない

AWS Security Hub / Security Hub CSPMは、送信元検知サービスを置き換えるものではありません。

送信元検知と集約 / 優先順位付けを分離して考えることが重要です。

20. 要件からサービスを選ぶ

21. 混同ポイント

• IAM Access Analyzer = 脅威検知：ポリシー上のアクセスを分析するサービスです。
• Amazon Inspector = 攻撃検知：主に脆弱性 / ネットワーク到達可能性を評価します。
• Amazon GuardDuty = 脆弱性スキャナー：セキュリティテレメトリから脅威を検出します。
• Security Hub CSPM = GuardDutyの代替：状態 / コンプライアンスと検出結果統合が中心です。
• AWS Security Hub = Security Hub CSPMと完全に同じ：現行仕様では責任が分かれています。
• 検出結果 = すべて同じ意味：送信元サービスによって根拠が異なります。
• コンプライアンス合格 = アクティブ脅威が存在しない保証：コンプライアンス状態と脅威検知は別の観点です。

22. SAP-C02判断フロー

セキュリティ上の問題を調べたい
        │
        ▼
何を知りたい？
        │
        ├─ アクセス可能性？
        │      ↓
        │ IAM Access Analyzer
        │
        ├─ 脆弱性 / 到達可能性？
        │      ↓
        │ Amazon Inspector
        │
        ├─ 不審なアクティビティ？
        │      ↓
        │ Amazon GuardDuty
        │
        ├─ コンプライアンス / ベストプラクティス？
        │      ↓
        │ Security Hub CSPM
        │
        └─ 複数シグナルを相関して
           重要な露出を優先？
               ↓
         AWS Security Hub

23. まとめ

IAM Access Analyzer
→ アクセス分析
→ 外部 / 内部 / 未使用

Amazon Inspector
→ 脆弱性管理
→ EC2 / ECR / Lambda
→ EC2 ネットワーク到達可能性

Amazon GuardDuty
→ 脅威検知
→ CloudTrail / VPC フロー / DNS等を分析

Security Hub CSPM
→ セキュリティ状態
→ 標準 / 制御
→ コンプライアンス可視性
→ 検出結果の統合 / ASFF

AWS Security Hub
→ サービスにリンクされたIAM Access Analyzerによる未使用アクセス検出結果
→ 複数セキュリティシグナルを相関
→ 露出の検出結果
→ リスクの優先順位付け

最重要ポイントは、「どのセキュリティサービスが一番強いか」ではなく、アクセス・脆弱性・脅威・コンプライアンス・相関された露出のどの問題を解きたいかでサービスを選ぶことです。

24. 主要AWS公式資料

• IAM Access Analyzerの検出結果
• IAM Access Analyzerの概念
• IAM Access AnalyzerとSecurity Hub CSPMの統合
• Amazon Inspectorの自動スキャンタイプ
• Amazon Inspectorの検出結果タイプ
• GuardDutyの基本データソース
• GuardDutyの検出結果
• AWS Security HubとSecurity Hub CSPM
• AWS Security Hub — OCSF
• Security Hub CSPMの検出結果 / ASFF
• AWS Security Hubの露出の検出結果
• AWS Security Hub — 未使用のアクセスの検出結果