Azure Event Hubs Dedicatedで、イベントデータの「処理中」をハードウェアレベルで保護するConfidential Computingが一般提供されました。2026年7月8日時点で確認できるAzure Updatesでは、本機能は「Launched／General Availability」とされ、提供時期は2026年5月と記載されています。従来の通信中・保存時の暗号化に加え、Event Hubs内部で処理されるデータにも保護範囲を広げられる更新です。(Microsoft Azure)
ただし、すべてのEvent Hubs環境ですぐ有効化できるわけではありません。対象はDedicatedレベルのみで、Confidential Computingを有効にした新しい環境を作成する必要があります。既存の名前空間へ後から追加することはできず、公式ドキュメントに掲載されている対応リージョンもKorea CentralとUAE Northに限られます。日本リージョンが必須のシステムでは、現時点で直接採用できない点が最大の判断材料です。(Microsoft Learn)
なお、これはAI機能そのものの追加ではありません。機密情報をAI、リアルタイム分析、IoT、セキュリティ監視などへ流すイベントストリーミング基盤を強化するセキュリティ更新です。
Azure Event Hubs DedicatedのConfidential Computingで何が変わるのか
今回の更新により、Azure Event Hubs Dedicatedでは、Trusted Execution Environment、略してTEEと呼ばれるハードウェアベースの信頼実行環境を利用して、処理中のイベントデータを隔離できるようになりました。
公式情報の要点を整理すると、次のようになります。
| 項目 | 内容 |
|---|---|
| 提供状態 | 一般提供、GA |
| 対象レベル | Azure Event Hubs Dedicated |
| 主な保護対象 | Event Hubs内部で処理中のイベントデータ |
| 保護方式 | ハードウェアベースのTEEによる隔離 |
| 有効化のタイミング | 新規作成時 |
| 既存環境への追加 | 不可。新しい環境への移行が必要 |
| アプリケーションコード | 機能利用のためのコード変更は原則不要 |
| 掲載されている対応リージョン | Korea Central、UAE North |
Confidential Computingは名前空間レベルの作成フローから有効化できますが、Infrastructure as CodeではDedicatedクラスターのplatformCapabilitiesに設定します。そのクラスターにEvent Hubs名前空間を関連付ける構成です。(Microsoft Learn)
「保存中」「通信中」に加えて「使用中」のデータを保護する
クラウド上のデータ保護は、データの状態を3つに分けて考えると理解しやすくなります。
| データの状態 | Event Hubsでの主な保護 |
|---|---|
| 通信中 | TLSによる暗号化 |
| 保存中 | Microsoft管理キー、または顧客管理キーによる暗号化 |
| 使用中・処理中 | Confidential Computingによるハードウェアレベルの隔離 |
Azure Event Hubsでは、クライアントと名前空間間の通信がTLSで暗号化され、保存データにはAzure Storage Service Encryptionが適用されます。必要に応じてAzure Key Vaultの顧客管理キーも利用できます。今回追加されたConfidential Computingは、これらを置き換えるものではなく、処理中のデータ保護を重ねる多層防御です。(Microsoft Learn)
たとえば、医療機器から送信された測定値をEvent Hubsで受信し、複数の分析サービスへ配信するケースを考えてみます。従来の暗号化だけでもネットワークとストレージは保護できますが、Confidential Computingを利用すると、Event Hubsのサービス内部でイベントを処理する段階にもハードウェアベースの隔離を追加できます。
利用条件で特に注意すべきポイント
Dedicatedレベルでのみ利用できる
Confidential Computingの対象はAzure Event Hubs Dedicatedです。StandardやPremiumの名前空間へ設定を追加する機能ではありません。
Dedicatedは、大量かつ低遅延のイベントストリーミングを必要とする企業向けのシングルテナント構成です。クラスターはCapacity Unit、CU単位で確保され、専用のCPUやメモリリソースが割り当てられます。固定的なコストが発生するため、セキュリティ要件だけでなく、処理量や予算との釣り合いを確認する必要があります。(Microsoft Learn)
「Confidential Computingを使いたいからDedicatedへ上げる」という判断だけでは不十分です。次の条件を同時に確認しましょう。
- 処理中データの保護が契約、規制、社内基準で求められている
- Dedicatedの固定コストを許容できる
- 高スループットや性能の安定性も必要としている
- 対応リージョンを利用できる
- 新しい名前空間への移行作業を実施できる
既存の名前空間には後から有効化できない
Confidential Computingは、名前空間またはそれを収容するDedicatedクラスターの作成時に有効化します。既存のEvent Hubs名前空間に対して、スイッチを後からオンにすることはできません。(Microsoft Learn)
既存環境で利用したい場合は、基本的に次の移行が必要です。
- Confidential Computingを有効にした新しいDedicatedクラスターを作成する
- 新しいクラスター内にEvent Hubs名前空間を作成する
- Event Hub、コンシューマーグループ、アクセス権、ネットワーク設定を再構成する
- プロデューサーとコンシューマーの接続先を切り替える
- 並行稼働でデータ欠落や重複を検証する
- 保存期間を考慮して旧環境を停止する
「アプリケーションコードの変更が不要」という説明は、Confidential ComputingによってEvent Hubs SDKやイベント処理方式を変更する必要がないという意味です。既存環境から別の名前空間へ移行する場合は、接続先、DNS、マネージドIDのロール割り当て、コンシューマーのチェックポイントなどの確認が必要です。
対応リージョンが限定されている
公式ドキュメントで掲載されている対応リージョンは、次の2つです。
- Korea Central
- UAE North
Japan EastとJapan Westは掲載されていません。そのため、国内保存、国内処理、通信遅延などの要件がある日本企業や公共機関では、現時点で採用が難しい可能性があります。(Microsoft Learn)
GAという表現は「どのリージョン、どの価格レベルでも利用できる」という意味ではありません。対象レベル、リージョン、新規作成という条件を満たした環境で本番利用できる状態と理解する必要があります。
Confidential Computingが保護するデータ境界
Confidential Computingを有効にしても、イベントデータが通過するシステム全体が自動的に機密実行環境になるわけではありません。
保護範囲を次のように分けて設計することが重要です。
| データが存在する場所 | Confidential Computingの扱い | 別途必要な対策 |
|---|---|---|
| 送信元アプリケーションのメモリ | Event Hubs機能の対象外として設計 | ホストOS、VM、コンテナー、認証情報の保護 |
| Event Hubsまでのネットワーク | TLSで保護 | Private Endpoint、ファイアウォール |
| Event Hubs内部の処理 | Confidential Computingの主な対象 | 作成時の有効化、構成監査 |
| Event Hubsの保存領域 | 保存時暗号化 | 必要に応じて顧客管理キー |
| Event Hubs Captureの保存先 | 保存先ストレージの管理範囲 | リージョン、暗号化、RBAC、ネットワーク制御 |
| 受信側アプリケーションのメモリ | Event Hubs機能の対象外として設計 | Confidential VMなど下流側の対策 |
| AI・分析サービスへ渡した後 | 各サービスの管理範囲 | 入力データ、ログ、保持期間、リージョンの確認 |
公式ドキュメントが示している保護対象は、Event Hubs内部で処理中のイベントデータです。したがって、送信元アプリケーションでイベントを作成する段階や、コンシューマーがイベントを受信した後のメモリまで自動的に保護されるわけではない、と考えて設計する必要があります。(Microsoft Learn)
データ所在地とCaptureにも注意する
Azure Event Hubsは、原則として名前空間の作成時に選択したリージョンでデータを保存・処理します。Geo-Disaster Recoveryを構成した場合は、選択したセカンダリリージョンへ名前空間などのメタデータがコピーされます。(Microsoft Learn)
一方、Event Hubs Captureの保存先となるAzure Blob StorageやAzure Data Lake Storageは、Event Hubsと同じリージョンにも別リージョンにも配置できます。Confidential Computing対応リージョンでEvent Hubsを作成しても、Capture先を別の国や地域にすると、データ所在地の境界は変わります。(Microsoft Learn)
個人情報や業界規制対象データを扱う場合は、Event Hubsだけでなく次の項目を一続きのデータフローとして確認してください。
- 送信元システムの所在地
- Event Hubsのリージョン
- Capture先ストレージのリージョン
- コンシューマーや分析基盤のリージョン
- バックアップやGeo-DRのセカンダリリージョン
- 診断ログの保存先
- 運用担当者がアクセスできるデータ範囲
管理者が設定すべきセキュリティ制御
Confidential Computingは単独で利用するよりも、ID、ネットワーク、暗号鍵、ポリシー、監視を組み合わせた方が効果的です。
Azure Policyで未設定のクラスターを監査・拒否する
Microsoftは、Confidential Computingが無効なDedicatedクラスターを監査または拒否するカスタムAzure Policyの例を公開しています。
ポリシーでは、Microsoft.EventHub/clustersのplatformCapabilities.confidentialCompute.modeがEnabledであるかを判定します。管理グループ、サブスクリプション、リソースグループ単位で割り当てることができます。(Microsoft Learn)
導入初期はAuditで現状を確認し、標準構成や例外申請の手順を整えた後にDenyへ切り替える方法が安全です。最初から拒否すると、検証環境や既存のデプロイパイプラインを停止させる可能性があります。
Microsoft Entra IDとマネージドIDを優先する
Event Hubsでは、Microsoft Entra IDとAzure RBACを使用して、送信者、受信者、管理者の権限を分離できます。
| 組み込みロール | 主な権限 |
|---|---|
| Azure Event Hubs Data Sender | イベントの送信 |
| Azure Event Hubs Data Receiver | イベントの受信 |
| Azure Event Hubs Data Owner | Event Hubsデータへの包括的なアクセス |
ロールはサブスクリプション全体ではなく、可能な限り名前空間、Event Hub、コンシューマーグループなどの狭いスコープで割り当てます。Azure上で動くアプリケーションには、接続文字列やSASキーを保存するのではなく、マネージドIDを利用する構成が推奨されます。(Microsoft Learn)
Private Endpointでパブリック接続を閉じる
Confidential Computingは、Event Hubsへ接続できる相手を制限する機能ではありません。外部からの接続経路は、ネットワーク設定で別途管理します。
機密性の高い環境では、Private Endpointを作成し、名前空間のパブリックネットワークアクセスを無効にする構成を検討します。接続元を限定する場合は、IPファイアウォールや仮想ネットワークの規則も利用できます。(Microsoft Learn)
顧客管理キーとManaged HSMを組み合わせる
より厳格なデータ保護が必要な場合は、Confidential Computingと顧客管理キーを組み合わせます。
- Confidential Computingで処理中のデータを保護する
- 顧客管理キーで保存時暗号化の鍵を管理する
- Azure Key Vault Managed HSMで鍵をハードウェア保護する
- キーのローテーション、失効、アクセス監査を自組織で管理する
Confidential Computingと顧客管理キーを組み合わせる場合、公式ドキュメントではユーザー割り当てマネージドIDの利用が必要とされています。名前空間作成前にManaged HSMへのアクセス権を付与する必要があり、作成後に生成されるシステム割り当てマネージドIDでは事前設定できないためです。(Microsoft Learn)
鍵へのアクセスを誤って失効させると、暗号化された名前空間を利用できなくなる可能性があります。鍵のローテーションや失効は、セキュリティ担当者だけでなく、Event Hubsの運用担当者を含めた手順として整備しておきましょう。(Microsoft Learn)
診断ログと構成変更を監視する
Confidential Computingが有効でも、不正なIDによるアクセスや設定変更までは防げません。
少なくとも次の項目を監視対象にします。
- 認証の失敗
- 想定外の送信元ネットワーク
- ロール割り当ての変更
- 名前空間やクラスター構成の変更
- 顧客管理キーへのアクセス失敗
- イベントの急激な送受信量の変化
- コンシューマーグループやパーティションへの異常なアクセス
- Private Endpointやパブリックアクセス設定の変更
MicrosoftのWell-Architected Frameworkでも、認証イベント、データプレーンのアクセスパターン、構成変更を診断ログで収集し、ネットワーク接続元や権限昇格の試行を監視することが推奨されています。(Microsoft Learn)
Infrastructure as Codeで有効化する方法
公式のBicepおよびARMテンプレート例では、DedicatedクラスターのplatformCapabilitiesへConfidential Computingの設定を追加します。
properties: {
platformCapabilities: {
confidentialCompute: {
mode: 'Enabled'
}
}
}その後、作成したDedicatedクラスターのリソースIDを指定して、Event Hubs名前空間を配置します。クラスターと名前空間のリージョンは一致させる必要があります。(Microsoft Learn)
注意したいのは、一般提供された機能である一方、公式ドキュメントのテンプレート例では2025-05-01-previewのAPIバージョンが使われている点です。(Microsoft Learn)
本番のデプロイパイプラインへ組み込む前に、次の事項を確認してください。
- 利用するAzure CLI、PowerShell、Bicepのバージョン
- 組織内でプレビュー表記のAPIバージョンを利用できるか
- Azure Policyのエイリアスが対象APIで評価されるか
- リージョンごとのリソースプロバイダー対応状況
- テンプレートのWhat-If結果
- クラスター作成後に設定値を取得して検証できるか
業務や開発での主な使いどころ
金融・決済データのリアルタイム処理
決済イベント、不正検知用データ、取引ログなどをリアルタイムに配信する構成では、処理中のデータまで保護対象に含めることで、多層防御を強化できます。
ただし、カード情報や口座情報をイベント本文へそのまま格納するのではなく、トークン化、マスキング、データ最小化を先に実施することが基本です。
医療・ヘルスケア機器のテレメトリ
医療機器やウェアラブル端末からEvent Hubsへ測定値を送り、アラート判定や分析を行う構成で活用できます。
Confidential Computingを有効にしても、患者情報とのひも付け、Capture先、分析サービス、診断ログなどは別のデータ境界です。イベント本文へ個人を直接識別できる情報を含める必要があるか、設計段階で見直しましょう。
製造業・重要インフラのIoTデータ
工場設備、エネルギー設備、交通、制御機器などのイベントを集約するケースでは、設備状態や運用情報が機密情報になることがあります。
Private Endpoint、マネージドID、送信専用ロールと組み合わせれば、ネットワーク、ID、処理環境を分けて保護できます。
セキュリティログや監査イベントの集約
認証ログ、侵入検知イベント、端末監視データなどは、攻撃者にとっても価値の高い情報です。大量のセキュリティイベントをEvent Hubsで集約し、分析基盤や監視サービスへ転送する構成では、処理中データの保護を追加できます。
AI・機械学習パイプラインへの入力
顧客対応履歴、製造データ、医療データなどをEvent Hubs経由でAIや分析サービスへ送るケースにも利用できます。
ただし、Confidential Computingが保護するのはEvent Hubs内部の処理です。AIモデルの推論処理、プロンプト、学習データ、出力ログまで同じ保護が継続するわけではありません。AI側のサービスについても、データ保持、リージョン、ログ保存、アクセス権を確認する必要があります。
マルチテナントSaaSの高機密データ
Microsoftのアーキテクチャガイドでは、規制対象のマルチテナント環境でテナントを専用名前空間に分離し、Confidential Computingを加える利用方法が示されています。処理中データにハードウェアレベルの隔離を追加しながら、既存のイベント処理コードを変更せずに導入できる点が利点です。(Microsoft Learn)
導入効果が小さいケース
次のような環境では、すぐにDedicatedへ移行する効果が小さい可能性があります。
- 機密性の低い公開データだけを扱っている
- イベント量が少なく、Dedicatedの固定コストに見合わない
- 保存時暗号化とPrivate Endpointだけで要件を満たせる
- Japan EastまたはJapan Westでの処理が必須
- 既存名前空間を停止・移行できない
- 下流のアプリケーションやストレージに十分な保護がない
- 処理中データの保護を要求する規制や契約条件がない
Confidential Computingは、すべてのEvent Hubs利用者が一律に有効化すべき機能ではありません。データ分類と脅威モデルを明確にし、「クラウド基盤の高権限層から処理中データを隔離する必要があるか」で判断するのが実務的です。
既存環境から移行する手順
現在の構成を棚卸しする
最初に、次の情報を一覧化します。
- 名前空間の価格レベル
- 利用リージョン
- Dedicatedクラスターの種類
- Capacity Unit数
- Event Hubとパーティション数
- コンシューマーグループ
- データ保持期間
- Captureの保存先
- プロデューサーとコンシューマー
- Private Endpoint、IP制限
- Microsoft Entra IDのロール割り当て
- SASや接続文字列の利用状況
- 顧客管理キーの有無
データ保護要件を言語化する
「セキュリティを上げたい」という抽象的な理由だけで進めず、次のような要件に落とし込みます。
- 処理中データの保護が監査要件に含まれる
- クラウド運用者を信頼境界の外に置く必要がある
- 顧客との契約でハードウェア隔離が求められる
- 個人情報や機密情報をイベント本文で処理する必要がある
- データを保存・処理できる国や地域が限定される
新環境を先に構築する
Confidential Computingを有効化したDedicatedクラスターと名前空間を新規作成し、次の設定を先に完了させます。
- Microsoft Entra IDとマネージドID
- 最小権限のRBAC
- Private Endpoint
- パブリックネットワークアクセスの無効化
- 顧客管理キーとManaged HSM
- 診断ログ
- Azure Policy
- アラートと運用手順
並行稼働で検証する
新旧環境を短期間並行稼働させ、次の項目を確認します。
- 送信件数と受信件数
- イベントの重複や欠落
- パーティションごとの負荷
- コンシューマーの遅延
- 認証エラー
- Private Endpoint経由の接続
- Captureファイルの生成
- 顧客管理キーへのアクセス
- CU使用率と必要容量
- 障害時の再接続とリトライ
Dedicatedクラスターで必要なCU数は、プロデューサー数、コンシューマー数、パーティション、ペイロードサイズ、受信量などによって変わります。想定ワークロードを実際に流して、リソース使用率を確認する方法が推奨されています。(Microsoft Learn)
対応要否を判断するチェック表
| 現在の状況 | 推奨する対応 |
|---|---|
| Event Hubsを利用していない | 原則として対応不要 |
| StandardまたはPremiumを利用中 | 直接有効化は不可。要件が強い場合だけDedicatedへの再設計を検討 |
| 既存のDedicatedを利用中 | 後付け不可。新クラスター・新名前空間への移行計画を作成 |
| 新規システムで対応リージョンを利用できる | 機密データを扱うなら初期設計で有効化を検討 |
| 日本国内リージョンが必須 | 現時点では導入を見送り、リージョン拡大を監視 |
| Captureを別リージョンに保存している | データ所在地とストレージ側の保護を再確認 |
| SAS接続を多用している | マネージドIDとMicrosoft Entra IDへの移行を優先 |
| 処理中データの保護要件がない | コストを含め、導入優先度は低い |
今回の更新で最も重要なのは、GAという表記だけで導入を決めないことです。まず、処理中データの保護が本当に必要かを確認し、Dedicatedのコスト、対応リージョン、新環境への移行可否、Event Hubsの前後を含むデータ境界を整理してください。
日本リージョンが必須の組織は、現時点では無理に構成を変更する必要はありません。Azure Updatesとリージョン提供状況を監視しながら、既存環境ではMicrosoft Entra ID、Private Endpoint、顧客管理キー、診断ログなど、現在利用できる管理策を先に強化するのが現実的です。
コメント