社内の顧客情報、全員に見せて大丈夫？権限管理と操作履歴の決め方

「全員に共有」と「担当者しか見られない」の間を作る

説明用の例として、営業、経理、外部の作業スタッフが同じ案件を扱う会社を考えます。営業は顧客の要望、経理は請求先、作業スタッフは訪問場所を知る必要があります。同じ案件だからといって、全員に仕入原価や全顧客の連絡先まで見せる理由にはなりません。仕事に必要な項目と、担当する案件の範囲を重ねると、共有する単位を小さくできます。

まず守りたい情報を選び、それぞれを使う人に用途を聞きます。閲覧できても金額の訂正はできない、担当案件を見られても全件出力はできない、と分けると、日常業務を妨げず制限を設けられます。OWASPも必要最小限の権限を推奨しています。ただし細分化するだけで終わらせず、担当者が付与理由を説明できる粒度にすることが運用の条件です。

参考：OWASP Foundation：Authorization Cheat Sheet

管理者を増やす前に、任せたい操作を分ける

困ったときに全員を管理者にすれば、権限の問い合わせは減るかもしれません。しかし一件の請求訂正のために、利用者の追加や他部門の削除まで許可することになります。説明用の例では、経理へ請求情報の訂正を認めつつ、受注明細の変更は営業の再申請にする案が考えられます。システム設定を管理する人と、取引を承認する人も同じとは限りません。

次の比較は、実際の案件に合わせて調整するための考え方です。利用者数だけで決めず、担当替えや外部スタッフの参加がどれほどあるかを見ます。個人名ごとの特例を増やし続けるより、役割と案件の所属を組み合わせた方が、交代時に何を変えるべきか説明しやすくなります。

表が収まらない場合は横にスクロールできます。

一覧から消しても、情報を守れたとは限らない

画面の列を非表示にしても、別のURLや検索、添付ファイルから情報を取れるなら、閲覧制限として不十分です。OWASPはリクエストごとの権限確認と、サーバー側での制御を求めています。発注側は仕組みの詳細をすべて決める必要はありませんが、「一覧・詳細・検索・出力で同じ範囲になるか」を、試験結果として確認できます。

データベースに行単位の制御を設ける方法もあります。PostgreSQLの公式資料では、強い権限を持つロールや通常のテーブル所有者などが制御の対象外になる条件が示されています。採用している技術名だけでは保護を判断できません。通常利用で使う接続と保守用の接続が違うかも含め、許可しない情報が返らないことを開発会社に確かめてもらいます。

参考：OWASP Foundation：Authorization Cheat Sheet ／ PostgreSQL Global Development Group：PostgreSQL Documentation: Row Security Policies

異動と代理対応の日に、権限の使いやすさが分かる

説明用の例として、部門長の休暇中だけ別の人が承認するとします。代理者に無期限の権限を加えると、休暇が終わっても承認できる状態が残ります。代理の対象、期間、依頼者を記録し、終了時に外す手順が必要です。本人の申請を代理権限で自己承認できないかも、通常の承認とは別に確かめます。

異動では、以前の案件を引き続き見る必要があるかを判断します。単に部署を変更すると、過去履歴が急に見えなくなる場合も、古い所属の情報を見続ける場合もあります。退職や外部委託の終了時は、既存のログイン状態や発行済みの共有リンクまで確認対象です。付与する操作だけでなく、権限を外した直後に何ができなくなるかを試すと、実際の運用を評価できます。

「誰が変えた？」に答えるための記録を残す

顧客の請求先や単価が変わったとき、ログイン履歴だけでは変更理由を説明できません。必要なのは対象の取引、操作した人、時刻、変更内容、理由、結果のつながりです。自動処理で変わった場合も、どの処理かを識別できるようにします。手動で再実行した操作なら、依頼者と実施者を記録すると後から経緯をたどれます。

OWASPのログ指針は、調査に必要な情報を残す一方、パスワードやアクセストークンなどの秘密情報をそのまま記録しないよう示しています。顧客情報を丸ごと複製すればよいわけではありません。記録を読む人、変更や削除ができる人、保存の期間も決めます。ログの存在が不正操作を防ぐのではなく、権限制御と事後確認を組み合わせて役立てます。

参考：OWASP Foundation：Logging Cheat Sheet

依頼先には、見えないことと調べられることを見せてもらう

試験では担当案件、他部門の案件、担当を外れた案件を用意し、同じ人が検索や出力を試します。成功する操作だけでなく、禁止した操作が拒否されることを確認してください。次に、請求先を変更した一件をログから探し、いつ誰が何を直したかを業務担当者が説明してみます。保存されていても取り出せない記録では、問い合わせ対応に使いにくいためです。

見積もりに含めたいのは、権限設定画面だけでなく、この試験、代理や異動の手順、記録の検索と引き継ぎです。権限の組み合わせや例外が増えるほど、改修後の確認も増えます。費用を抑えるなら必要な役割を絞りつつ、守るべき情報や操作まで省かないようにします。導入後は利用者一覧と現在の仕事を照らし、不要になった権限を見直せる担当者を置きましょう。

検討・発注前のチェックリスト

担当者と確認状況を添えて、社内の検討メモや打ち合わせの議題にご活用ください。

確認日：________________ / 担当者：________________

• □共有する情報ごとに、使う人と用途を確かめる。確認状況・メモ：
• □閲覧・編集・承認・出力を分けて考える。確認状況・メモ：
• □他部門の検索結果や添付から情報が見えないか試す。確認状況・メモ：
• □異動・退職・代理終了時の失効を確認する。確認状況・メモ：
• □一件の変更理由を記録からたどれるか試す。確認状況・メモ：
• □ログの閲覧者、保存期間、記録しない秘密情報を決める。確認状況・メモ：

よくある質問

参考資料

製品の仕様・提供条件は変更されることがあります。採用時には公式資料と契約内容をご確認ください。

• Authorization Cheat SheetOWASP Foundation
• Logging Cheat SheetOWASP Foundation
• PostgreSQL Documentation: Row Security PoliciesPostgreSQL Global Development Group