MENU

Azure Event HubsのNetwork Security Perimeter対応がGA｜影響範囲と設定手順

Azure

Azure Event HubsのNetwork Security Perimeter（NSP）対応が一般提供され、Event HubsをほかのAzure PaaSサービスと同じ論理的な境界で保護できるようになりました。

結論からいうと、今回の対応によって既存のEvent Hubsが自動的に遮断されるわけではありません。管理者がEvent Hubs名前空間をNSPに関連付け、アクセスモードや許可ルールを設定することで有効になります。

ただし、導入時にいきなり強制モードへ切り替えるのは危険です。既存のIPファイアウォールや信頼済みサービスの許可に依存する通信、Capture先のStorage、カスタマー管理キーで使用するKey Vaultへの通信が停止する可能性があります。基本方針は、Transitionモードで通信を可視化し、必要なルールを補ってからEnforcedモードへ移行することです。(Microsoft Azure)

目次

Azure Event HubsのNetwork Security Perimeter対応とは

Network Security Perimeterは、Azure PaaSリソースを論理的なセキュリティ境界にまとめ、境界内の通信と境界外からのパブリック通信を一元管理する仕組みです。

今回の一般提供により、Azure Event Hubsの名前空間をNSPへ関連付け、次のような制御ができるようになりました。

  • 境界外からEvent Hubsへ到達するパブリック受信通信の制限
  • Event HubsからStorageやKey Vaultへ向かうパブリック送信通信の制限
  • 同一NSPに属するPaaSリソース間の通信許可
  • プロファイル単位でのアクセスルール一元管理
  • 許可、拒否、既存リソースルールへのフォールバック状況のログ記録

NSPは単一リソースのファイアウォール設定ではありません。複数のPaaSリソースを「同じ信頼境界に属するか」という観点で管理できることが大きな違いです。(Microsoft Learn)

2026年7月8日という日付の扱い

Azure Updatesの当該情報は、2026年7月8日時点で公開または更新された公式情報として確認できます。一方、Azure Updatesの一覧では提供時期が「July 2025」と表示されています。

そのため、2026年7月に初めて一般提供されたと断定するよりも、2026年7月8日時点で一般提供状況と機能内容が公式に再確認できた更新として捉えるのが適切です。(Microsoft Azure)

NSPが保護するEvent Hubsの通信範囲

NSPで管理される対象は、個々のイベントハブではなくEvent Hubs名前空間です。1つの名前空間を複数チームや複数システムで共有している場合、NSPの設定変更が広範囲に影響する点に注意してください。

通信の種類NSPによる制御主な対象
パブリック受信通信IPアドレス、サブスクリプション、境界所属などで許可プロデューサー、コンシューマー、Kafkaクライアント
パブリック送信通信送信先FQDNや境界所属で許可Capture先のStorage、CMK用Key Vault
同一NSP内の通信境界内通信として許可Event Hubsと関連PaaSリソース
Private Endpoint経由の通信NSPのパブリックアクセスルールの影響を受けない仮想ネットワーク内のクライアント
認証・認可NSPとは別に必要Microsoft Entra ID、Azure RBAC、SAS

Event Hubsへのパブリック受信通信

NSPでは、インターネットや境界外のAzureリソースからEvent Hubsへ接続する通信を制御できます。

主な許可方法は次のとおりです。

  • 送信元IPアドレスによる許可
  • Azureサブスクリプションによる許可
  • 同一NSP内のリソースとしての許可

たとえば、固定グローバルIPを持つオンプレミス環境からイベントを送信している場合は、IPベースの受信ルールを使用できます。一方、Azure上のアプリケーションから接続する場合は、Microsoft Entra IDとマネージドIDを組み合わせ、リソースやサブスクリプションを識別できる構成が適しています。

Event Hubsからのパブリック送信通信

NSPは受信通信だけでなく、Event Hubsサービスから外部へ向かう通信も制御します。

特に確認が必要なのは、次の2つです。

  • Event Hubs CaptureによるAzure StorageまたはAzure Data Lake Storageへの書き込み
  • カスタマー管理キーを使用するためのAzure Key Vaultへのアクセス

これらの送信先が同じNSPに属していない場合、必要なFQDNへの送信ルールを用意しなければなりません。

受信側のプロデューサーやコンシューマーだけを確認し、サービス側の送信通信を見落とすと、「イベントの送受信は成功するがCaptureファイルが作成されない」「暗号化キーを取得できない」といった障害につながります。(Microsoft Learn)

同一NSP内のPaaS間通信

Event Hubs、Storage、Key Vaultなどを同じNSPに関連付けることで、同一の論理的な信頼境界として扱えます。

ただし、同じNSPに入れただけで認証が不要になるわけではありません。通信元にはマネージドIDなどのIDを付与し、送信先ではAzure RBACやアクセスポリシーを適切に設定する必要があります。

NSPは「ネットワーク的に到達できるか」を制御する仕組みであり、「誰が何を実行できるか」という認証・認可を置き換える機能ではありません。Microsoft Entra IDとAzure RBACを併用することが基本です。(Microsoft Learn)

既存のファイアウォールやPrivate Endpointとの違い

NSPを導入しても、Event HubsのIPファイアウォールやPrivate Endpointが不要になるわけではありません。それぞれ役割が異なります。

機能主な目的受信通信送信通信適した用途
Network Security Perimeter複数PaaSリソースの論理的な境界管理対応対応PaaS間通信とパブリック例外の一元管理
IPファイアウォール特定IPからの接続制限対応対象外固定IPを持つオンプレミスや外部システム
仮想ネットワークルール指定サブネットからの接続制限対応対象外Service Endpointを利用する既存構成
Private Endpoint仮想ネットワーク内のプライベートIPで接続対応対象外パブリック経路を使わない厳格な閉域接続
Azure RBAC操作権限の制御認可認可送信、受信、管理権限の最小化

Private Endpoint経由の通信は、NSPのパブリックアクセスルールとは独立して扱われます。そのため、仮想ネットワークからEvent Hubsへ接続する主要経路にはPrivate Endpointを使い、例外的なパブリック通信やPaaS間の境界管理をNSPで制御する構成が現実的です。(Microsoft Learn)

なお、NSPではService Endpointを利用した通信に制約があります。仮想マシンなどのIaaS環境からPaaSへプライベートに接続する用途では、Private Endpointを優先して検討してください。(Microsoft Learn)

管理者が設定する項目

Event HubsでNSPを利用するには、NSPを作成するだけでは不十分です。プロファイル、リソース関連付け、アクセスモード、受信・送信ルール、診断設定を組み合わせます。

NSPとプロファイルを設計する

NSPは論理的な境界本体であり、プロファイルはアクセスルールを管理する単位です。

開発、検証、本番をすべて1つのプロファイルにまとめると、検証用の例外ルールが本番環境にも適用されやすくなります。次のように環境や機密度で分けるのが基本です。

  • 本番環境
  • ステージング環境
  • 開発・検証環境
  • 高機密データを扱う環境
  • 外部連携を多く持つ環境

「同じ部門だから」という理由だけでまとめるのではなく、許可したい通信経路が同じかどうかで判断します。

Event Hubs名前空間を関連付ける

Azureポータルでは、Event Hubs名前空間のネットワーク設定からNetwork Security Perimeterとの関連付けを行います。英語表示では、おおむね次の順序です。

  1. Event Hubs名前空間を開く
  2. 「Networking」を開く
  3. 「Public access」を選択する
  4. 「Network security perimeter」を開く
  5. NSPとプロファイルを指定する
  6. アクセスモードを選択する

関連付け候補には、原則としてEvent Hubs名前空間と同じリージョンのNSPが表示されます。目的のNSPが表示されない場合は、権限だけでなくリージョンも確認してください。

設定には、Event Hubs名前空間側でContributor相当以上、NSP側でNetwork Security Perimeter Contributor相当以上の権限が必要です。(Microsoft Learn)

受信ルールと送信ルールを作成する

受信ルールでは、Event Hubsへの接続元を定義します。

  • 固定グローバルIPから接続する場合はIPルール
  • Azureリソースから接続する場合はサブスクリプションまたは境界所属
  • 同一NSP内のリソースから接続する場合はマネージドIDを利用

送信ルールでは、Event Hubsから境界外へアクセスする必要がある宛先をFQDNで許可します。

代表的な確認先は次のとおりです。

  • Event Hubs Captureの保存先
  • カスタマー管理キーを保管するKey Vault
  • 診断ログの保存先
  • 運用上必要な外部PaaSリソース

広いFQDNや不要なIP範囲をまとめて許可するのではなく、実際に使用するリソースへ限定してください。

TransitionとEnforcedの違い

NSPの導入では、アクセスモードの選択が最も重要です。

モードNSPルールに一致しない通信主な用途
Transition既存のリソースファイアウォールや信頼済みアクセス設定による判定へフォールバック影響調査、ルール設計、移行準備
EnforcedNSPで許可されていないパブリック通信を拒否本番での境界強制

Transitionモードでは、NSPのルール評価を行いながら、既存のEvent Hubsネットワーク設定による通信を継続できます。既存環境を止めずに、「Enforcedへ移行した場合に不足するルール」をログから確認するためのモードです。

Enforcedモードへ切り替えると、NSPで許可されなかった通信は、既存のリソース設定だけでは通過できません。また、Transition時に利用できていた信頼済みアクセスへのフォールバックも使用できなくなります。(Microsoft Learn)

そのため、次の順序を守る必要があります。

  1. Transitionモードで関連付ける
  2. 診断ログを有効にする
  3. 通常時とピーク時の通信を記録する
  4. 不足している受信・送信ルールを追加する
  5. プロデューサー、コンシューマー、Capture、Key Vaultをテストする
  6. Enforcedモードへ切り替える
  7. 拒否ログとアプリケーションエラーを継続監視する

SAS認証を利用している環境は特に注意する

Event Hubsでは、接続文字列とSASトークンを使った認証が広く利用されています。しかし、NSPのすべての許可方式がSASに対応するわけではありません。

同一境界内のリソース判定、境界間通信、サブスクリプションベースの受信ルールは、SAS認証では正常に機能せず、認証エラーになる場合があります。(Microsoft Learn)

これは、SAS接続がすべて利用できなくなるという意味ではありません。固定IPを使った許可などで接続できる構成もあります。ただし、NSPのリソース単位の制御を十分に活用するには、Microsoft Entra IDとマネージドIDへの移行が必要です。

移行前には、次の項目を確認してください。

  • プロデューサーが接続文字列を使用していないか
  • コンシューマーグループの読み取り処理がSASに依存していないか
  • Kafkaクライアントの認証方式
  • Azure FunctionsやStream Analyticsなどの接続方式
  • ローカル認証を無効化できるか
  • 必要なAzure RBACロールを割り当て済みか

SASを大量に利用している環境では、NSPのEnforced化と認証方式の移行を同日に実施しない方が安全です。まず認証方式を移行し、その後にネットワーク境界を強制すると、障害原因を切り分けやすくなります。

監査ログと検知への影響

NSPを関連付けただけでは、監査に必要なログが自動的に長期保存されるとは限りません。診断設定を作成し、Log Analyticsワークスペース、Storageアカウント、Event Hubsなどへ送信する必要があります。

NSPのアクセスログでは、主に次の情報を確認できます。

  • 通信が受信か送信か
  • NSPで許可または拒否されたか
  • 既存リソースルールへフォールバックしたか
  • 一致したルール
  • 送信元IPアドレス
  • 送信元リソースID
  • アプリケーションID
  • 送信先FQDN
  • 対象のEvent Hubs名前空間

Log Analyticsへリソース固有テーブルとして保存した場合、NSPAccessLogsテーブルを使用できます。ログは複数の通信が集約されることがあるため、Countが存在する場合は件数として集計し、値がない場合は1件として扱います。(Microsoft Learn)

Enforced移行前に不足ルールを探すKQL

Transitionモードでは、NSPルールには一致しなかったものの、既存のEvent Hubs側ルールによって許可された通信を探します。

NSPAccessLogs
| where ServiceResourceId has "/providers/Microsoft.EventHub/namespaces/"
| where Category in (
    "NspPublicInboundResourceRulesAllowed",
    "NspPublicOutboundResourceRulesAllowed"
)
| extend EventCount = iff(isnull(Count), tolong(1), Count)
| summarize Attempts = sum(EventCount)
    by ServiceResourceId,
       Category,
       SourceIpAddress,
       SourceResourceId,
       DestinationFqdn,
       MatchedRule
| order by Attempts desc

この結果に表示される通信は、Enforcedモードへ移行すると停止する可能性があります。

ただし、検出された通信を無条件にすべて許可してはいけません。次の3つに分類してください。

  1. 業務上必要な通信
  2. 移行期間中だけ必要な通信
  3. 不要または送信元を特定できない通信

必要な通信だけをNSPルールへ追加し、不明な通信はアプリケーション所有者やログ情報から送信元を確認します。

Enforced移行後の拒否を検知するKQL

NSPAccessLogs
| where ServiceResourceId has "/providers/Microsoft.EventHub/namespaces/"
| where Category in (
    "NspPublicInboundPerimeterRulesDenied",
    "NspPublicOutboundPerimeterRulesDenied"
)
| extend EventCount = iff(isnull(Count), tolong(1), Count)
| summarize Denied = sum(EventCount)
    by bin(TimeGenerated, 15m),
       ServiceResourceId,
       Category,
       SourceIpAddress,
       SourceResourceId,
       DestinationFqdn
| order by TimeGenerated desc

次のような拒否は、優先的にアラート対象とします。

  • 通常利用しているプロデューサーのIPアドレスからの受信拒否
  • Capture先Storageへの送信拒否
  • Key Vaultへの送信拒否
  • デプロイ直後に急増した拒否
  • 送信元を特定できない大量アクセス
  • 複数のEvent Hubs名前空間で同時に発生した拒否

NSPログはネットワーク境界の判定結果を示すものです。誰がイベントを送信・受信したかを詳細に追跡するには、Event Hubsのメトリック、アプリケーションログ、利用可能な場合はランタイム監査ログも組み合わせます。(Microsoft Learn)

ログ保存先も同じ境界設計に含める

診断ログの保存先がNSPの外側にある場合、ログ送信自体が停止する可能性があります。ログを送るLog Analyticsワークスペース、Storageアカウント、Event Hubsについても、同一NSPへの関連付けや必要な送信ルールを確認してください。(Microsoft Learn)

Microsoft Sentinelを有効にしたLog AnalyticsワークスペースをNSPへ関連付ける設計には制約があります。公式ドキュメントでは、Sentinelが有効なワークスペースでNSPを有効化すると分析ルールが無効化される可能性が示されています。

これは、NSPログをSentinelで分析してはいけないという意味ではありません。ログ保存先となるワークスペース自体をNSPへ関連付ける場合に、事前検証が必要ということです。(Microsoft Learn)

対応要否を判断するチェック表

すべてのEvent Hubs環境で、直ちにNSPをEnforcedモードにする必要はありません。現在の公開範囲、データの重要度、既存のPrivate Endpoint利用状況によって優先度を判断します。

現在の構成主なリスク推奨対応優先度
パブリックアクセスが有効で、多数のIPを許可している許可範囲の肥大化、設定の分散NSP導入を優先し、Transitionで通信を棚卸しする高
CaptureまたはCMKを使用している送信ルール不足による保存・暗号化障害StorageとKey Vaultを含めて事前検証する高
信頼済みサービスの例外に依存しているEnforced移行後に通信が停止する可能性実際の通信元とIDを特定し、明示ルールへ移行する高
SAS接続が中心サブスクリプションや境界ベースの判定を利用しにくいMicrosoft Entra ID移行計画を先に作る高
複数システムで名前空間を共有している変更時の影響範囲が大きい利用者を棚卸しし、必要なら名前空間を分割する高
Private Endpointのみで、パブリックアクセスも無効現在の外部露出は限定的中央統制の必要性を見て段階導入する中
開発・検証環境のみ本番への直接影響は小さい本番導入前のパイロット環境として利用する中
Geo-DRを使用しているNSPのサポート制約に該当現行構成のまま関連付けず、対応状況を確認する要注意

現時点では、Event HubsのGeo-disaster recoveryはNSPの制約事項として挙げられています。Geo-DR構成の名前空間へ、通常構成と同じ手順でNSPを適用しないでください。(Microsoft Learn)

推奨する導入手順

本番環境へ安全に導入するには、次の順番で進めます。

名前空間と依存関係を棚卸しする

最低限、次の項目を一覧化します。

  • サブスクリプション
  • リソースグループ
  • リージョン
  • Event Hubs名前空間
  • パブリックネットワークアクセスの状態
  • IPおよび仮想ネットワークルール
  • Private Endpointの有無
  • プロデューサーとコンシューマー
  • 認証方式
  • Captureの保存先
  • CMKのKey Vault
  • Geo-DRの利用状況
  • 診断ログの保存先
  • 管理部門とアプリケーション所有者

名前空間単位で影響するため、個々のイベントハブだけでなく、同じ名前空間を利用するすべてのシステムを対象にします。

小規模な名前空間でパイロットを実施する

利用者と通信経路を把握できている、影響の小さい非本番名前空間を選びます。

本番とまったく異なる構成では検証になりません。可能であれば、Capture、CMK、認証方式、Private Endpointなどが本番に近い名前空間を使用してください。

Transitionモードで関連付ける

最初からEnforcedを選ばず、Transitionで開始します。

関連付けと同時に診断設定も有効化し、通常の業務時間だけでなく、夜間バッチ、月次処理、ピーク時間帯などを含む一連の運用サイクルを確認します。

ログからルール候補を作成する

Transitionログから、既存設定へのフォールバックで許可されている通信を抽出します。

ルールを追加する際は、次の順で優先します。

  1. 同一NSPへのリソース関連付け
  2. Microsoft Entra IDとマネージドIDの利用
  3. サブスクリプション単位の明示許可
  4. 必要最小限のIPアドレス許可
  5. 必要最小限の送信先FQDN許可

広いIP範囲やFQDNを先に許可すると、NSPを導入しても境界が実質的に緩いままになります。

業務機能を個別にテストする

疎通確認だけでなく、次の業務処理を実行します。

  • プロデューサーからのイベント送信
  • コンシューマーによるイベント受信
  • Kafkaプロトコルを利用した送受信
  • コンシューマーグループごとの読み取り
  • Captureファイルの生成
  • Storageへの書き込み
  • Key Vaultからのキー取得
  • アプリケーション再起動後の再接続
  • スケールアウトしたインスタンスからの接続
  • 診断ログの継続受信

「ポートへ接続できる」だけでは、実際の業務処理が成功するとは限りません。

Enforcedへ切り替える

次の条件を満たした段階でEnforcedへ移行します。

  • 必要な通信元を特定できている
  • 不要な通信を除外できている
  • CaptureとCMKをテスト済み
  • SAS依存の扱いを決定済み
  • ログ送信経路を確認済み
  • 障害時の切り戻し手順がある
  • アプリケーション所有者へ変更日時を通知済み

切り替え直後は、NSPの拒否ログだけでなく、Event Hubsの受信数、送信数、サーバーエラー、スロットリング、アプリケーション側の再試行回数も確認します。

失敗しやすいポイント

失敗例発生する問題対策
最初からEnforcedにする未把握の通信が即時停止するTransitionでログを収集してから切り替える
受信通信だけ確認するCaptureやKey Vaultへの送信が失敗する送信先FQDNと同一NSP所属を確認する
既存の信頼済みサービス許可を前提にするEnforced後にフォールバックできないIDと明示的なNSPルールへ置き換える
SASのままサブスクリプションルールを使う認証エラーや接続失敗が発生するMicrosoft Entra IDへ移行する
異なるリージョンのNSPを選ぶ関連付け候補に表示されないEvent HubsとNSPのリージョンを確認する
ログ保存先を境界設計から外すNSPログが送信されなくなる保存先も同一NSPまたは許可ルールに含める
名前空間の共有利用者を確認しない別システムの送受信が停止する名前空間単位で利用者を棚卸しする
Geo-DR構成へそのまま適用するサポート制約に抵触する適用対象から除外し、公式対応状況を確認する
Service Endpoint前提で設計する想定した通信がNSPで許可されないPrivate Endpointへの移行を検討する

まず優先すべき対応

今回の一般提供を受けて、すべての環境を直ちに変更する必要はありません。最初に行うべきなのは、Event Hubs名前空間と通信依存関係の棚卸しです。

特に、次のいずれかに該当する環境は優先して確認してください。

  • パブリックネットワークアクセスが有効
  • 多数のIPアドレスやサブネットを許可している
  • Captureを使用している
  • カスタマー管理キーを使用している
  • 信頼済みサービスの例外に依存している
  • SAS接続を多数使用している
  • 1つの名前空間を複数システムで共有している
  • データ持ち出し対策や監査要件を強化したい

対応の基本は、棚卸し、Transition、ログ分析、ルール最小化、業務テスト、Enforcedの順です。

まずは影響範囲を把握できる非本番のEvent Hubs名前空間を1つ選び、Transitionモードと診断ログを有効にしてください。そこで得られた通信実態を基に、本番環境のNSPプロファイルと移行計画を作成するのが、安全かつ実務的な進め方です。

Azure
Azure Event Hubs Azureセキュリティ Network Security Perimeter

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次