Azure StorageをAzure DatabricksのUnity Catalogから利用している管理者・開発者にとって、今回の「Use Azure managed identities in Unity Catalog to access storage」で最も重要なのは、ストレージ接続の認証方式をサービスプリンシパル中心からAzureマネージドID中心に見直すべき点です。特に、Unity Catalogのメタストアルートストレージ、外部ロケーション、Storage firewall、Serverless SQL warehousesを使っている環境では、Access Connector、Azure RBAC、ネットワーク例外の確認が必要です。
結論から言うと、すぐに全環境を変更しなければならないという内容ではありません。ただし、Azure DatabricksでUnity Catalogを運用している場合は、今後の標準構成として「Azure Databricks Access Connector + Azure managed identity + Azure StorageのRBAC権限」を前提に設計するのが安全です。サービスプリンシパルを使っている既存メタストアは、移行手順と影響範囲を確認したうえで段階的に切り替えるのが現実的です。Microsoft Learnの英語ページでは最終更新日が2026年5月12日と表示されていますが、本稿では2026年5月13日付の更新情報として参照されている当該公式情報の内容を整理します。(Microsoft Learn)
Azure StorageのUnity Catalog接続で何が変わるのか
今回の公式情報は、Azure DatabricksのUnity Catalogユーザーに代わってAzure Storageコンテナーへアクセスする方法として、AzureマネージドIDを使う構成を説明しています。Unity Catalogでは、マネージドIDを主に次の2つの用途で使えます。(Microsoft Learn)
| 用途 | 対象 | 実務での意味 |
|---|---|---|
| メタストアのマネージドストレージへの接続 | Unity Catalogのマネージドテーブル保存先 | Unity Catalogの中核となる管理データ領域をマネージドIDで保護する |
| 外部ストレージへの接続 | ADLS Gen2上の既存データ、外部テーブル、ファイルアクセス | 既存のデータレイクをUnity Catalogで統制しやすくする |
大きなポイントは、マネージドIDを使うことでシークレットや資格情報のローテーション管理を減らせることです。AzureマネージドIDは、アプリケーションがMicrosoft Entra ID対応リソースへ接続するためのIDを提供し、開発者が資格情報を直接管理しなくてよい仕組みです。(Microsoft Learn)
従来、Azure DatabricksからAzure Storageへ接続する際にサービスプリンシパルを使っていた環境では、クライアントシークレットの有効期限、ローテーション漏れ、Key Vault連携、権限棚卸しが運用負荷になりがちでした。今回の内容は、その運用を減らし、Unity CatalogのストレージアクセスをよりAzureネイティブなID管理に寄せる流れと捉えると分かりやすいです。
対象になる管理者・開発者
今回の内容は、Azure Storageを直接使っている全ユーザー向けというより、Azure DatabricksとUnity Catalogを組み合わせてAzure Data Lake Storage Gen2にアクセスしている組織が主な対象です。
特に確認すべきなのは、次のような担当者です。
| 対象者 | 確認すべき内容 |
|---|---|
| Azure管理者 | Access Connectorの作成権限、マネージドID、Azure RBAC、Storage firewall設定 |
| Databricksアカウント管理者 | Unity Catalogメタストア、ストレージ資格情報、外部ロケーションの構成 |
| データ基盤エンジニア | ADLS Gen2パス、外部テーブル、ファイルイベント、Serverless SQL warehousesの接続確認 |
| セキュリティ担当者 | サービスプリンシパルの利用状況、シークレット管理、最小権限、ネットワーク例外 |
| 開発者・分析担当者 | 既存ノートブックやSQLクエリが外部ロケーション経由で継続利用できるか |
逆に、Azure Storage単体でBlobを利用しているだけの環境や、Unity Catalogを使っていないAzure Databricks環境では、直接の影響は限定的です。ただし、将来的にUnity Catalogへ移行する予定があるなら、最初からマネージドID前提で設計した方が手戻りを減らせます。
重要ポイントはAccess Connectorを中心にした構成
Azure DatabricksでUnity CatalogからAzure StorageへマネージドID接続する場合、中心になるのがAccess Connector for Azure Databricksです。
公式情報では、まずAzure上にAccess Connectorを作成します。Access ConnectorはAzure DatabricksアカウントにマネージドIDを接続するためのファーストパーティAzureリソースで、システム割り当てマネージドID、ユーザー割り当てマネージドID、またはその両方を含められます。(Microsoft Learn)
構成の流れは、次のように整理できます。
| 手順 | 作業 | 失敗しやすいポイント |
|---|---|---|
| Access Connectorを作成 | Azure PortalでAccess Connector for Azure Databricksを作成 | リージョンをStorage accountと揃え忘れる |
| マネージドIDを選択 | システム割り当て、またはユーザー割り当てを設定 | どちらのIDに権限を付けたのか分からなくなる |
| Azure StorageへRBACを付与 | Storage Blob Data Contributorなどを割り当て | ストレージアカウント全体に広すぎる権限を付ける |
| Unity Catalog側で利用 | メタストアまたはストレージ資格情報にAccess Connector IDを指定 | Access Connector IDとManaged Identity IDを混同する |
| ネットワーク設定を確認 | Storage firewall、VNet、Serverless SQL warehousesを確認 | RBACは正しいのにネットワークでブロックされる |
Access ConnectorのリソースIDは、Unity Catalog側の設定で必要になります。形式は次のようなAzureリソースIDです。
/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Databricks/accessConnectors/<connector-name>ここで注意したいのは、Access Connectorそのものを作っただけではAzure Storageへアクセスできないことです。実際にストレージへアクセスさせるには、Access Connectorに関連付けられたマネージドIDへAzure Storage側のRBAC権限を付与する必要があります。
必要なAzure権限とRBACの確認ポイント
公式情報では、Access Connectorを作成するユーザーまたはサービスプリンシパルには、AzureリソースグループのContributorまたはOwnerが必要です。また、マネージドIDへストレージアカウントの権限を付与するには、ストレージアカウントに対するOwnerまたはUser Access Administratorが必要です。(Microsoft Learn)
Azure Storage側では、一般的にStorage Blob Data Contributorを使って読み書き権限を付与します。このロールはAzure StorageのコンテナーとBlobに対する読み取り、書き込み、削除を許可します。(Microsoft Learn)
ただし、実務では「とりあえずストレージアカウント全体にStorage Blob Data Contributorを付ける」だけで終わらせない方がよいです。最小権限を意識するなら、用途ごとにスコープを分けて設計します。
| 利用シーン | 推奨される考え方 |
|---|---|
| Unity Catalogのメタストアルートストレージ | 専用コンテナーを用意し、他用途と混在させない |
| 外部テーブル用の既存データ | 対象コンテナーまたは必要なパスに限定して権限設計する |
| 検証環境 | 本番とは別のAccess ConnectorとStorage accountを使う |
| 複数ワークスペース運用 | どのワークスペースがどのメタストア・外部ロケーションを使うか台帳化する |
Storage Blob DelegatorとStorage Blob Data Contributorを組み合わせ、より限定的なアクセスにする選択肢も公式情報では示されています。Storage Blob Delegatorは、Microsoft Entra ID資格情報で署名されたSASに使うユーザー委任キーを生成できるロールです。(Microsoft Learn)
サービスプリンシパルからマネージドIDへ移行すべきか
既存環境でサービスプリンシパルを使ってUnity Catalogのストレージ接続を構成している場合、すぐに無計画な切り替えをする必要はありません。移行判断は、次の基準で行うと現実的です。
| 判断項目 | マネージドID移行を優先すべき状況 |
|---|---|
| シークレット管理 | サービスプリンシパルのシークレット更新で障害リスクがある |
| Storage firewall | ネットワークルールで保護されたADLS Gen2へUnity Catalogからアクセスしたい |
| 監査・統制 | IDと権限の棚卸しをAzure RBAC中心に寄せたい |
| 新規構築 | これからUnity Catalogを有効化する |
| 運用体制 | 開発チームにシークレットを持たせたくない |
Microsoft Learnのメタストア作成手順でも、マネージドIDはシークレットの維持やローテーションが不要で、Storage firewallで保護されたAzure Data Lake Storageアカウントへ接続できるため、Databricksが推奨する構成として説明されています。(Microsoft Learn)
移行で重要なのは、サービスプリンシパルを削除する前に、マネージドID経由の読み書きがすべての対象パスで成功することを確認することです。特に、既存の外部テーブル、Auto Loader、ジョブ、SQL Warehouse、ノートブックが外部ロケーションを経由しているか、直接abfss://パスを参照していないかを確認してください。
既存メタストアを移行する場合の流れ
公式情報では、サービスプリンシパルで作成済みのUnity Catalogメタストアを、マネージドIDでルートストレージへアクセスする構成にアップグレードできると説明されています。手順としては、Access Connectorを作成し、対象ストレージコンテナーへ権限を付与した後、Databricks CLIでストレージ資格情報を作成し、メタストアのルートストレージ資格情報を更新します。(Microsoft Learn)
実務では、次の順序で進めると安全です。
| フェーズ | 作業内容 |
|---|---|
| 事前調査 | メタストアID、現在のストレージ資格情報、サービスプリンシパル、対象ADLS Gen2パスを確認 |
| 準備 | Access Connectorを作成し、マネージドIDへAzure StorageのRBACを付与 |
| 検証 | 検証用ワークスペースまたは低リスクな外部ロケーションで読み書きを確認 |
| 更新 | Databricks CLIでストレージ資格情報を作成し、メタストアへ適用 |
| 監視 | ジョブ、SQL Warehouse、外部テーブル、権限エラー、Storage firewallログを確認 |
| 後片付け | 問題がないことを確認してから、旧サービスプリンシパルの権限とシークレットを整理 |
移行時に避けたいのは、「RBACを付けたから接続できるはず」と判断して本番メタストアをすぐ更新することです。Azure Storageへのアクセスは、ID、RBAC、Unity Catalog権限、ネットワーク設定がすべて揃って初めて成功します。どこか1つがずれていると、読み取りだけ失敗する、外部テーブルだけ失敗する、Serverless SQL warehousesだけ失敗する、といった切り分けに時間がかかる問題が起きます。
外部ロケーションを使う環境で確認すべきこと
Unity Catalogで既存のADLS Gen2データを管理する場合、ストレージ資格情報と外部ロケーションを使います。ストレージ資格情報にはAzureマネージドIDを指定し、外部ロケーションにはADLS Gen2のパスとストレージ資格情報への参照を設定します。(Microsoft Learn)
外部ロケーションを使う場合は、次の確認が重要です。
| 確認項目 | 内容 |
|---|---|
| Unity Catalog対応ワークスペース | 対象ワークスペースがUnity Catalogに対応しているか |
CREATE STORAGE CREDENTIAL権限 | ストレージ資格情報を作成するユーザーに権限があるか |
CREATE EXTERNAL LOCATION権限 | 外部ロケーションを作成する権限があるか |
| ADLS Gen2の階層型名前空間 | 外部ロケーションに使うStorage accountで有効になっているか |
| リージョン | ワークスペースとStorage accountが同一リージョンか |
| パス文字 | 外部ロケーションのパスに標準ASCII以外が含まれていないか |
特に見落としやすいのが、開発者がノートブックから直接ストレージパスを参照しているケースです。Unity Catalogによるガバナンスを徹底するなら、個別の直接アクセスではなく、ストレージ資格情報と外部ロケーションを通じてアクセス制御する設計へ寄せる必要があります。
Storage firewallを使っている場合の注意点
今回の公式情報で、実務上の影響が大きいのはStorage firewallまわりです。
Azure Databricksワークスペースを自社のAzure仮想ネットワークにデプロイしている、いわゆるVNet injection構成で、Azure Data Lake StorageアカウントをStorage firewallで保護している場合、次の2つを有効にする必要があります。(Microsoft Learn)
| 必要な対応 | 内容 |
|---|---|
| ワークスペースからAzure Storageへのアクセス | Private Endpointまたは仮想ネットワーク経由のアクセスを構成 |
| マネージドIDからAzure Storageへのアクセス | Storage accountのネットワーク設定でAccess Connectorをリソースインスタンスとして許可 |
Azure Portalで設定する場合、Storage accountのNetworking設定でPublic network accessを「選択した仮想ネットワークとIPアドレス」にし、Resource instancesにMicrosoft.Databricks/accessConnectorsとしてAccess Connectorを追加する流れになります。必要に応じてPublic network accessをDisabledにする選択肢もありますが、公式情報では標準的なアプローチとして「Enabled from selected virtual networks and IP addresses」を維持する考え方が示されています。(Microsoft Learn)
ここで注意したいのは、「Allow Azure services on the trusted services list to access this storage account」を有効にしたままにするかどうかです。公式手順では、より限定的にAccess Connectorを許可する流れの中で、この例外をクリアする手順が含まれています。(Microsoft Learn)
セキュリティを重視する環境では、「Azure trusted servicesを広く許可する」よりも、「必要なAccess ConnectorをResource instancesとして明示的に許可する」方が説明責任を果たしやすくなります。ただし、既存の他サービスがtrusted services例外に依存している場合、安易に無効化すると別システムに影響する可能性があります。変更前に、Azure Monitor、Microsoft Defender for Cloud、バックアップ、ログ収集などの利用状況も確認してください。
Serverless SQL warehousesを使う場合の影響
Serverless SQL warehousesを利用している場合も注意が必要です。公式情報では、Serverless SQL warehousesはユーザー自身のAzureサブスクリプションではなく、Azure Databricks側のサブスクリプションで実行されるコンピュートリソースであるため、Azure Data Lake StorageにStorage firewallを構成している場合は、Serverless SQL warehousesからのアクセスを許可する必要があると説明されています。(Microsoft Learn)
この点は、クラシックなクラスターでは成功するのに、SQL Warehouseでは同じ外部テーブルを読めない、というトラブルにつながりやすいです。
確認の観点は次の3つです。
| 観点 | 確認内容 |
|---|---|
| コンピュート種別 | All-purpose cluster、Job cluster、SQL Warehouse、Serverless SQL Warehouseのどれでアクセスするか |
| ネットワーク経路 | VNet、Private Endpoint、Storage firewall、Serverless compute planeの設定 |
| Unity Catalog権限 | ユーザーまたはグループに外部ロケーションやテーブルの権限があるか |
アクセス障害が発生した場合は、最初に「IDの問題」と決めつけないでください。Serverless SQL warehousesでは、RBACやUnity Catalog権限が正しくても、Storage firewall側の許可不足で失敗することがあります。
システム割り当てIDとユーザー割り当てIDの選び方
Access Connectorでは、システム割り当てマネージドIDとユーザー割り当てマネージドIDを使えます。どちらを選ぶかは、環境の規模と運用ポリシーで判断します。
| 種類 | 向いているケース | 注意点 |
|---|---|---|
| システム割り当てマネージドID | 単一のAccess Connectorでシンプルに運用する小規模環境 | Access ConnectorのライフサイクルとIDが結びつく |
| ユーザー割り当てマネージドID | 複数リソースでIDを再利用したい、権限を事前付与したい環境 | Managed Identity IDの指定漏れや権限混同に注意 |
AzureのマネージドIDには、リソースに紐づくシステム割り当てと、独立したAzureリソースとして作成して複数リソースに割り当てられるユーザー割り当てがあります。ユーザー割り当てマネージドIDはリソースとは独立したライフサイクルを持ち、複数リソースで共有できます。(Microsoft Learn)
実務では、検証環境や単一ワークスペースならシステム割り当てでも十分です。一方、複数のDatabricksワークスペース、複数のメタストア、IaCによる事前プロビジョニング、権限の一元管理を重視する環境では、ユーザー割り当てマネージドIDの方が管理しやすい場合があります。
管理者が今すぐ確認すべきチェックリスト
Azure StorageとUnity Catalogを本番利用している場合は、次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| Unity Catalogの利用有無 | 対象ワークスペースがUnity Catalogに接続されているか |
| 既存の認証方式 | サービスプリンシパル、マネージドID、アカウントキーのどれを使っているか |
| Access Connector | 作成済みか、リージョンはStorage accountと一致しているか |
| マネージドID | システム割り当てかユーザー割り当てか、IDのリソースIDを記録しているか |
| Azure RBAC | Storage Blob Data Contributorなど必要な権限が正しいスコープに付与されているか |
| Storage firewall | Resource instancesにAccess Connectorを許可しているか |
| Serverless SQL warehouses | Storage firewall利用時にServerless computeからのアクセスを考慮しているか |
| 外部ロケーション | 既存データがUnity Catalogの外部ロケーションとして管理されているか |
| 旧サービスプリンシパル | 不要になったシークレットや権限が残っていないか |
| 監査ログ | 権限変更、アクセス失敗、ジョブ失敗を確認できるか |
このチェックで特に重要なのは、認証方式とネットワーク設定を同時に確認することです。Azure DatabricksからAzure Storageへの接続障害は、RBAC、Unity Catalog権限、Storage firewall、リージョン、パス指定のいずれでも起こります。チームごとに担当が分かれている場合は、Azure管理者、Databricks管理者、データ基盤担当者が同じ構成図を見ながら確認するのが効率的です。
開発者が注意すべき実装・運用上のポイント
開発者側では、マネージドIDそのものを直接コードに埋め込むというより、Unity Catalogで定義された外部ロケーションやテーブルを使う設計に寄せることが重要です。
避けたいのは、次のような実装です。
# 直接abfssパスをハードコードしている例
df = spark.read.parquet("abfss://[email protected]/sales/")このようなコードが大量にあると、Unity Catalogで外部ロケーションを整備しても、権限統制や監査の抜け道になりやすくなります。理想は、Unity Catalog上のテーブルやビューを参照する形に整理することです。
SELECT *
FROM main.sales.orders;外部データを扱う場合も、外部ロケーションを通じてアクセスする設計にしておくと、後からストレージ資格情報やマネージドIDを変更しても、利用者側のコード変更を最小限にできます。
また、開発・検証時には次の点を確認してください。
| 確認項目 | 具体例 |
|---|---|
| 読み取りだけでなく書き込みも確認 | Deltaテーブル作成、INSERT、MERGE、DELETEを試す |
| ジョブ実行ユーザーで確認 | 管理者では成功するがジョブ実行IDでは失敗するケースを防ぐ |
| SQL Warehouseでも確認 | クラスターでは成功し、SQL Warehouseでは失敗する差分を確認 |
| 外部テーブルの再作成不要性 | ストレージ資格情報変更後も既存テーブルが参照できるか確認 |
| 監査ログ | どのIDでアクセスしているか追跡できるか確認 |
展開時に失敗しやすいポイント
マネージドID化はセキュリティと運用性を高めますが、設定箇所がAzureとDatabricksにまたがるため、初回展開ではミスが起きやすいです。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| Access Connectorを作ったのにアクセスできない | Storage account側のRBAC付与がない | マネージドIDへStorage Blob Data Contributorを付与 |
| RBACを付けたのにアクセスできない | Storage firewallでブロックされている | Resource instancesやVNet、Private Endpointを確認 |
| ユーザー割り当てIDで失敗する | Managed Identity IDを指定していない | Access Connector IDとManaged Identity IDを両方記録 |
| SQL Warehouseだけ失敗する | Serverless compute planeの許可不足 | Serverless SQL warehouses向けのStorage firewall設定を確認 |
| 本番だけ失敗する | リージョンやStorage accountが検証環境と異なる | Access Connector、Workspace、Metastore、Storageのリージョンを確認 |
| 旧サービスプリンシパルを消したら障害 | 一部ジョブが直接旧資格情報を参照 | 削除前にジョブ、シークレットスコープ、ノートブックを棚卸し |
特に、Access Connectorのリージョンは軽視されがちです。公式情報では、Access Connector、ワークスペース、メタストア、クラウドストレージの場所を同じクラウドリージョンに配置することがパフォーマンス上望ましいとされています。(Microsoft Learn)
既存環境へのおすすめ対応順
本番環境でAzure DatabricksとAzure Storageを使っている場合、次の順序で進めるとリスクを抑えられます。
まず現状を棚卸しする
最初に、Unity Catalogメタストア、ストレージ資格情報、外部ロケーション、サービスプリンシパル、シークレットスコープ、Storage firewallの設定を一覧化します。
この段階では設定変更を急がず、次の情報を集めます。
| 項目 | 記録する内容 |
|---|---|
| メタストア | メタストアID、リージョン、ルートストレージ |
| ストレージ資格情報 | 名前、認証方式、関連する外部ロケーション |
| Access Connector | リソースID、マネージドIDの種類、リージョン |
| Azure Storage | アカウント名、コンテナー、階層型名前空間、Firewall設定 |
| サービスプリンシパル | 使用箇所、シークレット期限、付与されているRBAC |
| ジョブ・ノートブック | 直接ストレージパスを参照している処理 |
新規構成はマネージドID前提にする
これからUnity Catalogのメタストアや外部ロケーションを作る場合は、サービスプリンシパルではなく、Access ConnectorとマネージドIDを使う構成を基本にします。特に、Storage firewallやPrivate Endpointを使う予定がある環境では、後から変更するより初期設計で組み込んだ方が安全です。
既存構成は段階的に移行する
既存のサービスプリンシパル構成は、検証環境または影響の小さい外部ロケーションから移行します。移行後は、読み取り、書き込み、ジョブ実行、SQL Warehouse、監査ログを確認し、問題がないことを確認してから本番メタストアへ展開します。
旧資格情報は最後に整理する
マネージドID移行後も、すぐにサービスプリンシパルを削除しない方が安全です。一定期間、ジョブ失敗やアクセスログを確認し、利用が残っていないことを確認してから、旧RBAC、シークレット、Key Vault参照を削除します。
今回の更新で取るべきアクション
今回の「Use Azure managed identities in Unity Catalog to access storage」は、Azure Storageへの接続方式を単に説明した記事ではなく、Azure DatabricksのUnity Catalog運用をより安全で管理しやすい構成へ寄せるための実務ガイドとして読むべき内容です。
管理者が最初にやるべきことは、現在のUnity Catalogストレージ接続がサービスプリンシパル依存か、マネージドID化済みかを確認することです。次に、Access Connector、Azure RBAC、Storage firewall、Serverless SQL warehousesの設定を点検します。開発者は、直接abfss://パスへ依存した実装を減らし、Unity Catalogのテーブル、外部ロケーション、ストレージ資格情報を前提にしたアクセスへ整理してください。
新規構築では、Azure Databricks Access ConnectorとAzureマネージドIDを標準構成にするのが第一候補です。既存環境では、構成棚卸し、検証、段階移行、旧資格情報の整理という順序で進めることで、シークレット管理の負担を減らしながらAzure Storageへのアクセス制御を強化できます。
コメント