Databricks Certified Data Engineer Associate 教科書
第7章 ガバナンスとセキュリティ(Governance and Security, 15%)
🎯 この節の学習目標
Unity Catalog のアクセス制御は「プリンシパル(principal)に権限(privilege)をセキュラブルオブジェクト(securable object)に対して与える」という3要素で構成されます。まず「誰に」にあたるプリンシパルは3種類です。
| プリンシパル | 正体 | 典型的な用途 |
|---|---|---|
| ユーザー | 個人のアカウント(メールアドレスで識別) | 個人での分析・開発作業 |
| グループ | ユーザーやサービスプリンシパルの集合(例:data_engineers) | 権限付与の推奨単位。部署・ロール単位の管理 |
| サービスプリンシパル | 自動化のための「人でない」ID | ジョブ・パイプライン・CI/CD などの自動処理の実行主体 |
ベストプラクティスは、個々のユーザーではなくグループに権限を付与することです。人の入退社や異動のたびに GRANT 文を打ち直すのではなく、グループのメンバーシップを変えるだけで済みます。また、定期ジョブなどの自動化処理は個人アカウントではなくサービスプリンシパルで実行するのが原則です。個人アカウントで動かすと、その人の退職・権限変更でパイプラインが突然止まるリスクがあります。
UC のセキュラブルオブジェクトは階層構造になっており、上位オブジェクトに与えた権限は下位オブジェクトに継承されます。たとえばカタログに SELECT を GRANT すると、その配下のすべてのスキーマの、さらに配下のすべてのテーブルに対する SELECT が許可されます。
図:Unity Catalog の権限階層。上位への GRANT は配下の全オブジェクトへ継承される
ここで最重要の論点が「テーブルを読むには3点セットが必要」というルールです。あるテーブルに SELECT する権限が有効になるためには、対象テーブルの SELECT だけでなく、その通り道にあたる上位オブジェクトの USE 権限もそろっていなければなりません。
USE CATALOGUSE SCHEMASELECT主な権限の意味も整理しておきます。
| 権限 | 対象 | できること |
|---|---|---|
USE CATALOG / USE SCHEMA | カタログ / スキーマ | そのコンテナの中を「通行」できる。中のオブジェクトへのアクセスの前提条件 |
SELECT | テーブル・ビュー | データの読み取り |
MODIFY | テーブル | INSERT / UPDATE / DELETE / MERGE などデータの変更 |
CREATE TABLE | スキーマ | そのスキーマ内でのテーブル作成 |
READ VOLUME / WRITE VOLUME | Volume | Volume 内のファイルの読み取り / 書き込み |
EXECUTE | 関数 | 関数の実行 |
ALL PRIVILEGES | 各オブジェクト | そのオブジェクトに適用可能なすべての権限の一括付与 |
なお、オブジェクトの所有者(owner)(作成者、または移譲された者)は、そのオブジェクトに対するすべての権限を暗黙に持ち、他プリンシパルへの GRANT も行えます。
💡 具体例:分析チームに販売データの読み取りを許可する
-- 3点セットをグループに付与する
GRANT USE CATALOG ON CATALOG main TO `analysts`;
GRANT USE SCHEMA ON SCHEMA main.sales TO `analysts`;
GRANT SELECT ON TABLE main.sales.orders TO `analysts`;
-- スキーマ配下の全テーブルを読ませたいなら、スキーマに SELECT(継承を利用)
GRANT SELECT ON SCHEMA main.sales TO `analysts`;
-- データエンジニアには書き込みとテーブル作成も
GRANT MODIFY ON TABLE main.sales.orders TO `data_engineers`;
GRANT CREATE TABLE ON SCHEMA main.sales TO `data_engineers`;
-- 自動化ジョブの実行主体(サービスプリンシパル)への付与
GRANT SELECT, MODIFY ON SCHEMA main.sales TO `etl-pipeline-sp`;
-- 取り消し
REVOKE SELECT ON TABLE main.sales.orders FROM `analysts`;
-- 現在の権限の確認
SHOW GRANTS ON TABLE main.sales.orders;
プリンシパル名はバッククォートで囲みます。UI から操作する場合は、Catalog Explorer で対象オブジェクトを開き、Permissions タブ → Grant からプリンシパルと権限を選択します(内部的には同じ GRANT が発行されます)。
DENY については、試験ガイドの記載と実際の Unity Catalog の仕様にずれがあるため、分けて理解しておく必要があります。
公式試験ガイド(2026年5月版)には、アクセス制御のコマンドとして GRANT / REVOKE / DENY と記載されています。DENY は「明示的な拒否」を登録するコマンドで、レガシーの hive_metastore(テーブルACL)では GRANT に優先します。
Unity Catalog では DENY はサポートされていません(使えるのはレガシーの hive_metastore のみ)。UC のアクセス制御は GRANT / REVOKE と権限設計で行います。すなわち「見せたくないプリンシパルには最初から GRANT しない(必要なら REVOKE する)」という最小権限の原則とグループ単位の設計でアクセスを制御します。
-- レガシーの hive_metastore(テーブルACL)での DENY の例
-- ※ Unity Catalog ではこの DENY 文はサポートされない
GRANT SELECT ON SCHEMA hive_metastore.hr TO `analysts`;
DENY SELECT ON TABLE hive_metastore.hr.salaries TO `analysts`;
📝 試験のポイント
「DENY が GRANT に優先する」という原則は、レガシーの hive_metastore(テーブルACL)での話です。Unity Catalog に DENY はありません。UC で「このグループには見せたくない」を実現するには、そのプリンシパル(が属するグループ)に SELECT を GRANT しない/REVOKE するのが正解です。継承で広く許可を与えるとテーブル単位の除外ができないため、UC では許可を与える範囲そのものを最小限に設計する(スキーマを分ける・グループを分ける)ことが重要になります。REVOKE は「与えた許可を取り消して無指定に戻す」操作で、無指定なら UC の既定は拒否です。
試験でも実務でもよく出るのが「ユーザーがテーブルにアクセスできない。原因はどれか」という診断型の問題です。チェックの手順は権限階層をそのまま上からたどります。
💡 具体例:SELECT を GRANT したのに読めない
「main.sales.orders に SELECT を GRANT したのに、ユーザーから PERMISSION DENIED になる」という問い合わせが来たとします。SHOW GRANTS で確認すると、テーブルの SELECT は付与済みでしたが、カタログ main への USE CATALOG が付与されていませんでした。3点セットのうち上位の「通行権」が欠けていたのが原因で、GRANT USE CATALOG ON CATALOG main TO `analysts`; で解決します。テーブル単体の権限だけ見ていると見落とす、典型的なパターンです。
✅ この節のまとめ
USE CATALOG + USE SCHEMA + SELECT の3点セットが必要。SHOW GRANTS。ALL PRIVILEGES の安易な付与は避ける。問1. あるユーザーは main.sales.orders テーブルへの SELECT と、スキーマ main.sales への USE SCHEMA を GRANT されているが、クエリを実行すると権限エラーになる。最も可能性の高い原因はどれか。
main への USE CATALOG 権限が付与されていない正解:B
テーブルの読み取りには USE CATALOG・USE SCHEMA・SELECT の3点セットが必要で、この状況で欠けている可能性が高いのは最上位の USE CATALOG です。Aの MODIFY は書き込み用の権限であり、読み取りには不要です。Cは誤りで、SELECT はテーブルにもビューにも適用されます。Dのような排他関係は存在しません。
問2. Unity Catalog 上のテーブル main.hr.salaries について、グループ interns には読み取りをさせたくない。最も適切な対応はどれか。
DENY SELECT ON TABLE main.hr.salaries TO `interns`; を実行するinterns に SELECT を GRANT しない(付与済みなら REVOKE する)。権限が無指定なら UC の既定は拒否である正解:B
Unity Catalog では DENY はサポートされていないため(使えるのはレガシーの hive_metastore のみ)、Aは実行できず誤りです。UC の既定は拒否であり、SELECT を GRANT しない/REVOKE すればアクセスできません。あわせて、許可はグループ単位・最小権限で設計するのが原則です。Cは最小権限の原則に反するうえ対応として本末転倒、Dはデータそのものを失うため論外です。なお試験ガイドには GRANT/REVOKE/DENY と記載がありますが、DENY が効くのは hive_metastore(テーブルACL)だけという点を押さえてください。
問3. 毎晩実行される ETL ジョブに、書き込み先スキーマへの権限を設定したい。ベストプラクティスに沿った構成はどれか。
正解:C
自動化処理はサービスプリンシパルで実行し、最小権限を付与するのが原則です。Aは担当者の退職や権限変更でジョブが停止するリスクがあります。Bは最小権限の原則に真っ向から反し、監査上も問題です。Dは運用として現実的でなく、自動化の意味がなくなります。
問4. カタログ main に対してグループ analysts へ SELECT を GRANT した。この操作の効果として正しいものはどれか(USE 権限は別途付与済みとする)。
正解:B
上位オブジェクトへの GRANT は配下の全オブジェクトへ継承されます。継承は「その時点のオブジェクト一覧への一括付与」ではなく階層としての効果なので、後から作成されるテーブルにも自動的に及びます(Cは誤り)。Aは継承がテーブルまで届かないとしている点が誤りです。Dも誤りで、カタログに SELECT を GRANT する構文は有効で、継承のためによく使われます。