こんにちは！インフラやセキュリティの世界へようこそ。
新人のIT担当者や、アプリ開発に情熱を注ぐ一般開発者の皆さん、日々の業務お疲れ様です。「セキュリティ」という言葉を聞くと、何だか難しそうだな、堅苦しいルールがたくさんあるんだろうな……と、少し身構えてしまいますよね。でも、安心してください。一歩ずつ、身近な例から紐解いていけば、決して越えられない壁ではありません。
今回は、現代のITインフラで最も重要視されている「ネットワークセグメンテーション」と「マイクロセグメンテーション」について、一緒に優しく学んでいきましょう！
—
1. 家の防犯に例えて考えてみよう！「境界防御」の限界
皆さんが住んでいる「お家」を思い浮かべてみてください。
昔ながらのセキュリティといえば、頑丈な「玄関の鍵」を閉めておくことでしたよね。泥棒が入ってこないように、家の外周に高いフェンスを立てて、鍵をしっかりかける。この「外と内の境界線だけをガチガチに守る」という考え方を、セキュリティの世界では「境界防御（Perimeter Defense）」と呼びます。
今までの企業ネットワークもまさにこれと同じでした。
「会社のオフィス（社内ネットワーク）の中に入ってしまえば、みんな信用できる仲間だよね！」という前提で、会社の入り口（ファイアウォール）だけを厳重に守っていたのです。
しかし、今の時代はどうでしょう？
リモートワークが普及し、クラウドサービス（AWSやAzureなど）を当たり前のように使うようになりました。もはや「会社の中」という明確な境界線は曖昧になり、さらに、もし悪意ある攻撃者が巧妙な手口（フィッシングメールなど）で、たった一台のPCの「玄関の鍵」を破って社内に入り込んでしまったらどうなるでしょうか？
そうです。家の中に入ってしまえば、リビングも、寝室も、大切な金庫（データベース）の部屋も、すべての部屋の扉が開きっぱなし状態になってしまうのです。これでは泥棒にとって「天国」のような状態ですよね。
—
2. ゼロトラストの時代へ：家の中でも「部屋ごとに鍵」をかける
この「誰も信用しない（ゼロ・トラスト）」という前提に立ち、社内に入られたとしても被害を最小限に食い止めるための技術が、今回テーマにする「セグメンテーション」です。
- ネットワークセグメンテーション：
家の中を「パブリックゾーン」「プライベートゾーン」「サーバー専用ゾーン」のように、大きなフロア単位やネットワーク（VLANやサブネット）単位で壁を作って分けること。
- マイクロセグメンテーション：
さらに細かく、家の中の「一部屋ごと」「なんならタンスの引き出しごと」に鍵をかけ、誰がどの引き出しを開けていいかを厳密に制御すること。
これにより、たとえ攻撃者が一台のPCを乗っ取ったとしても、隣の部屋（重要なデータベース）へ移動することができなくなるため、被害をその場で食い止める（被害の極小化）ことができるのです。
—
3. クラウド時代のワークロード通信制御を覗いてみよう
では、実際のクラウド環境（例えばAWSなどのインフラ）では、このマイクロセグメンテーションをどのように実現しているのでしょうか？
現場のインフラエンジニアやクラウド開発者がよく使う「セキュリティグループ（Security Group）」という機能の設定例を覗いてみましょう。
これは、クラウド上の仮想サーバー（ワークロード）一台一台に持たせる、いわば「デジタルな門番」です。
AWSセキュリティグループの設定例（イメージ）
以下の設定は、「Webサーバーからはデータベースサーバーへアクセスしても良いけれど、一般のインターネットからは直接データベースに触らせない」という鉄則をコード（Terraformという構成管理ツール）で表現したものです。難しく見えますが、日本語のコメントを読んでみてくださいね。
# データベースサーバー用のファイアウォールルール（マイクロセグメンテーションの実装例）
resource "aws_security_group" "db_server_sg" {
name = "db-server-security-group"
description = "データベースへの通信を厳格に制御するセキュリティグループ"
# 【インバウンドルール】外からデータベースへの通信許可設定
ingress {
description = "信頼されたWebサーバーからの通信のみを許可する"
from_port = 3306 # MySQLデータベースの標準ポート
to_port = 3306
protocol = "tcp"
# ポイント：インターネット全体（0.0.0.0/0）ではなく、WebサーバーのセキュリティグループIDを指定して絞り込む！
security_groups = [aws_security_group.web_server_sg.id]
}
# 【アウトバウンドルール】データベースから外への通信（基本は必要最小限に）
egress {
description = "データベースからの不要な外部通信を原則禁止（必要なアップデート用等を除き制限）"
from_port = 0
to_port = 0
protocol = "-1" # すべてのプロトコル
cidr_blocks = ["0.0.0.0/0"] # ※実務ではここもさらに厳格に宛先を絞り込みます
}
}このように、security_groups = [aws_security_group.web_server_sg.id] と記述することで、「Webサーバーという身元が確かな身内からしか、データベースの部屋に入れませんよ」という厳密な制御（マイクロセグメンテーション）を行っています。
—
4. アプリケーション開発者が意識すべきポイント
インフラやネットワークの専門家だけでなく、アプリケーションを開発する私たちも、このセグメンテーションの思想を意識する必要があります。
例えば、Webアプリケーションを作る際に、ユーザーからの入力を受け取る index.php や app.js などのスクリプトから、直接データベースの管理者権限で接続していないでしょうか？
もしアプリケーションの脆弱性を突かれて 命令 を不正に実行されてしまった場合、データベースへのアクセス権限が緩いと、すべてのデータが抜き取られてしまいます。
アプリケーション側でも、以下のような設計を心がけましょう。
1. 最小権限の原則（Principle of Least Privilege）：
データベースに接続する際のユーザーアカウントには、「データの閲覧だけ」「特定のテーブルの更新だけ」といった、必要最小限の権限しか与えないようにする。
2. コンテナやサービスごとのネットワーク分離：
Dockerなどのコンテナ技術を使う場合も、コンテナ同士がどのネットワーク（BridgeやOverlayなど）に所属し、どのポートで通信すべきかを docker-compose.yml 等で明確に定義する。
—
5. まとめ：一歩ずつ、安全なインフラを作ろういこう
今回は、ネットワークセグメンテーションとマイクロセグメンテーションについて、家の中の防犯や具体的なクラウドの設定を交えて解説しました。
最初は「覚えることがたくさんあって大変だな」と感じるかもしれませんが、セキュリティの基本はいつの時代も「信頼しない、確認する、範囲を狭める」の3つだけです。
「このサーバーは本当に他のサーバーと通信する必要があるんだっけ？」
「このアプリケーションの権限、強すぎていないかな？」
日々の開発やインフラ構築の中で、そんな小さな疑問を持てること自体が、最高峰のセキュリティエンジニアへの第一歩です。焦らず、一歩ずつ、安全で堅牢なシステムを一緒に作っていきましょう！
コメント