Azure VPN GatewayのPoint-to-Site（P2S）接続を部門・権限・委託先ごとに分けて運用したい場合、今回のGAは重要です。これまでP2S VPNでは「接続できたユーザーをネットワーク上でどう分離するか」が設計上の悩みになりがちでした。2026年5月のAzure Networking更新で、VPN GatewayのP2S接続におけるUser Groups and IP address poolsが一般提供（GA）となり、ユーザーのIDや資格情報に応じて異なるIPアドレスプールを割り当てられるようになりました。(Microsoft Azure)
結論から言うと、この機能は「VPNに接続できるか」だけでなく、「接続後にどのネットワーク範囲として扱うか」を設計しやすくする更新です。管理者は、Microsoft Entra IDグループ、証明書のCommon Name、RADIUS属性などを使ってユーザーグループを判定し、グループごとに異なるP2SクライアントIPアドレスプールを割り当てられます。これにより、Azure Firewall、NSG、ACLなどの送信元IPベースの制御と組み合わせて、部門別・権限別のアクセス制御を実装しやすくなります。(Microsoft Learn)
Azure VPN GatewayのP2S接続で何が変わったのか
今回GAとなったUser Groups and IP address poolsは、P2S VPNユーザーを論理的なユーザーグループに分類し、グループごとに異なるIPアドレスプールを割り当てる機能です。Microsoft Learnでは、User GroupまたはPolicy Groupを「同じアドレスプールからIPを割り当てるべきユーザーの論理表現」と説明しています。(Microsoft Learn)
従来のP2S VPNでも、Azure上のリソースへリモート接続することはできました。しかし、全ユーザーを同じクライアントアドレスプールで扱う設計では、接続後のアクセス制御が粗くなりやすいという課題がありました。
今回の機能を使うと、たとえば次のような分離がしやすくなります。
| 利用者の種類 | 割り当てるP2S IPアドレスプール例 | 想定するアクセス制御 |
|---|---|---|
| 社内一般ユーザー | 10.10.10.0/24 | 業務アプリのみに許可 |
| 開発者 | 10.10.20.0/24 | 開発環境・検証環境に許可 |
| 運用管理者 | 10.10.30.0/24 | 管理用サブネットや踏み台に限定許可 |
| 外部委託先 | 10.10.40.0/24 | 特定システムだけに最小権限で許可 |
重要なのは、この機能自体がアプリケーション権限やAzure RBACを置き換えるものではない点です。役割は「VPN接続後の送信元IPをグループごとに分けること」です。そのうえで、Azure Firewall、ネットワークセキュリティグループ、ルート、アプリ側の認可と組み合わせて、実際のアクセス制御を設計します。Microsoftのユースケースでも、部門ごとに事前定義したアドレスプールを割り当て、そのIPを使ってFirewall、NSG、ACLで許可または拒否する例が示されています。(Microsoft Learn)
GAによる実務上の意味
Azure Updatesの「Launched」は、一般に実稼働向けにリリースされた状態を示します。Azure UpdatesページではLaunchedを「完全にリリースされた実稼働対応の製品」と説明しています。(Microsoft Azure)
ただし、GAになったからといって、既存のP2S VPN構成が自動的にグループ別IPプールへ移行されるわけではありません。Azure portalの手順では、User Groupsは既定で無効であり、VPN GatewayのPoint-to-site configurationから有効化して設定する流れになっています。(Microsoft Learn)
実務上は、次のように捉えるのが安全です。
| 観点 | 変更前に起きやすかった課題 | 今回のGAで取りやすくなる対応 |
|---|---|---|
| アクセス制御 | P2S接続ユーザーを同じIP範囲として扱いがち | 部門・権限・委託先ごとに送信元IP範囲を分離 |
| セキュリティ運用 | 「VPN接続済みなら広く到達できる」設計になりやすい | NSGやFirewallでグループ単位の許可ルールを作りやすい |
| 監査 | ログ上の送信元IPだけでは利用者種別を推測しにくい | IPプール単位で利用者カテゴリを識別しやすい |
| 展開 | 個別ユーザーごとの例外設定が増えやすい | Entraグループや証明書CNなどの条件で分類可能 |
特に、リモートワーク、外部ベンダー接続、開発者VPN、特権管理者用VPNを同じP2S構成で扱っている環境では、設計を見直す価値があります。
影響を受ける管理者・開発者
この更新の主な対象は、Azure VPN GatewayでP2S VPNを運用しているネットワーク管理者、ID管理者、セキュリティ担当者です。アプリケーション開発者にも影響があります。アプリ側で送信元IPによる許可リストを使っている場合、P2SユーザーのIP範囲がグループ別に分かれることで、許可ルールの見直しが必要になるためです。
管理者が確認すべき範囲
まず確認すべきなのは、現在のP2S VPNがどの認証方式で構成されているかです。User Groupsの判定に使える値は認証方式によって異なります。Microsoft Learnでは、Microsoft Entra IDではグループのObject ID、RADIUSではVendor-Specific Attribute、証明書認証ではCommon Nameのドメイン名が利用されると説明されています。(Microsoft Learn)
| 認証方式 | グループ判定に使う主な値 | 注意点 |
|---|---|---|
| Microsoft Entra ID | EntraグループのObject ID | グループ名ではなくObject IDを使う |
| 証明書認証 | 証明書Common Nameのドメイン部分 | SANだけに依存した設計は避ける |
| RADIUS | MS-Azure-Policy-IDのVSA値 | RADIUS/NPS側の属性設定が必要 |
Microsoft Entra IDを使う場合、グループ名ではなくObject IDを指定する点は特に間違えやすいポイントです。グループ名は変更される可能性がありますが、Object IDは識別子として扱われます。設定時に表示名をコピーしてしまうと、期待したグループ判定にならない可能性があります。(Microsoft Learn)
開発者が確認すべき範囲
開発者は、アプリやミドルウェアがP2S VPNユーザーの送信元IPに依存していないかを確認してください。
たとえば、次のような構成では影響が出る可能性があります。
| 確認対象 | 見直すポイント |
|---|---|
| WebアプリのIP制限 | 旧P2Sアドレスプールだけを許可していないか |
| API ManagementやApplication Gateway前段の制御 | 新しいグループ別CIDRを許可対象に含める必要があるか |
| VMやDBのファイアウォール | 管理者用・開発者用・委託先用を分けて許可できるか |
| 監査ログ・SIEM | IPプールから利用者カテゴリを判定するルールを追加できるか |
注意したいのは、「特定ユーザーに固定IPを割り当てる機能」と誤解しないことです。この機能の主眼はユーザーグループごとのIPアドレスプール割り当てです。ログ分析では、個人の特定をIPだけに頼らず、VPN認証ログ、Entra IDサインインログ、アプリケーションログと突き合わせる設計が必要です。
設定前に押さえるべき制限と設計条件
User Groups and IP address poolsを展開する前に、制限事項を確認しておく必要があります。Microsoft Learnでは、1つのP2S VPN Gatewayで参照できるグループ数は最大90、ゲートウェイに割り当てられるポリシー/グループメンバー総数は390とされています。また、アドレスプールは他の接続構成、仮想ネットワーク、仮想ハブ、オンプレミスのアドレスと重複できません。(Microsoft Learn)
| 項目 | 確認内容 |
|---|---|
| グループ数 | 1つのP2S VPN Gatewayで最大90グループまで |
| メンバー数 | 割り当て済みグループ全体で最大390メンバーまで |
| 優先順位 | 数値が小さいグループが先に評価される |
| デフォルトグループ | どの条件にも一致しないユーザーが入る |
| アドレスプール | 他のプール、VNet、Virtual Hub、オンプレミス範囲と重複不可 |
| 最小プレフィックス | 構成手順では/24より小さい範囲は指定不可とされている |
特に重要なのは、デフォルトグループの設計です。条件に一致しなかったユーザーはデフォルトグループに割り当てられます。デフォルトグループを強い権限のネットワーク範囲にしてしまうと、設定ミスや外部ユーザーの属性不備が過剰権限につながります。Microsoft Learnでも、外部ユーザーの種類や名前が正しく設定されていない場合、デフォルトグループのIPプールに割り当てられる可能性があると説明されています。(Microsoft Learn)
実務では、デフォルトグループは「最小権限」「隔離」「検証用」に近い扱いにするのが安全です。たとえば、デフォルトグループには業務システムへの直接アクセスを許可せず、問い合わせ用ポータルや限定的な踏み台のみ許可する設計が考えられます。
推奨する展開手順
導入時は、いきなり本番VPN Gatewayに設定を入れるのではなく、現在のP2S設計を棚卸ししてから段階的に展開するのが安全です。
| 手順 | 作業内容 | 失敗しやすいポイント |
| -: | ——————————————- | —————————— |
| 1 | 現在のP2S認証方式、クライアントアドレスプール、NSG/Firewallルールを確認 | 既存の許可ルールを把握せず新プールを追加して通信断 |
| 2 | 利用者をグループ化する基準を決める | 部門名だけで分け、権限レベルを考慮しない |
| 3 | グループごとのCIDRを設計する | VNetやオンプレミスと重複する範囲を選ぶ |
| 4 | Entra Object ID、証明書CN、RADIUS VSAを整理する | 表示名やメールアドレスを誤って設定する |
| 5 | User Groupsを有効化し、ポリシーグループとメンバーを作成する | デフォルトグループを高権限にしてしまう |
| 6 | アドレスプールを各グループに関連付ける | どのグループにもプールがない構成にする |
| 7 | NSG、Azure Firewall、アプリ側IP制限を更新する | VPN側だけ変更して到達制御を更新しない |
| 8 | テストユーザーで接続し、割当IP・到達先・ログを確認する | 複数グループ所属時の優先順位を未検証 |
| 9 | 本番ユーザーへ段階展開する | Azure VPN Clientや構成プロファイルの更新漏れ |
Azure portalでは、Point-to-site configurationのUser Groupsタブから機能を有効化し、ポリシーグループ、ポリシーメンバー、アドレスプールを設定して保存する流れです。Microsoft Learnでは、User Groupsは既定で無効であり、利用前にEnableを選択する手順が示されています。(Microsoft Learn)
設計例：部門別にP2Sアクセスを分離する
たとえば、Finance、Engineering、Vendorの3種類のユーザーを分けたい場合、次のような設計が考えられます。
| グループ | 判定条件の例 | IPアドレスプール | 許可する通信 |
|---|---|---|---|
| Finance | EntraグループのObject ID | 10.50.10.0/24 | 会計DB、経費精算システム |
| Engineering | EntraグループのObject ID | 10.50.20.0/24 | 開発VM、検証DB、CI/CD関連 |
| Vendor | 証明書CNまたはRADIUS属性 | 10.50.30.0/24 | 指定サーバーの保守ポートのみ |
| Default | 条件不一致 | 10.50.99.0/24 | 原則拒否、必要最小限の案内先のみ |
この設計では、P2S VPNへの接続可否は認証で制御し、接続後の到達範囲はIPアドレスプールとFirewall/NSGで制御します。たとえば、Finance用のサブネットやDBには10.50.10.0/24からの通信のみ許可し、Vendor用の10.50.30.0/24からは特定ポートだけを許可します。
ここで避けたいのは、「VPNに接続できるユーザーは社内ネットワークの大半にアクセスできる」という設計です。P2S VPNは便利な反面、境界を曖昧にすると横展開リスクが高まります。User Groups and IP address poolsは、その境界をIP設計に落とし込むための機能として使うと効果的です。
移行・運用時に注意すべきポイント
既存のP2S接続は自動で安全になるわけではない
GAになっても、既存のP2Sユーザーが自動的に部門別IPプールへ分かれるわけではありません。User Groupsを有効化し、グループ、メンバー、アドレスプール、アクセス制御ルールを設計して初めて効果が出ます。
特に、NSGやAzure Firewallが旧P2Sアドレスプールだけを許可している場合、新しいプールからの通信が拒否される可能性があります。逆に、広い範囲を許可したままでは、グループを分けた意味が薄くなります。
複数グループ所属時は優先順位で決まる
ユーザーが複数の条件に一致する場合、数値が小さい優先順位のグループが先に評価されます。Microsoft Learnでも、複数グループに該当するユーザーは、より低い数値の優先順位を持つグループとして扱われると説明されています。(Microsoft Learn)
たとえば、あるユーザーが「Engineering」と「Privileged Admin」の両方に所属している場合、どちらのIPプールを割り当てるかを優先順位で明確にしておく必要があります。特権管理者用のルールを作るなら、一般部門グループより優先されるように設計するのが自然です。
Entra IDの外部ユーザーはデフォルトグループ落ちに注意する
外部ユーザーをP2S VPNに接続させる場合は、Microsoft Entra ID上のユーザータイプや名前の設定に注意が必要です。Microsoft Learnでは、外部ユーザーが接続する場合、ユーザータイプをGuestではなくMemberにし、Nameをメールアドレスに設定する必要があると説明されています。設定が正しくない場合、デフォルトグループに割り当てられる可能性があります。(Microsoft Learn)
外部委託先を扱う環境では、デフォルトグループに広いアクセス権を与えないことが特に重要です。
Azure VPN Clientと接続プロファイルの更新も確認する
トラブルシューティング項目では、Azure VPN ClientでMultipoolを有効化できない場合、ユーザーデバイスにインストールされているAzure VPN Clientを最新にし、クライアントを再ダウンロードするよう案内されています。(Microsoft Learn)
クライアント配布をIntuneや社内ポータルで管理している場合は、VPN Gateway側の設定変更だけでなく、クライアントバージョン、VPNプロファイル、利用者向け手順書も更新対象に含めてください。
RADIUS連携ではVSAの値を正確にそろえる
RADIUS認証では、MS-Azure-Policy-IDというVendor-Specific Attributeがユーザーグループ判定に使われます。値はRADIUSサーバー側とAzure側で一致している必要があり、Microsoft LearnではVSA値が16進オクテット文字列で、6ad1bdから始まる必要があると説明されています。(Microsoft Learn)
RADIUS/NPSを使っている環境では、Azure側だけでなくNPSポリシー、条件、Access-Acceptに含まれる属性まで確認してください。設定後は、想定したVSAが返っているかをNPSログやパケットキャプチャで検証すると原因切り分けがしやすくなります。
管理者向けチェックリスト
本番展開前に、少なくとも次の項目を確認してください。
| チェック項目 | 確認ポイント |
|---|---|
| P2S VPN Gatewayの前提 | P2S構成、認証方式、Gateway SKU、既存アドレスプールを確認 |
| グループ設計 | 部門だけでなく、権限レベル・外部委託・管理者を分ける |
| デフォルトグループ | 最小権限にし、誤割当時の影響を小さくする |
| アドレス設計 | VNet、Virtual Hub、オンプレミス、他VPNプールと重複しない |
| Entra設定 | グループ名ではなくObject IDを使う |
| 証明書設定 | Common Nameの値とグループ判定条件を一致させる |
| RADIUS設定 | MS-Azure-Policy-IDのVSA値をAzure側と一致させる |
| アクセス制御 | NSG、Azure Firewall、アプリ側IP制限を新プールに合わせて更新 |
| クライアント | Azure VPN Client、VPNプロファイル、利用者手順を更新 |
| 監査 | 割当IP、ユーザーID、接続ログ、アプリログを突合できるようにする |
よくある誤解
VPN Gatewayだけでユーザー単位の認可が完結するわけではない
この機能は、P2Sユーザーをグループ別IPアドレスプールに分ける機能です。アプリケーションの権限管理、Azure RBAC、データベース権限の代替ではありません。
「Finance用IPプールからは会計DBに接続できる」というネットワーク制御はできますが、「会計DB内のどのテーブルを参照できるか」は別の認可レイヤーで制御する必要があります。
ユーザーごとの固定IP割り当て機能ではない
名称から「ユーザーごとに固定IPを割り当てられる」と誤解しやすいですが、基本はユーザーグループごとのアドレスプール割り当てです。個人単位の追跡は、VPN認証ログやEntra IDログと組み合わせて行うべきです。
グループを細かく分けすぎると運用が難しくなる
アクセス制御を厳密にしようとして、部署、役職、プロジェクト、委託先ごとに細かく分けすぎると、アドレス設計とFirewallルールが複雑になります。最初は「一般ユーザー」「開発者」「管理者」「外部委託先」「デフォルト隔離」程度の実効性のある分類から始め、必要に応じて分割する方が運用しやすくなります。
まず取るべき次の行動
Azure VPN GatewayでP2S VPNを運用している場合は、まず現在のクライアントアドレスプールとアクセス許可ルールを棚卸ししてください。そのうえで、リモートユーザーを「同じネットワーク権限で扱ってよい単位」に整理します。
特に確認すべきなのは、外部委託先、特権管理者、開発者、一般ユーザーが同じP2S IP範囲で扱われていないかです。同じ範囲に入っている場合、今回GAとなったUser Groups and IP address poolsを使うことで、接続後のアクセス制御をより安全に設計できます。
導入時は、デフォルトグループを最小権限にすること、アドレスプールの重複を避けること、複数グループ所属時の優先順位をテストすることが重要です。VPN接続を許可するだけでなく、「接続した後にどこまで到達できるか」を明確にすることが、今回のAzure Networking更新を活かす最大のポイントです。
コメント