こんにちは！クラウドインフラの保守や開発、お疲れ様です。日々の業務の中で、「もしも私たちのクラウドサーバーがサイバー攻撃を受けたらどうしよう…」と、ふと不安になることはありませんか？
物理的なサーバーであれば、怪しい動きがあったときにサーバーの電源コードを抜いたり、中のパーツを調べたりできますよね。でも、AWSやAzure、GCPといった「クラウドの世界」にあるサーバー（インスタンス）は、私たちが直接触ることができません。画面の向こう側の、雲（クラウド）のどこかで動いているのです。
今回は、そんなクラウド環境でセキュリティインシデント（事件）が起きたとき、私たちがどうやってサーバーの「記憶（メモリ）」を救い出し、調査すればいいのかについて、身近な例えを交えながら一歩ずつ優しく紐解いていきたいと思います！
—
1. クラウドのメモリ調査って、なぜそんなに難いの？
まずは、私たちが普段使っているパソコンや、家の中の防犯を思い浮かべてみてください。
あなたが家に帰ってきたとき、リビングのテーブルの上に「メモ書き」がたくさん置いてあったとします。そのメモには、今日誰が来て、何を話して、どこに鍵を置いたかという「生々しい情報」が書かれています。
パソコンやサーバーの世界で言うと、この「テーブルの上のメモ書き」がメモリ（RAM）にあたります。メモリには、現在進行形で動いているプログラム、入力されたパスワード、悪いハッカーがこっそり仕込んだ不正なプログラム（マルウェア）の痕跡が、文字通り「むき出し」の状態で残っています。
オンプレミス（自分たちの手元にある物理サーバー）であれば、専用の道具を使ってこのテーブルの上のメモをごっそり写真に撮る（メモリダンプを取得する）ことができました。
しかし、クラウド環境では話が別です。
AWSやAzureといったクラウド事業者（ハイパーバイザ）が、私たちのサーバーの足元をがっちりと固めているため、私たちユーザーが「ちょっとサーバーの頭の中を覗かせて！」と直接メモリを覗き見ることができない仕組みになっています。
「えっ、じゃあクラウドでサーバーがハッキングされたら、犯人の痕跡は諦めるしかないの？」
いいえ、そんなことはありません！ここで登場するのが、今回のお題である「スナップショットベースのメモリ取得」という、ちょっと裏技的なアプローチなんです。
—
2. スナップショットとは？ 家の「合鍵」と「タイムカプセル」
クラウド環境における「スナップショット」とは、簡単に言うと「その瞬間のサーバーの状態を丸ごと保存したタイムカプセル」のようなものです。
私たちが直接メモリを覗けないなら、サーバーが動いている「世界ごと」一時停止させて、その瞬間の状態をまるっと保存（スナップショットを取得）してしまえばいい、というのがこの手法の考え方です。
ハイパーバイザ（クラウドの基盤システム）のレベルで、仮想マシンのディスクだけでなく、メモリの内容も含めてまるごとストレージに書き出させます。これによって、クラウドの制限を回避しつつ、フォレンジック（鑑識調査）に必要な「脳みその中身」を手に入れることができるのです。
—
3. 実践！AWSでのメモリダンプ取得に向けたアプローチ
それでは、実際にAWS（Amazon EC2）を例にして、いざという時にどう動けばいいのかを見ていきましょう。
「いざインシデントが起きた！」という現場では、パニックになりがちですが、冷静に手順を踏むことが何よりも大切です。
ステップ1：インスタンスの整合性を保った停止と保存
ただ闇雲に電源を落とすと、メモリ上の大切なデータが消えてしまいます（メモリは電気を失うと消える「揮発性」の性質を持っています）。そのため、ハイパーバイザの機能を使って、メモリ状態を含めたスナップショットを取得します。
AWS CLI（コマンドラインツール）を使用する場合、以下のようなイメージで操作を行います。
# 【重要】フォレンジック調査のために、現在のEC2インスタンスのAMI（Amazonマシンイメージ）と
# メモリを含めたハイパーバイザレベルのスナップショットを同時に取得するコマンドの例です。
# 実際のインシデントレスポンスでは、証拠保全のガイドラインに従って実行します。
aws ec2 create-image \
--instance-id i-0123456789abcdef0 \
--name "Incident-Response-Snapshot-20231025" \
--description "フォレンジック調査用のメモリ・ディスク統合スナップショット" \
--no-rebootここで大切なポイントは、--no-reboot（再起動をしない）オプションです。サーバーを再起動してしまうと、悪意あるプログラムがメモリ上で隠れてしまい、証拠が消えてしまうリスクがあるため、動いている状態のままスナップショットを生成します。
—
ステップ2：取得したスナップショットを安全な「検体分析用環境」へ移動
スナップショットが無事に取得できたら、本番のシステムから切り離す必要があります。
事件現場（本番環境）の証拠品をそのまま荒らしてしまうのはNGなのと同じで、取得したスナップショットから別の調査用インスタンス（フォレンジック専用の隔離されたAWSアカウントやVPC）を立ち上げます。
# 調査用の独立したEC2インスタンスを、取得したスナップショット（AMI）から起動する例
aws ec2 run-instances \
--image-id ami-0987654321fedcba0 \
--instance-type t3.medium \
--key-name forensic-analyst-key \
--security-group-ids sg-0123456789abcdef0 \
--subnet-id subnet-0123456789abcdef0これで、本番環境を止める時間を最小限に抑えつつ、安全な場所でじっくりとサーバーの「脳みそ（メモリ）」を解析する準備が整いました。
—
4. 現場のアナリストが教える、クラウド特有の「罠」と盲点
さて、ここまで聞くと「なんだ、スナップショットを撮ればバッチリ安心だね！」と思われるかもしれませんが、現場のプロはもう少しシビアに見ています。
クラウドでのスナップショットベースのメモリ取得には、いくつかの「盲点」があります。
1. タイムラグの壁
巨大なインスタンス（例えばメモリが数百GBあるもの）の場合、ハイパーバイザがメモリの内容をストレージに書き出すまでにわずかな「時間（ラグ）」が生じます。この間に、巧妙な攻撃者は証拠を消したり、自分たちの痕跡をさらに隠そうとしたりすることがあります。
2. 暗号化の鍵（KMS）の管理
もし元のインスタンスのストレージがAWS KMSなどで暗号化されている場合、スナップショットを別の調査用アカウントに持っていくときに「復号化の権限」で詰んでしまうことがあります。日頃から、インシデント時にどの権限で誰がデータを復号できるのかをシミュレーションしておく必要があります。
家で言うなら、「防犯カメラの映像は撮れたけれど、金庫の鍵が開けられない！」という状態に似ています。だからこそ、平時の備えが命取りになるのです。
—
5. 一歩ずつ対策を学んでいきましょう！
クラウド環境におけるメモリフォレンジックは、一見すると黒魔術のように難しく感じるかもしれません。「ハイパーバイザ」「スナップショット」「KMS」……聞き慣れない言葉の連続で、頭がクラクラしますよね。
でも、安心してください。セキュリティのプロたちも、最初は「サーバーの電源の落とし方」から学びました。
今日からできる小さな一歩として、以下を意識してみてください：
- 自分たちが使っているクラウド環境（AWS/Azure/GCP）で、「もし今スナップショットを取るならどういう手順になるか」のドキュメントに一度目を通してみる。
- 権限周り（誰がバックアップやスナップショットを作れるか）の棚卸しをしてみる。
「難しそう」を「ちょっと分かったかも」に変えるだけで、あなたの会社のセキュリティはぐっと強固になります。一緒に一歩ずつ、安全なクラウド環境を作っていきましょうね！
コメント