理Kotowary

認可（ログイン後の権限）— 「何をしてよいか」を決める

大人こども
初級中級上級

概要 — まず全体をつかむ

初級では認可を「入れる部屋は役職次第」と捉えました。中級では、制御モデルと、サーバ側での必須確認を見ます。

詳細 — 1段階ずつ追う

これは何をする係？

権限の決め方には代表的な2方式があります。

  • RBAC（ロールベース） — 「管理者・編集者・閲覧者」などロールに権限を束ね、利用者に割り当てる
  • ABAC（属性ベース） — 部署・所有者・時間帯などの属性で、より細かく判断する

登場人物メモ:

  • ※1 スコープ — トークンに載る「できる操作の範囲」（OAuth）
  • ※2 所有者チェック — 「そのデータの持ち主か」を確認すること
アニメーション『RBAC（ロールで権限を束ねる）』を開く
利用者ロール権限佐藤鈴木田中管理者編集者閲覧者削除できる編集できる閲覧できる割り当て上位ロールは下位の権限も含むロールに権限をまとめ、利用者にロールを割り当てる
この部分をもっと深く（上級）
  • RBAC — ロールで束ねる（シンプル、粗い）
  • ABAC — 属性（部署・時間・所有者）で細かく
  • ReBAC — オブジェクト間の関係グラフで判断（共有・招待・ネストに強い。Zanzibar）
  • ポリシーエンジン — OPA/Regoなどに認可を集約し、コードから分離
やさしく言うと（初級）

入館証（認証）を持っていても、入れる部屋は役職によって違いますよね。それが認可です。操作の前に「この人にこの権限があるか」を確認し、なければ断ります（※1 403）。

アニメーション『認証と認可の違い』を開く
認証と認可 — 順にくぐる2つの門別々のチェック。①で本人確認 → ②で権限確認あなたアクセスしたい人認証OKなら次の門へ①認証Authentication「あなたは誰？」身分証で本人確認する確認に使うものパスワード／パスキー②認可Authorization「何をしてよい？」権限で可否を判定する判定に使うものロール（役割・権限）✓ 操作を実行許可された範囲で✗ 認証で拒否（401）そもそも本人確認できず✗ 認可で拒否（403）本人だが、その権限がない認証＝誰か（本人確認）／認可＝何ができるか（権限）。認証を通っても、管理者ページのように権限がなければ弾かれる

登場人物メモ:

  • ※1 403（権限なし） — 本人だが、その操作は許されていない
  • ※2 ロール（役割） — 「管理者」「一般」など、権限のまとまり

仕事の流れ

  1. 認証で「誰か」を特定する
  2. リクエストのたびに ポリシー評価（ロール／属性／所有者）
  3. サーバ側で許可・拒否を判断する（クライアントの制御は飾りに過ぎない）
  4. 拒否なら 403 を返す
この部分をもっと深く（上級）
  1. 認証で主体（誰）を特定
  2. リクエストのリソースと操作を特定
  3. ポリシー評価（集中エンジン or 分散）で許可／拒否
  4. トークンのスコープ／クレームや、リソースの所有関係を照合
やさしく言うと（初級）
  1. ログイン済みの人が、ある操作をしようとする
  2. サーバが「この人（の役割）に、この操作の権限があるか」を確認する
  3. あれば実行、無ければ拒否（403）

設計の勘所

  • RBAC vs ABAC — まずRBAC、細かい制御が要ればABACを足す
  • 垂直と水平 — 垂直＝上位権限への昇格を防ぐ／水平＝他人の同種データへの越境を防ぐ
  • スコープで範囲を絞る — OAuthではトークンのスコープで「できる操作の範囲」を限定する（※1）
  • 最小権限 — 既定は拒否（deny by default）、必要な分だけ許可
  • サーバで必ず確認 — 画面でボタンを隠すのはUXであって認可ではない
この部分をもっと深く（上級）
  • マルチテナント — テナント越境を根本から防ぐ設計（テナントIDを全クエリに）
  • 最小権限の運用 — 権限の棚卸し、期限付き付与、アクセスレビュー
  • 認可のキャッシュと失効 — 判断のキャッシュは便利だが、権限変更の反映が遅れる
  • 監査ログ — 誰が何を許可・拒否されたか追える状態
やさしく言うと（初級）
  • 認証と認可は別 — 認証＝「誰か」、認可＝「何してよいか」。ログインできても、できることは人による
  • 最小権限 — 仕事に必要な分だけ権限を渡す。万一奪われても被害を小さくできる

⚠️ うまくいかないとき

  • IDOR — IDを差し替えるだけで他人のデータにアクセスできる（所有者チェック漏れ）
  • 認可漏れ — 一部のAPIだけチェックを忘れる
  • 権限昇格 — ロールや属性の判定ミスで上位操作ができてしまう
この部分をもっと深く（上級）
  • IDOR — 所有者チェック漏れで他人のリソースへ
  • 混乱した代理（confused deputy） — 権限を持つ仲介を騙して代行させる
  • テナント越境 — フィルタ漏れで別テナントのデータが見える
  • 過剰スコープのトークン — 必要以上の権限が漏洩時に致命的
やさしく言うと（初級）
  • 認可漏れ — チェックを忘れ、他人のデータが見えてしまう（重大事故の定番）
  • 権限昇格 — 一般利用者が管理者の操作をできてしまう

関連する知識

理解度チェック

そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。

問1. 「役割（ロール）に権限をまとめ、利用者にロールを割り当てる」方式はどれ？

問2. URLのIDを他人のものに変えると、他人のデータが見えてしまう脆弱性は？

問3. 「既定は拒否し、必要な分だけ許可する」という原則を何と呼ぶ？

問4. OAuthのトークンに載る「できる操作の範囲」を何と呼びますか。カタカナで答えてください。

問5. 認証で「誰か」を特定した後に「何をしてよいか」を決める仕組みを、日本語二文字で何と言いますか。

問6. 認可でリクエストを拒否したとき、返すのに適したHTTPステータスはどれ？

問7. 「画面でボタンを隠す」ことは認可として十分か？

問8. 「水平方向の権限越境」に当たるのはどれ？