次の方法で共有

承認の基本

  • [アーティクル]

承認 (AuthZ と省略されることもあります) は、リソースまたは機能へのアクセスを評価できるようにするアクセス許可を設定するため使用されます。 これに対し、認証 (AuthN と省略されることもあります) は、ユーザーまたはサービスのようなエンティティが、主張する本人であることを証明することに重点を置いています。

承認には、エンティティがアクセスできる機能、リソース、またはデータの指定を含めることができます。 承認では、データに対して実行できる処理も指定されます。 この承認アクションは、多くの場合 "アクセス制御" と呼ばれます。

認証と承認は、ユーザーのみに限定されない概念です。 サービスまたはデーモン アプリケーションは、多くの場合、特定のユーザーの代わりではなく、それら自身としてリソースに対する要求を行うように構築されます。 この記事では、ユーザーまたはアプリケーションのいずれかを示すために "エンティティ" という用語が使用されます。

承認方法

承認を処理するいくつかの一般的な方法があります。 ロールベースのアクセス制御は、Microsoft ID プラットフォームを使用する、現在最も一般的な方法です。

承認としての認証

おそらく承認の最も単純な形式は、要求を行うエンティティが認証されているかどうかに基づいてアクセスを許可または拒否することです。 要求元は、自分が本人であることを証明できる場合、保護されたリソースまたは機能にアクセスできます。

アクセス制御リスト

アクセス制御リスト (ACL) を使用した承認では、リソースまたは機能へのアクセスが許可されている、または許可されていない特定のエンティティの明示的なリストを保持する必要があります。 ACL では、承認としての認証よりも細かい制御が可能になりますが、エンティティの数が増えるにつれて管理が困難になります。

ロールベースのアクセス制御

ロールベースのアクセス制御 (RBAC) は、アプリケーションで承認を適用するためのおそらく最も一般的な方法です。 RBAC を使用すると、あるエンティティが実行できるアクティビティの種類を記述するためにロールが定義されます。 アプリケーション開発者は、個々のエンティティではなくロールに対してアクセスを許可します。 その後管理者は、さまざまなエンティティにロールを割り当てて、どのエンティティがどのリソースと機能にアクセスできるかを制御できます。

高度な RBAC 実装では、ロールがアクセス許可のコレクションにマップされることがあり、このときアクセス許可には実行できるアクションやアクティビティが細かく記述されます。 ロールはその後、アクセス許可の組み合わせとして構成されます。 エンティティの全体的なアクセス許可セットを計算するには、エンティティを割り当てる先の各種ロールに付与するアクセス許可を結合します。 このアプローチの好例として、Azure サブスクリプション内のリソースへのアクセスを制御する RBAC 実装が挙げられます。

Note

アプリケーション RBAC は Azure RBAC および Microsoft Entra RBAC とは異なります。 Azure カスタム ロールと組み込みロールはどちらも Azure RBAC の一部であり、Azure リソースの管理に役立ちます。 Microsoft Entra RBAC を使用すると、Microsoft Entra リソースを管理できます。

属性ベースのアクセス制御

属性ベースのアクセス制御 (ABAC) は、よりきめ細かいアクセス制御のメカニズムです。 この方法では、エンティティ、アクセス対象のリソース、現在の環境にルールが適用されます。 ルールによって、リソースと機能へのアクセスのレベルが決まります。 たとえば、マネージャーであるユーザーのみが、営業日の午前 9 時から午後 5 時までの時間帯に "営業時間中にマネージャーのみ" というメタデータ タグで識別されたファイルにアクセスできるようにすることができます。 この場合、アクセスは、ユーザーの属性 (マネージャーとしてのステータス)、リソースの属性 (ファイルのメタデータ タグ)、環境属性 (現在の時刻) を調べることによって決定されます。

ABAC の利点の 1 つは、ルールと条件の評価によってよりきめ細かい動的なアクセス制御を実現でき、具体的なロールと RBAC 割り当てを大量に作成せずに済むことです。

Microsoft Entra ID で ABAC を実現する 1 つの方法は、動的メンバーシップ グループを使用することです。 動的グループを使用すると、管理者は必要な値を持つ特定のユーザー属性に基づいて、ユーザーをグループに動的に割り当てることができます。 たとえば、作成者グループを作成して、作成者という役職を持つすべてのユーザーを作成者グループに動的に割り当てることができます。 動的グループを承認のための RBAC と組み合わせて使用して、ロールをグループにマップし、ユーザーをグループに動的に割り当てることができます。

Azure ABAC は、現在利用できる ABAC ソリューションの一例です。 Azure ABAC は、Azure RBAC を基盤としたものであり、特定のアクションのコンテキストにおける属性に基づいたロールの割り当て条件を追加することにより構築されます。

承認の実装

承認ロジックは多くの場合、アクセス制御が必要なアプリケーションまたはソリューション内に実装されます。 多くの場合、アプリケーション開発プラットフォームには、承認の実装を簡略化するミドルウェアまたはその他の API ソリューションが提供されています。 例としては、ASP.NET の AuthorizeAttribute や Angular の Route Guards の使用などがあります。

認証対象のエンティティに関する情報に依存した承認方法の場合、アプリケーションでは認証時に交換される情報が評価されます。 たとえば、セキュリティ トークン内に指定された情報を使用します。 承認のためにトークンからの情報を使用する予定の場合は、クレームの検証を通じてアプリを適切にセキュリティで保護する方法に関するこちらのガイダンスに従うことをお勧めします。 セキュリティ トークンに含まれていない情報を得るために、アプリケーションでは外部リソースに追加の呼び出しを行う場合があります。

開発者がアプリケーション内に承認ロジックを完全に埋め込むことが絶対に必要というわけではありません。 代わりに、専用の承認サービスを使用して、承認の実装と管理を一元化することができます。

次のステップ