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