認可・アクセス制御

ABAC（属性ベースアクセス制御）えーびーえーしー

アクセス制御属性ポリシーRBACXACML認可

ABACについて教えて

簡単に言うとこんな感じ！

ABACは「属性」を使ってアクセスを細かくコントロールする仕組みだよ。「誰が・何に・どんな状況で」アクセスしていいかを、役職だけじゃなく部署・時間帯・場所なんかも組み合わせて判断するってこと！

ABACとは

ABAC（Attribute-Based Access Control／属性ベースアクセス制御）とは、ユーザー・リソース・環境などが持つ「属性（Attribute）」を組み合わせたポリシーによって、アクセス権を動的に判断するアクセス制御モデルです。たとえば「部署が経理で、勤務時間内で、社内ネットワークからアクセスしている場合のみ経費データを閲覧可」のように、複数条件を組み合わせたきめ細かな制御が可能です。

従来のRBAC（ロールベースアクセス制御）が「この役職の人はこのリソースにアクセスできる」という固定的なルールだったのに対し、ABACは「誰が・何に・どんな状況で」という多次元の属性を掛け合わせることで、より柔軟で精密なポリシーを実現します。ゼロトラストセキュリティの考え方とも親和性が高く、クラウド時代の認可モデルとして注目されています。

ABACの仕組みと構成要素

ABACは4種類の「属性」と、それを評価する「ポリシーエンジン」で成り立っています。

属性の種類	英語	例
主体属性	Subject Attribute	ユーザーID・部署・役職・所属グループ
リソース属性	Resource Attribute	ファイルの機密レベル・データの種類・所有者
アクション属性	Action Attribute	読み取り・書き込み・削除・エクスポート
環境属性	Environment Attribute	アクセス時刻・場所・使用デバイス・IPアドレス

これらをポリシー（ルール）に組み合わせてアクセス可否を動的に判定します。

ポリシーの例（平文イメージ）

IF  主体.部署 = "経理"
AND 主体.雇用形態 = "正社員"
AND リソース.機密レベル <= "社外秘"
AND 環境.時刻 >= 09:00 AND 環境.時刻 <= 18:00
AND 環境.ネットワーク = "社内VPN"
THEN アクセス = 許可

覚え方：「4つのW」

Who（誰が）× What（何に）× How（どう）× When/Where（いつ・どこで）

この4つの「属性」を組み合わせて「Yes / No」を決めるのがABAC、と覚えると迷いません。

歴史と背景

1990年代：RBACが主流として普及。役職・グループによる固定的な権限管理が企業システムで広く採用される
2000年代前半：RBACでは「例外ルール」が増えすぎてポリシー管理が破綻するケースが増加
2004年：OASIS（標準化団体）が XACML（eXtensible Access Control Markup Language） 1.1を策定。属性ベースのポリシー記述言語として普及の足がかりになる
2013年：米国国立標準技術研究所（NIST）が ABACの定義・ガイドラインを公式文書 NIST SP 800-162 として公表し、政府・大企業での採用が加速
2010年代後半〜現在：クラウドサービス（AWS・Azure・GCP）がABAC対応のIAMポリシーを実装。ゼロトラストアーキテクチャとの統合が進む

RBAC vs ABAC：何が違う？

多くの組織はRBACからABACへの移行、またはハイブリッド運用を検討しています。

比較項目	RBAC	ABAC
制御の単位	ロール（役職・グループ）	属性の組み合わせ
柔軟性	低い（固定ルール）	高い（動的判定）
管理のしやすさ	シンプルで直感的	ポリシーが複雑になりやすい
例外対応	ロールを増やすしかない	属性条件で吸収できる
向いている規模	小〜中規模	中〜大規模・マルチクラウド
代表的な製品例	Active Directory	AWS IAM タグポリシー・Azure ABAC

規格・番号	内容
NIST SP 800-162	ABACの定義・概念・実装ガイドラインを示したNIST公式文書
XACML 3.0（OASIS）	ABACポリシーを記述するXMLベースの標準言語。ABAC実装の代表的な規格