こんにちは！インフラやクラウドのセキュリティを担当しているエンジニアの皆さん、そして「セキュリティってなんだか難しそう……」と少し不安を感じている開発者の皆さん。日々の開発やサーバー管理、本当にお疲れ様です！
クラウドの世界は、いつでもどこからでもサーバーにアクセスできて本当に便利ですよね。でもその反面、インターネットという「広大な海」にあなたの家（サーバー）がポツンと建っているような状態でもあります。
もし、ある日突然、見知らぬ泥棒があなたの家の窓をこじ開けて侵入してきたら……あなたはどうしますか？パニックになって部屋中をめちゃくちゃに荒らしてしまったり、証拠をうっかり消してしまったりするかもしれません。
クラウドでのインシデント（セキュリティ事故）の初動対応も、これとまったく同じです。今回は、攻撃を受けたときに慌てず騒がず、しかし迅速に被害を最小限に食い止めるための「初動対応のステップ」を、身近な防犯の例えを交えながら優しく紐解いていきたいと思います。一歩ずつ、一緒に学んでいきましょうね！
—
1. 泥棒が入ってきた！その時、家（サーバー）の鍵をどう閉めるか？（ネットワーク隔離）
深夜、自宅のリビングから「ガチャッ」と物音がしたとします。泥棒の気配がしたら、あなたは何を一番最初に行いますか？
「犯人の顔をじっくり見てやろう」と部屋の電気をすべてつけますか？いいえ、違いますよね。まず自分や家族の安全を確保し、これ以上被害が広がらないように、その部屋のドアをそっと閉めて鍵をかけ、警察（この場合はセキュリティチーム）に連絡するはずです。
クラウドの世界でも全く同じです。サーバーが攻撃を受けている（あるいは怪しい動きをしている）と分かった瞬間、一番最初に行うべき最優先事項は「ネットワークからの隔離」です。
ネットワーク隔離の基本アプローチ
攻撃者が踏み台にしたサーバーをインターネットにつないだままにしておくと、さらに別の重要なサーバーへ攻撃を広げられたり、大事なデータを外部に持ち出されたりしてしまいます。
クラウド（AWSやAzure、GCPなど）では、物理的なケーブルを抜く代わりに、「セキュリティグループ（ファイアウォール）」や「ネットワークACL」のルールを瞬時に変更して、外部からの通信をすべて遮断します。
例えば、AWSのセキュリティグループで「すべてのインバウンド（外部からの通信）を遮断する」ための設定変更や、隔離用の隔離専用セキュリティグループ（一切の通信を許可しないもの）へ付け替える作業がこれに該当します。
# 【参考例】AWS CLIを使って、怪しいインスタンスのセキュリティグループを「隔離用（通信遮断）」に付け替える手順
# ※実務では事前に「隔離用セキュリティグループ（インバウンド・アウトバウンド全て拒否）」を作成しておきます。
aws ec2 modify-instance-attribute \
--instance-id i-0123456789abcdef0 \
--groups sg-99999999999999999 # ← 全通信を遮断する隔離用セキュリティグループのIDを指定このコマンドを叩くことで、サーバーはインターネットから完全に「孤島」の状態になります。攻撃者はこれ以上手出しができなくなりますが、私たちも中に入れなくなる……わけではありません。後述する「踏み台サーバー」やクラウド特有の仕組みを使って、安全に中を調査する道を残しておくのがプロの技です。
—
2. 犯人の足跡と現場の写真を残す（スナップショット取得とログ保全）
さて、泥棒を一部屋に閉じ込めて安全を確保したら、次に警察が来るまでの間に「現場の証拠」をしっかり残さなければいけませんよね。床に残った足跡、指紋、荒らされた様子などをそのままの状態で写真に収めるはずです。
サーバーの世界でも、電源をプツッと切ってしまうのは一番やってはいけないNG行動です。電源を切ってしまうと、メモリ（RAM）の中に残っていた「今まさに動いていた悪意あるプログラムの断片」や「一時的なパスワード」がすべて消えてなくなってしまうからです。
そのため、以下の2つの手順を泥縄式ではなく、冷静に行う必要があります。
① ディスクの「スナップショット（写真）」を撮る
サーバーのハードディスク（OSが入っている部分）の状態を、その瞬間に丸ごとコピーして保存します。これが「現場の写真撮影」です。
# 【参考例】AWS CLIで現在のルートボリュームのスナップショットを取得するコマンド
aws ec2 create-snapshot \
--volume-id vol-0123456789abcdef0 \
--description "Incident Response Snapshot: 202X-YY-ZZ Investigation" \
--tag-specifications 'ResourceType=snapshot,Tags=[{Key=Purpose,Value=Forensics}]'このスナップショットさえ取得できれば、万が一ライブ中のサーバーがクラッシュしても、安全な別環境でその当時の状態を再現してじっくり捜査（フォレンジック調査）ができます。
② 通信ログやメモリの保全
次に、サーバーの中にある「誰が、いつ、どこからアクセスしてきたか」のログを安全な場所へコピーします。
例えば、Linuxサーバーであれば以下のログファイルが重要な証拠品になります。
/var/log/auth.logまたは/var/log/secure（ログイン成功・失敗の履歴）/var/log/nginx/や/var/log/httpd/（Webサーバーへのアクセス履歴）historyコマンドの履歴（攻撃者が実行したコマンドの痕跡）
これらのファイルや、メモリダンプ（メモリ上のデータの保存）を、改ざんされないように別の安全なストレージ（S3バケットなど）へ転送・保管します。
—
3. 集めた証拠をどう読み解くか？（分析フローの基本）
証拠が集まったら、いよいよ「どうやって侵入されたのか（原因）」と「何をされたのか（被害範囲）」を解き明かす分析のフェーズに入ります。ここでは、新人エンジニアの皆さんが最初につまづきやすいポイントを整理した、基本的な分析フローをご紹介します。
[1. タイムラインの作成]
└─ ログを時間順に並べ、「何時何分にどこからアクセスがあったか」を可視化する。
[2. 侵入経路の特定]
└─ Webアプリの脆弱性（SQLインジェクション等）か、弱いパスワードの総当たり（ブルートフォース）かを探る。
[3. 被害範囲の確認（水平展開の調査）]
└─ このサーバーを踏み台にして、社内の他のデータベース等にアクセスされていないか確認する。実際のログ調査で見るべきポイントの例
例えば、Linuxの認証ログ (/var/log/secure) を見るとき、以下のような怪しい連続ログインの痕跡がないかを探します。
# /var/log/secure のログサンプル（攻撃者の総当たり攻撃の例）
Oct 10 14:23:01 web-server-01 sshd[1542]: Failed password for invalid user admin from 198.51.100.42 port 54321 ssh2
Oct 10 14:23:03 web-server-01 sshd[1544]: Failed password for invalid user root from 198.51.100.42 port 54321 ssh2
Oct 10 14:23:05 web-server-01 sshd[1546]: Accepted password for root from 198.51.100.42 port 54321 ssh2 ← ここで侵入されている！「あ、198.51.100.42というIPアドレスから、14時23分5秒に root ユーザーとしてログインされてしまっているぞ！」ということが、このログから読み解けますね。このように、点と点を繋ぎ合わせてストーリーを組み立てていくのがインシデント調査の醍醐味（そして大変なところ）です。
—
おわりに：恐れず、チームで備えよう
いかがでしたでしょうか？
クラウドネットワークでのインシデント初動対応は、一見すると難解なコマンドの連続に見えますが、やっていることは「家の鍵を閉めて（ネットワーク隔離）、警察のために現場の写真を撮り（スナップショット）、足跡を調べる（ログ保全・分析）」という、現実世界の防犯とまったく同じです。
セキュリティの事故は、どんなに気をつけていても完全に防ぐことは難しいものです。だからこそ、「もし起きてしまったらどう動くか」という手順（プレイブック）をあらかじめチームで共有し、いざという時に慌てず冷静に対応できるようにしておくことが何よりも強力な防御になります。
最初は分からないことばかりで当たり前です。一歩ずつ、焦らず、日々の運用の中で知識と経験を積み重ねていきましょうね。あなたのその丁寧なセキュリティへの意識が、組織の大切なシステムとデータを守る最強の盾になります。応援しています！
コメント