GA：ユーザー代理認可を使用した、権限に対応したDatabricks Appsの構築

Databricks Appsを使用すると、開発者はインタラクティブなダッシュボードや運用ツールからカスタムAIエージェントに至るまで、データおよびAIアプリケーションをDatabricksプラットフォーム上に直接構築してデプロイできます。

一般提供（GA）が開始されたユーザー代理（OBO）認可により、アプリケーションコード内でデータガバナンスルールを再実装することなく、パーソナライズされ、権限を認識したエクスペリエンスを提供するアプリを構築できるようになります。アプリがOBOを使用してサポートされているDatabricks APIを呼び出すと、サインインしているユーザーのアイデンティティを使用して動作します。Unity Catalogは、行フィルターや列マスクを含む、そのユーザーの既存のデータ権限を適用し、APIスコープは、アプリがユーザーの代わりに実行できる操作を制限します。アプリは、共有設定の読み取りやアプリケーションメトリクスの書き込みなど、アプリが所有する操作に対して、専用のサービスプリンシパルを引き続き使用できます。

たとえば、営業インサイトアシスタントは、アプリに広範なSQL権限やワークスペース管理権限を与えることなく、営業担当者がアクセスを許可されているアカウントとフィールドのみを使用して質問に答えることができます。

各操作を管理するアイデンティティから始める

アプリを設計する際は、次の問いを立ててください。 「この特定の操作は誰の権限で管理されるべきか？」

Databricks Appsは、アプリ認可とユーザー認可という、相互に補完し合う2つの認可モデルをサポートしています。アプリ認可はアプリ専用のサービスプリンシパルを使用し、アプリが所有する操作や、すべてのユーザーに同じ結果を返す必要があるエクスペリエンスに適しています。ユーザー認可は、ユーザーの権限で操作を管理する必要がある場合に、サインインしているユーザーのアイデンティティを使用します。ほとんどの本番アプリでは、リクエストパスごとに適切なアイデンティティを選択することで、両方のモデルを使用できます。 詳細は Databricksアプリでの認可の設定を参照してください。

たとえば、「今四半期のアカウントのパフォーマンスはどうなっているか、またその変化の要因は何か？」といった質問に答えるアプリを考えてみましょう。このアプリには以下が必要です。

• リクエストを行うユーザーとして売上データや顧客データをクエリする。
• 行レベルのフィルターや列マスクを含む、Unity Catalogの権限を尊重する。
• 読み取り専用の分析結果を返す。
• 必要に応じて、別のサービスを呼び出して結果を要約する。
• データの変更やSQLリソースの管理を行わない。

これはユーザー認可に最適です。アプリはリクエストを行うユーザーの転送されたアクセストークンをSQLコネクタに渡し、Databricksはそのユーザーの既存のウェアハウスとUnity Catalogの権限を使用してクエリを評価します。アプリ側でコード内にルールを再作成することなく、地域のマネージャーにはその地域の担当アカウントのみが表示され、全国のリーダーにはすべての地域が表示されます。管理者がUnity Catalogのポリシーを更新すると、それ以降のアプリのリクエストにその変更が反映されます。 

ユーザーの権限によって、クエリが返すことのできるデータが決まります。次の設計上の決定事項は、転送されたユーザートークンを使用して、アプリがユーザーの代わりに実行できる操作を制限することです。

タスクに適合する最も狭いAPIスコープを使用する

営業インサイトアシスタントは、読み取り専用のクエリを実行する必要があります。リソースを管理したり、他のSQL操作を実行したりするための広範なSQLアクセスは必要ありません。そのため、より広範な sqlスコープではなく、 sql:restricted-queryをリクエストする必要があります。 

sql:restricted-queryを使用すると、アプリは読み取り専用のSQLクエリを実行できます。アプリが他のSQL操作を実行することは許可されません。これにより、アプリの製品としての動作と認可境界がより適切に一致します。アプリは分析のために管理対象データを読み取ることができますが、ユーザーのアイデンティティを広範なSQL操作の資格情報として使用することはできません。

アプリがユーザーの代わりにGenieやUnity Gatewayも呼び出す場合は、 genieや ai-gatewayなど、対応するスコープのみをリクエストしてください。アプリが実際にそれらの機能を使用しない限り、 files、 model-serving、 vector-searchなどはリクエストしないでください。 

スコープは機能の上限を定めるものであり、データアクセスを許可するものではありません。アプリが適切なAPIスコープを持っている必要があり、さらにユーザーがターゲットリソースへのアクセス権限を持っている必要があります。 詳細は スコープベースのセキュリティと権限の昇格を参照してください。

明示的なAPIスコープでアプリを設定する

Databricks UIまたは Declarative Automation Bundleでユーザー認可を設定します。 

読み取り専用の分析アシスタントの場合、アプリは以下を宣言できます。

注意：APIスコープは、アプリが宣言するユーザー認可設定の一部です。SQLウェアハウスやUnity Catalogデータへのアクセス権を付与するものではありません。リクエストを行うユーザーは、ターゲットのSQLウェアハウスの使用を許可されており、かつクエリ対象のデータに対して必要なUnity Catalogの権限を持っている必要があります。 

ユーザーがユーザー認可されたアプリに初めてアクセスすると、Databricksは要求されたAPIスコープへの同意を求めるプロンプトを表示します。 

ユーザーアイデンティティをSQLコネクタに渡す

Databricksは、現在のユーザーのアクセストークンを x-forwarded-access-token HTTPヘッダーで転送します。アプリは、ユーザーコンテキストのアクセスが必要なリクエストに対してそのトークンを取得し、SQLコネクタに渡す必要があります。

次の例では、FlaskとDatabricks SQL Connector for Pythonを使用して、トークンの流れを明確に示しています。Databricks AppKitを使用してアプリを構築する場合も、同じ認可原則を適用してください。ユーザー固有の操作にはユーザーコンテキストクライアントまたはリクエスト時のアイデンティティを使用し、アプリ所有の操作はアプリのアイデンティティで行います。

注意： 転送されるトークンは有効期限が短く、リクエストごとに発行されます。アプリはリクエストごとにトークンを読み取り、リクエスト間やセッション内に保存することはありません。 

アプリの認証との重要な違いは、コネクターが転送されたユーザートークンを access_token 経由で受信することです。 sql:restricted-query APIスコープは、アプリが必要とする読み取り専用のSQL機能に制限し、Unity Catalogがそのユーザーが実際にアクセスできる行と列を決定します。 詳細は、 ユーザー認証を使用したクエリを参照してください。

ワークスペース管理者が上限を設定できるようにする

開発者は、アプリに必要なAPIスコープを指定します。ワークスペース管理者は、アプリ開発者がワークスペース内のアプリに追加できるAPIスコープを制御できます。

このポリシーにより、チームは読み取り専用の分析やAIエクスペリエンスを構築できると同時に、アプリがより広範な、または無関係な機能を要求するのを防ぐことができます。アプリ開発者は、ワークスペースで構成されたAPIスコープの境界を超えてアプリの権限を拡張することはできません。

これにより、組織は2つのレベルの制御が可能になります。

• アプリは、その機能に必要な最小限のAPIスコープを宣言します。
• ワークスペース管理者は、そのワークスペース内のアプリが利用できる最大限のAPIスコープを定義します。

ワークスペース管理者は、この許可リストを 設定 > 開発 > アプリで設定します。この設定はデフォルトですべてのサポートされているAPIに設定されていますが、選択したAPIスコープに絞り込むことも、Noneに設定してユーザー認証を無効にすることもできます。 詳細は、 ユーザー認証スコープの制限を参照してください。

アカウント管理者は、スコープがワークスペースの許可リストに含まれていない場合でも、スコープを追加できます。管理者が後から許可されたスコープを削除した場合、そのスコープで既に実行されているアプリは実行を継続できますが、許可されていないスコープが削除されるまで、起動、デプロイ、または更新することはできません。

アプリ所有の操作とユーザー所有の操作を分離する

多くの便利なアプリでは、両方の認証モデルが必要です。例えば、売上インサイトアシスタントは以下を使用する場合があります。

• アプリケーションメトリクスの書き込みや共有設定の読み取りを行うための、アプリスコープのクライアント。
• 現在のユーザーのデータをクエリするための、 sql:restricted-query を持つユーザースコープのクライアント。
• ユーザーに代わって別の Databricks サービスを呼び出す必要がある場合の、個別のユーザーAPIスコープ。

1つの汎用クライアントを作成してそれをあらゆる場所で再利用するのではなく、アプリケーションコード内でそのアイデンティティの境界を明示することをお勧めします。依存関係、名前、テストを分離することで、アプリの資格情報がユーザー固有のパスに使用されたり、ユーザートークンがバックグラウンド処理のために保持されたりするのを防ぐことができます。

リクエストにユーザー認証が必要で、転送されたトークンがない場合は、アプリのサービスプリンシパルに暗黙的に切り替えるのではなく、安全に処理を失敗（フェイルクローズ）させてください。そうしないと、アプリは有効に見えるものの、異なる権限で生成された応答を返してしまう可能性があります。そのため、上記の例の query_as_user は、欠落しているヘッダーをインラインで処理するのではなく、 require_user_token で始まっています。

エージェントにも同じパターンを適用する

Databricks Apps にデプロイされたカスタムエージェントも同じモデルを使用できます。転送されたユーザートークンはアクティブなユーザーリクエスト中のみ利用可能であるため、アプリケーションの起動時ではなく、リクエスト時の invoke または stream ハンドラー内でユーザースコープのワークスペースクライアントを初期化してください。共有リソースやバックグラウンド操作にはアプリ認証を使用します。 詳細は、 エージェントの認証を参照してください。
 

実装を安全にする

• 必要な最小限のAPIスコープのみを要求します。
• コード、テスト、および依存関係の接続において、アプリ所有のクライアントとユーザー認証されたクライアントを分離した状態に保ちます。
• 転送されたアクセストークンを出力、ログ記録、または永続化しないでください。
• アプリの管理を信頼できる開発者に制限し、認証関連の変更にはピアレビューを義務付けます。
• ユーザートークンを保持するのではなく、共有操作やバックグラウンド操作にはアプリ認証を使用します。
• Unity Catalogのアクセス権限が異なるユーザーでテストを行い、ポリシー変更後にそれらのテストを繰り返します。

始めましょう

ユーザー代理認証により、同じメカニズムからパーソナライズとガバナンスの両方を得ることができます。ユーザーの Unity Catalog 権限によってアプリがアクセスできるデータが決定され、最も狭い一致するAPIスコープによってユーザーに代わって実行できる操作が決定されます。まずは、追加のリソースやベストプラクティスについて、こちらの ヘルプドキュメントを参照してください。

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