【メモ】認証、認可、秘密情報管理の落とし穴
はじめに
技術系の事故では、「ログイン機能はあるのに権限が甘い」「秘密情報が思わぬ場所に残る」といった形で問題が現れます。1
この章では、認証、認可、セッション、パスワード保存、秘密情報管理をまとめて整理します。
どれも別テーマに見えますが、実務では同じ「誰が何にどうアクセスできるか」の問題としてつながっています。
認証と認可は別の防御線
認証は「誰かを確認すること」、認可は「何を許すかを決めること」です。
ログインできることと、対象データへアクセスしてよいことは同じではありません。1
たとえば、次のような事故は認可の問題です。
- 他人のデータがIDを変えるだけで見える
- 一般ユーザが管理者機能へ入れる
- 本来編集不可のデータを変更できる
認証が強くても、認可が弱ければ守れているとは言えません。
セッション管理の弱さも事故につながる
認証後の状態を維持するセッション管理は、認証機能の一部として考えるべきです。
注意したい観点は次のとおりです。
- セッション識別子を安全に扱えているか
- 使い回しや固定化を防げているか
- 重要操作で再確認が必要ではないか
- ログアウトやタイムアウトが適切か
セッション管理が雑だと、「ログイン済みだから安全」と思っている箇所が突破口になります。
パスワード保存で考えること
平文や復号可能な形で持たない
パスワードは、読める形で保存しないことが基本です。1
「後で確認したい」「移行時に便利だから」といった理由で、復元可能な形を残す設計は危険です。
保存方法だけでなく運用も見る
保存時の方式が適切でも、ログ、例外メッセージ、デバッグ出力、テストデータに漏れていれば意味がありません。
秘密情報は、保存場所だけでなく、どこへ流れうるかまで見る必要があります。
秘密情報のハードコードが危険な理由
APIキー、接続文字列、秘密鍵、認証情報をコードや設定ファイルへ直接埋め込むと、次の問題が起きやすくなります。1
- リポジトリや配布物から漏れる
- ローテーションがしづらい
- 環境ごとの差し替えが雑になる
- 退職者や委託先のアクセス制御が難しくなる
秘密情報は、「使える状態でそこにある」だけで価値を持つため、見え方と管理のしやすさを両方考える必要があります。
鍵管理で意識したいこと
鍵やトークンの管理では、次の視点が重要です。
- どこに保管するか
- 誰が参照できるか
- いつ失効、更新するか
- 漏えい時にどう切り替えるか
安全な保管だけでなく、回せること、止められることも管理の一部です。
起こしやすい誤り
ログイン機能があるので安心する
認証があることと、認可が適切であることは別です。
画面遷移やID指定だけで別データへ届かないかを見る視点が必要です。
テスト用だから秘密情報を埋め込んでよいと思う
テストコード、サンプル、検証環境でも、後で残り続けると事故の入口になります。
秘密情報を設定ファイルへ置いただけで管理した気になる
どの環境で、誰が見られ、どう更新し、漏えい時にどう止めるかまで考えて初めて管理と言えます。
日常で意識したい原則
- 認証と認可を分けて考える
- セッション管理も認証設計の一部として扱う
- パスワードや鍵を読める形で持たない
- 秘密情報はコードや配布物へ埋め込まない
- 漏えい時に止められる運用を前提にする
ミニ確認
- 認証と認可の違いは何か
- セッション管理が弱いと何が起きうるか
- パスワード保存で見るべきは保存先だけか
- ハードコードされた秘密情報が危険なのはなぜか