社内AI基盤のアクセス制御設計｜RBAC・ABAC・最小権限で守る権限管理の実装指針

概要

生成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基盤におけるロール設計の例は以下のとおりです。

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キーをローテーションする
• 過剰な権限を持つアカウントを特定する

レビュー頻度の目安は以下のとおりです。

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、シークレット管理

認可は、エンドポイントごとにロールを要求するデコレータとして実装すると見通しが良くなります。

# 例: PythonでのRBAC実装
from functools import wraps

def require_role(required_role):
    def decorator(f):
        @wraps(f)
        def decorated_function(*args, **kwargs):
            if not current_user.has_role(required_role):
                abort(403)  # Forbidden
            return f(*args, **kwargs)
        return decorated_function
    return decorator

@app.route('/api/model/train')
@require_role('data_scientist')
def train_model():
    # モデル学習の処理
    pass

ステップ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アドレスからのみ許可する

シークレットは環境変数やハードコードではなく、シークレットマネージャーから取得します。

# 例: AWS Secrets Managerを使用したAPIキー管理
import boto3

def get_api_key():
    client = boto3.client('secretsmanager')
    response = client.get_secret_value(SecretId='ai-model-api-key')
    return response['SecretString']

# 環境変数やハードコードではなく、シークレットマネージャーから取得する

ステップ5: 監査ログの設定

記録すべきイベントは次のとおりです。

• 認証イベント: ログイン/ログアウト、認証失敗
• アクセスイベント: データへのアクセス、API呼び出し
• 変更イベント: 権限の変更、データの更新/削除
• モデルイベント: 学習、デプロイ、推論実行

ログは改ざんできない形式で保存し、SIEM（Security Information and Event Management）へ集約します。保存期間は法的要件に応じて設定します。

# 例: 詳細な監査ログ
import logging
from datetime import datetime

logger = logging.getLogger('ai_system_audit')

def log_access(user_id, resource, action, result):
    logger.info(
        "Event: ACCESS | User: %s | Resource: %s | Action: %s | "
        "Result: %s | Timestamp: %s | IP: %s",
        user_id, resource, action, result,
        datetime.now().isoformat(), request.remote_addr,
    )

ステップ6: 定期的な監査とテスト

• ユーザー権限が適切かを定期的にレビューし、未使用アカウントや過剰な権限を特定する
• ログを分析して異常なアクセスパターンを検出する
• ペネトレーションテストで権限エスカレーションやアクセス制御のバイパスを検証する

---

主要クラウドにおける権限管理

オンプレミスのローカルLLM基盤とハイブリッドで構成する場合でも、クラウド側のIAMは前提知識として押さえておく価値があります。

完全オンプレミス構成では、これらに相当する役割を、社内IdP（Keycloak等）・ベクトルDBのRLS・ネットワークセグメンテーションで自前構築することになります。

---

まとめ

社内AI基盤のアクセス制御は、データ保護とシステムの安全性を確保するうえで根幹となる要素です。RBAC・ABAC・PBACを適切に組み合わせ、最小権限・職務分離・定期レビュー・詳細な監査ログを実装することで、堅牢な権限管理体制を構築できます。

特にRAGや生成AIは、検索や推論を通じて広範なデータへ間接的に到達できてしまうため、通常のシステム以上に慎重な設計が求められます。アクセス制御を「アプリ層・データ層・ネットワーク層」で多層化し、継続的な監視と改善を回していくことが、安全なAI活用の前提となります。