AuthZ（認可）とは何ですか？
AuthZ の定義、AuthN 対 AuthZ、AuthZ の動作方法、および認可のベストプラクティスについて探ります。
Product & Design
AuthZ とは何ですか、そして AuthN とはどう違いますか？
AuthZ は authorization（認可）の略です。認可は authentication（認証）とは別のメカニズムです。認証はあなたが誰であるかを確認し、認可は特定のリソースにアクセスできるかどうか、またそれに対してどのような操作を行えるかを決定します。
実世界の例では、リソースにはソフトウェア、システム、ドキュメント、注文、資産が含まれます。認可は誰がこれらのリソースにどのような条件でアクセスできるかを指定して、追加の制御層を追加します。
AuthZ はどのように機能しますか？
認可は認証とは別ですが、しばしば関連しています。たとえば、OAuth 2.0、OIDC、SAML のような標準プロトコルは、トークンベースの認可メカニズムを組み込んでいます。
トークンベースの認可システムでは、認可サーバーがユーザーに アクセストークン を発行します。このトークンは許可を含み、ユーザーが特定のリソースにアクセスできるかどうかを決定します。
許可を直接ユ ーザーに割り当てることは非効率的であり、特に詳細な条件が必要な場合にはそうです。たとえば、アクセスはユーザーの位置情報などの特定の状況に依存するため、アクセス制御ポリシーが必要となります。
認可がどのように機能するかのステップバイステップの高レベルフローは次のようになります：
- 認証を開始する: ユーザーはメールとパスワードを使用するなどして、識別子とメソッドを選択してサインインします。
- 認可リクエスト: サインイン後、ユーザーはユーザー ID や役割などの詳細を含むリソースへのアクセスを要求します。
- アクセス制御の検証: システムは、役割ベースや属性ベースルールなど、事前定義された認可ポリシーに対してリクエストを確認します。
- 認可の決定: システムは、ポリシーと許可に基づいてアクセスを許可するか否かを決定します。
OAuth 2.0 の認可リクエストフローの詳細を理解するには、authorization request をご覧ください。
認可の種類は何ですか？
役割ベースのアクセス制御とその動作
Role-Based Access Control (RBAC) は、役割を使用してアクセスを管理します。各ユーザーには 1 つ以上の事前定義された役割が割り当てられ、それぞれの役割には許可のセットが含まれています。RBAC の鍵は、主体（またはユーザー）、役割、許可の関係を理解することです。
役割ベースのアクセス制御（RBAC）の動作を理解するには、次のことを知る必要があります：
- 主体: これには
userやmachine-to-machine applicationなどのユーザーや非人間のエンティティが含まれます。 - 役割: 仕事の機能や責任を表します。例えば、
adminmember - 許可: 特定のリソースに対して許可されている操作を指定します。例えば、
read: order。
属性ベースのアクセス制御とその動作
Attribute-Based Access Control (ABAC) は、認可に広く利用され、単に役割だけでなく、エンティティの特定の属性を使用することでより複雑なシナリオをサポートします。
たとえば、ある企業は、従業員が職務役割、場所、文書の分類レベルに基づいて機密ファイルにアクセスする必要があるグローバルなドキュメント共有プラットフォームを管理しています。
属性は次のように設計されることがあります：
- ユーザー属性: 役割（例：「マネージャー」、「エンジニア」）、場所（例：「米国」、「ヨーロッパ」）。
- リソース属性: 文書の種類（例：「財務報告書」、「設計ファイル」）、分類レベル（例：「機密」）。
- 環境属性: アクセス時間（例：「勤務時間内」）、デバイスタイプ（例：「会社のラップトップ」）。
また、他のアクセス制御モデルとして、policy-based access control (PBAC) があります。各モデルにはその強みと弱みがあり、モデルの選択は使用ケースと要件に依存します。
AuthZ 使用例と例
B2C ソフトウェア
B2C ソフトウェアは、多くの場合、ビジネスのニーズに基づいた特定の役割を必要とします。たとえば、書店管理アプリは、リソースやサービスを管理する責任を持つ役割を含む可能性があります。
B2B マルチテナントアプリ
B2B アプリでは、企業ごとにテナントを表すマルチテナントアーキテクチャを使用することがよくあります。組織内では、管理者やメンバーなどの役割が必要です。これは、Authorization (AuthZ) が組織レベルでのユーザー管理において重要な役割を果たすところであり、しばしば Role-Based Access Control (RBAC) を使用します。
機械と機械の認可
機械と機械の コミュニケーションは、人間の関与なしにサービス間で直接行われます。たとえば、API サービスを呼び出すこと。それ には、安全で動的かつ細かいアクセスを確保するためにトークン（例：OAuth 2.0 アクセストークン）がしばしば含まれます。
AuthZ のベストプラクティスは何ですか？
以下は、セキュアで効果的なアクセス制御を確保するための authorization (authZ) のベストプラクティス です：
-
最小特権の原則
これは、アカウントが危険にさらされた際の不正アクセスや損害のリスクを最小限に抑えることを保証します。ユーザーやシステムは、役割に必要なリソースやアクションのみにアクセスする必要があります。
-
トークンベースの認可を採用する
トークンベースのアクセス制御は、オープン標準に従いながら、より柔軟で詳細な制御を提供します。安全なトークン（例：OAuth 2.0、JWT）を使用して、時間に依存したアクセスやスコープを付与します。
-
定期的に監査とモニタリングを行う
アクセスログや認可ポリシーを定期的にレビューして、異常や更新されていない許可を特定することが必要です。
-
職務の分離を適用する
細かい許可（例：特定のアクションやリソース（例：読み取り、書き込み、削除）を定義する）を実装することから始めます。役割を作成するときには、明確な役割名を使用し、職務の分離を強制して、不正行為や単一ユーザーによる誤りのリスクを最小限に抑えます。
-
マルチテナンシーをサポートする（該当する 場合）
マルチテナントシステムでは、テナントの分離が重要です。それを役割ベースのアクセス制御と組み合わせることで、データリソースの分離を達成し、適切な役割が自分のテナント内でのみリソースにアクセスできるようにすることができ、他のテナントのリソースへの偶発的または悪意のあるアクセスを防ぎます。
-
動的にアクセスを取り消す
あなたの AuthZ システムを設計する際には、条件が変わった場合（例：役割の更新、または雇用終了）に許可を即座に更新または取り消すことができるようにすることを保証してください。これは、動的な API チェック、ウェブフック、または他の方法によって達成できます。目標は、リアルタイムでの不正アクセスを防ぐことです。
AuthZ（認可）と Auth（認証）の違いは何ですか？
認証と認可の違いは、アイデンティティとアクセス管理における目的とプロセスにあります。
AuthN（認証）は、「あなたは誰で、どのアイデンティティを所有していますか」という質問に答えます。これは、ユーザー、サービス、またはデバイスのアイデンティティを確認するプロセスです。認証は、システムやリソースへのアクセスを試みるエンティティが本物であることを保証します。一般的な方法には、パスワード、生体認証、2要素認証（2FA）があります。たとえば、メールとパスワードを使用してアカウントにログインする際、システムは認証を通じてあなたのアイデンティティを確 認します。
AuthZ（認可）は、「あなたは何をすることが許されていますか」という質問に答えます。これは、ユーザーの許可や役割に基づいてリソースへのアクセスを許可または拒否するプロセスです。認可は認証の後に発生し、認証されたユーザーがどのような操作を行えるかを決定します。たとえば、ログイン後、管理者ユーザーは設定を変更するアクセス権を持ち、通常のユーザーはそれらを表示するのみです。
要約すると、AuthN（認証）はアイデンティティを確認し、AuthZ（認可）はアクセスを定義します。最初に認証が行われ、その後認可が続行されて、リソースのセキュアで適切な使用を確保します。
Logto を使用して AuthZ（認可）を構築する
Logto Cloud は、OIDC、OAuth 2.0、SAML などのオープンスタンダードプロトコルに基づく主要な認可サービスを提供します。Role-Based Access Control、Organizations (Multi-Tenancy)、Custom Token Claims などの機能を備え、さまざまな視点からの認可ニーズに対応します。