マイクロセグメンテーションとは？VLANとの違いと導入手順を図解
VLANで分けているのに、1台に侵入されると社内のサーバーへ次々に広がるのではと不安に感じていませんか。
マイクロセグメンテーションとは、サーバーなどのワークロードごとに通信の許可を決め、侵入後の横移動を止める仕組みです。
この記事では、VLANとの違い、ラベルで書く許可リスト、実現方式、導入手順と失敗しやすい点を、例示のIPとポート番号で図解します。
この記事は以下のような人におすすめ！
- VLANとの違いを説明できるようにしたい人
- VLANで分けているのに侵入後の広がりが不安な人
- 導入の進め方と失敗しやすい点を知りたい人
マイクロセグメンテーションとは
1-1. ワークロードごとに通信の許可を決める仕組み
マイクロセグメンテーションは、ネットワークを細かく分ける考え方を、サーバー1台やアプリケーション1つの単位まで進めたものです。
ここでいうワークロードとは、仮想マシン、コンテナ、物理サーバーなど、アプリケーションが動く単位のことです。
従来の境界型の守り方では、インターネットと社内の境目にファイアウォールを置き、内側の通信は基本的に通していました。
図の左のように、境界の内側が1つの広いネットワークだと、Webサーバーが乗っ取られた時点で、同じ内側のファイルサーバーやデータベースにも届いてしまいます。
図の右のように、マイクロセグメンテーションでは、ワークロードごとに「どこから、どのポートへの通信なら受け付けるか」を決めます。
例では、Webサーバーからデータベースへはデータベースの待ち受けポートtcp/1433だけを許可し、ファイルサーバーへのtcp/445は拒否しています。
図のIPアドレスは、RFC 5737で説明用に予約された例示のアドレスです。
攻撃手法を整理したMITREの知識ベースでも、緩和策M1030「ネットワークセグメンテーション」で、ワークロード単位の分割にマイクロセグメンテーションを使い、横移動を防ぐよう挙げています（参考1）。
1-2. ゼロトラストの中での位置付け
マイクロセグメンテーションは、ゼロトラストを実現する手段の1つとしてよく語られます。
NISTのSP 800-207は、ゼロトラストを、物理的な場所やネットワーク上の位置だけを理由に暗黙の信頼を与えない考え方だと説明しています。
同じ文書は、守る対象をネットワークのセグメントではなく、資産やサービスなどの資源そのものに置くとしています（参考2）。
社内ネットワークにいるから通してよい、とはしないという点で、ワークロードごとに通信を決めるマイクロセグメンテーションと方向が一致します。
同じ文書の要旨は、ゼロトラストが求められる背景として、リモートで働く利用者、私物端末の業務利用（BYOD）、会社のネットワークの外にあるクラウドの資産を挙げています。
Microsoftのゼロトラストの展開ガイドでは、まず機能やセキュリティの要件で大きく分けるマクロセグメンテーションを固め、その上でより細かいマイクロセグメンテーションへ進む順序をすすめています。
同じガイドは、IPアドレスに頼る従来の分け方よりも、IDに基づく分け方を採るよう挙げています（参考3）。
つまり、いきなり全サーバーを1台ずつ囲むのではなく、本番と開発、利用者の端末とサーバーといった大きな区切りを先に作り、その中を細かくしていくのが現実的です。
ゼロトラスト全体の考え方は、記事の最後で紹介するゼロトラストの解説記事で詳しく扱っています。
VLAN・サブネットによる分割との違い
2-1. 分ける単位と判定に使う値の違い
VLANやサブネットによる分割も、ネットワークを分けて通信の範囲をしぼる方法です。
違いが出るのは、どの単位で分け、何の値で通すかどうかを決めるかです。
VLANは、スイッチの中でネットワークを論理的に分け、VLAN 10とVLAN 20のように番号の違うネットワーク同士は、ルーターなどを通らないと通信できないようにします。
サブネットは、192.0.2.0/25と192.0.2.128/25のようにIPアドレスの範囲で分け、その間の通信をルーターやファイアウォールのルールで制御します。
どちらも、所属するネットワークを決めるのはIPアドレスやスイッチのポートの設定なので、サーバーの役割が変わっても、設定を変えない限り同じ扱いのままです。
どちらも、判定に使うのはVLAN番号やIPアドレスの範囲で、分ける単位はネットワークそのものです。
マイクロセグメンテーションでは、ワークロード1つずつに対して、役割を表すラベルやグループとポート番号でルールを書きます。
MITREのM1030でも、物理的な境界、VLANによる論理的な分離、ファイアウォールなどのアクセス制御を組み合わせることが効果的なセグメンテーションだとされ、マイクロセグメンテーションはその中のワークロード単位の手段として並んでいます（参考1）。
VLANの仕組みやタグの付き方は、記事の最後で紹介するVLANの解説記事で確かめられます。
2-2. 同じセグメントの中の通信を止められるか
実務で最も大きな違いになるのが、同じセグメントの中にある機器同士の通信です。
この、内部の機器同士の横方向の通信は、東西（イーストウエスト）の通信と呼ばれます。
図のように、Webサーバー192.0.2.11と192.0.2.12が同じVLAN 10にあると、2台の間の通信はスイッチの中で届き、セグメントの間に置いたファイアウォールを通りません。
そのため、片方が乗っ取られると、もう片方のファイル共有（tcp/445）やリモートデスクトップ（tcp/3389）へ試しに接続できてしまいます。
マイクロセグメンテーションでは、宛先のワークロードごとにルールを持つため、同じVLANの中でも「Webサーバー同士のtcp/445は拒否」と決められます。
MITREのM1030は、外部と内部の南北の通信だけでなく、内部同士の東西の通信もファイアウォールで制限するよう挙げています（参考1）。
ただし、VLANが不要になるわけではありません。
VLANやサブネットで大きく分けたうえで、その中をマイクロセグメンテーションで細かく制御すると、ルールの数を抑えながら東西の通信も止められます。
セグメンテーション全体の分け方は、記事の最後で紹介するネットワークセグメンテーションの解説記事で扱っています。
- VLAN・サブネットはネットワーク単位で分け、VLAN番号やIPの範囲で判定する
- マイクロセグメンテーションはワークロード単位で、役割のラベルとポートで判定する
- 同じVLANの中の東西の通信を止められるのは、マイクロセグメンテーションの側
ラベル・タグで書く許可リスト型のポリシー
3-1. IPアドレスではなく役割のグループで書く
マイクロセグメンテーションのルールは、IPアドレスではなく、Web、アプリ、データベースといった役割のグループで書くのが基本です。
サーバーを増やしたり作り直したりするとIPアドレスは変わるため、IPでルールを書くと、そのたびにルールの書き換えが必要になるからです。
Azureのアプリケーションセキュリティグループ（ASG）は、この考え方をクラウドで実現する機能です。
仮想マシンのネットワークインターフェイスをAsgWeb、AsgLogic、AsgDbといったグループに入れ、ルールの送信元や宛先にグループ名を書きます。
Microsoftの説明の例では、優先度100でインターネットからAsgWebへのtcp/80を許可し、優先度110でAsgLogicからAsgDbへのtcp/1433を許可しています。
さらに優先度120で、すべての送信元からAsgDbへの1433を拒否しています。
ルールは優先度の数字が小さい順に処理されるため、AsgLogicからの通信は110で許可され、それ以外の送信元からの通信は120で止まります。
この拒否の行が要るのは、同じ仮想ネットワーク内の通信をすべて許可するAllowVNetInBoundという既定のルールがあるためです。
つまり、何も書かなければ東西の通信は通るので、止めたい通信は明示して拒否する必要があります。
なお、ASGを送信元と宛先の両方に指定するルールでは、両方のグループのネットワークインターフェイスが同じ仮想ネットワークにある必要があります。
同じ説明は、個々のIPアドレスやその範囲よりも、サービスタグやASGでルールを作るようすすめています（参考4）。
3-2. 既定で拒否し、必要な通信だけを許可する
ルールの基本形は、必要な通信だけを並べ、それ以外は拒否する許可リスト（ホワイトリスト）型です。
反対に、危ない通信だけを並べて止める拒否リスト型では、想定していない通信を見逃しやすくなります。
なお、1-1や5-1の図はWebとデータベースの2層構成の例で、Webからデータベースのtcp/1433を許可していました。
ここではアプリ層を挟む3層構成の例で、どの通信を許可するかは、このように構成によって決まります。
図は、ロードバランサー、Web、アプリ、データベースの3層構成で、通信を許可リストにした例です。
Webサーバーはアプリのtcp/8080にだけ、アプリはデータベースのtcp/5432にだけ接続でき、管理用の端末からは各サーバーのtcp/22で保守します。
この表にない通信は最後の行で拒否されるため、Webサーバーからデータベースへ直接つなごうとしても届きません。
MITREのM1030も、ネットワーク機器のアクセス制御リストで「既定で拒否」の方針を強制するよう挙げています（参考1）。
Microsoftの展開ガイドでも、すべての層で既定で拒否し、ポリシーで明示的に許可したときだけアクセスを認める原則を示しています（参考3）。
ラベルは、役割（role）のほかに、環境（本番・開発）、アプリケーション名、場所などを組み合わせて付けることが多く、「本番のapp同士だけ」のように条件を重ねられます。
たとえば、env=prod、app=payroll、role=dbというラベルを付けた給与システムのデータベースには、env=prodかつapp=payrollかつrole=appのワークロードからのtcp/5432だけを許可する、といった書き方です。
こうしておけば、開発環境（env=dev）のアプリが誤って本番のデータベースへつなごうとしても、ラベルが合わないため拒否されます。
ただし、ラベルの付け間違いはそのまま通信の許可の間違いになるため、だれがラベルを付け替えられるかも管理の対象です。
マイクロセグメンテーションの実現方式
4-1. エージェント型とネットワーク型
マイクロセグメンテーションを実際に動かす方式は、大きく分けて、通信を判定する場所の違いで整理できます。
エージェント型は、各サーバーにエージェントと呼ばれるソフトウェアを入れ、管理サーバーで決めた方針を、OSに備わったファイアウォールの設定として配る方式です。
サーバーの中で判定するため、物理サーバー、仮想マシン、別々のクラウドが混ざった環境でも、同じ考え方のルールを適用しやすい点が特長です。
一方で、エージェントを入れられない機器や、OSの管理者権限を奪われたときの扱いは、製品ごとに確かめる必要があります。
ネットワーク型は、仮想化基盤の仮想スイッチ、ソフトウェアで経路や制御を決めるSDN（Software-Defined Networking）、内部向けのファイアウォールなど、ネットワーク側で判定する方式です。
サーバーにソフトを入れずに済む一方、判定できるのは、その機器を通る通信に限られます。
たとえば、同じ物理サーバーの上で動く2台の仮想マシンの通信は外のファイアウォールを通らないため、仮想スイッチなど基盤の内側で判定する仕組みが必要です。
MITREのM1030はSDNのツールでワークロード単位の分割を実現するよう挙げ、OSのファイアウォールで特定の機器との通信だけを許す例も示しています（参考1）。
Microsoftのガイドも、SDNとネットワークアクセス制御（NAC）でポリシーを動的に適用するよう挙げています（参考3）。
サーバー側で動くセキュリティ対策の全体像は、記事の最後で紹介するCWPPの解説記事が参考になります。
4-2. クラウドのセキュリティグループで実現する
クラウドでは、標準のセキュリティグループで、ワークロード単位の制御を始められます。
AWSのセキュリティグループは、関連付けたEC2インスタンスなどの仮想的なファイアウォールとして働き、ルールで許可した通信だけがその資源に届きます。
受信ルールには送信元、ポートの範囲、プロトコルを、送信ルールには宛先、ポートの範囲、プロトコルを指定します。
AWSの説明の例では、同じグループに属するインスタンス同士の通信や、別のグループのインスタンスからのSSHを許可するルールが示されています。
図のように、送信元にsg-webといったグループを指定すれば、IPアドレスを書かずに「Webの役割からだけtcp/8080を許可」と表せます。
セキュリティグループはステートフルで、許可した通信への応答は、受信ルールの内容に関係なく戻ってきます。
また、AmazonのDNS、DHCP、インスタンスのメタデータ、Amazon Time Sync Serviceなどへの通信は、セキュリティグループでは絞り込まれません。
AWSは、tcp/22やtcp/3389を0.0.0.0/0に開けず特定の範囲だけに許可すること、広いポート範囲を開けないこと、似た役割の資源ごとにグループを分けて数を必要最小限にすることをすすめています（参考5）。
同じ説明は、セキュリティグループと似たルールのネットワークACLをサブネットに設けて、守りを重ねる方法も挙げています。
Azureでは、3-1で見たネットワークセキュリティグループとASGの組み合わせが同じ役割を担います。
横移動（ラテラルムーブメント）を止める仕組み
5-1. 侵入後の横移動はどこで止まるか
横移動（ラテラルムーブメント）とは、最初に侵入した1台を足がかりに、同じネットワークの別の機器へ広がっていく攻撃者の動きです。
図の例では、攻撃者がWebサーバー192.0.2.11を乗っ取り、ファイル共有のtcp/445、リモートデスクトップのtcp/3389、Windowsのリモート管理のtcp/5985を使って、ほかのサーバーへ広がろうとしています。
マイクロセグメンテーションで「Webからはデータベースのtcp/1433だけ」と決めていれば、それ以外の3つの接続は宛先の手前で拒否されます。
MITREのM1030は、リモートデスクトップについて、ネットワーク内のセキュリティゾーンの間でRDPの通信を止めるファイアウォールのルールを有効にするよう挙げています。
また、ネットワーク上のサービスを探す偵察や、リモートサービスの脆弱性を突く攻撃への緩和策としても、重要なサーバーへの経路をしぼる分割を挙げています。
同じ緩和策は、Windowsのリモート管理についても、OSのファイアウォールで特定の機器との通信だけを許すよう挙げています（参考1）。
ただし、許可した1本の通信（図ではtcp/1433）は、攻撃者にとっても通り道のままです。
データベース側のアカウントの権限をしぼる、Webサーバー用のアカウントで管理操作をさせないといった、通信の制御以外の対策も組み合わせる必要があります。
Microsoftのガイドは、侵害を前提に、ネットワーク、利用者、端末、アプリケーションの単位でアクセスを分け、侵害の影響範囲を小さくするよう求めています（参考3）。
5-2. 拒否の記録と検証で効果を確かめる
ルールを入れたら、意図どおりに止まっているかを記録で確かめます。
製品やクラウドの機能によっては、ワークロード間の通信について、送信元、宛先、ポート、許可か拒否かに加えて、どのルールに当たったかまで記録できます。
項目名や形式は製品によって違い、図の「ルール」の列のように当たったルール名を残さない製品やサービスもあるため、図は考え方を示す例です。
ふだん通信しないWebサーバーからファイルサーバーへのtcp/445の拒否が続くなら、乗っ取りや不正なスキャンを疑う手がかりになります。
反対に、業務で使う通信が拒否されていれば、ルールの許可し忘れです。
拒否が急に増えたときは、直前にルールやラベルを変えていないか、新しいサーバーやアプリが追加されていないかを、変更の記録と突き合わせて確かめます。
Microsoftのガイドでは、仮想ネットワークのフローログを分析するTraffic Analyticsで、通信が意図したセグメントの間だけで流れているかを確かめ、想定外の東西の通信から横移動や設定ミスを見つける使い方を挙げています（参考3）。
MITREのM1030も、ファイアウォールのルールやセグメンテーションの方針を定期的に見直し、ネットワークの流れを監視し、定期的な侵入テストで分割が効いているかを試すよう挙げています（参考1）。
ルールを作ったら終わりではなく、記録の確認とテストを続けることが、マイクロセグメンテーションを保つ条件です。
導入手順と失敗しやすい点
6-1. 可視化→ポリシー作成→監視モード→適用の4段階
マイクロセグメンテーションの導入は、いきなり拒否のルールを入れるのではなく、段階を踏んで進めるのが一般的です。
1つ目は通信の可視化で、フローログや製品の観測機能を使い、どのワークロードが、どこへ、どのポートでつないでいるかの一覧を作ります。
一覧には、送信元と宛先の役割、ポートとプロトコル、通信の回数や時間帯、その通信を使う業務と担当者を並べておくと、後で許可するかどうかを判断しやすくなります。
月末の締め処理や週1回のバックアップのように、短い期間では現れない通信もあるため、観測の期間は業務の周期に合わせて決めます。
2つ目はポリシー作成で、ワークロードに役割のラベルを付け、一覧の中から業務に必要な通信だけを許可リストにします。
3つ目は監視モードで、ルールを実際には適用せず、「このルールなら拒否されていた通信」を記録して、許可し忘れがないかを確かめます。
この動作の呼び名や有無は製品によって違うため、使う製品の説明書で確かめてください。
4つ目が適用で、影響の小さいアプリケーションから順に拒否を有効にし、問題が出たときにルールを戻す手順と連絡先を先に決めておきます。
Microsoftのガイドは、ネットワークセキュリティグループなどの分割の設定を、コードで管理するInfrastructure as Codeの仕組みで自動的に展開する方法も挙げています（参考3）。
ルールをコードで管理すると、だれがいつ何を変えたかを追いやすく、間違えたときに前の版へ戻しやすくなります。
6-2. 失敗しやすい点：許可し忘れる通信
導入で最も多いつまずきは、業務アプリの通信以外にある、裏で動く通信の許可し忘れです。
名前解決のDNS（udp/53など）や時刻合わせのNTP（udp/123）を止めると、アプリケーションは動いていても、接続先が見つからない、認証が時刻のずれで失敗するといった症状が出ます。
Active Directoryを使う環境では、Kerberos（tcp/88など）やLDAP（tcp/389など）を許可し忘れると、サーバーへのログインやサービスの起動に失敗することがあります。
監視サーバーからの死活監視やバックアップサーバーからの夜間の取得は、観測の期間に現れず、適用後に初めて止まることがよくあります。
クラウドでは、AWSのセキュリティグループのように、AmazonのDNSやDHCPなど一部の通信がもともとルールの対象外になっている場合もあります（参考5）。
一方で、Azureの既定のAllowVNetInBoundのように、何もしなければ仮想ネットワーク内の通信をすべて通すルールもあるため、使うサービスごとに既定の動作を確かめておきましょう（参考4）。
もう1つの失敗は、例外を重ねて許可を広げすぎることで、「とりあえず全ポート許可」の行が残ると、マイクロセグメンテーションの効果はほとんどなくなります。
AWSも、広いポート範囲を開けず、各ポートは必要な送信元と宛先だけに絞るようすすめています。
見落としやすいのが、ワークロードから外へ出ていく通信の制御です。
AWSの説明の例でも、セキュリティグループの送信ルールは既定のまま、すべての通信を許可しています。
MITREのM1030は、ネットワークから出る通信も必要なポートだけに限るよう挙げているため、乗っ取られたサーバーが外部へデータを送り出す経路を減らす意味で、外向きのルールも見直しておきましょう（参考1）。
例外を足すときは、期限と理由を書き残し、見直しのときに不要な行を消せるようにしておくと安全です。
- 拒否を有効にする前に、監視モードや記録で許可し忘れを探す
- DNS、NTP、認証、監視、バックアップ、更新の通信を一覧に入れる
- 職場のネットワークのルールは自分で変えず、担当部署の手順に沿って変更する
マイクロセグメンテーションのよくある質問
7-1. 導入前によく出る疑問
Q1. マイクロセグメンテーションを入れたら、VLANは要らなくなりますか？
いいえ、VLANやサブネットによる大きな区切りは残し、その中をマイクロセグメンテーションで細かく制御する組み合わせが一般的です。
Microsoftのガイドも、マクロセグメンテーションを土台にしてマイクロセグメンテーションへ進む順序を示しています（参考3）。
Q2. ZTNAやファイアウォールとの違いは何ですか？
境界のファイアウォールは外と内の間の通信、ZTNAは利用者から業務アプリへの接続、マイクロセグメンテーションはワークロード同士の通信を主に守ります。
図のように守る向きが違うため、どれか1つで置き換えるのではなく、組み合わせて使います。
Q3. 小さな会社や少ないサーバーでも意味がありますか？
サーバーが数台でも、ファイルサーバーや経理のサーバーのように止められると困る機器があれば、そこへの通信をしぼる意味はあります。
まずは重要な数台だけを対象にし、OSのファイアウォールやクラウドのセキュリティグループといった手元の機能から始めると、無理なく進められます。
Q4. OSのファイアウォールだけでも実現できますか？
台数が少なければ、各サーバーのOSのファイアウォールで受け付ける送信元とポートをしぼることで、近い効果は得られます。
ただし、台数が増えるとルールの配布や記録の集約が手作業では追いつかなくなるため、集中管理の仕組みを検討する目安になります。
クラウドであれば、AWSのセキュリティグループのように追加料金なしで使える標準機能から試すこともできます（参考5）。
Q5. 導入するとき、最初に何をすればよいですか？
最初の一歩は、守りたいサーバーを1つ決め、そのサーバーへの通信を記録で洗い出すことです。
だれが、どのポートでつないでいるかが分かれば、許可リストの下書きを作れます。
ここまで読んでくださって、ありがとうございます。
マイクロセグメンテーションは、ワークロードごとに必要な通信だけを許可し、侵入された1台からの横移動を止める仕組みです。
VLANやサブネットで大きく分けたうえで、役割のラベルで許可リストを書き、可視化、監視モード、適用の順に進め、記録の確認を続けましょう。
今日できることを1つ選ぶなら、手元のクラウドやサーバーで、tcp/22やtcp/3389が0.0.0.0/0から許可されたままになっていないかを確かめてみてください。
職場の環境で気になる点を見つけたら、自分で設定を変えず、担当部署に相談しましょう。
関連する仕組みを詳しく知りたい方は、次の記事もどうぞ。
