中級ではRBAC/ABACとサーバ側確認を見ました。上級では、モデルの進化と大規模運用へ。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
モデルの発展
- RBAC — ロールで束ねる（シンプル、粗い）
- ABAC — 属性（部署・時間・所有者）で細かく
- ReBAC — オブジェクト間の関係グラフで判断（共有・招待・ネストに強い。Zanzibar）
- ポリシーエンジン — OPA/Regoなどに認可を集約し、コードから分離
やさしく言うと（中級）
権限の決め方には代表的な2方式があります。
- RBAC（ロールベース） — 「管理者・編集者・閲覧者」などロールに権限を束ね、利用者に割り当てる
- ABAC（属性ベース） — 部署・所有者・時間帯などの属性で、より細かく判断する
登場人物メモ:
- ※1 スコープ — トークンに載る「できる操作の範囲」（OAuth）
- ※2 所有者チェック — 「そのデータの持ち主か」を確認すること
アニメーション『RBAC（ロールで権限を束ねる）』を開く
判断の流れ
- 認証で主体（誰）を特定
- リクエストのリソースと操作を特定
- ポリシー評価（集中エンジン or 分散）で許可／拒否
- トークンのスコープ／クレームや、リソースの所有関係を照合
やさしく言うと（中級）
- 認証で「誰か」を特定する
- リクエストのたびに ポリシー評価（ロール／属性／所有者）
- サーバ側で許可・拒否を判断する（クライアントの制御は飾りに過ぎない）
- 拒否なら 403 を返す
大規模での勘所
- マルチテナント — テナント越境を根本から防ぐ設計（テナントIDを全クエリに）
- 最小権限の運用 — 権限の棚卸し、期限付き付与、アクセスレビュー
- 認可のキャッシュと失効 — 判断のキャッシュは便利だが、権限変更の反映が遅れる
- 監査ログ — 誰が何を許可・拒否されたか追える状態
やさしく言うと（中級）
- RBAC vs ABAC — まずRBAC、細かい制御が要ればABACを足す
- 垂直と水平 — 垂直＝上位権限への昇格を防ぐ／水平＝他人の同種データへの越境を防ぐ
- スコープで範囲を絞る — OAuthではトークンのスコープで「できる操作の範囲」を限定する（※1）
- 最小権限 — 既定は拒否（deny by default）、必要な分だけ許可
- サーバで必ず確認 — 画面でボタンを隠すのはUXであって認可ではない
⚠️ 落とし穴
- IDOR — 所有者チェック漏れで他人のリソースへ
- 混乱した代理（confused deputy） — 権限を持つ仲介を騙して代行させる
- テナント越境 — フィルタ漏れで別テナントのデータが見える
- 過剰スコープのトークン — 必要以上の権限が漏洩時に致命的
やさしく言うと（中級）
- IDOR — IDを差し替えるだけで他人のデータにアクセスできる（所有者チェック漏れ）
- 認可漏れ — 一部のAPIだけチェックを忘れる
- 権限昇格 — ロールや属性の判定ミスで上位操作ができてしまう
関連する知識
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. 「AさんはこのフォルダのオーナーでBを編集者に招待した」のような関係で権限を決める方式は？
問2. 認可ロジックをアプリから切り出し、ポリシーとして一元管理する仕組みは？
問3. ABAC（属性ベースアクセス制御）の説明として正しいのは？
問4. 「混乱した代理（confused deputy）」とはどんな問題か？
問5. マルチテナント環境でテナント越境を根本から防ぐ設計に近いのは？
問6. 認可判断をキャッシュするときの注意点として正しいのは？
問7. 所有者チェック漏れで、URLなどのIDを差し替えると他人のリソースにアクセスできてしまう脆弱性を、英字4文字の略語で答えてください。
問8. OPAで認可ポリシーを記述するために使う専用言語を何と言いますか。