【入門編】フローログ（VPC Flow Logs）を用いた異常通信のフォレンジック – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

こんにちは！インフラやクラウドのセキュリティの世界へようこそ。
初めてサーバーOSの要塞化（ハーデニング）やクラウドのログ監視を任されると、「どこから手をつければいいんだろう…」と不安になりますよね。難しそうな専門用語の壁にぶつかって、圧倒されてしまうこともあるかもしれません。

でも、安心してください。セキュリティの基本原則は、私たちが普段暮らしている現実世界の「防犯」と全く同じなんです。

今回は、クラウドのネットワークを守るための強力な武器である「VPCフローログ（VPC Flow Logs）」を使った異常通信の見つけ方と、それを自動化する仕組みについて、身近な例えを交えながら一歩ずつ優しく紐解いていきましょう！

—

1. 家の鍵と防犯カメラで例える「VPCフローログ」の正体

皆さんが住んでいる「家」を想像してみてください。
頑丈な玄関ドア（ファイアウォール）を閉めていれば、泥棒は簡単に入れません。でも、「誰かが夜中に玄関のドアノブをガチャガチャと回してこじ開けようとした痕跡」や、「怪しいセールスマンがウロウロしていた記録」が残っていたらどうでしょう？「おや、危ない奴が狙っているぞ」と気づくことができますよね。

クラウドの世界でも全く同じことが起きています。AWSやGCPなどのクラウド環境にある仮想サーバー（VPC）のネットワークには、日々たくさんの通信（パケット）がやってきます。

正常な通信： 住民や宅配便など、許可された人が玄関から入ってくる。
拒否された通信（REJECT）： 不審者が鍵のかかったドアを無理やり開けようとして、追い返された記録。

この「誰が、どこから、いつ、あなたのサーバーのドアを叩き、通れたのか（ACCEPT）、通れなかったのか（REJECT）」の全記録をノートにびっしり書き留めてくれる監視カメラの映像、それがVPCフローログなんです。

—

2. 攻撃者はどこを狙う？フローログで「怪しい動き」を見抜くコツ

サイバー攻撃者は、いきなり正面突破でサーバーを乗っ取るわけではありません。彼らはまず、私たちのクラウド環境のあちこちを「スキャン」して、鍵の閉め忘れや、ボロが出そうな隙間を探します。

例えば、VPCフローログを覗いてみると、次のような不審なログがたくさん見つかることがあります。

2.0 123456789012 eni-0123456789abcdef0 198.51.100.45 10.0.1.15 45678 22 6 1 44 1680000000 1680000060 REJECT OK

なんだか呪文のようで見慣れない文字が並んでいますよね。でも、分解して読むとすごくシンプルです。

1. 198.51.100.45：通信の相手（どこから来た？＝怪しいIPアドレス）
2. 10.0.1.15：あなたのサーバーのIPアドレス（どこへ向かった？）
3. 22：ポート番号（何の扉をノックした？＝この場合はリモート管理用のSSH）
4. REJECT：結果（どうなった？＝「拒否したよ！」）

もし、世界中の見知らぬIPアドレスから、あなたのサーバーの管理用ドア（SSHの22番ポートや、Windowsリモートデスクトップの3389番ポートなど）に対して、何千回もREJECTのログが記録されていたら……？
これはまさに、「泥棒があなたの家の鍵をバールでこじ開けようとガシャガシャやっている瞬間」そのものです。

—

3. 手作業での限界：SIEM連携で「自動警備システム」を作ろう

「よし、毎日フローログを眺めて、怪しい奴がいたらブロックしよう！」と思ったそこのあなた、ちょっと待ってください。
クラウドの世界では、世界中から昼夜問わず数百万件ものアクセスが飛んできます。人間の目でこれをずっと監視し続けるのは、不眠不休で防犯カメラのモニターを凝視し続けるようなもので、絶対に無理ですし、疲弊してしまいますよね。

そこで登場するのが、SIEM（Security Information and Event Management：シエム）や、クラウドの自動分析サービスとの連携です。

簡単に言うと、「怪しい動き（例えば、1分間に同じIPアドレスから何回もドアを叩いて拒否されたログ）を見つけたら、自動で警報を鳴らして、その不審者のIPアドレスからのアクセスを自動的に遮断する仕組み」のことです。

自動化のイメージ（仕組みの流れるステップ）

1. ログの収集： VPCフローログが自動的にAmazon S3などのストレージに溜まる。
2. 検知・分析： セキュリティ分析ツール（AWSならAmazon GuardDutyやCloudWatch Logsなど）がリアルタイムでログをチェックする。
3. 自動対応（アクション）： 「おや、このIPアドレス、さっきから不審な動きをしているぞ」と検知した瞬間に、プログラム（AWS Lambdaなど）が走り、ファイアウォール（セキュリティグループやNACL）のルールを書き換えて、そのIPからの通信を完全にシャットアウトする！

この「人間の手を介さずに、瞬時に悪い奴を追い出す仕組み」を作ることが、現代のインフラセキュリティにおける要塞化の極意なんです。

—

4. 実務で使える！設定と分析の第一歩

それでは、実際に私たちが日常の業務でどのようにこの仕組みを取り入れていけばいいのか、具体的な設定や心構えを見ていきましょう。

① まずはVPCフローログを有効化する

クラウド環境を作ったはいいものの、実はフローログがオフになっているケースが新人さんの初期構築ではよくあります。まずはこれを有効にしましょう。

AWSのコンソール、またはTerraformなどのIaC（Infrastructure as Code）ツールを使って、次のように設定します。

# TerraformでのVPCフローログ設定のサンプル例
resource "aws_flow_log" "main_vpc_flow_log" {
  # ログの出力先をCloudWatch Logsグループに指定します
  log_destination      = aws_cloudwatch_log_group.flow_log_group.arn
  # ログの収集元となるVPCのIDを指定します
  vpc_id               = aws_vpc.main.id
  # すべてのトラフィック（許可されたものも拒否されたものも）を記録対象にします
  traffic_type         = "ALL"
  
  tags = {
    Name = "Production-VPC-FlowLog-Guard"
  }
}

ここで traffic_type = "ALL" にしておくのがポイントです。最初は REJECT だけでもいいように思えますが、「どこから正常な通信が来ているか」を知ることも、異常検知の基準（ベースライン）を作る上で非常に大切だからです。

② ログから不審な兆候を見つけるためのクエリ例

CloudWatch Logs Insightsや、S3に溜まったログをAmazon Athenaなどで分析する際によよく使う、検索クエリのイメージを見てみましょう。

-- 過去24時間で、最も多く「拒否（REJECT）」された送信元IPアドレスをランキング形式で特定するクエリ
SELECT 
    srcaddr AS 攻撃者候補のIP,
    count(*) AS 拒否された回数
FROM 
    vpc_flow_logs
WHERE 
    action = 'REJECT'
    -- ここに特定の管理ポート（例: 22番や3389番）を指定して絞り込むこともできます
    AND dstport IN (22, 3389)
GROUP BY 
    srcaddr
ORDER BY 
    拒否された回数 DESC
LIMIT 10;

もしこのクエリを回したときに、見覚えのない海外の特定IPから何万回も拒否ログが上がっていたら……。すでにあなたのサーバーは、ボット（自動化された攻撃プログラム）のターゲットにされている可能性が高いと言えます。

—

まとめ：一歩ずつ、確実な防犯を形にしよう

今回は、VPCフローログを用いた異常通信のフォレンジックと、自動検知の大切さについてお伝えしました。

VPCフローログとは、サーバーの「防犯カメラの映像」である。
ログを見ることで、REJECT（拒否された通信）から泥棒（不正アクセス）の足跡をたどることができる。
人間の手作業には限界があるため、SIEMや自動スクリプトを組み合わせて「自動警備システム」に育てていくことが重要。

セキュリティ対策は、最初から完璧を目指す必要はありません。「まずはフローログを有効にする」「怪しいログの見方を知る」「自動化の仕組みに興味を持つ」というように、一歩ずつ確実に知識と環境を固めていけば、あなたのインフラは確実に鉄壁の要塞へと近づいていきます。

日々の運用の中で、ぜひ今回の内容を思い出してみてくださいね。応援しています！