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