Databricksを基幹データ基盤として使い、年次の内部監査がある数千人規模の企業では、データ基盤担当と監査部門が同じ課題に直面している。機密データへのアクセス権限を誰にどこまで見せるかという設計を、グループ権限の積み上げ方式のままにしておいてよいのか、という問いである。Databricksは2026年8月19日、RBAC(ロールベースアクセス制御、Role-Based Access Control)を一般提供(GA)した[1]。ロールの実体はアカウントまたはワークスペースのグループで、ユーザーがそれを引き受けて使う。ユーザーが明示的にロールを引き受けている間だけ、そのロールの権限のみが有効になる仕組みで、複数グループへの所属で権限が積み上がっていく従来モデルとは前提が異なる[1][2]。内部統制対応や監査法人対応のタイミングは、権限設計を見直す数少ない好機でもある。本稿では変更点の中身と、データ基盤部門・監査部門が今回のGAをどう位置づけるべきかを整理する。
予備知識
- RBAC(ロールベースアクセス制御)＝ユーザー個人ではなく「役割(ロール)」に権限を紐づけ、その役割を使う間だけ権限を有効にする方式
- Unity Catalog＝Databricks上でデータ・AI資産の権限を一元管理する機能
- ロール引き受け(role assumption)＝ユーザーが特定のロールを明示的に選択し、その間だけロールの権限で操作すること
- グループ権限の積み上げ方式＝ユーザーが所属する全グループの権限が合算され、常時有効になる従来方式
権限設計をデータガバナンス全体の中でどう位置づけるか、体系的な整理に使える
DatabricksのRBAC一般提供で何が変わったのか
DatabricksのRBACは、ユーザー起点ではなくロール起点で権限を切り替える仕組みである。2026年8月19日に一般提供され、ロールを引き受けている間はそのロールの権限だけが適用され、ユーザー自身が本来持つ累積権限には戻らない[1]。Databricksの説明では、ロールの実体はグループであり、特定のグループに「Assume(引き受け)」権限を付与することでロールとして機能させる[2]。
ユーザーはワークスペースUI上のロール切替、ロール専用のアクセスモードを割り当てたクラスタ、CLI、API、BIツール連携のいずれかからロールを引き受けられる[2]。有効化は次の順で進む。
| 手順 | 実施者 | 内容 |
|---|---|---|
| 1 | アカウント管理者 | アカウントレベルで機能全体を有効化 |
| 2 | ワークスペース管理者 | 個々のワークスペースで機能を有効化 |
| 3 | 利用者 | ロールを引き受けて作業を開始 |
アカウント管理者が先に機能をオンにしないと、個々のワークスペースでは有効化できない[1]。全社一括切り替えではなく、ワークスペース単位で段階的に展開できる設計である。
権限変更を内部統制の証跡要件に落とし込む際の基礎知識になる
旧来のグループ権限方式とRBACは何が違うのか
両者の違いは「権限が常時足し算されるか」「用途ごとに切り替えるか」にある。従来方式はユーザーが所属する全グループの権限が合算され、ログイン中は常に有効になる。RBACでは、ロールを引き受けた瞬間だけそのロールの権限に切り替わり、他の用途の権限は一時的に見えなくなる[2]。ただしワークスペースの全ユーザーに共有されているカタログ・Unity Catalogのオブジェクト・コンピュート・ワークスペース資産は、ロールを引き受けている間も見える[2]。
Databricksの資料は、RBACが既存のグループ権限を置き換えるのではなく、併存させる仕組みだと説明している[2]。ロールを引き受けていない間は、従来どおり所属グループの権限で操作する。両者を並べると次のようになる。
| 観点 | 従来のグループ積み上げ | RBAC(ロール引き受け) |
|---|---|---|
| 最小権限の露出時間 | ログイン中は常時露出 | ロール引き受け中のみ露出 |
| 監査ログの粒度 | 個人アカウント単位 | 引き受けた人(run_by)と引き受けたロール(run_as)の両方を記録[2] |
| 用途間の混在防止 | グループ設計次第で混在しうる | 引き受け中は他用途の権限が無効化される（全ユーザー共有の資産は除く） |
| 運用負荷 | グループ設計の見直しが低頻度 | ロール定義とAssume権限の管理が追加で発生 |
監査ログにrun_byとrun_asの両方が記録される点は、誰が・どのロールとして・何をしたかを追跡する際の粒度が上がることを意味する[2]。
SIer（システムインテグレーター）やMSP（マネージドサービスプロバイダー）にMicrosoft 365・Entra ID環境の運用を委託している企業は多い。数千人規模のテナントで、日々の設定変更や障害対応を委託先が代行している場合、「[…]
導入・移行はどう進めるか
RBACは既存のグループACLを即座に置き換える機能ではない。まずアカウント管理者が機能を有効化し、監査対象になりやすい機密スキーマや特定プロジェクト用のグループを選んでロール化するのが現実的な出発点である[1][2]。
ロール化はグループへの「Assume」権限付与という形で行われるため、既存のグループ設計を大きく作り直さずに始められる[2]。まず1つの機微データ領域でパイロット運用し、監査ログのrun_by/run_asが意図どおり記録されるかを確認したうえで、対象範囲を広げる進め方が無理がない。
全ユーザーに一律でロール引き受けを強制する必要はなく、機密度の高いデータにだけロールを設定し、それ以外は従来のグループ権限のまま運用する併存構成も選べる[2]。
「このアプリケーションは対象外にしているから、条件付きアクセスの制約を受けない」。多くの企業のID基盤担当者が、そう考えてポリシー設計をしてきたはずだ。しかし2026年6月15日から段階的に始まった変更で、この前提の一部が崩れる。Micr[…]
国内の内部統制対応でRBACはどう位置づけるべきか
内部統制報告制度(いわゆるSOX対応)や監査法人対応では、誰がいつ機密データにアクセスしたかの証跡が問われる。RBACのrun_by/run_as併記は、この証跡要件と相性がよい[2]。従来のグループ設計では、権限を持つ全員が常時アクセス可能な状態を説明する必要があったが、RBACなら「用途ごとに引き受けた記録」で説明できる。
一方で、既存の権限設計を変えること自体に社内調整コストがかかる。特にSIerへ運用を委託している場合は、権限設計の変更管理プロセスに沿って委託先と合意形成する手間が増える。ロール化の範囲を機密度の高い一部スキーマに絞れば、この調整コストは抑えられる。
- データ基盤部門の次の一手: 機密性の高いスキーマ1つを選び、既存グループをロール化してパイロット運用する
- 監査/決裁側の判断材料:
run_by/run_asログが年次監査の証跡要件を満たすか、監査法人と事前にすり合わせる
まとめ
DatabricksのRBACは、権限を「常時持つもの」から「用途ごとに引き受けるもの」へ切り替える仕組みであり、既存のグループACLを置き換えるのではなく併存させる設計である[1][2]。監査ログに引き受けた人とロールの両方が残る点は、内部統制対応での説明力を高める材料になる。
データ基盤担当は、まず機密度の高いスキーマ1つでロール化とパイロット運用を試し、監査ログの記録内容を確認するとよい。監査・決裁側は、既存のグループ設計をどこまで残し、どこからロール化するかの線引きを、次回監査サイクルの前に整理しておくとよい。権限設計の見直しは、機能が使えるようになった今が動きやすい時期である。
よくある質問（FAQ）
Q. RBACを有効化すると既存のグループ権限はなくなりますか。
A. なくなりません。RBACは既存のグループ権限と併存する仕組みで、ロールを引き受けていない間は従来どおりグループ権限で操作します[2]。
Q. ロールは誰が作るのですか。
A. 既存のグループに「Assume」権限を付与することでロール化します。新しい概念をゼロから作るのではなく、既存のグループ管理の延長で設定できます[2]。
Q. Azure DatabricksやGoogle Cloud上のDatabricksでも同じ機能ですか。
A. 本稿はAWS上のDatabricksのリリースノートと製品ドキュメントに基づいています。他クラウド版の提供時期や挙動は、各クラウド向けドキュメントで別途確認してください。
出典
- Databricks on AWS Release Notes, August 2026, https://docs.databricks.com/aws/en/release-notes/product/2026/august
- Databricks on AWS, Role-based access control (RBAC), https://docs.databricks.com/aws/en/security/auth/rbac/
