こんにちは！インフラ構築や開発の現場に飛び込んだばかりの頃は、覚えることが山ほどあって大変ですよね。「ネットワークセグメンテーション」や「マイクロセグメンテーション」なんて聞くと、なんだか呪文のように難しく感じるかもしれませんが、安心してください。一歩ずつ、身近な例えから紐解いていけば、誰でも「なるほど！」と腑に落ちるはずです。
今日は、クラウド（VPC）の世界でなぜ部屋の区切りが重要なのか、そしてどうやって泥棒（攻撃者）の侵入や横移動（ラテラルムーブメント）を防ぐのかを、一緒に優しく学んでいきましょう！
—
1. 家の防犯に例えてみる「VPCとセグメンテーション」の基本
想像してみてください。あなたは一戸建ての大きな家を建てました。この家全体が、クラウド上の空間である VPC（仮想プライベートクラウド） だと思ってください。
もし、この家の中に玄関の鍵しかなかったらどうなるでしょうか？
一度泥棒に玄関を破られて侵入されたら、リビングも、寝室も、貴重品が置いてある書斎も、すべてフリーパスになってしまいますよね。家の中を自由に歩き回られ（これがセキュリティ用語でいうラテラルムーブメント＝横移動です）、大切なデータを根こそぎ盗まれてしまいます。
これを防ぐために、昔ながらのネットワークセグメンテーション（サブネット分離）では、家の中に「頑丈な廊下のドア」を作りました。
「ここから先はプライベートな寝室ゾーンだから、パスワードを知っている家族しか入れませんよ」という境界線を作るイメージですね。
さらに進化版！「マイクロセグメンテーション」とは？
じゃあ、さらにセキュリティをガチガチに固める「マイクロセグメンテーション」はどういうことでしょうか？
これは、家の中のすべての部屋のドアに個別の電子ロックをかけ、誰がどの部屋を行き来していいかを厳密にリスト化することです。
- リビングにいる人は、キッチンには行けるけど、金庫のある書斎には絶対に絶対に入れない。
- 万が一、リビングの窓から侵入されても、キッチンのドアですぐに足止めを食らう。
クラウドの世界では、この「各部屋の電子ロック」の役割を果たすのが、これから解説する 「セキュリティグループ（ファイアウォール）」 なんです。
—
2. 攻撃者はどうやって社内を「横移動」するのか？
セキュリティの現場で一番怖いのは、最初の侵入（初期ペネトレーション）そのものよりも、「侵入されたあとに、いかに網の目のように動き回られるか」です。
例えば、会社のシステムの中で、世界中から誰でもアクセスできる「Webサーバー（ホームページを表示するサーバー）」が1台あるとします。もし、このWebサーバーにプログラムの弱点（脆弱性）が見つかり、攻撃者に乗っ取りの合図を出されてしまったとしましょう。
もし、Webサーバーと同じ部屋（サブネット）に、顧客のクレジットカード情報が入っているデータベースサーバーが「鍵なし」で置いてあったらどうなりますか？
攻撃者はWebサーバーを乗っ取ったあと、すぐ隣のデータベースサーバーへスルスルと侵入し、データをすべて盗み出してしまいます。これが、セグメンテーションをサボったときに起こる最悪のシナリオです。
だからこそ、「Webサーバーの部屋からデータベースサーバーの部屋へは、特定の通信（データベースへの問い合わせ）以外は一切通さない！」という厳格なルールが必要になるんですね。
—
3. 実践！クラウドでのマイクロセグメンテーション設定例
それでは、実務のインフラ構築でよく使われるクラウド（例：AWSなど）の環境を想定して、セキュリティグループを使った具体的な設定を見てみましょう。
今回は、「Webサーバーからはデータベースサーバーへ接続できるけれど、それ以外の余計な通信はすべてブロックする」という、最小権限の原則に基づいた設定をコード（Terraformというインフラ定義ツール）で書いてみます。
難しそうに見えますが、日本語のコメントを読めば「あ、こういうことね！」とすぐに分かりますよ。
# 1. データベースサーバー用のセキュリティグループ定義
# ここが「金庫の部屋の電子ロック」に相当します。
resource "aws_security_group" "db_server_sg" {
name -- "db-server-security-group"
description -- "データベースサーバー用の厳格なアクセス制御"
vortex_id -- aws_vpc.main.id
# 【許可ルール】Webサーバーからのデータベース通信（MySQLのポート: 3306）のみを許可する
ingress {
description -- "Webサーバーからの安全なデータベースアクセスのみ許可"
from_port -- 3306
to_port -- 3306
protocol -- "tcp"
# ここがポイント！「どのサーバーからでもOK」ではなく、「Webサーバーのセキュリティグループからのみ」に限定します
security_groups -- [aws_security_group.web_server_sg.id]
}
# 【拒否ルール（デフォルト）】上記以外のすべての受信通信は自動的にブロックされます（暗黙の拒否）
egress {
from_port -- 0
to_port -- 0
protocol -- "-1"
cidr_blocks -- ["0.0.0.0/0"] # 外部へのパッチ適用などの通信は許可
}
}この設定の素晴らしいところは、IPアドレスの変更などに左右されず、「Webサーバーという役割を持つグループからしかデータベースに触らせない」という確実な境界線を作れている点です。万が一、別の一般PCや関係のないサーバーが侵害されても、このデータベースの部屋には物理的（論理的）に入ることができません。
—
4. 一歩ずつ対策を進めるためのチェックリスト
現場でインフラやアプリを触るとき、まずは以下のポイントから見直してみましょう。すべてを完璧にする必要はありません。一歩ずつ進めば確実にセキュリティは強固になります！
1. 「とりあえず全部通信OK（0.0.0.0/0）」のルールを見つける
- セキュリティグループやファイアウォールの設定画面を開き、どこからでもアクセスできる緩い設定になっていないか確認する。
2. サーバーの「役割」ごとにグループを分ける
- Webサーバー、APサーバー、DBサーバーを同じごちゃ混ぜの空間に置かず、それぞれ独立したセキュリティグループを割り当てる。
3. 「必要最小限」の通信だけを通す
- 「このサーバーとこのサーバーは、何の仕事で会話する必要があるんだっけ？」を問い直し、不要なポート（
22(SSH) や3306(MySQL) など）が一般に公開されていないか点検する。
—
まとめ
ネットワークセグメンテーションやマイクロセグメンテーションは、サイバー空間における「頑丈なドアと電子ロック」です。
最初は難しく感じるかもしれませんが、「この部屋からあの部屋へ行くには、パスポート（許可された通信）が必要だ」というシンプルなルールを積み重ねるだけです。
インフラや開発の現場で設計図を描くときは、ぜひ「もし泥棒が玄関から入ってきたら、次の部屋でどうやって食い止めようか？」という防犯の視点を持ってみてください。あなたの書いたその1行のセキュリティ設定が、会社の未来の重大インシデントを救う強力な盾になりますよ。
それでは、また次回のセキュリティ解説でお会いしましょう！一歩ずつ、確実に安全なシステムを作っていきましょうね。
コメント