業務システムの権限はどう決める？請求書の登録・承認と異動時の見直し

権限とは、本人確認の後に「何をできるか」を決めること

認証は、そのアカウントを使う本人かどうかを確かめることです。権限は、その利用者が対象の情報へどの操作を行えるかという条件です。同じシステムへログインできる人でも、請求書を登録する人と承認する人が同じ操作をできるとは限りません。

OWASPの権限設計の資料も、認証と権限を区別し、利用者・対象・操作を業務の状況に合わせて整理する考え方を示しています。役割の名前やログイン成功だけを、操作の許可に置き換えないための参考です。OWASPの権限設計の説明を読む

社員IDの接続、追加の本人確認、端末を使えないときの復帰は、システムへ入る前後の別の設計です。本稿では、本人確認ができた後の請求書の操作へ焦点を絞ります。ログインの設定を変えただけで、支店ごとの閲覧範囲も直ったとは判断しません。

請求書一件の仕事を、登録・確認・承認・経理の参照へ分ける

最初に、購買担当と購買責任者から、請求書一件をどのように扱うかを聞きます。次は仕事を説明するための順序です。この架空例で、実際に登録から承認まで完了した記録ではありません。

1. 購買担当が下書きを用意する。誰が登録し、どの支店の請求書として扱い、誰が内容を直すのかを聞きます。仕入先、金額などの実値を説明用資料へ写す必要はありません。
2. 内容を確認する。請求書と取引の内容を誰が照合し、差し戻す必要があれば誰へ返すかを聞きます。内容の確認と、システム上の承認操作を同じ仕事と決めつけません。
3. 責任者が承認を判断する。誰の担当範囲を承認できるか、自分が登録した請求書も承認してよいか、承認後の変更をどう扱うかを業務責任者へ確認します。
4. 経理が必要な請求書を参照する。承認済みの内容を見るだけか、修正や出力も必要かを分けます。経理という役割名から、全支店の編集権限まで自動で付けません。

支払処理、会計仕訳、税務上の判断まで必要なら、それぞれの担当と条件を追加で確認します。この例に記録されていない処理を、今回の発注範囲や権限へ黙って加えないでください。

役割・操作・対象の範囲と状態を、ひとまとまりにする

「購買担当は編集できる」という説明には、どの請求書を、どの状態で編集できるかが足りません。担当支店の下書きなのか、別支店の下書きなのか、承認後の請求書なのかで、判断が変わります。

役割

購買担当、承認する責任者、経理など、業務で担う仕事です。役職名と一対一で決まるとは限りません。

操作

登録、閲覧、編集、承認などです。一つを許すときに、別の操作も含めないようにします。

対象の範囲

担当支店だけか、別支店も含むかなど、どのデータを扱えるかです。所属が同じでも担当範囲が違うなら、その条件も必要です。

対象の状態

下書きか承認済みかなどです。下書きの編集を許しても、承認後の編集まで許すとは限りません。

開発会社へは、例えば「購買担当が、担当支店の請求書の下書きを登録する」のように、役割と操作と対象を同じ文で渡します。別支店の閲覧や承認後の編集が未決なら、その点と判断する担当を示します。

画面のボタンを隠すだけで十分かも確認が必要です。詳細画面、検索、出力、通知、APIなど別の経路でも同じ範囲が適用されるかを、開発会社へ尋ねます。OWASPは、対象となる情報と操作についてリクエストごとに権限を確かめる考え方を示しています。本稿は具体的な実装や安全性の検証結果を認定するものではありません。

架空例の「許す案・許さない案・未決定」を近くで読む

以下は、担当支店の購買担当・責任者と、経理担当の提案を比べる架空例です。購買担当の登録と承認、経理の閲覧と編集は別の操作です。登録を許す案があっても、承認や別支店の閲覧を許したことにはなりません。

この例の経理担当には、対象となる支店の条件が記載されていません。全社の請求書を見られると補わず、どの支店・担当範囲を扱うかも確認します。元の資料に条件がないことと、閲覧を禁止したことを混同しないでください。

登録する人と承認する人を分けるか、業務責任者が決める

この架空例では、担当者の登録を許し、その担当者による承認は許さない案を置いています。一方で、責任者による承認を許す案があります。これは検討用の役割分担で、実際にその権限で運用しているという意味ではありません。

業務責任者には「自分が登録した請求書を自分で承認してよいか」「別の人が確認すべき内容は何か」「責任者も登録する場合はどうするか」を聞きます。業務上の判断を先にそろえてから、その決定を開発会社へ伝えます。

NIST SP 800-53の職務分離の考え方も、分ける必要がある職務を組織で特定し、その分担を支えるアクセス権限を定めるものです。すべての会社で同じ二人制にするという説明ではありません。本稿では、登録と承認を分ける必要と条件を業務責任者へ尋ねる参考にしています。NISTの原典と現行カタログを確認する

誰にどの仕事を任せるかという業務判断、その条件をどの役割やデータ範囲で実装するかという技術判断、実際に設定を変える作業を分けます。「業務責任者が了承した」だけで、画面やAPIの制御まで設定できたとは扱いません。

異動では、新しい権限だけでなく古い権限と未処理の仕事を確認する

購買担当が別部署へ異動するときは、新しい仕事に必要な権限だけを足して終わりにしません。異動前の支店の請求書を引き続き扱う必要があるか、未処理の請求書を誰が引き継ぐか、古い権限をいつ外すかを決めます。

1. 変更の依頼を受ける人を決める。誰から異動の連絡を受け、対象者・異動日・担当する仕事を何で確かめるかを、運用担当とそろえます。
2. 業務責任者が、残す権限と外す権限を判断する。未処理の引継ぎが必要なら、対象の請求書、引継ぎ先、残す期間や終了条件を具体化します。古い役割を無期限に残す案へ自動で広げません。
3. 設定担当と、変更する場所・時点をそろえる。利用者への役割割当だけか、所属支店の情報や個別の例外設定も関係するかを確認します。ログイン用のアカウントを止めることと、個別業務の権限を変えることも分けます。
4. 変更後の操作と、残っている権限を確かめる。新しい仕事を行えるか、外したはずの支店や操作が使えないかを、許可された確認方法で照合します。変更依頼の受付や設定連絡だけで完了にはしません。

NISTのアカウント管理の説明にも、人の異動・退職と管理の手続きを整合させる観点があります。本稿の架空例では解除の時点や実施結果は未確認のため、具体的な期限や解除成功は追加していません。実際の管理者、会社の運用条件、使う製品で必要な変更先を確認します。

兼務や代理は、必要な範囲と終わり方を別に決める

同じ人が購買担当と責任者を兼ねる場合、二つの役割を足した結果、本人が登録して承認できてしまわないかを確認します。役割の一覧だけでなく、組合せたときに業務上の分担が保たれるかを、業務責任者と開発会社に確かめてもらいます。

休暇中の代理が必要なら、誰のどの請求書へ何の操作を許すか、開始と終了の条件、代理であることの記録、終了時に外す担当を決めます。対象者のアカウントを共有すれば済むという前提にせず、実際の製品で使える方法と責任の残し方を確認します。

役割の種類を増やす方法と、所属・担当範囲・期限などの条件で絞る方法には、管理や試験の違いがあります。「支店の数だけ役割を作る」「高機能な権限設定画面を最初から作る」と決めず、必要な仕事と変更の頻度を伝えて案を比べます。製品の標準機能で足りる部分、追加対応、運用上の制約を開発会社へ聞いてください。

図で、請求書と三つの役割、未決定の操作を対応させる

図を原寸で開く

図を読んだ後の行動：業務責任者へ未決定の操作と対象範囲を聞き、IT担当へ変更する場所・担当・時点を確認します。回答を反映した条件で、許す操作と許さない操作を試す段取りへ進めます。

合意した条件を、できる操作・できてはいけない操作の両方で確かめる

提案が業務上の条件として合意できたら、IT担当と開発会社が試験を準備します。対象の版、許可された環境、試験用の利用者と請求書、役割、所属・担当範囲、下書きか承認済みかをそろえます。実在の請求書や他人のアカウントへ無断で操作する確認ではありません。

1. 許すことに決めた操作を試す。対象の役割でログインし、合意した範囲の請求書を登録・参照・承認できるかを、操作ごとに確かめます。管理者で全部動く結果を、各役割の結果へ流用しません。
2. 許さないことに決めた操作を試す。担当者が承認できない条件などを、合意した期待結果と照合します。対象外の支店、承認後の編集、別の画面や出力経路など、今回必要な範囲も確認します。未決定の操作は、先に判断を求めてから試験条件にします。
3. 異動や代理の変更後を確かめる。変更依頼と決定内容、設定の記録、実際の操作結果を対応させます。新しい権限が使えることだけでなく、外すと決めた旧権限が残っていないかも確認します。

結果は「合意した条件」「実際に行った操作と結果」「残った未確認」を分けて残します。ボタンが見えないことと、別経路でも操作できないことは同じではありません。満たさない結果が出たら、業務責任者と開発会社へ差を示し、条件の誤りか設定・実装の修正が必要かを相談します。

修正の連絡が来ても、その連絡だけで合格にせず、変更に関係する役割・対象・操作を同じ前提で再確認します。運用を始めた後も、異動や兼務、対象データが変わったときに、決めた条件と実際の権限を見直す担当を置いてください。一般的な受入操作の組立ては、受入テストの対象と期待結果を決める方法も参照できます。

まとめ：請求書一件と登場する人から、権限と変更の条件を決める

最初の一歩は、請求書一件について、購買担当・承認する責任者・経理が何をするかを並べることです。役割、登録・編集・閲覧・承認、対象の支店と請求書の状態をそろえ、許す案・許さない案・未決定を区別します。

業務上の承認と、システムへの設定、操作で確かめた結果も別です。異動では、新しく渡す権限だけでなく、外す権限、未処理の引継ぎ、変更後に確認する担当まで決めます。未確認を、許可済み・設定済み・確認済みへ書き換えないでください。

まず購買責任者と、担当支店の登録・承認、別支店の閲覧、承認後の編集を話してください。決まらない項目は判断する担当と質問を残し、開発会社へ実現方法・制約・確かめ方を同じ条件で尋ねます。