前回の記事「次世代マイクロセグメンテーション Zero Networksとは？ネットワーク層MFAで実現する真のゼロトラスト」では、
Zero Networksの概要や昨今のサイバーセキュリティ状況における「封じ込め（Containment）」の重要性について詳しくご紹介しました。
今回は、Zero Networksが持つ最大の強みであり、特許取得済みの機能である ネットワーク層MFAについて、
具体的な仕組みや設定の大枠、実際の動作検証プロセスを解説します。
「特権ポートを狙った攻撃を防ぎたいけれど、運用効率も落としたくない……」という管理者必見の内容です。
～WFP（Windows Filtering Platform）を活用した時限アクセスでラテラルムーブメントを封じ込める～
ドメイン管理者の認証情報が漏えいした瞬間、社内のRDPやSSHが攻撃者に利用されたら――。インフラエンジニアなら、一度は想像したことがあるシナリオではないでしょうか。
近年のランサムウェア攻撃では、「侵入されること」よりも、その後に社内を自由に移動されるラテラルムーブメントが大きな被害につながります。侵入した攻撃者がRDPやSSHを悪用して社内を自由に動き回る「ラテラルムーブメント」は、これまでの境界防御では防ぎきれませんでした。
そこで本記事では、特許技術である「ネットワーク層MFA」を掲げるZero Networksを、弊社のラボ環境で検証しました。「必要な時だけ、認証された人にだけ」通信経路を開放するJust-In-Time（JIT）アクセスをどのように実現するのか、仕組みと実機の挙動をレポートします。
■WFPとは
Windows Filtering Platform（WFP） は、Windowsに標準搭載されている通信監視・制御の仕組みです。
ネットワーク通信がOSに届く前後で「誰が、どこへ、どのアプリから通信しようとしているのか」を判定し、許可・拒否を行います。
Zero NetworksはこのWFPを活用し、通信の発生を検知するとMFA認証を要求し、認証に成功した場合のみ一時的にアクセスを許可します。
独自のファイアウォールドライバーで通信を制御するのではなく、Windows標準機能を利用するため、安定性や互換性を保ちながら高度なアクセス制御を実現しています。
ネットワーク層MFAとは？Zero Networksが実現するJust-In-Time（JIT）アクセス
仕組み
これまでのマイクロセグメンテーションは、IPベースの経路制御が主役でした。しかし、これでは「管理者になりすましたアクセス」を止められません。Zero Networksの ネットワーク層MFA は、通信がサーバーに届く直前のネットワーク層で本人確認を強制します。攻撃に悪用されやすい特権ポートをデフォルトで「ステルス化（閉鎖）」し、認証に成功したときだけ時限的にゲートを開放します。
実際に検証してみると
今回の検証では、Windows Server環境をターゲットに、MFA設定後に未認証端末からのポートスキャンが抑止されることを確認しました。さらに、正規の管理者が接続を試みたタイミングでMFA認証が実行され、一時的なアクセスが許可されるまでの流れをステップバイステップで確認しました。
ここがポイント
- 「IPアドレス」ではなく「アイデンティティ（人間）」でネットワークを縛る発想の転換。
- 攻撃の71%で狙われる「RDP/WinRM/SSH/RPC」を標準でガード。
「通信の直前」にゲートが出現！VPN MFAとの決定的な違い
仕組み
従来のVPN MFAなどは、一度突破されると内部の特権ポートが「開けっ放し」になりがちです。対してZero Networksは、管理者がRDPを開始したパケットそのものをトリガーにメール認証やブラウザ認証を起動します。認証が完了すると設定された有効期間に限って通信経路を開放するため、攻撃者が「開いている穴」を探すことも困難になります。
実際に検証してみると
Activitiesログを確認して驚いたのは、単なるIPアドレスやポート番号だけではなく、通信を発生させたプロセス名やADユーザー情報まで把握できていたことです。
一般的なVPN MFAが「誰がネットワークに入ったか」を確認するのに対し、Zero Networksは「誰が・どの端末から・どのプロセスで・どのサーバへ接続しようとしているか」を通信単位で把握した上でMFAを要求します。
実際に検証してみると、認証対象をネットワーク境界ではなくアクセス行為そのものにできる点が非常にユニークであり、運用現場に適した仕組みだと感じました。
ここがポイント
- VPN MFAが「境界」を守るなら、ネットワーク層MFAは「資産そのもの」を自動ロックする。
- 独自ドライバー不要。OS標準のWFPを使うからこそ得られる抜群の安定性。
【検証レポート】JITアクセスの挙動を5ステップで追いかける
ここからは、実際に手を動かして確認した検証プロセスを紹介します。今回の検証では、Windows Server環境をターゲットに、MFA設定後のポートステルス化、認証要求、一時的なアクセス許可、自動失効までの一連の流れを確認しました。
■今回の検証構成
ステップ1：設定は拍子抜けするほど簡単？ポリシー作成の実態
仕組み
設定は、管理コンソールの「Inbound MFA Policy」から行います。
どのポートをトリガーにするか（例：RDP TCP 3389）、どの認証メソッドを使うか（Email OTP、Microsoft Entra ID、Oktaなど）を指定します。
実際の検証結果
①管理コンソールの「Network」→「Assets」→「Monitored」から、「Inbound MFA」の対象となる検証サーバーを指定します。
※本記事ではホスト名などの環境固有情報はマスキングしています。
■Monitored画面
②「Rules」→「Inbound MFA」→「Add MFA Policy」からMFA設定を実施します。今回は検証のため、下記の内容で設定しました。
■MFA Policy設定画面
■設定後画面
| 設定項目 | 説明 | 選択可能項目 | 今回の設定 |
|---|---|---|---|
| Source assets | MFAを要求する接続元アセット（端末）を指定します。 | ・Any asset ・Unmonitored assets ・単体サーバ・端末指定 等 |
Any Asset（すべての管理端末） |
| Excluded source assets |
MFA対象から除外する接続元アセットを指定します。
|
・Administrators ・All domain admins 等 |
指定なし |
| Source processes | MFA要求の対象とする接続元プロセスを指定します。 | ・Any process ・プロセスパスはフルまたは部分的(ワイルドカード付き)のいずれかで指定可能。サービスは短縮名(例:W32Time)で指定する必要があります。 |
Any process |
| Excluded source processes | MFA対象から除外するプロセスを指定します。 | – | 指定なし |
| Source users | MFAを要求するユーザーを指定します。特定ユーザーやグループへの限定も可能です。 | ・Any user ・Administrators ・Domain Admins 等 |
Any user |
| Fallback to logged-on user | 接続を開始したプロセス(システムプロセスなど)からユーザーコンテキストを取得できない場合、MFAポリシーはログインユーザーにフォールバックしてMFAを実行しようとします。 | ・On ・Off |
Off |
| Restrict to initiating user | MFA認証したユーザーと、実際に接続に利用するユーザーが一致しているときのみアクセス許可するかを指定します。 MFAリクエストを開始するユーザーが使用する認証情報以外の認証情報の使用を禁止します。 |
・On ・Off |
On |
| Use PAM | PAM（Privileged Access Management） から特権アカウントのパスワードを自動取得する機能を有効化するかを指定します。 | ・Off ・RDP file ・Password |
Off |
| Destination assets | MFAで保護する対象サーバを指定します。 | ・All segmented assets ・単体サーバ・端末指定 ・Administrators 等 |
検証用Windows Server |
| Destination processes | MFA要求の対象とする接続先プロセスを指定します。 | ・Any process ・プロセスパスはフルまたは部分的(ワイルドカード付き)のいずれかで指定可能。サービスは短縮名(例:W32Time)で指定する必要があります。 |
Any process |
| Triggering destination ports | MFA要求を発生させる宛先プロトコルとポートを指定します。 | ・任意の対象ポートを指定可能 | TCP 3389 |
| Extra ports to open | 認証成功後に追加で開放するポートを指定します。 | ・任意の対象ポートを指定可能 | 指定なし |
| Name | ポリシーの名前を記載します。 | ・任意 | RDP MFA |
| MFAポリシーでデフォルトのIDプロバイダー（IdP）を使用するかどうかを指定します。 | ・On ・Off |
On | |
| Use MFA Cache | MFAキャッシュがこのMFAポリシーに使用されるかどうかを指定します。 | ・On ・Off |
Off |
| MFAポリシーはこのポリシーで指定されたソースフィールドのみがトリガーされ、同じポートのグローバルポリシーには含まれません。
例えば、ソースユーザーでドメイン管理者を指定し、宛先がTCP 3389ポートのドメインコントローラーで、「グローバルのオーバーライド」が「オン」の場合、ドメイン管理者でないユーザーは、グローバルグループ「All segmented assets」内の「任意の」ユーザーに対して別のMFAポリシーがあっても、DCへのMFAプロンプトを受け取りません。 |
・On ・Off |
Off | |
| MFA methods | MFAの認証方式を指定します。 | ・Email ・Browser ・No MFA ※IdP設定で接続情報を追加すると対象IdPも選択可能となります。 |
Email&Browser ※両認証方式で検証 |
| Expiration of reactively created rules | ルールの有効期限を指定します。 | ・Never ・Hour ・4hours ・8hours ・12hours ・16hours ・Day ・Week ・Month |
hour |
| Secured connection | MFA認証後の認証済み、暗号化された通信のみ許可するかどうかを指定します。 |
・Disabled
・Authenticated and integrity-protected connections
（認証済みかつ改ざん防止された接続）
・Encrypted connections（暗号化された接続）
・Null encapsulation connections
（カプセル化なし接続）
・Encrypted connections and dynamically negotiate encryption
（暗号化接続かつ動的にネゴシエーションする暗号化方式）
|
Disabled |
| Change Ticket | このポリシーが作成されたチケットの番号指定します。 | ・任意 | 指定なし |
| Description | ポリシーの簡単な説明を記載します。 | ・任意 | 記載なし |
| State | 本ポリシーを有効にするかどうかを指定します。 | ・Enabled ・Disabled |
Enabled |
ステップ2：本当に見えない！偵察活動を「無効化」するステルス性能
仕組み
MFAポリシーが適用されたアセットは、その瞬間から「ステルス状態」になります。業務に必要な通信以外はデフォルトで破棄（Drop）されるためです。
実際の検証結果
検証端末からポートスキャンを実施したところ、本来であれば「Open」と表示されるはずの TCP 3389 が「Filtered（応答なし）」となりました。
つまり、外部から見るとRDPポートの存在を判別できず、攻撃者による偵察活動を困難にできることを確認できました。
一方で、対象サーバ上で netstat を実行したところ、TCP 3389 は LISTENING 状態であり、RDPサービス自体は正常に動作していました。
また、Windows Defender Firewall の設定を確認したところ、「リモートデスクトップ（TCP受信）」ルールも許可状態となっており、Windows FirewallによってRDP通信が遮断されているわけではありませんでした。
次に、WFPのフィルタ一覧を確認したところ、Zero Networks – Network Segmentation に関連するフィルタや、既定で通信をブロックする ZN-NetSeg-Inbound-Block-Ipv4-Default などのルールが登録されていることを確認できました。
これらの結果から、Zero NetworksはRDPサービスを停止したり、Windows Firewallの設定を変更したりするのではなく、Windows標準機能であるWFP上のフィルタを利用して未認証の通信を制御していることが分かりました。
つまり、サーバ側ではRDPサービスを通常どおり待受状態（LISTENING）のまま維持しながら、認証されていない通信のみをWFPで遮断しています。その結果、利用者からは「ポートが見えない」「接続できない」状態に見える一方、認証後は即座に通信を許可できます。
今回の検証により、Zero Networksがサービス停止やポート開閉ではなく、WFPによるネットワーク層の通信制御によってJust-In-Timeアクセスを実現していることを確認できました。
これはZero Networks独自の特許技術です。
■検証端末からのポートスキャン結果
■対象端末でのWindows Defender Firewall設定（通信許可）
■対象端末でのポート状態（OPEN状態）
■WFPフィルタ一覧でZero Networksネットワークセグメンテーション用フィルタが登録
ここがポイント
- 「穴を塞ぐ」のではなく「穴を見せない」ステルス戦略。
- Firewallを閉じているのではなく、WFPに登録されたZero NetworksのNetSegフィルタで通信制御している。
ステップ3：パケットがトリガー！担当者へMFA認証を要求
仕組み
担当者がいつものようにリモートデスクトップ（mstsc.exe）を開始すると、その通信を検知して即座にMFA認証が要求されます。
今回の検証では、メール認証とブラウザ認証の両方を試しました。
メール認証では「接続元サーバ・端末でログオンしているユーザ」のAD Mail属性に登録されたメールアドレス宛てに認証要求が送信され、
画面には「誰が・どのプロセスで・どのサーバへ」アクセスしようとしているかが表示されるため、正当な操作であることを再確認したうえで承認できます。
※メールのヘッダーを確認したところ、RDP接続を開始してから約7秒程度でZero Networksが認証要求メールを送信している事がわかりました。
一方、ブラウザ認証では接続元端末上で認証画面が自動的に表示され、そのまま本人確認を実施できることを確認しました。
いずれの方式でも「誰が・どのプロセスで・どのサーバへ」アクセスしようとしているかが表示され、認証完了後に通信が許可され、
RDP接続を開始できました。
※ブラウザ認証でも同様にRDP接続を開始してから15秒程度で認証要求ブラウザが表示されました。
実際の検証結果
①検証用端末からリモートデスクトップ接続を開始します。
②初回のリモートデスクトップ接続は失敗し、「接続元サーバ・端末でログオンしているユーザ」のAD Mail属性に登録されたアドレスへメールが届きます。
※メール認証時は接続元サーバ・端末でログオンしているユーザのAD Mail属性にメールアドレスの登録が必要となります。
③メール認証で送信されるメールには、「誰が・どのプロセスで・どのサーバへ」アクセスしようとしているかの詳細が表示されます。
④認証画面で任意のメールアドレスを指定し、認証リクエストを送信します。
※任意のメールアドレスを入力できますが、実際に認証メールが送信されるのは、ADのユーザー情報に登録された Mail 属性のアドレスのみとなります。
ブラウザ認証の場合は上記メール送信は行われず、接続元端末上で下記認証画面が立ち上がってきます。
⑤認証リクエスト後に届いた認証コードを入力し、「Approve」することで通信が許可されます。
⑥認証完了結果画面が表示されます。
ここがポイント
- 通信開始をトリガーにMFAが実行されるため、必要な操作だけを都度確認できる。
- メール認証を利用する場合は、事前にユーザーのMail属性へ有効なメールアドレスを登録しておくことが重要。
- Zero Networksの管理サーバ（セグメントサーバ）から対象サーバへWinRMで常時接続をしているため、
エージェントレスにもかかわらず、RDPなどの通信を即座に検知できる。
ステップ4：認証成功で道が開く！JITアクセスが生み出す「最小権限」の瞬間
仕組み
MFA認証が完了すると、Zero Networksは認証結果に基づき、対象アセットへのアクセスを一時的に許可します。
これが JITアクセス の真髄です。
実際の検証結果
先ほどまでポートスキャンできなかった状態から、認証後は通信できる状態に変わります。
実際にZero Networksの管理画面でも「Inboundルール」に許可設定が追加され、「Activities」でも通信拒否から通信許可までのログを確認できます。
■Inboundルールへ自動追加
■Activitiesログ
ここがポイント
- 認証された人に、必要な時間だけ通信経路を作る。
- 特権ポートの常時公開を避け、アタックサーフェスを最小化できる。
ステップ5：後片付けも全自動！「閉め忘れ」を許さない自動運用
仕組み
JITアクセスは、あらかじめ設定した有効期間（Expiration of reactively created rules）が終了すると自動的に失効します。
その後は、新しい接続には再度MFAが必要になります。
※「Use MFA Cache」をONにしておけば、Inbound Ruleから設定が消えても再度MFA認証無しでもアクセス可能となります。
実際の検証結果
「Expiration of reactively created rules」を1時間に設定して放置してみたところ、有効期限終了後のRDP接続は拒否され、再度MFAを要求されました。
JITアクセスが自動で失効することを確認でき、「後片付け」をシステムに任せられる安心感を強く感じました。
■有効期限を迎えると自動削除
■ポートスキャンも再び不可
■再度RDP接続を行うと、認証要求が再発生
実際の現場で考えられるユースケース
ユースケース：複数管理者で同一サーバにアクセスする場合
運用現場では、複数の管理者（管理者A、管理者B）が同一のサーバにアクセスし、システムを管理するケースがあります。
本検証では、複数の管理者が同一のサーバにアクセスする環境において、どのように認証されるのかを確認しました。
複数の管理者が同一の接続サーバを利用する場合でも、MFA認証メールの送信先は「接続元端末でログオンしているユーザ」のAD Mail属性に登録されたアドレスとなります。
そのため、UserAでログオンした管理者AにはUserA宛、UserBでログオンした管理者BにはUserB宛に認証メールが届き、管理者ごとにMFA認証が必要となります。
各自が認証を完了すると、その端末から接続サーバへのRDP接続が許可され、以降はAdministratorなどの共通アカウントでログインして運用可能となります。
管理者が複数いても、接続元端末にログオンしているユーザへ認証要求がいくため、それぞれの担当者で独立して運用を実施できることが確認できました。
■ユースケース構成
ここがポイント
共通のAdministratorアカウントを運用している環境でも、Zero Networksはユーザー情報だけではなく接続元端末も考慮してアクセス制御を実施します。
そのため、ある端末で認証済みだからといって別端末から自動的にアクセスできるわけではなく、各端末ごとにMFA認証が必要となることが確認できました。
SI現場のエンジニアが語る：設計・運用の「ここが勘所」
検証を通じて得た、SIerの視点でのアドバイスをまとめます。
| 観点 | 設計・運用で意識したいこと |
|---|---|
| ポリシー設計の広がり | ネットワーク層MFAはRDPだけでなく、社内Webアプリや管理用ポートなど任意のTCPサービスに適用できます。 重要システムへのアクセス経路全体を保護できる点が大きな特徴です。 |
| クラウド疎通の事前確認 | ネットワーク層MFAを利用する場合、対象アセットからZero NetworksクラウドへのHTTPS（TCP443）通信が必要です。 PoC開始前に通信経路やProxy設定を確認しておくことで、認証トラブルを防止できます。 |
| ADユーザー情報の整備 | Email認証を利用する場合は、ADのmail属性に正しいメールアドレスが登録されていることを確認します。 特に古いアドレスや共有アドレスが残っていると認証トラブルの原因になります。 |
結論：認証情報を盗まれても「物理的に通さない」安心感
今回の検証を通じて、Zero Networksのネットワーク層MFAは、Windows標準のWindows Filtering Platform（WFP）を活用しながら、認証結果に応じてJust-In-Time Access（JIT）を実現する仕組みであることを確認できました。
特に印象的だったのは、管理用ポートを常時公開することなく、必要なタイミングだけ認証済みユーザーへアクセスを許可するというアプローチです。
今回のラボ検証では、ポートスキャン時のステルス化、MFA認証の起動、一時的なアクセス許可、そして有効期限終了後の自動失効まで、一連の動作を確認することができました。
近年は、認証情報の漏えいを前提とした「侵害前提（Assume Breach）」の考え方が一般的になっています。そのような環境では、「侵入を防ぐ」だけでなく、「侵入後に自由に動けない」状態を作ることが重要です。ネットワーク層MFAは、その考え方を実装する有効な選択肢の一つであると感じました。
次回予告
今回はWindows環境を対象に、ネットワーク層MFAによるJust-In-Timeアクセス制御を検証しました。
次回はZero Networksのさらに実践的な活用方法として、エージェントレス／エージェント型の違いや導入方法、通信可視化や自動ポリシー生成の仕組み、さらにOT/IoT環境への適用まで、実機を用いて検証していく予定です。