Databricksの監査ログ・課金情報のシステムテーブルをワークスペース単位で分離する方法

はじめに

Databricksの一般的な利用形態として、1つのDatabricksアカウントを複数の組織で共有するケースがあります。例えば、企業内の複数部門や企業グループ内の複数の関連会社がそれぞれ独自のワークスペースを持ち、運用するといった形です。

このような環境では通常、中央ITチームがDatabricksアカウント全体を管理し、必要に応じて各組織にワークスペースを払い出します。この際によくある課題が、中央ITチームとしては「各組織には自分たちのワークスペースに関連する課金情報や監査ログだけを見せたい（他組織の情報は見せたくない）」というものです。しかし、Databricksのシステムテーブルにはアカウント全体の情報が含まれているため、そのままでは他組織のワークスペースの情報も閲覧できてしまいます。

このブログでは、Unity Catalogのビューを活用して、各組織が自組織のワークスペースに関連する監査ログと課金情報のみを参照できる環境を構築する方法を紹介します。

環境構成と要件

本記事では、ABCフィナンシャルグループ (FG) という架空の金融グループ会社を想定します。ABC FGではメインリージョンとしてAzure東日本リージョンを利用します。

本記事の内容はクラウドを問いません

本記事ではAzure Databricksを例としています。若干手順の読み替えが必要な箇所はありますが、Databricks on AWS、Databricks on Google Cloudでも同様の構成が可能です。

環境構成

環境構成は以下の図の通りです。

Databricksアカウント

ABCフィナンシャルグループ全体で1つのDatabricksアカウントを使用

Databricksワークスペース（いずれもAzure東日本リージョンを利用）

ABCフィナンシャルグループ中央ITチーム用ワークスペース

ABC銀行用ワークスペース

ABC証券用ワークスペース

要件

ABCフィナンシャルグループの中央ITチームは、各社に対して以下の要件を満たす必要があります。

• ABC銀行には、ABC銀行のワークスペースに関連する監査ログ・課金データのみを見せる
• ABC証券には、ABC証券のワークスペースに関連する監査ログ・課金データのみを見せる
• 他社の情報を見られないようにする

対象とするシステムテーブル

本記事においてワークスペース単位の分離対象とするシステムテーブルは以下の3つです。

1. 監査ログ: system.access.audit
2. 課金対象の使用状況システムテーブル: system.billing.usage
3. 価格設定システムテーブル system.billing.list_prices

各システムテーブルの詳細は以下のリンクをご覧ください。

システムテーブルによるワークスペースレベル情報の有無

監査ログテーブルと課金対象の使用状況テーブルには、ワークスペースレベルの情報が含まれています。一方、価格設定テーブルはSKU価格の履歴ログであり、ワークスペース固有の情報は含まれていません。そのため、後段のステップではワークスペースIDによるフィルタを行う必要がありません。

実装方法

要件を満たすために、以下の構成を実装していきます。

1. 中央ITチーム管理者グループのみが system カタログへのアクセス権を持つ
2. 中央ITチーム管理者グループが所有者となり各社共有用の shared_system カタログを作成する
3. 中央ITチームが shared_system カタログ配下に各社用のスキーマを作成し、各社に読み取りアクセス権を付与する
4. システムテーブルからワークスペースIDでフィルタした監査ログ・課金情報のシステムテーブルのビューを各社のスキーマに作成する
5. 各社ワークスペースと shared_system カタログをワークスペースバインディングで接続する

1. 環境準備

以下の環境が既に準備されていることを前提とします。

• Azure Databricksワークスペース
  • 中央ITチーム用ワークスペース
  • ABC銀行用ワークスペース
  • ABC証券用ワークスペース
• 各ワークスペースは同一のメタストアに関連付けられている
• アカウントグループ
  • 中央ITチーム管理者グループ
  • ABC銀行管理者グループ
  • ABC証券管理者グループ

本記事で使用するAzure Databricksワークスペース

ワークスペースに同一のメタストアを割り当て

本記事で使用するアカウントグループ

2. 各ワークスペースにアカウントグループをワークスペース管理者グループとして登録

アカウントコンソール (https://accounts.azuredatabricks.net) で、各ワークスペースの管理者グループを登録します。

1. アカウントコンソールの各ワークスペースの[権限]タブにアクセス
2. 該当するアカウントグループをワークスペース管理者 (Admin) として追加

中央ITチーム用ワークスペースの管理者グループ（他ワークスペースも同様に設定）

3. システムスキーマを有効化

中央ITチーム用ワークスペースでシステムスキーマを有効化します。これにより、監査ログや課金情報にアクセスできるようになります。

以下のQiita記事を参考に、Databricks SDK for Pythonを使って有効化するのが楽です。

システムスキーマ有効化の備考

• システムスキーマの有効化を実行するユーザーは、アカウント管理者の権限を持っている必要があります
• 上記Qiita記事は、有効化可能なすべてのシステムスキーマを有効化する実装になっています。有効化対象のシステムスキーマを絞り込みたい場合は、一部書き換えて実行してください

システムスキーマ有効化後の見え方：アカウント管理者

システムスキーマを有効化後、アカウント管理者の権限を持つユーザーのカタログエクスプローラーには、システムスキーマの一覧が表示され、各テーブルにSELECTができる状態になります。

カタログ：アカウント管理者にUSE CATALOGが付与されている

スキーマ：アカウント管理者にUSE SCHAMEが付与されている

テーブル：アカウント管理者にSELECTが付与されている

システムスキーマ有効化後の見え方：非アカウント管理者

アカウント管理者の権限を持たないユーザーのカタログエクスプローラーには、システムスキーマ有効化前と同様、system.aiスキーマとsystem.information_schemaスキーマのみが表示されます。

カタログ：All account usersにUSE CATALOGが付与されている

system.aiスキーマ：All account usersに各種権限が付与されている

system.information_schemaスキーマ：All account usersにUSE SCHAMEが付与されている

system.information_schemaスキーマ配下のテーブル：All account usersにSELECTが付与されている

4. shared_system カタログを作成

続いて、各組織のワークスペースへの共有用のカタログ shared_system を、中央ITチームのAzureポータルおよびDatabricksワークスペースを通じてセットアップしていきます。

Azureポータル：ストレージアカウント & コンテナーの作成

まずは、Azureポータルにアクセスし、カタログのパスとして設定するストレージアカウントおよびコンテナーを作成します。ストレージアカウント作成時に、階層型名前空間を有効にすることを失念しないようにします。

新しいストレージアカウントの作成

新しく作成したコンテナー

Azureポータル：アクセスコネクターの作成と権限付与

続いて、Azure Databricksのアクセスコネクターを作成し、先ほど作成したストレージアカウントに対するストレージBLOBデータ共同作成者の権限を付与します。

新しいアクセスコネクターの作成

アクセスコネクターのストレージアカウントに対する権限

Databricksワークスペース：メタストアレベルの権限付与

この後、ストレージ資格情報、外部ロケーション、カタログを作成していきます。メタストアレベルで以下の権限を持っていることを確認し、不足している場合には付与しておきます。

• CREATE CATALOG
• CREATE EXTERNAL LOCATION
• CREATE STORAGE CREDENTIAL

メタストアレベルの権限付与

Databricksワークスペース：ストレージ資格情報の作成・管理

続いて、Azure Databricksワークスペースにて、新しいストレージ資格情報を作成します。ここでは abc_cred_shared_system という名前にします。

アクセスコネクターIDには、Azureポータル上でアクセスコネクターの概要ページのリソースIDからコピーした値を貼り付けます。

ストレージ資格情報の作成

推奨設定：所有者をグループに変更

Unity Catalogではオブジェクトを作成したユーザーが自動的に所有者になるため、忘れずに所有者をグループに変更しておくのが良いです。

作成直後はユーザーが所有者

所有者をグループに変更

推奨管理：必要なワークスペースのみにバインディングを変更

ストレージ資格情報について、作成直後はすべてのワークスペースにバインディングされますが、必要なワークスペースのみにバインディングを変更しておくのが良いです。

中央ITチーム用ワークスペースにのみバインディング

Databricksワークスペース：外部ロケーションの作成・設定

続いて、新しい外部ロケーションを作成します。ここでは abc_extloc_shared_system という名前にします。

• 作成後、接続のテストを行い、すべて成功することを確認します
• 推奨設定：所有者をグループに変更
• 推奨設定：必要なワークスペースのみにバインディングを変更

外部ロケーションの作成

接続のテスト

Databricksワークスペース：カタログの作成

続いて、新しいカタログを作成します。ここでは shared_system という名前にします。

カタログの作成

Databricksワークスペース：カタログの設定

引き続きカタログの設定を行います。

• 必要なワークスペースのみにバインディングを変更
  • ここでは、中央IT、銀行、証券のワークスペースにバインディング
• 所有者をグループに変更
• 権限は一旦なしにする
  • デフォルトはAll account usersへのBROWSE権限だが、これを削除

カタログの設定1

カタログの設定2

5. 各社のスキーマ作成と所有者の変更

SQLエディタで以下のSQLを実行し、各社のスキーマ作成と所有者の変更を行います。

各社のスキーマ作成と所有者の変更

-- スキーマ作成
CREATE SCHEMA IF NOT EXISTS shared_system.abc_central_it COMMENT 'Schema for ABC Central IT system tables';
CREATE SCHEMA IF NOT EXISTS shared_system.abc_bank COMMENT 'Schema for ABC Bank system tables';
CREATE SCHEMA IF NOT EXISTS shared_system.abc_securities COMMENT 'Schema for ABC Securities system tables';

-- 所有者の変更
ALTER SCHEMA shared_system.abc_central_it OWNER TO `ABC Central IT Admin Group`;
ALTER SCHEMA shared_system.abc_bank OWNER TO `ABC Central IT Admin Group`;
ALTER SCHEMA shared_system.abc_securities OWNER TO `ABC Central IT Admin Group`;

スキーマ作成・所有者変更の実行結果

6. 各社のビュー作成

SQLエディタで以下のSQLを実行し、各社のビュー作成と所有者の変更を行います。冒頭の変数宣言のcatalog_schemaとworkspace_idを各社の値に変更し、ワークスペース数と同じ回数、実行します。

各社のビュー作成と所有者の変更

DECLARE catalog_schema = 'shared_system.abc_securities.';
DECLARE workspace_id = '3920382974887062';
DECLARE owner_principal = 'ABC Central IT Admin Group';

-- 監査ログの動的ビュー
DECLARE create_view_access_audit = "CREATE OR REPLACE VIEW " || catalog_schema || "access_audit AS SELECT * FROM system.access.audit WHERE workspace_id = '" || workspace_id || "'";
EXECUTE IMMEDIATE create_view_access_audit;

-- 課金使用状況の動的ビュー
DECLARE create_view_billing_usage = "CREATE OR REPLACE VIEW " || catalog_schema || "billing_usage AS SELECT * FROM system.billing.usage WHERE workspace_id = '" || workspace_id || "'";
EXECUTE IMMEDIATE create_view_billing_usage;

-- 価格設定の動的ビュー（ワークスペース固有情報なし）
DECLARE create_view_billing_list_prices = "CREATE OR REPLACE VIEW " || catalog_schema || "billing_list_prices AS SELECT * FROM system.billing.list_prices";
EXECUTE IMMEDIATE create_view_billing_list_prices;

-- 所有者を変更
DECLARE alter_view_access_audit = "ALTER VIEW " || catalog_schema || "access_audit OWNER TO `" || owner_principal || "`";
EXECUTE IMMEDIATE alter_view_access_audit;

DECLARE alter_view_billing_usage = "ALTER VIEW " || catalog_schema || "billing_usage OWNER TO `" || owner_principal || "`";
EXECUTE IMMEDIATE alter_view_billing_usage;

DECLARE alter_view_billing_list_prices = "ALTER VIEW " || catalog_schema || "billing_list_prices OWNER TO `" || owner_principal || "`";
EXECUTE IMMEDIATE alter_view_billing_list_prices;

ビュー作成・所有者変更の実行結果

7. 各管理者グループへの権限付与

各グループが適切な権限を持つように、カタログ、スキーマ、およびビューに対する権限を設定します。以下では、中央ITチーム、ABC銀行、およびABC証券の各管理者グループに対して必要な権限を付与するSQLステートメントを示します。

権限付与の概要

1. 中央ITチーム管理者グループ
   • shared_systemカタログに対する完全な管理権限（ALL PRIVILEGESとMANAGE）
2. ABC銀行管理者グループ
   • shared_systemカタログの使用権限（USE CATALOG）
   • abc_bankスキーマの使用権限と読み取り権限（USE SCHEMAとSELECT）
3. ABC証券管理者グループ
   • shared_systemカタログの使用権限（USE CATALOG）
   • abc_securitiesスキーマの使用権限と読み取り権限（USE SCHEMAとSELECT）

この権限設定により、各組織は自社のデータのみにアクセスでき、中央ITチームはすべてのリソースを管理できます。

各管理者グループへの権限付与

-- 中央ITチームの管理者グループに対する権限付与
-- shared_systemカタログにALL PRIVILEGESとMANAGEを付与
GRANT ALL PRIVILEGES ON CATALOG shared_system TO `central_it_admins`;
GRANT MANAGE ON CATALOG shared_system TO `central_it_admins`;

-- ABC銀行の管理者グループに対する権限付与
-- shared_systemカタログにUSE CATALOGを付与
GRANT USE CATALOG ON CATALOG shared_system TO `abc_bank_admins`;
-- abc_bankスキーマにUSE SCHEMAとSELECTを付与
GRANT USE SCHEMA ON SCHEMA shared_system.abc_bank TO `abc_bank_admins`;
GRANT SELECT ON SCHEMA shared_system.abc_bank TO `abc_bank_admins`;

-- ABC証券の管理者グループに対する権限付与
-- shared_systemカタログにUSE CATALOGを付与
GRANT USE CATALOG ON CATALOG shared_system TO `abc_securities_admins`;
-- abc_securitiesスキーマにUSE SCHEMAとSELECTを付与
GRANT USE SCHEMA ON SCHEMA shared_system.abc_securities TO `abc_securities_admins`;
GRANT SELECT ON SCHEMA shared_system.abc_securities TO `abc_securities_admins`;

各管理者グループへの権限付与の実行結果

8. systemカタログへの権限付与

上記で各社グループの設定については完了したのですが、最後の設定作業として、systemカタログに対して中央ITチームの管理者グループに以下の権限を設定する必要があります。

• USE CATALOG
• USE SCHEMA
• SELECT
• MANAGE (オプション)

systemカタログへの権限付与

systemカタログの権限一覧

systemカタログ権限付与の前提条件

systemカタログに権限を付与できるのは、メタストア管理者に属するグループのユーザーになります。

中央ITチームの管理者グループがメタストア管理者の権限を持っていない場合、当該グループを一時的にメタストア管理者に設定する必要があります。

systemカタログへの権限付与後、メタストア管理者の設定は削除（既定のSystem userに戻す）しても問題ありません。

systemカタログ権限未設定時のエラー

もし上記の権限を設定せずに、各社のビューをSELECTすると、以下のようなエラーメッセージが表示され、SELECTに失敗します。

ビューのSELECT時のエラー

サンプルデータの取得エラー

Your request failed with status FAILED: [BAD_REQUEST] [INSUFFICIENT_PERMISSIONS] Insufficient privileges: Table 'access_audit' does not have sufficient privilege to execute because the owner of one of the underlying resources failed an authorization check. User does not have USE SCHEMA on Schema 'system.access'. SQLSTATE: 42501

9. 見え方のテスト

実装が完了したら、各管理者グループで正しくアクセス権が設定されているかテストします。

中央IT管理者グループ

中央IT管理者グループは、すべてのシステムテーブルおよびビューにアクセスできることを確認します。

system.access.auditのサンプルデータ閲覧ができる

shared_systemスキーマ配下の各社のビューが見えており、ビューのサンプルデータ閲覧ができる

ABC銀行管理者グループ

ABC銀行管理者グループは、自社のスキーマ内のビューのみにアクセスできること、systemカタログおよび他社のスキーマで監査ログ・課金情報が見えないことを確認します。

systemカタログはデフォルトの表示、shared_systemカタログでは自社のabc_bankスキーマのみが表示されている

スキーマ配下のビューのサンプルデータ閲覧ができる

ABC証券管理者グループ

ABC証券管理者グループも同様に、自社のスキーマ内のビューのみにアクセスできること、systemカタログおよび他社のスキーマで監査ログ・課金情報が見えないことを確認します。

systemカタログはデフォルトの表示、shared_systemカタログでは自社のabc_securitiesスキーマのみが表示されている

スキーマ配下のビューのサンプルデータ閲覧ができる

考慮事項

最後に、いくつかの考慮事項を記載します。

マルチリージョン対応

上記の実装は、メインリージョンである東日本リージョンのワークスペースを想定したものです。システムテーブルの情報はリージョンごとに分かれているため、別リージョンのワークスペースを利用する場合では、各リージョンに同様の仕組みを実装するなどの対応が必要となります。

定期メンテナンス

定期的なメンテナンスとして以下の点に留意が必要です。

• 新たなワークスペースが追加された場合の対応
• ワークスペースIDが変更された場合のビューの更新
• アクセス権限の定期的な監査と見直し

ビューの読み取りに必要な権限

ビューを読み取るために必要な権限は、コンピュートの種類、Databricks Runtimeのバージョン、およびアクセスモードによって異なります。正確な内容は以下のドキュメントを参照ください。

(以下、上記ドキュメントより抜粋し機械翻訳した内容）

ビューの照会に関する要件

ビューを読み取るために必要な権限は、コンピュートの種類、Databricks Runtimeのバージョン、およびアクセスモードによって異なります。

注意
すべてのビューについて、ビュー自体とビューの元になる基盤テーブルおよびビューの両方で権限チェックが実行されます。基盤テーブルとビューについて権限がチェックされるユーザーは、コンピュートによって異なります。以下の場合、Unity Catalogは基盤データに対するビュー所有者の権限をチェックします：

• SQLウェアハウス
• 標準コンピュート（以前の共有コンピュート）
• きめ細かいアクセス制御が有効な、Databricks Runtime 15.4 LTS以上の専用コンピュート（以前の単一ユーザーコンピュート）

Databricks Runtime 15.3以下の専用コンピュートでは、Unity Catalogは基盤データに対するビュー所有者の権限とビューユーザーの権限の両方をチェックします。

この動作は以下の要件に反映されています。いずれの場合も、ビューユーザーがビューにアクセスするためには、ビュー所有者が基盤データに対する権限を維持する必要があります。

• すべてのコンピュートリソースについて、ビュー自体に対するSELECT権限、その親カタログに対するUSE CATALOG権限、およびその親スキーマに対するUSE SCHEMA権限が必要です。これはUnity Catalogをサポートするすべてのコンピュート種類（SQLウェアハウス、標準アクセスモードのクラスター、およびDatabricks Runtime 15.4以上の専用アクセスモードのクラスター）に適用されます。

• Databricks Runtime 15.3以下の専用アクセスモードを使用するクラスターの場合、ビューによって参照されるすべてのテーブルとビューに対するSELECT権限に加えて、それらの親カタログに対するUSE CATALOG権限、およびそれらの親スキーマに対するUSE SCHEMA権限も必要です。

注意
Databricks Runtime 15.4 LTS以上の専用クラスターを使用していて、基盤テーブルとビューに対するSELECT権限の要件を回避したい場合は、ワークスペースがサーバーレスコンピュートに対応しているか確認してください。

サーバーレスコンピュートはデータフィルタリングを処理し、基盤テーブルとビューに対する権限がなくてもビューへのアクセスを可能にします。専用コンピュートを使用してビューを照会する場合、サーバーレスコンピュートの料金が発生する可能性があることに注意してください。詳細については、専用コンピュート（以前の単一ユーザーコンピュート）におけるきめ細かいアクセス制御を参照してください。

おわりに

本記事では、Databricksの環境において、複数の組織間でシステムテーブル情報を安全に分離・共有する方法を実装しました。中央ITチームがシステムテーブルへの直接アクセスを制御しつつ、各社には自社の情報のみを閲覧できる仕組みを構築することで、情報セキュリティと必要なデータアクセスの両立を実現しています。

Unity Catalogのビュー機能を活用したこの手法が、皆様のDatabricks環境管理の参考になれば幸いです。