マイクロセグメンテーションとネットワークセグメンテーション: すべてのセキュリティチームがいずれ直面する問い

フラットなネットワークはもはや防御できません。どの企業もいずれ同じ転換点に到達します。セグメンテーションは必要だが、どの種類を選ぶべきか、という問いです。この問いは多くの場合、ネットワークセグメンテーションかマイクロセグメンテーションかの二者択一として提示されます。しかし実際には、環境が中程度でも複雑になった時点で、その捉え方は成り立たなくなります。今日のほとんどの企業は、次のような環境にまたがって運用しています。

• 複数のファイアウォールベンダー
• ハイブリッドなデータセンターおよびクラウド環境
• AWS、Azure、Kubernetes におけるワークロードレベルの制御
• 台頭する Zero Trust アクセスレイヤー

このような環境では、セグメンテーションは単一の決定ではありません。それは複数の適用レイヤーの積み重ねです。そこから真の課題が生まれます。すなわち、セグメンテーションの種類を選ぶことではなく、ポリシーの意図をそれを適用するすべてのレイヤーにわたって統制することです。

ネットワークセグメンテーションとは

ネットワークセグメンテーションは、次の手段を用いて環境を大きなセキュリティゾーンに分割します。

• VLAN
• サブネット
• ルーター
• アクセス制御リスト (ACL)
• ファイアウォール

次のようなよく知られた構成を思い浮かべてください。

• DMZ
• 内部ネットワーク
• ゲストネットワーク
• PCI ゾーン
• OT/IT の分離

主な目的

南北方向のトラフィック (ゾーンに出入りするトラフィック) を制御し、全体の攻撃対象領域を縮小すること。

強み

• 成熟しており、広く理解されている
• コンプライアンスフレームワーク (PCI、HIPAA など) に有効
• 小規模では運用負荷が低い
• 明確なセキュリティ境界を確立できる

限界が生じる場面

従来のネットワークセグメンテーションは本質的に粒度が粗いものです。トラフィックがいったんゾーン内に入ると、次のような状況になります。

• 移動が制限されないことが多い
• 東西方向の可視性が限定される
• 横方向の移動が容易になる

さらに現実の複雑さが加わります。

• Check Point のルールは Palo Alto のルールとは異なる
• クラウドのセキュリティグループはファイアウォールとは異なる挙動をする
• ポリシーはプラットフォームごとに独立して変化していく

統合レイヤーがなければ、ポリシードリフトはただちに始まります。

マイクロセグメンテーションとは

マイクロセグメンテーションは、ワークロード、アプリケーション、またはエンドポイントのレベルでセキュリティポリシーを適用します。ゾーン間のトラフィックを制御するのではなく、ゾーン内のトラフィックを制御します。

適用の方法

• ホストベースのエージェント (例: Illumio)
• ハイパーバイザーレベルの制御 (例: VMware NSX)
• クラウドネイティブな制御 (AWS Security Groups、Kubernetes Network Policies)

重要な区別: クラウドネイティブな制御はワークロードレベルの適用を提供しますが、完全なマイクロセグメンテーションプラットフォームではありません。

主な目的

東西方向のトラフィックを制御し、ワークロード間で最小権限アクセスを強制すること。

強み

• 横方向の移動を阻止する (ランサムウェアの封じ込めに不可欠)
• Zero Trust セグメンテーションを実現する
• セグメンテーションポリシーは IP アドレスではなくワークロードに追従する
• 動的なクラウド環境に合わせて拡張できる

難しくなる場面

マイクロセグメンテーションは次の要素をもたらします。

• 高い複雑性
• 依存関係マッピングの困難さ
• 検証を行わない場合にアプリケーションを停止させるリスク
• 複数のプラットフォームにまたがる分散した適用

プラットフォームごとにポリシーのモデル化の方法は異なります。そこから真の問題が始まります。すなわち、意図したポリシーと実際に適用されたポリシーとの乖離が急速に広がるのです。

マイクロセグメンテーションとネットワークセグメンテーションの主な違い

カテゴリー

ネットワークセグメンテーション

マイクロセグメンテーション

適用範囲

ゾーン（サブネット、VLAN）

ワークロード、アプリケーション、エンドポイント

対象トラフィック

ノース・サウス

イースト・ウェスト

適用手段

ファイアウォール、ルーター

エージェント、ハイパーバイザー、クラウドネイティブな制御

ポリシーの基準

IPアドレス、サブネット

アイデンティティ、ラベル、タグ

粒度

粗い

きめ細かい

変更の頻度

比較的安定

非常に動的

必要とされる成熟度

低～中程度

中～高程度

主な用途

コンプライアンス、境界の制御

横方向の侵害拡大の防止、Zero Trust

実際に重要な点

この比較は有用ですが、十分ではありません。どちらのアプローチも次の性質を持つためです。

• ポリシーを生成する
• ポリシーを適用する
• 異なるプラットフォーム上に存在する

そして、これらのプラットフォームは互いを統制しません。そこにリスクが蓄積します。

ネットワークセグメンテーションを使うべき場合（および、それで十分な場合）

ネットワークセグメンテーションは、多くの場合、適切な出発点となります。

有効なユースケース

• コンプライアンスのためのゾーニング（PCI、HIPAA）
• OTとITの分離
• ゲスト環境と社内環境の分離
• セキュリティ成熟度の初期段階

それで十分と判断できる兆候

• イースト・ウェスト方向のトラフィックのリスクが限定的である
• アプリケーション環境が安定している
• クラウドの複雑性が小さい
• ファイアウォールのベンダー数が少ない

環境が比較的静的であれば、ネットワークセグメンテーションで多くの効果を得られます。

マイクロセグメンテーションを使うべき場合

横方向の侵害拡大のリスクが高まると、マイクロセグメンテーションが不可欠になります。

マイクロセグメンテーションが有効なユースケース

• ランサムウェアの封じ込め
• 最重要アプリケーションの保護
• ハイブリッド環境およびマルチクラウド環境
• 医療機器の分離
• 金融サービスにおけるアプリケーションのセグメンテーション

導入が必要な兆候

• イースト・ウェスト方向のトラフィックが多い
• 機密性の高いアプリケーションが同一ゾーンを共有している
• クラウドワークロードが急速に変化している
• 複数のポリシー適用プラットフォームがすでに導入されている

重要な注意点

規律のないままマイクロセグメンテーションに踏み込まないでください。ポリシーの挙動を検証する前に詳細な制御を適用すると、次のリスクが生じます。

• アプリケーションの停止
• 運用上の摩擦の発生
• 「パイロット地獄」による取り組みの停滞

ガバナンスなしにマイクロセグメンテーションを導入しても、リスクは低減しません。むしろ increase するどころか、多くの場合リスクを増幅させます。

両者を組み合わせる方法: 多層セグメンテーションモデル

現代の環境では、どちらか一方を選ぶのではなく、両者を重ねて利用します。次のように考えると分かりやすいでしょう。

• ネットワークセグメンテーション = 建物の壁
• マイクロセグメンテーション = 各部屋の内部にある施錠されたドア
• ZTNA/SASE (例: Zscaler) = 入口のセキュリティチェックポイント
• ガバナンス = すべてのドアが設計図どおりであることを保証するマスターキーシステム

各層は、それぞれ異なる方法でリスクを低減します。

• マクロ境界は攻撃対象領域を縮小する
• マイクロセグメンテーションはラテラルムーブメントを阻止する
• アクセス層はユーザーとアプリケーション間の接続を制御する

ただし、ここに落とし穴があります。適用はあらゆる場所で行われますが、意図はどこかで統制されなければなりません。デモを申し込むと、これらの層をまたいで統合されたポリシーガバナンスがどのように機能するかをご確認いただけます。

真の課題: すべての適用層におけるセグメンテーション意図の統制

ほとんどのセグメンテーション戦略が見落としている問題があります。

• ファイアウォールはネットワークセグメンテーションを適用する
• マイクロセグメンテーションプラットフォームはワークロードポリシーを適用する
• クラウドコントロールは環境固有のルールを適用する
• ZTNA/SASE プラットフォームはユーザーアクセスを適用する

各システムには、次の特徴があります。

• 独自のポリシーモデルを持つ
• それぞれ独立して進化する
• 他のシステムへの可視性を欠く

時間の経過とともに起こること

• ルールが追加される
• 例外が蓄積する
• ラベルが変更される
• クラウド環境が拡大する
• チームが実効的なアクセス状況を把握できなくなる

その結果どうなるか。意図したセグメンテーションモデルは、次第に現実から乖離していきます。データもそれを裏付けています。エンタープライズファイアウォールの 60%が、最初の評価で重大度の高いコンプライアンスチェックに不合格となっています。これはツールの問題ではなく、ガバナンスの問題です。コントロールプレーンがなければ、次の事態が生じます。

• 実際に何が許可されているのかについて、チームが確信を持てなくなる
• 監査が困難になる
• リスクが見えなくなる
• Zero Trust の取り組みが本番環境に到達する前に停滞する

FireMon がネットワークセグメンテーションとマイクロセグメンテーションのガバナンスを統合する方法

ファイアウォール、マイクロセグメンテーションプラットフォーム、クラウドコントロールはポリシーを適用します。FireMon はそれらの上位で、クラウドネットワークセキュリティポリシーガバナンスのコントロールプレーンとして機能します。

実務上の意味

• プラットフォーム横断でポリシーを正規化。FireMon は、ファイアウォールルール、クラウドコントロール、マイクロセグメンテーションポリシーを統合モデルにまとめます。Illumio や VMware NSX といったプラットフォームにも対応し、Zscaler などの隣接する層への可視性も提供します
• 意図と適用状況を継続的に検証。セグメンテーションがあらゆる環境で設計どおりに動作することを確認します
• ドリフトと露出を早期に検出。過剰に許可されたアクセス、違反、不整合を、インシデントになる前に特定します

これにより、次の間にあるギャップが解消されます。

• 意図した内容
• 実際に適用されている内容

そして、このギャップにこそ大半のリスクが潜んでいます。詳しくはZero Trust マイクロセグメンテーションガバナンスをご覧ください。

セグメンテーション戦略の選び方

セグメンテーションを検討する際は、いくつかの重要な問いから始めてください。

• 成熟度曲線のどの段階にいるか
• 主要なリスクは境界の侵害か、それともラテラルムーブメントか
• 環境はどの程度動的か
• 適用プラットフォームはいくつ関係しているか
• それらすべてにわたってポリシーの意図を確信をもって検証できるか

実践的な進め方

1. ネットワークセグメンテーションから始める 2. 重要度の高い資産にマイクロセグメンテーションを重ねる 3. すべての適用レイヤーにわたってポリシーを統制する Control Plane を導入する 詳細は次をご覧ください: ネットワークセグメンテーションのベストプラクティスをご覧ください。

次に取るべき行動

マイクロセグメンテーションかネットワークセグメンテーションかという問いは、ほとんどの企業にとって適切な問いではありません。どちらか一方を選ぶものではなく、複数のプラットフォーム、ベンダー、環境にまたがって両方を運用することになります。真の差別化要因はセグメンテーション技術ではありません。それを適用するすべての基盤にわたって、ポリシーの意図を統制できるかどうかです。統制がなければ、次のことが起こります。

• ポリシーが乖離する
• リスクが蓄積する
• Zero Trust が停滞する

統制があれば、次のようになります。

• リスクを測定できる
• アクセスを制御できる
• セキュリティが運用に組み込まれる

デモを申し込む　ハイブリッドかつマルチベンダーの環境全体で FireMon がどのようにセグメンテーションを統制するのか、ぜひご確認ください。