侵害されたEC2インスタンスの対応　〜隔離専用セキュリティグループの設計と実装〜

概要

インシデントレスポンスの全体フローで解説した5フェーズのうち、この記事では封じ込め（Containment）フェーズで実施するネットワーク隔離について詳しく解説します。

AWS公式ドキュメントでは、ネットワーク隔離はEBSスナップショットやメモリなどの証拠データを取得した後に実施するステップとして定義されています。特にメモリのキャプチャはシステムの分離やシャットダウンの前に行うことが重要とされており、隔離を先に行うと揮発性データの取得機会を損なう可能性があります。証拠保全の手順については全体フロー記事のStep2（分析）を参照してください。

この記事では、証拠保全が完了した前提で、ネットワーク隔離をどのように実施するかに焦点を当てます。「セキュリティグループのルールをすべて削除すれば隔離できるのでは？」と思われるかもしれませんが、この方法には注意点があります。なぜルール全削除よりも隔離専用セキュリティグループへの付け替えが望ましいのかを整理し、具体的な隔離手順についてまとめます。

この記事のメリット

セキュリティグループのルール全削除の注意点を理解できる
隔離専用セキュリティグループの設計方針（インバウンド・アウトバウンド）がわかる
コンソールを使った隔離手順を習得できる
SCS試験で「封じ込め手順」の選択肢を正確に判断できるようになる

技術解説

「ルール全削除」と「隔離専用SGへの付け替え」の比較

セキュリティグループのルールをすべて削除すると、新規の外部通信は遮断されます。なお、セキュリティグループはデフォルトでインバウンドルールなし（すべて拒否）、アウトバウンドルールはすべて許可の状態で作成されます。ルールの変更はセキュリティグループに関連付けられたすべてのリソースに即座に適用されます。

AWS公式ドキュメントでも「既存のセキュリティグループからルールを削除する」手法は「隔離専用SGの作成・適用」と並んで封じ込め手段の一つとしてフラットに紹介されています。ただし、ルール全削除には以下の注意点があるため、ベストプラクティスとしては隔離専用SGへの付け替えがより望ましいアプローチです。

調査アクセスが失われる

ルールを全削除すると、調査担当者がインスタンスにアクセスする手段も失われます。AWS公式ドキュメントでは、稼働中のインスタンスに直接アクセスして調査を行う「ライブレスポンス」は、ディスクやメモリを別途取得できない場合などに限定されるオプションの手段とされています。これはシステムにログインして操作を行うとシステムデータやアーティファクトが変更されるためです。ただし、そのような状況に備えてアクセス手段自体は確保しておくことが望ましいと言えます。

元のルール構成が不明になる

削除前のルール構成は、攻撃者がどこから侵入したかを示す手がかりになる場合があります。削除してしまうと、この情報が失われます。

SGの変更と既存接続への影響

セキュリティグループはステートフルなファイアウォールであり、ルールの変更・削除が既存の接続に与える影響は、その接続が追跡対象か非追跡かによって異なります。

追跡対象の接続の場合

送信元IPやポートが限定されたルールで許可された接続は、接続情報（IP、プロトコル、ポート）が追跡されます。この場合、ルールを削除しても既存の接続はタイムアウトするまで維持されます。新規の接続のみが新しいルールに従います。

非追跡の接続の場合

インバウンドとアウトバウンドの両方で0.0.0.0/0（すべてのトラフィック）を許可するルールのみで構成されている場合、接続は追跡されません。この場合、ルールを削除すると既存の接続も即座に切断されます。

インシデント対応の文脈では、侵害されたインスタンスのSGは通常、送信元が限定されたルールで構成されているため、攻撃者がすでにバックドア接続を確立していた場合は追跡対象の接続に該当する可能性が高くなります。つまり、SGを付け替えるだけではその接続を即時に遮断できない場合があります。

この点を踏まえた完全な封じ込めには、以下のような追加対応が必要になる場合があります。

ネットワークACLの使用: ネットワークACLはサブネットレベルで動作するステートレスなファイアウォールです。接続の状態を追跡しないため、ルールを設定すれば確立済みの接続も含めて即座にトラフィックを遮断できます
OS上のファイアウォール設定（iptablesなど）でインスタンスレベルで通信を遮断する
接続がタイムアウトするまで待機する（TCP確立接続のデフォルトタイムアウトは最大432,000秒＝約5日間）

SCS試験においても、SGのステートフルな仕様とネットワークACLのステートレスな仕様の違いは重要な知識です。

項目	セキュリティグループ	ネットワークACL
動作レベル	インスタンス（ENI）単位	サブネット単位
ステート	ステートフル（接続を追跡）	ステートレス（接続を追跡しない）
ルール変更時の既存接続	追跡対象の接続は維持される	即座に新しいルールが適用される
ルールタイプ	許可ルールのみ	許可ルールと拒否ルールの両方
ルール評価	すべてのルールを評価	番号順に評価し、最初に一致したルールを適用

隔離専用セキュリティグループの設計

隔離専用SG（Quarantine SG）の設計は「新規の接続を調査担当者のIPアドレスのみに制限し、攻撃者の外部通信を遮断する」ことが基本です。AWS公式ドキュメントでも「新しい接続を特定のIPアドレスのみに制限する」アプローチが紹介されています。

項目	通常時のSG	隔離専用SG
インバウンド（外部→EC2）	用途に応じたルール（HTTP・SSHなど）	調査端末のIPアドレスからのみ許可（それ以外は拒否）
アウトバウンド（EC2→外部）	すべて許可（デフォルト）	すべて拒否（ルールなし）
SSMアクセス	VPCエンドポイントまたはインターネット経由	VPCエンドポイント経由のみ許可

SSMアクセスを維持するには、VPCにSSM用のVPCエンドポイント（com.amazonaws.<region>.ssm など）が設定されている必要があります。エンドポイントが未設定の場合、SSMはアウトバウンドのインターネット通信を使うため、アウトバウンドを全拒否するとSSMも切断されます。

VPCエンドポイントがない環境での注意点

VPCエンドポイントが設定されていない環境では、SSMアクセスを維持しながら完全に隔離することができません。この場合は、調査チームのIPアドレスからのSSHのみ許可するインバウンドルールを追加する方法が現実的です。

SGの付け替え vs 既存SGへのルール追加

インスタンスに複数のSGがアタッチされている場合、複数のSGのルールは集約（統合）されて評価されます。つまり、いずれかのSGで許可されていれば通信が可能です。そのため、既存SGのルールをすべて削除するよりも、隔離専用SGへ付け替えるほうが管理しやすい理由があります。

元のSGは変更せず保持できるため、侵害前のルール構成を記録として残せる
隔離解除時は元のSGに戻すだけで復旧できる
隔離専用SGを使い回せるため、複数インスタンスで一貫した隔離手順を適用できる

前提条件

リージョン: ap-northeast-1（東京）
VPC・サブネット・EC2インスタンスが1台起動済みの状態
EC2インスタンスには通常運用時のセキュリティグループがアタッチされている状態

手順1: 隔離専用SGの作成

インスタンスが侵害された時のためのセキュリティグループをあらかじめ作成しておきます。

セキュリティグループのコンソールから新規作成を選択し以下の内容で作成します。

セキュリティグループ名: quarantine-sg
説明: Quarantine SG for incident response
VPC: 対象インスタンスと同じVPCを選択します

「インバウンドルール」セクションで「ルールを追加」をクリックし、以下を入力します。

タイプ: SSH
プロトコル: TCP
ポート範囲: 22
ソース: マイIP を選択します

「アウトバウンドルール」セクションで、デフォルトの「すべてのトラフィック – 0.0.0.0/0」ルールの右側にある「削除」をクリックして削除します。

侵害されたインスタンスから新たに攻撃者のサーバへ接続する経路を遮断するためにアウトバウンドは遮断します。

インバウンドはSSHのみ許可、アウトバウンドはルールなし（すべて拒否）の状態になります。Windowsインスタンスの場合はSSHの代わりにRDP（タイプ: RDP、ポート: 3389）を設定してください。

手順2: 対象インスタンスの現在のSGを記録する

復旧時に必要になるためSGを付け替える前に、元のSG構成を確認しておきます。

手順3: SGを隔離専用SGに付け替える

対象インスタンスが選択された状態で、画面上部の「アクション」をクリックします。

ドロップダウンメニューから「セキュリティ」→「セキュリティグループを変更」を選択します。

「関連付けられたセキュリティグループ」セクションに、現在アタッチされているSGが表示されています。各SGの右側にある「削除」をクリックして、すべてのSGを外します。

「セキュリティグループを追加」のドロップダウンで quarantine-sg を検索・選択し、「セキュリティグループを追加」をクリックします。

quarantine-sg のみが表示されていることを確認します。

右下の「保存」をクリックします。

手順4: 隔離の確認

SGの付け替えが正しく反映されたことを確認します。

対象インスタンスの「セキュリティ」タブから「セキュリティグループ」に quarantine-sg のみが表示されていることを確認します。

セキュリティグループはステートフルなフィルタリングをします。

反映は即時に行われますが、隔離用のセキュリティグループに切り替える前から確立していた通信は引き続き許可されます。

左：セキュリティグループ切り替え前から実行しているping（疎通可能）
右：セキュリティグループ切り替え後に実行したping（疎通不可能）

まとめ

侵害されたEC2インスタンスの隔離には「ルール全削除」と「隔離専用SGへの付け替え」の2つの手法があり、AWS公式ドキュメントではいずれも封じ込め手段として紹介されています。ただし、元のSG構成の保全や調査アクセスの維持を考慮すると、ベストプラクティスとしては付け替えアプローチがより望ましいと考えられます。

操作	評価	理由
セキュリティグループのルールを全削除	注意が必要	調査アクセスが失われ、元の構成も消える
隔離専用SGへの付け替え	より望ましい	外部通信を遮断しつつ、元のSG構成を保持できる

また、SGの変更は追跡対象の既存接続を即座に切断しない点に注意が必要です。送信元が限定されたルールで許可された接続は追跡対象となり、ルールを削除してもタイムアウトまで維持されます。確立済み接続を即座に遮断するには、ステートレスなネットワークACLの併用やOSレベルのファイアウォール設定が必要になる場合があります。

調査後はシャットダウンを検討する

AWS公式ドキュメントでは、証拠収集が完了した後はインスタンスをシャットダウンすることが推奨されています。隔離環境でインスタンスを実行し続けることは標準的なアプローチとは言えません。必要なログ・スナップショットの取得後は、インスタンスを停止することを検討してください。

SCS試験では「インシデントレスポンスの封じ込めフェーズで適切な操作はどれか」という問いで、この違いが問われます。隔離の目的は「遮断」だけでなく「調査できる状態の維持」と「証拠保全」であるという点を押さえておくことが重要です。