アクセスコントロールのタイプ - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

アクセスコントロールのタイプ

アクセスコントロールの実装には、ロールベースのアクセスコントロール (RBAC) と属性ベースのアクセスコントロール (ABAC) という 2 つの広く定義されたモデルを使用できます。各モデルには長所と短所があります。これらについてはこのセクションで簡単に説明します。使用するモデルは、特定のユースケースに大きく左右されます。このガイドで説明するアーキテクチャは、両方のモデルをサポートしています。

RBAC

ロールベースのアクセスコントロール (RBAC) は、通常はビジネスロジックに沿ったロールに基づいてリソースへのアクセスを決定します。権限は必要に応じてロールに関連付けられます。たとえば、マーケティングロールは制限されたシステム内でマーケティング活動を行うことをユーザーに許可します。これは、簡単に認識できるビジネスロジックとうまく連携しているため、実装が比較的簡単なアクセス制御モデルです。

RBACモデルは次の場合には効果が低くなります。

  • 複数の役割を担うユニークなユーザーがいます。

  • ビジネスロジックが複雑で、役割を定義するのが難しい。

  • 大規模な規模にスケールアップするには、絶え間ない管理と、新規および既存のロールへの権限のマッピングが必要です。

  • 承認は動的パラメータに基づいています。

ABAC

属性ベースのアクセスコントロール (ABAC) は、属性に基づいてリソースへのアクセスを決定します。属性は、ユーザー、リソース、環境、さらにはアプリケーションの状態に関連付けることができます。ポリシーまたはルールは属性を参照し、基本的なブールロジックを使用してユーザーにアクションの実行を許可されているかどうかを判断できます。権限の基本的な例は次のとおりです。

支払いシステムでは、財務部門のすべてのユーザーは、/payments営業時間中に API エンドポイントで支払いを処理できます。

財務部門のメンバーシップは、/paymentsへのアクセスを決定するユーザー属性です。/paymentsAPI エンドポイントには、営業時間中のみアクセスを許可するリソース属性も関連付けられています。ABACでは、ユーザーが支払いを処理できるかどうかは、財務部門のメンバーシップをユーザー属性として、時間をリソース属性として含むポリシーによって決まります/payments

ABACモデルは非常に柔軟性が高く、動的で状況に応じたきめ細かな権限決定が可能です。ただし、ABACモデルを最初に実装するのは困難です。ルールとポリシーを定義し、関連するすべてのアクセスベクトルの属性を列挙するには、実装に多額の先行投資が必要です。

RBAC-ABACハイブリッドアプローチ

RBACとABACを組み合わせると、両方のモデルの利点の一部が得られます。RBACはビジネスロジックと密接に連携しているため、ABACよりも実装が簡単です。ABAC と RBAC を組み合わせると、承認に関する決定をさらに細かく行うことができます。このハイブリッドアプローチでは、ユーザーの役割 (および割り当てられた権限) と追加の属性を組み合わせてアクセス権を決定します。両方のモデルを使用すると、権限の管理と割り当てが簡単になり、権限の決定に関する柔軟性と細分性も向上します。

アクセスコントロールのモデルの比較

次の表は、前述の 3 つのアクセスコントロールのモデルの比較を示しています。この比較は、有益で大まかな内容になるよう意図されています。特定の状況でアクセスモデルを使用しても、この表の比較と必ずしも相関しない場合があります。

ファクター RBAC ABAC ハイブリッド
柔軟性
シンプル
詳細度
動的な決定とルール いいえ はい はい
コンテクスト対応 いいえ はい ある程度
実装作業