本文へスキップ
BecomeCoder

AWS SAA（ソリューションアーキテクト）コース　·　第3章　セキュアなアーキテクチャ設計　·　レッスン17

脅威検知と監査

導入

どれだけ防御を固めても、「今まさに何か異常が起きていないか」「誰が何をしたか」を継続的に見張る仕組みがなければ、侵害に気づくのが遅れます。この章の最後に、検知・監査を担うサービス群を整理します。

説明

SAAで問われる検知・監査系サービスは役割がそれぞれ異なるため、「何を見張るか」で区別するのが最も確実です。

サービス見張る対象検知するもの
GuardDutyVPCフローログ・DNSログ・CloudTrailログ不審な通信、侵害の兆候（脅威検知）
InspectorEC2・ECR・Lambdaソフトウェアの脆弱性、意図しないネットワーク露出
MacieS3個人情報（PII）などの機微データの所在と公開状態
CloudTrail全AWSサービスへのAPI呼び出し「誰が・いつ・何をしたか」の操作履歴
AWS ConfigAWSリソースの構成構成変更の履歴、ベストプラクティスへの準拠状況
flowchart TD
    subgraph 検知
      GD["GuardDuty<br/>脅威検知"]
      IN["Inspector<br/>脆弱性診断"]
      MC["Macie<br/>機微データ検出"]
    end
    subgraph 監査
      CT["CloudTrail<br/>API操作の記録"]
      CFG["AWS Config<br/>構成の準拠チェック"]
    end
    GD --> SEC["セキュリティ運用チーム"]
    IN --> SEC
    MC --> SEC
    CT --> SEC
    CFG --> SEC

覚え方のコツは、対象で区別することです。

  • 「怪しい通信をしていないか」→ GuardDuty
  • 「ソフトウェアに既知の脆弱性がないか」→ Inspector
  • 「S3に個人情報が誤って公開されていないか」→ Macie
  • 「誰がこの設定を変更したか知りたい」→ CloudTrail
  • 「このリソースは社内ルールに準拠しているか継続的にチェックしたい」→ AWS Config

具体例

セキュリティ運用チームの1日を追うと、5つのサービスが「対象別」に働き分けているのが分かります。

  • 朝、GuardDutyが通知：「あるEC2が、既知の不正サーバーと通信しています」（＝通信の異常）
  • 調べようとCloudTrailを確認：「昨夜、退職者のはずの鍵でそのEC2が起動されていた」（＝誰がAPIを叩いたか）
  • 横展開を点検、Inspectorが報告：「他のEC2にも未パッチの既知脆弱性があります」
  • 念のためMacieでS3を走査：「あるバケットにマスキングされていない個人情報が公開状態」
  • 再発防止にConfigでルール化：「S3バケットは非公開であるべき」に反したら即通知（＝構成が基準通りかを継続監視）

覚え方は「見張る対象で区別」。通信＝GuardDuty、脆弱性＝Inspector、S3の個人情報＝Macie、API操作の記録＝CloudTrail、構成の準拠＝Config。特に「CloudTrailは“誰が何をしたか”、Configは“今どうなっているか”」の対比は頻出です。

読んでみよう

この5つは名前が似た響きを持たないため、SAA本番では「対象（ログ/脆弱性/S3データ/API呼び出し/構成）」で見分けるのが最速です。特に「CloudTrailは”誰が何をしたか”の記録、Configは”今どうなっているか”の構成管理」という対比は頻出なので、必ず区別できるようにしておきましょう。

次のレッスンへ →