権限機能の検収方法｜見えない・操作できないを確認する

権限の検収テストでは、「担当者として必要な操作ができる」だけでなく、「許可されていない操作はできない」ことまで確認します。発注者が用意するのは、ロールごとの画面一覧だけではありません。ロール、対象データの所属、閲覧・作成・更新・削除・出力を交差させた権限受入票です。

とくに分けたいのが、自部署と他部署、そして「ボタンが見えない」と「直接実行しても拒否される」です。この分け方なら、納品物が合意した権限を満たすかを業務側でも判定できます。ただし、どこまでを当初の検収範囲とし、どこからを追加対応とするかは、見積依頼前の決め方に左右されます。

権限の検収テストは「許可」と「拒否」を対にする

権限確認では、正常に操作できた時点で合格にしてよいか迷いがちです。合格には、許可された経路と拒否される経路の両方の確認が必要です。許可されないロールや対象データでも同じ操作を試し、拒否されるところまでを一組にします。

2026年9月21日時点で、OWASPのAuthorization Cheat Sheetは、最小権限の設計にあたり、利用者種別、公開するリソース、閲覧・書込み・更新などの操作を列挙し、その組合せごとに許可する操作を決めることを推奨しています。また、設計時に割り当てた権限が正しく強制されているかを検証するテストの作成も推奨しています。

この考え方を納品時の受入へ落とすなら、次の二つを別の期待結果として記録します。

• 許可の確認：対象ロールで、合意した機能とデータを操作できる
• 拒否の確認：対象ロールでは許可されない機能やデータを指定しても、操作が成立しない

両方がそろって初めて、その行を合格にできます。「管理者なら更新できた」という結果は、一般担当者による更新が拒否されることの証明にはなりません。

発注者向けの権限受入票

以下は、小規模な業務システムの納品確認に使う運用上の提案です。公式資料が示すロール・対象データ・操作の考え方を基に、発注担当者が合否判定できる権限受入票へ組み直しています。実際のロール名、対象データ名、期待結果は、発注内容に合わせて置き換えてください。

表中の権限はあくまで条件例です。行を分ける基準には、「一般担当者」のようなロール名と、対象が自部署か他部署かという関係の両方を使います。作成に所属の区別がない設計なら「対象外」とし、曖昧な許可扱いにしません。

受入票には、各セルの許可・拒否だけでなく、試したアカウント、対象データ、操作結果、証跡、判定、備考を持たせます。これも運用上の提案であり、証跡は画面表示やエラーの記録など、発注者と開発会社が再確認できる形を事前に合意します。個人情報や機密情報が証跡へ不用意に残らない扱いも、合わせて決めておくとよいでしょう。

自部署と他部署を分ける理由は、ロール名が同じでも、操作対象との関係によって結果が変わるからです。2026年9月21日時点のOWASP Web Security Testing Guide v4.2は、同じ権限を持つ別利用者のリソースを操作できないかという水平検証と、上位または特定ロール向けの機能を操作できないかという垂直検証を分けています。IPAも2026年9月21日時点のアクセス制御や認可制御の欠落で、対象データを番号などで検索・変更する機能では、その対象がログイン中の利用者に許可されたものか常に確認するよう求めています。

したがって、「他部署メニューが表示されない」だけで他部署データの行を合格にしてはいけません。対象を変えた更新や出力が成立しないことを、別の受入結果として残します。

「見えない」と「操作できない」を別々に判定する

画面から削除ボタンが消えていれば、利用者には削除できないように見えます。では、その状態だけで拒否の確認は完了でしょうか。完了ではありません。

OWASP WSTG v4.2は2026年9月21日時点で、GUIだけで認可を検証し、機能側に認可検証を残さない実装は脆弱性につながり得ると説明しています。各ロールについて、ログイン後に実行される各機能・リクエストを対象に、別ロール向けの機能やリソースへアクセスできないか確認する手順も示しています。

そこで、拒否を期待するセルには、少なくとも次の二つの判定欄を設けます。

表示側の合格は、実行側の合格を兼ねません。反対に、実行が拒否されても、利用できない操作が画面に残って業務を迷わせるなら、表示要件としては不合格になり得ます。検収票で列を分ければ、「安全上は拒否されたが画面仕様と違う」「画面にはないが直接操作できた」という性質の異なる不一致を混同せずに扱えます。

ただし、発注担当者が独自に技術的な侵入試験を行うという意味ではありません。直接指定の具体的な手段、使用するテスト環境、許可された対象は、開発会社と合意して実施します。この受入は、納品時に合意済みの権限仕様を確認する範囲であり、技術顧問などが行うセキュリティ監査の代替ではありません。

見積依頼前に決める権限の境界

納品時に初めて受入票を作ると、「他部署の出力も禁止する想定だった」「削除ボタンを隠すだけだと思っていた」という解釈差が出ます。見積依頼前に、少なくともロール、対象データの区分、五つの操作、許可・拒否の期待結果を埋めます。要件全体の整理にはシステム要件定義のチェックリストも併用できます。

発注資料に含めたい条件は次のとおりです。

• ロール：誰を同じ権限として扱うか
• 対象データ：自部署・他部署など、所有や所属をどう区切るか
• 操作：閲覧・作成・更新・削除・出力のどれを許可するか
• 拒否時の期待：非表示にするのか、実行を拒否するのか、両方か
• 受入方法：用意するアカウントとデータ、確認環境、証跡、判定担当

この段階で空欄があれば、開発会社の実装判断へ委ねるのか、見積前に確定するのかを明記します。機能ごとの対象と受入方法が決まると、見積対象の読み違いも減らしやすくなります。依頼内容のまとめ方はシステム開発の見積もりを依頼するときの整理ポイントも参照してください。

納品時の進め方と追加範囲の判定

受入は、許可されるセルから始めて業務に必要な経路を確認し、その後、同じロールで拒否される対象へ切り替えます。次に対象所属を自部署から他部署へ変え、最後にロールを変えます。操作結果は、受入票の該当セルへ結び付けて記録します。順番そのものは運用上の提案ですが、一つの結果がどの条件の判定なのかを崩さないことが大切です。

不一致が出たら、すぐに「不具合」か「追加開発」かを決めつけず、合意済み資料と照合します。

判断の基準は、発注時に合意した範囲です。受入時に望ましいと感じた権限でも、資料にない項目を納品物の不備と扱えば修正範囲が曖昧になります。拒否と明記した操作が成立した場合は、合意との不一致を具体的なロール・対象・操作で示せます。

最終判定では、たとえば「一般担当者・他部署・出力」という一つの条件について、出力導線が見えず、直接指定でも出力が成立せず、証跡が受入票に結び付いているかを確認します。この条件が発注時の受入票にあれば合意との一致を判定でき、記載がなければ追加範囲を協議できます。ロール、対象所属、五つの操作を同じ粒度で記録しておくことが、発注者自身で合否と追加対応の境界を説明できる検収につながります。

費用、期間、契約、法務・税務上の扱いは条件により異なります。記事の確認日とリンク先の一次情報を確認し、個別判断は専門家へご相談ください。

システム開発・発注ガイドへ戻る