RBAC と ABAC: 知っておくべきアクセス制御モデル

イントロダクション#

アクセス制御 は、どのシステムにおいてもセキュリティの重要な側面です。許可されたユーザーのみがリソースにアクセスして操作を行うことを保証します。役割ベースのアクセス制御 (RBAC) と属性ベースのアクセス制御 (ABAC) は、現代のシステムで広く使用されている 2 つのアクセス制御モデルです。両方のモデルは広く採用されており、アクセス制御ポリシーを効果的に実施するために使用できます。しかし、それらは何であり、どのように異なるのでしょうか？

役割ベースのアクセス制御 (RBAC)#

役割ベースのアクセス制御 (RBAC) は、1990 年代初頭に初めて導入されました。このモデルの形式化は、1992 年に発表された論文で David Ferraiolo と Rick Kuhn によって推進されました。それ以来、RBAC は業界で最も広く使用されているアクセス制御モデルの 1 つになりました。

RBAC では、アクセス制御ポリシーは許可のコレクションである役割に基づいています。ユーザーは役割（例: 管理者、編集者、閲覧者）を割り当てられ、彼らのアクセス権は特定のリソース（例: ファイル、データベース、アプリケーション）に対する許可（例: 作成、編集、削除）によって決まります。ユーザーを役割に基づいてグループ化し、役割に許可を割り当てることによって、アクセス制御ポリシーの管理を簡素化します。役割からユーザーを追加または削除することは簡単であり、その変更は自動的にアクセス制御ポリシーに反映されます。

RBAC の主要構成要素#

• リソース: リソースは、ユーザーがアクセスできるエンティティです。リソースはファイル、データベース、API、または保護する必要がある他のシステムエンティティのいずれかである場合があります。
• 許可: 許可は、ユーザーがリソースに対して実行できる特定のアクションです。例えば、作成、編集、削除、表示。許可の定義はシステムによって異なる場合があります。ほとんどの場合、許可は最小粒度でリソースのレベルで定義されます。
• 役割: 役割は、ユーザーが実行できる一連のアクションを定義する許可のコレクションです。たとえば、管理者の役割には、リソースの作成、編集、削除の許可を持つ場合がありますが、閲覧者の役割にはリソースを表示する許可が含まれる場合があります。
• ユーザー: ユーザーは、1 つまたは複数の役割を割り当てられることができるエンティティです。ユーザーは、割り当てられた役割に関連付けられた許可に基づいてリソースにアクセスします。

RBAC のバリアント#

基本モデルを拡張して、より複雑なアクセス制御要件に対応するいくつかの RBAC バリアントがあります:

• RBAC0: ユーザーが役割に割り当てられ、役割が許可に割り当てられる基本モデルです。
• RBAC1: 役割階層の概念を追加します。役割は他の役割から許可を継承できます。階層型 RBAC とも呼ばれます。
• RBAC2: 役割に制約を追加します。制約を使用して、ユーザーが役割に割り当てられるために満たさなければならない追加の条件を定義できます。制約ベースの RBAC とも呼ばれます。
• RBAC3: RBAC1 と RBAC2 の機能を組み合わせています。役割階層と制約の両方をサポートします。

これらのバリアントの詳細については、RBAC モデルとその進化を参照してください。

RBAC の利点#

• 単純性: RBAC は理解と実装が簡単です。許可を役割に割り当て、役割をユーザーに割り当てることは簡単です。
• 効率: RBAC は、ユーザーを役割に基づいてグループ化することによって、アクセス制御ポリシーの管理を簡素化します。アクセス制御ポリシーを変更せずに、役割からユーザーを追加または削除するのは簡単です。特に許可構造が明確な大規模組織では、RBAC は非常に効率的です。
• 透明性: RBAC は、役割、許可、ユーザー間の明確なマッピングを提供します。アクセス制御ポリシーの監査とレビューが容易です。

RBAC の短所#

• 硬直性: RBAC は複雑なアクセス制御ポリシーを定義する際に硬直性を持つことがあります。アクセス制御ポリシーがより動的でコンテキストに依存するシステムには適していない場合があります。
• 粒度: RBAC は、細かいアクセス制御に必要な粒度を欠く場合があります。アクセス制御ポリシーは既定の役割に結び付けられており、より細かいレベルで許可を定義するには余分な労力が必要になる場合があります。
• 役割の爆発: 複雑な許可構造を持つ大規模組織では、役割の数が指数的に増加し、役割の爆発につながることがあります。多数の役割を管理するのは困難です。

属性ベースのアクセス制御 (ABAC)#

2000 年代後半にシステムがより複雑かつ動的になるにつれて、ますます多くの組織が 属性ベースのアクセス制御 (ABAC) を RBAC の代替として採用し始めました。ABAC の形式化の注目すべき一里塚は、2014 年に発行された NIST Special Publication 800-162 です。

ABAC は RBAC よりも柔軟なアクセス制御モデルです。ユーザー、リソース、アクション、環境の属性に基づいてアクセス制御ポリシーを定義する承認モデルです。ABAC を使用すると、組織はさまざまなコンテキストと条件に適応できるきめ細かいアクセス制御ポリシーを定義できます。

ABAC の主要構成要素#

• 主体: 主体は、リソースへのアクセスを要求するエンティティです。ユーザー、デバイス、アプリケーション、またはリソースへアクセスする必要があるその他のエンティティである場合があります。
• リソース: RBAC と同様に、リソースは主体がアクセスできるエンティティです。リソースはファイル、データベース、API、またはその他のシステムエンティティである場合があります。
• アクション: アクションは、主体がリソースに対して実行できる特定の操作です。それは、作成、読み取り、更新、削除、または制御が必要なその他の操作である場合があります。
• 環境: 環境は、アクセス要求が行われるコンテキストです。時間、場所、ネットワーク、デバイスなどの属性を含む場合があります。
• 属性: 属性は、主体、リソース、アクション、環境の特徴です。ユーザーの役割、部門、場所、IP アドレス、デバイスタイプなどの属性である場合があります。
• ポリシー: ポリシーは、アクセスが許可または拒否される条件を定義する規則です。ポリシーは属性に基づいて定義されます。

ABAC の利点#

• 柔軟性: ABAC は、複雑なアクセス制御ポリシーを複数の属性に基づいて適応できます。さまざまなコンテキストと条件に適応できるきめ細かいポリシーを組織が定義できるようにします。
• 動的: ABAC ポリシーは動的かつコンテキスト依存です。アクセス制御の決定は、場所、時間、デバイスタイプなどのリアルタイムの属性に基づいて行うことができます。
• 粒度: ABAC は、複数の属性に基づいてポリシーを定義することで、きめ細かいアクセス制御を提供します。役割と許可を定義するのではなく、属性ベースのポリシーはより細かいものであることができます。

ABAC の短所#

• 複雑性: ABAC は、RBAC と比較して実装と管理がより複雑です。属性とポリシーの定義には、より多くの努力と専門知識が必要な場合があります。RBAC の場合は役割と許可がしっかり構築されていますが、属性はより動的で、ポリシーも同様です。複雑なシステムでは、多数の属性とポリシーを管理するのは困難です。ポリシーを評価するための集中管理されたポリシー評価エンジンが必要になることがあります。
• パフォーマンス: 属性の評価は、特にリアルタイム環境においてパフォーマンスに影響を与える可能性があります。複数の属性とリアルタイムの条件に基づいたポリシーは、アクセス制御の決定に遅延を引き起こすことがあります。

比較表#

この比較表から明らかなように、RBAC は許可構造が明確に定義されており、アクセス制御ポリシーが比較的静的であるシステムに最適です。一方で、ABAC はアクセス制御ポリシーが動的で、コンテキスト依存で、細かい粒度が必要なシステムにより適しています。

例#

シナリオ: 病院システムで異なるスタッフメンバーが患者記録へのアクセスを管理する必要があります。

• スタッフ: 医者、看護師、管理者
• リソース: 患者記録
• 許可: 読み取り、書き込み、削除

ケース 1#

アクセス制御ポリシーが比較的単純な場合:

1. 医者は患者記録を読み取りおよび書き込みできます。
2. 看護師は患者記録を読み取りできます。
3. 管理者は患者記録を読み取り、書き込み、削除できます。

RBAC モデル#

この場合、RBAC は単純で効果的です。医者、看護師、管理者の役割を定義し、それぞれの役割に適切な許可を割り当てます。

アクセス制御の評価は簡単です:

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')

ABAC モデル#

この場合、ABAC は過剰かもしれませんが、部門、役割などの属性に基づいて詳細なポリシーを定義するために使用することもできます。

属性:

• user.role: doctor, nurse, admin
• resource.name: patient-record
• action: read, write, delete

ポリシー:

• ポリシー 1: ユーザーの役割とリソースの名前に基づいて読み取りアクセスを許可
  • subject: 役割が doctor, nurse, admin のユーザー
  • resource: 名前が patient-record のリソース
  • action: read
  • effect: 許可
  • rationale: "すべての役割に患者記録の読み取りアクセスを許可する"
• ポリシー 2: 医者と管理者のための編集アクセス
  • subject: 役割が doctor, admin のユーザー
  • resource: 名前が patient-record のリソース
  • action: write
  • effect: 許可
  • rationale: "医者と管理者に患者記録の書き込みアクセスを許可する"
• ポリシー 3: 管理者のための削除アクセス
  • subject: 役割が admin のユーザー
  • resource: 名前が patient-record のリソース
  • action: delete
  • effect: 許可
  • rationale: "管理者に患者記録の削除アクセスを許可する"

各読み取り/書き込み/削除要求に、ポリシーエンジンが属性に基づいてすべての関連ポリシーを評価し、アクセス制御の決定を行います。

比較#

この場合、アクセス制御ポリシーが単純で構造化されています。ユーザーがリソースにアクセスする権限を持っているかどうかを決定するために単一レベルの許可チェックのみが必要です。病院システムがより複雑な構造を持ち、複数の部門、役割、許可を持っているとする想像力を働かせましょう:

• RBAC モデルでは、患者記録リソースのアクセス制御評価プロセスは、ユーザーが read, write, delete の権限を持っているか否かに関係なく、依然として簡単で明示的です。
• 一方で、ABAC では department-id や doctor-id といった追加属性を導入する必要があります。もし患者記録にアクセスする IoT デバイスがあるのだろうか？それにはポリシー評価に新しい属性 device-id を導入することが求められるでしょう。インターンの医師に一時的に read 権限を付与するにはどうするのでしょうか？

結論として、RBAC は適していると言えるでしょう。RBAC は許可構造がはっきりしており、アクセス制御ポリシーが静的なシステムに対してはシンプルかつ効率的です。

ケース 2#

同じ病院システムですが、新しい役割 patient と新しい属性 patient-id を導入してみましょう。

アクセス制御ポリシーは次のとおりです：

1. 医者は患者記録を読み取りおよび書き込みできます。
2. 看護師は患者記録を読み取りできます。
3. 管理者は患者記録を読み取り、書き込み、削除できます。
4. 患者は自分の記録を読み取ることができます。

RBAC モデル#

この場合、古い read 許可に加えて、新しい許可 read-own を導入する必要があります。医者、看護師、管理者、患者の役割を定義し、それぞれの役割に適切な許可を割り当てます。

今度はアクセス制御評価が少し複雑になります。特に read 患者記録アクションに対しては:

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')
• GET /patient-records/:patient-id: user.permission.includes('read-own') && user.id === patient-id || user.permission.includes('read')

ABAC モデル#

新しい要件に対応するために、ABAC モデル内の属性およびポリシーを更新しましょう。

属性:

• user.role: doctor, nurse, admin, patient
• user.id: patient-id
• resource.name: patient-record
• resource.patient-id: patient-id
• action: read, write, delete

ポリシー:

• ポリシー 1: すべての患者記録への読み取りアクセスを許可する
  • subject: 役割が doctor, nurse, admin のユーザー
  • resource: 名称が patient-record のリソース
  • action: read
  • effect: 許可
  • rationale: "すべてのスタッフおよび本人（患者）に患者記録の読み取りアクセスを許可する"
• ポリシー 2: 医者および管理者のためのすべての患者記録への書き込みアクセスを許可する
  • subject: 役割が doctor, admin のユーザー
  • resource: 名称が patient-record のリソース
  • action: write
  • effect: 許可
  • rationale: "医者および管理者に患者記録の書き込みアクセスを許可する"
• ポリシー 3: 管理者のためのすべての患者記録への削除アクセスを許可する
  • subject: 役割が admin のユーザー
  • resource: 名称が patient-record のリソース
  • action: delete
  • effect: 許可
  • rationale: "管理者に患者記録の削除アクセスを許可する"
• ポリシー 4: 自分の患者記録への読み取りアクセスを許可する
  • subject: 役割が patient のユーザー
  • resource: 名称が patient-record のリソース
  • action: read
  • condition: user.id === resource.patient-id
  • effect: 許可
  • rationale: "自分の患者記録への読み取りアクセスを許可する"

比較#

この場合、アクセス制御ポリシーはより複雑でコンテキストに依存しています。患者記録リソースのアクセス制御評価プロセスは、ユーザーがリソースにアクセスできるかどうかを判断するために複数レベルの許可チェックが必要です。

• RBAC モデルでは、患者記録リソースのアクセス制御評価プロセスは、ユーザーがリソースにアクセスできるかどうかを判断するために複数レベルの許可チェックが必要です。例えば、患者が自分自身の記録にアクセスするかどうかを判断するためには、システムはユーザーが read-own 許可を持っているかどうか、およびユーザー ID が患者 ID と一致しているかどうかを確認しなければなりません。
• ABAC モデルでは、アクセス制御評価プロセスがより簡潔であることがあります。ポリシーはユーザー、リソース、アクションの属性に基づいて定義することができます。例えば、患者が自分自身の記録にアクセスできるかどうかを判断するために、ポリシーエンジンはユーザー ID と患者 ID に基づいてポリシーを評価できます。

この場合、ABAC はより適しているかもしれません。ABAC は、アクセス制御ポリシーが動的で、コンテキストに依存し、きめ細かい粒度が必要なシステムにより適しています。

結論#

RBAC と ABAC の選択は、システムの特定の要件に依存します。RBAC は、許可構造が明確に定義され、アクセス制御ポリシーが静的なシステムに最適です。ABAC は、アクセス制御ポリシーが動的で、コンテキストに依存し、きめ細かい粒度が必要なシステムにより適しています。実際には、組織は、望ましいアクセス制御レベルを達成するために、両方のモデルを組み合わせて使用することが多いです。