概要
生成AIや社内RAG基盤を業務に組み込むと、これまで部署単位で分散管理されていた図面・契約書・顧客情報といった機密データが、ひとつの推論パイプラインに集約されます。データの利用が容易になる一方、権限設計を誤ると、アクセス権のないデータがLLMの回答を通じて漏洩するインシデントに直結します。
DigitalBaseが社内AI基盤を構築する際に標準としているアクセス制御の設計指針を整理します。RBAC・ABAC・PBACの使い分け、最小権限と職務分離、ゼロトラスト、ベクトルDBやAPI層でのアクセス制御、監査の手順を解説します。
AI基盤における権限管理の重要性
AIシステムは大量の機密データや個人情報を扱うことが多く、不適切な権限設定は重大なセキュリティインシデントにつながります。特に、RAGのように検索結果をプロンプトへ注入する構成では、検索段階のアクセス制御が不十分な場合、LLMがアクセス権のないドキュメントを要約して返すリスクがあります。
AI固有のセキュリティリスク
1. データアクセスの範囲が広い
LLMは学習・ファインチューニングや推論時の検索のために複数のデータソースへアクセスします。アクセスが適切に制限されない場合、複数のデータソースにまたがる機密情報へ到達するリスクがあります。
2. 動的なアクセスパターン
AIシステムはユーザーの入力に応じて参照するデータが変わるため、静的なロール定義だけでは制御しきれません。誰が・どの文脈で・どのデータにアクセスしたかを実行時に判断する仕組みが求められます。
3. APIを介した間接的なアクセス
社内AI基盤は複数のシステムや外部APIと連携することが多く、APIキーやサービスアカウントの権限スコープ管理が安全性を大きく左右します。
4. モデルそのものへのアクセス制御
ファインチューニング済みモデルや埋め込みインデックスは、それ自体が保護対象となる資産です。不正なアクセス・改変・持ち出しから保護する必要があります。
アクセス制御の基本モデル
社内AI基盤では、用途に応じてRBAC・ABAC・PBACを組み合わせて設計します。
RBAC（Role-Based Access Control）
ユーザーの役割（ロール）に基づいて権限を付与するモデルです。
- ユーザーにロールを割り当て、ロールに権限を紐づける
- 管理がシンプルでスケーラブル
- 一般的なエンタープライズシステムで広く利用されている
AI基盤におけるロール設計の例は以下のとおりです。
| ロール | 主な権限 |
|---|---|
| データサイエンティスト | モデルの学習・調整・評価 |
| MLエンジニア | モデルのデプロイ、インフラ管理 |
| 業務ユーザー | AIシステムの利用（推論のみ） |
| 管理者 | ユーザー管理、権限設定、監査ログ閲覧 |
| 監査者 | ログの閲覧のみ（変更権限なし） |
ABAC（Attribute-Based Access Control）
ユーザー・リソース・環境の属性に基づいて、動的にアクセス判定を行うモデルです。RAGのように文脈ごとに参照範囲が変わる用途に適しています。
- 柔軟できめ細かいアクセス制御が可能
- 複雑な業務ルールを表現できる
- 動的なアクセス制御に適している
判定に用いる属性の例は次のとおりです。
- ユーザー属性: 所属部門、役職、クリアランスレベル
- リソース属性: データの機密度、所有者、作成日
- 環境属性: アクセス時刻、アクセス元IPアドレス、デバイス種別
ポリシーは以下のような条件式として表現します。
IF (ユーザー.部門 == "営業部" AND データ.種類 == "顧客情報" AND アクセス時刻 IN 業務時間 AND アクセス元IP IN 社内ネットワーク) THEN アクセスを許可
PBAC（Policy-Based Access Control）
明示的なポリシールールに基づいてアクセスを制御するモデルです。
- セキュリティポリシーを集中管理できる
- 監査要件への対応が容易
- ポリシーの変更を運用側で管理できる
実務では、ロールで基本的な権限を定義し（RBAC）、文脈依存の判定を属性で補い（ABAC）、組織横断の規約をポリシーとして一元管理する（PBAC）三層構成により、各モデルの役割を整理できます。
権限設定のベストプラクティス
1. 最小権限の原則（Principle of Least Privilege）
ユーザーやシステムには、業務に必要な最小限の権限のみを付与します。
- 推論エンドポイントには、推論に必要なデータへの読み取り権限のみを付与する
- データサイエンティストには学習データへのアクセスを許可し、本番デプロイ権限は分離する
- APIキーには必要なエンドポイントへのアクセスのみを許可する
2. 職務分離（Separation of Duties）
重要な操作には複数人の関与を必須とし、単独で完結できないように設計します。
- モデルの学習者とデプロイ者を分離する
- データのアップロード者と承認者を分離する
- 権限設定者と監査者を分離する
- 本番環境へのデプロイには複数人の承認を必要とする
3. ゼロトラストアーキテクチャ
「何も信用せず、すべてを検証する」という原則に基づき、すべてのアクセス要求を認証・認可します。
- すべてのAPIアクセスに認証を必須化する
- ネットワークセグメンテーションでAI基盤を分離する
- マイクロセグメンテーションでコンポーネント間通信を制限する
- 内部ネットワークからのアクセスも例外なく検証する
4. 定期的な権限レビュー
権限は時間とともに陳腐化するため、定期的に棚卸しします。
- ユーザーのロールや権限が現在の業務に適切か確認する
- 休眠アカウントや不要な権限を剥奪する
- APIキーをローテーションする
- 過剰な権限を持つアカウントを特定する
レビュー頻度の目安は以下のとおりです。
| 対象 | 推奨頻度 |
|---|---|
| ユーザー権限 | 四半期ごと |
| 管理者権限 | 毎月 |
| APIキー | 3ヶ月ごとにローテーション |
5. 時限付きアクセス
特別な権限が必要な場合は一時的に付与し、一定時間後に自動で剥奪します。緊急メンテナンス時の管理者権限、デバッグ目的のデータアクセス、プロジェクト期間限定のアクセスなどが該当します。
具体的な権限確認の手順
ステップ1: アクセス制御マトリックスの作成
誰が何にアクセスできるかを一覧化し、設計と実装のずれを可視化します。
| ロール/リソース | 学習データ | モデル | 推論API | 本番環境 | |----------------|----------|----------|---------|---------| | Data Scientist | 読み書き | 読み書き | 読み | 読み | | ML Engineer | 読み | 読み書き | 書き | 書き | | App Developer | - | - | 実行 | 読み | | Business User | - | - | 実行 | - | | Admin | 管理 | 管理 | 管理 | 管理 |
ステップ2: 認証・認可メカニズムの実装
認証は次のような手段を組み合わせます。
- SSO（シングルサインオン）: OAuth 2.0、SAML、OpenID Connect
- MFA（多要素認証）: 認証アプリ、生体認証など
- APIキー / トークン: 暗号化されたAPIキー、JWTトークン
- サービスアカウント: マネージドID、シークレット管理
認可では、エンドポイントごとに必要なロールを明示します。
ステップ3: データアクセス制御
行レベルセキュリティ（RLS）
データベース側で、ユーザーがアクセスできる行を制限します。RAGのベクトルストアにpgvectorのようなPostgreSQL拡張を用いている場合、検索クエリにもRLSが適用されるため、アプリ層の実装漏れに対する保護策として有効です。
-- 例: PostgreSQLでのRLS設定 CREATE POLICY customer_data_policy ON customer_data FOR SELECT USING (department = current_setting('app.user_department')); ALTER TABLE customer_data ENABLE ROW LEVEL SECURITY;
列レベルセキュリティ（CLS）
クレジットカード番号やマイナンバーなど、機密性の高い列へのアクセスを限定します。埋め込み生成の前段でこうした列をマスキングすることで、ベクトル化された情報からの間接的な漏洩も抑えられます。
ステップ4: APIセキュリティ
APIキーは次の観点で管理します。
- キーのローテーション: 定期的に更新する
- スコープ制限: 必要な機能のみを許可する
- レート制限: 利用者ごとの呼び出し回数を制限する
- IPホワイトリスト: 特定のIPアドレスからのみ許可する
シークレットは環境変数やハードコードではなく、シークレットマネージャーから取得します。
ステップ5: 監査ログの設定
記録すべきイベントは次のとおりです。
- 認証イベント: ログイン/ログアウト、認証失敗
- アクセスイベント: データへのアクセス、API呼び出し
- 変更イベント: 権限の変更、データの更新/削除
- モデルイベント: 学習、デプロイ、推論実行
ログは改ざんできない形式で保存し、SIEM（Security Information and Event Management）へ集約します。保存期間は法的要件に応じて設定します。
ステップ6: 定期的な監査とテスト
- ユーザー権限が適切かを定期的にレビューし、未使用アカウントや過剰な権限を特定する
- ログを分析して異常なアクセスパターンを検出する
- ペネトレーションテストで権限エスカレーションやアクセス制御のバイパスを検証する
要点
社内AI基盤のアクセス制御は、機密データの保護とシステムの安全な運用に必要です。RBAC・ABAC・PBACを適切に組み合わせ、最小権限・職務分離・定期レビュー・詳細な監査ログを実装することで、堅牢な権限管理体制を構築できます。
特にRAGや生成AIは、検索や推論を通じて広範なデータへ間接的にアクセスできるため、通常のシステム以上に慎重な設計が求められます。アクセス制御を「アプリ層・データ層・ネットワーク層」で多層化し、継続的に監視と改善を行うことが、安全なAI活用の前提となります。