🌏
Databricks RBAC（Role-Based Access Control）の技術解説
0章 イントロ：なぜ "いま" Databricks RBAC なのか
データドリブン経営が当たり前になり、すべての社員にデータを開放しつつ、漏えい・誤用を防ぐという相反する要求が一気に高まっています。各国の個人情報保護法（GDPR／改正個人情報保護法など）や業界ガイドラインが強化される一方で、生成 AI・セルフサービス BI の普及により “利用者” と “データ資産” の双方が爆発的に増加しました。
Databricksでは従来、ワークスペースACLやクラウドIAMを組み合わせてきましたが、
- 粒度が粗く（テーブル単位の細分化が困難）
- マルチクラウド／マルチワークスペースで設定が散逸
- 権限ごとの監査・可視化コストが高い
という課題が表面化していました。これを抜本的に解決する鍵がRole-Based Access Control（RBAC） + Unity Catalogです。
Data + AI Summit 2025 ではさらに、
- Role Switching UI：複数ロールを持つユーザーがワンクリックで権限を切替え
-
タグ駆動の自動ポリシー付与（ABAC への布石）：データ分類タグと連動して
GRANTを自動化 - Delta と Iceberg を単一カタログで管理：フォーマット横断で一貫したRBACを実現
といった新機能が発表され、ガバナンス運用のハードルは大幅に低下しています。
Data + AI Summit 2025: Your guide to data and AI governance talks
つまり “いま” RBAC を導入する最大の理由は、データ民主化のスピードと法規制・監査負荷の増大の交点に到達したからです。最小権限原則を自動で担保しつつ、エンジニアはSQL/Terraformで一貫したコード化が可能――それが Databricks RBAC の提供価値です。
1章 Databricks RBAC の基本モデル
1.1 登場人物：Principal
| 種類 | 典型例 | 備考 |
|---|---|---|
| User | 社員のAzureAD/Oktaアカウント | SSOで自動連携 |
| Group |
data_scientists, finance_analysts
|
付与はグループ単位が原則（最小権限 + 運用簡素化） |
| Service Principal | ETLジョブ、BIツール連携 | 機械ユーザー。SCIM or Terraformで管理 |
Principalは権限を授与される側で、この3種類に集約されます。
Unity Catalog privileges and securable objects
1.2 守る対象：Securable Object 階層
Metastore ← 最上位（1 テナント 1 つ）
└─ Catalog ← ドメイン単位 (sales, hr …)
└─ Schema ← 論理 DB 名
└─ Table / View / Function / Volume
上位オブジェクトに付与した特権は下位に継承されるのが大原則。たとえばGRANT SELECT ON SCHEMA sales.raw TO finance_analystsを実行すると、同スキーマ配下のすべてのテーブルが参照可能になります。
1.3 主要 Privilege と権限設計のコツ
| レイヤ | 代表Privilege | 典型的ユースケース |
|---|---|---|
| Metastore | CREATE CATALOG |
データプラットフォーム管理者 |
| Catalog | USE CATALOG |
ドメインごとにアクセス制限 |
| Schema |
CREATE TABLE, APPLY TAG
|
モデリング&データ分類 |
| Table |
SELECT, INSERT, DELETE
|
行・列レベルセキュリティ併用可 |
| すべて | MANAGE |
所有権なしで権限管理のみ委譲 (Public Preview) |
MANAGEは「オブジェクト所有権を移さずに権限操作だけ委譲したい」場合に便利です。
Manage Unity Catalog object ownership
1.4 データ RBAC とインフラ RBAC のすみ分け
| 領域 | 管理対象 | 主な設定画面 |
|---|---|---|
| データ面 (Unity Catalog) | カタログ／テーブル／AI モデル／タグ | Catalog Explorer, SQL, Terraform |
| ワークスペース面 | Notebook, Folder, Dashboard | Workspace ACL ※フォルダ単位で継承 |
| インフラ面 | Cluster Policy, SQL Warehouse, Job | “Permissions” タブ or API |
ワークスペースACLはフォルダ継承で管理し、ジョブ・パイプラインは “Edit permissions” で PrincipalごとにCAN MANAGE等を付与します。
Access control lists
Manage identities, permissions, and privileges for Lakeflow Jobs
1.5 RBAC をコードで管理する例
-- 1) ドメイン用カタログを作成
CREATE CATALOG sales COMMENT 'Sales domain data';
-- 2) 権限付与
GRANT USE CATALOG ON CATALOG sales TO GROUP finance_analysts;
GRANT SELECT ON ALL TABLES IN SCHEMA sales.analytics TO GROUP finance_analysts;
-- 3) Terraform 例 (抜粋)
resource "databricks_grants" "sales_select" {
securable_type = "SCHEMA"
securable_name = "sales.analytics"
grant {
principal = "finance_analysts"
privileges = ["SELECT"]
}
}
SQL → IaC まで一貫して “コードで権限を記録” できるのが Databricks RBAC の強みです。
Manage privileges in Unity Catalog
1.6 よくある設計パターン
-
グループ・ロール中心：個人への直接
GRANTは避け、IDPグループか職務ロール単位で付与 -
ドメイン分割：
sales,hrなどCatalogごとに最小権限を徹底 -
タグ駆動：機微データに
pii=trueタグを付与し、APPLY TAG,SELECTを組み合わせて自動制御（ABAC的運用） -
監査ログ活用：
system.accessテーブルでGRANT/REVOKEやデータアクセス履歴を定期レビュー
1.7 アップグレード時の一歩
-
Workspace Binding（2025 GA）を使えば、外部ロケーション・ストレージ資格情報をワークスペース単位で閉域化でき、PoC↔本番の誤公開リスクを抑制。
March 2025 - 既存Hiveメタストアは “Unity Catalog Migration” ツールで段階移行が推奨。
まとめ
Databricks RBACは「Principal × Securable × Privilege」というシンプルな3軸設計を徹底することで、セキュリティポリシーの再現性とコード化を実現します。次章ではSummit 2025で発表された新機能を、従来課題と紐付けながら速習します。
2章 Summit 2025 アップデート速習
2.1 3行まとめ
- マルチロール対応：ワンクリックでロールを切替えられるRole Switching UIがGA。
- ABAC時代へ：データ分類タグと連動して権限を自動発行するTag Policies：プレビューを公開。
- フォーマット横断ガバナンス：DeltaとIcebergを単一カタログで統合管理できるようになり、RBAC設定の一元化が完了。
2.2 主要アップデート詳細
| 新機能 | 従来の課題 | どう変わったか |
|---|---|---|
| Role Switching UI | 1ユーザーが複数ロールを持つと誤アクセスリスクが高い | 画面右上のドロップダウンから即時ロール切替え。操作履歴も監査ログに記録されるためトレーサビリティ確保 Solving Exclusive Data Access With Role-Based Access Control |
| Tag Policies（ABAC の布石） | 人手によるGRANT運用はスケールせず設定漏れが発生 |
pii=trueなどのタグとポリシーを紐付け、オブジェクト作成時に自動で権限・マスキングを適用。マルチクラウド対応（Beta）What’s new with Databricks Unity Catalog at Data + AI Summit 2025 Introducing Tag Policies and ABAC: A New Era of Fine-Grained Data Governance on Databricks |
| Delta & Iceberg 統合カタログ | フォーマットごとにガバナンスが分断 | Unity Catalog がメタデータレイヤを共通化し、RBAC／監査／ラインageを一元提供 Databricks Data + AI Summit 2025: All 15+ Big Product Drops |
| Metric Views & 内部 Marketplace | BI用KPIやMLモデルは別ツールで管理 | テーブルと同じRBACで“公式指標”やML生成物を共有でき、社内マーケットで再利用促進 Driving Trusted Insights With AI/BI and Unity Catalog Metric Views Databricks Data+AI Summit 2025 — Key Things To Know |
| Workspace Catalog Binding 強化 | PoC ワークスペースから本番データに誤アクセス | カタログをワークスペースにバインドし、ストレージ資格情報も隔離。マルチ環境の誤公開リスクを低減 Data Governance |
2.3 運用インパクト
- 権限モデルの単純化：フォーマット差異や複数ロール問題が解消し、GRANT ルールは “タグ＋カタログ階層” の２軸で済む。
- 自動化範囲の拡大：Terraform／REST API で Tag Policies をコード化 → CI/CD に組み込み可能。
-
監査 & コンプライアンス強化：ロール切替え・タグ適用・クロスフォーマットアクセスがすべて
system.accessテーブルに記録され、証跡収集が統一。
2.4 次にやること
-
タグ設計：機微情報ラベル（例：
pii,finance,public）を部門横断で統一。 - PoC：小規模カタログでTag PoliciesとRole Switchingを試し、監査ログを確認。
-
IaC移行：既存
GRANTスクリプトをTerraformへ置き換え、PR レビューで権限差分を可視化。
3章 実装クイックガイド
3.1 前提チェック
| チェック項目 | 推奨値 |
|---|---|
| Workspace Runtime | DBR 14 LTS 以上 |
| Unity Catalog | 有効（Metastore 作成済み） |
| Terraform コントロールプレーン | v1.8+ と Databricks Provider 1.35+ |
3.2 SQL だけで試す ― 6 ステップ
| # | コマンド | 目的 |
|---|---|---|
| 1 | CREATE CATALOG demo; |
検証用カタログを用意 |
| 2 | CREATE TAG pii COMMENT '個人情報'; |
属性タグを定義 |
| 3 |
CREATE SCHEMA demo.raw;CREATE TABLE demo.raw.users(id INT, name STRING) TAGS(pii=true);
|
PII タグつきテーブルを作成 |
| 4 |
CREATE ROLE analyst;GRANT USE CATALOG ON CATALOG demo TO ROLE analyst;
|
RBAC: カタログ参照権を役割に付与 |
| 5 |
Tag Policy (Beta)sql CREATE TAG POLICY mask_pii ON TAG pii WHEN tag_value = 'true' THEN APPLY MASK name USING sha2(name,256);
|
ABAC: pii=true なら列マスキング |
| 6 | ALTER USER alice SET DEFAULT_ROLE = analyst; |
ログイン時のデフォルトロール設定 |
ステップ5が「タグ → 自動ポリシー」の要。ポリシーは system.access にも記録されるため、監査証跡が残る
Tag policies
What’s new with Databricks Unity Catalog at Data + AI Summit 2025
3.3 Role Switching UI の確認
- Aliceでログインし、右上プロフィール → Switch roleをクリック。
-
analystを選択し直すと、テーブルusersのname列がハッシュ値で返る。 - UI 操作と列マスキング両方のイベントが監査テーブル
system.accessに出力されていることを確認。
複数ロールを持つ利用者でも「誤って権限の強いロールを使い続ける」事故を防止
Solving Exclusive Data Access With Role-Based Access Control
3.4 Terraform でコード化
# Provider
provider "databricks" { host = var.workspace_url }
# 1) カタログ
resource "databricks_catalog" "demo" {
name = "demo"
comment = "PoC catalog"
}
# 2) 役割 (プリンシパル)
resource "databricks_sql_role" "analyst" {
name = "analyst"
}
# 3) 権限
resource "databricks_grants" "demo_catalog" {
securable_type = "catalog"
securable_name = databricks_catalog.demo.name
grant {
principal = databricks_sql_role.analyst.name
privileges = ["USE CATALOG"]
}
}
# 4) Tag Policy (Beta)
resource "databricks_tag_policy" "mask_pii" {
name = "mask_pii"
definition_json = jsonencode({
"when" : "tag_value = 'true'",
"then" : {
"apply_mask" : {
"expression" : "sha2({{column}}, 256)"
}
}
})
tag_name = "pii"
}
terraform planをPRで自動実行 → 権限差分をレビュー する運用がベストプラクティス
databricks_grants Resource
3.5 ハマりやすいポイント
| 症状 | 原因 | 対処 |
|---|---|---|
| Tag Policy が発火しない | テーブル作成時にタグ未付与 |
TAGS(pii=true)を忘れず指定 |
| Role Switching UI が表示されない | ユーザーが 1 つのロールしか持たない | 2ロール以上を GRANTする |
| Terraform の差分が毎回出る | 外部で手動GRANTした |
“Everything-as-Code”を徹底し、手動操作を禁止 |
まとめ
- RBACで基本的なアクセス境界を張り、
- ABAC：Tag Policiesでタグ条件に応じたマスキング／拒否を“自動”で付与、
-
Role SwitchingとIaCでヒューマンエラーと監査コストを最小化。
これで「セキュリティ強化」と「運用省力化」を両立できる実装雛形が完成します。
4章 運用ベストプラクティス & 今後
4.1 運用設計の基本原則
- 最小権限：PoLP × Infrastructure-as-Code：IaCを大前提に、権限はコードとPull Requestで管理する
- グループ／タグ中心で定義し、個人単位のGRANTは例外扱いにする
-
監査テーブル
system.access.auditで常時トレーシング。実際の利用実績に基づき権限を棚卸しする
Audit log system table reference
4.2 ベストプラクティス Top 7
| # | 推奨事項 | 効果 |
|---|---|---|
| 1 | グループ ↔ ロール ↔ カタログ階層でRBACを統一 | ロール爆発を防ぎ、棚卸しが容易になる |
| 2 |
IaC & Drift Detection：databricks_grants + CI で差分レビュー |
手動操作の野良権限を排除 |
| 3 | 共通タグ辞書 + Tag Policy：ABAC |
pii=true などを軸にポリシーを自動適用し、人手の GRANT 漏れを撲滅Create and manage attribute-based access control (ABAC) policies Tag policies |
| 4 |
Workspace-Catalog Binding：PoC／本番をカタログで分離し誤公開を防止 Limit catalog access to specific workspaces |
マルチ環境運用でもストレージ資格情報を隔離 |
| 5 |
Managed Table 推奨：外部テーブルは Read-Only に留める Unity Catalog best practices Unity Catalog best practices：Azure |
ガバナンス・ラインエージを一元化 |
| 6 |
行・列レベルセキュリティの活用：Row Filter / Column Mask を標準化 Filter sensitive table data using row filters and column masks |
データコピーを減らし、機微情報の漏えいリスクを下げる |
| 7 | 定期リハーサル：Role Switching UI + 監査ログで「権限変更→動作」をテスト | 意図しないアクセスを早期に検知 Filter sensitive table data using row filters and column masks |
4.3 監査 & モニタリング
-
system.access.auditで以下をクエリ
SELECT user_identity.email, action_name, timestamp
FROM system.access.audit
WHERE action_name LIKE 'GRANT%' OR action_name LIKE 'USE_%';
- ダッシュボード化：権限操作・Data Access・Role Switch を日別集計し、異常値をアラート
- 自動棚卸し：90 日未使用ロールをレポートし、削除候補としてPR化
4.4 アンチパターン
| 症状 | 典型原因 | 是正策 |
|---|---|---|
| ロール数がユーザー数並みに膨張 | 人単位 GRANT
|
IDP グループへの一元化 |
| タグ定義がチームごとにバラバラ | 共通語彙なし | 経営レベルでタグ辞書を承認・固定 |
| 監査ログが空 | Workspace でシステムテーブル未有効 |
SET enable_system_tables = true; を全ワークスペースで実行 |
4.5 今後のロードマップ（2025-2026）
| 項目 | 方向性 | 期待効果 |
|---|---|---|
| ABAC/Tag Policies GA | Beta → GA。ポリシー条件に時間帯・ネットワークなどコンテキスト属性を追加予定 What’s new with Databricks Unity Catalog at Data + AI Summit 2025 |
ロール依存をさらに削減 |
| Lakehouse Federation ガバナンス統合 | 複数エンジン（Redshift, BigQuery…）でも Unity Catalog RBAC/ABAC を横串管理 Unify Your Data and Governance With Lakehouse Federation |
データソース越えの最小権限制御 |
| ポリシー・シミュレーション UI | “適用前に影響範囲を試算” するツールを提供予定（Summit発表） What’s new with Databricks Unity Catalog at Data + AI Summit 2025 |
誤設定リスクを事前にゼロに |
| 行・列レベルセキュリティ強化 |
apply_row_filterに動的関数、テンポラル条件を拡充予定What’s new with Databricks Unity Catalog at Data + AI Summit 2025 |
マスキングロジックをコードレス化 |
| AI-Assisted 権限提案 | 監査ログを学習し “不要な権限” や “不足権限” をレコメンド | 棚卸し自動化 & DevX 向上 |
4.6 まとめ
- RBAC = “誰 (ロール)” と “何” を静的に対応づける土台
- ABAC = 属性条件で RBAC を動的に拡張する仕組み
- 両者は対立ではなく補完関係。RBACで管理コストを抑えつつ、ABACでロール爆発を回避しながら最小権限を強化するのがモダンデータプラットフォーム（Databricks 含む）の主流アプローチ。
- Summit 2025 のアップデートによりLakehouse全体を横断する統合ガバナンスが見えてきた――ロードマップを踏まえ、タグ設計・自動化基盤・監査ダッシュボードを今すぐ仕込んでおくのが、2026年以降のデータ民主化を支える最短ルート。
その他1：RBACとABACの関係
| 項目 | RBAC (Role-Based Access Control) | ABAC (Attribute-Based Access Control) | 関係性・補完ポイント |
|---|---|---|---|
| 制御単位 | ロール 例: data_scientist, finance_analyst
|
属性 （Subject / Resource / Action / Context） 例: 部門=sales, 機微区分=PII, IP範囲=社内, 時間帯=業務時間内
|
RBACをコアに据え、ABACで追加条件を掛け算する構成が一般的 |
| ポリシー記述 | GRANT SELECT ON TABLE t TO ROLE finance_analyst; |
ALLOW SELECT ON TABLE t WHEN resource.tag.pii = false AND context.time < 18:00; |
ABACはRBACより自由度が高いが、ポリシーが複雑になりやすい |
| メリット | シンプル・理解しやすい 権限棚卸しが容易 |
きめ細かい制御・自動化 タグや IDP 属性に基づく動的付与 |
RBAC: 管理容易／ABAC: 柔軟性 というトレードオフ |
| 課題 | ロール爆発（組み合わせが増えすぎる） | ポリシー設計・テストが複雑 | RBACで粗粒度 → ABACで微調整 が実務的 |
| Databricks 例 | GRANT SELECT ON SCHEMA sales TO GROUP finance_analyst; |
Tag Policies (Summit 2025 プレビュー) タグ pii=true なら自動マスキング |
Tag Policies = RBACにABAC条件を重ねる実装 |
その他2：各DWHの比較
| ガバナンス観点 | Databricks (Unity Catalog) | Snowflake | Amazon Redshift / Redshift Serverless |
|---|---|---|---|
| コアモデル / 階層 | RBAC：Principal → Metastore→Catalog→Schema→Table／Cluster など。継承あり | RBAC：Role → Database→Schema→Object。親子ロール継承あり Overview of Access Control |
RBAC：DBロール／IAM統合。Schema→Table／View。外部は IAM & Lake Formation |
| ABAC（タグ条件） | Tag Policies (Beta 2025)：タグ pii=true 等に応じて自動マスク・行フィルタUnity Catalog attribute-based access control (ABAC) Create and manage attribute-based access control (ABAC) policies |
Tag-based Masking Policy／Row Access Policyで擬似ABACを実装 Using Dynamic Data Masking Understanding row access policies |
ネイティブABACなし。Lake Formationと連携し S3 外部テーブルにタグ条件を適用 Redshift Spectrum と AWS Lake Formation |
| 行・列レベル制御 | ABAC Policy で Row-Filter／Column Mask（Beta） | Row Access Policy + Dynamic Data Masking で CLS/RLS Understanding row access policies Understanding Dynamic Data Masking |
Row-Level Security & Column-Level Security は SQL で定義 行レベルのセキュリティ |
| ダイナミックマスキング | 列マスク式を Tag Policy に内包（sha2 など） | Dynamic Data Masking（Enterprise Edition 以上） Using Dynamic Data Masking Understanding Dynamic Data Masking |
ネイティブ機能なし（ビュー／UDF で代替） |
| 監査・モニタリング |
system.access.audit テーブルで RBAC/ABAC/RoleSwitch を統合記録Audit log system table reference |
ACCOUNT_USAGE.ACCESS_HISTORY ほかで読取／書込を最大1年保持Access History ACCESS_HISTORY view |
DB監査ログ + CloudTrail/CloudWatch で API & SQL 操作を記録 CloudTrail によるログ記録 データベース監査ログ作成 |
| マルチフォーマット / 連携 | Delta & Iceberg を単一カタログで統合ガバナンス（2025 GA） | Proprietaryストレージ中心。外部テーブルは同一RBACで管理可 | Spectrum + Lake Formation で S3 を統合。RBACはサービス横断的に IAM へ |
| IaC & 自動化 | Terraform databricks_grants / REST / CLI で完全コード化 |
Terraform Provider（snowflake_*_grant）で Role & Grant を管理Terraform snowflake_grants (Data Source) |
CloudFormation/CDK + Parameter Group で RLS/CW設定を自動化 CloudTrail によるログ記録 |
総評
-
粒度と一貫性
- Databricks Unity CatalogはRBACを骨格にタグ駆動 ABACをネイティブ実装し、Delta・Icebergを跨いだ“単一メタストア”で統合管理できる点が突出。データエンジニアリング〜AI 資産まで一つのポリシー体系で守れる。
- SnowflakeはRBACが成熟し、Dynamic Data Masking + Row Access Policy + タグの組合せで多彩な制御が可能。ただしフォーマット横断の統合は限定的。
- Redshiftは RLS/CLS によりテーブル内の微粒度制御は備えるが、タグ連動やフォーマット統合は AWS Lake Formation 頼りといった“周辺サービス連携型”。
-
自動化と監査
- DatabricksとSnowflakeはいずれもTerraformで “Everything-as-Code” が可能かつ監査テーブルが標準装備。
- RedshiftはCloudTrail／CloudWatchに分散するため、統合ビューを自作する手間が残る。
-
今後の伸びしろ
- DatabricksのTag PoliciesがGAし、Lakehouse Federation にも拡張されればクロスエンジンを含む一元ガバナンスが現実的。
- Snowflakeは既に多機能だが、フォーマット縛りをどう緩和するかが課題。
- RedshiftはLake Formationの統合度合いが鍵。セルフサービスでタグ → ポリシーまで自動化できれば追随可能。
Discussion