More than 1 year has passed since last update.

Unity Catalogにおけるデータのアクセス権

Last updated at 2022-03-24Posted at 2022-03-15

Data permissions | Databricks on AWS [2022/3/10時点]の翻訳です。

本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。

本書では、Unity Catalogにおけるデータとオブジェクトに対するアクセスを制御するために、どのようにデータのアクセス権が動作するのかを説明します。

Unity Catalogのデータとオブジェクトに対するアクセスを許可・剥奪するために、Databricks SQLのData Explorer、あるいはノートブック上のSQL文、Databricks SQLのクエリー、Unity CatalogのREST APIを用いてデータアクセスコントロールポリシーを適用します。

最初は、ユーザーはメタストアのデータにアクセスできません。メタストア管理者のみがスキーマ、テーブル、ビュー、その他のUnity Catalogオブジェクトを作成することができ、それらに対するアカウントレベルのユーザー、グループのアクセスを許可、拒否することができます。アクセスコントロールのポリシーは継承されません。メタストアを作成したアカウントレベルの管理者がオーナーとなり、メタストア管理者となります。

お使いのクラウドテナントに対してデータを読み書きできるようになる前に、Unity Catalogによってアクセスコントロールポリシーが適用されます。

オーナーシップ

Unity Cataloにおけるそれぞれのセキュリティ保護可能オブジェクトには、オーナーが存在します。プリンシパルと呼ばれる任意のアカウントレベルのユーザー、グループがオーナーになることができます。オブジェクトを作成したプリンシパルが最初のオーナーになります。オブジェクトのオーナーは、テーブルに対するSELECT、MODIFY、他のプリンシパルに対するアクセス権を許可する権限など、オブジェクトに対する全ての権限を持ちます。

オブジェクトオーナーは、別のユーザー、グループにオーナーシップを移譲することができます。メタストア管理者は、メタストアのいかなるオブジェクトのオーナーシップを別のユーザー、グループに移譲することができます。

セキュリティ保護可能オブジェクトのオーナーを参照するには、以下の文法を使用します。プレースホルダーの値を置き換えてください。

<SECURABLE_TYPE>: CATALOGやTABLEのようなセキュリティ保護可能オブジェクトのタイプ
<catalog>: テーブルやビューに対する親のカタログ
<schema>: テーブルやビューに対する親のスキーマ
<securable_name>: テーブルやビューなどのセキュリティ保護可能オブジェクトの名前

SQL

DESCRIBE <SECURABLE_TYPE> EXTENDED <catalog>.<schema>.<securable_name>;

オブジェクトのオーナーシップを移譲するには、以下の文法のSQLコマンドを使用します。プレースホルダーの値を置き換えてください。

<SECURABLE_TYPE>: CATALOGやTABLEのようなセキュリティ保護可能オブジェクトのタイプ
<SECURABLE_NAME>: テーブルやビューなどのセキュリティ保護可能オブジェクトの名前
<PRINCIPAL>: アカウントレベルのユーザーのメールアドレス、あるいはアカウントレーベルのグループの名前

SQL

ALTER <SECURABLE_TYPE> <SECURABLE_NAME> OWNER TO <PRINCIPAL>;

例えば、accountingグループにテーブルのオーナーシップを移譲するには以下を実行します。

SQL

ALTER TABLE orders OWNER TO `accounting`;

メタストアのオーナーシップ

メタストアを作成したアカウントレベルの管理者がオーナーとなります。メタストアのオーナーシップを、異なるアカウントレベルのユーザー、グループに移譲するには、(推奨)メタストアのオーナーシップをグループに転送するを参照ください。セキュリティ強化のため、このコマンドはSQL文法では使用できません。

権限

Unity Catalogでは、セキュリティ保護可能オブジェクトに対して以下の権限を許可することができます。

USAGE: このアクセス権はセキュリティ保護可能なオブジェクト自身へのアクセスを許可しませんが、子供のオブジェクトにアクセスするためにセキュリティ保護可能オブジェクトを通過することを許可します。例えば、テーブルからデータを取得するためには、ユーザーは当該テーブルに対するUSAGE権限と、親のスキーマ、親のカタログに対するUSAGE権限を必要とします。特定のグループに対してデータの名前空間のセクションへのアクセスを制限するために、この権限を使用することができます。
SELECT: テーブル、ビューからデータを読み込むことを許可します。ユーザーは親のカタログ、スキーマに対するUSAGE権限が必要です。
MODIFY: テーブルへの行追加、更新、データの削除を許可します。ユーザーは親のカタログ、スキーマに対するUSAGE権限が必要です。
CREATE: ユーザーが親のカタログに対してUSAGEとCREATE権限を有しているのであれば、スキーマの作成を許可します。ユーザーが親のカタログとスキーマに対してUSAGE権限、親のスキーマに対してCREATE権限を有しているのであれば、テーブル、ビューの作成を許可します。

さらに、ストレージ認証情報と外部ロケーションに対して以下のアクセス権を許可することができます。

CREATE TABLE: ストレージ認証情報を用いて指定された外部ロケーションに外部テーブルを作成することを許可します。
READ FILES: 外部ロケーションに関連づけられたストレージ認証情報を用いて、指定された外部ロケーションからデータファイルを読み込むことを許可します。

ストレージ認証情報に対して直接許可をすると、ストレージ認証情報を用いてお使いのクラウドテナントから直接ファイルを読み込むことを許可します。
WRITE FILES: 外部ロケーションに関連づけられたストレージ認証情報を用いて、指定された外部ロケーションにデータファイルを書き込むことを許可します。

ストレージ認証情報に対して直接許可をすると、ストレージ認証情報を用いてお使いのクラウドテナントから直接ファイルを書き込むことを許可します。

注意
ストレージ認証情報に対してREAD FILESとWRITE FILES権限を許可することができますが、そうするのではなく、外部ロケーションに対してこれらのアクセス権を許可することをお勧めします。これによって、よりきめ細かいレベルでのアクセス権管理を可能とし、エンドユーザーに対してよりシンプルな体験を提供します。

Unity Catalogでは、権限は子供のセキュリティ保護可能なオブジェクトには継承されません。例えば、ユーザーに対してカタログのCREATE権限を許可しても、ユーザーは自動ではカタログの全データベースに対するCREATE権限を持ちません。

以下の表では、それぞれのセキュリティ保護可能オブジェクトに許可される権限をまとめています。

セキュリティ保護可能オブジェクト	権限
カタログ	`CREATE`, `USAGE`
スキーマ	`CREATE`, `USAGE`
テーブル	`SELECT`, `MODIFY`
ビュー	`SELECT`
外部ロケーション	`USAGE`, `CREATE TABLE`, `READ FILES`, `WRITE FILES`
ストレージ認証情報	`USAGE`, `CREATE TABLE`, `READ FILES`, `WRITE FILES`

権限の管理

Databricks SQLのData Explorerか、Databricks SQLのSQLエディタ、Data Science & Engineeringノートブックでメタストアの権限を管理することができます。

権限を管理するには、GRANTとREVOKE文を使用します。オブジェクトのオーナーあるいはメタストア管理者のみが、オブジェクトとその子供のオブジェクトに対する権限を許可することができます。ビルトインのaccount usersというアカウントレベルのグループには全てのアカウントレベルのユーザーが含まれています。

このセクションには、権限を管理するためのSQLコマンドの使用例が含まれています。Databricks SQLのData Exprolerを用いた権限管理については、Manage access to dataを参照ください。

セキュリティ保護可能オブジェクトの権限の表示

SQLを用いてオブジェクトに許可されている権限を表示するには、以下のようなコマンドを使用します。Databricks SQLのData Explorerの使い方については、Use the Databricks SQL Data Explorerをご覧ください。

以下の文法を使用します。プレースホルダーの値を置き換えてください。

<securable_type>: カタログやテーブルのようなセキュリティ保護可能オブジェクトのタイプ
<securable_name>: セキュリティ保護可能オブジェクトの名前

SQL

SHOW GRANTS ON <securable_type> <securable_name>;

オブジェクトに対する特定のプリンシパルに許可された全ての権限を表示するには、以下の文法を使用します。プレースホルダーの値を置き換えてください。

<principal>: アカウントレベルユーザーのメールアドレスか、アカウントレベルグループの名前
<securable_type>: カタログやテーブルのようなセキュリティ保護可能オブジェクトのタイプ
<securable_name>: セキュリティ保護可能オブジェクトの名前

SQL

SHOW GRANTS <principal> ON <securable_type> <securable_name>;

権限の許可

SQLを用いて権限を許可するには、以下のようなコマンドを使用します。Databricks SQLのData Explorerの使い方については、Use the Databricks SQL Data Explorerをご覧ください。

以下の文法を使用します。プレースホルダーの値を置き換えてください。

<privilege>: SELECTやUSAGEのような許可する権限
<securable_type>: カタログやテーブルのようなセキュリティ保護可能オブジェクトのタイプ
<securable_name>: セキュリティ保護可能オブジェクトの名前
<principal>: アカウントレベルユーザーのメールアドレスか、アカウントレベルグループの名前

SQL

GRANT <privilege> ON <securable_type> <securable_name> TO <principal>

権限の剥奪

SQLを用いて権限を剥奪するには、以下のようなコマンドを使用します。Databricks SQLのData Explorerの使い方については、Use the Databricks SQL Data Explorerをご覧ください。

以下の文法を使用します。プレースホルダーの値を置き換えてください。

<privilege>: SELECTやUSAGEのような許可する権限
<securable_type>: カタログやテーブルのようなセキュリティ保護可能オブジェクトのタイプ
<securable_name>: セキュリティ保護可能オブジェクトの名前
<principal>: アカウントレベルユーザーのメールアドレスか、アカウントレベルグループの名前

SQL

REVOKE <privilege> ON <securable_type> <securable_name> FROM <principal>

ダイナミックビュー

Unity Catalogでは、以下を含むきめ細かいアクセスコントロールを設定するためのダイナミックビューを使用することができます。

行・列レベルでのセキュリティ
データマスキング

注意
ダイナミックビューを用いたきめ細かいアクセスコントロールはSingle Userセキュリティモードでは利用できません。

Unity Catalogでは、ユーザーがアクセスできる行、カラム、ビューのレコードを動的に制限するために、以下の関数を導入しています。

current_user(): 現在のユーザーのメールアドレスを返却。
is_account_group_member(): 現在のユーザーが特定のアカウントレベルグループのメンバーであればTRUEを返却。Unity Catalogのデータに対するダイナミックビューでの利用を推奨。
is_member(): 現在のユーザーが特定のワークスペースレベルのグループのメンバーであればTRUEを返却。この関数は既存のHiveメタストアとの互換性のために提供されています。これは、アカウントレベルのグループメンバーシップを評価しないので、Unity Catalogのデータに使用するのは避けてください。

以下の例では、Unity Catalogのダイナミックビューの作成方法を説明します。

カラムレベルのアクセス権

ダイナミックビューを用いることで、特定のユーザー、グループがアクセスできるカラムを制限することができます。以下の例では、auditorsグループメンバーのみがsales_rawテーブルのメールアドレスにアクセスすることができます。クエリー分析においては、Apache SparkはCASE文をREDACTEDという文字列リテラルや実際のメールアドレスのカラムの中身で置換します。他のカラムは通常通りに返却されます。この戦略はクエリー性能にはネガティブなインパクトを及ぼしません。

SQL

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW sales_redacted AS
SELECT
  user_id,
  CASE WHEN
    is_account_group_member('auditors') THEN email
    ELSE 'REDACTED'
  END AS email,
  country,
  product,
  total
FROM sales_raw

行レベルのアクセス権

ダイナミックビューをを用いることで、行やフィールドレベルでアクセス権を指定することがでできます。以下の例では、managersグループのメンバーのみが総額が$1,000,000を超えたトランザクションを参照することができます。この条件にマッチしたトランザクションは他のユーザーには表示されません。

SQL

CREATE VIEW sales_redacted AS
SELECT
  user_id,
  country,
  product,
  total
FROM sales_raw
WHERE
  CASE
    WHEN is_account_group_member('managers') THEN TRUE
    ELSE total <= 1000000
  END;

データマスキング

Unity CatalogのビューはSpark SQLを使用しているので、より複雑なSQL表現や正規表現を用いた高度なデータマスキングを実装することができます。以下の例では、全てのユーザーはメールアドレスのドメインを分析することができますが、auditorsグループのメンバーはメールアドレス全体を参照することができます。

SQL

-- The regexp_extract function takes an email address such as
-- user.x.lastname@example.com and extracts 'example', allowing
-- analysts to query the domain name

CREATE VIEW sales_redacted AS
SELECT
  user_id,
  region,
  CASE
    WHEN is_account_group_member('auditors') THEN email
    ELSE regexp_extract(email, '^.*@(.*)$', 1)
  END
  FROM sales_raw

Unity CatalogとレガシーなHiveメタストアを一緒に使用する

Unity Catalogは加法的(additive)なものであり、Databricksのワークスペース単位のHiveメタストアと一緒に使用できることを意味します。Hiveメタストアは、3レベルの名前空間ではhive_metastoreと呼ばれるトップレベルのカタログとして表示されます。例えば、レガシーのHiveメタストアのsalesスキーマのsales_rawというテーブルは、以下の記述で参照することができます。

SQL

SELECT * from hive_metastore.sales.sales_raw;

USE文を用いてカタログとスキーマを指定することができます。

SQL

USE hive_metastore.sales;
SELECT * from sales_raw;

Unity CatalogとHiveメタストアにおけるアクセスコントロール

Hiveメタストアのテーブルアクセスコントロールを設定しているのであれば、User Isolationセキュリティモードで稼働しているクラスターにおいては、hive_metastoreカタログのデータに対するアクセスコントロールの強制を継続します。Unity Catalogにおけるアクセスコントロールモデルは、レガシーのアクセスコントロールと若干の差異(DENY文など)があります。Hiveメタストアはワークスペースレベルのオブジェクトであるため、hive_metastoreカタログ内で定義されたアクセス権は常にワークスペースローカルのユーザー、グループを参照します。テーブルアクセスコントロールとの違いをご覧下さい。

テーブルアクセスコントロールがHiveメタストアで有効化されている場合、ワークロードではUser Isolationが有効化されたクラスターを使用する必要があります。SQLエンドポイントは常にこのセキュリティモードを使用します。

テーブルアクセスコントロールとの違い

Unity Catalogはワークスペース単位のレガシーテーブルアクセスコントロールとは、以下の違いがあります。

Unity Catalogのアクセスコントロールモデルは、テーブルアクセスコントロールと以下の違いがあります。

アカウントレベルのID: Unity Catalogにおけるアクセスコントロールポリシーは、アカウントレベルのユーザー、グループに適用されますが、Hiveメタストアのアクセスコントロールポリシーはワークスペースレベルのユーザー、グループに適用されます。
簡素化されたアクセス権: Unity Catalogには、カタログ、スキーマ、テーブルとビューに対する4つの権限(SELECT, MODIFY, CREATE, USAGE)、外部ロケーション、ストレージ認証情報固有の3つの権限(READ_FILES, WRITE_FILES, CREATE TABLE)しかありません。しかし、明示的にアクセス権が許可されるまでアクセスを常に拒否するDENY文はUnity Catalogにはありません。READ_METADATAやMODIFY_CLASSPATHといったレガシーな権限はサポートされていません。
権限が継承されません: Unity Catalogでは、親のオブジェクトに対する権限は子供のオブジェクトに継承されません。
カタログ内のオブジェクトに対する全てのオペレーションにはUSAGE権限が必要です: テーブルやデータベースに対するプリンシパルの権限に関係なく、プリンシパルはテーブルやデータベースにアクセスするために、親のカタログに対するUSAGE権限を必要とします。ワークスペースレベルのアクセスコントロールでは、ルートカタログに対するUSAGEの許可によって自動ですべてのデータベースのUSAGEを許可しますが、ルートカタログに対するUSAGEは必要ではありません。
ビュー: Unity Catalogでは、ビューのオーナーは、ビューが参照するテーブルやビューのオーナーである必要はありません。親のスキーマとカタログに対するUSAGE権限とSELECT権限を持っているだけで十分です。ワークスペースレベルのテーブルアクセスコントロールでは、ビューのオーナーは、参照するテーブルやビューのオーナーである必要があります。
ALL FILESやANONYMOUS FUNCTIONの未サポート: Unity CatalogではALL FILESやANONYMOUS FUNCTION権限の概念がありません。これらの権限は、許可されないユーザーがコードを実行しないようにするアクセス制限を回避する手段となり得ます。

Join

3レベルの名前空間記述を用いることで、Unity CatalgのメタストアのデータとレガシーHiveメタストアのデータをJoinすることができます。

注意
レガシーHiveメタストアのデータとのJoinはデータが格納されているワークスペースでのみ動作します。別のワークスペースでそのようなJoinを実行しようとするとエラーとなります。レガシーなテーブル、ビューをUnity Catalogにアップグレードすることをお勧めします。

以下のサンプルでは、レガシーHiveメタストアのsales_currentテーブルと、Unity Catalogメタストアのsales_historicalテーブルとをorder_idフィールドでJoinします。

SQL

SELECT * FROM hive_metastore.sales.sales_current
JOIN main.shared_sales.sales_historical
ON hive_metastore.sales.sales_current.order_id = main.shared_sales.sales_historical.order_id;

以下の例では、より複雑なJoinを行なっています。それぞれのテーブルには共通する顧客のレコードを少なくとも1行含むことを前提として、顧客ごとの現在と過去の売り上げの合計を返却します。

SQL

SELECT current.customer_id, current.customer_name, COALESCE(current.total, 0) + COALESCE(historical.total, 0) AS total
  FROM hive_metastore.sales.sales_current AS current
  FULL OUTER JOIN main.shared_sales.sales_historical AS historical
    ON current.customer_id = historical.customer_id;

デフォルトのカタログ

トップレベルのカタログ名を省略し、USE CATALOG文を使用していない場合、デフォルトのカタログが選択されます。ワークスペースにおけるデフォルトカタログを設定するにはspark.databricks.sql.initial.catalog.nameの値を設定します。

既存コードの変更なしに現在のHiveメタストアで動作するように、デフォルトのカタログをhive_metastoreに設定することをお勧めします。

クラスターのインスタンスプロファイル

Unity CatalogとHiveメタストアを同居させる際、Hiveメタストアのデータにアクセスするためにインスタンスプロファイルが使用されますが、Unity Catalogのデータへのアクセスには使用されません。Unity Catalogはクラスターに設定されたインスタンスプロファイルには依存しません。

レガシーテーブルのUnity Catalogへのアップデート

Hiveメタストアのテーブルは、ビルトインの監査、アクセスコントロールのように、Unity Catalogが導入するフルセットのセキュリティ、ガバナンス機能の恩恵を受けることができません。Unity Catalogにレガシーテーブルをアップグレードすることをお勧めします。

次のステップ

Databricks 無料トライアル

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up