CloudTrail・GuardDuty入門 監査と脅威検知の基本

「AWSアカウントで誰が何をしたのか、ちゃんと追跡できているだろうか」——クラウド環境を運用していると、こんな不安を感じたことはないでしょうか。

オンプレ環境であれば、syslogやauditdでサーバーの操作ログを取得し、OSSECやTripwireで不正アクセスを検知する仕組みを組んでいた方も多いはずです。

しかしAWSでは、サーバーだけでなくAPI操作そのものがインフラ変更に直結します。「誰がいつどのAPIを呼んだか」を記録する仕組みが欠かせません。

この記事では、AWSの監査ログサービス「AWS CloudTrail」と脅威検知サービス「Amazon GuardDuty」について、オンプレのログ管理との違いを交えながら、基本設定から実務での活用方法まで解説します。

なぜクラウドの監査ログ・脅威検知が重要なのか

オンプレ環境では、データセンターへの物理的な入退室管理と、OS上の操作ログ取得が主なセキュリティ対策でした。サーバールームに入れる人間は限られているし、SSHログインの記録はauth.logに残る。物理層とOS層の2つを押さえておけば、最低限の監査はできていました。

しかしクラウド環境では事情が異なります。AWSのマネジメントコンソールやCLIからAPIを1回叩くだけで、セキュリティグループの開放やS3バケットの公開といった重大な変更を実行できてしまいます。

しかもその操作は物理的な場所を問わず、世界中のどこからでも行えます。

・オンプレの監査: 物理入退室＋OS操作ログ（syslog/auditd）＋ネットワークIDS/IPS
・クラウドの監査: API操作ログ（CloudTrail）＋脅威検知（GuardDuty）＋ネットワークフローログ（VPC Flow Logs）

CloudTrailは「誰が何をしたか」を記録する監査ログ、GuardDutyは「怪しい動きがないか」を自動検知するマネージド型の脅威検知サービスです。この2つを組み合わせることで、オンプレ時代のsyslog＋IDS/IPSに相当する可視性を確保できます。

AWS CloudTrailの基本設定

1. CloudTrailとは何か

AWS CloudTrailは、AWSアカウント上で実行されたすべてのAPI呼び出しを自動的に記録するサービスです。オンプレでいえば、全サーバーのauditdログを一元的に収集・保管するSIEM（セキュリティ情報イベント管理）の入口に相当します。

記録される情報には以下が含まれます。

・誰が: IAMユーザー名、ロール、フェデレーションユーザー
・いつ: APIコールのタイムスタンプ（UTC）
・何を: 実行されたAPI名（例: RunInstances、PutBucketPolicy）
・どこから: 送信元IPアドレス
・結果: 成功・失敗とエラーコード

AWSアカウントを作成した時点で、CloudTrailはデフォルトで過去90日分のイベント履歴を保持しています。ただし、これだけでは長期保存やS3へのログ集約ができないため、「証跡（Trail）」を明示的に作成する必要があります。

2. 証跡（Trail）を作成する

マネジメントコンソールでの手順は以下の通りです。

1. AWSマネジメントコンソールで「CloudTrail」を検索して開く
2. 左メニューの「証跡」→「証跡の作成」をクリック
3. 証跡名を入力（例: main-audit-trail）
4. 「すべてのリージョンに適用」を有効化する。これを忘れると、東京リージョン（ap-northeast-1）以外の操作が記録されない
5. ログの保存先S3バケットを指定（新規作成または既存バケット）
6. ログファイルのSSE-KMS暗号化を有効にする（コンプライアンス要件がある場合は必須）
7. 「管理イベント」は読み取り・書き込みの両方を記録するよう設定
8. 「証跡の作成」をクリックして完了

AWS CLIで作成する場合は以下のコマンドを使います。

# CloudTrail証跡の作成（AWS CLI）
aws cloudtrail create-trail \
  --name main-audit-trail \
  --s3-bucket-name mycompany-cloudtrail-logs \
  --is-multi-region-trail \
  --enable-log-file-validation

# 証跡のロギングを開始
aws cloudtrail start-logging \
  --name main-audit-trail

# 証跡の状態を確認
aws cloudtrail get-trail-status \
  --name main-audit-trail

`–enable-log-file-validation`は、ログファイルが改ざんされていないことを検証するためのオプションです。オンプレ環境でログサーバーへの書き込み権限を制限していたのと同じ発想で、監査ログの信頼性を担保します。

3. CloudTrailログを検索・分析する

記録されたログは、CloudTrailコンソールの「イベント履歴」から直接検索できます。特定のIAMユーザーの操作を調べたい場合は、「ユーザー名」でフィルタリングするのが手っ取り早い方法です。

より高度な分析が必要な場合は、Amazon Athenaを使ってS3に保存されたログをSQLで検索できます。

# Athenaで特定ユーザーの操作を検索（SQL）
SELECT eventtime, eventsource, eventname,
       sourceipaddress, errorcode
FROM cloudtrail_logs
WHERE useridentity.username = 'target-user'
  AND eventtime > '2026-03-01'
ORDER BY eventtime DESC
LIMIT 100;

オンプレでgrepやawkでログを検索していた作業が、SQLで実行できるようになります。grepやawkの基礎を学びたい方はLinuxMaster.JPも参考にしてください。大量のログを横断的に分析する場合は、Athenaのほうが圧倒的に効率的です。

Amazon GuardDutyの基本設定

1. GuardDutyとは何か

Amazon GuardDutyは、AWSアカウント上の脅威をリアルタイムで自動検知するマネージドサービスです。CloudTrailのログ、VPC Flow Logs、DNSクエリログを機械学習で分析し、不審なアクティビティを検出します。

オンプレでいえば、SnortやSuricataといったIDS/IPSと、OSSEC等のHIDS（ホスト型侵入検知）を組み合わせた仕組みに相当します。ただし、GuardDutyはエージェントのインストールが不要で、有効化するだけで動作を開始する点が大きく異なります。

2. GuardDutyを有効化する

設定は驚くほど簡単です。

1. AWSマネジメントコンソールで「GuardDuty」を検索して開く
2. 「今すぐ始める」→「GuardDutyの有効化」をクリック

これだけです。裏側ではCloudTrailイベント、VPC Flow Logs、DNSログの分析が自動的に始まります。個別にログ転送を設定する必要はありません。

# GuardDutyの有効化（AWS CLI）
aws guardduty create-detector \
  --enable \
  --finding-publishing-frequency FIFTEEN_MINUTES

# 有効化の確認
aws guardduty list-detectors

オンプレ環境でIDS/IPSを導入する場合、ネットワークタップの設置、シグネチャの更新、チューニングに何週間もかかることがありました。GuardDutyはこれらをすべてAWSが管理してくれるため、有効化した瞬間から脅威検知が始まります。

3. 検出結果（Findings）を確認・対応する

GuardDutyが脅威を検出すると「検出結果（Finding）」として通知されます。検出結果には重要度が3段階で付与されます。

・High（高）: 即座に対応が必要。例: EC2インスタンスが暗号通貨マイニングに利用されている
・Medium（中）: 調査が必要。例: 通常と異なるリージョンからのAPI呼び出し
・Low（低）: 確認推奨。例: 通常と異なるIPアドレスからのコンソールログイン

検出結果の通知を自動化するには、Amazon EventBridgeと連携してAmazon SNSで通知を飛ばす構成が定番です。

# EventBridgeルールの作成（GuardDuty High/Medium検出時にSNS通知）（AWS CLI）
aws events put-rule \
  --name guardduty-high-medium-alerts \
  --event-pattern '{
    "source": ["aws.guardduty"],
    "detail-type": ["GuardDuty Finding"],
    "detail": {
      "severity": [{"numeric": [">=", 4]}]
    }
  }'

# SNSトピックをターゲットに設定
aws events put-targets \
  --rule guardduty-high-medium-alerts \
  --targets "Id"="1","Arn"="arn:aws:sns:ap-northeast-1:123456789012:security-alerts"

料金の仕組み

CloudTrailとGuardDutyの料金体系は以下の通りです（2026年3月時点、東京リージョン）。

CloudTrailは最初の証跡（管理イベント）が無料のため、基本的な監査ログの取得にはほぼコストがかかりません。S3へのログ保存料金は別途発生しますが、ライフサイクルルールでGlacierに移行すれば長期保存のコストも抑えられます。

GuardDutyは従量課金ですが、まず30日間の無料トライアルで実際のコストを確認できます。中小規模の環境であれば月額数ドル程度に収まることが多く、オンプレでIDS/IPSのアプライアンスを導入するコストと比べれば桁違いに安価です。

応用・実務Tips

CloudTrailとAWS Organizationsの統合

複数のAWSアカウントを運用している場合、AWS Organizationsの「組織の証跡」を使えば、全アカウントのCloudTrailログを1つのS3バケットに集約できます。オンプレで各サーバーのsyslogを中央のログサーバーに転送していたのと同じ構成です。

各アカウントで個別に証跡を作成する必要がなくなるため、管理の手間が大幅に減ります。セキュリティチームが一元的にログを監査する運用には必須の設定です。

GuardDutyの抑制ルールで誤検知を減らす

GuardDutyは機械学習ベースのため、正常な運用操作を脅威として検出する場合があります。たとえば、社内のペネトレーションテスト用IPアドレスからのスキャンが毎回検出されるようなケースです。

こうした場合は「抑制ルール（Suppression Rule）」を設定して、特定条件に一致する検出結果を自動的にアーカイブできます。ただし、抑制ルールの設定は必要最小限にとどめてください。過度な抑制は本物の脅威を見逃す原因になります。

CloudTrail Insightsで異常を自動検出する

CloudTrail Insightsを有効にすると、API呼び出しのパターンを学習し、通常と異なるアクティビティを自動で検出してくれます。たとえば、普段は1日に数回しか呼ばれないAPIが突然数百回呼ばれた場合にアラートが上がります。

GuardDutyがネットワークレベルの脅威検知に強いのに対し、CloudTrail InsightsはAPI操作の異常検知に特化しています。両方を有効にすることで、より広範な可視性を確保できます。

よくあるトラブルと対処法

CloudTrailのログが見つからない

「特定の操作のログがCloudTrailに記録されていない」という問い合わせは現場でよく発生します。確認すべきポイントは以下の通りです。

・リージョンの設定: 証跡が「すべてのリージョン」に適用されているか。リージョン限定の証跡だと、他リージョンの操作が記録されない
・データイベントの記録: S3オブジェクトレベルの操作（GetObject、PutObject）やLambda関数の呼び出しは「データイベント」に分類される。デフォルトでは記録されないため、明示的に有効化する必要がある
・ログの配信遅延: CloudTrailのログはリアルタイムではなく、最大15分程度の遅延がある。直前の操作が見えない場合は少し待ってから再確認する

GuardDutyの検出結果が多すぎる

有効化直後は大量の検出結果が出ることがあります。落ち着いて以下の手順で対応してください。

1. まずHighの検出結果に集中する。暗号通貨マイニング（CryptoCurrency:EC2/BitcoinTool.B!DNS等）は即対応
2. Medium/Lowは内容を確認し、既知の運用操作であれば抑制ルールを設定
3. 「Recon:EC2/PortProbeUnprotectedPort」が頻出する場合は、セキュリティグループでインバウンドルールを見直す

GuardDutyのコストが想定より高い

VPC Flow Logsの分析量がコストの大部分を占めることがあります。大量のネットワークトラフィックが発生するワークロード（動画配信、大規模データ転送等）を運用している場合は、GuardDutyコンソールの「使用状況」タブで内訳を確認し、必要に応じてVPC Flow Logs分析の対象を調整してください。

本記事のまとめ

CloudTrailとGuardDutyは、クラウドセキュリティの基盤となるサービスです。CloudTrailの証跡作成は最初の1つが無料で、GuardDutyも有効化ボタンを押すだけ。この2つを設定していない本番アカウントがあれば、今日中に有効化してください。

オンプレ時代にsyslogの設定やIDS/IPSのチューニングに苦労した経験がある方なら、このマネージドサービスの手軽さに驚くはずです。設定の手間はほぼゼロで、運用後の監視・対応に集中できる。これがクラウドネイティブなセキュリティ監視の強みです。セキュリティの基礎知識については、姉妹サイトセキュリティマスターズ.TOKYOでも解説しています。