2026年5月20日の更新で、Azure App Configuration ストアを Azure Network Security Perimeter（NSP）の管理対象として扱うための Azure CLI サポートが追加されました。重要なのは、単に新しいコマンドが増えたことではありません。App Configuration の公開ネットワークアクセスを、NSPの境界ルールで制御する運用に移行できるようになった点です。(GitHub)
管理者がまず確認すべきことは、既存の App Configuration ストアが public network access、Private Endpoint、CI/CD、アプリ実行環境のどれに依存しているかです。特に --public-network-access SecuredByPerimeter は強力な設定ですが、準備不足のまま適用すると、アプリの起動時設定取得、機能フラグの更新、運用者のポータル確認が失敗する可能性があります。
Azure Networkingの更新で何が変わったか
今回の更新では、Azure CLI の az appconfig に App Configuration 向けの NSP 管理コマンドと、公開ネットワークアクセスを制御する新しいパラメーターが追加されました。PR上では、az appconfig network-security-perimeter-configuration list/show/reconcile の追加、az appconfig create/update --public-network-access の追加、旧 --enable-public-network の非推奨化が明記されています。(GitHub)
| 変更点 | 内容 | 実務上の意味 |
|---|---|---|
| NSP構成の確認コマンド追加 | list、show、reconcile が追加 | App Configuration ストアに関連付く NSP 構成、プロファイル、アクセスモードをCLIで確認しやすくなる |
--public-network-access の追加 | Disabled、Enabled、SecuredByPerimeter を指定可能 | 公開ネットワークからのデータプレーン通信を、従来より明確な値で制御できる |
SecuredByPerimeter の追加 | NSPと関連付ける場合に使う値。CLI上ではプレビュー扱い | 本番適用前に動作確認、ログ確認、ロールバック手順が必要 |
--enable-public-network の非推奨化 | 新しい --public-network-access への移行が推奨される | 自動化スクリプト、Terraform外部実行、Azure DevOps/GitHub Actionsのコマンド見直しが必要 |
| 相互排他チェック | --enable-public-network と --public-network-access の同時指定はエラー | 古いテンプレートと新しい引数が混在するCI/CDで失敗しやすい |
App Configuration の ARM/Bicep/Terraform AzAPI リファレンスでも、publicNetworkAccess の値として Disabled、Enabled、SecuredByPerimeter が示されています。つまり、CLIだけでなくIaCでもこのプロパティを明示する設計に寄せるのが自然です。(Microsoft Learn)
Network Security PerimeterをApp Configurationに適用する意味
Azure Network Security Perimeter は、仮想ネットワーク外に配置されるPaaSリソースの周囲に論理的な境界を作り、境界外とのパブリックな受信・送信通信を明示的なルールで制御する仕組みです。NSPには、境界内リソース同士の通信、外部公開アクセスのルール管理、監査ログ、複数PaaSリソースを横断した一元的な管理といった特徴があります。(Microsoft Learn)
App Configurationで重要なのは、設定値や機能フラグがアプリの起動や実行中の判断に直結する点です。たとえば、App Service、Azure Functions、AKS、VM上のアプリが起動時に App Configuration へ接続できなくなると、アプリ自体はデプロイ済みでも正常に動作しないことがあります。
NSP対応は「App Configurationの認証が不要になる」機能ではありません。Microsoft Entra ID、アクセスキー、RBAC、ローカル認証無効化などの認証・認可とは別に、ネットワーク境界を制御するものです。disableLocalAuth などの認証関連設定は、publicNetworkAccess とは別プロパティとして扱われます。(Microsoft Learn)
影響範囲：管理者・開発者・DevOpsが見るべきポイント
今回の更新はネットワーク管理者だけの話ではありません。App Configuration はアプリケーション設定の中枢になりやすいため、運用チーム、開発チーム、CI/CD担当者が同じ前提で確認する必要があります。
| 対象者 | 確認すべきこと | 放置した場合のリスク |
|---|---|---|
| Azure管理者 | 既存ストアの publicNetworkAccess、Private Endpoint、NSP関連付け、アクセスモード | 公開アクセスを塞いだ後に、正当なアプリや管理者も接続できなくなる |
| ネットワーク/セキュリティ担当 | NSPプロファイル、受信ルール、送信ルール、ログカテゴリ | ルール不足により通信遮断、または過剰許可により境界の意味が薄れる |
| 開発者 | アプリの設定取得タイミング、リトライ、キャッシュ、起動失敗時の動作 | 設定取得エラーがアプリ障害として表面化する |
| DevOps担当 | Azure CLIバージョン、デプロイコマンド、旧引数の使用有無 | --enable-public-network と新引数の混在でパイプラインが失敗する |
| ガバナンス担当 | Azure Policy、Bicep/Terraform、例外申請フロー | ポリシーは準拠しているのに、NSP運用では未整備という状態になる |
App Configuration は Private Endpoint も利用できます。Private Endpointでは、仮想ネットワーク内のプライベートIP経由で App Configuration に接続でき、Microsoftバックボーン上で通信できます。App Configuration の Private Endpoint はSKUごとに上限があるため、StandardやPremiumで複数環境・複数リージョンを扱う場合は、事前に上限も確認してください。(Microsoft Learn)
--public-network-access の値はどう選ぶべきか
--public-network-access は、App Configuration のデータプレーンに対する公開ネットワークアクセスを制御します。今回の更新で、Enabled、Disabled、SecuredByPerimeter をCLIから明示しやすくなりました。(GitHub)
| 値 | 向いているケース | 注意点 |
|---|---|---|
Enabled | 移行前の暫定運用、外部ネットワークからのアクセスが必要な検証環境 | 便利だが、ゼロトラストや境界制御の観点では最小化したい |
Disabled | Private Endpoint経由に限定したい環境 | 管理者端末、CI/CD、アプリ実行基盤がPrivate Link経由で到達できるか確認が必要 |
SecuredByPerimeter | NSPで公開ネットワークアクセスを境界ルールに従って制御したい環境 | CLI上ではプレビュー扱い。関連付けやルールが未整備だと通信断の原因になる |
特に SecuredByPerimeter は慎重に扱うべきです。Azureの移行ドキュメントでは、publicNetworkAccess を SecuredByPerimeter に設定したリソースは、NSPにまだ関連付いていない場合でもロックダウン状態で作成され、Private Linkが構成されていればその通信のみ許可されると説明されています。NSPに関連付けた後は、NSPのアクセスルールが通信可否を決めます。(Microsoft Learn)
まず実行する確認コマンド
最初に、利用しているAzure CLIで新しいコマンドが使えるか確認します。PRは2026年5月20日にマージされていますが、実際に手元のCLIやCloud Shellで利用できるかはリリース状況に依存します。コマンドが見つからない場合は、Azure CLIを更新してから再確認してください。
az --version
az appconfig network-security-perimeter-configuration -h既存の App Configuration ストアの公開ネットワークアクセス設定を確認します。
az appconfig show \
--resource-group <RESOURCE_GROUP> \
--name <STORE_NAME> \
--query "{name:name, publicNetworkAccess:publicNetworkAccess}" \
--output tableNSP構成が関連付いているか確認します。
az appconfig network-security-perimeter-configuration list \
--store-name <STORE_NAME> \
--resource-group <RESOURCE_GROUP> \
--output table特定のNSP構成を詳しく確認する場合は show を使います。
az appconfig network-security-perimeter-configuration show \
--store-name <STORE_NAME> \
--resource-group <RESOURCE_GROUP> \
--name <NSP_CONFIGURATION_NAME>NSP側の関連付けやルール変更後、App Configuration側の有効な構成が古いように見える場合は reconcile を使います。これは指定したNSP構成の更新を強制的に再同期する操作であり、足りないアクセスルールを自動で作るコマンドではありません。App Configuration REST APIでも、NSP構成の Get、List By Configuration Store、Reconcile が 2025-08-01-preview APIとして定義されています。(Microsoft Learn)
az appconfig network-security-perimeter-configuration reconcile \
--store-name <STORE_NAME> \
--resource-group <RESOURCE_GROUP> \
--name <NSP_CONFIGURATION_NAME>新規作成時にNSP前提の公開ネットワークアクセスを指定する例です。
az appconfig create \
--resource-group <RESOURCE_GROUP> \
--name <STORE_NAME> \
--location <LOCATION> \
--sku Standard \
--public-network-access SecuredByPerimeter既存ストアを更新する例です。
az appconfig update \
--resource-group <RESOURCE_GROUP> \
--name <STORE_NAME> \
--public-network-access SecuredByPerimeter旧来の --enable-public-network は使い続けないほうが安全です。新旧の引数を同時に指定すると相互排他エラーになるため、CI/CD内の共通テンプレートや再利用スクリプトを必ず見直してください。(GitHub)
既存環境で安全に移行する手順
既存の本番 App Configuration ストアでは、いきなり SecuredByPerimeter や強制モードに寄せるのではなく、通信実態を把握してから段階的に移行します。NSPの移行ドキュメントでは、既存PaaSリソースを移行する際に、まずTransitionモードで既存のアクセスパターンを把握し、その後Enforcedモードへ移る考え方が示されています。(Microsoft Learn)
| 手順 | 実施内容 | 確認ポイント |
|---|---|---|
| 棚卸し | App Configuration ストア、利用アプリ、CI/CD、管理者アクセス経路を一覧化 | どのアプリがどのタイミングで設定を取得するか |
| 現状確認 | publicNetworkAccess、Private Endpoint、DNS、SDK接続先を確認 | パブリック経由・Private Link経由のどちらに依存しているか |
| NSP関連付け | NSP、プロファイル、アクセスルールを設計 | 受信元IP、サブスクリプション、境界内リソースを過不足なく定義 |
| 観察期間 | Transition相当のモードやログで通信を確認 | 拒否される予定の通信、不要な通信、想定外の外部アクセス |
| 切り替え | --public-network-access SecuredByPerimeter を適用 | メンテナンス枠、ロールバックコマンド、関係者連絡を準備 |
| 再同期と検証 | reconcile、アプリ起動、機能フラグ更新、ポータル確認 | アプリログ、NSPログ、App Configuration取得エラー |
ここで失敗しやすいのは、アプリ本体の通信だけを見て、CI/CDや運用者のアクセスを見落とすケースです。たとえば、GitHub Actionsのホステッドランナーや社外ネットワークから設定値を投入している場合、NSP適用後にデプロイだけ失敗することがあります。自己ホストランナーをPrivate Link到達可能なネットワークに置く、または必要なアクセスルールを設計するなど、デプロイ経路も含めて確認してください。
ログと監査で見るべき項目
NSPの運用では、設定を入れて終わりではなく、ログを見て「どの通信が許可され、どの通信が拒否されるべきか」を継続的に確認することが重要です。Azure Monitorには microsoft.network/networksecurityperimeters 向けの NSPAccessLogs テーブルがあり、NSPアクセスルールに基づいて許可されたインバウンドアクセスログを扱います。(Microsoft Learn)
App Configuration のNSP構成取得結果には、networkSecurityPerimeter、profile、resourceAssociation、provisioningState、provisioningIssues などの情報が含まれます。provisioningIssues には、構成伝播失敗、境界構成不足、マネージドID構成不足などの問題種別が返る可能性があります。(Microsoft Learn)
運用で見るべきポイントは次の通りです。
| 観点 | 確認内容 |
|---|---|
| アクセスモード | resourceAssociation.accessMode が想定通りか |
| ルールの鮮度 | accessRulesVersion が変更後の値になっているか |
| 診断設定 | diagnosticSettingsVersion と有効ログカテゴリが想定通りか |
| プロビジョニング状態 | Succeeded 以外が続いていないか |
| 問題通知 | provisioningIssues に MissingPerimeterConfiguration や MissingIdentityConfiguration が出ていないか |
reconcile は、こうした構成の反映ずれを疑うときに使う確認・再同期の手段です。ただし、通信要件の洗い出し不足やルール設計ミスを自動修復するものではありません。
Private Endpointとの使い分け
NSPとPrivate Endpointは競合する機能ではありません。Private Endpointは、仮想ネットワークから App Configuration にプライベートIPで接続するための仕組みです。一方、NSPはPaaSリソースの公開ネットワークアクセスを境界として制御する仕組みです。AzureのNSP移行ドキュメントでも、Private Link経由のアクセスはNSPの影響を受けないと説明されています。(Microsoft Learn)
判断基準は次のように考えると実務で迷いにくくなります。
| 構成 | 向いているケース |
|---|---|
| Private Endpoint中心 | アプリがVNet内、またはExpressRoute/VPN経由の閉域網からのみ利用する |
| NSP中心 | 複数のPaaSリソースを境界でまとめ、外部公開アクセスを一元的に管理したい |
| Private Endpoint + NSP | 閉域接続を基本としつつ、PaaS間通信や例外的な公開アクセスも統制したい |
一時的に Enabled | 移行前検証、例外処理、既存アプリの改修期間中のみ |
また、geo-replicationを使う App Configuration ストアでは、単一のPrivate Endpointで複数レプリカへ接続できる一方、リージョン障害時の到達性を考えると、レプリカごとにPrivate Endpointを用意する設計も検討対象になります。(Microsoft Learn)
Azure PolicyとIaCで確認すべきこと
Azure Policyには、App Configurationの公開ネットワークアクセスを無効化する組み込みポリシーや、Private Endpoint、Private DNS Zoneに関するポリシーが用意されています。公開ネットワークアクセスを無効化するポリシーはデータ漏えいリスク低減の文脈で説明されており、Private Endpoint作成と組み合わせた統制が前提になります。(Microsoft Learn)
ただし、既存ポリシーが「公開アクセス無効化」を見ているだけの場合、NSPの SecuredByPerimeter をどう評価するかは組織側で整理が必要です。Azure Policy、Bicep、Terraform、Azure CLIの値がばらばらだと、ある環境では Disabled、別の環境では SecuredByPerimeter、CI/CDでは旧 --enable-public-network false という不整合が起こります。
IaCでは、少なくとも次を明示してください。
resource appConfig 'Microsoft.AppConfiguration/configurationStores@2025-08-01-preview' = {
name: appConfigName
location: location
sku: {
name: 'standard'
}
properties: {
publicNetworkAccess: 'SecuredByPerimeter'
disableLocalAuth: true
}
}この例では publicNetworkAccess と disableLocalAuth をあえて分けて書いています。ネットワーク境界と認証方式は別の管理対象であり、片方だけでセキュリティ要件を満たしたと判断しないためです。
展開時に失敗しやすいポイント
SecuredByPerimeter を先に適用し、NSP関連付けやPrivate Endpointが後追いになる構成は避けてください。特に新規リソースで SecuredByPerimeter を指定すると、NSP未関連付けでも公開アクセスがロックダウンされるため、初期設定スクリプトや設定値投入ジョブが接続できないことがあります。(Microsoft Learn)
また、EnforcedモードではNSPアクセスルールが中心になります。Azureの移行ドキュメントでは、Trusted accessはEnforcedモードでサポートされないと説明されているため、従来「信頼されたAzureサービスだから通る」と考えていた通信は再確認が必要です。(Microsoft Learn)
実務での注意点をまとめると、次の通りです。
| 失敗パターン | 対策 |
|---|---|
| 旧引数と新引数を混在 | --enable-public-network を削除し、--public-network-access に統一する |
| アプリ通信だけを確認 | CI/CD、管理者端末、監視、設定投入バッチも確認する |
| DNS確認を省略 | Private Endpoint利用時はPrivate DNS Zoneと名前解決を必ず確認する |
| ログを有効化せず切り替え | 切り替え前にNSPログとアプリログを取得できる状態にする |
| すぐEnforcedにする | 既存環境ではTransition相当の観察期間を設ける |
| ロールバックを用意しない | Enabled または Disabled へ戻す手順、例外ルール追加手順を事前に決める |
管理者が次に取るべき行動
今回の Azure Networking 更新は、App Configuration をより厳密なネットワーク境界で管理するための重要な前進です。一方で、App Configuration はアプリの起動や設定更新に直結するため、ネットワーク変更の影響がすぐアプリ障害として現れます。
まずは、すべての App Configuration ストアについて publicNetworkAccess、Private Endpoint、利用アプリ、CI/CD経路を棚卸ししてください。そのうえで、検証環境で az appconfig network-security-perimeter-configuration list/show/reconcile を使い、NSP構成の見え方とログを確認します。既存本番環境では、Transition相当の観察、アクセスルール整備、アプリ起動テスト、ロールバック手順の準備まで完了してから SecuredByPerimeter を適用するのが安全です。
コメント