実用的観点からの（マイクロ）セグメンテーション

ベストプラクティスや戦略について説明する前に、まず前提を定義する必要があります。ネットワークセグメンテーションには、ネットワークを「分割」（セグメント化）し、誰が何にどのようにアクセスできるかを定義することが含まれます（たとえば、WebサーバーにはHTTP/S経由でのみアクセスできるなど）。 

従来、これはVLANと物理ファイアウォールを使用して実現されてきましたが、最近ではファイアウォールとセグメンテーションに対するソフトウェアベースのアプローチが多く見られるようになっています（例：Akamai Guardicore Segmentation）。どちらのアプローチにもメリットとデメリットがありますので、私たちはどちらか一方を推奨することはしません。私たちが推奨するのは、ベンダーに依存せず、あらゆる場所に適用できるポリシーや戦略です。

VLAN、アクセス・コントロール・リスト（ACL）、およびIP範囲を使用したトラフィック制御から、ベンダーに依存しないカスタムラベルの使用へ移行することで、マイクロセグメンテーションの領域に入ることとなります。このブログ記事で紹介する戦略はすべて、マイクロセグメンテーションを使用することを前提としています。

セグメンテーションを必要としないように戦略とガイドラインを適応させることは可能なはずですが、すべてのVLAN、ACL、およびIPリストを定義して維持するプロセスはおそらく非現実的であり、もしくはすべてのネットワーク管理者とエンジニアがすぐに疲れ果ててしまいます（すべての財務サーバーのIP範囲／グループを定義してみてください。それは可能かもしれませんが、そのリストを正確に長期間維持することはできるでしょうか？しかも、それは1つのサーバーグループにすぎません。エンタープライズネットワークには、エンドユーザー、ドメインコントローラー、ドメイン管理者、プリンターなど、他にも多くの要素が存在します）。

セグメンテーションの方法について論じる前に、主な前提条件である可視性について論じる必要があります。マイクロセグメンテーションは、それだけでは機能しません。「見えないものは守れない」という格言があります。適切なセグメンテーションは、トラフィックを整理して概観できるネットワーク可視性がある場合のみ有効です。通常、トラフィックは多すぎるため、現実的に人間の目で解析することはできません。

実際のセグメンテーション戦略に進む前に、適切なセグメンテーションに不可欠と思われるガイドラインや原則について説明します。

一般的に、受信トラフィックの多いサーバーは、Webサーバーやファイルサーバーなど、どちらかと言えばリクエストを処理する側のサーバーです（ドメインコントローラーもこのカテゴリに分類されます）。このようなサーバーでは、送信トラフィックの数を制限するか、少なくとも厳密に定義する必要があります。 

また、出力と入力の両方に対する制限を最小限にすると、サーバーを攻撃者にピボットとして利用されるリスクが生じます。なぜなら、そのサーバーは攻撃者にとってアクセスしやすく、ネットワークのより広範囲にアクセスするために利用できるからです。

マシンから発信されるトラフィックには大きなばらつきがあるため、一部のマシンに対してはポリシーを緩和しなければなりません。したがって、多くの例外を設ける必要があります。 

たとえば、ジャンプ・ボックス・サーバーです。これは、さまざまなユーザーがさまざまなプロトコルでさまざまなサーバーに接続するために利用します。すべてのユースケースをカバーしようとすると過度に許容的になってしまいますが、そうするとセグメンテーションの目的がすべて損なわれてしまいます。 

このような場合には、代わりに他の防御メカニズムを採用し、それらの制御をより厳格にすることが最善だと考えています。たとえば、ジャンプボックスのケースではより強力なユーザーアクセス制御を適用したり、監視サービスのアラート閾値を引き下げたりすることが挙げられます。

セグメンテーションを開始するときにすでに存在していたトラフィックだからといって、そのトラフィックを許可する必要はありません。生成されるトラフィックが不要であると見なされれば、既存のアプリケーションやサーバーの設定を変更しなければならない場合があります。場合によっては、既存の設定を参照して、そもそもなぜトラフィックが存在しているのかを把握する必要があります。

この場合、セグメンテーションは従来のファイアウォールと同様に、受信すべきではないネットワーク外からの受信トラフィックをブロックします。これは通常、インターネットからのトラフィックですが、自身のネットワークに接続されているサードパーティのネットワークからのトラフィックである場合もあります。 

したがって、公開されているSecure Shell（SSH）ポートやリモート・デスクトップ・プロトコル（RDP）ポート（あるいは本ドキュメントのラテラルムーブメントの項で扱うあらゆるポート）を遮断することが推奨されます。実際には、ネットワーク外部、特にインターネットから発信されるトラフィックについては、拒否リストよりも許可リストを使用する方が望ましいといえます（たとえば、インターネット上では常時どれほど多くのスキャナーが稼働しているかを考えてみてください）。

もちろん、他のセキュリティツールと同様、プラクティス（またはポリシー）のセグメンテーションであらゆる脅威に対処できるわけではありません。この場合、セグメンテーションですべての初期アクセスベクトルをカバーすることはできず、セグメンテーションのみに依存するとネットワークはリスクにさらされます。多くの侵害は、フィッシングメールやリンク、その他の形態のソーシャルエンジニアリングから始まります。 

また、一部のセキュリティ侵害は、許可する必要のあるプロトコルに脆弱性がある場合や、インターネットに正当に公開されているサービス（VPNサーバーなど）を利用するための認証情報が弱い場合に発生します。そのため、セグメンテーションだけに依存して初期アクセスを防止するのではなく、セグメンテーションに加えてホストと電子メールの保護のためのセキュリティソリューションを採用することが推奨されます。

ラテラルムーブメントを実行する方法は数多くありますが、ここではそのすべてを取り上げず、マシン上にすでに存在する正当なプロセスを通じて発生するラテラルムーブメントの防止に焦点を当てます。具体的には、プロトコル（RDPやSSHなど）、RPCベースのサービス（サービスマネージャーやタスクスケジューラーなど）、管理ツール（PowerShellやWMIなど）、またはLinuxで使用できるプロトコルやツール（別記事で紹介したものを含む）を対象とします。

ワンデイ脆弱性またはゼロデイ脆弱性については取り上げません。なぜなら、そのような脆弱性はあらゆる製品や実装に存在し得るため、一般的な戦略を適用することは現実的ではないからです。私たちが有効な対策として推奨できるのは、セグメンテーションです。アクセスできなければ、悪用するのは非常に困難だからです。

プロトコルごとの考慮事項について説明する前に、すべてに当てはまる2つの原則を確認します。

ユーザーは他のユーザーのマシンに（とりわけネットワーク経由で）アクセスする必要はありません。IT業務を行っている人でない限り、他のユーザーのマシンにリモートで接続する理由はそれほどありません。そのため、ネットワークの運用性を大幅に低下させることなくユーザーマシン間のトラフィックを制限することは十分可能です。

また、このセクションで説明するプロトコルはリモート制御やリモート実行に利用できるため、初期アクセスベクトルとしても利用できます。そのため、繰り返しになりますが、これらのプロトコルを介した任意のインターネットアクセスを制限する必要があります。

これらのサービスはインタラクティブでグラフィカルであるため、自動での使用はかなり制限されています。したがって、サーバー間でこれらのプロトコルが使用されているのを目にするのはそれほど多くないと予想されます（「予想される」という言葉が重要です。目にした場合は、その理由を調べる必要があります）。 

ユーザーマシン間でも同じ推論が当てはまります。ユーザーが互いに接続する必要はないはずです。これらの仮定の例外として、ジャンプボックスやターミナルサーバーがあります。それらを利用すれば、ユーザーが環境を転々と移動したりサーバーに接続したり、IT担当者がユーザーマシンに接続したり、アプリケーション所有者がアプリケーションサーバーに接続したりできます。 

このような例外には、セグメンテーションを使用して適切なポリシーを作成することで対処する必要がありますが、この取り組みは適切なアイデンティティアクセス管理（IAM）ソリューションで補う必要があります。

SSHの概念はRDPと似ていますが、話はより複雑です。SSHはターミナル（テキスト）ベースであるため、ソフトウェアとのやり取りに非常に使いやすく、SSHを使用するプログラムやスクリプトがあります。さらに、SSHは、SSHによってファイル転送プロトコルをカプセル化したSFTPなど、安全性の低いプロトコルをカプセル化するためにも使用されます。

そのため、SSHでは他のRDPよりもはるかに綿密なアプローチが必要です。ネットワークトラフィックを適切に可視化できなければ、エンドユーザーやネットワークの運用性に影響を与えずにSSHを適切にセグメント化することは極めて困難です。

MS-RPCとSMBのどちらも、すぐにラテラルムーブメントに利用できるわけではありません。しかし、これらを土台として構築された他のプロトコルは、すぐにラテラルムーブメントに利用できます（図4を参照）。SMBはファイル転送と通信に使用され、RPCは定義されたインターフェースからリモート機能を呼び出すために使用されます。RPCにSMBが使用されることもあるため、これらは密接に結合されています。また、これらはWindowsドメインシステムに組み込まれているため、適切にセグメント化することは極めて困難です。 

たとえば、ドメイン認証は、RPCベースのプロトコルであるNetlogonで実装されています。ドメインコントローラー上のSYSVOLという共有フォルダには、ドメイン・グループ・ポリシーやログオンスクリプトが格納されており、ドメインに参加しているコンピューターはSMBプロトコルを介してこれらにアクセスします。

ドメイン全体を破壊せずにSMBとRPCをブロックすることは実質的に不可能です。それでは、どうすればよいでしょうか？SMBでは、論理ユニットに基づいてポリシーを作成できます。宛先がファイルサーバーでない限り、ほとんどのサーバーとマシンはSMBを使用して相互に通信すべきではありません。そのため、適切なリングフェンシングセグメンテーションにより、SMBのリスクを緩和できます。

同様のアプローチをRPCに適用することもできますが、SMBとは異なり、ファイルサーバーにRPCトラフィックを許可する必要はないため、制限をより厳しくすることができます。また、RPCはユーザーモードで処理されるため、ターゲットのサービスまたはプロセスに応じてセグメンテーションポリシーを作成することができます。したがって、プロセスベースまたはサービスベースのルールを処理できるセグメンテーションエージェントがある場合にのみ、ラテラルムーブメントに悪用され得るRPCインターフェースに対処するだけでよいです。 

次の表には、ラテラルムーブメントを防止するために管理する必要があるRPCインターフェースが記されています。

これらのRPCインターフェースでのすべての操作が悪性であるわけではないため（たとえば、監視ソリューションやウォッチドッグがサービスの健全性を確認するためにリモートでサービスマネージャーとやり取りするなど）、既存のRPC通信を調査することが推奨されます。通常はRPCインターフェースにリモートでアクセスしない場合（またはソースリストを絞り込むことができる場合）、そのRPCインターフェースに関するセグメンテーションポリシーを作成し、セキュリティを強化することをお勧めします。

PowerShellとWMIはどちらもリモートマシンとやり取りでき、そのインタラクションはWindows Remote Management（WinRM）によって“実現されています。正当な使用法は通常、（WMIを使用した）リモート管理またはリモート監視であるため、ネットワーク内でのユースケースはほとんどありません。任意の使用を制限して、監視サーバーまたはITマシンでの使用のみを許可するセグメンテーションポリシーを作成できるはずです。 

もちろん、例外が発生する可能性はあり、開発者が利便性向上のために広範囲にわたってリモートPowerShellを使用した事例がいくつか見られました。そのため、個別の判断が必要となります。

小説『1984年』のように、あらゆる発信トラフィックを制御しない限り、セグメンテーションのみを使用して攻撃時のデータ窃取を防ぐことは現実的には期待できません。インターネットは広大であり、ユーザーがネットワークから接続しているすべてのサイトとサーバーに対して正確な判定を行うことは現実的ではありません。そのため、脅威アクターは他のすべてのアウトバウンドトラフィックの中に流出の試みを簡単に忍ばせることができます。

アウトバウンドトラフィックを制御するのではなく、機微な情報にアクセスできるユーザーを制御することの方が実現可能性が高いです。アウトバウンドトラフィックを制限できる唯一の場所は、ネットワーク内のサーバーです。ユーザーマシンとは異なり、アウトバウンドトラフィックの宛先のばらつきがかなり少ないはずです。

このセクション全体を貫く基本原則は、「存在しているからといって、それが許可されるべきとは限らない」ということです。ネットワークの一部をセグメント化する場合、ビジネスクリティカルなアプリケーション（SWIFTなど）であっても、運用ユニット（ドメインコントローラーなど）であっても、または環境（運用サーバーなど）であっても、最初にすべきことは既存のトラフィックの調査です（図5）。 

既存のトラフィックを分析した後に、関連するフローを許可して残りを制限するポリシーを作成できます（これは、セグメンテーションによってではなくアプリケーション所有者が対処する必要のある誤設定を見つける機会でもあります）。 

ブロックポリシーをすぐに適用せずに、アラート専用モードでしばらく実行することが推奨されます。意図したとおりにポリシーが実行されており、ポリシー違反アラートが最小限または制御された量であると判断された場合にのみ、制限ポリシーに移行します。 

また、現在の環境（セグメント化を開始する前に存在していた環境）と将来の環境（セグメンテーションポリシーを適用した後の環境）を区別することも重要です。最初にセグメンテーションを実行するときは、注意を払い、そのネットワークについて学習し、様々な要素を壊さないようにする必要があります。 

そして、新しいポリシーを追加する際には、既存のセグメンテーションポリシーを考慮する必要があります。通常の運用に必要な場合はポリシーによる例外や許可を設定しますが、ネットワークを拡張しているからといって既存のポリシーを無視してはなりません。

リングフェンシングを行う際は、主にネットワークの他の部分とセグメントのインターフェースや世界とセグメントのインターフェースに着目します。セグメント内で何が起こっているかは考慮せずに、セグメント化したいネットワークの部分に出入りするものを制御することを目指します。

リングフェンシングをさらに一歩進め、個々のマシンの目的に合わせてそれぞれにポリシーを適用することができます。たとえば、サーバーがデータベースとしてのみ機能する場合、データベースポートを介したアクセスのみを許可する必要があります（Webポートを介したWebサーバーへのアクセスなど）。

しかし、これはそれほど簡単なことではありません。通常、そのサーバーへのアクセスを必要とするサービス（ウォッチドッグ、パフォーマンスモニター、ITなど）が数多く存在します。また、そのアクセスポートは通常、ラテラルムーブメント手法によく似ています。それらは通常、何らかのリモートコントロールを軸として行われるからです（たとえば、リモートウォッチドッグは、PsExecラテラルムーブメント手法と同様の方法でサービスマネージャーにクエリーを実行します。呼び出しを区別する唯一の方法がディープ・パケット・インスペクションですが、これは通常は使用できません）。

この課題を克服するためには、すでにサービスにアクセスする必要があるもの以外に追加のトラフィックを許可する必要がある場合に、許可されるソースを監視を行うセグメントに制限することが推奨されます。

また、ユーザーが必要としない機密の場所へのアクセスを制限することもできます。内部アプリケーションだけがデータベースを利用している場合、任意のユーザーがそのデータベースに対してクエリーを実行できるようにする理由はほとんどありません。私たちの見解では、任意のユーザーによるアクセスをブロックすることは最も重要なセキュリティ対策です。なぜなら、多くの攻撃は侵害されたユーザーから始まるからです。

マイクロセグメンテーションを行う際、私たちはセグメンテーションポリシーに別の粒度レイヤーを適用しており、役割や感度に基づいてセグメント内のマシンを分離します。これは、アプリケーションリングフェンシングと一般的なリングフェンシングのハイブリッドと考えることができます。リングフェンシングとの大きな違いは、セグメント内のトラフィックを制御することと、ネイバーを自動的に信頼しないことです。

ここでの原則は、同じセグメント内にあるからといって、隣接するマシンからのトラフィックを信頼してはならないということです。攻撃者は、セグメントに関係なく、利用できるあらゆる接続を利用してネットワーク全体に伝播しようとします。 

したがって、セグメント内に同じ種類のアプリケーションサーバーがあっても、それらがすべてのポートとプロトコルで相互に通信できるようにする理由はありません。マイクロセグメンテーションとは、ネットワークセグメント内でも、同じ役割を持つマシン間でも、あらゆる種類のトラフィックにポリシールールを適用することを意味します。

もちろん、同じセグメント内のマシンは通常、より緊密に結び付いているため、過度に許容することなくポリシーを追加することは困難です。

ネットワーク内のセグメントの定義のしかたによっては、アプリケーションリングフェンシングの原則をそのままマイクロセグメンテーションの原則として利用できる場合もあります。たとえば、ネットワークをユーザーセグメント、データベースセグメント、Webサーバーセグメントに分割する場合、アプリケーションリングフェンシングで定義される原則は、マイクロセグメンテーションにも適用可能です。ただし、その場合は各アプリケーションセグメント内の異なるマシン間で同じ原則を適用する必要があります。

一方、ネットワークが財務セグメント、営業セグメント、ITセグメントに分割されており、各セグメントにサーバーとユーザーマシンが混在している場合は、よりクリエイティブになる必要があります。一般的なリングフェンシング戦略をセグメントに適用した後に、セグメント間およびセグメント内のポリシーを作成しなければなりません。各セグメントをミニネットワークと見なすことができます。その後、各セグメントを、そのセグメントに含まれるさまざまなアプリケーションやマシンタイプに分けることができます（たとえば、営業セグメントの場合、ファイルサーバー、データベース、およびユーザーマシンがある可能性があります）。各種類のマシンを新しいセグメントとして扱い、再びガイドラインに従ってリングフェンシングやアプリケーションリングフェンシングを行うことができます。

図6は、さまざまセグメンテーション戦略の関係をまとめたものです。

ネットワークセグメンテーションは、ネットワークのセキュリティを強化し、ネットワークベースの脅威に対処するために役立つツールです。また、セキュリティ上の価値を即座にもたらすツールでもあり、これを利用すれば長いセグメンテーションプロジェクトや困難なセグメンテーションプロジェクトを開始する必要がなく、作業を複数のサブプロジェクトに分割でき、各サブプロジェクトでネットワークのセキュリティポスチャが一歩ずつ改善されます。 

ネットワーク管理者がそれを行えるように、Akamaiはセグメンテーションポリシーやセグメンテーション戦略に関するさまざまなガイドラインを提供してきました。当社の推奨が実用的であり、組織のセキュリティ強化に役立てば幸いです。

Akamai Security Intelligence Groupは今後も、さまざまなセキュリティトピックに関する調査の監視、研究、公開に取り組みます。リアルタイムの最新情報、およびセキュリティ関連の調査について詳しくお知りになりたい場合は、X（旧Twitter）でフォローしてください。