Azure Service Bus のネットワーク セキュリティ境界（Network Security Perimeter、以下 NSP）は、2026年4月6日に Microsoft の Release Communications で一般提供が案内されました。今回の更新で重要なのは、Service Bus の公開エンドポイントを名前空間単位で個別に守るだけでなく、Service Bus と Azure Key Vault など複数の Azure PaaS を「同じ境界」でまとめて制御できるようになった点です。境界内の通信は許可しつつ、境界外との公開通信は明示的なルールで絞り込めるため、データ流出対策や監査強化を進めたい環境では特に効果があります。 (Microsoft)
結論からいえば、Azure Service Bus でネットワーク セキュリティ境界を検討すべきなのは、CMK と Key Vault を組み合わせている、複数の PaaS をまたいで公開経路を一元管理したい、許可・拒否ログを残したい、といったケースです。一方で、これは Private Endpoint の置き換えではなく、SAS トークン主体の構成や VNet サービス エンドポイント前提の構成は、導入前にかなり丁寧な検証が必要です。 (TECHCOMMUNITY.MICROSOFT.COM)
Azure Service Bus のネットワーク セキュリティ境界が GA で変わること
今回 GA になったのは、Azure Service Bus が NSP に正式対応し、本番運用で使いやすい形になったことです。Microsoft の案内では、NSP は Service Bus 名前空間の周囲に論理的なネットワーク境界を作り、既定で不正な公開アクセスを遮断しつつ、境界内の Azure PaaS 間通信を安全に扱える仕組みとして位置付けられています。従来の IP ファイアウォール、VNet サービス エンドポイント、Private Endpoint に加えて、「複数リソースを境界単位で統制する」選択肢が正式に加わったと考えると分かりやすいです。 (Microsoft)
特に実務で効くのは、個別リソースごとにネットワーク規則を積み上げる運用から、境界ベースの統制へ寄せられることです。Service Bus と Key Vault を同じ境界に入れておけば、CMK 利用時の通信を追加の細かな公開設定に頼らず保護しやすくなります。さらに、許可・拒否された接続試行をログとして残せるため、監査対応や切り分けもしやすくなります。 (Microsoft)
ネットワーク セキュリティ境界とは何か
NSP は、Azure PaaS リソースのための論理的なネットワーク境界です。構成要素としては、境界本体、ルールのまとまりであるプロファイル、境界外への例外通信を定義するアクセス ルール、そして Service Bus などのリソースを境界へ参加させる関連付けがあります。アクセス モードは 2 つあり、まずは通信パターンを観測しやすい Transition モード、最終的に既定拒否で運用する Enforced モードへ進めるのが基本です。 (マイクロソフト ラーン)
| 要素 | 役割 | 実務での見方 |
|---|---|---|
| ネットワーク セキュリティ境界 | 複数 PaaS を囲う論理的な外周 | システム単位・環境単位で設計する |
| プロファイル | 同じルールを適用するまとまり | 本番系、検証系、運用系で分けやすい |
| アクセス ルール | 境界外との例外通信を許可する設定 | 最小権限で IP / サブスクリプション / FQDN を絞る |
| リソース関連付け | Service Bus や Key Vault を境界へ参加させる設定 | どのリソースをどの境界に入れるかを明確にする |
| Transition / Enforced | 移行観測 / 本番強制 | まず Transition、ログ確認後に Enforced が安全 |
この整理は、Microsoft Learn のコンポーネント定義とアクセス モード定義に基づいています。Transition モードでは既存のリソース側ファイアウォール設定にフォールバックできますが、Enforced モードでは NSP のルールに従うため、移行の順番がとても重要です。 (マイクロソフト ラーン)
通信制御の考え方も押さえておきましょう。NSP では、境界外からの公開インバウンド通信は IP アドレスやサブスクリプション属性で許可し、境界外への公開アウトバウンド通信は FQDN ベースで許可します。つまり、「誰が入ってよいか」と「どこへ出てよいか」を境界レベルで分けて設計できるのがポイントです。 (マイクロソフト ラーン)
既存の Service Bus ネットワーク セキュリティ機能との違い
Azure Service Bus には、もともと IP ファイアウォール、VNet サービス エンドポイント、Private Endpoint があります。NSP はそれらの代替というより、守る粒度が違う追加レイヤーです。 (TECHCOMMUNITY.MICROSOFT.COM)
| 手段 | 守る粒度 | 向いているケース | 注意点 |
|---|---|---|---|
| IP ファイアウォール | 個別の Service Bus 名前空間の公開アクセス | 固定 IP の拠点、オンプレ NAT、ExpressRoute など | IPv4/CIDR 前提。IP 変更が多い運用には不向き |
| VNet サービス エンドポイント | 特定 VNet サブネットからの接続 | VNet 配下の VM やアプリから Service Bus を使う構成 | Premium のみ。NSP と組み合わせる場合は service endpoint traffic 非対応の注意がある |
| Private Endpoint | VNet 内のプライベート IP 経由の接続 | Private IP で閉じたい、本命の閉域接続を作りたい | Premium のみ。DNS 設計も必要 |
| ネットワーク セキュリティ境界 | 複数 PaaS を横断する論理境界 | Service Bus + Key Vault などを一括統制したい、監査も強化したい | Private Endpoint の代替ではない。公開経路の統制が中心 |
この比較は、Service Bus の公式ネットワーク セキュリティ資料と NSP の公式資料を基に整理しています。VNet サービス エンドポイントと Private Endpoint は Premium のみで、NSP は「Private Endpoint の代わりに private IP を付ける機能」ではありません。 (マイクロソフト ラーン)
実務上の理解としては、次のように考えると迷いにくいです。
「アプリから Service Bus へ private IP で閉じたい」なら Private Endpoint が主役です。
「Service Bus と周辺 PaaS の公開入出力をまとめて制御したい」なら NSP が主役です。
「両方必要」なら併用します。Microsoft も、Private Endpoint と NSP は補完関係であり、Private Endpoint を通るトラフィック自体は NSP のルールで支配しないと案内しています。 (TECHCOMMUNITY.MICROSOFT.COM)
なお、NSP の制限事項として、service endpoint traffic はサポートされないと明記されています。すでに Service Bus の VNet サービス エンドポイントを使っている環境は、机上で「そのままいけるはず」と判断せず、検証環境で通信確認を行い、必要なら Private Endpoint への見直しも視野に入れるべきです。 (マイクロソフト ラーン)
特に効果が大きい 3 つのシナリオ
CMK で Service Bus と Key Vault を組み合わせている
Service Bus で customer-managed keys を使う場合、Key Vault との通信が必須です。Microsoft は、Service Bus 名前空間と Key Vault を同じ境界に置くことで、その通信を追加の複雑な公開設定なしで保護しやすくなると説明しています。CMK を使っているなら、今回の GA を最も前向きに評価してよいケースです。 (Microsoft)
複数の PaaS を個別設定で運用していて、統制がばらついている
Service Bus ごと、Key Vault ごと、Storage ごとに個別のネットワーク例外を管理していると、設定の整合性が崩れやすくなります。NSP は、個別リソース単位ではなく境界単位で制御する発想なので、「同じシステムなのに許可ルールの書き方がバラバラ」という状況を減らしやすいのが強みです。 (Microsoft)
監査証跡をきちんと残したい
NSP では、許可・拒否されたアクセス試行を診断ログとして取得できます。保存先には Log Analytics Workspace、Storage、Event Hubs が使えますが、PaaS リソースのログを正しく流すには、ログの宛先も同じ境界内に置く必要がある点は見落としやすいところです。監査や障害解析を重視する環境では、この点も含めて設計すると効果が大きくなります。 (マイクロソフト ラーン)
導入前に押さえたい判断基準
「使えるか」ではなく、「どの課題を解くために入れるか」で判断したほうが失敗しません。目安は次のとおりです。
| 判断ポイント | NSP を前向きに検討すべきケース | 別手段を優先しやすいケース |
|---|---|---|
| 複数 PaaS を一括統制したいか | Service Bus と Key Vault などをまとめて管理したい | Service Bus 単体だけを単純に絞れればよい |
| 公開入出力を境界単位で絞りたいか | データ流出対策や監査を強めたい | 固定 IP 数本だけ許可できれば十分 |
| VNet 内から private IP で使いたいか | NSP を補助的に追加する | Private Endpoint を優先する |
| 認証方式を見直せるか | Entra ID / Managed Identity へ寄せられる | SAS 接続文字列に強く依存している |
| 既存の VNet サービス エンドポイント依存が強いか | 検証のうえ段階導入する | 先に通信方式の見直しを検討する |
この判断基準は、Microsoft の公式資料にあるアクセス モード、SAS 制限、Private Endpoint との関係、既存の Service Bus ネットワーク セキュリティ機能の説明を土台にした実務向けの整理です。特に「Private IP が必要か」と「SAS 依存を見直せるか」は、導入可否を大きく左右します。 (マイクロソフト ラーン)
実務で失敗しにくい導入手順
まず現状の通信と認証を棚卸しする
最初に確認したいのは、接続元 IP、利用している Azure サブスクリプション、外向き通信先の FQDN、Private Endpoint の有無、SAS / Entra ID / Managed Identity のどれで認証しているか、CMK と Key Vault の依存、Geo-DR の有無です。ここが曖昧なまま進めると、Transition では動いていたのに Enforced で止まる、という典型的な事故が起きます。 (マイクロソフト ラーン)
境界とプロファイルを先に設計する
NSP は、単に Service Bus を 1 つ追加すれば終わりではありません。どのリソースを同じ境界に入れるのか、どのグループに同じアクセス ルールを当てるのかをプロファイル単位で決める必要があります。たとえば、本番メッセージ基盤と運用ログ系で必要な例外通信が違うなら、同じ境界でもプロファイルを分けたほうが管理しやすくなります。 (マイクロソフト ラーン)
Service Bus 名前空間を Transition モードで関連付ける
Azure portal では、Service Bus 名前空間の Networking から Public access タブを開き、Network security perimeter セクションで関連付けできます。いきなり Enforced にするのではなく、まずは Transition モードで始めるのが定石です。Transition では NSP 構成を基準に評価しつつ、マッチしない通信は既存のリソース ファイアウォール設定にフォールバックできるため、既存運用を壊しにくくなります。 (マイクロソフト ラーン)
診断ログを有効化して、どの通信がどの規則で通っているかを見る
Transition の本当の価値はログです。公式ドキュメントでは、Transition モードで診断ログを有効にすると、接続が NSP 構成で許可されたのか、リソース側設定で許可されたのかを把握できるとされています。NSPAccessLogs には、公開インバウンド / アウトバウンドの許可・拒否だけでなく、Private Endpoint トラフィックや境界内通信に関するカテゴリもあるため、「本当に NSP 化できるか」を客観的に判断しやすくなります。 (マイクロソフト ラーン)
必要最小限のインバウンド / アウトバウンド規則を作る
NSP のアクセス ルールは、公開インバウンドを IP アドレスやサブスクリプション、公開アウトバウンドを FQDN で制御します。CMK のように Service Bus と Key Vault を同じ境界に入れられるケースでは、余計な境界外例外を増やさずに済むことがあります。逆に、境界外へ出る通信先を十分に洗い出せていないと、Enforced で想定外の拒否が発生します。 (マイクロソフト ラーン)
問題がないことを確認してから Enforced に移す
公開アクセスを本当に境界ルールだけに従わせたいなら、最後に Enforced モードへ切り替えます。関連付け後は、Azure CLI で publicNetworkAccess が SecuredByPerimeter になっているか確認すると分かりやすいです。 (マイクロソフト ラーン)
az servicebus namespace network-rule-set show --name <namespace-name> --resource-group <resource-group>Service Bus の関連付け確認では、関連付け済みの状態で publicNetworkAccess が SecuredByPerimeter と表示されます。 (マイクロソフト ラーン)
導入時に特に注意したい落とし穴
| 落とし穴 | 起きやすい問題 | 実務での対策 |
|---|---|---|
| Transition を「もう安全」と誤解する | 既存のリソース側設定にフォールバックしており、完全に閉じていない | Transition は短期の観測用と割り切る |
| Private Endpoint の代替だと思う | private IP にはならず、用途がずれる | VNet 内接続は Private Endpoint を主役にする |
| SAS 接続文字列をそのまま前提にする | 認証エラーが出るパターンがある | Entra ID / Managed Identity への見直しを含めて検証する |
| Geo-DR の片側だけ境界へ入れる | 旧 Geo-disaster recovery のペアリングに失敗する | Primary と Secondary を同じ境界へ関連付ける |
| サービス エンドポイント前提で進める | NSP 制約とぶつかり通信が不安定になる | 検証を先行し、必要に応じて Private Endpoint を検討する |
| ログ保存先を境界外に置く | ログが流れなくなる | Log Analytics / Storage / Event Hubs の配置を見直す |
この注意点は、Service Bus 向け NSP ドキュメント、NSP 全体の制限事項、移行ガイド、診断ログ資料に基づくものです。導入時に一番多い失敗は、ネットワーク設定だけ見て認証と依存関係を後回しにすることです。 (マイクロソフト ラーン)
特に認証は要注意です。Microsoft は、境界内通信やサブスクリプション ベースのインバウンド ルールでは SAS トークン認証がサポートされず、要求が認証エラーになる場合があると案内しています。Service Bus を接続文字列ベースで広く使っている環境ほど、「ネットワークは正しそうなのに接続できない」という見えにくい障害になりやすいため、先に棚卸ししておく価値があります。 (マイクロソフト ラーン)
Geo-DR も見落とされやすい点です。legacy Geo-disaster recovery（alias ベースのペアリング）を使っている場合、Primary と Secondary の両方を同じ NSP に関連付けないとペアリングが失敗します。片側だけ段階導入する設計は避けたほうが安全です。 (マイクロソフト ラーン)
ポータルや設定作業中に “This feature isn’t available for given subscription” が出た場合、公式ドキュメントでは feature flag の登録が案内されています。該当する場合は、次のコマンドを順に実行してから再確認します。 (マイクロソフト ラーン)
az feature register --namespace Microsoft.Network --name AllowNspLink
az feature register --namespace Microsoft.Network --name EnableServiceTagsInNsp
az provider register -n Microsoft.Networkもう 1 つ、IaC 運用では publicNetworkAccess に SecuredByPerimeter を先に入れすぎないことが大切です。公式資料では、この値を設定すると公開アクセスがロックダウンされ、境界やルールが整う前の段階では必要な通信まで閉じる可能性があります。新規 namespace 作成時は、「関連付け」「ルール投入」「疎通確認」の順序を playbook 化しておくと事故を減らせます。 (マイクロソフト ラーン)
いま取るべき次の一手
Azure Service Bus のネットワーク セキュリティ境界 GA は、単なる新機能追加ではなく、Service Bus の守り方を「個別設定」から「PaaS 群の境界管理」へ広げるアップデートです。CMK、監査、データ流出対策が課題なら、まずは検証環境で Transition モードに関連付け、診断ログを有効にし、SAS 依存・Private Endpoint との役割分担・Geo-DR の整合性を確認してから Enforced へ進めるのが最も現実的です。逆に、固定 IP 数本だけを許可できれば足りる小規模環境では、IP ファイアウォールのままのほうが運用は軽いこともあります。自社にとって必要なのが「閉域接続」なのか「境界単位の統制」なのかを先に切り分けると、Azure Service Bus のセキュリティ設計はかなり整理しやすくなります。 (Microsoft)
コメント