Azure Service Bus のネットワークセキュリティを見直すなら、まず押さえるべき答えはシンプルです。Service Bus は「認証だけ」ではなく、Service tags、IP firewall rules、service endpoints、private endpoints、Network Security Perimeter を組み合わせて、接続元・経路・PaaS間通信の境界を設計する必要があります。
Microsoft 公式ドキュメント「Network security for Azure Service Bus」は 2026年4月23日に更新され、Azure Service Bus のネットワーク保護機能を整理しています。特に注目すべきは、ServiceBus サービスタグの扱い、Premium tier 前提の仮想ネットワーク統合、Private Endpoint、そして Network Security Perimeter です。security admins、identity teams、compliance teams は、それぞれ「ネットワーク経路」「認証方式」「監査証跡」の観点で既存構成を棚卸しするべきタイミングです。(Microsoft Learn)
Azureの最新動向: Network Security for Azure Service Busで何が変わったか
2026年4月更新のポイントは、「まったく新しい単一機能が追加された」というより、Azure Service Bus のネットワークセキュリティを構成する主要機能を、現在の設計判断に使いやすい形で確認できるようになった点にあります。
Microsoft 公式ページでは、Azure Service Bus のネットワークセキュリティ機能として、Service tags、IP firewall rules、network service endpoints、private endpoints、Network Security Perimeter が取り上げられています。Service Bus の名前空間を保護する場合、これらを個別機能として見るのではなく、次の3層で整理すると判断しやすくなります。
| 層 | 主な目的 | 代表的な機能 | 担当チーム |
|---|---|---|---|
| 認証・認可 | 誰が Service Bus を利用できるかを制御する | Microsoft Entra ID、RBAC、SAS | identity teams |
| ネットワーク到達制御 | どのIP・VNet・経路から接続できるかを制御する | IP firewall rules、service endpoints、private endpoints | security admins |
| PaaS境界・監査 | PaaS間通信や外部公開ルールを境界で管理する | Network Security Perimeter、診断ログ | compliance teams |
重要なのは、どれか1つを入れれば安全になるわけではないことです。たとえば、IPアドレス制限をしてもSASキーが長期間使い回されていればリスクは残ります。逆に Microsoft Entra ID を使っていても、名前空間がすべてのネットワークから到達可能なままでは、不要な攻撃面を残すことになります。
Service tags：ServiceBusタグは全tierを前提に見直す
Service tag は、Azure サービスが使うIPアドレスプレフィックスのまとまりです。Microsoft がアドレス範囲を管理し、変更に応じて自動更新するため、NSG や Azure Firewall のルールで個別IPを追い続ける負担を減らせます。(Microsoft Learn)
Azure Service Bus では ServiceBus サービスタグを利用できます。公式ドキュメントでは、ServiceBus タグは Azure Service Bus traffic を表し、outbound 方向で利用でき、リージョンスコープと Azure Firewall に対応すると説明されています。ここでいう outbound は、Azure Virtual Network から Service Bus へ出ていく通信を意味します。(Microsoft Learn)
特に見落としやすい更新ポイントは、ServiceBus サービスタグの対象範囲です。以前は Premium tier の名前空間のIPアドレスだけが含まれていましたが、現在は tier に関係なく、すべての名前空間のIPアドレスが含まれると明記されています。(Microsoft Learn)
実務での判断基準
ServiceBus サービスタグは、次のような場面で有効です。
| 利用シーン | 使い方 | 注意点 |
|---|---|---|
| Azure VM や AKS から Service Bus へ送信する | NSG や Azure Firewall の宛先に ServiceBus を指定する | 特定の名前空間だけを許可する機能ではない |
| 複数リージョンの Service Bus を使う | リージョンスコープの利用を検討する | 対象リージョンを誤ると通信障害になる |
| IPレンジ管理を減らしたい | 個別IPではなくサービスタグでルール化する | 監査用には、なぜ許可しているかの説明が必要 |
ただし、Service tag は「接続先サービスのIP範囲を扱いやすくする仕組み」であり、認証や名前空間単位のアクセス制御の代わりではありません。Microsoft も、Service Tags だけではトラフィックの性質を考慮した保護として十分ではないと注意しています。(Microsoft Learn)
IP firewall rules：固定IPからの接続に向くが、運用変更に弱い
Azure Service Bus は、既定では有効な認証・認可を持つリクエストであればインターネットから名前空間へアクセスできます。IP firewall rules を使うと、許可する接続元を特定の IPv4 アドレスまたは CIDR 形式のIPv4アドレス範囲に制限できます。(Microsoft Learn)
IP firewall rules は、オンプレミス環境、企業NAT、ExpressRoute 経由の固定出口IPなど、「接続元が明確に分かっている」構成に向いています。たとえば、社内データセンターから Service Bus にメッセージを送る業務システムでは、社内のNATゲートウェイのグローバルIPだけを許可する設計が現実的です。
Service Bus の IP firewall rules は名前空間レベルで適用され、サポートされるプロトコルを使うすべてのクライアント接続に影響します。許可ルールに一致しないIPアドレスからの接続は unauthorized として拒否されますが、応答にはIPルールが原因であることは明示されません。障害調査では、認証エラーだけでなくネットワークルールも同時に確認する必要があります。(Microsoft Learn)
IP firewall rulesで失敗しやすいポイント
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| 開発者の一時的な自宅IPを許可したままにする | 退職・異動後も不要な経路が残る | 期限付きの例外管理にする |
| NATゲートウェイ変更を反映しない | 本番アプリが突然接続できなくなる | ネットワーク変更時のチェックリストに Service Bus を含める |
| Selected networks に切り替えた後、必要なIPやVNetを追加しない | 正規アプリまで接続できなくなる | 事前に検証環境で通信確認する |
| IP制限だけで十分と考える | SASキー漏えい時の影響が大きい | Microsoft Entra ID と RBAC を併用する |
Standard tier でも IP filtering は利用できますが、Private Endpoints と Service Endpoints は Premium tier でサポートされる機能です。Premium へ移行できない環境では、IP firewall rules と認証強化を組み合わせるのが現実的な第一歩になります。(Microsoft Learn)
Service endpointsとPrivate endpointsの違いを正しく選ぶ
Azure Service Bus のネットワーク統合では、service endpoints と private endpoints を混同しやすいです。どちらも「VNet から安全に Service Bus にアクセスする」ための機能ですが、設計思想が異なります。
| 比較項目 | Service endpoints | Private endpoints |
|---|---|---|
| 接続の考え方 | VNetサブネットから Service Bus への経路を制限する | Service Bus をVNet内のプライベートIPで到達可能にする |
| Service Busの見え方 | サービスエンドポイント自体はパブリックIP範囲に見える | Private Link 経由のプライベートIPで見える |
| 主な用途 | 特定サブネットからのアクセスだけを許可したい | パブリック公開を極力なくしたい |
| 対象tier | Premium tier | Premium tier |
| 注意点 | Standard tier と Premium tier を混在させるアプリでは設計に注意 | DNS設計、他Azureサービス連携、承認状態の確認が必要 |
Service endpoints を構成すると、Service Bus 名前空間は承認された仮想ネットワーク以外からのトラフィックを受け付けない構成にできます。ただし、Service Bus の仮想ネットワーク機能は Premium tier の名前空間でサポートされるため、Standard tier と Premium tier の名前空間を混在させるアプリケーションでは注意が必要です。(Microsoft Learn)
Private endpoints は、Azure Private Link を使って Service Bus へプライベートに接続する仕組みです。プライベートエンドポイントはVNet内のプライベートIPを使うため、Service Bus を実質的に自社VNet内のリソースのように扱えます。通信は Microsoft backbone network を通り、パブリックインターネットへの露出を避けやすくなります。(Microsoft Learn)
どちらを選ぶべきか
判断基準は次の通りです。
| 要件 | 推奨しやすい選択 |
|---|---|
| 「特定サブネットからのみ接続」を実現したい | Service endpoints |
| 「Public network access を無効化したい」 | Private endpoints |
| 名前空間をインターネットから到達不能に近づけたい | Private endpoints |
| 既存のVNet境界を使って段階的に絞り込みたい | Service endpoints |
| DNS、承認、Private Link 運用を整備できる | Private endpoints |
実務では、機密性の高い業務メッセージ、金融・医療・公共系の連携、顧客データを含むイベント処理では Private endpoints を優先して検討する価値があります。一方、既存システムの移行途中で、まずVNetベースの制限を導入したい場合は service endpoints が現実的な選択になることがあります。
Network Security Perimeter：PaaS間通信の境界を監査しやすくする
Network Security Perimeter は、PaaS リソースの周囲に論理的な境界を作り、境界内のリソース間通信や外部公開ルールを制御する考え方です。Azure Service Bus の名前空間を Network Security Perimeter に含めることで、Service Bus と Azure Key Vault など他の PaaS リソースとの通信を境界として扱いやすくなります。(Microsoft Learn)
Service Bus 向けの Network Security Perimeter では、同じ perimeter に関連付けられた PaaS リソース同士の通信を基本としつつ、外部との inbound / outbound 通信を明示的なアクセスルールで許可できます。また、perimeter 内の PaaS リソースでは監査・コンプライアンス向けの診断ログが有効になると説明されています。(Microsoft Learn)
compliance teamsが見るべきポイント
Network Security Perimeter は、単なるネットワーク制限ではなく、監査説明に向いた境界管理です。次のような観点で整理すると、監査対応がしやすくなります。
| 監査観点 | 確認する内容 |
|---|---|
| 境界の妥当性 | Service Bus、Key Vault、関連PaaSが同じ perimeter に含まれているか |
| 外部通信の根拠 | 例外的に許可した inbound / outbound ルールの理由が文書化されているか |
| CMK利用 | Customer-managed keys 利用時に Key Vault との通信要件が満たされているか |
| DR構成 | 旧来の geo-disaster recovery pairing で primary / secondary が同じ perimeter に関連付いているか |
| Private Link | Private endpoint 経由の通信は NSP ルールの対象外であることを理解しているか |
公式ドキュメントでは、legacy geo-disaster recovery の pairing では primary と secondary の名前空間を同じ Network Security Perimeter に関連付ける必要があること、また Network Security Perimeter rules は private endpoints 経由の Private Link トラフィックを管理しないことが示されています。(Microsoft Learn)
確認コマンドの例は次の通りです。
az servicebus namespace network-rule-set show \
--name <namespace-name> \
--resource-group <resource-group>Network Security Perimeter との関連付けがある場合、publicNetworkAccess フィールドに SecuredByPerimeter が表示されます。(Microsoft Learn)
identity teamsはMicrosoft Entra IDとSASの扱いを同時に見直す
ネットワーク制御を強化しても、認証方式が古いままではリスクは残ります。Azure Service Bus の認証・認可には、Microsoft Entra ID と Shared Access Signature、つまり SAS の2方式があります。Microsoft Entra ID 統合では、Azure RBAC を使ってユーザー、グループ、アプリケーション、マネージドIDに Service Bus リソースへの権限を付与できます。(Microsoft Learn)
Microsoft は、可能な場合は Azure Service Bus アプリケーションで Microsoft Entra ID を使うことを推奨しています。理由は、コード内にトークンを保存する必要がなく、SAS よりもセキュリティと使いやすさの面で優れているためです。(Microsoft Learn)
SASからMicrosoft Entra IDへ移行する実務ステップ
| 手順 | 作業内容 | チェックポイント |
|---|---|---|
| 既存接続の棚卸し | 接続文字列、SASトークン、SASポリシーを洗い出す | 本番・検証・バッチ・外部連携を漏らさない |
| RBAC設計 | Sender、Receiver、Owner を最小権限で割り当てる | 管理権限をアプリに与えすぎない |
| アプリ修正 | 接続文字列から DefaultAzureCredential などへ移行する | ローカル開発、本番、CI/CDで認証方法を確認する |
| 並行稼働テスト | SASを残した状態で Entra ID 認証を確認する | メッセージ送受信、再接続、スケール時の挙動を見る |
| local authentication無効化 | 問題がなければSASキー認証を無効化する | 例外アプリが残っていないか確認する |
| 不要SASポリシー削除 | 使わないSASポリシーを整理する | 誤って再有効化された場合の攻撃面を減らす |
Service Bus では local authentication、つまり SAS key authentication を無効化し、Microsoft Entra ID のみを使う構成にできます。Microsoft 公式ドキュメントでは、SASキーは長期間有効な共有シークレットであり、漏えい時には手動ローテーションまでアクセスされるリスクがある一方、Microsoft Entra ID は短命トークン、細かなRBAC、監査証跡、条件付きアクセスを利用できると説明されています。(Microsoft Learn)
確認コマンドの例は次の通りです。
az servicebus namespace show \
--resource-group <resource-group-name> \
--name <namespace-name> \
--query disableLocalAuthlocal authentication を無効化する前に、すべてのアプリケーションが Microsoft Entra ID 認証に移行済みであることを確認してください。先に無効化すると、接続文字列に依存しているバッチや外部連携が停止する可能性があります。(Microsoft Learn)
security adminsが今すぐ確認すべき構成チェックリスト
Azure Service Bus のネットワークセキュリティを更新観点で見直す場合、最初にやるべきことは設定変更ではなく棚卸しです。いきなり Private Endpoint 化や firewall 変更を行うと、依存サービスが見えないまま障害を起こすことがあります。
名前空間ごとの棚卸し項目
| 確認項目 | 確認理由 |
|---|---|
| tier | Service endpoints / Private endpoints / VNet機能の利用可否に影響する |
| region | service tag のリージョンスコープ、DR、Private Endpoint配置に関係する |
| Public network access | All networks、Selected networks、Disabled、SecuredByPerimeter の把握 |
| IP firewall rules | 不要な許可IP、広すぎるCIDR、退役済み拠点の有無を確認する |
| VNet rules | 対象サブネットが正しいか、不要なサブネットが残っていないか確認する |
| Private endpoint connections | 承認状態、DNS解決、利用中アプリを確認する |
| Trusted Microsoft services | 有効化理由と Managed Identity / RBAC の整合性を確認する |
| local authentication | SAS依存が残っていないか確認する |
| Network Security Perimeter | perimeter関連付け、外部通信ルール、診断ログを確認する |
Private endpoints や firewall rules を有効にすると、他の Azure サービスから Service Bus への連携に影響することがあります。Trusted Microsoft services を使う場合も、Microsoft は Managed Identity を割り当てることを重要事項として示しています。(Microsoft Learn)
グローバル環境ではIP範囲を手作業で固定しない
グローバル企業や複数リージョン利用の環境では、Service Bus のネットワーク設計で「IP範囲をExcelに貼って管理する」運用は避けるべきです。Service tags はクラウドやリージョンによって範囲が異なり、Microsoft は Service Tag Discovery API やJSONファイルで最新情報を提供しています。(Microsoft Learn)
特に、Azure Public、Azure US Government、中国リージョンなどをまたぐ場合、同じタグ名でも基盤となるIP範囲はクラウドごとに異なる可能性があります。グローバル読者向けの運用では、次の方針が現実的です。
| 方針 | 理由 |
|---|---|
| Service tag を優先する | IP変更への追随コストを下げられる |
| 例外IPは期限を付ける | 一時対応が恒久化するのを防げる |
| リージョンスコープを検討する | 不要なリージョン宛て通信を減らせる |
| Azure Firewall / NSG / Policy の証跡を残す | 監査時に「なぜ許可しているか」を説明できる |
| 定期的に到達性テストを行う | サービスタグ更新、DNS変更、Private Endpoint変更の影響を検知できる |
構成パターン別のおすすめ設計
Service Bus のネットワークセキュリティは、すべての環境で Private Endpoint が最適とは限りません。要件に応じて、段階的に選ぶのが実務的です。
| 構成パターン | 推奨構成 | 補足 |
|---|---|---|
| 小規模な社内バッチから送信 | IP firewall rules + Microsoft Entra ID | 固定出口IPがある場合に導入しやすい |
| Azure VM / AKS / App Service から利用 | Premium + Private Endpoint または service endpoints | App Service / Functions はVNet統合も含めて設計する |
| 機密データを含む業務連携 | Premium + Private Endpoint + local auth無効化 | DNS、RBAC、監査ログまでセットで確認する |
| Key VaultのCMKを使う | Network Security Perimeter の利用を検討 | Service Bus と Key Vault のPaaS境界を説明しやすい |
| 複数部門・複数国で利用 | Service tags + Azure Policy + 定期レビュー | 手作業IP管理を減らし、例外管理を明確にする |
よくある誤解と対策
| 誤解 | 正しい理解 | 対策 |
|---|---|---|
| Service tagを許可すれば名前空間単位で安全になる | Service tag はサービスのIP範囲であり、特定名前空間の認可ではない | RBAC、firewall、Private Endpoint と組み合わせる |
| Standard tierでもPrivate Endpointを使える | Service Bus の Private Endpoint は Premium tier でサポートされる | tier変更またはIP firewall rulesで代替する |
| IP制限を入れればSASキー管理は後回しでよい | SASキー漏えい時の影響は依然として大きい | Microsoft Entra ID移行とlocal auth無効化を計画する |
| Private EndpointにすればDNSは自動で問題ない | DNS解決が誤るとpublic経路へ向いたり接続失敗したりする | Private DNS Zone と名前解決経路を検証する |
| Network Security PerimeterがPrivate Linkも制御する | NSP rules は private endpoints 経由の Private Link トラフィックを管理しない | NSPとPrivate Endpointを別レイヤーとして設計する |
| Trusted servicesを有効にすれば連携はすべて安全 | Managed Identity とRBAC設定が必要 | 連携サービスごとにIDとロールを確認する |
次に取るべき行動
Azure Service Bus の2026年4月更新ポイントを受けて、まずやるべきことは既存名前空間の棚卸しです。特に、ServiceBus サービスタグの前提変更、Premium tier で利用できる Private Endpoint / Service Endpoint、Network Security Perimeter、SASから Microsoft Entra ID への移行状況を一体で確認してください。
実務では、次の順番で進めると失敗しにくくなります。
- すべての Service Bus 名前空間について、tier、region、public network access、IP/VNetルール、Private Endpoint、NSP関連付けを一覧化する。
- All networks のまま残っている名前空間を特定し、Selected networks、Disabled、SecuredByPerimeter のどれを目標にするか決める。
- identity teams と連携し、SAS依存アプリを Microsoft Entra ID と Managed Identity に移行する。
- security admins が Service tags、IP firewall rules、Private Endpoint、DNSを検証環境で確認する。
- compliance teams が Azure Policy、診断ログ、RBAC、例外ルールの証跡を監査用に整理する。
Azure Service Bus のネットワークセキュリティは、単なる「ファイアウォール設定」ではありません。認証、ネットワーク経路、PaaS境界、監査をまとめて設計することで、実運用に耐えるセキュリティ水準に近づけられます。
コメント