はじめに
これまで、以下の二つのブログで、Azure Storage Account のセキュリティに関する機能である、Storage Account Firewall と Network Security Perimeter (NSP) について、解説してきました。
- Azure Storage Accountのファイアウォール設定で困ることが多いので設定方法まとめ
- Azure Storage Account の Network Security Perimeter を理解する
この二つの機能は、どちらも Storage Account へのアクセスを制御するための機能ですが、制御できる範囲や、考え方が異なります。
そのため、この記事では、機能の違いを比較し、どのようなユースケースでどちらの機能を利用するのが適切かというところを、個人的な感覚を踏まえてまとめます。
全体的な所感としては、NSP は、概念としては非常に有用ではあるものの、既存のサポート範囲が限定的であることから、現時点では、「複数 PaaS のアクセス制御を一元化したい」というような、特定のユースケース以外では、Storage Account の Firewall の方が利用しやすいかなという印象です。
なお、この記事では、わかりやすく差を説明するため、できる限り、Storage Account Firewall と Network Security Perimeter (NSP) の対比を表を用いて記載いたします。
TL;DR
- 両機能とも制御対象は共通：データプレーンへの Public Endpoint 経由のアクセスのみ制御可能。管理プレーンや Private Endpoint 経由のアクセスは制御対象外。
- 管理スコープが異なる：Firewall は Storage Account 1 リソースごとの個別設定。NSP は 1 つのリソースで複数の PaaS サービスへのアクセスを一括管理でき、同一ペリメーター内のリソース間通信は暗黙的に許可される。
- インバウンド制御の方式が異なる：Firewall は IP 規則と仮想ネットワーク規則を使い分ける。NSP はサブスクリプション単位または IP ベースの許可ルールのみで、仮想ネットワーク規則 / サービスエンドポイントは非サポート。
- アウトバウンド制御は NSP のみ対応：診断ログの送信先など Storage Account 発のアウトバウンド通信を制御したい場合は NSP を使う必要がある（FQDN 指定）。
- 現時点では NSP のサポート範囲が限定的：NFS / SFTP・静的 Web サイト・Azure Backup は NSP 非対応。「複数 PaaS のアクセス制御を一元管理したい」など特定ユースケース以外は、現状 Firewall の方が利用しやすい。
Storage Account Firewall と NSP の共通の前提事項
Storage Account Firewall と Network Security Perimeter (NSP) は、どちらも Storage Account へのアクセスを制御するための機能です。
これら二つが制御したいアクセスや、制御可能な範囲に関しては、ほぼ共通しており、以下のような形となります。
| 制御対象 | Storage Account Firewall | Network Security Perimeter (NSP) |
|---|---|---|
| データプレーン | ✅ | ✅ |
| 管理プレーン | ❌ | ❌ |
| Public Endpoint 経由のアクセス | ✅ | △ (サービスエンドポイントは不可) |
| Private Endpoint 経由のアクセス | ❌ | ❌ |
つまり、
- データプレーン(データの操作) に対するアクセス制御である
- Public Endpoint 経由のアクセスに対するアクセス制御だが、Private Endpoint 経由のアクセスに対するアクセス制御はできない
というものとなります。
機能における制御範囲や考え方の違い
Storage Account Firewall と Network Security Perimeter (NSP) は、どちらも Storage Account へのアクセスを制御するための機能ですが、制御できる範囲や、考え方が異なります。
いくつかの観点で、両者の違いを比較してみます。
| 項目 | Storage Account Firewall | Network Security Perimeter (NSP) |
|---|---|---|
| 設定の適用単位 | Storage Account 1リソースごとに個別設定 | NSP リソース 1つで複数 PaaS に一括適用 |
| リソース間通信のデフォルト挙動 | ❌ 対応概念なし（各リソースに個別ルールが必要） | ✅ 同一ペリメーター内のリソース間は暗黙的に許可 |
| 信頼の考え方 | なし（すべてのアクセスを明示的な許可規則で管理） | NSP ペリメーター = 信頼ゾーン（内部は自由、外部はルールで制御） |
| 対応 PaaS サービス | Storage Account のみ | 複数の PaaS サービス（公式一覧参照） |
インバウンド通信の制御の比較
インバウンド通信の制御に関しては、Storage Account Firewall と NSP でそれぞれ特徴がありますので、それぞれの特徴をまとめてから、比較を行います。
Storage Account Firewall の特徴
Storage Account Firewall では、まず、パブリックアクセスを許可するかどうかの選択が可能で、すべてのアクセスを許可することも、すべてのアクセスを拒否することも可能です。
アクセスを部分的に許可するために、Storage Account Firewall では、 主に IPネットワーク規則 、 仮想ネットワーク規則、 Azure リソース インスタンス規則 と 信頼されたAzureサービスの例外 という四つの規則を利用します。
このうち、 IPネットワーク規則 、 仮想ネットワーク規則 の二つの規則は、特定のAzure サービスや Azure リソースとは紐づかない、アクセス元に関する規則で、 NSP と類似の制御の考え方となりますので、この二つに関してまとめます。
具体的には、以下の通りです。
| アクセス元(最終ホップ基準) | IPネットワーク規則 | 仮想ネットワーク規則 |
|---|---|---|
| Storage Account と同一リージョンのリソースからインターネット経由 | ❌ 制御不可 | ✅ 制御可能 |
| ペアリージョンからのアクセス + サービスエンドポイント経由 | ❌ 制御不可 | ✅ 制御可能 |
| ペアリージョンからのアクセス + サービスエンドポイント利用無し | ✅ 制御可能 | ❌ 制御不可 |
| ペアリージョン以外からのアクセス | ✅ 制御可能 | ❌ 制御不可 |
Storage Account と同一リージョンのリソースからインターネット経由に関して
ストレージアカウントへのアクセスは、ストレージアカウントにアクセスする際の最終的な Azure 上のリソースが重要になります。例えば、別リージョンのリソースから Storage Account へのアクセスに際して、Storage Account と同一リージョンの Azure Firewall を経由し、このAzure Firewallが最後のリソースとなる場合は、同一リージョンからのアクセスとみなされ、仮想ネットワーク規則で制御が必要となります。
Azure リソース インスタンス規則 と 信頼されたAzureサービスの例外 に関しては、ここでは取り上げませんが、重要な内容のため、公式ドキュメント を参照してください。
Network Security Perimeter の特徴
Network Security Perimeter (NSP) では、基本的にすべてのアクセスを拒否したうえで、アクセスを許可するためのルールを定義していく形となります。
インバウンド通信の制御に関しては、以下のようなルールを定義することができます。
| ルールの種類 | 説明 |
|---|---|
| Subscription ベース 許可 | サブスクリプション全体からのアクセスを許可するルールで、指定したサブスクリプション内すべてのリソースがアクセス可能になります |
| IPベースの許可 | 特定の IP アドレスや CIDR ブロックからのアクセスを許可するルール |
IPベースの許可に関して
IPベースの許可ルールは、アクセス元の IP アドレスが特定の IP アドレスや CIDR ブロックに含まれる場合にアクセスを許可するルールです。
ただし、このルールでは、RFC 1918 で定義されているプライベート IP アドレス空間を単体で指定することはできません。
Private Endpoint 経由のアクセスに対するアクセス制御はできないため、このルールが不要と判断されているからだと推測されます。
RFC 1918 で定義されているプライベート IP アドレス空間が指定できない点に関しては、以下のようにポータルで確認可能です。
同一リージョンからの IP ベースの制御に関する補足
既に、Storage Account Firewall の設定や、Storage Account の診断設定で、同一リージョンからアクセスした場合の結果の出方について詳しい方は、IPベースのアクセス許可で、RFC 1918 で定義されているプライベート IP アドレス空間を単体で指定できない場合、同一リージョン内のリソースからアクセスする場合はどう制御すればいいのか？という質問を抱く方がいるかと思います。
残念ながら、こちらは検証しましたが、同一リージョンの VM にパブリック IP アドレスを付与しても、ログ上、サービスエンドポイントからのアクセスのログとなってしまい、IPベースの許可ルールで制御することはできませんでした。
このように、同一リージョンからのアクセスでは、IPベースの許可ルールで制御することはできないため、同一リージョンからのアクセスを許可したい場合は、Subscription ベース 許可ルールでサブスクリプション全体からのアクセスを許可するルールを定義する必要があります。
{
"resourceId": "/SUBSCRIPTIONS/<サブスクリプションID>/RESOURCEGROUPS/RG-STORAGE-NSP/PROVIDERS/MICROSOFT.NETWORK/NETWORKSECURITYPERIMETERS/NSP-LAB-NSP",
"location": "japaneast",
"operationName": "ListBlobs",
"operationVersion": "2025-07-05",
"category": "NspPublicInboundPerimeterRulesDenied",
"properties": {
"serviceResourceId": "/subscriptions/<サブスクリプションID>/resourceGroups/rg-storage-nsp/providers/Microsoft.Storage/storageAccounts/<ストレージアカウント名>",
"profile": "default-profile",
"appId": "",
"matchedRule": {
"accessRule": "DefaultDenyAll" // 既定ですべてのアクセスを拒否するため、拒否されたアクセスのログ
},
"source": {
"resourceId": "/subscriptions/<サブスクリプションID>/resourcegroups/rg-storage-nsp/providers/Microsoft.Compute/virtualMachines/nsp-lab-vm",
"ipAddress": "", // パブリックIPが記録されていない
"port": "50656",
"protocol": "HTTPS",
"perimeterGuids": "",
"appId": "f9ce2ee6-e9e6-47ad-88af-91cf0695a510",
"parameters": "{\"ServiceEndpointIP\":\"fd00::756f:7318:0:a00:4\"}" // サービスエンドポイントのIPアドレスが記載されている
}
},
"resultDescription": "AuthorizationFailure",
<省略>
}
同一リージョンからの SMB 接続に関する補足
現行の制限においては、Azure Files に SMB プロトコルで接続する場合は、IPベースの許可ルールで制御する必要があります。
一方で、上記のように、同一のリージョンのVMからでは、IPベースの許可ルールで制御することはできないため、同一リージョンからの SMB 接続に関しては、NSP では制御できないということになります。
※正確には、IPベースの許可ルールにて、0.0.0.0/0 等を指定すればアクセス可能ですが、これはすべてのアクセスを許可することになってしまうため、制御不可としています。
アウトバウンド通信の制御の比較
アウトバウンド制御は、Storage Account の Firewall では制御できないものとなります。
私の確認した範囲では、Storage Account のアウトバウンド通信とは、主に診断設定のログの送信などのことですが、これを制御するには、NSP を利用して、FQDN ベースでのアクセス許可ルールを定義する必要があります。
| 項目 | Storage Account Firewall | Network Security Perimeter (NSP) |
|---|---|---|
| アウトバウンド通信の制御 | ❌ 制御不可 | ✅ FQDN ベースで制御 |
制限事項の違い
それぞれに、設定方法に制限や、考え方の違いがありますので、以下のようにまとめます。
一部、制限ではなく、設定方法となっている部分もありますが、二つの違いが分かりやすいようにあえて、まとめて表にしています。
両者のどちらかに何らかの制限がある項目
まずは、両者のどちらかに制限がある事項をまとめます。
| 項目 | Storage Account Firewall | Network Security Perimeter (NSP) |
|---|---|---|
| サービスエンドポイントの扱い | ⚠️ ペアリージョン+SEのサブネットでは必ず仮想ネットワーク規則が必要（IP規則不可） | ❌ サービスエンドポイント自体が非サポート |
| vNet による通信制御 | ✅ 同一・ペアリージョンの vNet は仮想ネットワーク規則に登録可能。 経路によっては仮想ネットワーク規則での制御となる |
❌ VNet ベースの制御規則が存在しない |
| アウトバウンド通信の制御 | ❌ アウトバウンド制御機能なし | ✅ FQDN で指定（ワイルドカード・IP 指定不可） |
| Trusted サービス例外の扱い | ✅ Trusted サービス例外の設定が可能 | ⚠️ 強制モードでは無効化（移行モードでは有効） 移行モードではFirewall ルールにフォールバックするため |
NSP にのみ制限がある項目
こちらでは、NSP のみに制限がある事項をまとめます。
| 項目 | Storage Account Firewall | Network Security Perimeter (NSP) |
|---|---|---|
| 対応プロトコル | ✅ SMB / NFS / SFTP 含む全プロトコル | ⚠️ HTTPS + SMB（NFS・SFTP 不可） ※SMBはIPアドレスルールのみ利用可 |
| Azure Backup | ✅ 信頼されたサービス例外で対応可能 | ❌ 非サポート |
| 静的 Web サイト | ✅ 対応可能 | ❌ 非サポート（NSP 紐付け不可） |
NSP が Storage Account 専用でないこともあって、まだ対応のサービスが限定的な印象があります。
所感
全体的な所感としては、現時点においては、Storage Account Firewall の方が、設定可能な内容やサポートされている機能も多く、使いやすいかなという印象です。
一方で、NSP では、複数の PaaS サービスへのアクセスをまとめて制御できるというところが大きな利点になるかと思いますので、用途によっては有用かと思います。
Network Security Perimeter は、最近リリースされたばかりのサービスなので、今後の発展に期待です。
今回のドキュメントフィードバック
以下の二つのドキュメントでは、Azure Files の SMB 接続に関して、片方は NSP 非サポートであることが書かれており、もう片方は、IPアドレスベースのルールであれば NSP で制御可能であることが書かれており、矛盾しているように見える記載がありました。
現状の動作確認としては、IPアドレスベースのルールを設定していれば、アクセス可能でしたので、Use network security perimeter for Azure Files の方のドキュメントの方が正しいのではないかと思います。
この点に関しては、矛盾しているのではないか？ということをフィードバックいたしました。
今後の更新に期待です。