認可.

認可 (AuthZ) は認証に続く段階です。ユーザー・サービス・端末が自分が誰であるかを証明した後、システムはその ID が特定のリソースに対して要求された操作を実行できるかどうかを判断しなければなりません。判定は、ロール (RBAC)、属性とポリシー (ABAC)、機密区分 (MAC)、所有者の裁量 (DAC) などに基づき、通常は主体・リソース・操作・環境を評価する policy decision point によって行われ、policy enforcement point が要求を制御します。現代のシステムでは、OAuth 2.0 のスコープ (RFC 6749)、OpenID Connect のクレーム、XACML、Rego/Open Policy Agent (OPA) といった標準でポリシーを外部化し、ルールをアプリケーションコードの外に保ちます。

認可は、Web において最も障害が発生しやすい制御です。OWASP は 2021 年版 Top 10 でアクセス制御の不備 (Broken Access Control) を A01、すなわち第 1 位のリスクに位置付け、テスト対象アプリケーションの 94 % で確認されました。これは 2025 年版でも維持されている順位です。典型的な欠陥が IDOR (Insecure Direct Object Reference) で、URL や API 呼び出し内の数値 id を変更して別テナントのデータを読み取るものです。2022 年にはオーストラリアの Optus の侵害により、認証不要で列挙可能な API エンドポイントを通じて約 1,000 万人の顧客の記録が流出し、2019 年の Instagram の IDOR では非公開の投稿やストーリーが露出しました。

より巧妙な分類が confused deputy で、より高い権限を持つコンポーネントが攻撃者の代わりにその権限を悪用するよう仕向けられるものです。これは CSRF と SSRF の概念的な根源です。防御策としては、デフォルトで拒否する、すべての要求に対してサーバー側で認可を実施する (クライアントを決して信頼しない)、認証だけでなくオブジェクトの所有権を確認する、推測困難な識別子を優先する、アクセス判定をログに記録する、そして水平方向および垂直方向の権限昇格を継続的にテストする、といったものがあります。

flowchart LR
  U[Authenticated request] --> PEP[Policy Enforcement Point]
  PEP --> PDP[Policy Decision Point]
  CTX[Subject resource action environment] --> PDP
  POL[(Policy RBAC ABAC Rego)] --> PDP
  PDP -->|Permit| R[Access resource]
  PDP -->|Deny| X[403 Forbidden and audit log]