管理者向け / 第5章 認証と認可

ページ 3 / 6

第5章セキュリティ

約5分で読む

認証と認可

「ログインできたのに、どうしてこのデータは開けないの?」

本人の確認と操作の許可を分けて、アクセスを断られる理由を見てみましょう。

  1. 01思い込み

    ログインできた!

    認証は通過

    これで中のデータは何でも見られるはず!

  2. 02予想外

    あれ、開けない

    403 Forbidden

    『権限がありません』って、どういうこと?

  3. 03理由

    関所は2つある

    誰? → してよい?

    本人の確認と、その操作をしてよいかの確認は別なんだ。

  4. 04捉え直し

    ログインと許可は別

    拒否の理由を確認

    ログインできても、操作できる範囲は別に確かめるんだね。

この章の合言葉

本人確認と操作の許可は別。必要な権限だけを渡す。

※本人を確かめるのが認証、操作を許可するのが認可です。この章はログインが必要な操作を例にしています。

読みはじめる

認証と認可はどう違う?

ログインできたのに『権限がありません』と断られた経験はありませんか。入口を通ることと、その先で何をしてよいかは、別々に確かめられているのです。ビルなら、受付で身分証を見せるのが認証、通行証で入れる部屋が決まるのが認可です。

保護された操作で行う2つの確認

いいえはいいいえはい
認証あなたは誰⁠?
認可してよい⁠?
実行
利用者操作したい人
システムの関所2つの確認
通さない止める結果
アクセスしたい
あなたは誰⁠?認証=本人確認
資格情報を確認401 = 有効な資格情報がない
それをしてよい⁠?認可=権限の確認
実行を拒否403 = 許可できない
実行できる成功応答の例⁠:200
  • 焦点

各工程・分岐・レーンをクリックすると、その仕組みの説明がここに表示されます。

この図をテキストで読む

業務フロー図「ログインが必要な操作の例 — 本人と権限を確認」。レーン3本、工程6個。 【レーン(担当)】(左から右) - 利用者: 操作したい人 - システムの関所: 2つの確認 - 通さない: 止める結果 【図の符号】色つきの工程=焦点 【工程】(上から下へ。担当 → 工程名) ── フェーズ: 認証(あなたは誰?) ── 1. 利用者: アクセスしたい〔開始・終了〕 2. システムの関所: あなたは誰?〔分岐〕(認証=本人確認) いいえ → 資格情報を確認 はい → それをしてよい? 3. 通さない: 資格情報を確認〔開始・終了〕(401 = 有効な資格情報がない) ── フェーズ: 認可(してよい?) ── 4. システムの関所: それをしてよい?〔分岐〕(認可=権限の確認) いいえ → 実行を拒否 はい → 実行できる 5. 通さない: 実行を拒否〔開始・終了〕(403 = 許可できない) ── フェーズ: 実行 ── 6. 利用者: 実行できる〔開始・終了〕(成功応答の例:200)

本人の確認と操作の許可は別。拒否の理由は応答やログで確かめます。

認証 と 認可 を見くらべる(早見表)

各セルをクリックすると、その意味や詳しい説明がここに表示されます。

この図をテキストで読む

比較表。2列 × 6行。 【列】 1. 認証(Authentication) 2. 認可(Authorization) 【比較】(観点ごとに) ■ 問い - 認証: あなたは誰? / 本人確認 - 認可: それをしてよい? / 権限の確認 ■ 順番 - 認証: ログイン時・要求時 / 有効性の確認は続く - 認可: 対象・操作ごと / 毎回確認 ■ 確かめる材料 - 認証: 認証要素・セッション等 - 認可: 役割・権限設定・持ち主か ■ 失敗したら - 認証: 401等 / 有効な資格情報がない - 認可: 403等 / 権限やアクセス条件を確認 ■ しくみ・例 - 認証: ログイン・MFA・SSO・セッション - 認可: 役割(RBAC)・最小権限・行レベルセキュリティ(RLS) ■ つまずきやすい点 - 認証: なりすまし・通行証の盗難 / 取得後も守る - 認可: 権限の渡しすぎに注意 / 最小権限で 【観点】 - 認証だけ見る: 認証 - 認可だけ見る: 認可

混同しやすい2語を6つの観点で見くらべます。

他人の申請書を開こうとすると?

AさんがURLのIDをBさんの申請書へ書き換えたとします。ログイン済みでも、Bさんの情報を読む権限はありません。サーバは本人と対象の閲覧権限を照合し、許可がなければ拒否します。

他人の申請許可なし
Aさんログイン済み
サーバで認可対象と権限を照合
閲覧を拒否申請書は返さない
この図をテキストで読む

構成図「本人でも、許可のない情報は返さない」。ブロック3個、つながり2本。 【ブロック】 - Aさん: ログイン済み - サーバで認可: 対象と権限を照合 - 閲覧を拒否: 申請書は返さない 【図の符号】橙の淡い塗り=注意・課題

対象と操作ごとに許可を確認する

画面でボタンを隠しても、要求を直接送ることはできます。そのため認可は画面任せにせず、サーバ側で操作ごとに確かめます。

「見られる」と「承認できる」も分ける

申請システムでは、担当者は自分の申請を編集し、上司は担当範囲の申請を承認する、といった分担があります。全員に管理者権限を渡すと仕事は進めやすく見えますが、誤操作やアカウントの乗っ取りで影響する範囲も広がります。

必要な情報と操作を役割ごとに整理し、その業務に必要な最小限の権限だけを渡します。これが最小権限の原則です。異動や退職、臨時作業の終了に合わせて見直し、不要な権限を外すところまで運用に含めます。

押さえておきたい用語

認証(Authentication)
本人や資格情報を確かめること。ログイン後もセッション等の有効性を確認する。有効な資格情報がない場合の応答例は401。
認可(Authorization)
対象の操作や情報へのアクセスを許すか決めること。匿名のアクセスを許す場合もある。403は拒否を表すが権限不足に限らない。
アクセス制御
利用者や通信の条件に応じて、対象への操作を許可・拒否する仕組み。認証・認可等を組み合わせる。
役割(RBAC)
役割(管理者・一般など)ごとに権限をまとめて割り当てる方式。1人ずつ設定するより管理しやすい認可の定番。
最小権限
各人に必要最小限の権限だけを与える原則。乗っ取られたときの被害を小さく抑えられる。
行レベルセキュリティ(RLS)
テーブルの行単位でアクセスを絞るデータベースの認可機能。『自分の行だけ』見られるように制限する。
ページ 3 / 6