翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# アクセスコントロールのタイプ
ロールベースのアクセスコントロール (RBAC) と属性ベースのアクセスコントロール (ABAC) の 2 つの広く定義されたモデルを使用して、アクセスコントロールを実装できます。各モデルには利点と欠点があり、このセクションで簡単に説明します。使用するモデルは、特定のユースケースによって異なります。このガイドで説明するアーキテクチャは、両方のモデルをサポートしています。
## RBAC
ロールベースのアクセスコントロール (RBAC) は、通常はビジネスロジックに沿ったロールに基づいてリソースへのアクセスを決定します。アクセス許可は、必要に応じてロールに関連付けられます。例えば、*マーケティング*ロールは、制限されたシステム内で*マーケティング*アクティビティを実行することをユーザーに許可します。これは、認識しやすいビジネスロジックによく合うため、実装する比較的シンプルなアクセスコントロールモデルです。
RBAC モデルは、次の場合に効果が低くなります。
+ 複数のロールを含む責任を持つ一意のユーザーがいます。
+ ロールの定義が困難になる複雑なビジネスロジックがある。
+ 大きなサイズにスケールアップするには、アクセス許可を継続的に管理し、新規および既存のロールにマッピングする必要があります。
+ 認可は動的パラメータに基づいています。
## ABAC
属性ベースのアクセスコントロール (ABAC) は、属性に基づいてリソースへのアクセスを決定します。属性は、ユーザー、リソース、環境、またはアプリケーションの状態に関連付けることもできます。ポリシーまたはルールは属性を参照し、基本的なブールロジックを使用して、ユーザーがアクションを実行できるかどうかを判断できます。アクセス許可の基本的な例を次に示します。
*支払いシステムでは、財務部門のすべてのユーザーが営業時間`/payments`内に API エンドポイントで支払いを処理できます。*
財務部門のメンバーシップは、 へのアクセスを決定するユーザー属性です`/payments`。API `/payments`エンドポイントに関連付けられたリソース属性もあり、営業時間内にのみアクセスを許可します。ABAC では、ユーザーが支払いを処理できるかどうかは、財務部門のメンバーシップをユーザー属性として、時刻を のリソース属性として含むポリシーによって決まります`/payments`。
ABAC モデルは、動的、コンテキスト、きめ細かな認可の決定を可能にするという点で非常に柔軟です。ただし、ABAC モデルを最初に実装することは困難です。関連するすべてのアクセスベクトルのルールとポリシーを定義し、属性を列挙するには、実装にかなりの先行投資が必要です。
## RBAC-ABAC ハイブリッドアプローチ
RBAC と ABAC を組み合わせると、両方のモデルの利点の一部が得られます。RBAC は、ビジネスロジックに非常に密接に連携しているため、ABAC よりも簡単に実装できます。承認の決定を行う際に、詳細度のレイヤーを追加するには、ABAC と RBAC を組み合わせることができます。このハイブリッドアプローチでは、ユーザーのロール (および割り当てられたアクセス許可) を追加の属性と組み合わせてアクセスを決定し、アクセスに関する決定を行います。両方のモデルを使用すると、権限の管理と割り当てが簡単になり、承認の決定に関する柔軟性と詳細度が向上します。
## アクセスコントロールモデルの比較
次の表は、前に説明した 3 つのアクセスコントロールモデルを比較したものです。この比較は、有益で高レベルであることを意図しています。特定の状況でアクセスモデルを使用すると、この表で行った比較と必ずしも相関しない場合があります。
| | | | |
| --- |--- |--- |--- |
| **係数** | **RBAC** | **ABAC** | **ハイブリッド** |
| **柔軟性** | Medium | 高い | 高 |
| **シンプルさ** | 高 | 低 | Medium |
| **詳細度** | 低 | 高 | 中程度 |
| **動的な決定とルール** | いいえ | あり | あり |
| **コンテキスト対応** | いいえ | あり | ある程度 |
| **実装の労力** | 低 | 高 | 中程度 |