2026年5月20日に更新されたAzure Networkingの公式ドキュメントでは、Network Security Perimeterの提供範囲が明確化されました。結論からいうと、Network Security PerimeterはすべてのAzureパブリッククラウドリージョンに加え、Azure Governmentリージョンでも利用可能であることが明記されています。対象となるのは、US Gov Virginia、US Gov Texas、US Gov Arizona、US DoD East、US DoD Centralです。(Microsoft Learn)
ただし、これは「すべてのPaaSサービスがAzure Governmentでそのまま使える」という意味ではありません。管理者や開発者がまず確認すべきなのは、対象クラウド、リージョン、オンボード済みPaaSサービス、アクセスモード、診断ログ、既存のファイアウォール設定との関係です。特にEnforcedモードへ移行する場合、許可ルールが不足していると業務アプリや監視連携が停止する可能性があります。
今回のAzure Networking更新で何が変わったか
今回の更新は、脆弱性対応や緊急パッチではなく、Network Security Perimeterの利用可能なクラウド環境を明確にするドキュメント更新です。
GitHubのMicrosoftDocs PRでは、当初「Azure Fairfax cloud」を含める趣旨の説明がありましたが、最終的に公開ドキュメントでは「Azure Government regions」として、対象リージョン名まで具体的に整理されています。PRの差分では、従来の「all Azure public cloud regions」という記述に、Azure Governmentリージョンが追加されています。(GitHub)
| 確認項目 | 更新前の読み取り方 | 更新後の読み取り方 |
|---|---|---|
| 提供範囲 | すべてのAzureパブリッククラウドリージョン | すべてのAzureパブリッククラウドリージョンに加え、指定されたAzure Governmentリージョン |
| 対象リージョン | Public cloud中心に判断 | US Gov Virginia、US Gov Texas、US Gov Arizona、US DoD East、US DoD Centralも確認対象 |
| 実務上の影響 | Government環境では可否判断が曖昧になりやすい | Government環境でもNSPを設計候補に入れやすくなる |
| 注意点 | サービス別対応状況の確認が必要 | Governmentで利用できないオンボード済みサービスもあるため、個別確認が必須 |
Network Security Perimeterとは
Network Security Perimeterは、Azure Storage、Azure Key VaultなどのPaaSリソースに対して、論理的なネットワーク境界を作るAzure Networkingの機能です。仮想ネットワークの外部に配置されるPaaSリソースのパブリックアクセスを制御し、明示的な受信・送信ルールによって必要な通信だけを許可します。(Microsoft Learn)
従来、PaaSごとにファイアウォール、許可IP、Private Endpoint、Trusted servicesなどを個別に管理している環境では、設定が分散しやすくなります。Network Security Perimeterを使うと、複数のPaaSリソースを境界に関連付け、プロファイルとアクセスルールで一元的に管理できます。
主な構成要素は次のとおりです。
| 構成要素 | 役割 |
|---|---|
| Network security perimeter | PaaSリソースを保護する論理境界 |
| Profile | 関連付けられたリソースに適用するアクセスルールのまとまり |
| Access rule | 境界外との受信・送信通信を許可するルール |
| Resource association | PaaSリソースを境界に参加させる関連付け |
| Diagnostics settings | 監査・分析用のログやメトリック収集設定 |
重要なのは、Network Security PerimeterがNSGやAzure Firewallの置き換えではない点です。NSGは主に仮想ネットワーク内の通信制御、Azure Firewallはネットワーク境界のトラフィック制御に使われます。一方、Network Security PerimeterはPaaSリソースのパブリックネットワークアクセスを、リソース単位・境界単位で制御するための仕組みです。
影響範囲：Azure Government利用者は特に確認が必要
今回の更新で最も影響を受けるのは、Azure Government環境でPaaSのネットワーク制御を設計している管理者です。
公式ドキュメントでは、Network Security PerimeterはすべてのAzureパブリッククラウドリージョンと、Azure GovernmentのUS Gov Virginia、US Gov Texas、US Gov Arizona、US DoD East、US DoD Centralで利用可能とされています。(Microsoft Learn)
ただし、Network Security Perimeter自体の提供範囲と、各PaaSサービスの対応状況は分けて考える必要があります。英語版の公式表では、オンボード済みPrivate LinkリソースごとにPublic cloud availabilityとGov Cloud availabilityが示されています。(Microsoft Learn)
| サービス | Public cloud | Gov Cloud | 実務上の見方 |
|---|---|---|---|
| Azure Monitor | 一般提供 | 未提供 | Government環境で監視用途に使う場合は代替設計を確認 |
| Azure AI Search | 一般提供 | 未提供 | 検索基盤をGovernmentで構成する場合は対象外 |
| Cosmos DB | パブリックプレビュー | 未提供 | 本番適用は慎重に判断 |
| Event Hubs | 一般提供 | 未提供 | ログ連携やイベント連携の設計に注意 |
| Key Vault | 一般提供 | 一般提供 | Government環境での候補になりやすい |
| SQL DB | パブリックプレビュー | 未提供 | 本番ワークロードでは制約確認が必要 |
| Storage | 一般提供 | 一般提供 | Government環境で特に確認価値が高い |
| Azure OpenAI Service | パブリックプレビュー | 未提供 | NSP前提の本番設計には向きにくい |
| Microsoft Foundry | 一般提供 | 一般提供 | 対象リソース種別を個別に確認 |
| Azure Service Bus | 一般提供 | 未提供 | メッセージング基盤では別方式も検討 |
Cosmos DB、SQL DB、Azure OpenAI ServiceはNetwork Security Perimeterに関してパブリックプレビュー扱いです。公式ドキュメントでは、プレビューはSLAなしで提供され、本番ワークロードには推奨されない旨が記載されています。(Microsoft Learn)
管理者が確認すべき設定ポイント
対象リージョンとクラウド環境を棚卸しする
最初に確認すべきなのは、対象リソースがどのクラウド環境にあるかです。
Azureパブリッククラウドのリソースであれば、今回の更新によって運用が大きく変わるケースは多くありません。一方、Azure Government環境では、これまで「使えるのか分かりにくい」と判断を保留していた設計に対して、Network Security Perimeterを選択肢に入れられる可能性があります。
ただし、次の環境を混同しないようにしてください。
| 環境 | 今回の更新で確認すべきこと |
|---|---|
| Azureパブリッククラウド | 既存のNSP設計、対応サービス、Enforced移行計画を再確認 |
| Azure Government | 対象リージョンとGov Cloud availabilityを確認 |
| Azure Chinaなどその他のナショナルクラウド | 今回の記述だけで利用可能と判断しない |
| ハイブリッド環境 | Public cloudとGovernment間で同一テンプレートを流用しない |
特にIaCテンプレートやAzure Policyで許可リージョンを制限している場合、Governmentリージョンを追加するかどうかを明示的に判断する必要があります。
TransitionモードとEnforcedモードを混同しない
Network Security Perimeterでは、PaaSリソースを境界に関連付ける際にアクセスモードを設定します。公式ドキュメントでは、accessModeの値としてTransitionとEnforcedが説明されています。(Microsoft Learn)
| アクセスモード | 特徴 | 使いどころ |
|---|---|---|
| Transition | NSPルールを評価しつつ、必要に応じて既存のリソースファイアウォール設定にフォールバックする | 既存環境のアクセスパターン把握、移行前検証 |
| Enforced | NSPのアクセスルールに従って通信を制御する | 本番で境界制御を有効化する段階 |
いきなりEnforcedモードにすると、既存の許可IP、Trusted services、リソース側ファイアウォール設定に依存していた通信が遮断される可能性があります。既存ワークロードでは、まずTransitionモードで診断ログを有効化し、実際に必要な受信元・宛先を確認してからEnforcedへ移行するのが安全です。
publicNetworkAccessの値を確認する
新規リソースをNetwork Security Perimeterへ組み込む場合、publicNetworkAccessの状態も重要です。公式ドキュメントでは、SecuredByPerimeterを設定すると、リソースが境界に関連付けられていない状態でもパブリックアクセスがロックダウンされ、構成済みのPrivate Linkトラフィックのみ許可されると説明されています。(Microsoft Learn)
実務では、次のように使い分けます。
| 状態 | 判断基準 |
|---|---|
| Enabled | 既存運用との互換性を重視する場合。ただし公開範囲の確認が必須 |
| Disabled | パブリック受信を使わないリソースで有効 |
| SecuredByPerimeter | 新規構築で「境界に入る前から公開しない」方針を徹底したい場合 |
新規のStorage AccountやKey VaultをGovernment環境で作成する場合、後から公開状態を閉じるより、最初からSecuredByPerimeterを前提に設計する方が設定漏れを減らせます。
開発者が注意すべき通信と認証
SASトークン依存の通信は見直す
公式ドキュメントでは、境界内トラフィックおよびサブスクリプションベースの受信アクセスルールは、Shared Access Signature、つまりSASトークンによる認証をサポートしないとされています。該当するシナリオではSASトークンを使った要求が拒否されるため、リソースに応じた別の認証方法を使う必要があります。(Microsoft Learn)
開発者は、次のようなコードや設定を確認してください。
| 確認対象 | 見直しポイント |
|---|---|
| Storageへのアップロード処理 | SAS URL前提の処理がないか |
| バッチ処理 | 一時的なSASでリソース間連携していないか |
| 外部連携 | サブスクリプションベースの許可ルールとSASを組み合わせていないか |
| CI/CD | デプロイ後の接続確認がSAS前提になっていないか |
境界内のリソース間通信では、マネージドIDとRBACを使う設計に寄せる方が、Network Security Perimeterとの相性は良くなります。
アウトバウンド通信はFQDN単位で棚卸しする
Network Security Perimeterでは、受信ルールとしてサブスクリプションベース、IPベースのルールがサポートされ、送信ルールとしてFQDNベースのルールがサポートされています。(Microsoft Learn)
開発チームは、アプリケーションが外部API、監視基盤、通知先、SaaS、パッケージ取得先などへ通信していないか確認しましょう。特にEnforcedモード移行後は、「アプリは起動するが外部連携だけ失敗する」という障害が起きやすくなります。
確認すべき代表例は次のとおりです。
| 通信先 | 確認例 |
|---|---|
| 外部API | 決済、認証、業務SaaSのFQDN |
| 監視・通知 | Webhook、メール通知、ログ転送先 |
| データ連携 | ETL、外部ストレージ、イベント送信先 |
| 開発・運用 | CI/CD、パッケージ取得、メンテナンス用接続 |
移行・展開時の安全な進め方
既存環境にNetwork Security Perimeterを導入する場合は、「作ってすぐEnforced」ではなく、段階的に移行します。
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 1 | 対象PaaSリソースを棚卸しする | 対応していないサービスまで対象に含める |
| 2 | Public cloud/Gov Cloudの対応状況を確認する | NSP自体の提供範囲とサービス別対応を混同する |
| 3 | Profile設計を決める | 業務単位ではなく場当たり的にルールを作る |
| 4 | Transitionモードで関連付ける | ログを有効化せず、必要通信を把握できない |
| 5 | 受信・送信アクセスルールを作成する | 一時対応の広すぎる許可が残る |
| 6 | マネージドIDとRBACを確認する | 境界内通信が認証で失敗する |
| 7 | 検証後にEnforcedへ切り替える | 本番切り替え直後に監視・バックアップ・連携が止まる |
移行前には、少なくとも次の観点でテストを行ってください。
- アプリケーションからPaaSへの通常アクセス
- PaaS同士のリソース間通信
- 管理者端末や運用ネットワークからのアクセス
- 監視ログの収集
- バックアップやレプリケーションなどの周辺機能
- CI/CDによるデプロイと設定変更
ログ、Sentinel、Backupまわりの注意点
Network Security Perimeterの導入では、アクセス制御だけでなくログ設計も重要です。
公式ドキュメントでは、Network Security Perimeterのアクセスログを有効にする場合、関連付けるLog AnalyticsワークスペースはAzure Monitorでサポートされるリージョンに配置する必要があるとされています。また、PaaSリソースログでは、Log Analytics Workspace、Storage、Event Hubなどのログ宛先を、対象PaaSリソースと同じ境界に関連付ける必要があります。(Microsoft Learn)
さらに、Microsoft Sentinelが有効なLog AnalyticsワークスペースではNetwork Security Perimeterがサポートされず、ワークスペースでNSPを有効化すると分析ルールが自動的に無効になると記載されています。Storage Accountについては、Azure BackupがNetwork Security Perimeter有効時にサポートされないため、バックアップを利用している、または利用予定があるStorage Accountは関連付けないことが推奨されています。(Microsoft Learn)
| 項目 | 注意点 |
|---|---|
| Log Analytics | 対応リージョンと境界への関連付けを確認 |
| Microsoft Sentinel | Sentinel有効ワークスペースではNSP非対応 |
| Storage + Azure Backup | Backup利用中または予定ありならNSP関連付けを避ける |
| Event Hub/Storageへのログ出力 | ログ宛先も同じ境界に入れる必要がある |
| 監査ログ | Transition期間中に通信パターンを必ず確認 |
Private EndpointとService Endpointの扱い
Network Security PerimeterはPrivate Linkを不要にする機能ではありません。公式ドキュメントでは、Private Link経由のアクセスはNetwork Security Perimeterの影響を受けないと説明されています。(Microsoft Learn)
一方で、Service Endpointトラフィックはサポートされておらず、IaaSからPaaSへの通信にはPrivate Endpointの利用が推奨されています。受信ルールで0.0.0.0/0を許可していても、Service Endpointトラフィックが拒否される可能性がある点にも注意が必要です。(Microsoft Learn)
実務では、次のように整理すると判断しやすくなります。
| 通信パターン | 推奨される考え方 |
|---|---|
| VNet内のVMやAKSからPaaSへ接続 | Private Endpointを優先 |
| PaaS間の境界内通信 | NSPとマネージドIDを組み合わせる |
| 境界外の特定クライアントから受信 | IPまたはサブスクリプションベースの受信ルールを検討 |
| PaaSから外部FQDNへ送信 | FQDNベースの送信ルールを定義 |
| Service Endpoint前提の既存構成 | Private Endpointへの移行可否を確認 |
スケール制限と命名ルールも事前に見る
大規模環境では、Network Security Perimeterの制限に早めに気付けるかどうかが重要です。
公式ドキュメントでは、サブスクリプションあたりNetwork Security Perimeterは推奨上限100、PerimeterあたりProfileは推奨上限200、Profileあたりのルール要素は受信・送信それぞれハードリミット200、同一Perimeterに関連付けられるPaaSリソースはサブスクリプション横断で推奨上限1000とされています。(Microsoft Learn)
| 制限 | 目安 |
|---|---|
| Network Security Perimeter数 | サブスクリプションあたり最大100が推奨上限 |
| Profile数 | Perimeterあたり最大200が推奨上限 |
| ルール要素数 | Profileあたり受信・送信それぞれ最大200がハードリミット |
| 関連付けPaaSリソース数 | 同一Perimeterで最大1000が推奨上限 |
| リソース名 | Azureポータル作成の関連付けでは、元リソース名を44文字以内に抑える必要がある場合あり |
小規模なPoCでは問題にならなくても、部門別・環境別・リージョン別にProfileを増やすと、ルール数がすぐに膨らみます。設計段階で「アプリごと」「データ分類ごと」「環境ごと」のどれをProfile分割基準にするか決めておくと、後から運用しやすくなります。
よくある誤解と判断基準
Azure Governmentで全サービスが使えるわけではない
今回の更新は、Network Security Perimeterの提供範囲にAzure Governmentリージョンが含まれることを明確化したものです。各PaaSサービスのGov Cloud対応状況は別表で確認する必要があります。StorageやKey VaultはGovernmentでも一般提供とされていますが、Azure Monitor、Azure AI Search、Event Hubs、Azure Service Busなどは記事作成時点の公式表ではGov Cloud未提供です。(Microsoft Learn)
Transitionモードは保護完了ではない
Transitionモードは、既存アクセスを把握しながら移行するためのモードです。既存のリソースファイアウォール設定にフォールバックするため、Enforcedモードと同じ保護状態ではありません。(Microsoft Learn)
広すぎる許可ルールは後で技術的負債になる
移行時に障害を避けるため、一時的に広い許可を入れたくなる場面があります。しかし、IP範囲やFQDNを広く許可しすぎると、Network Security Perimeterを導入する目的であるデータ流出対策が弱くなります。Transition期間中にログを確認し、必要な通信だけを絞り込む運用が重要です。
日本語ドキュメントだけで判断しない
記事作成時点では、英語版のNetwork Security Perimeter概念ページは2026年5月20日更新と表示され、Azure Governmentリージョンの記述が反映されています。一方、日本語版ページでは最終更新日が2026年4月20日と表示される場合があり、更新反映に差が出ることがあります。最新の提供範囲を確認する場合は、英語版のMicrosoft Learnも併せて確認するのが安全です。(Microsoft Learn)
まず取るべき対応
今回のAzure Networkingドキュメント更新を受けて、管理者や開発者がすぐに行うべきことは次の4つです。
1つ目は、Azure Governmentを含む対象環境で、Network Security Perimeterを使いたいPaaSリソースを棚卸しすることです。2つ目は、公式表でサービス別のPublic cloud availabilityとGov Cloud availabilityを確認することです。3つ目は、既存リソースをいきなりEnforcedにせず、Transitionモードと診断ログで通信パターンを把握することです。4つ目は、Private Endpoint、マネージドID、RBAC、ログ宛先、バックアップ要件を含めて、運用全体で破綻しない設計にすることです。
Network Security Perimeterは、PaaSのパブリックアクセス管理を一元化し、データ流出リスクを下げる有力な選択肢です。今回の更新により、Azure Government環境でも検討しやすくなりましたが、サービス別対応状況や移行手順を飛ばすと、可用性に影響します。まずは対象リソースを洗い出し、Transitionモードでログを取り、必要な通信だけをルール化してからEnforcedへ移行するのが現実的な進め方です。
コメント