📚 参考書籍
※この記事は書籍の一部をベースに再構成しています。もう少し踏み込んだ内容（設計や具体例）は書籍の中でまとめているので、気になる方はそちらもどうぞ。
『ゼロから触ってわかった！Azure × Databricksでつくる次世代データ基盤 非公式ガイド ―』
クラウドでデータ基盤を作ろうとすると、Azure・Storage・ネットワーク・権限・セキュリティ…
そこに Databricks が加わった瞬間、一気に難易度が跳ね上がります。 “最初のつまづき” を丁寧にほどいていくのが本書です。
https://link.amazon/B0cSn1ZCC
Databricks × ADLS Gen2の認証方式を整理 ― SAS・OAuth・Managed Identityの正しい使い分け
認証方式 ― SAS / OAuth / MIの使い分け
Databricks と ADLS Gen2 を接続する方法はいくつか存在します。
代表的なのは、**SAS / OAuth（サービスプリンシパル）/ Managed Identity（MI）**の3つです。
ただし、ここで最初に明確にしておくべきことがあります。
「マウント」という過去の設計との決別
かつての Databricks では、ストレージを DBFS にマウントする設計が一般的でした。
- SASトークンを使う
- シークレットを Key Vault に保存する
- /mnt/xxx にマウントする
このスタイルは一時代を築きましたが、現在は明確に位置づけが変わっています。
マウントは非推奨のレガシー技術です。
理由はシンプルです。
- アクセス制御が分散する
- ガバナンスが効かない
- シークレット管理が必要になる
- Unity Catalogと整合しない
本書で扱う設計は、
**Unity Catalog ＋ Managed Identity による「マウントレス設計」**です。
つまり、
- ストレージはマウントしない
- 直接 abfss:// でアクセスする
- UCでアクセス制御する
この思想への切り替えが重要です。
認証方式の全体像
それぞれの方式を整理すると、次のようになります。
- SAS → 一時的な共有キー
- OAuth → サービスプリンシパルによる認証
- MI → シークレット不要の自動認証
そして結論はシンプルです。
通常はMIを使う。例外的にOAuth。SASは基本使わない。
SAS（Shared Access Signature）
SASは、ストレージに対する一時的なアクセス権をURLとして発行する仕組みです。
- 短期間のアクセス共有
- 外部への一時的なデータ受け渡し
- 検証用途
こうした用途には有効です。
ただし、Databricksの基盤設計としては問題があります。
- キーの漏洩リスク
- 有効期限管理が必要
- アクセス制御が粗い
- Unity Catalogと連携できない
そのため、常設の接続には使うべきではありません。
OAuth（サービスプリンシパル）
OAuthは、Azure AD（Entra ID）上のサービスプリンシパルを使った認証方式です。
- Client ID / Secret を使う
- RBACで権限管理
- プログラムから利用可能
一見すると柔軟で強力ですが、弱点もあります。
- シークレット管理が必要
- ローテーション運用が発生
- 漏洩時のリスクが大きい
では、なぜ今でも使われるのか。
OAuthが必要になる唯一の正当なケース
それが、**テナントを跨ぐ接続（Cross-tenant）**です。
たとえば次のようなケースです。
- 別会社のAzure環境にあるADLSを参照する
- パートナー企業のデータを直接読み込む
- グループ会社間でテナントが分かれている
この場合、自分のテナントの Managed Identity は使えません。
なぜなら、MIは同一テナント内でのみ有効なIdentityだからです。
このときの選択肢は次のとおりです。
- B2B（ゲストユーザー）として招待
- サービスプリンシパルを発行してもらう
このようなケースでは、OAuthが現実的な選択になります。
つまり、
OAuthは「仕方なく使うもの」であり、「積極的に選ぶものではない」
という位置づけです。
Managed Identity（MI）
Managed Identity は、現在の標準的な認証方式です。
特徴はシンプルです。
- シークレット不要
- Azureが認証情報を管理
- RBACでアクセス制御
ここで重要な理解があります。
Managed Identityの正体は「Azureが管理するサービスプリンシパル」です。
つまり、
- 内部的にはサービスプリンシパル
- ただし人間はシークレットに触れない
- 完全に管理された状態で運用される
この「触れない」ことこそが、安全性の本質です。
MIのメリット
Managed Identityを使うことで、次のメリットが得られます。
- シークレット管理が不要
- 漏洩リスクが極小化
- ローテーション不要
- RBACで一元管理
- Unity Catalogと自然に統合
さらに、Access Connectorと組み合わせることで、
- Databricks → Identity → ADLS
というシンプルな信頼構造が実現します。
使い分けまとめ
実務での判断はシンプルに整理できます。
- 通常構成 → Managed Identity（MI）一択
- テナント跨ぎ → OAuth（サービスプリンシパル）
- 一時共有 → SAS（限定用途のみ）
この優先順位を崩さないことが重要です。
よくあるアンチパターン
認証設計でよくある失敗も整理しておきます。
- とりあえずSASで接続する
- サービスプリンシパルを乱立させる
- Key Vaultにシークレットを溜め込む
- マウント前提で設計する
- Identityではなく人に権限を付ける
これらはすべて、運用負債につながります。
まとめ：認証設計は「シンプルに寄せる」
認証方式は複数ありますが、設計思想はシンプルです。
- マウントは使わない（マウントレス設計）
- Managed Identityを標準とする
- 例外としてOAuthを使う
- SASは限定用途に留める
つまり、
「複雑なことをしない」ことが、最も安全で強い設計です。
Databricks と Azure の組み合わせでは、
すでに最適なパターンが用意されています。
それに素直に乗ることが、結果的に最短で最強の構成になるのです。