Logo Logo
GitHub Designed by Logto

アクセス制御 (Access control) とは?

アクセス制御 (Access control) には3つの主要なコンポーネントがあります:

  • 主体 (Subject): リソースに対してアクションを実行するエンティティです。主体はユーザー、サービス、デバイスである可能性があります。
  • リソース (Resource): アクセス制御 (Access control) によって保護されるエンティティです。リソースはファイル、データベース、API、またはその他のデジタル資産である可能性があります。
  • アクション (Action): 主体がリソースに対して実行できる操作です。アクションには読み取り、書き込み、実行、またはその他の操作が含まれます。

アクセス制御 (Access control) は、主体 (Subject)アクション (Action) に基づいて、リソース (Resource) への選択的アクセス制限を定義します。

以下はアクセス制御 (Access control) のいくつかの現実世界の例です:

  • ユーザー (主体) は、EC システムで自分の注文 (リソース) を読み取る (アクション) ことができます。
  • ユーザー (主体) は、ソーシャルネットワークで他のユーザーのプロフィール (リソース) を削除する (アクション) ことができません。
  • サービス (主体) は、マイクロサービスアーキテクチャでデータベース (リソース) にデータを書き込む (アクション) ことができます。

技術的な実装では、時々リソースを無視し、アクセス制御 (Access control) を誰 (主体) が何のアクションを実行できるかの制限として定義します。例えば、基本的な OAuth 2.0 フレームワークはスコープ (権限) を使用してアクションのみを指定し、リソースを定義しません。

認可サーバー (Authorization Server) アイデンティティプロバイダー (Identity provider, IdP) に応じて、アクセス制御 (Access control) のサポートは異なる場合があります。一部のシステムでは、OAuth 2.0 の拡張である OAuth 2.0 のリソースインジケーター をサポートしており、クライアントがアクセスしたいリソースを指定できます。

アクセス制御 (Access control) モデル

少数の主体とリソース間で制限を決定するのは簡単ですが、スケーラブルではありません。したがって、業界では効果的に管理するために多くのアクセス制御 (Access control) モデルを開発しています。 アイデンティティとアクセス管理 (Identity and access management, IAM) の文脈では、以下が一般的なアクセス制御 (Access control) モデルです:

  • ロールベースのアクセス制御 (RBAC) : 権限を役割に割り当て、その役割を主体に割り当てるモデルです。例えば、管理者の役割はすべてのリソースにアクセスできるかもしれませんが、ユーザーの役割は限定されたリソースにしかアクセスできないかもしれません。
  • 属性ベースのアクセス制御 (Attribute-based access control, ABAC) : 主体、リソース、環境の属性 (プロパティ) を利用してアクセス制御 (Access control) の決定を行うモデルです。例えば、“department=engineering” という属性を持つユーザーが、エンジニアリングのリソースにアクセスできるかもしれません。

他にも ポリシーベースのアクセス制御 (PBAC) などのアクセス制御 (Access control) モデルがあります。各モデルにはそれぞれの強みと弱みがあり、モデルの選択はユースケースと要件に依存します。

OAuth 2.0 におけるアクセス制御 (Access control)

OAuth 2.0 の文脈では、アクセス制御 (Access control) は通常 スコープ を使用して実装されます。通常、スコープの値はリソースとアクションを組み合わせた文字列です。例えば、read:orderswrite:profile です。

[!Note] “スコープ (Scopes)” という用語は、ほとんどの場合 “権限” と同義です。

OAuth 2.0 はスコープの構造と意味を定義していないことに注意する価値があります。スコープの解釈は リソースサーバー (Resource server) に任されており、スコープの発行は 認可サーバー (Authorization Server) に任されています。

例えば、ユーザー (主体) が EC システムで自分の注文 (リソース) にアクセスする必要がある場合、OAuth 2.0 を活用してスコープ read:orders を定義し、Web アプリケーション (クライアント) が認可サーバーからこのスコープを要求することができます。以下は簡略化されたフローです:

このフローでは、技術的アーキテクチャに応じて、リソースサーバーは API サービスであるか、リソース (注文) にアクセスする能力を持っている限り、クライアント (Web アプリケーション) 自身である場合もあります。

リソースインジケーターパラメータ

人々はしばしばスコープをリソースとアクションで定義します (例: read:orders、ここで orders はリソースで read はアクションです) が、リソースとアクションの数が増えるとこの方法のスケーラビリティに制限があります。RFC 8707 は OAuth 2.0 に resource パラメータ (つまり リソースインジケーター ) を導入し、クライアントがアクセスしたいリソースを指定できるようにします。

RFC は resource パラメータがリソースを表す URI であるべきことを指定しています。たとえば、単に orders を使用する代わりに、https://api.example.com/orders を使用できます。この方法は、実際のリソース URL を使用することで、名前の競合を防ぎ、リソースのマッチングの精度を高めます。

認可サーバーのサポート

OAuth 2.0 は認可サーバーがどのようにアクセス制御 (Access control) を実施すべきかを定義していません。実装の詳細は認可サーバーに委ねられています。したがって、認可サーバーの選択はアクセス制御 (Access control) メカニズムに大きく影響します。例えば、一部の認可サーバーはリソースインジケーターをサポートしているかもしれませんが、そうでないものもあります。ビジネス要件に基づいてどのアクセス制御 (Access control) モデルを使用するかを決定し、そのモデルをサポートする認可サーバーを選択することが重要です。アクセス制御 (Access control) モデルに確信が持てない場合、 ロールベースのアクセス制御 (RBAC) はほとんどの場合で十分です。

関連項目