クラウドセキュリティインシデント対応設計入門｜AWS/Azureの初動・証拠保全・封じ込めを実務フローで整理する実践ガイド

クラウドでセキュリティインシデントが起きたとき、「何からどの順番で動けばいいのか」がわからず焦った経験はないだろうか。オンプレではネットワークを切断してメモリダンプを取るのが定番だったが、クラウドではその手順がそのまま使えないどころか、逆に証拠を消してしまうリスクすらある。

この記事では、AWSとAzureのクラウド環境でセキュリティインシデントが発生した場合の対応設計を、検知から復旧まで5フェーズに分けて整理する。どのサービスを使い、どの順番で何をすべきかを、オンプレ経験者の視点で具体的に解説する。

オンプレとクラウドのインシデント対応、何が変わるのか

オンプレのインシデント対応では、「物理的にサーバーに触れる」という選択肢が常にあった。ネットワークケーブルを抜いてネットワーク隔離し、電源をそのまま維持したままメモリダンプを取り、ディスクイメージをコピーする——そうした手順が教科書的な正解だった。

クラウドでは、この前提が根本的に変わる。押さえておくべき違いは3点ある。

1. リソースの揮発性
EC2インスタンスやAzure VMは、終了（terminate/deallocate）と同時にメモリが消える。またスポットインスタンスは突然中断される。「停止してから調査する」という順番では、メモリ上の証拠が失われる可能性がある。

2. API操作がすべての痕跡を残す
クラウドの管理操作はすべてAPIコール経由で行われる。誰が何時何をしたかはCloudTrail（AWS）やAzure Activity Logに残るが、これらのログを攻撃者が削除しようとした場合の備えが必要だ。

3. IAM侵害が最も深刻なシナリオ
オンプレでは「ファイルサーバーに不正ログイン」のような限定的な侵害が多かったが、クラウドではIAMクレデンシャルの漏洩一件で全リソースへのアクセスが可能になる。IAMロールやアクセスキーの不正利用が最初の疑いポイントになる。

なお、クラウドセキュリティの「どこまでが自分の責任か」という基本については、クラウドセキュリティの責任共有モデルの解説記事もあわせて確認しておくといいだろう。

クラウドIRの5フェーズ全体像

クラウドのインシデント対応（IR: Incident Response）は以下の5フェーズで設計する。

オンプレのIRフレームワーク（NIST SP 800-61等）との大きな違いは、「フェーズ3（証拠保全）をフェーズ4（封じ込め）より前に配置する」点だ。クラウドでは封じ込めのためにインスタンスを停止・削除すると、その後にメモリ情報を取得できなくなる。証拠保全と封じ込めを並行して進めるか、最低限EBSスナップショットを取ってから封じ込めに移る設計が必要だ。

フェーズ1：検知と自動通知の設計

クラウドのインシデント検知は、原則として自動化が前提だ。人間が手でCloudTrailを掘り起こして異常を発見するのでは、タイムラグが大きすぎる。

1. AWS GuardDutyの活用

Amazon GuardDutyは、CloudTrail・VPC Flow Logs・DNSログを機械学習で分析し、脅威を自動検出するサービスだ。オンプレのIDS（侵入検知システム）に相当するが、センサーのデプロイは不要で、有効化するだけで動き始める。

検出できる脅威の例（検出タイプ名は執筆時点のもの）：
・UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B: 通常と異なる地域からのAWSコンソールログイン
・Recon:EC2/PortScan: インスタンスからのポートスキャン（C2サーバーに感染した可能性）
・CryptoCurrency:EC2/BitcoinTool.B: EC2インスタンスからの暗号資産マイニング通信
・UnauthorizedAccess:IAMUser/MaliciousIPCaller: 既知の悪意あるIPからのAPI呼び出し

GuardDutyの検出結果（Finding）は、AWS Security HubやEventBridgeと連携して、Slack・メール・PagerDutyへ自動通知する仕組みを構築しておく。GuardDutyの基本的な設定については、CloudTrail・GuardDuty入門の記事に整理している。

2. Microsoft Defender for Cloud（Azure）

Azure環境では、Microsoft Defender for Cloudが対応する役割を担う。VM・SQL・Key Vault・DNSなどのサービスごとにDefenderプランを有効化することで、脅威インテリジェンスと機械学習による自動アラートが得られる。アラートはMicrosoft Sentinelに集約するか、Action Groupを通じてメール・Webhook・Logic Apps経由で通知設定する。

フェーズ2：初動トリアージ

GuardDutyやDefender for Cloudのアラートがすべて本物の攻撃とは限らない。トリアージ（優先度判定）をいかに速く正確に行うかが対応の質を左右する。

1. AWS Security HubでFindingを一元管理する

AWS Security Hubは、GuardDuty・Amazon Inspector・AWS Config・AWS Macieなど複数のセキュリティサービスの検出結果を一か所に集約し、重要度（CRITICAL/HIGH/MEDIUM/LOW）でフィルタリングできる。マルチアカウント環境では、Organizations経由でSecurity HubをDelegated Administrator（委任管理者アカウント）に集約することで、全アカウントの検出結果を一画面で確認できる。詳細はAWS Security Hub入門の記事を参照してほしい。

2. AWS Detectiveで攻撃経路を深掘りする

「GuardDutyのアラートは出た。でも、具体的にどのリソースが、どのIAMユーザーから、どのような経路で操作されたのか」を調べるのがAWS Detectiveの役割だ。GuardDutyのFindingから直接Detectiveに遷移して、関係するエンティティ（IAMユーザー・EC2インスタンス・IPアドレス）の時系列グラフを確認できる。詳しくはAWS Detective入門の記事を参照してほしい。

フェーズ3：証拠保全の手順

封じ込めの前に、必ず証拠を保全する。クラウドで確保すべき証拠は大きく3種類だ。

1. CloudTrailログの保全

CloudTrailはAWS上のすべてのAPI呼び出しを記録する。インシデント発生時は、まず関係する時間帯のログが改ざん・削除されていないか確認し、安全な場所にコピーしておく。

事前対策として有効なのは、CloudTrailのS3バケットに対してObject Lockを設定しておくことだ。WORM（Write Once, Read Many）ポリシーにより、ログの上書き・削除を物理的に防げる。

# CloudTrailのS3バケットObject Lock設定確認（AWS CLI）
aws s3api get-object-lock-configuration   --bucket your-cloudtrail-bucket

# 特定時間帯のCloudTrailイベントを取得・エクスポート
aws cloudtrail lookup-events   --start-time "2026-09-15T00:00:00Z"   --end-time "2026-09-15T23:59:59Z"   --lookup-attributes AttributeKey=EventName,AttributeValue=ConsoleLogin   --output json > incident_events.json

2. VPC Flow Logsの取得

VPC Flow LogsはEC2インスタンスのネットワークトラフィックを記録する。「侵害されたインスタンスがどこと通信していたか」を追跡するために不可欠な証拠だ。Flow Logsの設計と読み方については、VPC Flow Logs入門の記事に詳しい。インシデント対応用途では、S3またはCloudWatch Logsに送信されているFlow Logsデータを、調査対象の時間帯で絞り込んでエクスポートしておく。

3. EC2インスタンスのEBSスナップショット取得

侵害されたEC2インスタンスは、終了する前に必ずEBSスナップショットを取得する。これがオンプレで言うディスクイメージに相当する。

# 対象インスタンスのEBSボリュームIDを取得（AWS CLI）
aws ec2 describe-instances   --instance-ids i-xxxxxxxxxxxxxxxxx   --query 'Reservations[].Instances[].BlockDeviceMappings[].Ebs.VolumeId'   --output text

# 証拠スナップショットを作成（タグで証拠であることを明示）
aws ec2 create-snapshot   --volume-id vol-xxxxxxxxxxxxxxxxx   --description "Incident Evidence - $(date +%Y%m%d-%H%M%S)"   --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Purpose,Value=IncidentEvidence},{Key=IncidentDate,Value=2026-09-15}]'

フェーズ4：封じ込めの実施

証拠保全が完了したら、被害拡大を防ぐ封じ込めに移る。クラウドでの封じ込めは、ネットワーク遮断だけでなくIAMレベルの制御が中心になる。

1. IAM権限の即時無効化

侵害されたIAMユーザーのアクセスキーが漏洩している場合、最初にすべきはそのアクセスキーの無効化だ。IAMコンソールまたはCLIで「キーの無効化」を実行する（削除ではなく無効化を推奨するのは、削除すると依存リソースへの影響を後から追いにくくなるためだ）。

# アクセスキーの無効化（AWS CLI）
aws iam update-access-key   --user-name compromised-user   --access-key-id AKIAXXXXXXXXXXXXXXXX   --status Inactive

# 無効化後にキーの状態を確認
aws iam list-access-keys   --user-name compromised-user

IAMロールが侵害された場合は、そのロールにインラインDenyポリシーを追加して権限を即時停止する方法が有効だ。AWS IAM Access Analyzerの記事では、外部に公開されているリソースの検出方法を解説しているので、侵害後のアクセス範囲確認にも活用できる。

2. ネットワーク隔離（セキュリティグループ差し替え）

侵害されたEC2インスタンスのセキュリティグループを、すべての通信を拒否するルールに差し替えることでネットワーク隔離を実現する。オンプレで言う「LANケーブルを抜く」に相当する操作だが、インスタンス自体はRunning状態を維持できるため、メモリ情報の取得が可能な点がオンプレより優れている。

# 「全拒否」セキュリティグループの作成（インバウンド/アウトバウンドルールを追加しない）
aws ec2 create-security-group   --group-name "forensics-isolation-sg"   --description "Isolation SG for incident response - all traffic denied"   --vpc-id vpc-xxxxxxxxxxxxxxxxx

# 対象インスタンスのセキュリティグループを隔離用SGに差し替え
aws ec2 modify-instance-attribute   --instance-id i-xxxxxxxxxxxxxxxxx   --groups sg-xxxxxxxxxxxxxxxxx

3. AzureでのVM隔離

Azure環境では、NSG（Network Security Group）に全トラフィックDenyルールを追加するか、Microsoft Defender for Cloudの「Isolate」機能を使えば、ポータルのワンクリックで対象VMのネットワーク隔離が実行できる（内部的にはNSGへのルール追加が行われる）。

フェーズ5：復旧と再発防止策

封じ込めが完了し、証拠保全・調査が終わったら、クリーンな環境で再構築する。

クラウドでの再構築のポイントは「IaCで全リソースを再デプロイする」ことだ。侵害されたインスタンスやリソースを修正・再利用するのではなく、TerraformやCloudFormationのコードから新規でデプロイし直す。これによりバックドアや設定残留のリスクを排除できる。

再発防止のために確認すべき項目：
・アクセスキーの棚卸し: IAM Identity Centerへの移行、または使われていないキーの即削除
・MFAの強制: すべてのIAMユーザー（特にルートアカウント）にMFAを必須化
・GuardDutyの有効化確認: 全リージョン・全アカウントで有効になっているか
・CloudTrailのマルチリージョン設定: 管理イベントの証跡が全リージョンで記録されているか
・S3バケットの公開設定確認: Block Public Access の設定が組織全体に適用されているか

コスト面から見る備えの設計

インシデント対応基盤を常時稼働させる場合の主なコスト目安（2026年9月時点・東京リージョン、規模によって大きく変動する）：

GuardDutyは30日間の無料トライアルがある。まず有効化してどの程度のイベント数が発生するかを確認してから、本番コストを見積もるのが現実的な進め方だ。

よくある失敗と対処法

失敗1: 封じ込めを急いでインスタンスをterminateしてしまう
インシデント対応で焦ってEC2インスタンスを終了（terminate）してしまうと、メモリ情報・ランニングプロセス・一時ファイルが完全に消える。まず「停止（stop）」かスナップショット取得後に終了する手順を踏む。

失敗2: ルートアカウントのアクセスキーが存在していた
AWSのルートアカウントにアクセスキーが存在するだけでリスクだ。「実はルートキーが漏洩していた」と判明するケースは珍しくない。通常業務ではIAMユーザーまたはIAMロールを使い、ルートアカウントのアクセスキーは作成しない・発見したら即削除する方針を組織ルールとして明文化しておく。

失敗3: CloudTrailが一部リージョンでしか有効になっていなかった
攻撃者がCloudTrail無効のリージョンで操作を行うケースがある。マルチリージョン証跡（Multi-region Trail）を有効化し、全リージョンの管理イベントを記録するようにする。

失敗4: GuardDutyの検出結果を通知設定せず放置していた
GuardDutyを有効化していたが通知設定がなく、Findingが画面の中に溜まり続けていた——という事例は多い。Security HubとEventBridgeを組み合わせ、CRITICAL/HIGHのFindingは即座にSlack等に通知する仕組みを最初に構築しておく。

まとめ

クラウドのインシデント対応をオンプレの延長線で考えると、証拠を失ったり対応が遅れたりする。以下のポイントを押さえておこう。

インシデント対応の手順は、実際に発生してから初めて考えるのでは遅い。検知→保全→封じ込めの手順書をあらかじめ作成し、定期的にシミュレーションしておくことがクラウドセキュリティ運用の基本だ。