Azure Databricksでアカウントグループをワークスペースから外しても、そのグループに設定したフォルダーやNotebookの権限は自動では消えません。今後の仕様変更では、ワークスペースへ直接割り当てていないアカウントグループの権限も評価されるようになるため、現在は非アクティブな「orphaned permissions」が再び有効になる可能性があります。
対策は、公式の「Orphaned permissions analysis notebook」を使って非アクティブな権限付与を検出し、不要なフォルダー、Notebook、ジョブ、クエリ、ダッシュボードのACLを変更前に削除することです。
2026年7月23日時点、Microsoft Learnでは本変更を「今後のリリース」と案内しており、具体的な適用日は示されていません。新しい権限が追加されるわけではなく、過去から残っている権限付与が有効化される変更です。適用日の確定を待たず、早めに監査を完了させる必要があります。(Microsoft Learn)
削除済みグループの権限が復活する前に知っておくべき変更点
Azure Databricksでは、NotebookやフォルダーなどのワークスペースオブジェクトにACLを設定できます。
現在は、原則としてワークスペースへ直接割り当てられたアカウントグループの権限がメンバーへ継承されます。今後は、ユーザーが所属するすべてのアカウントグループが権限評価の対象になります。
| 確認項目 | 現在 | 変更後 |
|---|---|---|
| 権限継承の対象となるグループ | ワークスペースへ直接割り当てられたアカウントグループ | ユーザーが所属するすべてのアカウントグループ |
| ワークスペースから外したグループのACL | 非アクティブ | 条件を満たすと有効化 |
| ユーザー自身のワークスペース割り当て | 必要 | 引き続き必要 |
| 新しいACLの追加 | なし | なし |
| 管理者が行うべき対応 | 残存ACLの把握 | 不要な残存ACLの削除 |
重要なのは、ワークスペースへ割り当てられていないユーザーが突然ログインできるようになる変更ではない点です。ユーザー自身は、個別割り当てや別のグループなどを通じて、引き続きワークスペースへ割り当てられている必要があります。
問題になるのは、次の2つを同時に満たすユーザーです。
- 個別割り当てや別グループ経由で、そのワークスペースを利用できる
- 過去にワークスペースから外したアカウントグループにも所属している
この場合、外したグループに残っているオブジェクト権限が、仕様変更後に有効になる可能性があります。(Microsoft Learn)
正確には権限が復元されるのではなく、残存ACLが有効になる
「削除したグループの権限が復活する」と表現されることがありますが、正確には権限が新しく作り直されるわけではありません。
今回の対象は、アカウントグループそのものをDatabricksアカウントから完全に削除したケースではなく、主にグループを対象ワークスペースから外したケースです。
Microsoftの公式ドキュメントでは、アカウントグループをワークスペースから削除しても、グループに設定されていた権限は維持されると説明されています。従来もグループを再度ワークスペースへ追加すると、以前の権限を取り戻す仕組みでした。(Microsoft Learn)
つまり、次の2つは別の操作です。
| 操作 | 実際に変更されるもの |
|---|---|
| グループをワークスペースから外す | グループ経由のワークスペース利用可否 |
| オブジェクトのACLからグループを削除する | Notebook、フォルダー、ジョブなどへの権限 |
前者だけを実施しても、後者のACLは残ります。
仕様変更後に起こり得る具体例
たとえば、外部委託先向けのアカウントグループContractorsに、機密プロジェクト用フォルダーの編集権限を付与していたとします。
契約終了後、管理者はContractorsをワークスペースから外しました。しかし、フォルダーのACLからは削除していませんでした。
その後、次の状態になっているとします。
- Aさんは個別割り当てによりワークスペースを利用している
- AさんはDatabricksアカウント上で、引き続き
Contractorsのメンバーになっている Contractorsには対象フォルダーの編集権限が残っている
現在はこの権限が非アクティブでも、仕様変更後はAさんがContractors経由で編集権限を継承する可能性があります。
このような「グループの割り当て解除とACL削除が一致していない状態」を、Orphaned permissions analysis notebookで検出します。
今回の変更で監査すべき権限の範囲
公式案内では、今回の変更によって影響するワークスペースオブジェクトの例として、次のものが挙げられています。
- ジョブ
- Notebook
- フォルダー
- クエリ
- ダッシュボード
Azure Databricksには複数のアクセス制御方式があるため、今回の変更をUnity Catalogのデータ権限と混同しないように注意してください。
| 保護対象 | アクセス制御方式 | 今回の主な監査対象 |
|---|---|---|
| Notebook、フォルダー、ジョブ、クエリ、ダッシュボードなど | ワークスペースACL | 対象 |
| アカウントレベルのグループやサービスプリンシパル | アカウントRBAC | 別途確認 |
| カタログ、スキーマ、テーブル、ボリュームなど | Unity Catalog | 別途確認 |
Orphaned permissions analysis notebookでワークスペースACLを監査しても、Unity CatalogのSELECT、USE SCHEMA、MODIFYなどのデータ権限まで自動的に整理されるわけではありません。データへのアクセスリスクも調べる場合は、Unity Catalogの権限監査を別作業として実施します。(Microsoft Learn)
Orphaned permissions notebookで監査する具体的な手順
監査は、Notebookを一度実行して終わりではありません。対象範囲の確定、検出結果のレビュー、ACLの修正、再実行までを一連の作業として扱います。
| 手順 | 作業内容 | 実務上のポイント |
|---|---|---|
| 対象を整理する | 本番、開発、検証などのワークスペースを一覧化する | 一部のワークスペースだけで完了としない |
| 公式Notebookを取得する | 「What’s coming?」ページの「Get notebook」から取得する | 非公式なコピーではなく最新版を使う |
| Notebookをインポートする | 管理者用フォルダーへURLまたはファイルから取り込む | 実行結果を閲覧できるユーザーを制限する |
| Notebookを実行する | Notebook内の説明に従って実行する | 必要な権限やコンピュート条件はNotebook内の最新記載を優先する |
| 結果を保存する | 検出されたグループ、オブジェクト、権限を記録する | 実行日時と対象ワークスペースも残す |
| 削除可否を判断する | オブジェクト所有者や業務担当者へ確認する | 検出された権限を機械的にすべて消さない |
| ACLを修正して再実行する | 不要な権限を削除し、Notebookを再実行する | 未対応項目と承認済み例外だけが残る状態にする |
公式Notebookを取得してワークスペースへインポートする
まず、Azure Databricksの「What’s coming?」ページにある「Orphaned permissions analysis notebook」の「Get notebook」からNotebookを取得します。
外部Notebookは、Azure Databricksの画面から次の流れでインポートできます。
- サイドバーから「Workspace」を開く
- 管理者専用の監査用フォルダーを開く
- フォルダーを右クリックして「Import」を選択する
- URLを指定するか、取得したファイルを選択する
- 「Import」を実行する
Azure DatabricksはURLまたはファイルからのNotebookインポートに対応しています。画面構成は更新される可能性がありますが、フォルダーの右クリックメニューまたは画面右上のメニューからインポートできます。(Microsoft Learn)
監査Notebookには、ワークスペース内のオブジェクト名やグループ名などが出力される可能性があります。一般ユーザーが閲覧できる場所ではなく、管理者や監査担当者だけが利用できるフォルダーへ配置するのが安全です。
全ワークスペースを網羅できているか確認する
ワークスペースオブジェクトのACLは、ワークスペース単位で管理されます。そのため、複数のワークスペースを利用している環境では、単一ワークスペースでNotebookを実行しただけで監査完了としないようにします。
監査台帳には、少なくとも次のワークスペースを含めます。
- 本番ワークスペース
- 開発ワークスペース
- 検証・ステージングワークスペース
- 利用終了予定だがまだ残っているワークスペース
- 特定部門や外部委託先が利用する専用ワークスペース
Notebookがどのワークスペースを対象に結果を返しているかを確認し、管理対象の全ワークスペースを網羅してください。
Notebookの検出結果は削除候補としてレビューする
公式ページでは、Orphaned permissions analysis notebookを「非アクティブな権限付与を識別する」ためのNotebookとして案内しています。検出結果に表示された権限が、すべて不要とは限りません。(Microsoft Learn)
たとえば、次のようなケースがあります。
- 将来グループを再利用する予定で、意図的に権限を残している
- 別ワークスペースでは現在も利用中のグループである
- オブジェクト所有者が不明で、削除の影響を判断できない
- 子オブジェクトではなく、親フォルダーから権限を継承している
- グループ名は古いが、現行業務で引き続き利用している
Notebookの結果は「即時削除リスト」ではなく、「仕様変更前に判断が必要なACLの一覧」として扱うのが適切です。
検出された権限を削除するか判断する基準
削除判断では、グループが現在ワークスペースへ割り当てられているかだけでなく、業務上の利用目的とオブジェクトの機密性を確認します。
| 検出された状態 | 推奨する対応 |
|---|---|
| 契約終了した委託先や廃止済みチームのグループ | 原則としてACLから削除する |
| グループは他のワークスペースで利用中だが、このオブジェクトは不要 | アカウントグループは残し、対象オブジェクトのACLだけ削除する |
| 管理・編集権限が広いフォルダーに残っている | 優先して削除または権限を縮小する |
| 参照権限が機密情報を含むダッシュボードに残っている | 業務上の必要性を確認し、不要なら削除する |
| 親フォルダーから権限を継承している | 親フォルダー側のACLを修正する |
| 所有者や利用目的が分からない | 直ちに削除せず、所有者と依存関係を確認する |
| 現在メンバーがいないグループ | 未使用ならACLを削除する |
| 意図的に残す必要がある | 所有者、理由、期限、次回確認日を記録する |
現在メンバーがいないグループでも、今後新しいメンバーが追加されれば残存ACLが有効になる可能性があります。「今は誰も所属していない」という理由だけで放置しないことが重要です。
優先順位は権限の強さだけで決めない
実務では、次の4要素を掛け合わせて対応順位を決めると、重大な権限から処理できます。
対応優先度＝権限の強さ × オブジェクトの機密性 × 対象人数 × 権限の広がり
| 優先度 | 代表的な状態 |
|---|---|
| 緊急 | 多人数のグループに、重要フォルダーのCAN MANAGEやCAN EDIT相当の権限が残っている |
| 高 | 個人情報や経営情報を扱うNotebook、クエリ、ダッシュボードに参照・実行権限が残っている |
| 中 | 対象人数が少なく、限定的なオブジェクトへの参照権限だけが残っている |
| 低 | 業務上必要な理由が確認済みで、所有者と見直し期限も登録されている |
広い親フォルダーに強い権限が残っているケースは、子オブジェクトへ影響が広がるため最優先で確認します。
フォルダーとNotebookの不要な権限を削除する方法
Workspaceブラウザーでは、オブジェクトやフォルダーのメニューから共有設定を開き、ユーザー、グループ、サービスプリンシパルの権限を管理できます。
フォルダーの権限を変更する場合は、次の流れで確認します。
- サイドバーから「Workspace」を開く
- 対象フォルダーまたはNotebookを探す
- 右クリックメニューまたはオブジェクトのメニューを開く
- 「Share」または権限管理画面を開く
- Orphaned permissions notebookで検出されたグループを確認する
- 不要な権限を削除するか、必要最小限の権限へ変更する
- 変更後に対象オブジェクトへ意図しないアクセスが残っていないか確認する
フォルダー内のオブジェクトは、親フォルダーに設定された権限を継承します。Notebook側の直接権限だけを削除しても、親フォルダーから同じグループの権限を継承していればアクセスは残ります。(Microsoft Learn)
検出結果を確認するときは、権限が次のどちらなのかを区別してください。
- 対象Notebookやオブジェクトに直接設定された権限
- 親フォルダーまたはルートから継承された権限
継承権限である場合は、権限の発生元となっている親フォルダーを修正します。
ジョブ、クエリ、ダッシュボードの権限も確認する
Notebookだけを監査しても不十分です。公式案内では、ジョブ、クエリ、ダッシュボードも影響対象の例に含まれています。
各オブジェクトの共有・権限画面を開き、検出されたアカウントグループのACLを確認します。特に次の権限は優先して調べます。
- オブジェクトの権限を変更できる管理権限
- 内容を変更できる編集権限
- ジョブやクエリを実行できる権限
- ダッシュボードや実行結果を閲覧できる権限
権限レベルの名称と可能な操作は、オブジェクトの種類によって異なります。単に「読み取り権限だから安全」と判断せず、表示されるデータや実行結果の機密性も確認してください。(Microsoft Learn)
Databricks CLIで大量のACLを確認するときの注意点
対象オブジェクトが多い場合は、Databricks CLIやPermissions APIを使った確認・修正も選択肢になります。
Databricks CLIでは、次の形式でオブジェクトの権限を取得できます。
databricks permissions get <object-type> <object-id-or-path> -o jsonobject-typeには、directories、notebooks、jobs、queries、dashboardsなど、対象に応じた種類を指定します。
一括変更を行う前には、必ずpermissions getで現在のACLを取得し、JSONなどでバックアップしてください。
特に注意が必要なのがdatabricks permissions setです。公式仕様では、setは既存の直接権限を置き換え、権限を指定しなければすべての直接権限を削除します。1グループだけを消すつもりで実行すると、無関係なユーザーやサービスプリンシパルの直接権限まで消すおそれがあります。
一方、databricks permissions updateは権限の更新に使用できます。実際の削除・変更処理は、利用しているCLIバージョンと対象オブジェクトの現行スキーマを確認したうえで作成してください。(Microsoft Learn)
大量変更では、次の順序を守ると事故を防ぎやすくなります。
- 現在のACLを取得する
- 変更前データを保存する
- 削除対象だけを含む変更一覧を作る
- 別の管理者が差分を確認する
- 少数のオブジェクトで試行する
- 本番変更を実施する
- ACLを再取得して差分を検証する
- Orphaned permissions notebookを再実行する
グループの間接割り当ても見落とさない
アカウントグループが、別の親グループを通じてワークスペースへ間接的に割り当てられている場合があります。
公式ドキュメントでは、別グループのメンバーシップを通じて間接的に割り当てられたグループは、ワークスペースの管理画面から直接削除できないとされています。その場合は、親グループのメンバー構成を変更するか、アカウントレベルで割り当てを見直す必要があります。(Microsoft Learn)
ただし、今回の監査目的はグループ構成を整理することだけではありません。グループを親グループから外しても、オブジェクト側のACLが残る可能性があります。
次の両方を確認してください。
- グループがどの経路でワークスペースへ割り当てられているか
- そのグループにどのワークスペースオブジェクトACLが残っているか
Orphaned permissions監査で起こりやすい失敗
| 失敗例 | 問題点 | 正しい対応 |
|---|---|---|
| グループをワークスペースから外して完了とする | オブジェクトACLが残る | 対象オブジェクト側から不要なACLを削除する |
| Notebookだけを確認する | ジョブ、フォルダー、クエリ、ダッシュボードを見落とす | Notebookの検出結果をオブジェクト種別ごとに確認する |
| 子Notebookの直接権限だけを削除する | 親フォルダーの継承権限が残る | 権限の発生元となる親フォルダーを修正する |
| 検出結果をすべて自動削除する | 意図的に残した権限まで失う | 所有者と業務上の必要性を確認する |
| メンバーがいないグループを放置する | 将来のメンバー追加で権限が有効になる | 未使用ならACLを削除する |
| Unity Catalogの権限も確認済みだと思い込む | データ権限の監査漏れが起きる | Unity Catalogは別途監査する |
CLIのpermissions setを安易に使う | 他の直接ACLまで置き換える可能性がある | 変更前バックアップと差分確認を行う |
| Notebookを一度だけ実行する | 修正漏れや新たな変更を確認できない | ACL修正後に再実行する |
監査結果として残すべき記録
監査結果は、単なるNotebookの実行画面ではなく、後から判断経緯を追跡できる形で保存します。
| 記録項目 | 記載内容 |
|---|---|
| ワークスペース | 対象ワークスペース名 |
| オブジェクト種別 | フォルダー、Notebook、ジョブ、クエリ、ダッシュボードなど |
| オブジェクト名・パス | 対象を特定できる名称またはパス |
| アカウントグループ | 権限が残っているグループ名 |
| 権限レベル | 管理、編集、実行、参照など |
| 権限の種類 | 直接付与または親からの継承 |
| 判定 | 削除、縮小、維持、要調査 |
| オブジェクト所有者 | 削除可否を判断した担当者 |
| 判断理由 | 業務上必要な理由または削除理由 |
| 見直し期限 | 維持する場合の次回確認日 |
| 変更記録 | チケット番号や変更実施日 |
| 再確認結果 | Notebook再実行後の状態 |
例外として残すACLには、少なくとも所有者、維持理由、見直し期限を設定します。「必要そうだから残す」という判断だけでは、数か月後に同じ孤立権限が発生します。
仕様変更前に完了させるチェックリスト
- [ ] 管理対象となる全ワークスペースを一覧化した
- [ ] 公式のOrphaned permissions analysis notebookを取得した
- [ ] Notebookの監査対象範囲を確認した
- [ ] 各ワークスペースの非アクティブな権限付与を検出した
- [ ] 管理・編集・実行に相当する強い権限を優先して確認した
- [ ] 親フォルダーからの継承権限を確認した
- [ ] 不要なグループACLをオブジェクト側から削除した
- [ ] 維持するACLに所有者、理由、期限を設定した
- [ ] CLIやAPIで変更する前にACLをバックアップした
- [ ] ACL修正後にNotebookを再実行した
- [ ] Unity Catalogのデータ権限を別途確認した
最初に行うべき作業は、公式の「What’s coming?」ページからOrphaned permissions analysis notebookを取得し、管理対象の全ワークスペースで非アクティブな権限付与を洗い出すことです。
その後、権限の強さ、オブジェクトの機密性、対象グループのメンバー数、親フォルダーからの継承範囲を基準に優先順位を付けます。不要なACLを削除したらNotebookを再実行し、未対応項目と承認済みの例外だけが残っていることを確認してください。
コメント