Azure NetworkingでPaaSリソースの公開アクセス制御を見直している管理者にとって、今回のポイントは明確です。Azure Network Security Perimeterは、Azure StorageやAzure Key VaultなどのPaaSリソースを論理的な境界内に置き、境界外とのパブリック通信を明示的なルールで制御する仕組みです。2026年5月20日に更新されたMicrosoft Learnの公式情報では、全Azureパブリッククラウドリージョンおよび一部のAzure Governmentリージョンで一般提供されていること、対応サービス、アクセスモード、制約事項が整理されています。(Microsoft Learn)
実務で最も重要なのは、Enforcedモードへ急に切り替えないことです。Enforcedモードでは、同一境界内の通信などを除き、PaaSリソースへのパブリック受信・送信が既定で拒否されます。既存環境では、まずTransitionモードで通信パターンを把握し、診断ログを確認しながらアクセスルールを整備してから段階的に適用するのが安全です。(Microsoft Learn)
Azure Network Security Perimeterとは
Azure Network Security Perimeterは、仮想ネットワークの外側にデプロイされるAzure PaaSリソースに対して、論理的なネットワーク境界を作るAzure Networkingの機能です。対象になるのは、Azure Storage、Azure Key Vault、Event Hubs、Service Bus、Azure Monitorなど、Private Linkに対応する一部のPaaSサービスです。(Microsoft Learn)
従来、PaaSリソースの公開アクセス制御は、各リソースのファイアウォール、Private Endpoint、信頼されたAzureサービス、IP制限などを個別に組み合わせて設計することが一般的でした。Network Security Perimeterを使うと、複数のPaaSリソースを「同じ信頼境界」に参加させ、境界外との通信だけを明示的なルールで許可できます。
ただし、Network Security Perimeterは仮想ネットワーク内のNSGやAzure Firewallの置き換えではありません。IaaSからPaaSへの安全な接続にはPrivate Endpointの利用が引き続き重要で、公式情報でもPrivate EndpointトラフィックはNetwork Security Perimeterの影響を受けないと説明されています。(Microsoft Learn)
2026年5月20日更新で押さえるべき変更点
公式ドキュメントの更新で管理者が特に確認すべきなのは、一般提供範囲、対応サービス、Enforcedモード時の既定動作、制約事項です。
| 確認項目 | 公式情報の要点 | 実務への影響 |
|---|---|---|
| 提供リージョン | 全Azureパブリッククラウドリージョンと、US Gov Virginia、US Gov Texas、US Gov Arizona、US DoD East、US DoD Centralで一般提供 | 本番導入を検討しやすくなったが、サービスごとの対応状況は別途確認が必要 |
| 既定の移行モード | リソース関連付け時の既定はTransitionモード | いきなり通信を遮断せず、既存通信をログで把握しながら移行できる |
| Enforcedモード | 明示的なAllowルールがないパブリック通信は既定で拒否 | 既存アプリ、運用ツール、外部連携が停止する可能性がある |
| アクセスルール | 受信はサブスクリプション単位またはIPベース、送信はFQDNベース | 「どこから来るか」「どこへ出るか」を棚卸しする必要がある |
| Private Link | Private Link経由のアクセスはNetwork Security Perimeterの影響を受けない | 重要な本番経路はPrivate Endpointへ寄せる設計が有効 |
| Service Endpoint | Service Endpointトラフィックはサポートされない | 既存のService Endpoint依存環境では移行設計に注意が必要 |
Network Security Perimeterのアクセスルールは、受信ではサブスクリプションベースまたはIPベース、送信ではFQDNベースをサポートします。一方で、Service Endpointトラフィックはサポートされず、Private Endpointの利用が推奨されています。(Microsoft Learn)
対応サービスと影響範囲
Network Security Perimeterは、すべてのAzure PaaSサービスに一律で適用できる機能ではありません。2026年5月20日時点の公式情報では、対応済みのPrivate LinkリソースとしてAzure Monitor、Azure AI Search、Cosmos DB、Event Hubs、Key Vault、SQL DB、Storage、Azure OpenAI Service、Microsoft Foundry、Service Busが挙げられています。ただし、サービスごとに一般提供かパブリックプレビューか、Government Cloudで利用できるかが異なります。(Microsoft Learn)
| サービス | パブリッククラウドでの状態 | 注意点 |
|---|---|---|
| Azure Storage | 一般提供 | Azure Backup利用中のStorage Accountでは制約に注意 |
| Azure Key Vault | 一般提供 | 秘密情報・証明書・キーへのアクセス経路を事前に棚卸しする |
| Event Hubs / Service Bus | 一般提供 | アプリケーションの送受信元、監視、運用ツールの接続を確認 |
| Azure Monitor | 一般提供 | Log Analytics WorkspaceとMicrosoft Sentinelの組み合わせに注意 |
| Azure AI Search | 一般提供 | 検索インデックス更新元や外部連携元を確認 |
| Microsoft Foundry | 一般提供 | 利用リージョンと対象リソースの種類を確認 |
| Cosmos DB / SQL DB / Azure OpenAI Service | パブリックプレビュー | 本番ワークロードへの適用は慎重に判断 |
公式情報では、Cosmos DB、SQL DB、Azure OpenAI ServiceのNetwork Security Perimeter対応はパブリックプレビューとされています。プレビュー機能はSLAがなく、本番ワークロードには推奨されないため、検証環境で動作確認を行い、制約を理解してから採用可否を判断するべきです。(Microsoft Learn)
TransitionモードとEnforcedモードの違い
Network Security Perimeterの導入で失敗しやすいのは、TransitionモードとEnforcedモードの違いを十分に理解しないまま本番リソースへ適用するケースです。
| モード | 動作 | 使うべき場面 |
|---|---|---|
| Transitionモード | Network Security Perimeterの設定を評価しつつ、該当ルールがない場合は既存のリソース側ファイアウォール設定にフォールバックする | 既存リソースの通信パターン調査、ルール不足の洗い出し |
| Enforcedモード | リソースはNetwork Security Perimeterのアクセスルールのみに従う | ルール整備後の本番適用、公開アクセスの厳格な制御 |
Transitionモードは、以前Learning modeと呼ばれていたモードです。既存のPaaSリソースをNetwork Security Perimeterへ参加させても、ただちに既存通信を遮断するのではなく、ログを使って不足しているアクセスルールや不要な通信を把握できます。(Microsoft Learn)
Enforcedモードでは、PaaSリソースのパブリック受信・送信は既定で拒否され、明示的に一致するNetwork Security Perimeterアクセスルールがある通信だけが許可されます。信頼されたAzureサービスによるアクセスはEnforcedモードではサポートされないため、従来の「trusted access」に依存していた設計は見直しが必要です。(Microsoft Learn)
管理者が最初に確認すべき設定
Network Security Perimeterを導入する前に、Azure管理者は対象リソースの一覧化だけでなく、既存の通信経路、認証方式、ログ出力先まで確認する必要があります。
| 確認項目 | 見るべき場所 | 判断基準 |
|---|---|---|
| 対象PaaSリソース | サブスクリプション、リソースグループ、Private Link対応リソース | 公式の対応サービスに含まれるか |
| publicNetworkAccess | 各PaaSリソースの公開ネットワークアクセス設定 | Enabled、Disabled、SecuredByPerimeterのどれで運用するか |
| accessMode | Network Security Perimeterの関連付け設定 | 既存環境はTransitionから始める |
| 受信ルール | IPアドレス範囲、サブスクリプション | 管理端末、CI/CD、外部サービスの接続元を洗い出す |
| 送信ルール | FQDN | アプリが接続する外部API、監視、通知先を洗い出す |
| 診断ログ | Diagnostic settings | Log Analytics、Storage、Event Hubsなどの保存先を決める |
| Private Endpoint | ネットワーク構成 | 重要な本番通信はPrivate Linkへ寄せる |
| Sentinel / Backup | Log Analytics Workspace、Storage Account | 既知の非対応・制約に該当しないか |
特に注意したいのがpublicNetworkAccessのSecuredByPerimeterです。この設定にすると、リソースがNetwork Security Perimeterへ関連付けられていない状態でも公開アクセスはロックダウンされ、構成済みであればPrivate Linkトラフィックのみが許可されます。関連付けを削除した場合の挙動も変わるため、削除やロールバック手順まで事前に確認しておくべきです。(Microsoft Learn)
安全に移行するための推奨手順
既存環境へNetwork Security Perimeterを適用する場合は、以下の順序で進めると、通信断のリスクを下げられます。
| 手順 | 作業内容 | 失敗しやすいポイント |
| -: | —————————————————————– | ——————————————– |
| 1 | 対象PaaSリソースを棚卸しする | プレビュー対応サービスを本番候補に含めてしまう |
| 2 | 既存のファイアウォール、Private Endpoint、Service Endpoint、trusted accessを確認する | trusted accessやService Endpointを前提にした通信を見落とす |
| 3 | Network Security PerimeterとProfileを作成する | 部署単位ではなく、通信要件単位でProfileを分ける |
| 4 | まずTransitionモードで関連付ける | いきなりEnforcedにしてアプリを止める |
| 5 | Diagnostic settingsでアクセスログを有効化する | ログ保存先が同じ境界内にないためログが流れない |
| 6 | ログから必要な受信・送信ルールを作る | 一時的な管理アクセスを恒久ルールにしてしまう |
| 7 | 検証リソースまたは一部リソースだけEnforcedにする | 全リソースを同時に切り替えて原因切り分けが困難になる |
| 8 | 監視しながら段階的に本番展開する | ロールバック時のpublicNetworkAccess設定を確認していない |
診断ログでは、Network Security Perimeterルールで許可・拒否された通信、リソース側ルールで許可・拒否された通信、Private Endpoint経由の許可などをカテゴリ別に確認できます。ログの保存先にはLog Analytics Workspace、Azure Storage、Azure Event Hubsなどを選択できますが、PaaSリソースログの流れを維持するには、ログ保存先を対象リソースと同じNetwork Security Perimeter内に置く必要があります。(Microsoft Learn)
開発者が確認すべき実装上の注意点
Network Security Perimeterはネットワーク管理者だけの機能ではありません。アプリケーション開発者やSREも、接続先、認証方式、SDKの挙動を確認する必要があります。
送信先FQDNをアプリ単位で棚卸しする
OutboundルールはFQDNベースです。たとえば、アプリが外部API、SaaS、監視サービス、メール通知基盤、Webhook、パッケージ取得先へ接続している場合、それらのFQDNを把握しないままEnforcedモードへ移行すると、送信通信が止まる可能性があります。(Microsoft Learn)
実務では、ソースコードだけでなく、環境変数、Key Vault内のシークレット、アプリ設定、CI/CD定義、監視エージェントの設定も確認してください。コードレビューでは見つからない接続先が、運用設定に含まれていることがあります。
SASトークン依存の通信を確認する
公式情報では、境界内通信およびサブスクリプションベースの受信アクセスルールでは、Shared Access Signature、つまりSASトークンによる認証がサポートされないとされています。この条件に該当するリクエストは認証エラーとして拒否されるため、対象リソースでサポートされる別の認証方式を検討する必要があります。(Microsoft Learn)
StorageなどでSASを多用している環境では、短期的には影響範囲の洗い出し、長期的にはMicrosoft Entra IDやマネージドIDを使った認証設計への移行を検討するとよいでしょう。ただし、利用できる認証方式はサービスや機能によって異なるため、個別のPaaSドキュメントで確認が必要です。
同一境界内通信にはマネージドIDを確認する
同じNetwork Security Perimeter内のリソース間通信を安全に成立させるには、マネージドIDの利用が重要です。公式のクイックスタートでも、リソース間のintra-perimeter communicationをサポートするためにManaged Identityの有効化が必要であり、強く推奨されると説明されています。(Microsoft Learn)
たとえば、Key Vaultからシークレットを取得するアプリ、Storageへ書き込む処理、監視データを送る処理では、ネットワーク境界だけでなく「誰がアクセスするのか」というID設計も合わせて確認してください。
SDKやIaCでは権限と名前長に注意する
公式情報では、SDKでリソース関連付けを作成する際に権限エラーが発生する可能性があり、修正までの回避策としてMicrosoft.Network/locations/*/read権限またはCreateOrUpdateAsyncでWaitUntil.Startedを使う方法が示されています。また、Azure portalから作成される関連付け名の形式により、Network Security Perimeterに対応するリソース名は44文字以内に制限されると説明されています。(Microsoft Learn)
命名規則に環境名、システム名、リージョン名、用途名をすべて詰め込んでいる組織では、既存の命名ルールがこの制限に合わない可能性があります。Terraform、Bicep、ARMテンプレート、Azure SDKで展開している場合は、命名規則と権限を事前にテストしてください。
導入を急ぐべき環境、慎重に進めるべき環境
Network Security Perimeterは、PaaSリソースの公開アクセスを統制したい組織にとって有効な選択肢です。一方で、すべての環境に即時適用すべきものではありません。
| 判断 | 環境の例 | 推奨アクション |
|---|---|---|
| 導入を検討しやすい | StorageやKey Vaultなど一般提供済みサービスを使い、Private Endpointとログ基盤が整っている | Transitionモードで検証し、段階的にEnforcedへ移行 |
| 効果が大きい | 複数のPaaSリソースを同一業務システムで利用し、データ持ち出し防止を強化したい | Profile単位で通信要件を整理し、境界外通信を最小化 |
| 慎重に進めるべき | Microsoft Sentinelを有効化したLog Analytics Workspaceを使っている | Network Security Perimeter適用による分析ルールへの影響を確認 |
| 慎重に進めるべき | Azure Backupを有効化したStorage Accountを使っている | Storage AccountをNetwork Security Perimeterへ関連付けない選択肢も検討 |
| 慎重に進めるべき | Service Endpointに依存している | Private Endpointへの移行可否を先に検討 |
| 検証優先 | Cosmos DB、SQL DB、Azure OpenAI Serviceに適用したい | プレビュー扱いのため、本番適用前に制約と代替策を確認 |
公式情報では、Network Security PerimeterはMicrosoft Sentinelが有効なLog Analytics Workspaceではサポートされず、適用すると分析ルールが自動的に無効化されるとされています。また、Network Security Perimeterが有効なStorage AccountではAzure Backupがサポートされないため、バックアップ要件がある環境では特に注意が必要です。(Microsoft Learn)
展開前チェックリスト
本番展開前には、少なくとも次の項目を確認してください。
| チェック | 確認内容 |
|---|---|
| 対象サービス | 公式の対応サービスに含まれ、一般提供かプレビューか確認した |
| リージョン | 利用リージョンでNetwork Security Perimeterが利用可能である |
| 既存通信 | 受信元IP、サブスクリプション、送信先FQDNを棚卸しした |
| Private Endpoint | 重要な本番通信をPrivate Linkへ移行できるか確認した |
| Service Endpoint | Service Endpoint依存の通信がないか確認した |
| trusted access | Enforcedモードで信頼されたAzureサービスに依存しない設計にした |
| SAS | SASトークン依存の処理が影響を受けないか確認した |
| Managed Identity | リソース間通信に必要なマネージドIDを有効化した |
| 診断ログ | Network Security Perimeterのアクセスログを有効化した |
| ログ保存先 | Log Analytics、Storage、Event Hubsなどの保存先が適切な境界内にある |
| Sentinel | Microsoft Sentinel有効化済みWorkspaceへの影響を確認した |
| Backup | Azure Backup対象のStorage Accountを誤って関連付けないよう確認した |
| スケール制限 | サブスクリプションあたりの境界数、Profile数、ルール要素数を確認した |
| 命名規則 | リソース名が44文字制限に抵触しないか確認した |
| ロールバック | 関連付け削除時のpublicNetworkAccess挙動を確認した |
スケール面では、サブスクリプションあたりのNetwork Security Perimeter数、Profile数、ルール要素数、同一境界へ関連付けられるPaaSリソース数に制限があります。大規模環境では、システム単位、データ分類単位、運用責任単位のどれで境界を分けるかを先に設計してください。(Microsoft Learn)
まとめ：まずはTransitionモードとログ確認から始める
Azure Network Security Perimeterは、Azure NetworkingにおけるPaaS公開アクセス制御をより一元的に管理するための重要な機能です。特に、StorageやKey Vaultなどの重要リソースを境界内に置き、外部との通信を明示的に許可する設計は、データ流出リスクの低減に役立ちます。
一方で、Enforcedモードは強力な制御である分、既存アプリや運用ツールの通信を止める可能性があります。まずは対象リソースを棚卸しし、Transitionモードで関連付け、診断ログから実際の通信パターンを確認してください。そのうえで、必要な受信・送信ルールを作り、Private Endpoint、マネージドID、認証方式、ログ保存先を整えてから段階的にEnforcedモードへ移行するのが現実的な進め方です。
次に取るべき行動は、対象サブスクリプション内のStorage、Key Vault、Event Hubs、Service Bus、Azure Monitorなどを一覧化し、「対応サービスか」「Private Endpointはあるか」「Enforcedで止まる通信は何か」を洗い出すことです。そこまで整理できれば、Network Security Perimeterを安全に展開するための移行計画を具体化できます。
コメント