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

ベストプラクティスや戦略について説明する前に、まず議題を定義する必要があります。ネットワークセグメンテーションには、ネットワークを「分割」（セグメント化）し、誰が何にどのようにアクセスできるかを定義することが含まれます（たとえば、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 は今後も、さまざまなセキュリティトピックに関する調査の監視、研究、公開に取り組みます。リアルタイムで最新情報や最新の調査結果を知りたい方は、ぜひ Twitter で Akamai をフォローしてください！