ABAC

ABAC（Attribute-Based Access Control：属性ベースアクセス制御）とは、ユーザー、リソース、アクション、環境の各属性を評価して、動的にアクセス制御の判断を行うセキュリティモデルです。従来のRBAC（ロールベース）が固定的なロール割り当てに依存するのに対し、ABACは多次元の属性に基づく柔軟なポリシー定義を可能にします。

たとえば、「東京オフィスに所属する（ユーザー属性）、正社員が（ユーザー属性）、勤務時間内に（環境属性）、機密レベルが中以下の（リソース属性）文書を、閲覧する（アクション属性）ことを許可する」というような、複合的な条件に基づくアクセス制御ルールを記述できます。

ABACの理論的基盤は、2014年にNISTがSP 800-162「Guide to Attribute Based Access Control (ABAC) Definition and Considerations」として体系化しました。クラウドコンピューティングの普及やマイクロサービスアーキテクチャの台頭により、従来のRBACだけでは対応しきれない複雑なアクセス制御要件が増加しており、ABACの重要性が高まっています。

AWS、Google Cloud、Microsoftなどの大手クラウドプロバイダーもABACの概念を取り入れたアクセス制御機能を提供しており、特にAWSはタグベースのアクセス制御（TBAC）としてABACの実装を積極的に推進しています。

ABACの4つの属性カテゴリ

• サブジェクト属性（Subject Attributes）：アクセスを要求する主体（ユーザー、プロセス、デバイス）の属性。役職、所属部門、セキュリティクリアランス、国籍、資格、認証方式などが含まれる。IDプロバイダーやHRシステムなどから動的に取得される。
• リソース属性（Resource Attributes）：アクセス対象のリソースの属性。機密レベル（Public/Internal/Confidential/Top Secret）、データ分類、作成者、所有部門、ファイル形式、作成日時などが含まれる。
• アクション属性（Action Attributes）：リソースに対して実行しようとする操作の属性。読み取り、書き込み、削除、実行、承認、転送などの操作種別と、その操作の影響範囲が含まれる。
• 環境属性（Environment Attributes）：アクセス要求が行われるコンテキストの属性。現在時刻、アクセス元のIPアドレス、ネットワーク（社内/VPN/外部）、デバイスのセキュリティ状態、脅威レベルなどの動的な条件が含まれる。

ABACのアーキテクチャ（XACML参照モデル）

• PEP（Policy Enforcement Point：ポリシー実施点）：アクセスリクエストを受け取り、PDPに認可判断を問い合わせ、その結果に基づいてアクセスを許可または拒否するコンポーネント。APIゲートウェイやリバースプロキシが担当することが多い。
• PDP（Policy Decision Point：ポリシー決定点）：ポリシーとリクエストの属性を評価し、アクセスの可否を判断する中核コンポーネント。Permit（許可）、Deny（拒否）、Not Applicable（該当なし）、Indeterminate（判定不能）のいずれかを返す。
• PAP（Policy Administration Point：ポリシー管理点）：ポリシーの作成、管理、配布を行う管理コンポーネント。セキュリティ管理者がポリシーを定義・編集するためのインターフェースを提供する。
• PIP（Policy Information Point：ポリシー情報点）：PDPがポリシー評価に必要な属性情報を外部データソース（LDAP、HR システム、CMDBなど）から取得するコンポーネント。

主要なポリシー言語

• XACML（eXtensible Access Control Markup Language）：OASISが策定したXMLベースのアクセス制御ポリシー言語。最も歴史のある標準だが、XMLの冗長性により記述が複雑。エンタープライズ環境や政府機関で採用されている。
• OPA/Rego（Open Policy Agent）：CNCFプロジェクトとして開発された汎用ポリシーエンジン。Regoというドメイン固有言語でポリシーを記述する。Kubernetes、Terraform、マイクロサービスなどのクラウドネイティブ環境で広く普及している。
• Cedar：AWSが2023年にオープンソースとして公開したポリシー言語。Amazon Verified PermissionsやAWS AVPで使用される。人間が読みやすい構文と高速なポリシー評価エンジンを特徴とし、形式検証による安全性保証を提供する。

ABAC vs RBAC

RBACは「ユーザーの役割（ロール）」に基づく比較的シンプルなモデルで、管理と理解が容易です。しかし、細かい粒度の制御にはロール数が爆発的に増加する「ロール爆発」の問題があります。ABACは多次元の属性を組み合わせた柔軟なポリシー記述が可能で、コンテキストに応じた動的な制御ができますが、ポリシー設計とテストの複雑さが課題です。

実際の運用では、RBACとABACを組み合わせたハイブリッドモデルが推奨されます。基本的なアクセス制御はRBACで実装し、より細かい粒度の制御や例外的なケースにABACを適用するアプローチです。

ABACの主要なユースケース

• 医療分野：患者データへのアクセスを、医療従事者の専門分野、患者との治療関係、アクセス時間帯、緊急度などの属性に基づいて細かく制御する。HIPAAコンプライアンスの実現に不可欠。
• 政府・防衛分野：セキュリティクリアランス、国籍、プロジェクト割り当て、情報分類レベルなどの属性に基づく多層的なアクセス制御。NISTの推奨モデルとして採用が進んでいる。
• マルチテナントSaaS：テナントID、サブスクリプションプラン、利用上限、機能フラグなどの属性に基づいて、テナントごとのリソース分離と機能制御を実現する。

• 01
  ポリシーのテストと形式検証を徹底する：ABACポリシーは複雑になりやすく、意図しないアクセス許可やアクセス拒否が発生するリスクがある。ポリシーの単体テスト、結合テスト、および可能であれば形式検証（Cedarの形式検証機能など）を実施し、ポリシーの正確性を保証する。
• 02
  属性情報ソースの信頼性を確保する：ABACの判断はPIPから取得する属性情報に依存するため、属性情報ソース（LDAP、HRシステム、CMDBなど）のデータ品質と整合性を維持する。属性情報の改ざんを防ぐため、情報ソースへのアクセス制御と監査ログを実装する。
• 03
  デフォルト拒否（Default Deny）ポリシーを採用する：明示的に許可されていないアクセスはすべて拒否する「デフォルト拒否」原則を採用する。ポリシーが該当しない場合や評価エラーが発生した場合は、安全側（拒否側）にフェイルオーバーする設計とする。
• 04
  ポリシー決定のパフォーマンスを最適化する：リアルタイムのアクセス制御判断にはミリ秒単位のレスポンスが求められる。ポリシー評価結果のキャッシュ、属性情報のプリフェッチ、ポリシーのインデックス化などにより、パフォーマンスを最適化する。キャッシュにはTTL（Time To Live）を設定し、古い判断結果の使用を防止する。
• 05
  ポリシーのバージョン管理と変更管理を実施する：ABACポリシーをGitなどのバージョン管理システムで管理し、変更履歴を追跡可能にする。ポリシーの変更はコードレビューを経て本番環境に反映し、ロールバック手順を整備する。CI/CDパイプラインにポリシーのテストを組み込む。
• 06
  アクセス制御の判断ログを記録・分析する：すべてのポリシー評価の結果（許可・拒否・エラー）、使用された属性、評価にかかった時間を監査ログに記録する。拒否されたアクセスのパターンを分析し、ポリシーの改善やセキュリティインシデントの早期検知に活用する。