【入門編】 クラウド環境におけるVPCフローログを用いたネットワークトラフィック分析 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

こんにちは!クラウドインフラのセキュリティや、日々のネットワーク監視に奮闘されている新人のIT担当者さん、そして開発者の皆さん。セキュリティの世界へようこそ!

「ファイアウォールやIDSなんて、専門家がやる難しい話でしょ……」なんて、思っていませんか?
大丈夫です。一歩ずつ、身近な例えから紐解いていけば、誰でも必ず「ネットワークの防犯」ができるようになります。今回は、クラウド環境(AWSのVPCなど)における「VPCフローログ」を使ったトラフィック分析と、怪しい通信を見つけ出す自動監視の仕組みについて、一緒に優しく学んでいきましょう!

—

1. なぜ「VPCフローログ」が必要なの?(家の鍵と防犯カメラの例え)

皆さんが暮らす「家」を想像してみてください。
玄関には頑丈な鍵(ファイアウォール)をかけ、窓には補助錠をつけて、「怪しい人が簡単に入れないように」対策をしていますよね。

クラウドの世界でも同じです。AWSなどのクラウド上にあるサーバー(仮想マシン)の周りには、「セキュリティグループ」や「ネットワークACL」という名前の頑丈な門や鍵が用意されています。これらは「誰が中に入れて、誰を締め出すか」を決める非常に優秀な門番です。

しかし、ここで少し考えてみてください。
頑丈な鍵をかけて安心しているその裏で、「深夜に変なセールスマンが玄関のドアノブをしつこくガチャガチャ回していないか」「留守の間に、裏口から誰かが覗き込んでいないか」、皆さんは気づくことができるでしょうか?

通常のファイアウォールは、「通す・通さない」の判断はしてくれますが、「誰がどれくらいの時間、どの部屋を覗き見ようとしたか」の細かい足跡までは、いちいち覚えていてくれません。

そこで登場するのが、今回の主役である「VPCフローログ(VPC Flow Logs)」です。
これは、クラウド内のネットワークを行き来するすべての通信の「足跡(誰が、どこへ、いつ、どれくらいのデータ量を送ったか)」を、まるで防犯カメラの映像のように記録し続ける仕組みなんです!

—

2. 攻撃者はどこを狙う?フローログで分かる不審な動き

サイバー攻撃者は、いきなり正面からドカーンとサーバーを壊すようなことはしません。彼らはもっと静かに、忍びのようにやってきます。

例えば、こんなシナリオを想像してください。

1. ポートスキャン(下見):
攻撃者はまず、あなたのサーバーの周りをウロウロしながら、「開いている窓(使われているポート)」がどこにあるか、片っ端から確認します。家の周りをぐるっと一周して、鍵がかかっている窓を探る泥棒の行動そのものですね。
2. 不正な外部通信(データ持ち出し・C2通信):
もし運悪くサーバーのセキュリティに隙があり、侵入を許してしまったとします。その侵入者は、盗んだデータを自分のアジト(外部の攻撃者サーバー)にこっそり送ろうとします。「おーい、機密データをこっちに送ってくれよ!」という通信が、クラウドの内部から外部に向かって発生するわけです。

こうした不審な動きは、サーバーの中に入らなくても、「ネットワークの足跡(VPCフローログ)」を眺めていれば一発でバレるようになっています。
「あれ? この海外の怪しいIPアドレスから、うちのサーバーのデータベース用ポートに対して、何千回も接続が試みられているぞ……?」といった違和感に気づけるのが、フローログ分析の最大の強みです。

—

3. 実践!VPCフローログの基本と読み方

では、実際にVPCフローログがどのような形をしているのか、中身を覗いてみましょう。フローログは、以下のようなスペース区切りのテキストデータとして、Amazon S3などの保存先にポツンと出力されます。

# バージョン アカウントID インターフェイスID 送信元IP 宛先IP 送信元ポート 宛先ポート プロトコル パケット数 バイト数 開始時刻 終了時刻 アクション ログステータス
2 123456789012 eni-0123456789abcdef0 203.0.113.50 10.0.1.100 54321 80 6 1 40 1672531200 1672531260 ACCEPT OK

なんだか数字やアルファベットが並んでいて難しそうに見えますよね。でも、分解してみるとすごくシンプルです。

  • 送信元IP (203.0.113.50): 通信をしかけてきた相手の住所(この場合は外の誰か)
  • 宛先IP (10.0.1.100): 通信を受け取ったあなたのサーバーの住所
  • 宛先ポート (80): サーバーのどの部屋(Webサービスなど)に用事があるのか
  • プロトコル (6): TCPというお決まりの通信ルールを使っているよ、という印
  • アクション (ACCEPT または REJECT): 門番(ファイアウォール)がその通信を「通した(ACCEPT)」のか、「追い返した(REJECT)」のか

ここでセキュリティ担当者として特に注目すべきなのは、「REJECT(拒否されているのに、何度もトライされている通信)」や、「普段は絶対に通信しない怪しい外部IPへのACCEPT(内部からのデータ持ち出しの疑い)」です。

—

4. 監視を自動化しよう!Amazon Athenaを使った分析パイプライン

とはいえ、毎日数ギガバイト、数テラバイトもある膨大なログのテキストを、人間の目で一つひとつチェックするのは不可能ですよね。そこで、クラウドの便利な仕組みを使って、「怪しい通信があったら自動でアラートを上げる仕組み(監視パイプライン)」を作りましょう。

今回は、S3に溜まったVPCフローログに対して、SQLを使ってサクッと検索できる「Amazon Athena(アテナ)」というサービスを利用します。

ステップ1: Athena用のテーブルを作成するSQL

まずは、S3にあるフローログのテキストを、データベースの表(テーブル)として扱えるようにするための設定(DDL)を流します。

-- VPCフローログをAthenaで検索できるようにテーブルを作成します
CREATE EXTERNAL TABLE IF NOT EXISTS vpc_flow_logs (
  version int,
  account_id string,
  interface_id string,
  source_address string,
  destination_address string,
  source_port int,
  destination_port int,
  protocol int,
  packets bigint,
  bytes bigint,
  start_time int,
  end_time int,
  action string,
  log_status string
)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ' '
LOCATION 's3://your-vpc-flow-logs-bucket-name/AWSLogs/123456789012/vpcflowlogs/us-east-1/'
TBLPROPERTIES ("skip.header.line.count"="1");

*※ s3://your-... の部分は、実際のログが保存されているご自身のS3バケットのパスに書き換えてくださいね。*

ステップ2: 怪しい「拒否された通信」を炙り出すクエリ

テーブルができたら、次のようなSQLを実行して、「ファイアウォールに何度もブロックされているのに、しつこくアプローチしてくる怪しい奴ら」をランキング形式で炙り出してみましょう。

-- ファイアウォールに拒否された(REJECT)通信のうち、送信元IPごとの試行回数を集計する
SELECT 
    source_address AS 攻撃者のIPアドレス,
    destination_port AS 狙われたポート,
    count(*) AS ブロックされた回数
FROM 
    vpc_flow_logs
WHERE 
    action = 'REJECT' -- 拒否された通信に絞る
    AND start_time >= cast(to_unixtime(current_timestamp - interval '1' hour) as bigint) -- 過去1時間以内のデータ
GROUP BY 
    source_address, 
    destination_port
ORDER BY 
    ブロックされた回数 DESC
LIMIT 10;

このクエリを、例えばAmazon EventBridgeやAWS Lambdaを使って「1時間に1回自動実行」するように設定しておきます。もし「ブロックされた回数」が異常に跳ね上がっているIPが見つかったら、Slackやメールに自動で通知が飛ぶように連携しておけば、立派な自動監視パイプラインの完成です!

—

5. まとめと一歩を踏み出すあなたへ

お疲れ様でした!今回は、VPCフローログの基本概念から、家の防犯に例えた理由、そしてAthenaを使った実践的なログ分析クエリまでを駆け足で見てきました。

セキュリティの対策というと、「完璧な防御壁を作らなきゃいけない」と身構えてしまいがちですが、現実のサイバー空間では「100%侵入を防ぐ」ことは不可能です。だからこそ、「入ろうとしている奴の足跡をしっかり記録し(VPCフローログ)、いち早く異変に気づいて対処する(監視と自動化)」という、ボディーガードのような視点が何よりも大切になります。

最初は複雑に見えるSQLやクラウドの用語も、実際に手を動かして「お、うちのサーバーに変な海外からアクセスが来てたんだな」と自分の目で確かめられるようになると、すごく面白くなってきますよ。

まずは小さな環境から、フローログを有効にしてS3に溜めるところから始めてみませんか?
一歩ずつ、確実にセキュリティのスキルを磨いていきましょう。応援しています!

コメント

タイトルとURLをコピーしました