こんにちは！インフラやセキュリティの世界へようこそ。
新人のIT担当者さんや、これから開発の現場でセキュリティを意識し始める方にとって、サーバーやクラウドの用語はなんだか呪文のように聞こえて、少し身構えてしまいますよね。
でも、大丈夫です！難しく見える技術も、私たちが普段暮らしている「お家の防犯」に置き換えてみると、スッと頭に入ってくるものなんです。
今回は、現代のクラウドインフラで必須となる「マイクロセグメンテーションによるコンテナ間通信の制御」について、一緒に優しく紐解いていきましょう！
—
1. コンテナの世界は「ワンルームのシェアハウス」？
皆さんは、最近のインフラの主役である「Kubernetes（クーベネティクス）」や「コンテナ」という言葉を聞いたことがありますでしょうか？
コンテナというのは、アプリケーションを動かすための「軽量な箱」のようなものです。一つの大きなサーバー（クラウド環境）の中に、たくさんのコンテナという小部屋をポコポコと作って、そこでWebサイトの仕組みやデータベースを動かしています。
ここで、最初のセキュリティの落とし穴があります。
初期設定のままのコンテナたちは、まるで「鍵のついていないワンルームのシェアハウス」のような状態なんです。
- リビング（Webサーバー）
- キッチン（顧客データ管理システム）
- 寝室（社内用管理ツール）
これらすべての部屋のドアが全開で、誰でも自由に行き来できてしまっているとしたら……ちょっと怖くないですか？
泥棒（攻撃者）の手口：侵入されたあとの「横移動（ラテラルムーブメント）」
もし、ハッカーがセキュリティの甘い「リビング（公開されているWebサーバーの脆弱性）」を突破してシェアハウスに侵入したとします。
もし部屋と部屋の間に鍵がなかったらどうなるでしょう？ ハッカーはそのまま「キッチン（顧客データ）」や「寝室（管理ツール）」へスタスタと歩いていき、大切な情報をすべて盗み出してしまいます。セキュリティの世界では、この侵入した後に内部を歩き回る攻撃を「ラテラルムーブメント（横移動）」と呼びます。
だからこそ、「どの部屋とどの部屋の行き来を許可するか」をしっかりコントロールする必要があるのです。これが今回のテーマである「マイクロセグメンテーション（細かい区画整理）」の考え方になります。
—
2. Kubernetes Network Policyで「部屋ごとの合鍵とオートロック」を作る
Kubernetesの世界では、この区画整理を行うために Network Policy（ネットワークポリシー） という機能を使えます。
これは、コンテナ同士の通信に対して「誰から誰への通信を許可するか」をホワイトリスト方式（許可されたもの以外はすべて禁止！）で設定する仕組みです。
例えば、「データベース用のコンテナには、Webサーバーからの通信だけを通し、それ以外の見知らぬコンテナからの通信はすべてシャットアウトする」という設定を書いてみましょう。
実践：Network Policyの設定ファイルを見てみましょう
実際の現場で使われる設定ファイルのサンプルです。難しそうに見えますが、日本語のコメントを読みながら一緒に見ていきましょう。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: db-security-policy # このルールの名前です
namespace: default # 対象となるお部屋のエリア（ネームスペース）
spec:
podSelector:
matchLabels:
role: database # 「role: database」というラベルがついたコンテナを守ります
policyTypes:
- Ingress # 外から中に入ってくる通信を制限しますよ、という意味です
ingress:
- from:
- podSelector:
matchLabels:
role: web # 「role: web」というラベルを持ったコンテナからの通信だけは通します！
ports:
- protocol: TCP
port: 3306 # データベースの扉（MySQLのポート）だけを開けますこの設定を適用すると、「Webサーバー」以外のコンテナからは、データベースへの扉がピシャリと閉ざされます。万が一、別の場所からハッカーに侵入されても、データベースという金庫まではたどり着けないというわけですね。一歩ずつ、お家の防犯がしっかりしてきました！
—
3. サービスメッシュ（Istio）で「通信の盗聴とすり替わり」を防ぐ
さて、お部屋ごとの行き来（ネットワークポリシー）を制限できるようになりましたが、プロの泥棒はさらに上をいきます。
廊下（コンテナ間の通信経路）にこっそり盗聴器を仕掛けたり、通信の中身をのぞき見したりするかもしれないのです。クラウドの内部ネットワークだからといって、流れているデータをそのまま（暗号化せずに）やり取りしていると、途中でデータをパッと盗まれてしまいます。
ここで登場するのが、サービスメッシュ（Istioなど）という技術と、mTLS（相互TLS認証）という仕組みです。
mTLSを身近な例でたとえると？
mTLSは、通信するお互い同士が「本物のパスポート（証明書）」を持っているかを確認し合い、さらに会話の内容をすべて強力な暗号でグルグル巻きにして話す仕組みです。
スパイ映画で、暗号化された無線でお互いの身元を確認しながら会話しているシーンを見たことはありませんか？ あれと同じことを、コンテナたちが自動で行ってくれます。
1. 身元確認（認証）：「本当にWebサーバーさんですか？証明書を見せてください」「はい、こちらです。データベースさんですね？」
2. 暗号化（機密性）：お互いが本物だと確認できたら、そこから先の会話はすべて誰にも解読できない暗号で話す。
これによって、仮にネットワークの廊下に盗聴器を仕掛けられても、中身は完全にチンプンカンプンな暗号なので、情報が漏れる心配がなくなるんです。
実践：IstioでmTLSを強制する設定
Istioを使うと、コードを書き換えなくても、設定一つでコンテナ間の通信をすべてmTLS（暗号化された安全な通信）に強制することができます。
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: default # 対象のエリア
spec:
mtls:
mode: STRICT # 「STRICT（厳格）」に設定することで、暗号化されていない通信を一切拒否します！たったこれだけの記述で、このエリアを通過するすべてのコンテナ間通信は、自動的に強力な暗号化のベールに包まれます。開発者がアプリのコード内で特別な暗号化プログラムを書く必要がないため、ヒューマンエラーを防ぐ意味でも非常に強力なアプローチです。
—
4. まとめ：焦らず、一歩ずつ堅牢なインフラへ
今回は、コンテナ環境におけるセキュリティの基本として、以下の2つを学びました。
1. Kubernetes Network Policyによる通信の最小化（部屋ごとの鍵とオートロック）
2. サービスメッシュ（Istio）によるmTLSの強制（廊下での盗聴を防ぐ、身元確認と暗号化の会話）
セキュリティの世界は広大で、最初は覚えることが多くて圧倒されてしまうかもしれません。でも、「誰がどこに通っていいんだっけ？」「このデータは裸のまま外に出ていないかな？」という視点（お家の防犯の感覚）を少しずつ持てるようになるだけで、あなたの作るシステムは劇的に安全になります。
焦らず、ご自身のペースで一歩ずつ、一緒に学びを深めていきましょう！次のインフラ構築でも、ぜひこの「マイクロセグメンテーション」の視点を思い出してみてくださいね。
コメント