目次 › 第4章 › 4-3

第4章 アプリケーションの組み立てとデプロイ / 想定学習時間:30〜40分 / 最終確認:2026年8月

4-3. アクセス制御・権限管理(Unity Catalogのガバナンス機能との連携)

1. Unity Catalogの権限モデルの基本

Unity Catalogでは、カタログ→スキーマ→オブジェクト(テーブル・モデル・関数・ボリュームなど)という階層のそれぞれに対して、GRANT文で権限を付与します。生成AIアプリに関係する主な権限は次の通りです。

重要なのは、階層のすべてで権限が揃って初めてアクセスできることです。たとえばモデルprod.genai_apps.support_rag_chainを使うには、prodへのUSE CATALOG、genai_appsへのUSE SCHEMA、モデルへのEXECUTEの3つが必要です。

-- モデル利用チームへの権限付与の例
GRANT USE CATALOG ON CATALOG prod TO `app-team`;
GRANT USE SCHEMA  ON SCHEMA  prod.genai_apps TO `app-team`;
GRANT EXECUTE     ON MODEL   prod.genai_apps.support_rag_chain TO `app-team`;

2. Model Servingエンドポイント自体の権限

UCの権限は「モデルというオブジェクト」への権限でした。これとは別に、デプロイ後のServingエンドポイント自体にもアクセス制御レベルがあります。

「モデル(UC)への権限」と「エンドポイントへの権限」は別レイヤーである点を区別してください。アプリの利用者はエンドポイントにCan Queryがあれば推論でき、背後のUCモデルへの直接権限は必要ありません。逆に、エンドポイントを構成・更新する人には、UC側のモデル権限とエンドポイントのCan Manageの両方が求められます。

3. サービスプリンシパルとシークレット管理

本番アプリからエンドポイントを呼ぶとき、個人ユーザーのアカウントやパーソナルトークンを使うのはアンチパターンです。個人の退職・異動でアプリが停止し、監査上も「アプリのアクセス」と「個人のアクセス」が区別できなくなるためです。代わりに次の構成を取ります。

• サービスプリンシパル(service principal) — アプリケーション専用のIDを作成し、必要最小限の権限(エンドポイントへのCan Queryなど)を付与する
• Databricks Secrets — APIキーやトークンをコードに直書きせず、シークレットスコープに保存して実行時に参照する

# シークレットの登録(CLI)
# databricks secrets create-scope genai-app
# databricks secrets put-secret genai-app openai-api-key

# ノートブック/ジョブからの参照
api_key = dbutils.secrets.get(scope="genai-app", key="openai-api-key")

# 外部モデル用エンドポイント設定などでは
# {{secrets/genai-app/openai-api-key}} の形式で参照できる

4. RAG特有の考慮:文書の権限と回答の権限の整合

RAGアプリでは、権限管理に固有の落とし穴があります。ユーザーが直接読む権限のない文書の内容が、ボットの回答経由で漏れてしまう問題です。

たとえば人事の給与規程(人事部限定)をインデックスに含めた社内ボットを全社員に公開すると、一般社員が「役員の報酬体系は?」と聞くだけで、本来アクセスできない情報が回答に含まれ得ます。ベクトル検索インデックスは元テーブルの行レベル権限を自動では引き継がないため、設計で整合を取る必要があります。代表的なアプローチは次の通りです。

原則は「回答の到達範囲は、ソース文書の閲覧権限の範囲を超えてはならない」です。試験でも、機密文書を含むRAGの設計問題でこの観点が問われます。

5. 最小権限の原則と監査

権限設計の全体を貫くのが最小権限の原則(principle of least privilege)です。各主体(ユーザー、グループ、サービスプリンシパル)には、業務に必要な最小限の権限だけを付与します。

• アプリのサービスプリンシパルにはCan Queryのみ(Can Manageを与えない)
• 開発者にはdevカタログの権限のみ(prodへの書き込みはCI/CD用サービスプリンシパルに限定)
• RAGのインデックス作成ジョブには、ソーステーブルのSELECTと対象スキーマへの作成権限のみ

また、UCは監査ログにより「誰が・いつ・どのモデルやテーブルにアクセスしたか」を記録します。推論リクエストの内容そのものの記録(推論テーブル)と合わせて、事後の追跡・説明責任を担保します。運用監視の詳細は第6章で扱います。

練習問題