「一般ユーザーと管理者の2種類」と決めても、誰の申請を閲覧できるのか、承認済みの内容を直してよいのかは残ります。権限の要件は、人の役割・操作・対象との関係・対象の状態を組み合わせて書きます。
この記事は社内サービスの要件を整理する人向けです。架空の備品貸出申請を使い、開発担当へ渡す確認表を作ります。作例は権限要件の整理であり、この表だけで実装の安全性を保証するものではありません。
ログインできることと、操作してよいことを分ける
OWASPは、本人を確かめる認証と、要求された操作を許可する認可を区別しています。また、必要な最小限の権限を与え、明示的に許可されない操作は拒否し、要求ごとに権限を確認するよう推奨しています。Authorization Cheat Sheet
この考え方を、次の業務ルールに落とします。社員は本人の申請を確認し、所属長は担当部署の申請を承認し、総務は現物の貸出を管理する。総務担当だからといって、申請者に代わって用途を書き換えられるとは限らない、と分けて考えます。
役割だけの表から、条件付きの表へ
以下は説明用の案です。実際には部署の兼務や代理対応を含め、業務責任者と合意します。
| 操作 | 許可する人 | 対象・状態の条件 | 許可しない例 |
|---|---|---|---|
| 申請を閲覧（社員として） | 申請した社員 | 本人の申請 | 他人の申請 |
| 申請を閲覧（承認のため） | 担当部署の承認者 | 承認対象の申請と、判断に必要な項目 | 他部署、承認と無関係な項目 |
| 申請を閲覧（貸出管理のため） | 総務の貸出担当 | 貸出管理に必要な申請情報 | 運用目的と無関係な項目 |
| 申請内容を修正 | 申請した社員 | 本人の下書き・差戻し中 | 承認待ち・貸出中 |
| 利用を承認 | 担当部署の承認者 | 自分以外が申請した承認待ち | 他部署、自分自身の申請 |
| 貸出を確定 | 総務の貸出担当 | 手配済みで受取待ち | 未承認の申請 |
| 役割を付与 | 権限管理担当 | 承認された申請に基づく付与 | 貸出担当による自己付与 |
「自分自身の申請を承認できない」を入れたら、承認者本人の申請を誰が承認するかも必要です。この例では別に指定した上位承認者へ回す案とします。禁止だけ書いて代替経路を用意しないと、正当な利用が止まります。
一覧・添付・出力にも同じ対象範囲を持たせる
詳細画面に入れなくても、検索結果のタイトルやCSVから他人の申請が読めたら、閲覧範囲の要件を満たしません。表の「閲覧」を、一覧・検索・詳細・添付・出力という入口に広げて確認します。
OWASPの認可テスト自動化の資料では、役割やサービス、データの条件を権限の対応表として表現する方法を紹介しています。Authorization Testing Automation この記事では、その考え方を業務側の確認票に使います。特定の自動化ツールを導入する必要はありません。
画面上でボタンを隠すだけではなく、サーバーでも同じ許可条件を確認することを、開発側との合意に含めます。表示の都合で例外を増やさず、どの入口からでも業務上の境界が守られる状態を求めます。
異動と代理対応を、付与とセットで決める
権限は登録時だけの話ではありません。月曜に別部署へ異動した社員が、金曜に開いた画面から以前の部署の申請を承認できるかを考えます。この作例では、承認を受け付ける時点の担当部署と権限で判定し、古い画面を開いていても承認は受け付けません。
一方、申請時の所属を履歴として残すことと、現在の閲覧権限を決めることは別です。異動前の本人の申請を閲覧できるかは業務方針として明記します。兼務・退職・代理期限の終了でも、権限の見直し担当と反映時点を決めます。
次のレビューで確認すること
- 許可の根拠を「管理者だから」以外の言葉で説明できるか。
- 同じ役割でも、本人・他人・他部署で結果が変わるか。
- 下書き・承認待ち・完了後で、できる操作が変わるか。
- 一覧・検索・添付・出力にも対象範囲を適用したか。
- 代理権限の付与者、期限、解除方法が決まっているか。
まず一つの操作を選び、許可する例と拒否する例を並べてください。業務の受け渡しは業務フローと例外の整理、操作結果の確認方法は受け入れ条件の書き方につなげられます。