こんにちは！クラウドの世界へようこそ。SREとして日々たくさんのシステムを見守っている私ですが、今回はインフラやネットワークの世界に一歩踏み出したばかりのあなたに向けて、とってもワクワクする（そして実務でめちゃくちゃ役立つ）テーマをお届けします。
テーマはずばり、「セキュリティ監査におけるNATゲートウェイのVPCフローログ解析手法」です！
「うわ、なんだか文字だけで難しそう……英語のヘッダー名とか出てきたらどうしよう……」なんて、眉間にシワを寄せていませんか？大丈夫です！一歩ずつ、私たちの身近な例えを交えながら優しく紐解いていきますので、安心してくださいね。
それでは、パケットがネットワークの海を駆け巡る冒険に出発しましょう！
—
1. そもそも「NATゲートウェイ」と「VPCフローログ」ってなに？
まずは、今回の主役である2つのアイテムを、身近な世界に置き換えて理解していきましょう。
郵便局の本社窓口である「NATゲートウェイ」
私たちが暮らす安全なアパート（AWSやGCPの中にあるプライベートサブネット）を想像してみてください。このアパートの住人たちは、外のインターネットの世界（お買い物や外部APIとの通信）と手紙のやり取りをしたいのですが、セキュリティ上の理由から、アパートの住所（プライベートIPアドレス）をそのまま外の世界に知られたくありません。
そこで登場するのが、アパートの管理人さんであり、外の世界への唯一の窓口であるNATゲートウェイ（Network Address Translation Gateway）です。
住人たちが外宛てに出す手紙は、すべて一度管理人さん（NATゲートウェイ）のところに集められます。管理人さんは、手紙の差出人を自分の名前に書き換えてから外の世界へ送り出し、返事が返ってきたら、元の住人にこっそり届け直してくれます。
街の監視カメラである「VPCフローログ」
さて、この管理人さんの窓口やアパートの出入り口には、24時間体制で通行人を記録する監視カメラが設置されています。これがVPCフローログです。
「誰が、どこ宛てに、どれくらいの大きさの荷物を送ったのか」を、ノートにびっしり記録してくれるスグレモノなんですよ。
セキュリティ監査とは、まさにこの監視カメラの記録（ログ）をチェックして、「怪しい人が出入りしていないか」「ルールを破って外に飛び出そうとした不審者はいないか」を点検するお仕事なんです！
—
2. なぜNATゲートウェイのログを監査するの？
「プライベートサブネットにあるサーバーなら、そもそも外から攻撃されない安全な場所じゃないの？」って思いますよね。その通り、基本的には安全です。
しかし、こんなシナリオを想像してみてください。
アパートに住んでいるお掃除ロボット（サーバー上で動くアプリケーション）が、知らないうちに悪者に乗っ取られてしまい、外の怪しい組織（悪意あるサーバー）へ向けて、アパートの秘密のデータをこっそり送り出そうとしたとします。
もし、VPCフローログという監視カメラの記録を見逃していたら……？ データの持ち出しに気づくのが遅れて、大惨事になってしまうかもしれませんよね。
だからこそ、私たちは定期的にNATゲートウェイを通過する通信を監視し、「おや、この送信先はなんだか怪しいぞ」「許可されていない通信をしようとしてブロック（REJECT）された形跡があるぞ」といった異変をいち早く察知する必要があるのです。
—
3. VPCフローログの読み方をマスターしよう
それでは、実際の監視カメラの記録（VPCフローログ）がどんな形をしているのか、中身をのぞいてみましょう。
AWSなどのクラウド環境でVPCフローログを出力すると、次のようなテキストデータがズラリと並びます。
# バージョン アカウントID インターフェースID 送信元IP 宛先IP 送信元ポート 宛先ポート プロトコル パケット数 バイト数 開始時刻 終了時刻 アクション ログステータス
2 123456789012 enit-abcdef0123456789 10.0.1.15 198.51.100.42 45321 443 6 15 1200 1689324000 1689324060 ACCEPT OK
2 123456789012 enit-abcdef0123456789 10.0.1.15 203.0.113.99 52112 80 6 0 0 1689324100 1689324160 REJECT OK「うわっ、数字だらけで目が回る！」という声が聞こえてきそうですね。でも大丈夫。よく見るポイントは決まっています。上から順番に、意味を優しく翻訳していきましょう！
10.0.1.15（送信元IP）：アパートのどの部屋（サーバー）からの通信か。198.51.100.42（宛先IP）：手紙の宛先（インターネット上のサーバー）。443または80（宛先ポート）：お相手のドアの番号（Web通信なら443など）。6（プロトコル）：通信のルール（数字の6は、おなじみのTCP通信を意味します）。ACCEPTまたはREJECT（アクション）：ここが超重要！管理人さんが「通してあげた（ACCEPT）」のか、「怪しいから追い返した（REJECT）」のかを表します。
セキュリティ監査で特に目を光らせるべきなのは、ズバリこのREJECT（拒否されたトラフィック）の記録です！
—
4. 実践！セキュリティ監査のためのログ解析手順
ここからは、実際にクラウド環境のログを解析して、セキュリティ上のリスクを見つける手順をハンズオン感覚で見ていきましょう。
今回は、AWSのAmazon Athena（S3に保存されたログをSQLでペタペタ検索できる魔法のようなサービス）を使った解析を例に解説します。
ステップ1: Athenaでログ用のテーブルを作る
まずは、VPCフローログが保存されているAmazon S3バケットを、AthenaからSQLで検索できるように「テーブル」という見出しを作ります。以下のクエリ（命令文）をAthenaのコンソールに貼り付けて実行してみましょう。
-- VPCフローログを検索するためのテーブルを作成するよ
CREATE EXTERNAL TABLE IF NOT EXISTS vpc_flow_logs (
version int,
account_id string,
interface_id string,
srcaddr string, -- 送信元IPアドレス
dstaddr string, -- 宛先IPアドレス
srcport int, -- 送信元ポート番号
dstport int, -- 宛先ポート番号
protocol int, -- プロトコル番号
packets bigint, -- パケット数
bytes bigint, -- バイト数
start_time int, -- 通信開始時間
end_time int, -- 通信終了時間
action string, -- ACCEPT または REJECT
log_status string
)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ' '
LOCATION 's3://あなたのバケット名/path/to/flow/logs/'
TBLPROPERTIES ("skip.header.line.count"="1");ステップ2: 拒否された（REJECTされた）怪しい通信を炙り出す
テーブルができたら、いよいよセキュリティ監査のメインディッシュです。「NATゲートウェイを通ろうとしたけれど、セキュリティグループやネットワークACLのルールに引っかかって追い返された通信」がないか、SQLで一網打尽に探し出します。
以下のクエリを実行してみてください。
-- REJECTされた通信を送信元IPごとに集計して、怪しい挙動がないかチェックするよ
SELECT
srcaddr AS 内部サーバーIP,
dstaddr AS 宛先外部IP,
dstport AS 宛先ポート,
COUNT(*) AS 拒否された回数
FROM vpc_flow_logs
WHERE action = 'REJECT' -- 拒否されたものだけに絞り込む！
AND ds >= '2023-10-01' -- 監査したい期間を指定する
GROUP BY srcaddr, dstaddr, dstport
ORDER BY 拒否された回数 DESC
LIMIT 10;このクエリを実行した結果、もし見覚えのない内部サーバーIP（srcaddr）から、変な宛先ポートに向けて何回も REJECT さえちゃっているログが出てきたら……？
それは、「内部のサーバーがウイルスに感染しているかも！」「設定ミスで外部への不正アクセスを試みているかも！」という重大なシグナルになります。すぐに現場のエンジニアと連携して、該当するサーバーの健康診断を行う必要があります。
—
5. 日々のSRE現場から：監査を成功させるためのコツ
最後に、現場で数々のトラブルを乗り越えてきた私から、実務で役立つちょっとしたコツをお伝えします。
1. ベースラインを知る（「いつも通り」を知る）
セキュリティ監査で一番大切なのは、「普段のシステムがどんな通信をしているか」を知っておくことです。いつもと違うパケットの量や、見慣れない宛先IPに気づくためには、まず「平時のログ」を眺めておくことが最大の近道になります。
2. アラートを自動化する
毎回手動でAthenaのクエリをポチポチ叩くのは大変ですよね。Amazon CloudWatch Logsのメトリクスフィルターや、Amazon GuardDutyなどのセキュリティサービスを組み合わせて、「REJECTの数が急増したらSlackに通知が飛ぶ仕組み」を作っておくと、夜もぐっすり眠れるようになりますよ。
—
おわりに
いかがでしたでしょうか？
「NATゲートウェイのVPCフローログ解析」と聞くと、なんだか難しそうな呪文のように聞こえますが、要するに「郵便局の窓口にある監視カメラの記録を紐解いて、不審な手紙のやり取りがないかチェックするお仕事」なんです。
ネットワークやセキュリティの世界は、こうした身近な例えに置き換えていくと、驚くほどすんなりと頭に入ってきます。
インフラ初学者のあなたも、今日から立派なセキュリティ監査官の第一歩を踏み出しました。ぜひ、ご自身の環境でもフローログを有効にして、パケットたちの冒険の足跡をのぞいてみてくださいね！
それでは、また次回の技術ブログでお会いしましょう。良きクラウドライフを！
コメント