ABACとは？属性ベースのアクセス制御に関する完全ガイド

ロールベースのアクセス制御（RBAC）は、ユーザーの役割に基づいてアクセスを判断する場合には有効です。しかし、要求されるデータ、環境、時間、場所、あるいは現在のセッション内での過去の操作などによって権限を細かく制御する必要がある場合、課題が生じます。

ABACは、アクセス要求のたびにより豊富な属性セットを評価します。主体（サブジェクト）、リソース、アクション、コンテキストを考慮した上で、アクセスの許可または拒否を決定します。そのため、従来のアクセス制御手法では対応できない動的なビジネス要件に対処する際に非常に有用です。

本ガイドでは、ABACの定義、仕組み、RBACとの比較、それぞれのモデルが適したケースについて説明します。また、TrueFoundryがどのように属性ベースのアクセス制御を活用し、AIエージェント、モデル呼び出し、MCPツールへのアクセスを大規模に管理しているかについても解説します。

RBAC Assigns permissions to Roles. ABAC Enforces Them Based on Real Context

TrueFoundry applies attribute-based access control at the gateway layer across every AI agent, model, and tool connection your teams run—evalutaing subject, resource, action, and environment.

Book a Demo

ABACとは？定義と意味

属性ベースのアクセス制御（ABAC）は、属性を評価してアクセスの許可・拒否を判断するアクセス制御モデルです。評価対象となる属性には、ユーザー、リソース、アクション、環境、デバイス、セッション、リスクスコア、あるいは要求に関連するビジネスコンテキストなどが含まれます。

ABACの意味は、RBACモデルと比較すると理解しやすくなります。RBACは「ユーザーが承認されたロールに属しているか」を問い、ABACは「属性の組み合わせがポリシーを満たしているか」を問います。

例えば、「ユーザーが財務部門に所属し、適切なセキュリティクリアランスを持ち、読み取りアクセスを要求し、かつ営業時間内に承認されたIPアドレスから接続している場合のみアクセスを許可する」といったポリシーを設定できます。条件が一つでも満たされない場合、アクセスは拒否されます。

これにより、ABACは複雑なビジネス要件に対応可能となります。現代の組織では、機密データ、業務プロセス、ERPシステム、患者記録、AIワークフローなど、ロールだけでは管理しきれないスマートなアクセス制限が求められています。

ABACモデルの主要コンポーネント

属性ベースのアクセス制御では、認可のために主に4つの属性カテゴリを使用します。それは、主体属性、リソース属性、アクション属性、環境属性です。これらを組み合わせることで、コンテキストに基づいた高度なアクセス判断が可能になります。

TrueFoundryは、ゲートウェイ層で属性ベースのアクセス制御を適用し、チームが実行するすべてのAIエージェント、モデル、ツール接続に対して、主体、リソース、アクション、環境を評価します。 

主体属性

主体属性は、アクセスを要求するエンティティを記述します。これには、部署、職務、地域、ユーザープロファイル、ビジネスユニット、認証ステータス、セキュリティクリアランス、あるいは要求を行う主体の属性などが含まれます。

AIシステムにおいては、主体属性にエージェントのID、アプリケーションのID、およびエージェントの背後にいる認証済みユーザーを含めることも可能です。これにより、すべてのAIエージェントを広範なアクセス権を持つ汎用サービスアカウントとして扱うリスクを回避できます。

リソース属性

リソース属性は、アクセス対象となる資産を記述します。例として、リソース所有者、データ分類、モデル階層、ツールカテゴリ、環境、機密レベル、データセキュリティラベル、本番環境またはステージング環境のステータスなどが挙げられます。

これらの属性は、機密データを保護し、データ保護を強化するのに役立ちます。例えば、ヘルスケア関連のポリシーにおいて、サポート担当者には内部の患者記録の読み取りを許可しつつ、請求システムへの書き込みや臨床記録の更新をブロックするといった制御が可能です。

アクション属性

アクション属性は、要求された操作を定義します。一般的な例として、読み取り、書き込み、削除、呼び出し、要約、生成、実行、エクスポート、承認、変更などが挙げられます。これらのアクションは、ユーザーの役割とは独立して許可または拒否することができます。

AIエージェントにとってこれが重要なのは、同じツールであっても安全なアクションとリスクを伴うアクションの両方をサポートする場合があるためです。例えば、エージェントがCRMレコードを要約するのは安全であっても、顧客データを更新する際には、より強力な承認が必要になる可能性があります。

環境属性

環境属性は、リクエストを取り巻く状況を記述します。これには、時刻、場所、IPアドレス、デバイスの状態、リスクスコア、セッションの動作、認証方法、環境条件などが含まれます。

環境条件により、アクセス制御ポリシーはより適応性の高いものになります。信頼できるオフィス内のデバイスからの営業時間内のリクエストは許可されるかもしれませんが、管理外のデバイスからの営業時間外のリクエストであれば、拒否または追加の認証（ステップアップ認証）が必要になる場合があります。

ABACの仕組み：ポリシーと決定プロセス

属性ベースのアクセス制御（ABAC）は、ポリシー主導型のセキュリティアプローチです。属性を収集し、ABACポリシーに基づいて評価を行い、ユーザーやシステムが保護されたリソースに到達する前に最終的な決定を強制します。

このプロセスは通常、ポリシー管理ポイントから始まります。システム管理者は、どの属性の組み合わせが許可されるかを記述するルールを定義します。これらのルールは、Extensible Access Control Markup Language（XACML）などのポリシー言語で表現されることがあります。

ポリシーエンジンは、リクエストをリアルタイムで評価します。決定を下す前に、LDAP（Lightweight Directory Access Protocol）ディレクトリからのID情報、デバイス信号、リソースのメタデータ、セッションコンテキスト、セキュリティポリシーなどをチェックします。

ポリシー適用ポイントは、保護されたリソースに到達する前にその結果を適用します。エンタープライズAIシステムにおいて、 AIゲートウェイ は、モデルの呼び出しやツールの実行を事前に制御できるため、有用な適用レイヤーとなります。

エンタープライズAIアクセス制御におけるABACのベストプラクティス

企業はABACを単なるポリシー構文としてではなく、ガバナンスモデルとして扱うべきです。その目的は、ユーザー、エージェント、ツール、ビジネスユニットの数が増加しても、理解しやすく、適用可能で、監査可能かつ管理しやすいルールを作成することです。

• 価値の高いユースケースから始める： すべてのリソースを網羅する前に、機密データ、財務ワークフロー、患者記録、特権ツール、本番環境のAIエージェントに焦点を当ててください。
• ポリシーを理解しやすく保つ： セキュリティチーム、法務チーム、プラットフォームチームがレビューできる条件を記述してください。過度に複雑なブール論理は、長期的なポリシー管理を弱体化させる可能性があります。
• 属性管理を標準化する： ID属性、リソースラベル、ツール分類、環境条件の所有者を定義してください。属性の品質が低いと、あらゆる決定の信頼性が低下します。
• ロールベースの基盤と組み合わせる： RBACを使用して広範なグループ分けを行い、属性チェックでコンテキストを判断します。これにより、シンプルさと詳細なアクセス制御のバランスが保たれます。
• すべての決定を明確にログ記録する： 主体、リソース、アクション、環境、ポリシーの一致、最終的な決定を記録します。これらのログは、セキュリティレビューや調査の際に役立ちます。
• 適用前にポリシーをテストする： ユーザー、エージェント、ツール全体で想定されるアクセス決定をシミュレーションします。これにより、ポリシーの精度が向上し、正当な業務を誤ってブロックするリスクが軽減されます。

これらのベストプラクティスはAI以外にも適用可能です。Webプラットフォームでは、サイトの一部、Cookieの種類、エンドユーザー、同意状態、デバイスコンテキストなどに属性を使用できます。エンタープライズシステムでも、データセキュリティやアクセス管理に同様のロジックが活用されています。

ABACとRBAC：主な違いと使い分け

RBACと属性ベースのアクセス制御（ABAC）は、どちらも組織のアクセス管理に役立ちます。違いは、アクセスを許可するかどうかの判断方法にあります。RBACは「ロール（役割）」を使用しますが、ABACはリクエスト時に幅広い属性セットを評価します。

権限がロールと明確に一致する場合、RBACの方が管理は容易です。例えば、財務マネージャーには特定の財務アプリケーションへのアクセス権が必要といったケースです。一方、データの機密性、場所、デバイス、アクション、セッションコンテキストなどに応じてアクセスを制御する場合、属性ベースの制御の方が強力です。

ロール管理と属性チェックの両方が重要な場合、一部の企業ではARBAC（属性ベースのロール管理）というハイブリッドアプローチを採用しています。これにより、チームはシンプルなユーザーロールを維持しつつ、機密性の高いリソース、ツール、モデル、ワークフローに対してより詳細な制御を追加できます。

裁量アクセス制御と比較して、属性ベースのモデルは中央のセキュリティチームに一貫したポリシー運用をもたらします。また、静的なアクセス制御ポリシーと比較しても、アプリケーション、ツール、チームを横断する動的な業務において、より適応性の高いユーザーエクスペリエンスを実現します。

エンタープライズAIシステムでABACが重要な理由

人間の従業員は通常、組織内で定義された役割に従って行動します。一方、AIエージェントはタスク、プロンプト、ツール、コンテキストに基づいて動作します。この違いにより、多くのエージェント型AIのユースケースでは、静的なロールだけでは不十分となります。

例えば、カスタマーサポートのAIエージェントがサービスワークフロー中にCRMレコードを読み取ることはあっても、リクエスター、アクション、リソース、コンテキストが承認されたポリシーを満たさない限り、機密性の高い請求レコードを修正させるべきではありません。

ABACがない場合、組織は通常、2つの不十分な選択肢に直面します。AIエージェントに過剰な権限を与えてセキュリティリスクを高めるか、あるいはエージェントを厳しく制限しすぎて、多くの有用なワークフローで手動の例外処理や運用上の遅延が発生するかのいずれかです。

属性ベースの制御により、チームはタスクに合わせてアクセス権を調整できます。ある状況では読み取り専用の顧客アクセスを承認し、別の状況では書き込みを拒否し、機密データやリスクの高いツールが関与する場合にはより厳格なチェックを適用するといった運用が可能です。

これは、AIエージェントがModel Context Protocol（MCP）と連携するようになるにつれて重要になります。ツールが内部システム、ドキュメント、データベース、チケット管理プラットフォームにアクセスできるようになるためです。 MCP Gateway レイヤーは、それらのツール呼び出しにコンテキストに応じた認可が必要な場合に重要となります。

Static Role Assignments Cannot Govern. Dynamic AI Agent Behavior at Scale.

Create your TrueFounday account and apply attribute-based access control to every AI agent, model, and tool connection from one government gateway—-RBAC plus full ABAC contact enforcement.

Create Account

TrueFoundryはエンタープライズAIガバナンスにABACをどのように適用しているか

TrueFoundry は、属性ベースのアクセス制御（ABAC）の概念を本番環境のAIガバナンスに適用します。これにより、企業はゲートウェイ層で適用されるコンテキストに応じたポリシーを通じて、モデル、ツール、AIエージェントへのアクセスを管理できるようになります。

サブジェクト属性は、企業のIDプロバイダーから取得可能です。TrueFoundryはOAuth 2.0のIDインジェクションを利用できるため、すべてのエージェントの操作をリクエスト元のIDや組織属性と紐付けることができます。これにより、共有サービスアカウントのみに依存するリスクを回避します。

リソースおよびアクションの属性は、モデル層とツール層で適用可能です。TrueFoundryの MCPゲートウェイ は、特定のエンタープライズツールに対する読み取り専用や読み書き両方のアクセス権など、モデルごと、ツールごとのポリシーを適用できます。

環境属性は、ワークフローレベルの制御を通じて評価されます。エージェントゲートウェイは、セッションコンテキスト、実行時の動作、コストしきい値、ワークフローの状態、およびエージェント型AIシステムの承認済み実行境界を管理するのに役立ちます。

この LLMゲートウェイ は、モデルへのアクセス、ルーティング、プロバイダーの抽象化、レート制限、コストの可視化を管理します。これらの制御を組み合わせることで、企業はモデル呼び出し、MCPツールのアクション、またはエージェントワークフローが実行される前にポリシーを適用できます。

ポリシーの決定内容は、関連する属性、適用されたポリシー、および決定結果とともにログに記録されます。これらの監査ログは顧客のVPC内に保持できるため、SOC 2、HIPAA、および社内のコンプライアンス審査プロセスのサポートに役立ちます。

ABACは、企業がコンテキストに基づいてアクセスを決定するのに役立ちます。TrueFoundryは、AIエージェントがモデルを呼び出したり、MCPツールにアクセスしたり、エンタープライズシステム上で動作したりする前に、それらの決定を強制するサポートをします。

デモを予約する ことで、TrueFoundryがモデル、ツール、エージェント、予算、監査ログ全体にわたって、IDを認識したABACポリシーをどのように適用しているかをご確認いただけます。