Azure Event Hubsで、Network Security Perimeter（NSP）のサポートが一般提供になりました。結論からいうと、今回の一般提供によって既存のEvent Hubs名前空間の通信が自動的に遮断されたり、設定変更が強制されたりするわけではありません。NSPを作成し、プロファイルとアクセスルールを用意したうえで、対象の名前空間を明示的に関連付ける必要があります。(Microsoft Azure)
ただし、Event Hubsをパブリックエンドポイントで利用している環境、Event Hubs Captureやカスタマーマネージドキーを利用している環境、Shared Access Signature（SAS）や仮想ネットワークのサービスエンドポイントに依存している環境では、対応要否を早めに確認すべきです。
実務上は、いきなり通信を制限するのではなく、依存関係の棚卸し、Transitionモードでのログ収集、アクセスルールの作成、Enforcedモードへの移行という順序で進めるのが安全です。
Azure Event HubsのNetwork Security Perimeter一般提供とは
Microsoftは2026年7月8日付のAzure Updatesで、Azure Event HubsにおけるNetwork Security Perimeterサポートの一般提供を案内しました。
NSPは、AzureのPaaSリソースを論理的な境界内にまとめ、境界外とのパブリックネットワーク通信を明示的なルールで制御する仕組みです。Event Hubsでは、名前空間へのインバウンド接続だけでなく、Capture用ストレージやカスタマーマネージドキー用Key Vaultへのアウトバウンド接続も制御できます。(Microsoft Azure)
Azure Updatesにおける「Launched」は、本番環境で利用できる完全リリースを意味します。一方、Microsoft Learnの対応表では、Event HubsのNSPサポートはPublic cloudで一般提供、Gov Cloudでは利用不可とされています。ソブリンクラウドを利用している場合は、対象環境での提供状況を別途確認してください。(Microsoft Azure)
NSPは主に、次の要素で構成されます。
| 構成要素 | 役割 |
|---|---|
| Network Security Perimeter | PaaSリソースを囲む論理的なセキュリティ境界 |
| プロファイル | 同じ通信要件を持つリソースに適用するルールの集合 |
| インバウンドアクセスルール | 境界外からの接続をIPアドレスやサブスクリプション単位で許可 |
| アウトバウンドアクセスルール | 境界外の接続先をFQDN単位で許可 |
| リソース関連付け | Event Hubs名前空間を特定のプロファイルへ所属させる設定 |
| 診断設定 | 許可・拒否された通信をアクセスログとして記録 |
NSPの目的は、個々のPaaSリソースに別々のファイアウォールルールを設定するだけでなく、複数サービスにまたがる通信境界を一元管理することです。境界外との通信を明示的に許可する方式にすることで、意図しない外部接続やデータ流出のリスクを抑えられます。(Microsoft Learn)
今回の変更で保護される範囲
Event HubsでNSPの関連付け対象になるAzureリソースは、Microsoft.EventHub/namespaces、つまりEvent Hubs名前空間です。個別のイベントハブ、Kafkaトピック、パーティション、コンシューマーグループごとにNSPを設定する仕組みではありません。名前空間は、配下のイベントハブに対するネットワークエンドポイントとネットワーク制御を提供する単位です。(Microsoft Learn)
主な保護対象は次のとおりです。
| 通信 | 具体例 | NSPでの扱い |
|---|---|---|
| パブリックインバウンド | アプリケーション、Kafkaクライアント、Azureサービスから名前空間への接続 | IPアドレスまたはサブスクリプション単位のルールで許可 |
| PaaS間通信 | 同じNSP内のAzureサービスからEvent Hubsへのイベント送信 | 同一ペリメーター通信として制御 |
| パブリックアウトバウンド | Event Hubs CaptureからAzure StorageやData Lake Storageへの書き込み | 接続先FQDNをアウトバウンドルールで許可 |
| カスタマーマネージドキー | Event HubsからAzure Key Vaultへのアクセス | 同一ペリメーター通信またはアウトバウンドルールで許可 |
| Private Link経由 | 仮想ネットワーク内のPrivate Endpointからの接続 | NSPのアクセスルールとは別に許可される |
Event HubsのNSPサポートでは、イベント取り込み、Kafkaワークロード、Capture、カスタマーマネージドキーが主な対応シナリオとして挙げられています。(Microsoft Learn)
ただし、NSPはネットワーク境界を制御する機能です。NSPルールで通信が許可されても、Event Hubsの認証や認可が不要になるわけではありません。Microsoft Entra IDとAzure RBAC、またはSASによるデータアクセス制御は引き続き必要です。(Microsoft Learn)
対応要否を判断するチェック表
すべてのEvent Hubs環境で、直ちにNSPを導入する必要があるわけではありません。現在の接続方式と利用機能から優先度を判断します。
| 現在の構成 | 対応優先度 | 判断のポイント |
|---|---|---|
| パブリックアクセスを全ネットワークに許可 | 高 | 認証情報が漏えいした場合の接続元制限が弱いため、NSP導入候補 |
| IPファイアウォールを名前空間ごとに管理 | 中～高 | 複数PaaSサービスのルールを一元化したい場合に有効 |
| Event Hubs Captureを使用 | 高 | StorageやData Lake Storageへのアウトバウンド通信を洗い出す必要がある |
| カスタマーマネージドキーを使用 | 高 | Key Vaultへの接続とマネージドIDの構成確認が必要 |
| 「信頼されたMicrosoftサービス」を許可 | 高 | Enforcedモードでは従来のTrusted accessに依存できない |
| SASを主要な認証方式として使用 | 高 | サブスクリプションルールや同一ペリメーター通信に制約がある |
| VNetサービスエンドポイントを使用 | 高 | NSPではサービスエンドポイントトラフィックがサポートされない |
| Geo-disaster recoveryを使用 | 高 | Event HubsのNSPでは未サポートのため、導入を保留して代替策を検討 |
| Private Endpointのみで接続 | 低～中 | Private Link通信はNSPの影響を受けないため、緊急性は比較的低い |
| StorageやKey Vaultなど複数PaaSを一体管理 | 高 | NSPによる共通境界とプロファイル管理の効果が大きい |
特に注意すべきなのは、Trusted access、SAS、サービスエンドポイント、Geo-disaster recoveryです。これらはEnforcedモードへの移行時に通信障害の原因になりやすいため、関連付け前に必ず棚卸ししてください。(Microsoft Learn)
NSPと既存のEvent Hubsネットワーク機能の違い
NSPは、Private EndpointやIPファイアウォールの単純な置き換えではありません。それぞれ制御する範囲が異なります。
| 機能 | 主な制御対象 | 管理単位 | NSPとの関係 |
|---|---|---|---|
| IPファイアウォール | 公開接続元のIPアドレス | Event Hubs名前空間 | Transitionモードでは既存ルールへフォールバック可能 |
| VNetサービスエンドポイント | 許可した仮想ネットワークのサブネット | Event Hubs名前空間 | NSPとの併用に制約があるためPrivate Endpointへの移行を検討 |
| Private Endpoint | プライベートIP経由の接続 | エンドポイント単位 | NSPの影響を受けず、明示的なNSPルールも不要 |
| Network Security Perimeter | PaaS間および境界外との公開インバウンド・アウトバウンド通信 | 複数PaaSリソースを含むプロファイル | 共通ルールを一元管理できる |
| Microsoft Entra ID／Azure RBAC | 誰が何を送受信できるか | IDとリソーススコープ | NSPとは別に必須 |
| SAS | 送信、受信、管理などの権限 | 名前空間またはエンティティ | 一部のNSP通信パターンでは利用不可 |
Private Endpointは、仮想ネットワーク内のプライベートIPを利用してEvent Hubsへ接続する仕組みです。一方のNSPは、PaaSリソースを論理的な境界にまとめ、公開経路を使う場合の接続元と接続先を制御します。両者は排他的ではなく、Private Endpointによるプライベート接続とNSPによる公開通信の統制を併用できます。(Microsoft Learn)
管理者が実施する設定手順
通信依存関係を先に棚卸しする
NSPを作成する前に、対象のEvent Hubs名前空間について次の情報を整理します。
- イベントを送信するアプリケーションとAzureサービス
- イベントを受信するコンシューマー
- AMQP、HTTPS、Kafkaなどの利用プロトコル
- 接続元のサブスクリプション、パブリックIPアドレス、仮想ネットワーク
- Microsoft Entra ID、マネージドID、SASの利用状況
- Event Hubs Captureの保存先
- カスタマーマネージドキー用Key Vault
- Private EndpointとVNetサービスエンドポイントの有無
- Trusted accessへの依存
- Geo-disaster recoveryの構成
- 診断ログの送信先
名前空間だけを確認するのではなく、送信元、受信側アプリケーション、Capture先、Key Vault、監視基盤まで含めた通信図を作成することが重要です。
NSPとプロファイルを作成する
AzureポータルでNetwork Security Perimeterを作成し、Event Hubs用のプロファイルを用意します。
開発、検証、本番で通信要件が異なる場合は、同じプロファイルを使い回さず、環境ごとに分ける方が安全です。
Event Hubs名前空間からNSPを関連付けるには、次の権限が必要です。
| 対象 | 必要な権限 |
|---|---|
| Event Hubs名前空間 | Contributor以上 |
| Network Security Perimeter | Network Security Perimeter Contributor以上 |
Event Hubs名前空間の画面では、次の順に操作します。
- AzureポータルでEvent Hubs名前空間を開く
- 「Settings」から「Networking」を選択する
- 「Public access」タブを開く
- Network security perimeter欄で「Associate NSP」を選択する
- NSPとプロファイルを指定する
- 関連付けを実行する
選択できるのは、Event Hubs名前空間と同じリージョンにあるNSPです。別リージョンのNSPは一覧に表示されません。(Microsoft Learn)
最初はTransitionモードを使用する
既存環境では、最初からEnforcedモードにしないことが重要です。
Transitionモードは既定のアクセスモードで、NSPルールに一致しない通信があった場合でも、既存のEvent Hubsファイアウォール設定やTrusted accessの評価へフォールバックします。そのため、既存アプリケーションを稼働させながら、NSPルールに不足している通信をログから確認できます。(Microsoft Learn)
Transitionモードでは、次の通信を重点的に確認します。
- NSPルールでは許可されず、既存のIPファイアウォールで許可された接続
- Trusted accessによって許可されたAzureサービス
- 想定していなかった送信元IPアドレス
- CaptureやKey Vaultへのアウトバウンド通信
- 運用ツール、バッチ処理、障害対応端末からの接続
- 使用されていない古いアプリケーションからの接続
Transitionモードは永続的な安全設定ではありません。既存ルールへフォールバックできるため、ログを確認した後は必要なNSPルールを追加し、Enforcedモードへの移行を計画します。
必要最小限のアクセスルールを設定する
NSPで使用できる主なルールは次のとおりです。
| 方向 | ルールの種類 | Event Hubsでの利用例 |
|---|---|---|
| インバウンド | サブスクリプションベース | 特定のAzureサブスクリプションからの接続を許可 |
| インバウンド | IPアドレスベース | オンプレミス拠点や固定NAT IPからの接続を許可 |
| アウトバウンド | FQDNベース | Capture先Storageや外部サービスへの接続を許可 |
ルール名には、接続元や利用目的が分かる名称を付けます。たとえば、allow-prod-app-subscriptionやallow-capture-storageのように、後から監査ログを見ても用途を判断できる名前が適しています。(Microsoft Learn)
同一NSP内のPaaS間通信では、対象リソースにマネージドIDを設定することも重要です。ネットワーク上の通信が許可されても、Storage、Key Vault、Event Hubs側のAzure RBACやデータアクセス権限が不足していれば処理は失敗します。
正常系と拒否系の両方をテストする
本番移行前には、許可した接続だけでなく、拒否されるべき接続も確認します。
| テスト | 期待結果 |
|---|---|
| 許可したサブスクリプションのアプリからイベントを送信 | 成功 |
| 許可したコンシューマーからイベントを受信 | 成功 |
| 許可していない外部IPから接続 | 失敗 |
| Event Hubs CaptureでStorageへ書き込み | 成功 |
| カスタマーマネージドキーを使用した暗号化処理 | 成功 |
| 許可していないFQDNへのアウトバウンド接続 | 失敗 |
| Private Endpoint経由の接続 | 成功 |
| 再起動やスケールアウト後の接続 | 成功 |
Kafkaを使用している場合は、プロデューサーとコンシューマーの両方で確認します。通常のEvent Hubs SDKが成功しても、Kafkaクライアントの認証方式や接続元が異なれば、Kafka側だけ失敗する可能性があります。
確認後にEnforcedモードへ移行する
Enforcedモードでは、原則としてNSPルールに一致しないパブリック通信が拒否されます。既存のEvent Hubsファイアウォール設定やTrusted accessに依存した通信は救済されません。
Private Endpoint経由の通信はNSPの影響を受けませんが、公開経路を利用する通信は明示的なNSPルールが必要です。(Microsoft Learn)
切り替え時には、次の運用情報も準備しておきます。
- 変更日時と担当者
- 影響を受けるアプリケーション一覧
- 正常性を確認するメトリック
- 拒否ログを確認するKQL
- Transitionモードへ戻す判断基準
- Event Hubs、Storage、Key Vaultそれぞれの管理担当者
- 障害時の連絡経路
監査と異常検知への影響
NSP導入による重要な変化は、ネットワークアクセスの判定結果を統一形式で記録できることです。
Transitionモードでは、NSPルールで許可された通信と、既存のPaaSリソース側ルールへフォールバックして許可された通信を区別できます。Enforcedモードでは、NSPによって拒否されたインバウンドとアウトバウンドを確認できます。(Microsoft Learn)
NSPアクセスログをLog Analyticsへ送信した場合、NSPAccessLogsテーブルに保存されます。主な確認項目は次のとおりです。
| 列 | 確認できる内容 |
|---|---|
Category | NSPルール、既存リソースルール、Private Linkなどの判定種別 |
ResultAction | 許可または拒否 |
ResultDirection | インバウンドまたはアウトバウンド |
RuleType | NSPルールかPaaSリソース側ルールか |
SourceIpAddress | 接続元IPアドレス |
SourceResourceId | 接続元Azureリソース |
SourceAppId | 接続元アプリケーションID |
DestinationFqdn | アウトバウンド接続先FQDN |
MatchedRule | 一致したアクセスルール |
Count | 集約されたイベント数 |
これらの列はMicrosoft公式のNSPAccessLogsスキーマで定義されています。(Microsoft Learn)
拒否された通信を確認するKQL
NSPAccessLogs
| where TimeGenerated > ago(24h)
| where ResultAction == "Denied"
| extend EventCount = coalesce(Count, 1)
| project
TimeGenerated,
TimeGeneratedEndTime,
ServiceResourceId,
ResultDirection,
Category,
SourceIpAddress,
SourceResourceId,
SourceAppId,
DestinationFqdn,
MatchedRule,
EventCount
| order by TimeGenerated descEnforcedモードへの移行直後は、この結果をEvent Hubsの送信エラー、受信遅延、Capture失敗などの運用メトリックと突き合わせます。
既存ルールへフォールバックした通信を確認するKQL
NSPAccessLogs
| where TimeGenerated > ago(7d)
| where Category in (
"NspPublicInboundResourceRulesAllowed",
"NspPublicOutboundResourceRulesAllowed"
)
| extend EventCount = coalesce(Count, 1)
| summarize
Events = sum(EventCount)
by
ServiceResourceId,
Category,
SourceIpAddress,
SourceResourceId,
DestinationFqdn,
MatchedRule
| order by Events descこの結果に表示される通信は、Transitionモードでは動作していても、Enforcedモードに切り替えると停止する可能性があります。必要な通信であればNSPルールへ移し、不要な通信であればアプリケーションや旧設定を削除します。
NSPアクセスログは集約される場合があります。CountやTimeGeneratedEndTimeが存在しないレコードは、イベント数を1件として扱います。(Microsoft Learn)
優先して設定したい検知ルール
運用開始後は、少なくとも次の条件を監視します。
- Enforcedモードで発生した拒否通信
- Transitionモードで既存リソースルールへフォールバックした許可通信
- 未知の送信元IPアドレスやアプリケーションID
- 許可していないアウトバウンドFQDNへの接続試行
- 通常利用しない時間帯の接続増加
- 特定ルールへの通信集中
- ルール変更直後の拒否件数急増
拒否ログをすべて重大インシデントにすると、設定ミスやアプリケーション再試行によるノイズが増えます。まずEvent Hubs名前空間、接続元、方向、ルール名で集約し、業務影響のある通信を優先的にアラート化するのが実用的です。
ログ送信先とMicrosoft Sentinelの注意点
NSPの診断設定では、Log Analyticsワークスペース、Storage、Event Hubsなどを送信先に指定できます。Log Analyticsへ送信した場合のテーブル名はNSPAccessLogsです。(Microsoft Learn)
ただし、ログ送信先もネットワーク設計に含める必要があります。Microsoftは、PaaSリソースのログ送信先を対象リソースと同じNSP内に配置するよう案内しています。送信先がペリメーター外にあると、Enforcedモードへの切り替え後にログが届かなくなる可能性があります。(Microsoft Learn)
また、NSPを関連付けたLog Analyticsワークスペースでは、Microsoft Sentinelに関する制約があります。Microsoft公式ドキュメントでは、Microsoft Sentinelを有効化したLog AnalyticsワークスペースはNSPでサポートされず、ワークスペースにNSPを有効化すると分析ルールが自動的に無効化されるとされています。Sentinelを利用している場合は、監視基盤の設計を変更する前に必ず制約を確認してください。(Microsoft Learn)
導入前に確認すべき制約と失敗しやすいポイント
SASでは利用できない通信パターンがある
Event Hubsでは、次のNSP機能がSAS認証で正常に機能しません。
- 同一ペリメーター内のアクセス
- ペリメーター間アクセス
- サブスクリプションベースのインバウンドルール
これらのシナリオでは、SASを使ったリクエストが認証エラーとして拒否されることがあります。NSPの機能を十分に利用するには、Microsoft Entra ID、マネージドID、Azure RBACへの移行を優先してください。(Microsoft Learn)
Geo-disaster recoveryは未サポート
Event HubsのNSPでは、Geo-disaster recoveryがサポートされていません。
Geo-DRを利用する本番名前空間へ、検証せずにNSPを関連付けるべきではありません。エイリアス、プライマリ名前空間、セカンダリ名前空間の切り替え試験まで含めて確認できない場合は、Private Endpointや既存ファイアウォールによる保護を継続します。(Microsoft Learn)
VNetサービスエンドポイントはサポートされない
NSPの一般的な制約として、サービスエンドポイントトラフィックはサポートされません。インバウンドルールで広いIP範囲を許可していても、サービスエンドポイント経由の通信が拒否される可能性があります。
仮想マシンやAKSなどのIaaSからEvent Hubsへ接続する構成では、Private Endpointへの移行を検討してください。(Microsoft Learn)
Trusted accessはEnforcedモードで利用できない
Transitionモードでは、NSPルールに一致しない通信が従来のTrusted accessで許可される場合があります。しかし、EnforcedモードではTrusted accessはサポートされません。
「信頼されたMicrosoftサービスからこの名前空間へのアクセスを許可する」を有効にしているだけでは不十分です。実際にどのAzureサービスが接続しているかを特定し、同じNSPへ関連付けるか、明示的なルールやPrivate Linkへ移行します。(Microsoft Learn)
長いリソース名では関連付けできない場合がある
NSPの既知の制約として、Azureポータルが作成する関連付けリソース名との兼ね合いから、元のPaaSリソース名を44文字以内にする必要があります。
既存のEvent Hubs名前空間名が長い場合は、検証環境で関連付けの可否を事前確認してください。(Microsoft Learn)
削除によるロールバックにも注意する
NSPとの関連付けを削除すると、通常は既存のEvent Hubsファイアウォール設定へ制御が戻ります。
ただし、publicNetworkAccessがSecuredByPerimeterに設定されている状態で関連付けを削除すると、リソースはロックダウン状態になります。障害時に単純に関連付けを削除するのではなく、アクセスモードとpublicNetworkAccessの状態を確認してから操作してください。(Microsoft Learn)
大規模環境では上限を確認する
NSPには、次の規模上限があります。
| 項目 | 上限 |
|---|---|
| サブスクリプション当たりのNSP | 推奨100 |
| NSP当たりのプロファイル | 推奨200 |
| プロファイル当たりのルール要素 | インバウンド、アウトバウンドそれぞれ200 |
| 1つのNSPに関連付けるPaaSリソース | 推奨1,000 |
多数のEvent Hubs、Storage、Key Vaultを一つのNSPにまとめる場合は、ルール数と関連付け数を先に見積もります。(Microsoft Learn)
管理者が優先すべき対応
今回の一般提供に対して、推奨する対応順序は次のとおりです。
| 優先度 | 対応 | 完了条件 |
|---|---|---|
| 最優先 | Event Hubs名前空間を一覧化 | 所有者、用途、環境、公開設定が分かる |
| 最優先 | SAS、Geo-DR、サービスエンドポイント、Trusted accessを確認 | NSP導入を妨げる構成を特定できている |
| 高 | Capture、Key Vault、ログ送信先を確認 | 必要なアウトバウンド通信が整理されている |
| 高 | 非本番名前空間をTransitionモードで関連付け | NSPアクセスログを取得できている |
| 高 | フォールバック通信をNSPルールへ移行 | 必要な通信がNSPルールだけで許可される |
| 中 | SASからMicrosoft Entra IDへ移行 | 同一ペリメーター通信とサブスクリプションルールを利用できる |
| 中 | 正常系と拒否系を試験 | 想定外の接続だけが拒否される |
| 最終 | Enforcedモードへ切り替え | 業務通信、Capture、暗号化、監視が正常に動作する |
今回の更新だけを理由に、既存環境へ急いでEnforcedモードを適用する必要はありません。一方、パブリックアクセスを広く許可している環境や、複数のPaaSサービス間で機密データを扱う環境では、NSPは優先度の高いセキュリティ改善策になります。
最初に行うべき作業は、Azure Resource Graphや運用台帳からEvent Hubs名前空間を一覧化し、各名前空間の「Networking」「Authentication」「Capture」「Encryption」「Geo-disaster recovery」を確認することです。その後、影響の小さい非本番名前空間を一つ選び、TransitionモードとNSPAccessLogsを使った評価を開始してください。
コメント