はじめに
概要
本ドキュメントは、AWSにおける操作履歴（ログ）に関する検索キーワードの意図を整理し、関連する解説をまとめたものです。主にCloudTrailやCloudWatch Logsを使ったログ確認方法、ログの検索・分析手法、監査やセキュリティ強化に役立つ運用のポイントを扱います。
対象読者
- AWSの基本知識を持つ開発者・運用担当者
- ログを使って不正アクセスや操作ミスを調べたい方
- 監査やセキュリティ対策の導入を検討している方
本書の目的
各章で実務に役立つ手順や考え方を具体例とともに示します。コマンドや設定の細かな説明も載せますが、まずはログの役割と検索の考え方を理解できる構成にしています。
使い方・前提
特別な環境は不要です。AWSマネジメントコンソールや基本的なCLI操作がわかれば読み進められます。具体的な手順は画面イメージやコマンド例を示しますので、実際に手を動かしながら学べます。
本書の構成
第2章以降で、ログの確認方法、クエリの使い方、Lambdaやセッションマネージャーのログ取得、CloudTrailの活用法などを順序立てて解説します。各章は独立して参照できます。
AWS CloudTrailでコンソールログイン履歴を確認する方法
概要
CloudTrailはAWSで行われた管理操作やAPI呼び出しを記録します。コンソールのログイン履歴は「ConsoleLogin」イベントとして残り、誰がいつどこからログインしたかを確認できます。
手順（コンソールで確認）
- AWSマネジメントコンソールにログインし、CloudTrailを開きます。
- 左メニューの「イベント履歴（Event history）」をクリックします。
- 検索欄でEvent nameに「ConsoleLogin」と入力します。期間やユーザー名で絞り込めます。
- 該当イベントを選ぶと詳細が開きます。userIdentity.userNameでユーザー名、sourceIPAddressで接続元IPが分かります。
- ログイン成功/失敗はイベント内のフィールド（例: responseElementsやerrorCode）で判別できます。追加EventデータでMFA使用の有無（additionalEventData.MFAUsed）が確認できます。
ポイントと注意点
- CloudTrailの管理イベント記録が有効でないと履歴に残りません。トレイルを作成しておくとS3やCloudWatch Logsへ保存できます。
- 不正アクセスを疑う場合は該当IPや時間帯の他サービス操作ログも合わせて調べると確実です。
具体的な画面操作を追えば、誰がどこからどのようにログインしたかを短時間で把握できます。
Amazon CloudWatch Logsとは？ログ収集・監視など
概要
Amazon CloudWatch Logsは、AWSリソースやアプリケーションのログを一元的に収集・保管・検索・監視するサービスです。ログを使って障害調査や動作確認、セキュリティ監査が行えます。
ログの構成
- ロググループ：関連するログをまとめる単位で、保存期間（Retention）を設定できます。
- ログストリーム：各インスタンスやアプリごとの時系列ログです。
コンソールでの確認手順
- AWSコンソールのCloudWatchを開く
- 「ロググループ」から該当グループを選択
- ログストリームを選び、時間範囲や検索フィルターで絞り込む
フィルターにはキーワードや正規表現が使えます。
CloudWatch Logs Insightsの紹介
Logs InsightsはSQLライクなクエリで高速に検索・集計できます。例：
fields @timestamp, @message | filter @message like /ERROR/ | sort @timestamp desc | limit 20
このように頻度や発生源の特定が簡単です。
ユースケースと注意点
- ユースケース：トラブルシューティング、パフォーマンス分析、監査ログの保管
- 注意点：長期間の保存はコストが増えるためRetention設定を見直す、JSON形式のログにすると解析が楽になります。IAMで閲覧権限を適切に管理してください。
AWSのログイン履歴確認法｜セキュリティ強化のポイント
ConsoleLogin イベントで履歴を見る
AWSでは、CloudTrailの「ConsoleLogin」イベントでコンソールのサインイン履歴を確認できます。CloudTrailのイベント履歴やS3に保存したログから、eventName=ConsoleLoginを検索してください。ログにはイベント時刻、送信元IP、ユーザー名、リージョンなどが含まれます。
絞り込みのポイント
- 期間: 調査したい期間で絞り込みます（例: 過去7日）。
- ユーザー: IAMユーザー名やフェデレーションユーザーで指定できます。例: aliceで検索。
- イベントソース: eventSourceにsignin.amazonaws.comを指定すると、サインインに関する詳細が得られます。追加データとしてMFAの有無やUserAgent、sourceIPAddressが確認できます。
異常検知の例と対策
- 短時間に失敗ログインが続く → ブルートフォースの可能性があるため対象ユーザーの認証情報をロック・更新します。
- 不慣れなリージョンやIPからの成功ログイン → 該当セッションを調査し、必要ならパスワードとアクセスキーを更新します。
- 深夜のアクセスや普段使わない端末からのログイン → ユーザーに確認し、不正ならMFA強制化やアクセス制限を行います。
運用で押さえておきたい設定
- CloudTrailを組織全体に適用して全アカウントのログを集約します。
- ログはS3で暗号化し、バケットポリシーで書き換えを防ぎます。
- CloudWatch Logs InsightsやアラームでConsoleLoginの失敗や不審な成功を自動検出し、SNSで通知する運用を用意します。
これらを組み合わせると、ログインの早期発見と迅速な対応が可能になり、セキュリティが強化されます。
Lambdaのログを見てみよう＆検証リソースお片付け！
CloudWatchでログを見る
Lambda関数の画面にある「CloudWatchログを表示」ボタンを押すと、該当関数のロググループ（/aws/lambda/関数名）へ移動します。ログストリームを開くと、リアルタイムに出力された実行結果やエラーを確認できます。例：タイムアウトや例外スタックトレースの確認に便利です。
Logs Insightsでクエリを作る
CloudWatch Logs Insightsでは自由に検索や集計ができます。簡単な例：
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 50
このようにして直近のエラーや特定ワード（例：「Timeout」）を絞り込みます。時間範囲は画面上部で指定できます。
ログの期間・キーワード検索、CSVエクスポート
ログストリーム内で期間を指定して閲覧し、ブラウザ内検索でキーワードを探せます。Logs Insightsの結果は右上のメニューからCSVでエクスポート可能です。解析や報告書作成に便利です。
検証後のお片付け（必ず行う）
検証が終わったら不要なリソースを削除して費用と混乱を防ぎます。主な削除対象：
– Lambda関数本体
– 関連するCloudWatch Logs（/aws/lambda/関数名）
– 作成したCloudWatchアラームやEventBridgeルール
– テストで使ったS3バケットや一時ファイル
– 検証用のIAMロール（他で使っていないか必ず確認）
削除前に他サービスで共有していないか確認してください。特にIAMロールやS3は誤って削除すると影響が出ます。
CloudTrailでコンソールログイン履歴を確認してみた
概要
CloudTrailのイベント履歴で「SwitchRole」やイベントソース「signin.amazonaws.com」を検索すると、コンソールのログインやロール切替の記録を詳しく確認できます。ログイン履歴はセキュリティ監査や不正検知に役立ちます。
確認手順（コンソール）
- AWSマネジメントコンソールでCloudTrailに移動します。イベント履歴（Event history）を開きます。
- フィルタで「Event name」にSwitchRoleやConsoleLoginを指定、または「Event source」にsignin.amazonaws.comを入力します。
- 期間を絞って検索します。必要ならCSVでエクスポートします。
注目すべき項目
- eventTime：発生日時
- userIdentity：誰が実行したか（IAMユーザーやロール）
- sourceIPAddress：接続元IP
- awsRegion：アクセスされたリージョン
- responseElementsやerrorCode：成功／失敗の判定
利用シーンと注意点
- ロール切替（SwitchRole）を監視すると、別アカウントや権限昇格の痕跡を追えます。signin.amazonaws.comはサインイン全般を示します。
- 不審なIPや異常な時間帯のログインを優先的に調べます。ログは整合性保持のためS3に保存し、CloudWatchでアラート設定すると効率的です。
実例クエリ（Event historyのフィルタ）
- Event name = SwitchRole
- Event source = signin.amazonaws.com
これらでまず疑わしいログインを洗い出し、詳細なフィールドを基に調査を進めてください。
AWS操作ログとは？ログの種類やCloudTrailでの記録方法
はじめに
AWS操作ログは、誰がいつ何をしたかを記録する情報です。ログインや設定変更、API呼び出しなどが含まれます。問題発生時の原因追跡や監査に役立ちます。
ログの主な種類
- 管理イベント（Management Events）: コンソールログイン、IAMの変更、インスタンス作成など。運用や設定変更の記録です。
- データイベント（Data Events）: S3オブジェクトの取得やLambda関数の呼び出し。操作の粒度が細かい分、量が増えます。
- システムログ（例: OSやアプリのログ）: EC2内のログはCloudTrailではなく各サービス側で収集します。
CloudTrailでの記録方法（基本手順）
- トレイルを作成してS3バケットに保存します。
- 管理イベントは基本的に記録されます。データイベントは必要に応じて個別に有効化します。
- CloudWatch Logsに送ればリアルタイム監視やアラームが作れます。
具体的な注意点と例
- S3のオブジェクト操作を全部記録するとログ量が急増して費用が上がります。必要なバケットだけ有効化してください。
- マルチリージョンのトレイルを有効にすると見落としが減ります。
- ログ保管バケットは暗号化とアクセス制限を設定して保護してください。
運用のヒント
- 監査用には管理イベントと重要なデータイベントを組み合わせます。
- CloudWatchで特定のAPI呼び出しを検出し通知するルールを作ると迅速に対応できます。
CloudWatch Logs Insights 入門：基本的なクエリとコマンド
はじめに
CloudWatch Logs Insightsは、ログを素早く検索・集計できるサービスです。SQLに似た書き方で、短時間で傾向や異常を見つけられます。
基本の流れ
- ロググループを選ぶ
- 時間範囲を指定する
- クエリを実行する
よく使うコマンド例
- fields: 表示するフィールドを指定します。例:
fields @timestamp, @message - filter: 条件で絞り込みます。例:
filter status = 500 - stats: 集計を行います。例:
stats count() by status - sort / limit: 並び替えと件数制限をします。例:
sort @timestamp desc | limit 20 - parse: メッセージを分解してフィールドにします。例:
parse @message "user=* action=*" as user, action
実践例（エラー急増を調べる）
filter status >= 500でエラーだけ抽出stats count() by bin(5m)で5分ごとの件数を集計sort @timestamp desc | limit 20で最新を確認
注意点
- ログフォーマットが一定でないとparseが失敗します。実例を見ながら少しずつ調整してください。
- クエリは実行時間で課金されます。期間や集計粒度を適切に設定しましょう。
セッションマネージャーの操作ログを取得する方法
概要
AWS Systems ManagerのSession Managerは、EC2やオンプレ端末へのシェル接続をログとしてCloudWatch Logsへ送れます。リージョン、IAMユーザやロール、接続したOSユーザ名、セッションID、開始・終了時刻などが記録され、監査やトラブルシュートに役立ちます。
前提
- SSM Agentが対象インスタンスにインストールされていること
- IAMロールやポリシーでCloudWatch Logsへ書き込みできる権限があること
操作ログの有効化（コンソール手順）
- AWSコンソールで「Systems Manager」→「Session Manager」→「Preferences」を開きます。
- 「Session logging」を有効にし、CloudWatch Logs用のロググループを指定します。必要に応じてKMSキーも設定します。
- 設定を保存してからセッションを開始すると、ログが指定のロググループに出力されます。
※ CLIやCloudFormationでも設定できますが、まずはコンソールで確認すると分かりやすいです。
CloudWatch Logsでの確認方法
- CloudWatch Logsコンソールで対象のロググループを開き、ログストリームを選びます。
- 検索ボックスで「sessionId:」、「user:」などを絞り込むと該当セッションを素早く見つけられます。
ログに含まれる主な項目
- リージョン、アカウントID
- IAMユーザ名またはロール名
- OS上のユーザ名（例: ec2-user）
- sessionId、開始/終了時刻
- コマンド入力や出力（転送設定次第で記録されます）
監査や運用での活用ポイント
- CloudWatch Logs Insightsで時間帯やユーザごとのアクセス傾向を集計します。
- 異常なユーザや想定外の時間帯の接続でアラートを設定します。
- 長期保存が必要ならCloudWatchからS3にエクスポートしておきます。
注意点
- セッションはSSM経由のため接続元のIPがログに残らないことがあります。外部IP情報が必要な場合はCloudTrailの記録やネットワークログと併用してください。
AWS環境のリソース管理を効率化！AWS Resource Explorer
概要
AWS Resource Explorerは、アカウント内のリソースをキーワードで横断検索できるサービスです。インスタンスやS3バケット、RDSなどを一か所から探せるため、運用やトラブル対応で役立ちます。\n\n### できること（具体例）
– タグで検索：tag:Owner=Alice のように所有者タグで絞り込めます。\n- リソース種別で検索：type:AWS::EC2::Instance といった指定で絞れます。\n- 名前や部分一致検索：my-db のように一部の文字列でヒットします。\n- CLI/SDKから検索可能：自動化スクリプトでも使えます。\n\n### 使い方（手順）
1. コンソールでResource Explorerを開き、インデックスを作成します。インデックス作成後にリソース情報が集約されます。\n2. 検索スコープや対象リージョンを選択します。複数リージョンを横断する設定も可能です。\n3. キーワードやフィルター（タグ、タイプ、アカウント）を指定して検索します。\n\n### IAMと権限
検索には適切なIAM権限が必要です。最小権限の原則に従い、検索だけを許可するポリシーを作成してください。組織で横断検索する場合は、各アカウントでのアクセス許可を確認します。\n\n### ベストプラクティス
– タグ運用を統一しておくと検索が非常に楽になります。\n- よく使うクエリはスニペット化して共有しましょう。\n- インデックス作成後に反映されるまで時間がかかることがあるので、変更直後は待つ運用を組み込みます。\n\n### 注意点
– すべてのメタデータが即時に反映されるわけではありません。\n- インデックスや検索でわずかな費用が発生する場合がありますので、運用ポリシーに含めてください。\n\nResource Explorerは、環境把握と保守作業の負担を減らす便利なツールです。まずは小さな範囲で試し、タグと検索ルールを整えてから本格運用に移すことをおすすめします。
セキュリティと運用の要『AWS CloudTrail』
はじめに
CloudTrailはAWSアカウント内の操作履歴を自動で記録するサービスです。誰が何をしたかを追跡でき、障害対応や不正検知、監査に役立ちます。
CloudTrailとは
管理イベント（コンソール操作やAPI呼び出し）とデータイベント（S3オブジェクトやLambda関数の呼び出し）を記録します。例：誰かがIAMユーザーを作成した、S3にファイルがアップロードされた、などです。
基本的な設定手順
- マネジメントコンソールでTrailを作成する。
- ログ送信先にS3バケットを指定し、必要ならCloudWatch Logsへ配信する。
- マルチリージョンを有効にして全リージョンをカバーする。
- ログファイル検証をオンにして改ざん防止を有効にする。
ログの確認方法
CloudTrailコンソール、CloudWatch Logs、またはAthenaでS3のログを検索できます。簡単な例：Athenaで特定ユーザーのイベントを抽出して発生時間を確認します。
運用とモニタリング
- 重要イベント（権限変更やログイン失敗）をCloudWatchアラームやSNSで通知する。
- 不要なデータイベントは収集を絞ってコストを管理する。
セキュリティ強化のベストプラクティス
- 最小権限でTrailの設定・閲覧を制限する。
- S3バケットは暗号化とアクセス制御を設定する。
- ログの保管期間をポリシーで管理し、長期保存が必要な場合はライフサイクルを設定する。
補足
CloudTrailは運用とセキュリティの両面で基盤となるサービスです。まずは基本設定を確実に行い、必要に応じて監視や検出の仕組みを整えてください。
CloudTrailのログファイルを検証して不正検知を通知する
概要
CloudTrailは操作ログを記録します。ログファイルの整合性検査を有効にすると、ファイル改ざんの有無を検証できます。ここでは、整合性検査の有効化から検出ルール作成、アラート通知までの流れを分かりやすく説明します。
前提
- CloudTrailで証跡を作成済み
- 証跡がS3に配信される設定
手順（簡潔）
- 証跡でログファイル整合性検査を有効にする
- CloudTrailの設定画面で「ログファイルの整合性検査（Log file integrity）」をオンにします。これで配信されたログに対する検証情報がS3に保存されます。
- S3とオブジェクト保護
- 受け取り用バケットにバージョニングやオブジェクトロックを設定し、削除や上書きを防ぎます。
- 検出ルールを作る
- CloudWatch Logsでメトリクスフィルターを作成するか、LambdaでS3のPUTイベントをトリガーして検証処理を実行します。
- 例：CloudWatch Logsのフィルターパターンで異常なAPI呼び出し（例：ConsoleLoginの失敗増加）を検出します。
- アラームと通知
- メトリクスに対してCloudWatchアラームを作り、SNSでメールやWebhookに通知します。Slack通知はSNS→LambdaでWebhook送信が簡単です。
検出時の対応フロー（例）
- 通知受信→影響範囲確認（IAMユーザー、ソースIP）→当該キーの無効化・一時的なアクセス制限→詳細調査とログ保存
注意点
- 整合性検査は改ざん検出に有効ですが、誤検知を避けるためしきい値やフィルターは段階的に調整してください。
- 通知先を複数用意すると対応が早くなります。
