第12章 — アクセス制御とアイデンティティ

『LLM Primer VII: AIセキュリティ』を章ごとに紹介していくウォークスルー、第12回。合成的な問いに答える章 — LLM統合アプリケーションのどのcapabilityを誰が呼び出してよいか、その強制がシステムのコンポーネント間でどう構造化されるか。

なぜこの章があるのか

伝統的なアクセス制御の規律はLLMシステムにもすべて当てはまる。プリンシパルを認証し、リクエストをポリシーに対して認可し、テナントを分離し、プリンシパルごとに消費を有界化し、エンタープライズガバナンスのオーバーレイを露出する。仕組みはこの分野が何十年も使ってきたもの — OAuth 2.0、mTLS、RBAC、ABAC、トークンバケット、SAML、SCIM — だ。新しいのは、モデル呼び出しそのものがプリンシパルになりうる点 — ユーザの代理で動くエージェントは自身のアイデンティティと権限を運ぶ — と、モデル挙動のテナントごと設定がマルチテナントLLMプラットフォームにおいて一級のプロダクト機能である点だ。

ひとことで言うと: LLMシステムのアクセス制御は、伝統的な規律にひとつ追加が加わったもの — ツールを介して動くとき、モデル自身がプリンシパルとなり、その権限は侵害されたプロンプトがそれを行使しきれない程度に狭くスコープされていなければならない。

12.1 認証と認可は転用でき、加えるべきものがある

認証は資格情報を検証する。APIキーは最も単純な仕組みだ — 高エントロピーの文字列がプロビジョニング時にプリンシパルに渡され、資格情報データベースにハッシュ化されて保存され、リクエストごとにヘッダで提示される。実装も使用も容易だが、ログ、CI出力、コミットされたリポジトリを通じて漏れやすい。OAuth 2.0のベアラトークンは短命トークンとスコープ制限で状況を改善する。OAuth 2.1ドラフトは過去10年のセキュリティのベストプラクティスを統合している。mTLSは機械間通信に相互認証を加え、内部LLMサービスに特に有用だ。認可は、認証済みのプリンシパルが何を行ってよいかを問う。RBAC — ロール、権限、割当 — は集団が安定したグループに分かれる場合に機能する。ABAC — 属性ベースのアクセス制御 — は、プリンシパル、リソース、コンテキストの属性に対する述語を評価し、RBACが扱えない場合を扱う。リソースの所有者、リクエストの時刻や場所、システム内の関係に依存する権限などだ。両者は排他ではない。本番システムはしばしば重ねて使い、粗い粒度のアクセスにはRBAC、具体的な条件にはABACを使う。第10章のポリシーエンジン — OPA、Cedar — が、ABACをスケールで保守可能にする方法だ。

12.2 マルチテナント分離は防御の深さの問題である

マルチテナントシステムは単一のデプロイから複数の顧客に提供する。分離の要件は、どのような障害モードでもテナントが他テナントのデータ、リクエスト、モデルとのやりとりを見られないことだ。3つのアーキテクチャアプローチがスペクトル上に並ぶ。データベースレベルの分離 — テナントごとに独立したデータベース — は最も強いが運用コストも最も高い。スキーマレベルの分離 — 共有インフラ上でテナントごとに独立したPostgreSQLスキーマまたはMySQLデータベース — は中間だ。行レベルの分離 — 共有スキーマ、各行にテナントID、データベース強制のRow-Level Security — は最も安いが、規律あるアプリケーションコードを要求する。LLMシステムでは分離が検索コーパス(テナントごとのベクタデータベース名前空間)、プロンプト組み立てロジック(テナント間の連結禁止)、ログストア(テナント間読み取り禁止)、テナント固有データでファインチューニングされる場合のモデル自身にまで及ぶ。レート制限とクォータはリソース消費軸を加える。トークンバケットは定義された容量まで短時間のバーストを許す。スライディングウィンドウはより均一なレートを、より高い計算コストで強制する。リーキーバケットは下流のレートを平滑化する。LLMシステムではレート制限の次元が拡張する。秒あたりリクエスト、分あたりトークン、日あたりコスト、時間あたりツール呼び出し、秒あたり埋め込み。各次元には固有の経済的・セキュリティ的な正当化があり、エンタープライズ層は通常、複数の軸で差別化する。

12.3 エンタープライズガバナンスはシステムを使えるものにするオーバーレイである

エンタープライズの顧客は認証とレート制限を超えたガバナンス要件を持つ。どの従業員がシステムを、どのデータで、どの目的で使っているかを知る必要がある。社内コンプライアンスと外部監査に十分な監査ログが必要だ。どのモデルが許可されるか、どのツールが使えるか、どの内容カテゴリが許されるかの統制も必要だ。データ取り扱いに関する約束 — 学習利用、暗号化、所在、保持、削除 — も必要となる。標準となっている機能はこれらの要件を反映している。SAMLまたはOpenID Connectによるシングルサインオンは、エンタープライズのアイデンティティプロバイダをシステム利用者の真の源とする。SCIMプロビジョニングはユーザ変更を自動伝播する。監査ログのエクスポートはLLMシステムのテレメトリをエンタープライズSIEMへ送る。データ所在の約束はテナントのデータが指定された管轄区域を出ないことを保証する。顧客管理の暗号鍵はエンタープライズがプロバイダから独立してローテーションや失効を行うことを可能にする。プライベートデプロイ選択肢はLLMサービスをエンタープライズ自身のクラウドアカウントへ移す。これらの機能は実装するだけでなく運用しなければならないガバナンス面で、エンタープライズガバナンスのオーバーレイこそが、マルチテナントLLMプラットフォームを規制業界が採用できるものに変える。

覚えておきたいこと: モデルが呼び出せる全てのツールは、そのユーザが直接呼び出したかのように認可されるべきだ — 呼び出し元のアイデンティティで、呼び出し元のテナントの中で、呼び出し元のレート制限に従って。それ以外は、モデルが代理しているプリンシパルを超える権限をモデルに与えることになり、多くのエージェントアーキテクチャが偶発的に組み込んでしまう失敗モードそのものだ。

第12章が敷いたもの

第IV部はLLMセキュリティのシステムレベルの次元を展開してきた。アーキテクチャの境界(第10章)、可観測性とインシデントレスポンス(第11章)、アイデンティティとアクセス制御(第12章)である。扱いは仕組み優先で、守り抜ける技術的姿勢を与える。第13章は第V部を、技術の核から外側へ、規制の境界へと踏み出して開く。2026年8月から大半の高リスクカテゴリに全面適用されるEU AI Actは、単独では最も帰結の大きい規範だが、米国連邦の姿勢(EO 14110からEO 14179への移行後に進化中)、州法(コロラド、カリフォルニア、ニューヨーク市、その他)、AIに適用されるGDPR、そしてシンガポール、日本、韓国、インドなどで台頭する枠組みが合わさって、コンプライアンス面は統一ではなく複数となる。この章は、これらの規制が実務上何を要求し、第3章、第10章、第11章、第12章の統制がそれらの要求にどう対応するかを検討する。

次回 — 第13章: 規制の状況。EU AI Actの段階的適用、AIシステムに対するGDPR、監査可能性、モデルカード、そして規制アーキテクチャを構造化するリスク分類の枠組み。

全体像を掴みたい方へ: 書籍の該当章には、OAuthとmTLSのセットアップの実例、本番例を伴う完全なRBAC対ABAC判断マトリクス、ストレージ層をまたぐテナント分離のパターン、そして本記事では要約にとどめた「In Plain English」サイドバーが収録されている。Amazonで『LLM Primer VII』を見る →