誰を信用した瞬間に、何が壊れるのか

架空事例：建設機材を扱う青葉機材が、取引先向けに予約・返却システムを公開する。組織、権限、取引条件、攻撃例はすべて説明用であり、実在企業の被害や運用を示すものではない。

正しい利用者が、間違った予約を見た

取引先の担当者は、自分のアカウントでログインした。パスワードは合っている。通信もHTTPSで暗号化されている。ところが予約一覧の番号を一つ変えると、別の会社の明細が表示された。

認証は成功していた。暗号化にも失敗していない。問題は、表示してよい対象を決める判断が欠けていたことである。

「ログイン済みなら予約を表示できる」という規則では足りない。ログインした主体が、どの会社に属し、その予約に対して参照権限を持つのか。予約の番号を知っていることと、予約を読む権利があることは別である。OWASPの認可ガイドも、許可を既定とせず、要求ごとにアクセス可否を評価する考え方を示す。2

青葉機材は、この事故を「検索画面のバグ」としてだけ扱わないことにした。取引先の作業者、営業管理者、配送担当、保守会社が、それぞれ何を読む・変更する・承認するのか。業務モデルから権限を組み立て直す。ここにシステムアーキテクトの仕事がある。

保護対象は、データベースの中だけではない

守るべきものを「顧客テーブル」とだけ記述すると、取引先の秘密の一部しか見えない。貸出価格、建設現場の住所、契約条件、予約できる残数、現場で受け取る担当者の電話番号は、業務上の意味が異なる。

機密性が重要な価格と、改ざんされると誤配送になる納入先住所は、同じ対策だけで扱えない。さらに、「事故がなくても予約できない」という可用性の問題もある。三つを一括して「セキュリティを高める」と書けば、どの障害が事業に痛いのかを議論できない。

青葉機材は、情報そのものに加え、操作と結果も保護対象に含める。顧客が予約を確定する操作、営業が値引きを承認する操作、保守会社が機材の点検状態を更新する操作である。改ざんされた点検状態は、秘密が漏れていなくても事業の判断を誤らせる。

同じ技術でも防ぐ損失は異なる。暗号化は通信の機密性を助けるが、正当な営業担当者が誤った価格を入力する問題までは解決しない。バックアップは誤削除から戻す助けになるが、閲覧権限が広すぎる問題を修正しない。対策から考えるのでなく、先に失ってはいけない性質を定める。

信頼境界は、ネットワークの線とは限らない

ブラウザからAPIへ要求が届く。APIから予約サービスへ進み、予約サービスはデータベースと配送会社のAPIを呼び出す。図では四つの箱が矢印でつながるだけかもしれない。

しかし、信頼の前提は矢印ごとに変わる。ブラウザの表示項目を信用してよいのか。APIゲートウェイで認証した利用者の識別を、内部サービスがどこまで信じるのか。配送会社から戻った配達済みの通知を、本当に当該取引に対応するものと扱えるか。

あるサービスに届く識別子が内部ネットワークから来たという理由だけで正しい主体を表すとは限らない。転送ヘッダーの偽造可能性、代理実行時の利用者権限、サービス自身の権限を整理する。ネットワークを囲むことと、権限の伝播規則を設計することは異なる。

同じ境界の内側にも信頼できない値がある。取引先が入力した説明欄は、データベースへ保存された瞬間に無害な文字列へ変わるわけではない。後から営業画面へ表示するときには、再び外部由来の入力として扱う。誰が作った値かを失ったまま「内部DBから来たから安全」と考えると、入力と出力の双方で判断を誤る。

脅威から始めても、損失までは決まらない

「情報漏えい」という言葉を脅威とみなして対策表へ書くと、攻撃者が何をできるのか曖昧になる。ある利用者が他社の予約IDを推測する、保守端末から管理者の認証情報が盗まれる、配送APIが応答しない。具体的な出来事へ分解してみる。

発生し得る出来事が分かると、前提も見える。他社予約の閲覧には、IDの推測可能性に加え、閲覧先が対象ごとの認可を欠いている必要がある。IDをランダムにしても、判定がないという設計上の欠落は残る。推測しにくさはアクセス制御の代わりではない。

被害の大きさは、技術的な脆弱性の名前だけでは決められない。特別価格の漏えいが契約違反になる取引と、公表価格のページが閲覧された取引では影響が違う。外部サービスの停止が致命的なのか、後から配送通知すればよいのかも、業務の時間制約が決める。

NIST SP 800-30 Rev.1は、脅威、脆弱性、発生可能性、影響などを踏まえるリスクアセスメントを組織の意思決定へ結び付ける資料である。3 本章で使う脅威例や重要度は独自の仮定であり、同資料に青葉機材の優先順位が書かれているわけではない。

仕様へ翻訳しない対策は、後から消える

「管理者以外には閲覧させない」は不十分だ。誰を管理者と呼ぶのか。営業管理者は自社の取引先の情報を横断してよいのか。配送担当は電話番号を読む必要があるが、値引き率も読めてよいのか。

要求を、主体・操作・対象・条件の組合せへ落とす。たとえば「取引先担当者は、所属会社に紐付く確定済み予約について、取引先向け公開項目だけを閲覧できる」。この表現なら、他社の予約を要求した場合、未確定の予約を要求した場合、管理者の代理操作の場合をテストできる。

何も設定されていない新しいAPIが追加されたらどうなるか。既定で許可する設計なら、新規機能の公開時に意図しない閲覧が始まる。許可を明示しない操作は拒否する規則は、仕様の漏れを安全側へ倒すための設計になる。2

ただし、拒否すれば常に業務上正しいわけではない。外部の配送連携が一時的に使えなくなった場合、顧客への予約確定まで止める必要があるかは、業務の成立条件に依存する。アクセス権限の拒否と、障害時の縮退運転は異なる判断である。

非機能要件に押し込めると、機能側の穴が残る

セキュリティが非機能要件として扱われるからといって、すべてを設定項目だけで済ませられるわけではない。誰がどの予約を読むかは、業務権限という機能の振る舞いにも現れる。

監査記録を設ける場合も、単にログを書き込む機能ではない。誰の操作か、どの取引に作用したか、いつの情報に基づいた判断かを後から説明できる粒度が必要になる。必要な項目を増やすほど、ログ自体が保護すべき個人情報や機密情報を含む可能性も増える。

性能との衝突もある。すべての操作で権限判定をするなら、判定に使う組織情報が最新かどうかが問題になる。キャッシュで速くしても、権限取り消しが即座に効かないなら許容できない業務がある。遅延、最新性、可用性を、一つの「安全性」という言葉へ押し込めない。

IPA SAシラバスVer.5.2の5-5はセキュリティを非機能要件の知識に含め、8-1と8-4は要件をシステム方式へ割り当て、方式の一貫性や実現可能性を評価する能力を求める。1 認可の実装を誰に担当させるかは、技術選択と同時に責務の設計である。

最後に残るのは、検証できる問い

青葉機材は、管理画面へログインできることだけを確認する試験をやめた。別会社の予約IDを指定したとき、閲覧拒否だけでなく情報の存在を余計に知らせないか。配送担当者が権限を失った後、開いたままの画面から更新できないか。管理者の操作記録は、検証可能な主体と対象に結び付いているか。

単に攻撃を見つけるためではない。守ると合意した約束が、システムとして成立することを確かめるためである。

午前Ⅱでは暗号、認証、認可、アクセス制御、可用性の区別を問う。午後では、状況に応じてどの境界が信頼できず、どの要求を強制すべきかを本文の条件から説明する。両方の出発点は同じだ。何を守るのかを、対策名より先に言えることである。

知識を答案へ戻す

午前Ⅱ。 認証は主体の確認、認可は操作・対象への許可判断、暗号化は特定の機密性や完全性を実現する手段である。IDの推測困難性とアクセス制御を混同しない。

午後Ⅰ。 利用者、業務権限、外部連携、対象データを切り分け、信頼境界をまたいだ時点で何が保証されなくなるかを説明する。本文にない攻撃や制度を仮定しない。

午後Ⅱ。 保護すべき業務と損失、選択した方式と代替案、検証した権限の境界、残存リスクを一つの設計判断として述べる。

立ち止まって考える：認証に成功し、通信も暗号化されている。他社の予約を表示できないことまで保証できるか

できない。認証・通信保護と、対象予約への認可は異なる。要求ごとに主体・操作・対象・条件を評価する仕組みが必要である。

出典と照合範囲

[1] コンプリートテキスト第1・3・20・21・23章、およびIPA SAシラバスVer.5.2：要求・信頼境界・非機能要件・方式評価の関係を出発点とした。青葉機材の業務と判断は架空の例。公式シラバス

[2] OWASP Authorization Cheat Sheet：拒否を既定とする認可、許可の正当化、リソースへのアクセス判断を参照した。特定製品の安全性を保証する資料ではない。公式解説

[3] NIST SP 800-30 Rev.1（2012）：リスクアセスメントを意思決定に結び付ける説明を参照した。個々の想定損失の数値は与えていない。公式資料