概要
会員サイトや業務システムを新しく作る際、発注側が決めるべきなのは「ログイン機能を付けるか」だけではありません。利用者、社内担当者、委託先が、どの情報を、どんな条件で扱えるかまで要件にします。この記事では、その判断を開発会社へ伝える権限表と、納品時の確認事項を整理します。
OWASP（オワスプ）は、ソフトウェアの安全性を高めるための資料やツールを無料公開する非営利団体です。
OWASPの紹介
認証と認可は別の確認
認証は、利用しようとする人やシステムが、そのアカウントの正当な利用者かを確かめることです。認可は、確認したアカウントに、対象の情報や操作を許すか決めることです。ログインできても、他社の請求書や他人の注文を読めてよいわけではありません。画面でボタンを隠すだけでなく、情報を返す側で権限を確かめる設計が必要です。OWASPの認証解説・認可解説
確認された事実：アカウントと接続が関わった2つの事例
ビックカメラ.comの2010年の事例では、一部会員のID・パスワードによる不正な接続と、20件のポイント不正使用が確認されました。発表から認証情報の入手方法は分かりません。当時の再開対応を、そのまま現在の実装方法として勧めるものでもありません。同社の発表「1」
LINEヤフーの2023年の事例では、双方の委託先企業の従業者が所持するPCの感染が契機となったと説明されています。同社は、共通の従業者認証基盤で管理するシステムへのネットワーク接続を許可していたことと、関係会社のシステムを介した不正アクセスも説明しています。同社の更新発表「発生した事象」
前者は会員アカウント、後者は組織をまたぐ認証基盤と接続の事例です。「本人として扱う根拠」と「そこから許す操作範囲」を分けて考える参考になります。両事件に同じ認可不備があったとは判断しません。
一般化したリスク：ログイン後にも境界がある
以下は個別事件の原因の断定ではなく、同種のシステムを設計する際の論点です。正しい認証情報が不正使用された場合、通常のログイン判定を通る可能性があります。また、本人確認に成功しても、注文番号や所属先を変えた要求で別の利用者の情報を取得できれば、認可の境界を越えます。顧客、部署、委託先、管理者の境界を要件から落とさないことが出発点です。S-01・S-02
推奨する設計と選択判断
最初に「誰が・何を・どこまで」の要件を決める
本記事では、画面一覧を作る段階で、操作対象と権限も一緒に決めることを勧めます。例えば予約サービスなら、次のように書きます。これは説明用の例であり、各社の業務に合わせて変更します。
| 利用者 | 対象 | 許す操作と条件 |
|---|---|---|
| 会員 | 自分の予約 | 内容の確認。取消しは受付期限内だけ |
| 店舗担当 | 自店舗の予約 | 受取状況の更新。ほかの店舗は対象外 |
| 本部管理者 | 担当業務に必要な予約 | 一覧と集計。全件出力は別の承認を必要とする |
「担当者だから閲覧可」だけでなく、所属店舗、所有者、受付期限といった条件を書きます。細分化すると運用は複雑になりますが、全員に管理者権限を渡すと区別した意味がなくなります。発注側は例外を承認する人と、異動・退職時に権限を解除する人まで決めます。最小権限の考え方を業務に落とし込む設計判断です。S-02
APIとファイルにも同じ境界を適用する
OWASPは、許可の根拠がない要求は拒否し、すべての要求で権限を確かめる方針を示しています。画面を経由しないAPI、CSV出力、添付ファイルの取得にも適用します。開発側では共通処理で確認漏れを減らしつつ、個々の情報が誰に属するかも確認します。S-02
受け入れ時は、開発環境に会員A・B、店舗A・B、管理者の試験用アカウントを用意します。AがBのデータを読む、一般会員が管理者の処理を呼ぶ、といった許してはいけない操作が拒否され、データが変更されないことを確認します。正常なログインだけを試して完了にはしません。
本人確認を強める操作と、復旧方法を決める
多要素認証は、パスワード以外の要素も使って確認する方法です。OWASPは多要素認証や試行回数の制限、重要操作時の再認証を扱っています。S-01
新規開発では、管理者ログイン、送金先・連絡先の変更、全件出力など、侵害時の影響が大きい操作を先に列挙して、追加確認の対象を決めます。追加確認は利用者の手間と問い合わせを増やすため、端末紛失時の復旧と問い合わせ担当者による本人確認も同時に設計します。復旧経路だけが簡単な確認に置き換わらないか、通常のログインと合わせて試験します。
ログイン状態を終わらせる条件を持つ
セッションは、ログイン後の利用者を継続して識別する仕組みです。OWASPは、無操作時と一定時間経過後の期限を設け、ログアウトや期限切れをサーバー側でも反映することを示しています。S-03
本記事では、管理者と一般会員で利用場面を分けて期限を決め、パスワード再設定、権限変更、不正利用の申告時にも既存のログイン状態をどう失効させるかを要件化します。短すぎる期限は入力途中の作業を妨げるため、重要操作の再確認や入力の一時保存と組み合わせます。試験では、ログアウト前の接続情報を使って保護されたデータに再アクセスできないことを確かめます。