Azure Databricks Unity Catalogでは、2026年8月3日からMANAGE権限の成立条件が変わります。結論から言うと、過去に付与したMANAGEが同じカタログまたはスキーマのUSE権限不足によって現在は行使できなくても、変更後に自動的に有効になるケースがあります。
特に優先して確認すべきなのは、MANAGE ON CATALOGの既存付与と、親カタログのUSE CATALOGを持つユーザーやグループに対するMANAGE ON SCHEMAです。一方、テーブル単体のMANAGEは親カタログと親スキーマのUSEが引き続き必要なため、親USE不足の付与が8月3日に一律で有効化されるわけではありません。(Microsoft Learn)
この記事では、MANAGEの付与自体は残っているものの、現在はUSE不足で行使できない状態を「休眠MANAGE権限」と呼びます。8月3日前に棚卸しする方法、危険な組み合わせ、確認用SQL、不要な権限の削除手順まで具体的に解説します。
2026年8月3日に変わるMANAGE権限の要件
今回の変更では、MANAGEを付与したオブジェクト自体に対するUSE権限が不要になります。ただし、対象オブジェクトより上位にある親コンテナーのUSE権限は、原則として引き続き必要です。
| 管理対象 | 2026年8月2日まで | 2026年8月3日以降 | 休眠権限が有効化される可能性 |
|---|---|---|---|
| カタログ | 同じカタログのUSE CATALOG＋MANAGE | カタログのMANAGEのみ | 高い |
| スキーマ | 親カタログのUSE CATALOG＋同じスキーマのUSE SCHEMA＋MANAGE | 親カタログのUSE CATALOG＋スキーマのMANAGE | 高い |
| テーブル | 親カタログのUSE CATALOG＋親スキーマのUSE SCHEMA＋テーブルのMANAGE | 原則として同じ | 今回の変更による直接的な有効化は限定的 |
公式情報では、変更後にカタログを管理するにはカタログのMANAGEのみ、スキーマを管理するには親カタログのUSE CATALOGとスキーマのMANAGEが必要と整理されています。テーブルでは、引き続き親カタログのUSE CATALOGと親スキーマのUSE SCHEMAが必要です。(Microsoft Learn)
ただし、親コンテナーの所有者である場合や、親コンテナーに対するMANAGEを持っている場合は、親のUSEがなくても管理できるケースがあります。そのため、監査ではUSEの有無だけでなく、親オブジェクトの所有権とMANAGEの連鎖も確認する必要があります。(Microsoft Learn)
最も危険なのはカタログとスキーマのMANAGE
カタログに対するMANAGEは、現在USE CATALOGがないため使えない状態でも、8月3日以降はMANAGE単独で有効になります。
スキーマに対するMANAGEも、親カタログのUSE CATALOGさえあれば、同じスキーマのUSE SCHEMAがなくても有効になります。
つまり、これまで「USEを付けていないから安全」と判断していた権限設計は、そのままでは安全性を維持できません。
MANAGE権限が単なるデータ閲覧権限より危険な理由
権限変更や所有権移転、オブジェクト削除ができる
MANAGEは、単にテーブルの内容を閲覧する権限ではありません。オブジェクトの所有者でなくても、次の操作を可能にする強い管理権限です。
- 対象オブジェクトに対する権限の付与と取り消し
- オブジェクトの所有権移転
- 対象オブジェクトの削除
- 他のユーザー、グループ、サービスプリンシパルへの権限付与
MANAGEを持つ主体は、対象オブジェクトに対するすべての権限を自動的に得るわけではありません。しかし、必要な権限を自分自身に明示的に付与できます。(Microsoft Learn)
SELECTが自動付与されなくても安心できない
8月3日に休眠MANAGEが有効になっても、その瞬間にSELECTやMODIFYが自動付与されるわけではありません。
しかし、MANAGEが有効になった主体は、自分自身にUSE SCHEMA、SELECT、MODIFYなどを付与できる可能性があります。そのため、「データをまだ読めないから影響はない」という判断は適切ではありません。
今回のリスクは、データアクセス権が直接増えることよりも、アクセス権を自分で増やせる管理能力が復活することにあります。
親のMANAGEが子オブジェクトへ広がる
Unity Catalogでは、カタログやスキーマなどのコンテナーに付与した権限が、配下のオブジェクトへ継承されます。
カタログにMANAGEを付与すると、配下のスキーマやテーブルなどにもMANAGEが適用されます。スキーマのMANAGEも、その配下のテーブル、ビュー、ボリューム、関数などに影響します。(Microsoft Learn)
したがって、カタログレベルの休眠MANAGEが有効になると、影響範囲はカタログ本体だけにとどまりません。配下に本番データや機密スキーマが含まれている場合、最優先で確認する必要があります。
8月3日以降に有効化される具体的なパターン
| 現在の付与状態 | 8月3日以降の結果 | 判定 |
|---|---|---|
MANAGE ON CATALOG prodはあるが、USE CATALOGがない | カタログのMANAGEが有効になる | 要対応 |
USE CATALOG ON CATALOG prodとMANAGE ON SCHEMA prod.hrはあるが、USE SCHEMAがない | prod.hrのMANAGEが有効になる | 要対応 |
スキーマのMANAGEはあるが、親カタログのUSE CATALOG、所有権、MANAGEのいずれもない | 原則として引き続き行使できない | 継続監視 |
テーブルのMANAGEはあるが、親スキーマのUSE SCHEMAがない | 今回の変更だけでは原則として有効にならない | 棚卸し対象 |
テーブルのMANAGEと、両方の親USEがある | 現在も行使可能 | 既存の過剰権限を確認 |
カタログまたはスキーマのMANAGEがグループ経由で付与されている | 条件を満たせばグループメンバー全員に影響 | 要対応 |
親カタログからMANAGEが継承されている | 子スキーマやテーブルにも影響 | 最優先 |
特に見落としやすいのは、スキーマにUSE SCHEMAがないものの、別業務のために親カタログのUSE CATALOGだけはすでに付与されているケースです。8月3日以降、この組み合わせだけでスキーマのMANAGEが行使可能になります。
監査対象の優先順位
すべてのMANAGEを確認するのが理想ですが、対象が多い場合は次の順で進めます。
| 優先度 | 監査対象 | 理由 |
|---|---|---|
| 最優先 | 本番カタログに対するMANAGE | 8月3日以降は同じカタログのUSE CATALOGが不要になる |
| 最優先 | カタログから継承されたMANAGE | 配下のスキーマやテーブルへ広範囲に影響する |
| 高 | スキーマのMANAGEと親USE CATALOGを持つ主体 | USE SCHEMAがなくても有効になる |
| 高 | 退職者、異動者、旧委託先を含むグループ | 過去の権限が残っている可能性がある |
| 高 | サービスプリンシパルに付与したMANAGE | 人による確認なしで権限変更処理が実行される可能性がある |
| 中 | テーブル単体のMANAGE | 要件自体は大きく変わらないが、親権限との組み合わせを確認すべき |
| 中 | 開発・検証カタログのMANAGE | 本番より優先度は低いが、本番データを参照する構成では注意が必要 |
個人ユーザーへの直接付与だけでなく、アカウントグループ、同期グループ、サービスプリンシパル、親オブジェクトからの継承を含めて確認します。
8月3日前に行うMANAGE権限の監査手順
INFORMATION_SCHEMAで候補を抽出する
カタログ、スキーマ、テーブルまたはビューに付与されているMANAGEをまとめて抽出する例です。
SELECT
'CATALOG' AS object_type,
catalog_name AS object_name,
grantee,
grantor,
inherited_from
FROM system.information_schema.catalog_privileges
WHERE privilege_type = 'MANAGE'
UNION ALL
SELECT
'SCHEMA' AS object_type,
concat(catalog_name, '.', schema_name) AS object_name,
grantee,
grantor,
inherited_from
FROM system.information_schema.schema_privileges
WHERE privilege_type = 'MANAGE'
UNION ALL
SELECT
'TABLE_OR_VIEW' AS object_type,
concat(table_catalog, '.', table_schema, '.', table_name) AS object_name,
grantee,
grantor,
inherited_from
FROM system.information_schema.table_privileges
WHERE privilege_type = 'MANAGE'
ORDER BY object_type, object_name, grantee;system.information_schemaを使用すると、実行者から確認可能なカタログを横断して候補を抽出できます。INHERITED_FROMに親オブジェクトの情報がある場合は、直接付与ではなく、カタログやスキーマから継承された権限を重点的に確認します。(Microsoft Learn)
ただし、このSQLの結果だけで監査完了と判断してはいけません。公式ドキュメントでは、現在のINFORMATION_SCHEMAには、MANAGE保有者が対象オブジェクトの全付与を確認できない場合があるという制限が案内されています。最終確認には、適切な権限を持つ管理者によるSHOW GRANTSまたはCatalog Explorerを使用します。(Microsoft Learn)
SHOW GRANTSでオブジェクトごとに確認する
候補が見つかったら、対象オブジェクトに対するすべての付与を確認します。
SHOW GRANTS ON CATALOG prod;SHOW GRANTS ON SCHEMA prod.finance;SHOW GRANTS ON TABLE prod.finance.customer_master;特定の主体に絞って確認する場合は、次の形式を使います。
SHOW GRANTS `legacy-data-admins` ON SCHEMA prod.finance;オブジェクト所有者、親コンテナーの所有者、メタストア管理者、または対象オブジェクトに対するMANAGEを持つ主体は、SHOW GRANTSやCatalog Explorerから付与内容を確認できます。(Microsoft Learn)
監査結果を判定表に整理する
単にMANAGEの有無を記録するだけでは不十分です。少なくとも次の項目を整理します。
| 確認項目 | 記録内容 |
|---|---|
| オブジェクト | カタログ、スキーマ、テーブルの完全修飾名 |
| 付与先 | ユーザー、グループ、サービスプリンシパル |
| 付与方法 | 直接付与、親からの継承 |
現在のUSE | USE CATALOG、USE SCHEMAの有無 |
| 親の管理権限 | 親オブジェクトの所有権またはMANAGE |
| 現在の行使可否 | 2026年8月2日までの条件で判定 |
| 変更後の行使可否 | 2026年8月3日以降の条件で判定 |
| 業務上の必要性 | 権限管理、所有権移転、削除が本当に必要か |
| 対応 | 維持、縮小、削除、別グループへ移行 |
| 承認者 | データ所有者またはシステム責任者 |
「以前の担当者だから」「運用開始時に必要だったから」という理由だけで維持せず、現在の職務と照合して判断します。
不要なMANAGE権限を削除する方法
不要な付与が見つかった場合は、2026年8月3日より前にREVOKEします。
REVOKE MANAGE ON CATALOG prod
FROM `legacy-data-admins`;REVOKE MANAGE ON SCHEMA prod.finance
FROM `external-contractors`;REVOKE MANAGE ON TABLE prod.finance.customer_master
FROM `old-service-principal`;REVOKEは、指定した権限が実際には付与されていなかった場合でも成功し、最終的にその権限が存在しない状態を保証します。(Microsoft Learn)
継承されたMANAGEは付与元を確認する
テーブルに表示されたMANAGEが親スキーマや親カタログから継承されている場合、テーブルだけを見て対応しても根本的な解消にはなりません。
例えば、カタログに次の付与がある場合です。
GRANT MANAGE ON CATALOG prod
TO `data-platform-team`;このMANAGEは配下のスキーマやテーブルにも影響します。不要であれば、付与元のカタログ側で取り消します。
REVOKE MANAGE ON CATALOG prod
FROM `data-platform-team`;カタログ全体の管理は不要だが、特定のスキーマだけを管理させたい場合は、カタログのMANAGEを削除したうえで対象範囲を狭めます。
GRANT USE CATALOG ON CATALOG prod
TO `data-platform-team`;
GRANT MANAGE ON SCHEMA prod.team_workspace
TO `data-platform-team`;ただし、スキーマのMANAGEも強い権限です。権限付与や所有権移転、削除が必要な管理者グループに限定してください。
USEを外すだけの対策は避ける
今回の変更後は、カタログのUSE CATALOGやスキーマのUSE SCHEMAを外しても、同じオブジェクトのMANAGEを無効化する対策にはなりません。
したがって、次のような対応は不十分です。
REVOKE USE SCHEMA ON SCHEMA prod.finance
FROM `legacy-data-admins`;MANAGE ON SCHEMA prod.financeが残っており、親カタログの条件を満たしていれば、8月3日以降は管理権限を行使できます。
不要な管理能力を止めるには、USEではなくMANAGE自体を取り消す必要があります。
必要な操作だけを個別付与する
利用目的がデータ参照だけであれば、MANAGEではなく必要な権限だけを付与します。
GRANT USE CATALOG ON CATALOG prod
TO `sales-analysts`;
GRANT USE SCHEMA ON SCHEMA prod.sales
TO `sales-analysts`;
GRANT SELECT ON TABLE prod.sales.orders
TO `sales-analysts`;スキーマ配下のテーブルを広く参照させる必要がある場合は、業務範囲を確認したうえでスキーマレベルのSELECTを検討します。
GRANT SELECT ON SCHEMA prod.sales
TO `sales-analysts`;なお、Unity CatalogのALL PRIVILEGESにはMANAGEが含まれません。管理権限は、通常のデータ操作権限とは分けて明示的に管理する必要があります。(Microsoft Learn)
変更後の組み合わせを非本番環境でテストする
今回の変更はMANAGEの行使条件に関するものです。単にテーブルへSELECTできるかを確認するだけでは、MANAGEが有効になったかどうかは判定できません。
専用のテストカタログ、テストスキーマ、テストグループを用意し、変更適用後に次の組み合わせを検証します。
| テストケース | 権限構成 | 8月3日以降の想定結果 |
|---|---|---|
| カタログ管理 | カタログのMANAGEのみ | 管理可能 |
| スキーマ管理 | 親のUSE CATALOG＋スキーマのMANAGE、USE SCHEMAなし | 管理可能 |
| スキーマ否定テスト | スキーマのMANAGEのみで、親のUSE、所有権、MANAGEなし | 管理不可 |
| テーブル管理 | 両方の親USE＋テーブルのMANAGE | 管理可能 |
| テーブル否定テスト | テーブルのMANAGEはあるが、いずれかの親USEがなく、親の所有権やMANAGEもない | 管理不可 |
検証では、本番オブジェクトの削除や所有権移転を試してはいけません。専用テストテーブルに対して、一時的な権限の付与と取り消しを行います。
GRANT SELECT ON TABLE uc_manage_test.audit_schema.test_table
TO `uc-manage-test-target`;
REVOKE SELECT ON TABLE uc_manage_test.audit_schema.test_table
FROM `uc-manage-test-target`;この操作を実行できれば、テスト実行者のMANAGEが行使可能な状態です。検証終了後は、テスト用の付与とグループメンバーシップを必ず削除します。
監査で起こりやすい見落とし
個人ユーザーだけを確認する
実際の権限は、グループやサービスプリンシパルを通じて付与されていることがあります。個人への直接付与がなくても、所属グループ経由でMANAGEを保有している可能性があります。
テーブルだけを確認する
カタログやスキーマのMANAGEは子オブジェクトへ影響します。テーブルの権限画面だけを確認しても、付与元となる親カタログや親スキーマを見落とす可能性があります。
INFORMATION_SCHEMAの結果を完全な一覧だと考える
INFORMATION_SCHEMAの結果は実行者の可視範囲に左右されます。候補抽出には便利ですが、最終確認は十分な権限を持つ管理者がSHOW GRANTSまたはCatalog Explorerで行います。(Microsoft Learn)
USEがないため安全だと判断する
この判断こそ、今回見直す必要があるポイントです。8月3日以降、同じカタログやスキーマのUSE不足は、MANAGEを無効にする条件ではなくなります。
データを読めないため問題ないと判断する
MANAGEはSELECTを自動付与しませんが、自分自身や他の主体に権限を付与できます。現在データを読めないことと、管理権限が安全であることは別問題です。
2026年8月3日までの対応チェックリスト
8月2日までに実施すること
- カタログ、スキーマ、テーブルの既存
MANAGEを抽出する - 個人、グループ、サービスプリンシパルをすべて確認する
- 直接付与と親オブジェクトからの継承を区別する
- 親の
USE、所有権、MANAGEを含めて変更後の行使可否を判定する - 不要な
MANAGEをREVOKEする - 必要な権限は
SELECTやMODIFYなどに置き換える - 変更前後の
SHOW GRANTS結果を保存する - 非本番環境で実施する検証手順を用意する
8月3日以降に確認すること
- 監査対象の
SHOW GRANTSを再取得する - カタログとスキーマの新しい権限組み合わせを非本番で検証する
- 削除した
MANAGEが別の親オブジェクトから継承されていないか確認する - 意図しない権限付与、所有権移転、オブジェクト削除が発生していないか確認する
- 今後の
MANAGE付与を個人ではなく管理用グループに限定する - 権限付与の目的、承認者、見直し期限を記録する
公式に案内されている対応の中心は、既存のMANAGE付与を監査し、意図したアクセスになっているか確認することです。広く付与したまま同じオブジェクトのUSE不足に依存している場合、そのMANAGEは変更後に有効になります。(Microsoft Learn)
最初に実施すべきなのは、本番カタログと本番スキーマのMANAGE一覧を取得することです。その後、親のUSE、所有権、MANAGEを含めて変更後の状態を判定し、不要な付与を2026年8月3日前に削除してください。
コメント