こんにちは！インフラやセキュリティの世界へようこそ。
新人のIT担当者さんや、開発は好きだけどセキュリティは少し苦手だな……と感じている一般開発者の方に向けて、今日から使える実践的なセキュリティの知見をお届けします。
今回のテーマは「VPC設計におけるゼロトラストネットワークアクセスの実装」、少し噛み砕いて言うと「クラウドの中を細かく区切って、安全をがっちり守るマイクロセグメンテーション」です。
難しい言葉が並んで圧倒されてしまうかもしれませんが、大丈夫です。身近な「家」の防犯に例えながら、一歩ずつ分かりやすく解説していきますね！
—
1. なぜ「境界防御」だけでは家を守れないのか？
これまでのセキュリティは、よく「お城の壁」に例えられてきました。
外からの侵入を防ぐために分厚い外壁を作り、門を一つだけにして、そこで厳重に身元チェックをする。これが従来の「境界防御」という考え方です。
クラウドの世界でも同じで、かつては「会社のオフィスやVPC（仮想プライベートクラウド）という外壁の内側に入ってしまえば、中は安全（信頼できる）」という前提で設計されていました。
家の鍵に例えてみましょう
あなたがマイホームを建てたとします。
- 玄関の鍵をピカピカにして、防犯カメラもバッチリつけました。これなら泥棒は入れませんよね。
- でも、もし「うっかり泥棒が窓から侵入してリビングに入り込んだ」としたらどうでしょう？
- 従来の考え方だと、リビングに入られてしまった瞬間、家の中にあるすべての部屋（寝室、子供部屋、金庫部屋）のドアが開きっぱなし状態になってしまいます。リビングに入った泥棒は、何の苦労もなく金庫部屋まで歩いていき、宝物を持ち出せてしまいますよね。
これが、クラウドのネットワークにおいて「VPCの中に入られたら、中のサーバー同士は自由に通信し放題」という状態の怖さです。現代の攻撃者は、あの手この手で「一度中に入る」ことに成功してしまいます。だからこそ、「中に入られても、被害を最小限に抑える仕組み」が必要になるのです。
—
2. ゼロトラストと「マイクロセグメンテーション」とは？
そこで登場するのが、「ゼロトラスト（何も信用するな、すべて検証せよ）」という考え方です。
「一度VPCの中に入ったから安全」とは絶対に思わず、サーバーとサーバーが通信する時ですら「本当に君、通信していい相手かい？」と毎回疑ってチェックする仕組みを作ります。
このゼロトラストの思想をクラウドのネットワークで具現化する技術が、「マイクロセグメンテーション（超・細分化）」です。
先ほどの家の例えに戻りましょう。
マイクロセグメンテーションを取り入れた家は、こうなります。
- 玄関の鍵だけでなく、「リビングから廊下に出るドア」「廊下から寝室に入るドア」「書斎に入るドア」すべてに頑丈な鍵と指紋認証をつけます。
- たとえリビングが破られても、泥棒は廊下ですら先に進めません。
これをクラウド（AWSやGCP、Azureなど）のVPC環境で実現するのが、サブネットの分割と、ファイアウォール（セキュリティグループ）による通信の厳格なコントロールです。
—
3. 実践！VPC内を細かく区切る設計と設定
それでは、具体的にどうやってクラウドのネットワークを区切り、安全な環境を作ればいいのか見ていきましょう。
今回は、よくある「Webサーバー」「AP（アプリケーション）サーバー」「DB（データベース）サーバー」の3階層構造を例にします。
ネットワークの部屋割り（サブネット設計）
VPCという大きな敷地を、以下のように用途別で完全に部屋を分けます。
1. パブリックサブネット（玄関）： インターネットからユーザーが最初にアクセスしてくる場所（ロードバランサーなど）
2. プライベートサブネット（居住スペース）： WebサーバーやAPサーバーなど、内部で動くプログラムを置く場所
3. データベスサブネット（金庫部屋）： 大切な顧客データが入ったデータベース専用の場所（インターネットからは絶対に直接アクセスさせない）
設定例：ファイアウォール（セキュリティグループ）で通信を最小限にする
クラウドでは、サーバーごとに「セキュリティグループ」という名の「小さな番人」を置くことができます。この番人に「最小権限の原則（必要最低限の通信だけ許可し、他はすべて拒否する）」を設定しましょう。
以下は、AWSのTerraform（インフラをコードで管理するツール）をイメージした設定サンプルです。日本語のコメントを読んで、どのように通信を絞っているか確認してみてください。
# ==========================================
# 1. データベース（金庫部屋）用のセキュリティグループ
# ==========================================
resource "aws_security_group" "db_sg" {
name ="database-security-group"
description ="データベースを守る最後の砦の番人"
vpc_id = aws_vpc.main.id
# 許可ルール：APサーバーからの通信だけを「データベースのポート(3306)」宛てに許可する
ingress {
description ="APサーバーからの安全な問い合わせのみ許可"
from_port = 3306
to_port = 3306
protocol ="tcp"
# ここがポイント！インターネットや他のサーバーからは一切アクセスさせず、
# APサーバーのセキュリティグループからの通信だけを許可します。
security_groups = [aws_security_group.app_sg.id]
}
# 拒否ルール（明示的な記載がなくても、ゼロトラストでは許可されていない通信はすべて自動でブロックされます）
egress {
description ="データベースからの外への通信は原則不要なので絞る"
from_port = 0
to_port = 0
protocol ="-1"
cidr_blocks = ["0.0.0.0/0"] # ※実運用ではパッチ適用等のためアウトバウンドも絞るのが理想です
}
}この設定の美しいところは、「もしWebサーバーやAPサーバーがハッカーに乗っ取られたとしても、データベースの部屋の鍵はAPサーバーからの身分証（セキュリティグループ）がないと開かないため、最悪のデータ流出を防げる」という点です。これがマイクロセグメンテーションの真骨頂です。
—
4. 日々の開発・運用で意識してほしいこと
インフラの設計者がこうしたゼロトラストなネットワークを用意してくれても、アプリケーションを書く開発者側が油断していると、思わぬ穴が空いてしまいます。
最後に、現場で開発する皆さんに心がけてほしいポイントをいくつかお伝えしますね。
- 「とりあえず全部許可（
0.0.0.0/0）」のセキュリティグループを作らない - テスト中だからといって、何でも通るガバガバな鍵をつけっぱなしにしない。本当に必要な通信先（IPや他のセキュリティグループ）だけをピンポイントで指定する癖をつけましょう。
- サーバー間の通信でも暗号化（HTTPS/TLS）を怠らない
- VPCの中だからといって、サーバー間の会話を丸見え（平文）にしないこと。万が一、内部の通信を盗聴（パケットキャプチャ）されたときの保険として、内部通信でもTLSを使う意識を持ちましょう。
- 「動けばいいや」ではなく「なぜこの通信が必要なのか」を言語化する
- アプリの仕様書やプルリクエストを書くときに、「この機能のために、どのサーバーからどのサーバーへ、どのポートで通信が通るべきか」をチームで共有できるようにしておくと、セキュリティレビューもスムーズになります。
—
まとめ
今回は、VPC設計におけるゼロトラストネットワークアクセスと、マイクロセグメンテーションについてお話ししました。
- 境界防御だけでは、一度侵入されたときにすべてを失うリスクがある
- 家の中を細かく区切り（マイクロセグメンテーション）、部屋ごとに頑丈な鍵をかける
- 通信は「最小権限の原則」に基づき、必要なもの以外はすべて遮断する
最初は「設定項目が増えて面倒だな」と感じるかもしれませんが、この泥臭い積み重ねが、あなたや会社のサービス、そして大切なユーザーのデータを守る最強の盾になります。
一歩ずつ、安全で堅牢なシステム作りを一緒に楽しんでいきましょう！それではまた次回の記事でお会いしましょう。
コメント