属性ベースのアクセス制御 (Attribute-based access control, ABAC)

属性ベースのアクセス制御 (ABAC) とは？

ABAC は、属性を使用してアクセス制御の決定を行う アクセス制御 (Access control) モデルです。これらの属性には、以下のようなさまざまな要因が含まれることがあります:

• ユーザー属性: 例、ロール、部署、場所など。
• リソース属性: 例、機密性レベル、所有者、タイプなど。
• 環境属性: 例、アクセス時間、場所、デバイスなど。

これらの属性を評価して一連のルールに通すことで、ABAC は主体（例、ユーザー、サービス）がリソースへのアクセス権を付与されるべきかを判断します。このアプローチは、コンテキストに基づく詳細なアクセス制御と動的なポリシー強制を可能にします。

ABAC はどのように機能するのか？

ABAC は、ポリシーベースのアプローチによってアクセス制御を行います。典型的な ABAC ポリシーは、以下で構成されます:

• 主体: アクセスを要求するエンティティ（例、ユーザー、サービス、デバイス）。
• アクション: リソースに対して行われる操作（例、読み取り、書き込み、削除）。
• リソース: アクセスされるエンティティ（例、ファイル、データベース、API）。
• 環境: アクセスが要求されるコンテキスト（例、時間、場所、デバイス）。
• 属性: アクセスの決定を行うために評価される主体、リソース、および環境のプロパティ。
• ポリシー: アクセスが許可または拒否される条件を定義する一連のルール。

ABAC ポリシーは、従来のアクセス制御モデルである 役割ベースのアクセス制御 (Role-based access control, RBAC) などよりも複雑です。一方、ABAC はアクセス制御の決定において、より柔軟で詳細な選択を提供します。

ABAC ポリシーの例

例えば、システムにはいくつかの ABAC ポリシーがあります：

1. ポリシー 1: 以下の場合にアクセスを許可：

   • (主体) 主体のロールが manager。
   • (属性) リソースの機密性レベルが high。
   • (環境) 場所が internal。
   • (アクション) どんなアクションでも。
   • (環境) 時間が 9 AM から 5 PM (営業時間) の間である。

2. ポリシー 2: 以下の場合にアクセスを拒否：

   • (主体) 主体のロールが manager ではない。
   • (属性) リソースの機密性レベルが high。
   • (環境) どんな場所でも。
   • (アクション) どんなアクションでも。
   • (環境) どんな時間でも。

3. ポリシー 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

役割ベースのアクセス制御 (Role-based access control, RBAC) と ABAC を比較すると、両者のモデルの違いを理解するのに役立ちます：

	RBAC	ABAC
アクセス制御ポリシー	ロールに基づく	属性に基づく
粒度	粗い	細かい
柔軟性	制限付き	非常に柔軟
複雑さ	シンプル	より複雑
パフォーマンスへの影響	最小	影響が大きい可能性あり
アクセス管理	ロール管理	ポリシー管理
適している状況	明確に定義された許可構造	動的でコンテキストに基づいたアクセス制御

関連項目

• アクセス制御 (Access control)
• 役割ベースのアクセス制御 (Role-based access control, RBAC)
• 認可 (Authorization)