EC2インシデント対応の隔離と調査ツールの使い分け

概要

EC2インスタンスで不審な動作が検出された場合、セキュリティエンジニアはインスタンスの隔離と原因の調査を迅速に実施する必要があります。この記事では、隔離と調査に使用するAWSの主要ツールであるSecurity Groups、AWS CloudTrail、VPC Flow Logsの3つに焦点を当てて解説します。

インシデントレスポンスの全体フローではNISTフレームワークに基づく5フェーズを、隔離専用セキュリティグループの設計と実装ではネットワーク隔離の具体的な手順を解説しています。この記事では、隔離に加えて調査フェーズで使用するツールの選定と活用方法にフォーカスします。AWSには多くのセキュリティ関連サービスがありますが、インシデントの「隔離と調査」という目的に対して適切なツールを選択できることが重要です。

クラウド資格 実践ラボ

侵害されたEC2インスタンスの対応　〜隔離専用セキュリティグループの設計と実装〜 | クラウド資格 実践ラ… 概要 インシデントレスポンスの全体フローで解説した5フェーズのうち、この記事では封じ込め（Containment）フェーズで実施するネットワーク隔離について詳しく解説します…

クラウド資格 実践ラボ

侵害されたEC2インスタンスへの対応　インシデントレスポンスの全体像 | クラウド資格 実践ラボ  概要 EC2インスタンスが侵害された場合、「まず何をするか」が調査の成否を左右します。 AWSはセキュリティインシデントへの対応として、NISTのフレームワークに基づく検…

 この記事のメリット

• EC2インシデント対応における隔離と調査の各フェーズで使うべきツールを理解できる
• Security Groups・CloudTrail・VPC Flow Logsそれぞれの役割と用途の違いを把握できる
• GuardDutyやNetwork Access Analyzerなど類似サービスとの使い分けを理解できる
• VPC Flow LogsとCloudTrailを使った実際の調査手順を習得できる
• SCS試験で「インシデント調査に使用するツール」を問われた際に正確に判断できるようになる

 技術解説

 インシデント対応における3つの主要ツール

EC2インスタンスで不審な動作が検出された場合、隔離と調査に使用する主要ツールは以下の3つです。

Security Groups（隔離）

Security Groupsは、EC2インスタンスのネットワークアクセスを制御するファイアウォールです。インシデント対応では、隔離専用のセキュリティグループに付け替えることで、侵害されたインスタンスの外部通信を遮断し、被害の拡大を防ぎます。隔離の具体的な手順については隔離専用セキュリティグループの設計と実装で詳しく解説しています。

AWS CloudTrail（API活動の追跡）

CloudTrailは、AWSアカウント内で実行されたAPI呼び出しを記録するサービスです。デフォルトでは管理イベント（リソースの作成・変更・削除などのコントロールプレーン操作）が記録されます。S3オブジェクトの操作やLambda関数の呼び出しなどのデータイベントは、明示的に有効化する必要があります。

インシデント調査では、侵害されたインスタンスに関連するAPI操作（誰が・いつ・どのような操作を行ったか）を追跡することで、攻撃者の行動を時系列で把握できます。なお、CloudTrailコンソールの「イベント履歴」で検索できるのは過去90日間の管理イベントに限られます。90日を超えるログの調査が必要な場合は、S3バケットに配信された証跡ログをAmazon Athenaなどで分析します。

CloudTrailで確認できる情報の例:

• インスタンスの起動・停止・設定変更の履歴
• セキュリティグループやIAMロールの変更
• 不正なAPI呼び出し（他リソースへのアクセスや新規リソースの作成）
• 操作を実行したIAMユーザーやロール、送信元IPアドレス

VPC Flow Logs（ネットワークトラフィックの記録）

VPC Flow Logsは、VPC内のネットワークインターフェイスを通過するIPトラフィックのメタデータを記録するサービスです。フローログのデータはネットワークトラフィックのパス外で収集されるため、ネットワークスループットやレイテンシには影響しません。送信先としてCloudWatch Logs、Amazon S3、Amazon Data Firehoseの3つを選択できます。集約間隔はデフォルトで10分ですが、1分に変更することも可能です。なお、Nitroベースのインスタンスでは、集約間隔の設定にかかわらず常に1分以下で集約されます。

インシデント調査では、侵害されたインスタンスがどの外部IPアドレスと通信していたか、どのポートが使用されていたかを特定できます。

VPC Flow Logsのデフォルトフォーマット（バージョン2）で記録されるフィールド:

 類似サービスとの比較

AWSにはセキュリティ関連のサービスが多く存在しますが、インシデントの「隔離と調査」という目的には以下のように役割が異なります。

 なぜGuardDutyは調査に不向きなのか

Amazon GuardDutyは脅威インテリジェンスフィードと機械学習モデルを使用して、不審な挙動を自動検知する脅威検出サービスです。基盤となるデータソースとして、CloudTrail管理イベント、VPC Flow Logs、DNSログをデフォルトで分析します。さらにオプションの保護プランとして、S3データイベントの監視、EKS監査ログの分析、RDSログインアクティビティの監視、EC2・ECS・EKSのランタイムモニタリング、マルウェア検出なども利用可能です。

インシデントの「検出」フェーズでは重要な役割を果たしますが、すでに検出された問題の「調査」には直接的な機能を持ちません。GuardDutyの検知結果（Finding）は侵害された可能性のあるリソースの概要を示しますが、詳細な調査にはCloudTrailやVPC Flow Logsのログを直接確認する必要があります。

 なぜNetwork Access Analyzerは調査に不向きなのか

AWS Network Access Analyzerは、VPCのネットワーク構成を静的に分析し、意図しないアクセスパスが存在しないかを確認するためのツールです。セキュリティ体制の評価やコンプライアンスチェックには有効ですが、「いつ・どのIPアドレスから・どのような通信が行われたか」というインシデント調査に必要なリアルタイムのトラフィック情報は提供しません。

 なぜAthenaは直接的な調査ツールではないのか

Amazon AthenaはS3に保存されたデータをSQLでクエリできるサービスです。CloudTrailログやVPC Flow LogsをS3に保存している場合、Athenaで大量のログデータを効率的に検索・分析できます。AWS公式ドキュメントでもVPC Flow LogsのクエリにAthenaを使用する方法が紹介されています。この点ではログ分析の補助ツールとして有用ですが、Athena自体はインスタンスの隔離や直接的なイベント調査の機能を持ちません。あくまでCloudTrailやVPC Flow Logsが記録したデータを分析するための手段です。

 実践

ここでは、不審な動作が検出されたEC2インスタンスに対して、VPC Flow LogsとCloudTrailを使った調査の手順をコンソールで実践します。リソースを新規作成するハンズオンではなく、既存のログをコンソール上で閲覧・検索し、不審な通信やAPI操作の痕跡を読み取る操作を体験します。Security Groupsを使った隔離手順は隔離専用セキュリティグループの設計と実装を参照してください。

 前提条件

• リージョン: ap-northeast-1（東京）
• VPC・サブネット・EC2インスタンスが1台起動済みの状態
• VPC Flow Logsが有効化されており、CloudWatch Logsグループに配信されている状態
• CloudTrailが有効化されている状態（デフォルトで証跡が記録されている）
• 調査対象のインスタンスIDが特定されている状態

 手順1: VPC Flow Logsで不審なネットワーク通信を確認する

VPC Flow Logsを使って、侵害されたインスタンスのネットワーク通信パターンを確認します。

• AWSマネジメントコンソールにログインし、右上のリージョンが「アジアパシフィック（東京） ap-northeast-1」であることを確認します。
• 上部の検索バーに VPC と入力し、表示された「VPC」を選択します。
• 左側ナビゲーションの「仮想プライベートクラウド」→「お使いのVPC」を選択します。
• 対象のVPCを選択し、画面下部の「フローログ」タブを開きます。
• フローログの送信先（CloudWatch Logsグループ名）を確認します。例: /aws/vpc/flowlogs

screenshot: VPC詳細画面の「フローログ」タブ（フローログの送信先CloudWatch Logsグループ名が表示されている状態）

次に、CloudWatch Logsで実際のフローログを検索します。

• 「フローログ」タブのCloudWatch Logsのリンクをクリック選択します。
• 「ログストリーム」タブに、ENI（Elastic Network Interface）ごとのログストリームが表示されます。対象インスタンスのENI ID（例: eni-xxxxxxxxxxxxxxxxx）を含むストリームを選択します。

screenshot: CloudWatch Logsのログストリーム画面（対象ENIのフローログレコードが一覧表示されている状態）

対象インスタンスのENI IDは、EC2コンソールでインスタンスを選択し「ネットワーキング」タブの「ネットワークインターフェイス」セクションで確認できます。

• ログストリーム内にフローログのレコードが表示されます。デフォルトフォーマットでは、各フィールドがスペース区切りで記録されています。フィールドの順序は技術解説セクションの表を参照してください。

例:

2 123456789012 eni-abc12345 203.0.113.50 10.0.1.100 44321 22 6 10 840 1609459200 1609459260 ACCEPT OK

この例では、外部IPアドレス 203.0.113.50 からインスタンスのプライベートIP 10.0.1.100 のポート22（SSH）に対して、プロトコル番号6（TCP）の通信が許可（ACCEPT）されたことを示しています。

• 不審な通信パターンを確認するために、「ログストリームの検索」機能を使います。ログストリーム一覧画面に戻り、画面上部の「すべてのログストリームを検索」をクリックします。

• フィルタパターンに対象インスタンスのプライベートIPアドレスを入力して検索します。時間範囲を指定して絞り込みます。

確認すべきポイント:

• 見覚えのない外部IPアドレスからの通信（特にSSHやRDPのポート）
• 通常使用しないポートへの通信（C&Cサーバーとの通信に使われることがある）
• 大量のアウトバウンド通信（データの持ち出しの兆候）
• 深夜や業務時間外の通信

 手順2: CloudTrailでAPI活動を調査する

CloudTrailを使って、侵害されたインスタンスに関連するAPI呼び出しを確認します。

• 上部の検索バーに CloudTrail と入力し、表示された「CloudTrail」を選択します。
• 左側ナビゲーションの「イベント履歴」を選択します。イベント履歴では過去90日間の管理イベントを検索できます。
• 検索フィルタのドロップダウンで「リソース名」を選択します。
• 検索ボックスに対象のインスタンスID（例: i-xxxxxxxxxxxxxxxxx）を入力してEnterキーを押します。
• 時間範囲を「カスタム」に設定し、不審な動作が検出された前後の期間を指定します。
• 該当するイベントの一覧が表示されます。各イベントをクリックすると、詳細情報を確認できます。

screenshot: CloudTrailのイベント履歴画面（リソース名でインスタンスIDを検索し、関連イベント一覧が表示されている状態）

確認すべきイベントの例:

• 特定のイベントを選択し、「イベントレコード」を展開してJSON形式の詳細を確認します。

screenshot: CloudTrailイベント詳細画面（イベントレコードのJSON表示が展開され、userIdentity・sourceIPAddress・requestParametersが確認できる状態）

イベントレコードで注目すべきフィールド:

{
    "eventTime": "2025-01-15T03:24:00Z",
    "eventName": "AuthorizeSecurityGroupIngress",
    "userIdentity": {
        "type": "AssumedRole",
        "arn": "arn:aws:sts::123456789012:assumed-role/EC2Role/i-xxxxxxxxxxxxxxxxx"
    },
    "sourceIPAddress": "203.0.113.50",
    "requestParameters": {
        "groupId": "sg-xxxxxxxxxxxxxxxxx",
        "ipPermissions": {
            "items": [{
                "ipProtocol": "tcp",
                "fromPort": 0,
                "toPort": 65535,
                "ipRanges": {
                    "items": [{"cidrIp": "0.0.0.0/0"}]
                }
            }]
        }
    }
}

{
    "eventTime": "2025-01-15T03:24:00Z",
    "eventName": "AuthorizeSecurityGroupIngress",
    "userIdentity": {
        "type": "AssumedRole",
        "arn": "arn:aws:sts::123456789012:assumed-role/EC2Role/i-xxxxxxxxxxxxxxxxx"
    },
    "sourceIPAddress": "203.0.113.50",
    "requestParameters": {
        "groupId": "sg-xxxxxxxxxxxxxxxxx",
        "ipPermissions": {
            "items": [{
                "ipProtocol": "tcp",
                "fromPort": 0,
                "toPort": 65535,
                "ipRanges": {
                    "items": [{"cidrIp": "0.0.0.0/0"}]
                }
            }]
        }
    }
}

この例では、EC2インスタンスのIAMロールを使って、すべてのTCPポートを全世界に開放するセキュリティグループの変更が行われたことがわかります。sourceIPAddress と userIdentity から、操作の実行者と実行元を特定できます。

 手順3: 調査結果の整理

VPC Flow LogsとCloudTrailの調査結果を突き合わせることで、インシデントの全体像を把握します。

VPC Flow Logsで特定した不審な外部IPアドレスと、CloudTrailで確認した不正なAPI操作のタイムスタンプを照合することで、攻撃の開始時期・経路・影響範囲をより正確に特定できます。

 まとめ

EC2インスタンスで不審な動作が検出された場合の隔離と調査には、以下の3つのツールが主要な役割を果たします。

GuardDutyは脅威の「検出」に特化したサービスであり、すでに検出されたインシデントの詳細な「調査」には向きません。Network Access Analyzerはネットワーク構成の静的分析ツールであり、リアルタイムのトラフィック調査には使えません。Athenaはログ分析の補助ツールとして有用ですが、それ自体が隔離や調査の機能を持つわけではありません。

SCS試験では「不審な動作が検出されたEC2インスタンスの隔離と調査に使用するツール」を問われた際、隔離にはSecurity Groups、API活動の追跡にはCloudTrail、ネットワーク通信の調査にはVPC Flow Logsという組み合わせを選択することが重要です。各ツールが「何の情報を提供するか」を理解しておくことで、選択肢の絞り込みが容易になります。

参照先

• VPC フローログ – Amazon VPC
• フローログレコード – Amazon VPC
• AWS CloudTrail の概念
• Amazon GuardDuty とは
• Network Access Analyzer とは – Amazon VPC
• AWS セキュリティインシデント対応ガイド