属性ベースのアクセス制御 (ABAC) とは?
ABAC は、属性を使用してアクセス制御の決定を行う アクセス制御 (Access control) モデルです。これらの属性には、以下のようなさまざまな要因が含まれることがあります:
- ユーザー属性: 例、ロール、部署、場所など。
- リソース属性: 例、機密性レベル、所有者、タイプなど。
- 環境属性: 例、アクセス時間、場所、デバイスなど。
これらの属性を評価して一連のルールに通すことで、ABAC は主体(例、ユーザー、サービス)がリソースへのアクセス権を付与されるべきかを判断します。このアプローチは、コンテキストに基づく詳細なアクセス制御と動的なポリシー強制を可能にします。
ABAC はどのように機能するのか?
ABAC は、ポリシーベースのアプローチによってアクセス制御を行います。典型的な ABAC ポリシーは、以下で構成されます:
- 主体: アクセスを要求するエンティティ(例、ユーザー、サービス、デバイス)。
- アクション: リソースに対して行われる操作(例、読み取り、書き込み、削除)。
- リソース: アクセスされるエンティティ(例、ファイル、データベース、API)。
- 環境: アクセスが要求されるコンテキスト(例、時間、場所、デバイス)。
- 属性: アクセスの決定を行うために評価される主体、リソース、および環境のプロパティ。
- ポリシー: アクセスが許可または拒否される条件を定義する一連のルール。
ABAC ポリシーは、従来のアクセス制御モデルである ロールベースのアクセス制御 (RBAC) などよりも複雑です。一方、ABAC はアクセス制御の決定において、より柔軟で詳細な選択を提供します。
ABAC ポリシーの例
例えば、システムにはいくつかの ABAC ポリシーがあります:
-
ポリシー 1: 以下の場合にアクセスを許可:
- (主体) 主体のロールが
manager
。 - (属性) リソースの機密性レベルが
high
。 - (環境) 場所が
internal
。 - (アクション) どんなアクションでも。
- (環境) 時間が 9 AM から 5 PM (営業時間) の間である。
- (主体) 主体のロールが
-
ポリシー 2: 以下の場合にアクセスを拒否:
- (主体) 主体のロールが
manager
ではない。 - (属性) リソースの機密性レベルが
high
。 - (環境) どんな場所でも。
- (アクション) どんなアクションでも。
- (環境) どんな時間でも。
- (主体) 主体のロールが
-
ポリシー 3: 以下の場合にアクセスを許可:
- (主体) 主体のロールが
employee
またはmanager
。 - (属性) リソースの機密性レベルが
low
。 - (環境) どんな場所でも。
- (アクション)
read
アクション。 - (環境) どんな時間でも。
- (主体) 主体のロールが
ポリシー評価エンジンはこれらのポリシーを順にチェックし、条件に一致する最初のポリシーがアクセスの決定を下します。一方、他のポリシーが一致しない場合は、デフォルトで拒否ポリシーが施行されます。
シナリオを通して ABAC の動作を理解しましょう:
シナリオ 1. ユーザーがオフィス外(環境)で高機密性レベルのドキュメント(リソース)にアクセス(
read
アクションを実行)したいと考えています。ユーザーはmanager
のロールをシステムに保存しています。
決定: アクセスは拒否されます。なぜなら、ユーザーはオフィスの外にいるからです(場所が internal
ではない)。
シナリオ 2. ユーザーがオフィス時間中(環境)にオフィスネットワーク(場所=
internal
)で高機密性レベルのドキュメント(リソース)にアクセス(read
アクションを実行)したいと考えています。ユーザーはmanager
のロールを持っています。
決定: アクセスは許可されます。なぜなら、ポリシー 1 のすべての条件が満たされているからです。
シナリオ 3. シナリオ 2 のすべての条件が同じですが、ユーザーが
manager
ではなくemployee
のロールを持っています。
決定: アクセスは拒否されます。なぜなら、ユーザーのロールがポリシー 1 の条件に一致しないからです。
シナリオ 4. ユーザーが低機密性レベルのドキュメント(リソース)にアクセス(
read
アクションを実行)したいと考えています。ユーザーはemployee
のロールを持っています。
決定: アクセスは許可されます。なぜなら、ポリシー 3 のすべての条件が満たされているからです。
シナリオ 5. ユーザーが低機密性レベルのドキュメント(リソース)を削除(
delete
アクションを実行)したいと考えています。ユーザーはemployee
のロールを持っています。
決定: アクセスは拒否されます。なぜなら、低機密性レベルのドキュメントで delete
アクションを許可するポリシーがないからです。
すべてのポリシーで必要な属性が要求されるわけではないことに注意してください。この柔軟性により、より動的でコンテキストに基づいたアクセス制御メカニズムが可能になります。
拡張アクセス制御マークアップ言語 (XACML)
XACMLは、アクセス制御ポリシーを表現するためのXMLベースの標準です。特定のアクセス制御モデルを定義しているわけではありませんが、XACMLはABACポリシーの実装によく使用されます。前の例のABACポリシーを表現するために、XACMLがどのように使用できるかの非標準の例を見てみましょう:
<PolicySet PolicySetId="ABAC_Policies" PolicyCombiningAlgId="urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-overrides">
<Description>ABAC Policies</Description>
<Policy PolicyId="Policy1" RuleCombiningAlgId="urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-overrides">
<Description>Employees can read data</Description>
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
<AttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true"
/>
</Match>
</AllOf>
</AnyOf>
</Target>
<Rule RuleId="Rule1" Effect="Permit">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">employee</AttributeValue>
<AttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true"
/>
</Match>
</AllOf>
</AnyOf>
</Target>
</Rule>
<Rule RuleId="Rule2" Effect="Deny">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">user</AttributeValue>
<AttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true"
/>
</Match>
</AllOf>
</AnyOf>
</Target>
</Rule>
</Policy>
<!-- ...other policies... -->
</PolicySet>
XACMLの詳細については、 eXtensible Access Control Markup Language (XACML) をご参照ください。
実装の考慮事項
ABAC は強力なアクセス制御管理方法を提供しますが、いくつかの実装上の考慮事項も伴います:
- システムの複雑性: 属性とルールの数が増えるにつれて、ABAC ポリシーは複雑になる可能性があります。適切なポリシー管理とテストは、より単純なアクセス制御モデルよりも時間がかかります。
- パフォーマンス: 複雑な ABAC ポリシーの評価はシステムパフォーマンスに影響を与える可能性があります。キャッシングと最適化技術はこの問題を軽減するのに役立ちます。
- ポリシーの競合: 競合するポリシーは予測不可能なアクセス決定をもたらす可能性があります。定期的なポリシーレビューと競合解決がポリシー管理プロセスの一部であるべきです。
ABAC と RBAC
ロールベースのアクセス制御 (RBAC) と ABAC を比較すると、両者のモデルの違いを理解するのに役立ちます:
RBAC | ABAC | |
---|---|---|
アクセス制御ポリシー | ロールに基づく | 属性に基づく |
粒度 | 粗い | 細かい |
柔軟性 | 制限付き | 非常に柔軟 |
複雑さ | シンプル | より複雑 |
パフォーマンスへの影響 | 最小 | 影響が大きい可能性あり |
アクセス管理 | ロール管理 | ポリシー管理 |
適している状況 | 明確に定義された許可構造 | 動的でコンテキストに基づいたアクセス制御 |