Databricks、AI/BI ダッシュボードの埋め込みにおけるセキュリティ対策を解説

課題

顧客向けアプリケーションに Databricks の AI/BI ダッシュボードを埋め込むことは、比較的 straightforward です。埋め込み機能を有効にし、バックエンドでスコープ限定のトークンを発行し、クライアント SDK でダッシュボードを描画するだけです。このプロセスの詳細は、How to embed Databricks AI/BI Dashboards in customer-facing applications という基礎ガイドで一通り解説されています。

より難しいのは認証の問題です。ダッシュボードを埋め込んだ後、各閲覧者がどの行のデータを見るべきかというルールです。パートナー企業には自社のデータのみを表示し、社内チームには所属する地域のデータのみを表示させる必要があります。このガイドでは、そうしたルールを実装する方法を紹介します。

本リファレンスパターンは、Databricks の複数の機能を組み合わせたものです。具体的には __aibi_external_value、Unity Catalog の行フィルタと列マスク、そして ID プロバイダー（IdP）から同期されたグループ機能です。これは単一の機能を有効化するのではなく、設計パターンとして捉えてください。

共通の権限ルールブックと、2 つの実装パス

同じ権限テーブルが、アプリケーション経由でアクセスする埋め込みダッシュボードと、Databricks ユーザーが実行する直接 SQL クエリの両方の制御に利用されます。

具体的なシナリオ

ある企業が、西・東・中央の 3 つの地域にまたがるデータを表示する「Open Accounts Receivable (AR) Tasks」という共有ダッシュボードを使用しているケースを考えてみましょう。このダッシュボードは、2 つの異なる視聴者層に対して提供されています。

外部の運用パートナーである Acme Ops、Bolt Partners、Core Logistics は Databricks のログイン権限を持たず、ホワイトラベルポータルを通じてダッシュボードにアクセスします。各パートナーは自社の担当地域のみを表示でき、連絡先メールアドレスは非表示となります。

内部チームは同社社員であり、Databricks にサインインして利用します。財務部門は全地域のデータにアクセス可能ですが、地域別運用チームは自らの担当地域のみを確認できます。これらの権限は、手動で管理するユーザーリストではなく、Okta や Entra ID といったアイデンティティプロバイダーのグループから付与されます。

一つのデータセットを 5 つのビューアーが共有し、それぞれが異なるスライスを表示します。対象となるのは Acme Ops、Bolt Partners、Core Logistics、財務部門、そして地域別運用チームです。以下の例では、Acme と財務部門に焦点を当てており、識別子として partner_acme、finance_all、West を使用しています。Acme は West 地域のデータを表示しますが、メールアドレスは非表示です。一方、財務部門は同じ公開ダッシュボードから全 3 つの地域をフルで確認できます。

1 つのテーブル、1 つのビュー、1 つのダッシュボード

アクセスルールはダッシュボードやクエリに散在するのではなく、一元管理されます。顧客ごとにダッシュボードを作成するとコピーが生成され、同期が外れるリスクがあります。また、すべてのクエリでフィルタを繰り返すと、ミスの機会が増えることになります。

このモデルは以下の 3 つのオブジェクトで構成されています。

• 基本テーブル open_ar_tasks は、各 AR タスクごとに 1 行保持し、地域と連絡先メールアドレスがタグ付けされています。

権限テーブルは、アクセス管理における唯一の信頼できる情報源です。各行には、スコープがアクセス可能な領域と、機密値をマスクする必要があるかどうかが記載されています。viewer_scope 列には、外部パートナー ID（例：partner_acme）や内部グループ名（例：finance_all）といった情報が格納されます。

「Secured View」は基本テーブルと権限情報を結合するため、閲覧者は自身がアクセス権を持つ領域のみを表示でき、設定に応じてメールアドレスはマスクされます。

一般的な導入環境では、このテーブルは上位の権限管理システムやアプリケーションが持つグループと地域のマッピング情報によって自動的に充填され、個別の閲覧者ごとに手動で編集されることはありません。

これにより、顧客ごとのダッシュボードやクエリ内で重複するフィルタリング処理を不要にします。ルールはダッシュボード自体を変更することなく、照会・監査・変更が可能なテーブル上に定義されます。

この仕組みは閲覧者ごとに適用され、各ユーザーがアクセス権を持つ情報のみを返却します：

*Acme（外部値 = partner_acme）: 西部地域のみ表示、連絡先メールアドレスはマスク。*

金融（外部値：finance_all）：全 3 つの地域、連絡先メールアドレスを完全に表示。

__aibi_external_value の由来

バックエンドが埋め込みトークンを発行する際に、この値を設定します。バックエンドはサービスプリンシパルとして認証し、Databricks からスコープ付きのトークンを要求します。そのトークンには 2 つの値が含まれます。

1. external_viewer_id：監査のために視聴者を識別するための ID
2. external_value：視聴者のアクセス範囲（スコープ）を表す値

Databricks がこのトークンの署名を行い、視聴者が埋め込まれた値を改ざんすることはできません。この値はダッシュボードの SQL として __aibi_external_value という名前で公開されます。

サービスプリンシパルの認証情報を保持しているため、このバックエンドは信頼できるサーバーサイドコンポーネントです。ブラウザ側ではなく、認証情報はソース管理（バージョン管理）システムではなく、シークレットマネージャーに保存されています。

重要な点は、クエリを実行する際のアイデンティティが誰であるかです。埋め込みクエリは、視聴者の Databricks 上の ID ではなく、設定された公開用アイデンティティ（パブリッシングアイデンティティ）の下で実行されます。

外部埋め込みにおいては、Databricks は個別のデータ権限を付与し、サービスプリンシパルに独自のデータアクセス権を与えることを推奨しています。これにより、クエリはサービスプリンシパルの権限で実行されます。（もし共有データ権限を使って公開すると、クエリはパブリッシャーの認証情報で実行されてしまいます。）その後、__aibi_external_value を用いて、各視聴者ごとにアクセス範囲を絞り込みます。

クエリがサービスプリンシパルの権限で実行されるため、埋め込みパスにおいて is_account_group_member() 関数を実行しても、実際にダッシュボードを閲覧している個人を特定することはできません。

重要なのは、external_value がパートナー ID に限定されない点です。バックエンドがトークンに署名するスコープであれば何でも利用できます。具体的には、外部パートナー向けに partner_acme を、内部グループ向けに finance_all（そのグループ名）を指定可能です。

エンタイトルメントテーブルでは、パートナー ID とグループ名が同じ列に格納されているため、1 つのダッシュボード、1 つのビュー、そして 1 つのフィルターで両者をカバーできます。

視聴者は署名された値を確認したり設定したりできないため、その値を変更することはできません。未知のスコープは行に一致しないため、デフォルトで拒否する動作が保証されます。

同じビューとフィルター（WHERE viewer_scope = __aibi_external_value）を両者のオーディエンスで共通して使用できます。異なるのは、このスコープのソースだけです。

グループ単位でアクセス権限を付与する

組織では、ID プロバイダーから同期されたグループを通じてアクセス管理を行うのが一般的です。例えば、Okta の「Finance」グループにユーザーが追加されると、自動的に finance_all というロールが付与され、データテーブルへの直接操作は不要になります。この例では、finance_all は全リージョンを指し、ops_west は西地域のみを指します。

アプリケーションは、閲覧者がどのグループに所属しているかをどのように把握するのでしょうか？埋め込み時に SQL を実行して確認することはできません。なぜなら、そのクエリはサービスプリンシパルの権限で実行されるため、is_account_group_member() 関数が誤ったアイデンティティを検証してしまうからです。閲覧者のトークンを発行する前に、アプリケーションのバックエンド側で閲覧者が属するグループを解決する必要があります。

一つの選択肢として、ユーザー認証機能を有効にした Databricks Apps でアプリケーションを実行する方法があります。

ログイン済みの内部ユーザーの場合、プラットフォームは信頼できるアイデンティティコンテキスト（閲覧者のメールアドレスやオン・ビハーフ・オブ (OBO) トークンなど）をバックエンドに転送します。バックエンドはこのトークンを使用して、SCIM の /Me エンドポイントを閲覧者の権限で呼び出し、所属グループを取得します。

このアプローチでは、サービスプリンシパルに対する管理者権限は不要です。ユーザーが自分のレコードを読み取るためです。ただし、ユーザー認証のスコープが必要であり、Apps OBO はまだ成熟段階にあるため、信頼する前に対象のデプロイ環境で検証を行う必要があります。

該当する権限を持つグループが見つからない場合は、より広いアイデンティティ（生のメールアドレスなど）にフォールバックせず、トークンの発行を拒否して安全側に閉じるべきです。

複数の権限グループに所属するビューアがいる場合、結果は決定論的に解決する必要があります。優先順位を定義するか、トークンを発行する前に複数のグループを単一の正規化されたスコープにマッピングすることで、同じビューアが常に一貫したアクセス権を受け取るようにします。

外部パートナーの場合はより単純です。Databricks のアイデンティティを持たない彼らのスコープは、ログイン時に割り当てられた固定のパートナー ID です。トークンもフィルタリング条件も共通であり、参照処理は不要です。

設計上の一つの制約があります。署名付きトークンは単一の external_value を保持します。ビューアが異なる権限を持つ複数のグループに所属している場合、1 つのトークンで表現できるスコープは 1 つに限られます。しかし、「1 人 1 ロール」が一般的なケースであれば、この制約でも問題ありません。

真の意味での複数グループへの統合アクセスが必要な場合は、全アクセス権限を持つグループを使用するか、以下の直接 SQL パスを利用します。これにより、行フィルタで各グループ全体にわたる OR 条件を適用できます。複合スコープ（JSON など）を external_value に圧縮することも可能ですが、その場合、パースとマッチングの処理はデータセット側の SQL へ移り、1 KB のペイロード制限の影響を受け続けます。

ガランティの強化

行フィルタリングは基本動作を提供します。各ビューアが自分の行のみを表示できる仕組みです。これに 3 つの追加レイヤーを組み合わせることで制御をさらに強化しますが、これらすべては同一の権限テーブルから読み込まれます。

ビューアごとに機密カラムをマスクする

ロールレベルセキュリティ（Row-level security）は、ビューアがアクセスできる行を決定します。一方、マスキングは、どのカラムを表示できるかを制御します。外部パートナーには、内部チームと同じ詳細度が必要ないケースが多いためです。

partner_pii 属性は、パートナー向けに true、内部グループ向けに false を設定し、これがセキュリティ強化されたビューにおけるマスキングロジック（上記 SQL の CASE 式）を駆動します。同じダッシュボードでも、内部の閲覧者には完全なメールアドレスを表示しつつ、パートナーには ****@example.com のようにマスクされた値を表示できます。マスキングルールが多数のテーブルにまたがり複雑化する場合は、Unity Catalog のカラムレベルのマスキングや属性ベースアクセス制御（ABAC）を長期的な解決策として採用するのが適切です。ここでは、例を示すためにビュー内で完結した構成としています。

デフォルト拒否と証明

未知のスコープはダッシュボードの行を一切返さず、基盤となるデータ構造に関する情報も漏らしてはいけません。構造を推測させるエラーや部分的なデータではなく、空の結果のみが返されるべきです。よりクリーンなアプローチとして、バックエンドがトークンを発行する前にエンティティメントテーブルを確認し、ゼロ行しか取得できないスコープには即座に拒否することも有効です。それと同様に重要なのが、スコープは認証された閲覧者から導出され、クライアントが提供したパラメータから生成されるわけではないという点です。これにより、閲覧者が他テナントのスコープを要求することを防ぎます。

トークン発行時にゲート（制限）を設けることで、アクセス権限のない視聴者がトークンを取得する自体を防ぐことができます。これは SQL フィルタのみを頼りにするよりも効果的な防御策です。

成功したトークン発行と拒否されたリクエストの両方をログに記録することで、認可決定の監査証跡を残すことが可能になります。権限のない視聴者はログに現れないため、万が一リクエストが漏れた場合でも、未知のスコープではダッシュボードの行が返されない仕組みになっています。

これらのログに外部ビューアー ID とそのスコープを記録しておけば、監査時に各認可決定を実際の顧客やユーザーに遡って追跡できます。

直接 SQL パスを保護する

埋め込みコントロールはアプリケーション経路の保護には役立ちますが、Databricks ユーザーがベーステーブルに直接クエリを投げるケースは別の脅威です。これに対処するには、Unity Catalog の行フィルタをベーステーブルに追加し、クエリを実行するユーザーの ID とグループに基づいてキーを設定する必要があります。

この直接クエリ経路では、is_account_group_member() 関数が実際のユーザーを評価し、そのユーザーが持つすべての権限付きグループを統合して判断します。

以下の関数に含まれるパブリッシャー例外（current_user() がパブリッシング ID と一致する場合）は、ダッシュボードのパブリック化や更新を行う ID に対する意図的な緊急時対応（break-glass）の許可であり、一般的なオペレーターによるバイパスではありません。これはオプションかつ高リスクな機能であるため、正当な理由がある場合のみ含め、デプロイごとに承認を得る必要があります。

機密フィールドに対するカラムマスクも同様の仕組みで動作します。これらの Unity Catalog の制御機能は、埋め込みパスとは独立して管理されています。具体的には、埋め込みされたビューアは __aibi_external_value とエンタイトルメントビューを通じてスコープが制限される一方、ワークスペース内の直接クエリは、呼び出し元の身元とグループを評価する Unity Catalog の行フィルタによって保護されます。両方の強制ポイントでは、同じエンタイトルメントテーブルが利用されています。

構築前に確認すべき点

「マルチテナンシー」について。 これはプール型の論理的多テナンシーです。外部パートナー同士は互いに隔離され、一方、社内従業員は自社のテナント内でグループベース（ロールベース）のアクセス権限が付与されます。すべてのデータは共有テーブル内に保持されたままですが、トークン、ビューフィルタ、エンタイトルメントテーブルが分離を確保します。直接 SQL による行フィルタは、この保証をアプリケーション外にも拡張するものです。

このパターンの適用タイミング。 Databricks アカウントを持たない外部パートナーと社内従業員が、同じダッシュボードを共有する必要がある場合にこのパターンを使用してください。すべての閲覧者が内部の Databricks ユーザーである場合は、Unity Catalog の行セキュリティとカラムセキュリティを組み合わせた基本的な埋め込み機能で十分対応できる可能性があります。

実用的な制約と注意点。 公開前に、以下の製品制限と運用詳細が最新のドキュメントと一致しているか必ず確認してください。

トークンは有効期限が 1 時間と短いため、アプリ側で定期的に更新する必要があります。特に、タブを開いたまま放置している場合などは要注意です。クライアント SDK を使えばこの処理は簡単で、トークンの有効期限が迫った際に getNewToken コールバックが /api/token エンドポイントから自動的に再取得してくれます。

external_viewer_id と external_value の合計サイズは 1 KB に抑えるようにしてください。ID は JSON ブロックや長いメールアドレスではなく、コンパクトな識別子として扱うのが基本です。

外部埋め込み機能のレート制限は、ワークスペースごとに 1 秒あたり 20 ダッシュボード読み上げまでとなっています。大規模な B2B ポータルを運用する場合はこの数値を把握しておく必要があります。

非個人識別情報（PII）である external_viewer_id を使用してください。監査ログに記録されるため、氏名や生メールアドレスのような機密情報よりも、安定した顧客 ID やユーザー ID の方が適しています。

ダウンロード機能はデフォルトで有効になっています。埋め込みビューアからは CSV、TSV、Excel、PNG 形式でのエクスポートが可能ですが、ワークスペース管理者がこれを無効にしない限り制限されません。エクスポートされるデータが、ビューアから見える範囲のデータと一致しているか確認しておきましょう。

直接 SQL パスを利用する場合は、アカウントレベルのグループを事前に用意してください。UC の行フィルタやマスキングは is_account_group_member() 関数を呼び出して評価しますが、これはワークスペース内のローカルグループではなく、アカウントレベルのグループに対して実行されます。埋め込みパスではこの関数は決して呼び出されません。

権限テーブルが巨大化するケースには注意が必要です。スコープが数千件に及んだり、階層構造が深くなったりする場合は、結合処理やマスキング式をシンプルに保ち、ルールが複雑化したら ABAC（属性ベースアクセス制御）を活用するのが賢明です。

重要なポイント

• アクセスルールは単一の権限テーブルに一元管理し、埋め込みダッシュボードと直接 SQL による保護の両方に活用してください。
• ユーザーが編集可能なフィルターに依存するのではなく、閲覧者やグループのスコープを __aibi_external_value に署名して適用します。
• デフォルト拒否（default-deny）、データマスキング、Unity Catalog の行フィルタを組み合わせた多層防御を採用しましょう。
• 埋め込み機能の実装は第一歩に過ぎません。実際に重要なのは、アクセス制御の設計と検証です。

次のアクション

まずは基礎となるガイド「How to embed Databricks AI/BI Dashboards in customer-facing applications」から始め、本記事で解説する権限管理、マスキング、デフォルト拒否のパターンを適用してください。基盤となるガバナンス制御については、AI/BI 埋め込みドキュメント、Unity Catalog の行フィルタと列マスキング、そして ABAC ガイドライン を参照してください。