Azure Networkingの「Network Security Perimeter（NSP）」をBicepやAzure Verified Modules（AVM）で管理している場合、今回の更新でまず見るべきポイントは profile と access-rule の子モジュールが公開されたこと です。既存のAzureリソース設定が自動で変更される更新ではありませんが、NSPのプロファイルやアクセスルールをIaCで分離管理しやすくなったため、管理者はモジュール参照、テレメトリ設定、アクセスルールの設計、TransitionからEnforcedへの展開手順を確認しておくべきです。
2026年5月20日にマージされたPRでは、avm/res/network/network-security-perimeter/profile と avm/res/network/network-security-perimeter/profile/access-rule の追加、enableTelemetry パラメータの導入、READMEとCHANGELOGの更新、JSONファイル内のBicep生成バージョン更新が行われています。変更内容はAVMのNetwork Security Perimeterモジュール利用者に関係するもので、Azure Networking全体の脆弱性修正や緊急パッチではなく、NSPをIaCで扱うためのモジュール更新として捉えるのが正確です。(GitHub)
今回のAzure Networking documentation updateで変わったこと
今回の更新は、Azure Network Security Perimeterそのものの概念を変えるものではなく、AVM BicepモジュールでNSPの子リソースを扱いやすくする更新です。特に、これまで親モジュール中心で管理していたプロファイルやアクセスルールを、より細かい単位でデプロイできるようになった点が実務上のポイントです。
| 変更点 | 内容 | 管理者・開発者が確認すべきこと |
|---|---|---|
profile 子モジュールの公開 | avm/res/network/network-security-perimeter/profile が追加され、NSPプロファイルを個別モジュールとして参照可能になりました。(GitHub) | 親NSPは基盤チーム、プロファイルはアプリチームなど、管理単位を分けるか検討する |
profile/access-rule 子モジュールの公開 | avm/res/network/network-security-perimeter/profile/access-rule が追加され、アクセスルールを単体で管理しやすくなりました。(GitHub) | ルール追加・変更だけをCI/CDで反映する運用に使えるか確認する |
enableTelemetry パラメータの導入 | モジュールの使用状況テレメトリを有効・無効にするパラメータが追加されています。単体の子モジュールでは既定値が True と記載されています。(GitHub) | 組織のデータ収集・プライバシーポリシーに合わせて false 指定を標準化するか決める |
| README・CHANGELOGの更新 | 親モジュールは 0.1.4、profile と access-rule は 0.1.0 としてCHANGELOGが更新されています。Breaking Changesはいずれも「None」です。(GitHub) | 既存テンプレートに破壊的変更がない前提でも、バージョン固定と検証環境での展開を行う |
| Bicep生成バージョンの更新 | PRではJSONファイル内のBicepバージョンが 0.43.8 に更新されています。(GitHub) | CI/CDでBicepビルドやARM JSON検証を行う場合、ローカル・パイプラインのBicep CLIバージョンを確認する |
実務上は、「すぐ既存環境を直す必要があるか」よりも、「今後NSPをどうIaC管理するか」を見直す更新です。特に、Azure PaaSのネットワーク境界を中央集権的に管理したい組織では、親モジュールだけで一括管理するか、子モジュールで権限と責任を分けるかを決めるタイミングになります。
Azure Network Security Perimeterとprofile/access-ruleの関係
Azure Network Security Perimeterは、仮想ネットワーク外に配置されるAzure PaaSリソースの周囲に論理的なネットワーク境界を作り、パブリックネットワーク経由のアクセスを明示的なルールで制御する機能です。Microsoft Learnでは、NSPはAzure StorageやAzure Key VaultなどのPaaSリソースに対するパブリックアクセス制御を支援し、境界内リソース間の通信、外部パブリックアクセス管理、アクセスログ、PaaS横断の統一的な管理を主な特徴として説明しています。(Microsoft Learn)
NSPを理解するには、次の4つを分けて考えると整理しやすくなります。
| 構成要素 | 役割 | 実務での見方 |
|---|---|---|
| Network Security Perimeter | PaaSリソースを保護する論理境界の最上位リソース | 「どのシステム境界を作るか」を表す |
| Profile | 関連付けられたリソースに適用するアクセスルールの集合 | 「同じルールを共有するリソース群」を表す |
| Access rule | 境界外との通信を許可するInbound/Outboundルール | 「例外的に許可する外部通信」を表す |
| Resource association | PaaSリソースをNSPのプロファイルに関連付ける設定 | 「どのリソースをどのプロファイルに入れるか」を表す |
Microsoftの概念ドキュメントでも、Profileは関連付けられたリソースに適用されるアクセスルールの集合、Access ruleは境界外アクセスを許可するInbound/Outboundルール、Resource associationはPaaSリソースの境界メンバーシップと説明されています。(Microsoft Learn)
この構造をBicepで管理する場合、今回追加された子モジュールによって、次のような分担がしやすくなります。
| 管理対象 | 利用するモジュール | 向いている運用 |
|---|---|---|
| NSP本体、診断設定、ロック、RBAC、プロファイル、リソース関連付けをまとめて管理 | avm/res/network/network-security-perimeter | 基盤チームがNSP全体を一括管理する |
| 既存NSP配下にプロファイルを追加・更新 | avm/res/network/network-security-perimeter/profile | 共通NSPの中でアプリ単位のプロファイルを作る |
| 既存プロファイルにアクセスルールを追加・更新 | avm/res/network/network-security-perimeter/profile/access-rule | ルール変更だけを申請・承認・展開する |
既存環境への影響範囲
今回のAzure Networking documentation updateは、既存のAzureリソースに即時の動作変更を加えるものではありません。影響が出るのは主に、AVMのBicepモジュールを使ってNSPをデプロイ・更新するタイミングです。
影響を受けやすいケース
次のいずれかに該当するチームは、今回の更新を確認する価値があります。
| 対象 | 確認理由 |
|---|---|
| AVMのNSPモジュールを使っている | 親モジュールのCHANGELOGが 0.1.4 に更新され、子モジュール公開が明記されています。(GitHub) |
Bicep Registryの br/public:avm/... をCI/CDで参照している | バージョン固定、検証環境でのwhat-if、Bicep CLIバージョン確認が必要です |
| NSPのプロファイル・アクセスルールを手書きBicepで管理している | 子モジュールへ置き換えることで、標準化とレビュー容易性を高められます |
| PaaSファイアウォール設定を各サービス個別に管理している | NSPに移行する場合、Transition/Enforcedの移行設計が必要です |
| 組織でテレメトリ送信を制限している | enableTelemetry の既定値と明示設定を確認する必要があります |
影響が限定的なケース
Azure PortalだけでNSPを操作している、またはNSPをまだ導入していない場合、今回のモジュール更新だけで既存通信が変わることは基本的にありません。ただし、今後BicepやCI/CDでNSPを管理する予定があるなら、最初から子モジュールを使う設計にしておくと、運用分担がしやすくなります。
また、これは「セキュリティに関わるモジュール更新」ではありますが、脆弱性修正として急いで適用するタイプの更新ではありません。親モジュールのCHANGELOGではBreaking ChangesはNoneと記載されています。(GitHub)
管理者が確認すべき設定ポイント
enableTelemetry は組織ポリシーに合わせて明示する
今回の更新で重要なのが enableTelemetry です。profile と access-rule のREADMEでは、enableTelemetry はモジュールの利用テレメトリを有効・無効にするパラメータで、単体利用時の既定値は True と記載されています。(GitHub)
AVMのテレメトリ説明では、テレメトリは任意であり、Bicepでは enableTelemetry を false にすることでオプトアウトできると説明されています。(Azure)
セキュリティやコンプライアンスが厳しい環境では、テンプレートごとに判断するのではなく、社内のBicep標準として次のように決めておくと運用がぶれません。
| 方針 | 設定例 | 向いている環境 |
|---|---|---|
| テレメトリを許可する | enableTelemetry: true | MicrosoftのAVM改善に利用状況を提供しても問題ない環境 |
| テレメトリを無効化する | enableTelemetry: false | 金融、公共、社内規定で外部送信を制限する環境 |
| 親モジュールだけで管理する | 親モジュール側で明示 | 子モジュールを直接呼ばず、基盤チームが一括管理する環境 |
ここで注意したいのは、AVMの利用テレメトリとNSPのアクセスログは別物だという点です。enableTelemetry を無効にしても、NSPの診断ログ設計が不要になるわけではありません。通信の許可・拒否を監査するには、NSP側の診断設定を別途設計する必要があります。
Inbound/Outboundアクセスルールで使える属性を確認する
NSPのアクセスルールは、InboundとOutboundで使う属性が異なります。Microsoft LearnのNSP概念ドキュメントでは、サポートされるアクセスルール種別として、InboundはサブスクリプションベースとIPベース、OutboundはFQDNベースが示されています。(Microsoft Learn)
| 方向 | 主に使うパラメータ | 用途例 | 注意点 |
|---|---|---|---|
Inbound | addressPrefixes | 社内固定IPレンジからKey Vaultへアクセスを許可 | CIDR形式で管理し、個人宅IPなど一時的な値を恒久ルールにしない |
Inbound | subscriptions | 特定サブスクリプションのマネージドIDからのアクセスを許可 | 認証方式やマネージドIDの利用条件を確認する |
Outbound | fullyQualifiedDomainNames | PaaSリソースから外部APIのFQDNへの通信を許可 | 宛先FQDNを棚卸しし、過剰に広い許可を避ける |
Access Ruleのテンプレートリファレンスには emailAddresses、phoneNumbers、serviceTags もプロパティとして表示されますが、同じページでこれらのルール種別は現在利用不可と説明されています。実装時は「プロパティがあるから使える」と判断せず、利用可能なルール種別を公式ドキュメントで確認してください。(Microsoft Learn)
Resource associationのaccessModeは移行段階で使い分ける
NSPを既存PaaSに導入する場合、最も事故が起きやすいのは accessMode の切り替えです。Microsoft Learnでは、Transitionは既定モードで、NSP構成に一致しない場合にリソース側のファイアウォール設定へフォールバックできる移行用モード、EnforcedはNSPアクセスルールだけに従うモードと説明されています。(Microsoft Learn)
| モード | 使う場面 | 注意点 |
|---|---|---|
| Transition | 既存通信を観察し、必要なアクセスルールを洗い出す段階 | この段階では完全な保護状態ではない |
| Enforced | 必要なInbound/Outboundルールを確認し終えた本番適用段階 | 許可ルールが不足すると通信断につながる |
古い説明やAPIバージョンではLearningという表記が残る場合があります。NSP概念ドキュメントでもTransition modeは「formerly Learning mode」と説明されています。Bicep、REST API、Azure Portal、SDKで受け付ける値がずれるとデプロイ失敗につながるため、CI/CDでは利用するAPIバージョンと実際の検証結果をセットで確認してください。(Microsoft Learn)
Private Link、Managed Identity、診断ログを混同しない
NSPはパブリックネットワークアクセスの制御に強く関係しますが、Private Link経由のアクセスはNSPの影響を受けないとMicrosoft Learnで説明されています。Enforcedにする前に、どの通信がPrivate Linkで、どの通信がパブリック経由なのかを分けて棚卸しすることが重要です。(Microsoft Learn)
また、NSP内のリソース間通信ではManaged Identityの利用が重要です。クイックスタートでは、境界内またはリンクされた境界間の安全なアクセスを確保するため、Managed Identityの有効化が強く推奨されています。(Microsoft Learn)
診断ログも必須の確認項目です。Transitionモードでログを有効にすると、NSP構成で許可された通信なのか、既存リソース側のファイアウォール設定で許可された通信なのかを分析できます。Enforcedへ移行する前にログを確認しないと、必要なルール不足に気づけません。(Microsoft Learn)
開発者向け：Bicepでの利用イメージ
親モジュールでNSP本体とプロファイル、アクセスルールをまとめて管理する場合は、次のような構成になります。実際のIPアドレス、FQDN、リソース名は自社環境に合わせて置き換えてください。
targetScope = 'resourceGroup'
param location string = resourceGroup().location
module nsp 'br/public:avm/res/network/network-security-perimeter:0.1.4' = {
name: 'deploy-nsp-prod'
params: {
name: 'nsp-prod-001'
location: location
enableTelemetry: false
profiles: [
{
name: 'profile-app'
accessRules: [
{
name: 'allow-corp-in'
direction: 'Inbound'
addressPrefixes: [
'203.0.113.0/24'
]
}
{
name: 'allow-api-out'
direction: 'Outbound'
fullyQualifiedDomainNames: [
'api.contoso.com'
]
}
]
}
]
}
}親モジュールのREADMEでは、profiles 配下に accessRules を指定する例が示され、OutboundではFQDN、InboundではIPアドレスプレフィックスを指定する例が掲載されています。(GitHub)
一方、既存NSPに対してプロファイルだけを追加したい場合は、今回公開された profile 子モジュールを使えます。
module nspProfile 'br/public:avm/res/network/network-security-perimeter/profile:0.1.0' = {
name: 'deploy-nsp-profile-app'
params: {
networkPerimeterName: 'nsp-prod-001'
name: 'profile-app'
enableTelemetry: false
}
}既存プロファイルにアクセスルールだけを追加・更新したい場合は、profile/access-rule 子モジュールを使います。
module outboundRule 'br/public:avm/res/network/network-security-perimeter/profile/access-rule:0.1.0' = {
name: 'deploy-nsp-rule-api'
params: {
networkPerimeterName: 'nsp-prod-001'
networkPerimeterProfileName: 'profile-app'
name: 'allow-api-out'
direction: 'Outbound'
fullyQualifiedDomainNames: [
'api.contoso.com'
]
enableTelemetry: false
}
}profile モジュールでは、スタンドアロン利用時に親NSP名を示す networkPerimeterName が必要です。access-rule モジュールでは、親NSP名に加えて networkPerimeterProfileName が必要です。どちらのREADMEにも、単体モジュールとして br/public:avm/res/network/network-security-perimeter/profile、br/public:avm/res/network/network-security-perimeter/profile/access-rule を参照する形式が示されています。(GitHub)
安全に移行・展開する手順
NSPは通信制御に直結するため、モジュール更新を見つけたからといって本番へ即時反映するのは避けるべきです。特にEnforcedへ移行する場合は、段階的な検証が必要です。
| 手順 | 実施内容 | 判断基準 |
|---|---|---|
| 既存IaCを棚卸しする | avm/res/network/network-security-perimeter、手書きの Microsoft.Network/networkSecurityPerimeters を検索する | 親モジュール管理か子モジュール管理かを分類できる |
| バージョン固定を確認する | 0.1.4 や 0.1.0 など、利用するモジュールバージョンを明示する | CI/CDで意図しないバージョン変更が起きない |
| テレメトリ方針を決める | enableTelemetry を明示し、社内標準に反映する | 本番テンプレートで設定漏れがない |
| 検証環境でwhat-ifを実行する | 既存プロファイル・アクセスルール・関連付けの差分を見る | 予期しない削除や上書きがない |
| Transitionでログを集める | 既存通信を観察し、不足しているInbound/Outboundルールを洗い出す | 必要通信と不要通信を区別できる |
| Enforcedへ切り替える | ルールが揃ったプロファイルから段階的に適用する | 通信断時の切り戻し手順がある |
| 運用監視を定着させる | 診断ログ、変更履歴、ルールレビューを定期運用に入れる | 例外ルールが増え続けない |
Transitionモードは、既存PaaSリソースをNSPへ安全に移行するための段階として説明されています。Microsoft Learnでは、TransitionではNSP構成に一致しない場合に既存のリソースファイアウォール設定へフォールバックでき、診断ログにより不足ルールや不要な接続を分析できるとされています。(Microsoft Learn)
失敗しやすいポイントと回避策
子モジュールを使っても、設計責任は分離しすぎない
profile や access-rule を子モジュール化できると、アプリチームが個別ルールを管理しやすくなります。ただし、各チームが自由にOutbound FQDNを追加し始めると、NSP本来の「境界管理」が形だけになります。
ルール追加は、次の情報をセットでレビューすると実務で破綻しにくくなります。
| レビュー項目 | 確認内容 |
|---|---|
| 通信方向 | InboundかOutboundか |
| 宛先・送信元 | IPレンジ、サブスクリプション、FQDNが過剰に広くないか |
| 認証方式 | Managed IdentityやRBACで認可されているか |
| 期限 | 一時的な例外なのか、恒久ルールなのか |
| 監査 | 診断ログで確認できるか |
Enforcedへの切り替えを急ぎすぎる
Enforcedでは、関連付けられたPaaSリソースのパブリックInbound/OutboundアクセスがNSPアクセスルールに従います。必要なルールが不足していると、アプリケーションの外部API連携、監視連携、運用端末からのアクセスが止まる可能性があります。Microsoft Learnでも、既存リソースではTransitionモードを使い、ログを分析してからEnforcedへ移行する流れが説明されています。(Microsoft Learn)
使えないルール種別を使おうとする
テンプレートリファレンスにプロパティが表示されていても、現在利用不可とされているルール種別があります。特に emailAddresses、phoneNumbers、serviceTags は、Access Ruleのプロパティとして表示される一方で「currently unavailable for use」と説明されています。(Microsoft Learn)
本番テンプレートでは、現時点で利用可能なInboundのIP・サブスクリプション、OutboundのFQDNを中心に設計するのが安全です。
ルール名や設定値に機微情報を入れる
NSPの概念ドキュメントでは、組織および情報保護の観点から、NSPルールや構成に個人情報・機微情報を含めないよう注意されています。(Microsoft Learn)
たとえば、ルール名に顧客名、案件名、個人名、内部システムの詳細すぎる名称を入れるのは避けましょう。allow-crm-out のような機能単位の名前にし、詳細は社内の変更管理チケットに持たせるほうが安全です。
名前長とスケール制限を後回しにする
NSPにはスケール上の制限があります。Microsoft Learnでは、推奨制限としてサブスクリプションあたりNSP最大100、NSPあたりプロファイル最大200、プロファイルあたりInbound/Outboundそれぞれルール要素最大200、同一NSPに関連付けるPaaSリソース最大1000などが示されています。(Microsoft Learn)
また、Azure Portalで作成されるResource Association名の制約により、関連付け対象リソース名は44文字以内に制限される場合があると説明されています。長い命名規則を採用している組織では、NSP導入前にリソース名の設計を見直してください。(Microsoft Learn)
今回の更新を採用すべき判断基準
今回の子モジュール公開は、すべてのチームがすぐ採用すべき更新ではありません。以下のように、運用モデルに合わせて判断するのが現実的です。
| 状況 | 推奨判断 |
|---|---|
| NSP本体からアクセスルールまで基盤チームが一括管理している | 親モジュール中心で継続し、必要に応じて子モジュールを検証する |
| アプリチームごとにプロファイルやルールを分けたい | profile と access-rule 子モジュールの採用を検討する |
| 既存の手書きBicepでアクセスルールだけを管理している | 子モジュールへの移行候補にする |
| 本番でまだNSPを使っていない | 先に対象PaaS、対応状況、Transition運用、ログ設計を確認する |
| Cosmos DB、SQL DB、Azure OpenAI Serviceなどを対象にしたい | サービスごとの提供状態や制約を確認してから採用する |
NSPの概念ドキュメントでは、Azure Monitor、AI Search、Event Hubs、Key Vault、Storage、Foundry、Service Busなど複数のサービスが一般提供として記載される一方、Cosmos DB、SQL DB、Azure OpenAI ServiceはNetwork Security Perimeterに関してパブリックプレビューとして示されています。プレビューはSLAなしで提供され、本番ワークロードには推奨されない場合があるため、対象サービスごとの状態確認が必要です。(Microsoft Learn)
管理者が今すぐ確認するチェックリスト
今回のAzure Networking documentation updateを受けて、まずは次の順で確認すると効率的です。
| チェック項目 | 確認方法 |
|---|---|
| AVMのNSPモジュールを使っているか | Bicep内で avm/res/network/network-security-perimeter を検索する |
| バージョンが固定されているか | br/public:...:<version> の指定を確認する |
| 子モジュールを使う余地があるか | profileやaccess-ruleを別チーム・別パイプラインで管理したいか確認する |
enableTelemetry 方針が明確か | 本番テンプレートで true / false を明示する |
| Inbound/Outboundルールが最小限か | IP、サブスクリプション、FQDNの許可範囲を見直す |
| Transitionのログを見ているか | Enforced移行前に診断ログを確認する |
| Private LinkとPublicアクセスを分けて設計しているか | 通信経路ごとに影響を整理する |
| Resource Association削除時の影響を把握しているか | publicNetworkAccess が SecuredByPerimeter の場合のロックダウンに注意する |
クイックスタートでは、Resource Associationを削除するとアクセス制御が既存リソースのファイアウォール構成に戻る可能性があり、PublicNetworkAccess が SecuredByPerimeter の状態で関連付けを削除するとロックダウン状態になると説明されています。切り戻し手順を作る際は、この点を必ず確認してください。(Microsoft Learn)
まとめ：今回の更新はNSP運用を細かく標準化するための機会
2026年5月20日のAzure Networking documentation updateは、Network Security PerimeterのAVM Bicepモジュールに profile と access-rule の子モジュールを追加する更新です。既存環境を自動で変えるものではありませんが、NSPをIaCで管理する組織にとっては、プロファイルとアクセスルールの運用をより細かく分離・標準化できる意味があります。
管理者は、まず既存Bicepテンプレートのモジュール参照を棚卸しし、バージョン固定、enableTelemetry、アクセスルール種別、TransitionからEnforcedへの移行手順を確認してください。開発者は、親モジュールで一括管理するのか、子モジュールでプロファイル・アクセスルールを分離管理するのかを決め、検証環境でwhat-ifと診断ログ確認を行ってから本番展開するのが安全です。
コメント