認可・アクセス制御

認可とは、認証済みのユーザーが何にアクセスできるかを制御するプロセスであり、認証（誰であるか）とは明確に分離して設計する必要がある。RBAC（Role-Based Access Control）は、ロール（管理者・一般ユーザー等）に権限を付与し、ユーザーをロールに割り当てるシンプルなモデルであり、多くのビジネスアプリケーションでの基本的な選択肢となる。ABAC（Attribute-Based Access Control）は、ユーザー属性・リソース属性・環境属性を組み合わせた条件式で権限を判定する柔軟なモデルであり、より複雑なビジネスルールを表現できるが実装と管理のコストも高い。

ReBAC（Relationship-Based Access Control）は、Googleが開発したZanzibarシステムで採用されたモデルであり、ユーザーとリソースの関係グラフに基づいて権限を決定する。GoogleドキュメントやGitHubのリポジトリ権限のような「特定のオブジェクトを所有・共有されているか」という関係性を自然に表現できる。OPA（Open Policy Agent）はポリシーをコードとして記述し、認可ロジックをアプリケーションから分離して中央管理するためのOSSツールであり、マイクロサービス環境での認可ポリシーの一元化に適している。

IDOR（Insecure Direct Object Reference）は、URLパラメータ等に含まれるリソースIDを操作することで他のユーザーのデータに不正アクセスできる脆弱性であり、OWASP Top 10の常連項目である。最小権限の原則とデフォルト拒否（Deny by Default）の組み合わせは、認可設計の基本原則であり、許可が明示的に付与されていない限りアクセスを拒否するという考え方を徹底することでIDORや権限昇格を防ぐ基盤となる。

コードレビューで着目するポイント

リソース取得時に、ログインユーザーとリソースの所有者の一致確認が行われているか（IDORチェック）
認可チェックがコントローラ層だけでなく、サービス・ドメイン層でも行われているか
管理者権限が必要なエンドポイントに対して、ユーザーロールの検証がサーバー側で実施されているか
デフォルトで全アクセス拒否のポリシーが実装されており、許可は明示的に設定されているか
水平方向のアクセス制御（同ロール間のデータ分離）が設計・実装されているか
認可ロジックが複数箇所に散在せず、中央のサービスまたはポリシーとして管理されているか
権限変更・削除操作のログが監査証跡として記録されているか

典型的なアンチパターン

IDの連番推測によるIDOR: /api/orders/12345というURLで、認証済みであれば誰でも他ユーザーの注文を参照できる実装。IDをUUIDやトークンにしても根本的な解決にはならず、リソース取得時に必ずオーナーシップ検証を行う必要がある。

フロントエンドのみのアクセス制御: 管理者UIのボタンをロールに基づいて非表示にしているが、APIエンドポイント自体にはロールチェックがない実装。APIをHTTPクライアントで直接呼べば誰でもアクセスできてしまう。サーバーサイドでの検証は省略できない。

認可ロジックの分散: コントローラ・サービス・リポジトリ層それぞれに断片的に認可ロジックが書かれており、新しいエンドポイントを追加する際にどこに追加すべきか分からない状態。認可判定を一箇所（ポリシーサービスやミドルウェア）に集約することで一貫性を保てる。

参考リソース

OWASP Authorization Cheat Sheet — 認可設計の包括的なチェックリストと実装ガイド
Google Zanzibar論文 (2019) — ReBAC（関係ベースアクセス制御）の実装詳細と設計思想
Open Policy Agent (OPA) (https://www.openpolicyagent.org/) — ポリシーとしての認可ロジックを中央管理するOSS
NIST SP 800-162: Guide to Attribute Based Access Control — ABACの政府標準定義ガイド
SpiceDB / Authzed — Zanzibarインスパイアの関係ベースアクセス制御OSSとマネージドサービス