認証と認可の違い：「誰か」と「何ができるか」を分ける
ログインできることだけでは、データを見せてよい理由になりません。
ログインできる社員に、すべての資料を見せてよいわけではありません。この記事では「誰が、どの資料に、何をしてよいか」を権限表にし、開発担当者やサービス管理者へ渡せる確認条件を作ります。
公式資料から分かること：認証と認可は別の判断
OWASPは、認証を主体の身元の確認、認可を要求された行為が許可されるかの確認として区別しています。また、業務に必要な最小限の権限、原則拒否、要求ごとの権限確認を推奨しています。画面のボタンを隠すだけでアクセスを制御したことにはならず、サーバー側などでの確認が必要です。
公開記事のように、ログインせず閲覧を許可する情報もあります。「すべてにログインを要求する」ことより、対象と操作に合った許可条件を決めることが重要です。
仕事の具体例：原稿担当でも、他人の下書きは別
架空の社内記事サイトを考えます。執筆者は自分の下書きを編集でき、公開担当者は承認された原稿を公開できる設計にします。同じ「執筆者」でも、自分と他人の原稿を区別します。役職名だけでなく、担当関係や原稿の状態も条件になります。
- 社員：公開済みの社内記事を読める。下書きや公開操作は許可しない。
- 執筆者：自分の下書きを読んで編集できる。他人の下書きの編集や独断の公開は許可しない。
- 公開担当者：対象原稿を確認し、承認条件を満たしたものを公開できる。
これは説明用の設計例です。管理者だからすべての業務資料を読む必要がある、とは決めつけず、実際の仕事に合わせて条件を調整してください。
コピーして使える権限表
対象サービス／責任者：
利用者・役割 | 対象資料 | 状態・担当条件 | 許可する操作 | 許可しない操作
社員 | 社内記事 | 公開済み | 閲覧 | 編集・公開
執筆者 | 原稿 | 自分の下書き | 閲覧・編集 | 他人の原稿の編集・公開
公開担当者 | 原稿 | 承認済み | 公開 | 未承認原稿の公開
例外の承認者／期限：
確認ケース | 期待結果 | 実際の結果 | 確認日・環境
許可された利用者・資料・操作 | 成功 | 未確認 |
許可されていない組み合わせ | 拒否 | 未確認 |結果の確認ポイント
許可する操作が成功することだけでなく、禁止した組み合わせで内容を取得できず、変更も保存されないことを確かめます。画面で非表示でも、資料のURLやシステムへの要求が通るなら、権限表の目的を満たしていません。拒否メッセージに資料本文などが含まれないかも確認します。
動作確認は管理者の許可を得たテスト環境・テスト用アカウント・ダミー資料で行い、他人の実データや第三者のサービスへ無断で試さないでください。役割や機能を変えた際は、同じ確認ケースを再利用します。
今日試すこと
守りたい資料1種類を選び、閲覧・編集・削除・共有の4操作について許可条件を書いてください。不明な組み合わせは勝手に許可せず、資料の責任者へ確認する項目として残します。
参考資料
- OWASP｜Authorization Cheat Sheet：認証と認可の区別、最小権限、要求ごとの確認。