「Microsoft updates Network Security Perimeter guidance for Azure Storage」で最も重要な変更点は、Azure StorageでNFS・SMB・SFTPを利用する場合の説明が明確になったことです。
2026年7月8日の公式GitHub差分では、従来の「Network Security Perimeterに関連付けるとHTTPS以外がブロックされる」という説明が、「Enforced modeではHTTPS以外がブロックされる」へ修正されました。さらに、Transition modeで通信できても、既存のストレージファイアウォールへのフォールバックによる可能性があり、Network Security Perimeterで正式にサポートされていることを意味しないと追記されています。(GitHub)
結論として、Network Security Perimeterを使用していない環境には、今回の更新による直接的な対応はありません。一方、Transition modeでNFS・SMB・SFTPが動作している環境や、Enforced modeへの移行を予定している管理者は、優先的な確認が必要です。
Azure Storage / Network Security Perimeterの「Microsoft updates Network Security Perimeter guidance for Azure Storage」とは
Network Security Perimeter（NSP）は、仮想ネットワークの外側に配置されるAzure StorageなどのPaaSリソースを、論理的なネットワーク境界で保護する仕組みです。
NSPに関連付けたリソースは、境界外とのパブリックな受信・送信通信を既定で制限し、必要な通信だけをアクセスルールで許可できます。ストレージアカウントごとに個別設定するファイアウォールより上位の境界として、複数のPaaSリソースを一元管理できる点が特徴です。(Microsoft Learn)
今回確認された差分は、新機能の発表というよりも、Azure Storage固有の制限事項を正確にするためのガイダンス更新です。
| 項目 | 更新前の説明 | 更新後の説明 | 管理者への影響 |
|---|---|---|---|
| 非HTTPSプロトコル | NSPに関連付けるとブロックされる | Enforced modeでブロックされる | Transition modeへの関連付け自体は可能な場合がある |
| NFS・SMB・SFTPが必要な場合 | NSPに関連付けない | Enforced modeを使用しない | Enforcedへの移行対象から除外する判断が必要 |
| Transition modeで通信できた場合 | 詳細な注意が不足 | ファイアウォールへのフォールバックの可能性を明記 | 動作確認だけでEnforcedへ移行してはいけない |
GitHubの公開差分は2026年7月8日付ですが、Microsoft Learnページの最終更新日は2026年7月7日と表示されています。本記事では、具体的な差分を確認できる7月8日の更新として扱います。(GitHub)
なお、公開された差分だけから、2026年7月8日にAzure Storageの実際のサービス動作が変更されたとは判断できません。既存動作の説明が明確化された可能性もあるため、更新日をそのまま障害発生日として扱わず、実環境の設定とログで影響を確認する必要があります。
対応が必要かを最初に判断する
まず、次の表で自社環境の対応要否を判断してください。
| 現在の構成 | 対応の優先度 | 必要な対応 |
|---|---|---|
| NSPを使用しておらず、導入予定もない | 低 | 直ちに設定を変更する必要はない |
| HTTPSベースのアクセスだけを使用し、NSPをTransition modeで検証中 | 中 | 診断ログからフォールバック通信を洗い出す |
| Transition modeでNFS・SMB・SFTPを使用している | 高 | Enforcedへ切り替えない。通信方式またはアカウント分離を検討する |
| Enforced modeでNFS・SMB・SFTPを使用する計画がある | 最優先 | 設計を見直す。現行ガイダンスでは非対応 |
| ストレージファイアウォールの「信頼されたサービス」に依存している | 高 | NSPアクセスルールへの置き換え可否を確認する |
| Azure Backup、オブジェクトレプリケーション、静的Webサイトを使用している | 高 | NSPとの非互換性を確認する |
| Microsoft Sentinel有効のLog Analyticsワークスペースをログ送信先にする予定 | 高 | ログ収集アーキテクチャを先に見直す |
特に注意したいのは、Transition modeを恒久運用の回避策にしないことです。MicrosoftはTransition modeを移行期間用のモードと位置付け、できるだけ早くEnforced modeへ移るよう案内しています。したがって、NFS・SMB・SFTPが必須のストレージアカウントは、現時点ではNSPによるEnforced運用の対象から外すのが現実的です。(Microsoft Learn)
Network Security Perimeterが保護する範囲
Azure StorageのNSP対応では、主に次のHTTPSベースのデータプレーン操作を制御できます。
- Azure Blob Storage
- Azure Data Lake Storage Gen2
- Azure FilesのHTTPSベース操作
- Azure Table Storage
- Azure Queue Storage
Azure Files自体がすべて非対応という意味ではありません。HTTPS経由の操作は対象ですが、SMBやNFSによるファイルアクセスはEnforced modeで利用できない点を区別する必要があります。(Microsoft Learn)
Transition modeとEnforced modeの違い
| 通信・設定 | Transition mode | Enforced mode |
|---|---|---|
| NSPアクセスルールに一致する通信 | NSPルールで許可 | NSPルールで許可 |
| NSPルールに一致しない通信 | ストレージファイアウォールへ評価をフォールバック | 拒否 |
| ストレージの許可済みネットワーク | フォールバック時に使用される | 上位のNSPルールが優先される |
| 信頼されたAzureサービス | 従来設定によって許可される場合がある | 例外として扱われない |
| パブリック受信・送信 | NSPと既存ルールの両方を評価 | NSPで明示的に許可した通信だけ |
| Private Link経由の通信 | NSPのルール評価対象外 | NSPのルール評価対象外 |
| NFS・SMB・SFTP | フォールバックにより成功する場合がある | ブロックされる |
Transition modeは「現在の通信を学習し、必要なルールを準備するための状態」です。Enforced modeにすると、ストレージアカウント側のファイアウォールで許可されていた通信であっても、NSPルールに存在しなければ通らなくなります。(Microsoft Learn)
Private Endpointの通信はNSPのアクセスルールによる制御を受けません。ただし、NFS・SMB・SFTPについては、Azure Storage固有のガイダンスがEnforced modeを使わないよう明記しています。Private Endpointを使っていることだけを根拠に、これらのプロトコルも利用できると判断しないでください。(Microsoft Learn)
ネットワーク許可とデータ権限は別に考える
NSPで通信が許可されても、ストレージデータへのアクセス権が自動的に付与されるわけではありません。
Microsoft Entra ID、Azure RBAC、アカウントキー、SASなどによる認証・認可は別途必要です。NSPは通信経路を制御する仕組みであり、データアクセス権限を置き換える機能ではありません。(Microsoft Learn)
管理者が確認すべき設定
accessModeを確認する
NSPでは、ストレージアカウントとのリソース関連付けにaccessModeを設定します。
| 設定値 | 動作 | 運用上の位置付け |
|---|---|---|
Transition | NSPルールに一致しない場合、既存のリソースルールへフォールバックする | 通信の棚卸しと移行テスト用 |
Enforced | NSPルールだけで受信・送信を制御する | 本番の強制適用状態 |
Transition modeは既定値です。通信断を防ぎながら移行できますが、フォールバックが残った状態ではNSPによる完全な保護にはなりません。(Microsoft Learn)
publicNetworkAccessを確認する
新しいリソースでは、publicNetworkAccessをSecuredByPerimeterに設定できます。
この状態では、NSPにまだ関連付けられていない場合でもパブリックアクセスがロックダウンされ、NSPへの関連付け後にNSPルールが通信を管理します。リソース作成からNSP関連付けまでの一時的な公開を避けたい場合に有効です。(Microsoft Learn)
Azure portalでは、NSPリソースの関連付け済みリソースから、次の設定を変更できます。
- パブリックネットワークアクセスの
Enabled、Disabled、SecuredByPerimeter - アクセスモードの
Transition、Enforced
設定名や画面上の表記は、ポータルの言語や更新状況によって異なる場合があります。
アクセスルールの範囲を確認する
NSPで利用できる主なアクセスルールは次のとおりです。
| 方向 | ルールの種類 |
|---|---|
| 受信 | サブスクリプションベース |
| 受信 | IPアドレスベース |
| 送信 | FQDNベース |
サブスクリプションベースの受信ルールは、特定の単一リソースだけではなく、そのサブスクリプション内のリソースを広く対象にします。認証・認可は別途必要ですが、ネットワーク許可の範囲が想定以上に広くならないよう、専用サブスクリプションの利用やルール分割を検討してください。(Microsoft Learn)
また、同一NSP内の通信とサブスクリプションベースの受信ルールでは、SASによる認証がサポートされません。SASを使うアプリケーションは、Microsoft Entra IDとマネージドIDなど、利用サービスでサポートされる別の認証方式へ変更できるか確認が必要です。(Microsoft Learn)
事前に確認すべき非対応機能と制限
Azure StorageをNSPへ関連付ける前に、次の依存関係を確認してください。
| 機能・構成 | 影響 | 推奨対応 |
|---|---|---|
| NFS、SMB、SFTP | Enforced modeでブロックされる | Enforced対象から除外するか、HTTPSベースの方式へ変更する |
| Blobのオブジェクトレプリケーション | 送信元または送信先がNSPに関連付けられていると利用できない | レプリケーション対象のアカウントにNSPを設定しない |
| Azure Backup | 現時点ではNSPへオンボードされていない | バックアップを使用するアカウントを関連付けない |
| 静的Webサイト | NSPと併用できない | 静的Webサイト用アカウントを分離する |
| 非管理ディスク | NSPルールを認識しない | NSPで保護するアカウントでは使用しない |
| カスタマーマネージドキー | Key Vaultへの到達性が必要 | Key Vaultを同じ境界から利用できるよう設計する |
| 仮想ネットワークのサービスエンドポイント | NSPの一般的な制限対象 | IaaSからPaaSへの通信はPrivate Endpointを優先する |
オブジェクトレプリケーションと静的Webサイトは、既に有効な場合はNSPを関連付けられず、NSP関連付け後に有効化することもできません。設定作業の直前ではなく、設計・棚卸しの段階で確認することが重要です。(Microsoft Learn)
監査・検知への影響
Enforcedへ切り替える前に診断ログを有効化する
Transition modeからEnforced modeへ移る前に、NSPの診断設定を有効化してください。
特に確認すべきログカテゴリは次のとおりです。
| ログカテゴリ | 意味 | 管理者が取るべき対応 |
|---|---|---|
NspPublicInboundResourceRulesAllowed | NSPでは許可されず、PaaSリソース側のルールで受信が許可された | Enforced移行前にNSP受信ルールを追加する |
NspPublicOutboundResourceRulesAllowed | NSPでは許可されず、PaaSリソース側のルールで送信が許可された | 送信先FQDNを確認してNSP送信ルールを追加する |
NspPublicInboundPerimeterRulesDenied | Enforced modeでパブリック受信が拒否された | 正規通信か、不審なアクセスかを判定する |
NspPublicOutboundPerimeterRulesDenied | Enforced modeでパブリック送信が拒否された | 必要な依存先か、意図しないデータ送信かを判定する |
NspOutboundAttempt | NSP内リソースからの送信試行 | 想定外の外部接続先を検出する |
NspIntraPerimeterInboundAllowed | 同じ境界内からの受信が許可された | 正常なサービス間通信のベースラインに使う |
NspPrivateInboundAllowed | Private Endpoint経由の受信が許可された | Private Link経路の利用状況を確認する |
Transition modeで最も優先して見るべきなのは、名前にResourceRulesAllowedを含むログです。これらは「現在は動いているが、Enforcedへ切り替えると停止する可能性が高い通信」を示します。(Microsoft Learn)
Log Analyticsでフォールバック通信を抽出する
Log Analyticsへ送信したNSPログは、NSPAccessLogsテーブルで確認できます。Category、Count、ServiceResourceId、SourceIpAddress、DestinationFqdn、MatchedRuleなどを利用して、通信元・通信先・適用ルールを追跡できます。ログは集約される場合があり、Countがない場合は1件として扱います。(Microsoft Learn)
Enforced移行前のフォールバック通信を抽出する例です。
NSPAccessLogs
| where TimeGenerated > ago(7d)
| where Category in (
"NspPublicInboundResourceRulesAllowed",
"NspPublicOutboundResourceRulesAllowed"
)
| extend EventCount = coalesce(Count, 1)
| summarize
Events = sum(EventCount),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated)
by Category,
ServiceResourceId,
SourceResourceId,
SourceIpAddress,
DestinationFqdn,
MatchedRule
| order by Events descEnforced移行後の拒否通信を確認する例です。
NSPAccessLogs
| where TimeGenerated > ago(24h)
| where Category in (
"NspPublicInboundPerimeterRulesDenied",
"NspPublicOutboundPerimeterRulesDenied"
)
| extend EventCount = coalesce(Count, 1)
| summarize
Events = sum(EventCount),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated)
by Category,
ServiceResourceId,
SourceResourceId,
SourceIpAddress,
SourceAppId,
DestinationFqdn
| order by Events desc単発の拒否だけでアラートを発生させると、検証作業や設定反映直後の通信で通知が増える可能性があります。業務上重要なストレージアカウント、未知の送信先FQDN、短時間の急増などを条件に加えると、運用しやすくなります。
ログ送信先も同じNSP内に配置する
NSPのアクセスログは、Log Analyticsワークスペース、Azure Storage、Azure Event Hubsなどへ送信できます。
ただし、PaaSリソースのログを正常に流すには、ログ送信先も対象リソースと同じNSP内に配置する必要があります。オンボードされていないリソースを診断設定の送信先として使用すると、ログフローが停止する可能性があります。(Microsoft Learn)
Microsoft Sentinel利用環境は特に注意する
Microsoftの公式制限では、Microsoft Sentinelが有効なLog AnalyticsワークスペースをNSPへ関連付ける構成はサポートされていません。ワークスペースにNSPを有効化すると、Sentinelの分析ルールが自動的に無効化されると説明されています。(Microsoft Learn)
そのため、Sentinelを利用している場合は、Sentinel有効ワークスペースをそのままNSPへ関連付けないでください。別のLog Analyticsワークスペース、Azure Storage、Azure Event Hubsなどを含め、ログの収集・保管・連携方法を事前に設計する必要があります。
管理者が優先すべき対応
| 優先度 | 対応 | 完了の判断基準 |
|---|---|---|
| P0 | NSP関連付け済みストレージアカウントを一覧化する | accessMode、利用プロトコル、依存サービスを把握できている |
| P0 | NFS・SMB・SFTPの利用有無を確認する | 該当アカウントをEnforced移行対象から除外できている |
| P0 | Azure Backup、レプリケーション、静的Webサイト、CMKを確認する | 非互換機能とKey Vault依存を整理できている |
| P1 | 診断ログを有効化する | NSPAccessLogsで通信を確認できる |
| P1 | ResourceRulesAllowedを分析する | すべてのフォールバック通信について、許可・廃止・例外の判断が済んでいる |
| P1 | 信頼されたサービスへの依存を確認する | NSPルールまたは別経路へ置き換えられている |
| P1 | サブスクリプションベースルールの範囲を見直す | 不要なサブスクリプション全体許可がない |
| P2 | 少数アカウントでEnforcedへ段階移行する | 業務通信が成功し、想定外の拒否がない |
| P2 | 切り戻し手順を記録する | Transitionへ戻す手順と既存ファイアウォール設定を確認できている |
失敗しやすいポイント
- Transition modeで通信できたため、Enforced modeでも動くと思い込む
- ストレージファイアウォールの「信頼されたサービス」がEnforcedでも有効だと考える
- 受信ルールだけを確認し、外部FQDNへの送信通信を見落とす
- ログ送信先をNSPの外側に置き、移行後に監査ログが途切れる
- サブスクリプションベースルールを安易に追加し、許可範囲を広げすぎる
- すべてのストレージアカウントを一度にEnforcedへ切り替える
- SASを利用するアプリケーションの認証方式を確認しない
まとめ：まず非HTTPS依存とフォールバック通信を洗い出す
今回のAzure Storage / Network Security Perimeterガイダンス更新では、NFS・SMB・SFTPがブロックされる条件が、NSPへの関連付け全般ではなく、Enforced modeであることが明確になりました。
ただし、Transition modeで通信できることは、NSPがそのプロトコルをサポートしている証拠にはなりません。既存ファイアウォールへのフォールバックで成功しているだけなら、Enforcedへ切り替えた時点で停止します。
管理者は、最初にストレージアカウントごとの利用プロトコルと非互換機能を棚卸ししてください。次に診断ログを有効化し、NspPublicInboundResourceRulesAllowedとNspPublicOutboundResourceRulesAllowedを確認します。フォールバック通信をすべて説明できる状態にしてから、HTTPSベースのワークロードだけを段階的にEnforced modeへ移行するのが安全です。
コメント