埋め込みのその先へ：すべてのビューワーに対してAI/BIダッシュボードを安全に保護する方法

課題

顧客向けアプリケーションに Databricks AI/BI ダッシュボードを埋め込むのは、比較的簡単です。埋め込みを有効にし、バックエンドでスコープ付きトークンを発行し、クライアント SDK を使用してダッシュボードをレンダリングするだけです。基本的なガイドである「顧客向けアプリケーションに Databricks AI/BI ダッシュボードを埋め込む方法」では、そのプロセスを最初から最後まで説明しています。

より難しい問題は認可です。ダッシュボードが埋め込まれた後、各閲覧者にはどの行を表示すべきでしょうか？ パートナーには自社のデータのみを表示し、社内チームには担当リージョンのデータのみを表示させたい場合があります。このガイドでは、これらのルールを適用する方法を説明します。

このリファレンスパターンは、いくつかの Databricks の機能を組み合わせています。__aibi_external_value、Unity Catalog の行フィルターと列マスク、およびアイデンティティプロバイダー（IdP）から同期されたグループです。これは単一の有効化機能ではなく、デザインパターンです。

1つのルールブック、2つの適用パス

同じエンタイトルメントテーブルが、アプリケーション経由でアクセスされる埋め込みダッシュボードと、Databricks ユーザーが実行する直接の SQL クエリという2つのパスを制御します。

具体的なシナリオ

3つのリージョン（West、East、Central）のデータをまたぐ、共有の「未回収売掛金（AR）タスク」ダッシュボードを使用している企業を考えてみましょう。このダッシュボードは、2つの異なる対象者に提供されます。

• Acme Ops、Bolt Partners、Core Logistics などの外部の運営パートナーは、Databricks のログイン権限を持たず、ホワイトラベルのポータル経由でダッシュボードにアクセスします。各パートナーは自社のリージョンのみを閲覧でき、連絡先メールアドレスはマスクされている必要があります。
• 社内チームは、Databricks にサインインする自社の従業員です。財務チーム（Finance）はすべてのリージョンへのアクセスが必要ですが、地域の運用チームは自社のリージョンのみを閲覧します。彼らのアクセス権は、手動で管理されたユーザーリストからではなく、Okta や Entra ID などのアイデンティティプロバイダー（IdP）のグループから取得されます。

5つの閲覧者が1つのデータセットを共有し、それぞれ異なる部分を閲覧します（Acme Ops、Bolt Partners、Core Logistics、Finance、および地域の運用チーム）。以下の例では、Acme と Finance に焦点を当てています。識別子 partner_acme、finance_all、および West がこれらの例を表しています。Acme はメールアドレスがマスクされた状態で West を閲覧し、Finance は同じ公開ダッシュボードから3つのリージョンすべてを完全に閲覧します。

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

アクセスルールは、ダッシュボードやクエリに分散させるのではなく、1つの場所に集約します。顧客ごとにダッシュボードを作成すると、同期がずれてしまうコピーが作成される原因になります。また、すべてのクエリでフィルターを繰り返すと、ミスの原因になります。

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

• ベーステーブル `open_ar_tasks`：AR タスクごとに1行を保持し、リージョンと連絡先メールアドレスがタグ付けされています。

• エンタイトルメントテーブルは、アクセスに関する唯一の真実のソース（Single Source of Truth）です。各行は、スコープがアクセスできるリージョンと、機密性の高い値をマスクする必要があるかどうかを定義します。viewer_scope 列には、partner_acme などの外部パートナー ID と、finance_all などの社内グループ名の両方が格納されます。

• 保護されたビュー（Secured view）：ベーステーブルをエンタイトルメントに結合するため、閲覧者には権限のあるリージョンのみが表示され、フラグが設定されている場合はメールアドレスがマスクされます。

ほとんどのデプロイでは、上流のエンタイトルメントシステムまたはアプリケーションが所有するグループからリージョンへのマッピングによってこのテーブルにデータが入力されます。閲覧者ごとに手動で編集されることはありません。

これにより、顧客ごとのダッシュボードや、クエリ間で繰り返されるフィルターを回避できます。ルールはテーブル内に存在するため、ダッシュボードを変更することなく、クエリ、監査、変更を行うことができます。

閲覧者ごとに適用されると、保護されたビューは、その閲覧者に権限があるデータのみを返します。

Acme (external_value = partner_acme): West のみ、連絡先メールアドレスはマスク。

Finance (external_value = finance_all): 3つのリージョンすべて、連絡先メールアドレスはすべて表示。

__aibi_external_value の取得元

バックエンドは、埋め込みトークンを発行するときにこの値を設定します。サービスプリンシパルとして認証し、監査用に閲覧者を識別する external_viewer_id と、閲覧者のスコープを表す external_value の2つの値を持つスコープ付きトークンを Databricks に要求します。Databricks がトークンに署名するため、閲覧者は埋め込まれた値を変更できません。この値は、ダッシュボードの SQL に __aibi_external_value として公開されます。サービスプリンシパルの認証情報を保持するため、このバックエンドは信頼されたサーバー側のコンポーネント（ブラウザではない）であり、それらの認証情報はソース管理ではなくシークレットマネージャーに保管されます。

重要な詳細は、誰のアイデンティティがクエリを実行するかということです。埋め込みクエリは、閲覧者の Databricks アイデンティティではなく、設定された公開用アイデンティティの下で実行されます。

外部埋め込みの場合、Databricks は個別のデータ権限を設定し、サービスプリンシパルに独自のデータアクセスを許可することを推奨しています。これにより、クエリはサービスプリンシパルとして実行されます。（代わりに共有データ権限で公開すると、クエリは公開者の認証情報として実行されます。）その後、ビューは __aibi_external_value を通じて、各閲覧者向けにそのアクセスを制限します。クエリはサービスプリンシパルとして実行されるため、埋め込みパスでは is_account_group_member() を使用してダッシュボードを実際に閲覧している個人を特定することはできません。

重要な詳細は、external_value がパートナー ID に限定されないということです。バックエンドがトークンに署名する任意のスコープにすることができます。たとえば、外部パートナーの場合は partner_acme、社内グループの場合は finance_all（そのグループ名）などです。

エンタイトルメントテーブルはパートナー ID とグループ名を同じ列に保持するため、1つのダッシュボード、1つのビュー、1つのフィルターで両方をカバーできます。

閲覧者が署名された値を表示したり設定したりすることはないため、閲覧者がそれを変更することはできません。不明なスコープはどの行にも一致しないため、デフォルト拒否（default-deny）の動作が提供されます。

同じビューと同じフィルター（WHERE viewer_scope = __aibi_external_value）が両方の対象者に提供されます。異なるのは、そのスコープのソースだけです。

個人ではなくグループにアクセス権を付与する

組織は通常、アイデンティティプロバイダーから同期されたグループを通じてアクセスを管理します。誰かが Okta の Finance グループに参加すると、そのアクセス権は自動的に finance_all にマッピングされ、データテーブルを変更する必要はありません。この例では、finance_all はすべてのリージョンにマッピングされ、ops_west は West リージョンにマッピングされます。

アプリケーションは、ビューワーがどのグループに属しているかをどのようにして識別するのでしょうか？埋め込み時にはSQLに依存することはできません。クエリがサービスプリンシパルとして実行され、is_account_group_member() が誤ったアイデンティティをチェックしてしまうためです。アプリケーションは、トークンを発行する前に、ビューワーを認識できるバックエンドでビューワーのグループを解決する必要があります。

1つの方法として、ユーザー認証を有効にした Databricks Apps 上でアプリケーションを実行することが挙げられます。

ログインしている社内ユーザーの場合、プラットフォームはビューワーのメールアドレスや代理（OBO）トークンを含む、信頼されたアイデンティティコンテキストをバックエンドに転送します。バックエンドはそのトークンを使用して、ビューワーとして SCIM /Me を呼び出し、そのグループを読み取ります。

ユーザー自身が自分のレコードを読み取るため、このアプローチではサービスプリンシパルの管理者権限は必要ありません。ただし、ユーザー認可スコープが必要であり、Apps OBO はまだ開発途上の段階であるため、実際に依存する前にターゲットのデプロイ環境で検証してください。

権限のあるグループが見つからない場合は、生のメールアドレスなどのより広いアイデンティティにフォールバックするのではなく、安全側に倒して（fail closed）トークンの発行を拒否してください。

ビューワーが複数の権限を持つグループに属している場合は、結果を決定論的に解決します。優先順位を定義するか、トークンを発行する前に複数のグループを1つの標準的なスコープにマッピングすることで、同じビューワーが常に一貫したアクセス権を得られるようにします。

外部パートナーの場合はよりシンプルです。Databricks のアイデンティティを持たないため、彼らのスコープはログイン時に割り当てられる固定のパートナー ID になります。同じトークン、同じフィルターを使用し、ルックアップは不要です。

設計時に考慮すべき制限事項として、署名付きトークンが保持できる external_value は1つだけである点が挙げられます。ビューワーが異なる権限を持つ複数のグループに属している場合でも、1つのトークンは1つのスコープしか表せません。1人につき1つのロールという一般的なケースであれば、これで問題ありません。

複数のグループを完全に結合（union）させるには、フルアクセスグループを使用するか、以下に示す直接 SQL パスを使用します。直接 SQL パスでは、行フィルターがすべてのグループに対して OR 条件を適用できます。複合スコープ（JSON など）を external_value に詰め込むこともできますが、その場合、パースとマッチングの処理がデータセットの SQL 側に移動し、1 KB のペイロード制限に縛られたままになります。

セキュリティ保証の強化

行フィルタリングは、「各ビューワーには自身の行のみが表示される」という基本動作を提供します。さらに3つのレイヤーで制御を強化でき、これら3つはすべて同じ権限テーブルから読み取りを行います。

ビューワーごとの機密列のマスキング

行レベルのセキュリティは、ビューワーがアクセスできる行を決定します。マスキングは、表示できる列を決定します。通常、外部パートナーは社内チームほど詳細な情報を必要としないためです。

パートナーの場合は true、社内グループの場合は false となる mask_pii フラグが、保護されたビュー内のマスキングロジック（上記の SQL における CASE 式）を制御します。同じダッシュボードで、社内ビューワーには完全なメールアドレスを表示し、パートナーには ****@example.com のようなマスクされた値を表示することができます。マスキングルールが多くのテーブルに及び複雑になる場合は、長期的には Unity Catalog の列マスクや属性ベースのアクセス制御（ABAC）を使用するのが最適です。ここでは、例をシンプルに完結させるためにビューを使用しています。

デフォルト拒否（Default-deny）とその証明

未知のスコープに対しては、ダッシュボードの行を返さず、基礎となるデータ構造に関する情報を一切漏らさないようにする必要があります（構造を暗示するエラーや部分的なデータは返さず、空の結果のみを返します）。さらに手前で処理を止める方がよりスマートです。バックエンドがトークンを発行する前に権限テーブルを確認し、対象行がゼロのスコープに対しては発行を拒否します。同様に重要な点として、スコープは認証されたビューワーから派生したものであり、クライアントから提供されたパラメータから取得されることは決してないため、ビューワーが他のテナントのスコープを要求することはできません。

トークン発行時にゲートウェイ（制限）を設けることで、拒否されたビューワーがトークンを受け取ることを防ぎます。これは、SQL フィルターのみを唯一のガードとして依存するよりも優れています。トークンの正常な発行と拒否されたリクエストの両方をログに記録することで、認可の決定を監査可能にします。拒否されたビューワーはそもそも表示されず、仮にリクエストがすり抜けたとしても、未知のスコープではダッシュボードの行は返されません。これらのログに external_viewer_id とそのスコープを記録することで、監査時に各認可の決定を実際の顧客やユーザーまで遡って追跡できます。

直接 SQL パスの保護

埋め込み制御はアプリケーションパスを保護します。一方、ベーステーブルを直接クエリする Databricks ユーザーは別の脅威となります。クエリを実行するユーザーのアイデンティティとグループをキーとする Unity Catalog の行フィルターをベーステーブルに追加します。この直接クエリパスでは、is_account_group_member() が実際のユーザーを評価し、そのユーザーが権限を持つすべてのグループを組み合わせることができます。以下の関数におけるパブリッシャーの例外処理（current_user() がパブリッシュ用アイデンティティと等しい場合）は、ダッシュボードをパブリッシュまたは更新するアイデンティティに対する意図的な緊急避難措置（break-glass allowance）であり、一般的なオペレーターによるバイパスではありません。これはオプションであり、リスクが高いため、正当な理由がある場合にのみ含め、デプロイごとに承認してください。

機密フィールドに対する列マスクも同様に機能します。これらの Unity Catalog による制御は埋め込みパスとは独立しています。埋め込まれたビューワーは __aibi_external_value と権限ビューを介してスコープが制限されるのに対し、直接のワークスペースクエリは、呼び出し元のアイデンティティとグループを評価する Unity Catalog の行フィルターによって保護されます。どちらの適用ポイントも、同じ権限テーブルを使用します。

構築する前に

「マルチテナンシー」について： これは、プールされた論理的なマルチテナンシーです。外部パートナーは互いに隔離され、社内従業員は自社のテナント内でグループベース（ロールベース）のアクセス権を受け取ります。すべてのデータは共有テーブルに保持され、トークン、ビューフィルター、および権限テーブルによって分離が強制されます。直接 SQL の行フィルターは、アプリの外部でも同様の保証を拡張します。

このパターンを使用すべきケース： Databricks アカウントを持たない外部パートナーと社内従業員が1つのダッシュボードを共有する必要がある場合に、このパターンを使用します。すべてのビューワーが社内の Databricks ユーザーである場合は、Unity Catalog の行および列セキュリティを使用した基本的な埋め込みで十分な場合があります。

実用的な制約と注意点： 公開する前に、現在のドキュメントで以下の製品制限と運用の詳細を確認してください。

• トークンの有効期限は短い（1時間）ため、特にタブを開いたままにしている場合は、アプリでトークンを更新する必要があります。クライアント SDK を使用すると、これが簡単になります。getNewToken コールバックは、トークンの有効期限が近づくと /api/token エンドポイントから再取得を行います。
• external_viewer_id と external_value の合計を 1 KB 未満に抑える： JSON ブロブや長いメールアドレスではなく、コンパクトな識別子を使用してください。
• 外部埋め込みの場合、ワークスペースあたり1秒間に20回のダッシュボード読み込みというレート制限があります。大規模な B2B ポータルを構築する際には知っておく価値があります。
• PII（個人を特定できる情報）を含まない external_viewer_id を使用する。 これは監査ログに記録されるため、フルネームや生のメールアドレスよりも、不変の顧客 ID やユーザー ID を使用する方が適しています。
• ダウンロードはデフォルトで有効になっています。ワークスペース管理者がダウンロードを無効にしない限り、埋め込みビューワーはCSV、TSV、Excel、およびPNGをエクスポートできます。エクスポートされた結果が、想定されるビューワー制限データと一致していることを確認してください。
• ダイレクトSQLパス用のアカウントレベルのグループをプロビジョニングします。UCの行フィルターとマスクは、ワークスペースローカルのグループではなく、アカウントレベルのグループに対してis_account_group_member()を評価します。埋め込みパスがこの関数を呼び出すことはありません。
• 大規模なエンタイトルメントテーブルに注意してください。数千ものスコープや深い階層がある場合は、結合式やマスク式をシンプルに保ち、ルールが複雑になった場合はABACに依存するようにします。

主要なポイント

• アクセスルールを1つのエンタイトルメントテーブルに保持し、埋め込みダッシュボードとダイレクトSQL保護の両方に使用します。
• ビューワーまたはグループのスコープを__aibi_external_valueに署名します。ユーザーが編集可能なフィルターには依存しないでください。
• デフォルト拒否（default-deny）、マスキング、およびUnity Catalogの行フィルターを多層的なコントロールとして使用します。
• 埋め込みは最初の一歩に過ぎません。アクセス制御の設計と検証こそが重要な作業です。

次のステップ

まずは基本ガイド「顧客向けアプリケーションにDatabricks AI/BIダッシュボードを埋め込む方法」から始め、次にこのブログ記事で説明されているエンタイトルメント、マスキング、デフォルト拒否のパターンを適用してください。基盤となるガバナンス管理については、AI/BI埋め込みに関するドキュメントに加えて、Unity Catalogの行フィルターと列マスク、およびABACガイダンスを参照してください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事