第7章 ガバナンスとセキュリティ / 想定学習時間:30〜40分 / 最終確認:2026年8月

7-2. アクセス制御(GRANT/REVOKE/DENY・プリンシパル・権限階層)

🎯 この節の学習目標

1. プリンシパル:権限を「誰に」与えるか

Unity Catalog のアクセス制御は「プリンシパル(principal)権限(privilege)セキュラブルオブジェクト(securable object)に対して与える」という3要素で構成されます。まず「誰に」にあたるプリンシパルは3種類です。

プリンシパル正体典型的な用途
ユーザー個人のアカウント(メールアドレスで識別)個人での分析・開発作業
グループユーザーやサービスプリンシパルの集合(例:data_engineers)権限付与の推奨単位。部署・ロール単位の管理
サービスプリンシパル自動化のための「人でない」IDジョブ・パイプライン・CI/CD などの自動処理の実行主体

ベストプラクティスは、個々のユーザーではなくグループに権限を付与することです。人の入退社や異動のたびに GRANT 文を打ち直すのではなく、グループのメンバーシップを変えるだけで済みます。また、定期ジョブなどの自動化処理は個人アカウントではなくサービスプリンシパルで実行するのが原則です。個人アカウントで動かすと、その人の退職・権限変更でパイプラインが突然止まるリスクがあります。

2. 権限階層と継承:上位で与えれば下位に効く

UC のセキュラブルオブジェクトは階層構造になっており、上位オブジェクトに与えた権限は下位オブジェクトに継承されます。たとえばカタログに SELECT を GRANT すると、その配下のすべてのスキーマの、さらに配下のすべてのテーブルに対する SELECT が許可されます。

メタストアワークスペースに割り当てられる最上位。管理者ロールの領域
継承
カタログUSE CATALOG / CREATE SCHEMA / ALL PRIVILEGES など
継承
スキーマUSE SCHEMA / CREATE TABLE / CREATE FUNCTION など
継承
テーブル / ビュー / Volume / 関数SELECT / MODIFY / READ VOLUME / EXECUTE など

図:Unity Catalog の権限階層。上位への GRANT は配下の全オブジェクトへ継承される

ここで最重要の論点が「テーブルを読むには3点セットが必要」というルールです。あるテーブルに SELECT する権限が有効になるためには、対象テーブルの SELECT だけでなく、その通り道にあたる上位オブジェクトの USE 権限もそろっていなければなりません。

主な権限の意味も整理しておきます。

権限対象できること
USE CATALOG / USE SCHEMAカタログ / スキーマそのコンテナの中を「通行」できる。中のオブジェクトへのアクセスの前提条件
SELECTテーブル・ビューデータの読み取り
MODIFYテーブルINSERT / UPDATE / DELETE / MERGE などデータの変更
CREATE TABLEスキーマそのスキーマ内でのテーブル作成
READ VOLUME / WRITE VOLUMEVolumeVolume 内のファイルの読み取り / 書き込み
EXECUTE関数関数の実行
ALL PRIVILEGES各オブジェクトそのオブジェクトに適用可能なすべての権限の一括付与

なお、オブジェクトの所有者(owner)(作成者、または移譲された者)は、そのオブジェクトに対するすべての権限を暗黙に持ち、他プリンシパルへの GRANT も行えます。

3. GRANT / REVOKE のSQLと DENY の扱い

💡 具体例:分析チームに販売データの読み取りを許可する

-- 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仕様(2026年8月)

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 の既定は拒否です。

4. 診断:「テーブルが読めない」はどの階層が欠けているか

試験でも実務でもよく出るのが「ユーザーがテーブルにアクセスできない。原因はどれか」という診断型の問題です。チェックの手順は権限階層をそのまま上からたどります。

  1. USE CATALOG はあるか(なければカタログ自体が見えない・入れない)
  2. USE SCHEMA はあるか(なければスキーマの中に入れない)
  3. テーブルへの SELECT(継承分含む)はあるか
  4. (レガシーの hive_metastore 配下の場合のみ)どこかに DENY が登録されていないか(あれば他の GRANT に関係なく拒否)

💡 具体例:SELECT を GRANT したのに読めない

main.sales.ordersSELECT を GRANT したのに、ユーザーから PERMISSION DENIED になる」という問い合わせが来たとします。SHOW GRANTS で確認すると、テーブルの SELECT は付与済みでしたが、カタログ main への USE CATALOG が付与されていませんでした。3点セットのうち上位の「通行権」が欠けていたのが原因で、GRANT USE CATALOG ON CATALOG main TO `analysts`; で解決します。テーブル単体の権限だけ見ていると見落とす、典型的なパターンです。

✅ この節のまとめ

練習問題

問1. あるユーザーは main.sales.orders テーブルへの SELECT と、スキーマ main.sales への USE SCHEMA を GRANT されているが、クエリを実行すると権限エラーになる。最も可能性の高い原因はどれか。

  1. テーブルへの MODIFY 権限が不足している
  2. カタログ main への USE CATALOG 権限が付与されていない
  3. SELECT はビューにしか適用できないため、テーブルには無効である
  4. USE SCHEMA と SELECT は同時に保持できない
解答と解説を見る

正解:B

テーブルの読み取りには USE CATALOG・USE SCHEMA・SELECT の3点セットが必要で、この状況で欠けている可能性が高いのは最上位の USE CATALOG です。Aの MODIFY は書き込み用の権限であり、読み取りには不要です。Cは誤りで、SELECT はテーブルにもビューにも適用されます。Dのような排他関係は存在しません。

問2. Unity Catalog 上のテーブル main.hr.salaries について、グループ interns には読み取りをさせたくない。最も適切な対応はどれか。

  1. DENY SELECT ON TABLE main.hr.salaries TO `interns`; を実行する
  2. interns に SELECT を GRANT しない(付与済みなら REVOKE する)。権限が無指定なら UC の既定は拒否である
  3. 全ユーザーに ALL PRIVILEGES を付与したうえで、interns のアカウントを削除する
  4. テーブルを DROP して interns が見られないようにする
解答と解説を見る

正解:B

Unity Catalog では DENY はサポートされていないため(使えるのはレガシーの hive_metastore のみ)、Aは実行できず誤りです。UC の既定は拒否であり、SELECT を GRANT しない/REVOKE すればアクセスできません。あわせて、許可はグループ単位・最小権限で設計するのが原則です。Cは最小権限の原則に反するうえ対応として本末転倒、Dはデータそのものを失うため論外です。なお試験ガイドには GRANT/REVOKE/DENY と記載がありますが、DENY が効くのは hive_metastore(テーブルACL)だけという点を押さえてください。

問3. 毎晩実行される ETL ジョブに、書き込み先スキーマへの権限を設定したい。ベストプラクティスに沿った構成はどれか。

  1. ジョブを作成したエンジニア個人のユーザーアカウントに MODIFY を付与し、そのアカウントでジョブを実行する
  2. ワークスペースの全ユーザーに ALL PRIVILEGES を付与して権限エラーを防ぐ
  3. サービスプリンシパルを作成してジョブの実行主体とし、必要最小限の権限(SELECT・MODIFY 等)を付与する
  4. 毎回ジョブ実行前に管理者が手動で一時的な GRANT を発行する
解答と解説を見る

正解:C

自動化処理はサービスプリンシパルで実行し、最小権限を付与するのが原則です。Aは担当者の退職や権限変更でジョブが停止するリスクがあります。Bは最小権限の原則に真っ向から反し、監査上も問題です。Dは運用として現実的でなく、自動化の意味がなくなります。

問4. カタログ main に対してグループ analysts へ SELECT を GRANT した。この操作の効果として正しいものはどれか(USE 権限は別途付与済みとする)。

  1. カタログ直下のスキーマには効果があるが、テーブルには効果がない
  2. 権限の継承により、カタログ配下のすべてのスキーマのすべてのテーブルとビューを SELECT できる
  3. GRANT 実行時点で存在していたテーブルのみが対象で、以後作成されるテーブルには適用されない
  4. カタログへの SELECT という権限は存在しないため、文はエラーになる
解答と解説を見る

正解:B

上位オブジェクトへの GRANT は配下の全オブジェクトへ継承されます。継承は「その時点のオブジェクト一覧への一括付与」ではなく階層としての効果なので、後から作成されるテーブルにも自動的に及びます(Cは誤り)。Aは継承がテーブルまで届かないとしている点が誤りです。Dも誤りで、カタログに SELECT を GRANT する構文は有効で、継承のためによく使われます。