Azure DatabricksのUnity Catalogを利用してテーブルのアクセス制御を行う

こんばんは。今日は、Azure DatabricksのUnity Catalogを利用してテーブルのアクセス制御を行う方法を試してみたので、備忘メモとして残しておこうと思います。

なお、Databricksでは、いろいろなレベルでアクセス制御ができるようでしたので、それぞれ試してみました。

テーブルレベルのアクセス制御

テーブルレベルのアクセス制御は、カタログエクスプローラーのGUIから簡単に構成することができます。

例えば、現在作業している管理ユーザとは別の一般ユーザ（ユーザBとします）にSELECT権限だけ付与してみます。

上のキャプチャの注意書きの通り、このときテーブルに対するSELECT権限だけでは足りず、カタログ・スキーマレベルでUSE CATALOG / USE SCHEMA権限の付与も併せて必要になる点留意です。

また比較のため、同じスキーマ内にユーザBには何も権限を付与しないもう一つのテーブルを作成しておきます。

その上でユーザBでログインしなおしてカタログを除くと・・ちゃんとテーブルはアクセス権が付与されたtitanicテーブルしかみれないようになっています。（moviesは見れない）

Notebookからテーブルを参照しようとしてみても、SELECT権限がない、というエラーが出てきます。

まずはテーブルレベルのアクセス制御ができることを確認しました。

行レベル・列レベルのセキュリティ

続いて、行レベル・列レベルのセキュリティの実現方法を確認します。

Databricksでの行レベル・列レベルのアクセス制御は、「動的ビュー関数」の機能を使って実現できるようです。

動的ビューを使用すると、行レベルと列レベルでアクセスを制御でき、さらにデータ マスキングを提供できます。

・・・

Unity Catalog では、動的ビューを使用して、次のようにアクセス制御をきめ細かく構成できます。

ビューの作成 – Azure Databricks | Microsoft Learn

今回は、以下のようなTitanic乗船客リストのデータを用いて、実験してみます。

列レベルのセキュリティ

ビューの作成 – Azure Databricks | Microsoft Learn

この場合、以下のようなビューを作成することになります。

CASE文のところで、必要なアクセス制御を実装しています。is_account_group_member()関数は、Databricksで組み込みで用意されている関数で、実行者が指定したアカウントグループのメンバーかどうかを判定します。（managersグループに属すメンバーがクエリすれば氏名情報を、そうでないユーザがクエリしたら”REDACTED (編集済)”と返す）

%sql
CREATE VIEW titanic_columnfiltered AS
SELECT
  PassengerId,
  Survived,
  Pclass,
  CASE WHEN
    is_account_group_member('managers') THEN Name
    ELSE 'REDACTED'
  END AS Name,
  Sex,
  Age,
  Sibsp,
  Parch,
  Ticket,
  Fare,
  Cabin,
  Embarked
FROM titanic

なお、このときのアカウントグループは、Databricksアカウントコンソールで管理されるグループのことを指しています。

また、クエリを実行するユーザにビューのSELECT権限（＋USE CATALOG, USE SCHEMAがなければあわせて）も付与しておきます。（今回はNotebookでSQLを実行）

Unity Catalog の権限とセキュリティ保護可能なオブジェクト – Azure Databricks | Microsoft Learn

# titanic_columnfilteredテーブルへのSELECT権限の付与
%sql
GRANT SELECT ON TABLE sample001.sampleschema001.titanic_columnfiltered TO `権限付与先のグループ/ユーザ名`;

この状態で、managersグループに属するユーザAと、属さないユーザBからそれぞれテーブルをクエリしてみます。

ユーザA（managersグループに属する）

Name列が参照できています。

ユーザB（managersグループに属さない）

Name列情報は”REDACTED”と表示され参照できません。

想定通り、ユーザAからのみName列情報が参照できることが確認できました！

行レベルのセキュリティ

この場合以下のようなビューを作成することになります。

列レベルのセキュリティの場合は、SELECTで取得する列中で条件を挟みましたが、こちらはWHERE句の中で条件を挟むことになります。

%sql
CREATE VIEW titanic_rowfiltered AS
 SELECT
  PassengerId,
  Survived,
  Pclass,
  Name,
  Sex,
  Age,
  Sibsp,
  Parch,
  Ticket,
  Fare,
  Cabin,
  Embarked
 FROM titanic
 WHERE
   CASE
     WHEN is_account_group_member('managers') THEN TRUE
     ELSE PClass = 1
   END;

同様に、このビューをクエリするユーザにSELECT権限を付与しておきます。

%sql
GRANT SELECT ON TABLE sample001.sampleschema001.titanic_rowfiltered TO `権限を付与する先のグループ/ユーザ名`;

この状態で、managersグループに属するユーザAと、属さないユーザBからそれぞれテーブルをクエリしてみます。

ユーザA（managersグループに属する）

すべてのPclassのデータが参照でき、合計891行返されています。

ユーザB（managersグループに属さない）

Pclass=1のデータのみが返されており、合計でも216行にフィルターされていることが分かります。

こちらも想定通り、行レベルのセキュリティが効いていることが確認できました！

タグベースのアクセス制御

DatabrciskのUnity Catalogでは、行レベル、列レベルセキュリティに加えて、タグベースのアクセス制御もできる、という噂を聞いた気がしたけど、公式ドキュメントからは見つけられなかった・・勘違いだったかな・・・

以下を見ると、ロードマップにはあるようなので、今後こうしたよりきめ細かいアクセス制御もできるようになっていくのかもしれないですね。また追加で分かったことがあればUpdateしようと思います。

Unity Catalogにおける権限継承を用いてアクセスポリシー管理をシンプルに – Qiita

以上、Unity Catalogを利用したアクセス制御を試してみた、のメモでした。少しでも参考になりましたら幸いです！

おしまい