認可は、認証済みのアイデンティティ（ユーザー、アプリケーション、サービス）が実行できることと、システム内のどのリソースにアクセスできるかを決定します。

ほとんどのシステムでは、認証（AuthN）が先に、その後に認可が行われます。つまり、システムが、あなたは誰であるのかを確認すると、認可が、あなたは何をできるのかを決定します。

認可によって、すべての認証済みアイデンティティが定義された境界内で動作することが保証されます。認可がないと、ログイン（AuthN）に成功したユーザーがすべての機密データにアクセスし、あらゆる操作を実行できてしまいます（AuthZのエラー）。ゼロトラストアーキテクチャでは、認可の判断は、初回アクセス時だけでなく、セッション全体を通して継続的に評価されます。

認可は、次の3つの主要要素を結び付けます。

• ユーザー：認証済みのアイデンティティ
• 権限：特定の操作を実行するための特定の権利（read:Patientsなど）
• リソース：保護対象となるアセット

ロールベースのアクセスコントロール（RBAC）

RBACは基本の認可モデルです。権限を管理者、編集者、閲覧者などのロールに付与し、これらのロールをユーザーに割り当てることで、権限の管理が簡素化されます。

• 仕組み：システムはユーザーに割り当てられたロールを確認し、その権限を集約して、要求された操作が許可されるかどうかを判断します。
• 使用すべきケース：ユーザー権限が静的な職務やグループと明確に一致する場合（典型的な企業アプリケーションや管理アプリケーションなど）。
• 制約：ロールは通常、静的であるため、RBACはデバイス、時間、場所といった動的またはコンテキスト依存のポリシーにはあまり適していません。

企業のIAMシステムや大規模クラウド環境では、RBACはフレームワークを通じて導入されています。

属性ベースのアクセスコントロール（ABAC）

ABACは、動的なポリシーに基づいて、ユーザーやリソース、環境の属性を評価し、アクセスを決定します。

• 仕組み：アクセスは、リアルタイムで評価されるポリシー式によって決定されます（user.department == resource.departmentの比較、現在時刻が営業時間内かどうかの確認など）。
• 使用すべきケース：認可の判断が複雑で、高度にコンテキスト依存である、または動的な要素に左右される場合（企業のIP範囲からのみアクセスを付与する、営業時間内のみドキュメントへのアクセスを許可する、機密リソースに対して特定のセキュリティクリアランスレベルを要求するなど）。
• トレードオフ：ABACは複雑さが生じます。ポリシーは、様々な属性の組み合わせにおける競合や意図しないアクセスを防ぐため、慎重に設計し、徹底的にテストする必要があります。

標準ベースのポリシーエンジン（Open Policy AgentやXACMLなど）は、ABACポリシーを適用することで、一貫性と可監査性を確保します。

関係性ベースのアクセスコントロール（ReBAC）ときめ細かな認可（FGA）

ReBACは、ユーザーと特定のリソース間の関係性と所有権に基づいて認可を行います。

• 仕組み：システムは明示的な関係性（「所有者」、「共有者」、「グループのメンバー」など）を確認して、アクセスを許可または拒否します。現在の実装では、グラフベースの関係性モデルを用いて、複雑な権限チェーンをたどっています。
• 使用すべきケース：ソーシャルメディアやドキュメント共有プラットフォームなどの共同作業システム（「投稿者本人のみが削除できる」、「共有ワークスペース内のユーザーはすべてのドキュメントを閲覧できる」など）。

ReBACおよびFGAシステムは、関係性を理解するインフラストラクチャとグラフベースの認可パターンを活用して、これらの関係性を大規模にモデル化し、クエリを実行します。OpenFGAやSpiceDBなど、複数のオープンソースの実装により、すべての開発者がこのテクノロジーを利用できます。

きめ細かな認可（FGA）は、ReBAC原則を拡張し、複雑な関係性グラフに基づく大規模な認可の判断を可能にします。FGAシステムは、グループ、組織、ネストされた権限を横断し関係性をたどることによって、「ユーザーXはドキュメントYを編集できるか？」といった質問に答えることができます。このモデルは、ドキュメント共同作業やソーシャルプラットフォームでの認可を強化し、フォルダー階層、グループメンバーシップ、共有関係を通じてアクセスを継承できます。

API駆動型のアプリケーションは、OAuth 2.0認可フローを介して発行されるアクセストークンを用いて、認可を実施します。

1. 認可マッピング：認証が成功すると、認可サーバーは、選択されたAuthZモデルと適用される動的なポリシー（RBAC、ABACなど）に基づいて、ユーザーに付与される権限を決定します。
2. トークン発行：サーバーは、アクセストークン、最も一般的には、JSON Web Token（JWT）を発行します。このトークンには、件名とその認可されたスコープに関するクレームが含まれます。または、認可サーバーのイントロスペクションエンドポイントを通じて検証が必要な不透明なトークンが発行されます。認証フローでは、トークンの取得方法と、トークンに含まれるクレームが決定されます。
3. APIの適用：APIはリクエストを受信すると、JWTを検証し、トークン内のクレームに基づいて認可ルールを適用します。

このトークンベースのアプローチをステートレスと言います。トークンには、APIに必要なすべての情報（認可コンテキストと暗号署名）が含まれています。

スコープは、クライアントアプリケーションが認可サーバーから要求する権限を定義します。認可サーバーは、ユーザーが同意したスコープのみを許可し、発行されるアクセストークンにそのスコープを含めます。

• アプリケーションがアクセストークンを要求すると、必要なスコープを指定します（read:documents、write:documentsなど）。
• 認可サーバーは、要求されたスコープをユーザーの実際の権限と照合して、ユーザーが認可できる範囲のみを許可します。
• 発行されたアクセストークンには、承認されたスコープが含まれています。APIは、トークンに要求された操作に必要なスコープが含まれていることを検証します。必要なスコープがない場合、APIはアクセスを拒否します。

ロールは通常、広範なアクセス権を定義する一方、スコープはきめ細かな操作レベルの権限を表します。ロールとスコープを組み合わせることで、柔軟にAPIを管理できます。

OpenID Connect（OIDC）は、OAuth 2.0を拡張したもので、認可スコープに加えて、ユーザーの本人確認やプロファイル要求のためのIDトークンを発行できます。

すべての保護されたAPIエンドポイントは、受信したアクセストークンを検証する必要があります。トークンの署名（完全性と正当性を保証する）、有効期限（expクレーム）、オーディエンス（audクレーム）、発行者（issクレーム）、および必要な権限（スコープまたはロール）を検証します。追加の検証には、トークン失効状態の確認、nbf（有効期限の開始日時）クレームの検証、クライアントごとのレート制限の強制などが含まれます。JWTの場合、認可サーバーは、署名検証のためにJSON Web Key Set（JWKS）エンドポイント経由で公開鍵を発行します。

APIは、エラーの種類を伝えるために特定のHTTPステータスコードを返す必要があります。

• 401 Unauthorized：認証が失敗した、または認証情報が存在しないことを意味し、リクエストに有効な認証情報が含まれていません（トークンが欠落している、無効である、または有効期限が切れている）。
  例：Authorizationヘッダーが欠落、JWTの有効期限切れ、署名が無効
• 403 Forbidden：認可が失敗したことを意味します。ユーザーのアイデンティティは確認（認証）されていますが、その権限によって、要求されたリソースや操作に対するアクセスが拒否されています。
  例：トークンは有効であるが、ユーザーにはDELETE /users/:idを実行するadminロールがないため、要求された操作に対してスコープが不足している

認可チェックに一貫性がないと、どのようなセキュリティリスクがありますか？

認可ロジックがコード全体に分散していると、一部の経路で必要なチェックが実行されず、攻撃者が悪用できる脆弱性が残る可能性があります。ミドルウェアやポリシーエンジンによって認可を一元的に適用することがベストプラクティスです。新しいアプローチとして、Policy-as-Codeが登場しており、Rego（Open Policy Agent）のような言語を用いて、認可ロジックをアプリケーションコードから分離し、一元的なテストと監査を可能にするものです。

最小権限の原則とは何ですか？

この原則は、ユーザーやサービスに職務上必要な最小限のロールと権限のみを付与することを求めており、これによりアイデンティティの侵害による潜在的な損害を最小限に抑えます。実際には、定期的に権限を監査し、時間制限付きのアクセス付与を実装し、使用されていないロールやスコープを削除することを意味します。

ステップアップ認証はいつ使用すべきですか？

ステップアップ認証は、セキュリティと使いやすさのバランスを取れる仕組みです。認証済みのユーザーに対しても、振込や給与変更などのリスクの高い操作を行う場合には、追加の要素（生体認証スキャンなど）を要求します。このアプローチは、アダプティブ認証またはコンテキスト認証とも呼ばれます。

一般的な認可の脆弱性は何ですか？

壊れたオブジェクトレベル認可（BOLA）は、安全でない直接オブジェクト参照（IDOR）とも呼ばれ、一般的な脆弱性です。これは、APIが一般的な権限（「ドキュメントを閲覧できる」など）をチェックする一方で、ユーザーが要求された特定のリソースID（「ドキュメントID 12345」など）へのアクセス権を持っていることを検証できない場合に発生します。この脆弱性は、OWASP API Security Top 10リストで常にAPI1:2023に指定されています。操作の権限とリソースレベルのアクセスの両方を必ず検証することが重要です。

認可とアクセスコントロールの違いは何ですか？

認可はアクセスコントロールの1つです。アクセスコントロールは、認証（アイデンティティの検証）、認可（権限の付与）、適用（ポリシー適用の確保）を含む、より広範なセキュリティ規律です。認可は、認証済みのアイデンティティが実行できる操作の決定と適用を明確に指します。

マイクロサービスのアーキテクチャで認可はどのように機能しますか？

分散システムでは、API gateway（粗粒度）、サービスメッシュ（ネットワークレベル）、個々のサービス（細粒度）といった複数の階層で認可が行われます。JWTを用いたトークンベースの認可によって、サービス間でのステートレスな検証が可能になります。ただし、一貫性を維持するのは容易ではありません。ポリシーの更新はすべてのサービスに反映される必要があり、関係性に基づく決定には集中型ポリシーエンジンや分散キャッシュが求められます。

認可は、包括的なアイデンティティとアクセス管理戦略を構成する要素の1つです。OAuth 2.0やOpenID Connectなどの最新の認可フレームワークと、ABAC、ReBAC、きめ細かな認可（FGA）などのきめ細かいモデルを利用して、開発者はゼロトラストの原則に沿った、より安全でスケーラブルなアプリを構築できます。認証、アクセスコントロールモデル、セキュリティのベストプラクティスについての詳細は、Auth0の「IAM入門」シリーズをご覧ください。

詳細を見る

これらの資料は一般的な情報提供のみを目的としています。お客様ご自身の専門アドバイザーから、セキュリティ、プライバシー、コンプライアンス、またはビジネスに関する助言を得る責任はお客様にあり、本資料に記載された情報のみに依存すべきではありません。