全体像：どんな状況設定？
舞台は半導体メーカーU社。国内拠点のU社と国内40社の協力会社が、生産計画・設計書類などの“受発注以外”のファイルをやり取りするために、社内開発のWebベース交換システム「Dシステム」を使っています。アクセスは協力会社側とU社の「ファイル受渡し用PC」からHTTPSで行い、社内からはFWでその専用PCだけに制限。アカウントは“協力会社の拠点ごとに1つ”、認証はID/パスワードです。
事件発生：改ざん＋海外アクセスの発覚
ある日、Dシステムのトップページが改ざんされます。原因はHTTPサーバの既知脆弱性の悪用で、パッチ適用等で復旧。この調査で、協力会社P社のアカウントが“海外IPから”使われた痕跡が見つかります。P社に確認すると、従業員が海外出張先からアクセスしていたと判明。実は利用規約では「協力会社社内にPC設置」「盗難・マルウェア・不正持ち出し対策」「Dシステムは“そのPCからのみ”アクセス」を求めていたのに、U社は遵守状態を確認していなかった──という“ガバナンスのほころび”も露わに。対応として、海外からのアクセスをFWで禁止し、加えてSIEMを導入します。
脆弱性診断：XSSがどこで、なぜ起きる？
U社は専門会社N社に診断を依頼。その結果、XSS脆弱性が発見されたのが“ファイル備考の入力→確認画面”の流れ（図2）。画面Aで入力した「備考」「参考URL」が画面Bに反映され、参考URLはリンクとして表示されます。
N社の詳報：
-
「備考（description）」は適切にエスケープされていて安全。
-
一方「参考URL（refURL）」の出力処理に問題があり、リンクをクリックすると“XSS!”ダイアログが出る＝リンク生成の過程でXSSが成立。
-
検証URLを変えて原因切り分け。属性値コンテキスト（href）への出力に必要な処理が不足しており、引用符やイベントハンドラ混入で発火できる状況が再現。
図4〜図9の抜粋は、実際に
対策の二本柱：アプリ修正＋CSP
R氏（登録セコスペ）が提案した対策は2つ。1つ目はUアプリの改修（今回のXSS箇所の根本修正）。2つ目はHTTPレスポンスにContent-Security-Policy: script-src 'self';を追加し、“同一オリジンのスクリプトだけ実行可”とするヘッダ対策です。後者は短期導入が利点ですが、既存の“意図した動作”が阻害されるスクリプト（例：インライン/イベントハンドラ/外部CDNなど）がないか洗って、必要なら“呼び出し方法の変更”が要る、と注意喚起。古いブラウザ非対応もあるので、最終的には“両方”実施を決定。
SaaS移行の是非：Gサービスの機能と課題
Uアプリの改修を進める中で、「SaaSへ移行した方が機能・セキュリティ面で良いのでは？」という案が浮上。G社のSaaS（Gサービス）の概要は、ブラウザアクセス／アップロード・ダウンロード／階層フォルダ管理／個別権限制御／容量割当／他契約領域は不可、等。これを前提に「必要なセキュリティ対策がSaaSで満たせるか」を表2で整理。要点は：
-
送信元IP制限（＝協力会社以外からのアクセス禁止）は“不可”。
-
Webアプリ脆弱性、OS・HTTPサーバのパッチ適用は“G社が実施”で可。
-
保存時暗号化は“自動で暗号化、鍵はG社管理”。
-
完全削除は“不可の可能性あり”。
-
DRは“日本とF国の両方のDCに冗長化”。
この検討と比較過程自体も問題文に明示されています。
信頼性の裏付け：認証取得＋越境リスクへの意識
Tさんは、SaaS選定の目安として、クラウドサービスの実践規範ISO/IEC 27017の認証、パブリッククラウドの個人情報保護実践規範ISO/IEC 27018の認証を示唆。Gサービスは27017を取得済み。ただしF国の法制度により、F国内のデータは政府に強制提出させられる可能性があるため、「ファイル内容をどう守るか」をU社措置として検討せよ、という論点を提示します（→クライアント側暗号化等の発想につながる）。
SIEM連携：SaaSでも監視できるか？
Gサービス自体はSIEM機能を提供しないが、API経由でログを取得してU社のSIEMに取り込めます。提供ログは“アカウント/フォルダ/ファイル”単位で、操作種別（作成・削除・権限変更・DL/UL等）、日時、実行者ID、送信元IP、結果（成功/失敗）を記録。ここから“ブルートフォース検知などがどこまでできるか”を検討します。
表4の検知ロジック（例）：
ただし“ゆっくり攻撃”だと見逃すことがあり、特に後者は“送信元IPを変えながら攻撃された場合”に抜けやすい。だから多要素認証（MFA）を採用すべき、という流れ。
MFAの実装方針：IDaaS＋FIDO（Kサービス）
MFAはGサービス単独では不可だが、IDaaS連携で実現可能。国内複数DC運用の「Kサービス」をIDaaSとして選び、FIDOベースの認証を採用する方針です。
スマホFIDOの“認証フロー（図10）”のポイントは、(3)〜(5)のメッセージ生成に“オリジンb”を組み込み、ブラウザがアクセスしている正しいオリジンであることを検証する点。これは攻撃者が“偽サイトに誘導して認証情報を抜く”タイプの攻撃を防ぐための仕掛けです。
認証器の比較（表5・表6・表7）では、スマホ、USB外部キー、OS内蔵生体の性質と運用リスク（紛失時、退職時、配布方法など）を整理。最終的に“OS内蔵生体認証”を採用。理由はDシステム時代と同様に「アクセス元PCを限定」する要件を技術的に満たしやすく、配布負担も小さいから、というまとめです。
出題の狙い（読む視点のガイド）
この問題は、CSPを含む現代的なXSS対策、SaaS移行時のリスク分析（“できる/できない”の棚卸しと補完策の立案）、ログに基づく検知の限界認識とMFA設計、FIDOの“オリジン拘束”の意義などを、ストーリーに沿って総合的に考えさせる構成です。
