📚 参考書籍
※この記事は書籍の一部をベースに再構成しています。もう少し踏み込んだ内容（設計や具体例）は書籍の中でまとめているので、気になる方はそちらもどうぞ。
『ゼロから触ってわかった！Azure × Databricksでつくる次世代データ基盤 非公式ガイド ―』
クラウドでデータ基盤を作ろうとすると、Azure・Storage・ネットワーク・権限・セキュリティ…
そこに Databricks が加わった瞬間、一気に難易度が跳ね上がります。 “最初のつまづき” を丁寧にほどいていくのが本書です。
https://amzn.to/3QaOzbW
3.3 Access Connector構築 ― Managed Identityによる接続標準
Databricks と ADLS Gen2 を接続する際、これまで主流だったのは SAS やサービスプリンシパルでした。
しかし現在の標準は、Managed Identity をベースとしたシークレットレス接続です。
その中核にあるのが、Access Connectorです。
これは単なる接続設定ではなく、「Databricks が Azure リソースにアクセスするための公式な入口」です。
Access Connectorとは何か
Access Connector は、Azure 上のリソースとして作成される「接続の実体」です。
そしてこの中に、Managed Identity が紐づいています。
つまり構造としてはこうなります。
- Access Connector（Azureリソース）
└ Managed Identity（認証の実体）
Databricks は、この Identity を使って ADLS にアクセスします。
Storage Credentialとの関係
ここで、多くの人が混乱するポイントがあります。
それが Access Connector と Storage Credential の違いです。
整理すると次のようになります。
- Access Connector → Azure側の実体（Identityを持つ）
- Storage Credential → Unity Catalog上の定義（名前付きの入口）
イメージとしてはこうです。
「Access Connectorという実体」を、「Storage Credentialという名前」でUCに登録する」
つまり、
- Azureで作る → Access Connector
- Databricks（UC）で参照する → Storage Credential
という役割分担です。
信頼関係の正体：誰が誰を信じているのか
Managed Identity を使う設計の本質は、信頼関係の整理にあります。
ここを曖昧にすると、設計の理解が一気に崩れます。
重要なのは次の視点です。
- ADLS は Databricks を信じているわけではない
- ADLS は「Identity」を信じている
具体的にはこうなります。
- Access Connector に紐づく Managed Identity が存在する
- ADLS 側でその Identity に RBAC を付与する
- その Identity を使って Databricks がアクセスする
つまり、信頼の流れはこうです。
ADLS → Managed Identity → Databricks
この「Identityを介した信頼の連鎖」こそが、シークレットレスの本質です。
- パスワード不要
- キー管理不要
- ローテーション不要
セキュリティと運用性が両立される理由はここにあります。
Managed Identityの種類と使い分け
Access Connector を作成する際、Managed Identity のタイプを選択する必要があります。
- システム割当（System-assigned）
- ユーザー割当（User-assigned）
この選択は設計思想に関わる重要なポイントです。
システム割当
Access Connector に対して自動的に Identity が割り当てられます。
- 設定がシンプル
- 1リソース＝1 Identity
- 削除と同時にIdentityも消える
単一ワークスペースで完結する場合は、これで十分です。
ユーザー割当
事前に作成した Identity を複数リソースで使い回します。
- Identityを固定できる
- 複数ワークスペースで共有可能
- IaC（Terraformなど）と相性が良い
シニア設計では、こちらが選ばれるケースが多いです。
- 環境ごとに同一権限を再現したい
- アクセス制御を中央管理したい
- Identityのライフサイクルを独立させたい
こうした要件がある場合は、ユーザー割当が適しています。
構築の基本ステップ
Access Connector を使った接続は、次の流れで構築します。
① Access Connectorの作成
- Managed Identity を設定（システム or ユーザー）
- リソースとしてデプロイ
② ADLSへの権限付与
- 対象ストレージアカウントまたはコンテナに対して
- RBAC（例：Storage Blob Data Contributor）を付与
ここで重要なのは、「Identity単位」で付与することです。
③ Unity CatalogでStorage Credentialを作成
- Access Connector を参照して定義
- UC上で名前を付ける
④ External Locationを定義
- ADLS のパス（abfss://）を指定
- Storage Credential と紐づける
よくあるアンチパターン
Managed Identity を使う設計でも、誤りはよく見られます。
- Storage Credential と Access Connector を混同する
- Databricks に直接権限を付与しようとする
- Identityではなく人に権限を付ける
- SASやキーと併用して設計が複雑になる
特に多いのが、
「誰に権限を付けているのか分からない」状態です。
正しくは常に、
「Identityに対して権限を付与する」
という一貫したモデルで考える必要があります。
設計のポイント
実務で効いてくる観点を整理します。
- Identityはリソースではなく“主体”として扱う
- Access Connectorは接続の実体として一貫管理する
- Storage Credentialは論理的な入口として整理する
- RBACはIdentity単位で付与する
この構造を理解すると、設計が一気にシンプルになります。
まとめ：接続設計は「Identity設計」である
Access Connector は単なる接続設定ではありません。
それは、Databricks と Azure の間にある「信頼の橋」です。
押さえるべきポイントは次のとおりです。
- Access Connector は Azure側の実体
- Storage Credential は UC側の定義
- ADLSはIdentityを信じてアクセスを許可する
- Managed Identityでシークレットレスを実現する
- システム割当とユーザー割当を使い分ける
つまり、接続設計とは「どうつなぐか」ではなく、
「誰としてアクセスするか」を設計することです。
この視点を持つことで、セキュアで運用しやすいレイクハウス基盤が実現できるのです。