AWSは設計段階から監査ログの仕組みを組み込んでおかなければ、後から取り出せない情報が多数あります。AWS CloudTrailとAWS Configは、そのための中核サービスです。
この記事では、CloudTrailによる「誰が・いつ・何を操作したか」のAPI操作ログと、AWS Configによる「リソース設定の変更履歴・コンプライアンス評価」を組み合わせた監査証跡の設計方法を解説します。CloudWatch監視（メトリクス・アラーム）との棲み分けも明確にしながら、ガバナンス層の構成として実務で使えるベストプラクティスをまとめます。
この記事のポイント
・CloudTrailはAPIコール全記録、ConfigはAWSリソースの設定状態変化を記録する
・2つを組み合わせて「変更の操作者」と「リソースの変化前後」を突き合わせた証跡が完成する
・証跡はマルチリージョン＋S3永続保存が前提。改ざん防止にはLogFileValidationを有効化する
・Config Rulesでコンプライアンス違反を自動検出し、修復アクションまで自動化できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
AWS CloudTrailとConfigとは何か（概要・違い）
AWSの監査ログ設計を語る上で、まず2つのサービスの役割の違いを正確に把握しておく必要があります。混同されがちなサービスですが、記録する対象がまったく異なります。AWS CloudTrailは、AWSアカウント内で発生したすべてのAPIコールを記録するサービスです。「誰が（IAMユーザー・ロール）」「いつ（タイムスタンプ）」「どのリソースに対して（ARN）」「何の操作をしたか（APIアクション名）」という4要素を、ほぼリアルタイムでJSONログとしてS3に書き込みます。マネジメントコンソールからの操作も、CLI・SDKからの操作も、すべてAPIコールとして記録されます。
AWS Configは、AWSリソースの設定状態を継続的にスナップショットとして記録し、変更履歴を管理するサービスです。「EC2インスタンスのセキュリティグループが変わった」「S3バケットのパブリックアクセスがONになった」「IAMポリシーのアタッチ先が変わった」といった設定の変化を、変更前後の値と比較しながら追跡できます。
2つのサービスの立ち位置を整理すると、次のようになります。
| サービス | 何を記録するか | 主な用途 |
|---|---|---|
| AWS CloudTrail | APIコール（操作ログ） | 誰が・いつ・何をしたか（操作主体の追跡） |
| AWS Config | リソースの設定状態（設定ログ） | 何が変わったか（設定変化の追跡・コンプライアンス評価） |
| Amazon CloudWatch | メトリクス・ログ（監視ログ） | リソースの稼働状態・パフォーマンス異常の検知 |
CloudTrailで「誰が・いつ・何を操作したか」を記録する仕組み
CloudTrailはデフォルトで、AWSアカウントの各リージョンで過去90日間のイベント履歴をコンソール上で確認できます。ただし90日を超えるログ保存や、複数アカウント・リージョンの一元管理、改ざん防止といった要件を満たすには、「証跡（Trail）」の明示的な設定が必要です。1. 証跡（Trail）の作成とマルチリージョン設定
CloudTrailの証跡を作成する際は、すべてのリージョンを対象にする設定（「すべてのリージョンに適用」）を必ず有効にしてください。リージョンを絞ると、攻撃者が意図的に別リージョンでリソース操作を行った場合にログが取れません。CloudTrailには記録するイベントの種類として「管理イベント（Management Events）」と「データイベント（Data Events）」があります。
・管理イベント：IAMロールの作成・削除、EC2の起動・停止、セキュリティグループの変更など。デフォルトで有効。監査の基本はこれで9割カバーできます
・データイベント：S3オブジェクトの読み書き、Lambda関数の実行など、リソースの「中身」への操作。量が膨大になるため、機密バケット・重要Lambda関数に絞って有効化するのが現実的です
2. S3への永続保存と改ざん防止
証跡ログはS3バケットに永続保存されます。設定時に「ログファイルの整合性検証（Log File Validation）」を有効にしてください。CloudTrailが毎時ダイジェストファイルを生成し、後からログが改ざんされていないことをSHA-256ハッシュで検証できます。セキュリティインシデント発生時や外部監査での証拠提出時に、ログの信頼性を担保できます。S3バケット側では以下の設定を合わせて行うことを推奨します。
・バケットポリシー：CloudTrailサービスプリンシパル（cloudtrail.amazonaws.com）からのみ書き込みを許可
・MFAデリート：ログの削除にMFAを要求（改ざん防止の最終ライン）
・S3ライフサイクル：7年以上の保存が求められる場合はS3 Glacierへの自動移行を設定
3. CloudTrailログの構造と読み方
CloudTrailのイベントレコードは、JSON形式で以下のような情報を含みます。# CloudTrailイベントレコードの主要フィールド（抜粋） { "eventTime": "2026-07-10T09:15:30Z", "eventSource": "ec2.amazonaws.com", "eventName": "AuthorizeSecurityGroupIngress", "userIdentity": { "type": "IAMUser", "userName": "dev-operator" }, "sourceIPAddress": "203.0.113.x", "requestParameters": { ... }, "responseElements": { ... } }
AWS Configで「リソース設定の変更履歴」を管理する仕組み
CloudTrailが「誰が何をしたか」の操作ログであるのに対し、AWS Configは「AWSリソースが今どういう状態か、以前はどういう状態だったか」を継続的に記録します。1. 設定スナップショットと変更履歴
AWS Configを有効化すると、対象リソース（EC2、S3、IAM、VPC、RDSなど）の設定状態を定期的に記録します。設定に変化があると、変更前後の状態をJSONで比較して「設定変更履歴（Configuration History）」として保存します。たとえば「S3バケットのパブリックアクセスブロックがOFFになった」という変更は、Configの変更履歴から変更前後の設定値と変更タイムスタンプを即座に確認できます。このタイムスタンプをもとにCloudTrailのログを検索すると、誰がその変更を行ったAPIコールかを特定できます。
2. AWS Config Rules（コンプライアンスルール）
AWS Configの真価はConfig Rulesにあります。「あるべき設定状態」をルールとして定義しておき、実際の設定と照合してコンプライアンス準拠・違反を自動評価します。AWSが提供するマネージドルール（AWS Managed Rules）を利用すると、即日で監査基準を設定できます。代表的なものを示します。
・s3-bucket-public-read-prohibited：S3バケットのパブリック読み取りが禁止されていることを確認
・iam-root-access-key-check：rootアカウントのアクセスキーが存在しないことを確認
・ec2-instance-no-public-ip：EC2インスタンスにパブリックIPが付与されていないことを確認
・cloudtrail-enabled：CloudTrailが全リージョンで有効であることを確認
・mfa-enabled-for-iam-console-access：コンソールアクセス可能なIAMユーザーにMFAが設定されていることを確認
ルールに違反したリソースを検出したら、AWS Systems Manager Automationと連携させることで自動修復（Auto Remediation）も可能です。たとえば「パブリックアクセスがONになったS3バケットを自動でOFFに戻す」といった対応を自動化できます。
CloudTrailとConfigを組み合わせた監査ログ設計のベストプラクティス
2つのサービスを別々に設定するだけでは、監査証跡の設計として不完全です。組み合わせることで初めて「変更の全貌」が把握できます。1. AWS Organizations＋組織証跡で全アカウント一元管理
複数のAWSアカウントを運用している場合（マルチアカウント構成）、各アカウントで個別にCloudTrailを設定するのは管理コストが高くなります。AWS Organizationsを使った組織証跡（Organization Trail）を活用すると、Organizations内の全メンバーアカウントのCloudTrailログを、管理アカウントが管理するS3バケットに一元集約できます。AWS Configも同様に、Configのアグリゲーター機能（Aggregator）を使うことで、複数アカウント・リージョンのコンプライアンス状況を一元的なダッシュボードで把握できます。セキュリティ担当者が個別アカウントにログインしてConfigを確認する手間がなくなります。
マルチアカウント・マルチリージョン構成の設計指針については、AWSの上級講座でより詳しく解説しています。AWSマスターセミナー上級編の詳細はこちらをご確認ください。
2. CloudTrailとConfigの時系列連携（タイムライン調査の設計）
監査調査の実務では、CloudTrailとConfigのログを時系列で突き合わせる作業が発生します。設計時点で以下の連携を考慮しておくと、調査時の作業効率が大幅に向上します。・Amazon Athena＋S3：CloudTrailのJSONログをS3に保存し、Athenaでクエリ検索できる構成にする。特定のIAMユーザーや特定のAPIアクションを瞬時にフィルタリングできます
・AWS CloudTrail Lake：SQLライクなクエリでCloudTrailイベントを直接検索できるマネージドサービス。Athenaよりセットアップが手軽で、近年の推奨構成です
・Amazon Security Hub：ConfigのコンプライアンスデータとCloudTrailのイベントを統合し、セキュリティ問題を一元管理します
3. S3バケットの設計（ログ保管バケットの分離）
CloudTrailとConfigのログを保管するS3バケットは、通常のワークロードとは別の専用バケットを用意してください。バケット側にはS3バケットポリシーとオブジェクトロック（WORM設定）を組み合わせて、ログの削除・上書きを物理的に防止する構成が理想です。実際の監査シナリオと調査方法
設計した監査ログがどのように実務で機能するか、代表的な2つのシナリオを示します。1. セキュリティインシデント調査（不正アクセス疑い）
「本番S3バケットのオブジェクトが外部から参照された可能性がある」という報告を受けた場合の調査フローです。# 調査フロー例 # ステップ1: AWS Configで当該S3バケットの設定変更履歴を確認 # → パブリックアクセスブロックがいつOFFになったか、変更前後の値を確認 # ステップ2: 変更タイムスタンプをもとにCloudTrail Lakeで検索 # S3バケットのパブリックアクセス設定を変更したAPIコールを特定 # (CloudTrail Lake のクエリ例) # SELECT eventTime, userIdentity.userName, sourceIPAddress # FROM cloud_trail_events # WHERE eventName = 'PutBucketPublicAccessBlock' # AND eventTime BETWEEN '2026-07-01' AND '2026-07-14' # ステップ3: 操作者のIAMユーザー/ロールが想定内か確認 # → 想定外のユーザー・IPアドレスなら侵害の可能性を検討 # ステップ4: 同一セッションで行われた他の操作をCloudTrailで連鎖調査
2. コンプライアンス監査対応（外部審査・ISO27001等）
外部審査機関から「過去1年間のAWSリソース変更履歴と、セキュリティ基準への準拠状況を提出してください」と求められた場合の対応フローです。・設定変更履歴の提出：AWS Configの設定変更履歴レポートをエクスポートし、対象期間のリソース変更一覧を提出
・コンプライアンス評価レポート：Config RulesのコンプライアンスレポートをエクスポートSし、評価対象ルールごとの準拠/違反状況と違反発生日時を提出
・操作証跡の提出：重要変更に対応するCloudTrailのイベントレコードを特定し、操作者・タイムスタンプ・操作内容をセットで提出
「CloudTrailを有効にしていなかった」「Configを入れていなかった」という状況では、こうした審査に対応できません。監査ログ設計は、システム構築と同時に着手するのが鉄則です。
設計上の注意点とコスト最適化
1. CloudTrailのデータイベントはコストに注意
CloudTrailの管理イベントはデフォルト無料（最初のトレイル）ですが、データイベント（S3オブジェクトのGetObject・PutObjectなど）は有料です。大規模S3を運用している場合、データイベントを全バケット対象にすると想定外の課金が発生します。機密性の高い特定バケット・特定Lambda関数に絞って有効化してください。2. AWS Configの記録対象リソースの選定
AWS Configは記録対象リソース数に応じて課金されます。「すべてのリソースタイプを記録」に設定すると、EC2・S3・IAM・VPC・RDS・Lambda・CloudFormation等のすべての変更が記録されますが、コストが増加します。ガバナンス上重要なリソースタイプ（IAM・S3・EC2のセキュリティグループ・VPC）に絞り込むことで、コストを抑えながら必要な監査証跡を確保できます。3. ログの保存期間とS3ライフサイクルポリシー
監査目的での保存期間は、業界や規制によって異なります。・一般的な目安：CloudTrailログは最低1年保存（不正アクセス発覚の遅延を考慮）
・PCI DSS準拠：1年以上（直近3ヶ月はオンライン、残り9ヶ月以上はアーカイブ）
・ISO27001：監査ログの保存期間は組織のセキュリティポリシーによる（1年以上が一般的）
S3のライフサイクルポリシーで「90日後にS3 Intelligent-Tieringへ移行」「1年後にS3 Glacierへ移行」という設定をすることで、長期保存のコストを大幅に削減できます。
まとめ・次のステップ
AWS CloudTrailとConfigによる監査ログ設計の要点を整理します。| 設計項目 | 推奨設定・ポイント |
|---|---|
| CloudTrail証跡 | 全リージョン適用・Log File Validation有効・S3への永続保存 |
| CloudTrailデータイベント | 機密バケット・重要Lambdaに絞って有効化（コスト管理） |
| AWS Config記録 | IAM・S3・EC2 SG・VPC等の重要リソースを優先記録 |
| Config Rules | マネージドルール活用＋自動修復で違反を即時対応 |
| マルチアカウント | 組織証跡＋Configアグリゲーターで全アカウント一元管理 |
| ログ保存 | S3ライフサイクルポリシーでコスト最適化（Glacier移行） |
| インシデント調査 | CloudTrail LakeまたはAthenaでSQLクエリ検索 |
AWSのガバナンス設計・セキュリティ設計・マルチアカウント構成をさらに体系的に学びたい方は、AWSマスターセミナー上級編での実践ハンズオンを検討してみてください。
AWSのガバナンス設計も、Linuxサーバーの「型」がわかれば本質は同じです
CloudTrailやConfigの設定も、根底にあるのはLinuxサーバー運用の設計思想です。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：AWS BackupでEC2・RDS・EFSのバックアップを一元管理する方法｜バックアッププランと復元テストの運用設計
- この記事の属するカテゴリ：AWS(Amazon Linux)へ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます