情報処理安全確保支援士試験 令和２年秋午後２問１の問題解説

全体像（どんな話？）

U社（半導体メーカー）が、協力会社40社と設計書や生産計画ファイルをやり取りするための自社開発Webシステム（Dシステム）を運用中。ある日トップページ改ざんが起き、調査するとHTTPサーバの既知脆弱性が悪用されていたことが判明。規約違反の海外アクセスも見つかり、一次対策（FWで海外を遮断、SIEM導入）を実施。
さらに専門会社の診断でXSS脆弱性が発覚 → アプリ改修＋CSPで対策。
その流れで「いっそSaaSに移行した方が良い？」という検討へ。SaaS（Gサービス）の機能・セキュリティ・監査/認証・ログ連携・法域リスクを評価し、検知強化にはMFAが必要 → IDaaS（Kサービス）連携でFIDO認証を導入。FIDO認証器（スマホ、外部USBキー、OS内蔵生体）を比較し、運用・要件適合性からOS内蔵生体を選定、というストーリーです。

システム前提（Dシステム）

• 利用者：U社生産管理課＋各協力会社。

• 接続：HTTPS。U社内からのアクセス端末はFWで「生産管理課の受渡し用PC」に限定。

• 認証：ID＋パスワード。

• 規約：受渡し用PCの盗難/マルウェア/持ち出し対策を要求、かつ“受渡し用PCからのみ”アクセス可。U社は遵守確認をしていなかった（ここが運用ガバナンスの弱点）。

インシデントと一次対応

• 事故：HTTPサーバの既知脆弱性を突かれてトップページ改ざん。パッチ適用などで復旧。

• 併発：P社アカウントで海外IPからのアクセス履歴（本人は海外出張中で“意図せざる規約違反”）。

• 一次対策：FWで海外遮断、加えて協力会社“以外”からのアクセス検知のためSIEM導入。
  → ポイント：技術的対策（パッチ、FW）と監視（SIEM）を併走させる“層防御”。

脆弱性診断（XSSの見つけ方・本質）

診断は「アドレスバーに診断用URLを入力→HTTPレスポンスと画面を確認」というブラックボックス手順。

• 画面A（入力）→画面B（確認）への遷移で、パラメータの出力場所を検査。

• descriptionは適切にエスケープされOK。

• しかしrefURL（参考URLリンクのhref）の扱いに不備があり、属性値コンテキストのエスケープが足りないためXSSが発火。

• 診断URL3で href="... onmouseover=alert('XSS!') ..." のような“属性値からのイベントハンドラ注入”が効くことを実証。
  → 狙い：**「出力コンテキスト別のエスケープ」**を理解しているか（テキスト・HTML・属性・URL・JSそれぞれで方法が違う）。

XSS対策（2本柱）

1. アプリ改修：refURLの出力箇所に対し、属性値コンテキストに適したエスケープ/バリデーションを実装。URLであればスキーム制限（http/httpsのみ等）や、javascript:を弾く、引用符や制御文字のエスケープ、リンクテキストとhrefの二重化チェックなど。

2. CSP導入：Content-Security-Policy: script-src 'self'; をレスポンスヘッダに付与し、同一オリジン配信のスクリプトのみ実行許可。短期で効くが、インラインスクリプトや外部CDNのJSが動かなくなる可能性があるため、必要に応じて呼び出し方法の変更（インラインを外部ファイル化、nonce/hashの付与、CDNをやめ同一オリジンから配信）を検討。

• なお古いブラウザはCSP非対応 → “アプリ改修＋CSP”の併用がベストプラクティス。

SaaS（Gサービス）への移行検討

Gサービスの要点（問題文の表1・表2相当）：

• 機能：ブラウザで利用、アップ/ダウンロード、階層フォルダ、利用者ごとのアクセス権。契約容量あり・他テナントと分離・アカウント発行上限あり。

• セキュリティ実現可否（項目1）

  • 送信元IP制限：不可（ベンダ側機能になく“協力会社以外禁止”をSaaSだけで実現できない）

  • アプリの脆弱性/OSやHTTPサーバパッチ適用：ベンダ責任で可

  • 保存時暗号化：自動で可（鍵はG社管理）

  • 完全削除：否（削除後も残存可能性）

  • 事業継続：可（国内＋F国データセンタの冗長化）

監査・認証と“信頼できるSaaS”の見極め

• クラウドセキュリティの実践規範ISO/IEC 27017、パブリッククラウドの個人情報保護（PII）向け実践規範ISO/IEC 27018の認証を取得しているかを確認材料に。

• ただし法域リスクがある：F国の安全保障関連法で政府提出を強制され得る。
  → 取れる措置の本質：“自社管理の鍵でコンテンツを暗号化してからクラウドに置く”（クライアントサイド暗号/ゼロ知識化）。これなら事業者が鍵を持たないため、提出されても平文は読まれにくい。併せてメタデータ露出の最小化や重要ファイルの二重化（社内保管）も論点。

SIEM連携（項目2）

• Gサービス自体はSIEMを持たないが、APIで操作ログを取得して自社SIEMに取り込み可能。

• 取得できるログ：アカウント（ログイン/作成/削除/権限変更）、フォルダ（作成/削除/改名/権限変更）、ファイル（アップ/ダウン/削除/改名/権限変更）。日時・ユーザID・送信元IP・結果（成功/失敗）付き。

• 検知ロジックの例：

  • ①固定IDに対するパスワード総当たり → 一定時間あたりのログイン失敗回数を閾値で検出。

  • ②少数のパスワードを多数IDに試す → 同一IPから異なるIDへの失敗回数を閾値で検出。

• 限界：ゆっくり実施（低速ブルートフォース）やIP分散（ボット/プロキシ）だと見逃しやすい。
  → 根本対策としてMFA導入が必要。Gサービス単独では不可だがIDaaS連携で実現。

IDaaS＋FIDO（パスワードレス多要素）

• Kサービス（IDaaS）と連携してFIDO認証を採用。FIDOは公開鍵方式＋ユーザ検証（生体/暗証）でフィッシング耐性が高い。

• 認証フローのキモ：メッセージに**“ドメイン/オリジンと乱数”**をハッシュ・署名に含める。これにより、攻撃者が用意した偽サイトや中継サイトに誘導されても、正規オリジンでない限り署名検証に失敗し、資格情報の悪用を防げる。

• 認証器の比較

  • スマホ（Bluetooth）：生体あり／共用不可／配布は協力会社ごとに差。

  • USBキー：共用不可だが紛失・盗難のリスク管理が難しい。

  • OS内蔵生体：PC内蔵の指紋/顔など。“受渡し用PCからのみアクセス”というDシステムの要件に技術的に合致しやすい（PC＝認証器）。
    → 結論：OS内蔵生体がもっとも望ましい（配布不要・PC紐づけ・規約要件に合う）。退職時は当該PCのアカウント/権限を確実に削除、外部認証器なら速やかな失効が必要、など運用ルールも付随。

この問題が“試している力”

1. Webアプリの脆弱性を“コンテキスト別”に理解し、診断結果から具体的対策に落とせる力（属性値XSS・CSP・インライン禁止の影響と回避）。

2. クラウド移行の是非を“機能・運用・法域・監査・ログ・検知・MFA”の多視点で評価できる力。

3. ゼロトラスト的発想（IP制限だけに頼らない／MFA・IDaaS・端末認証を組み合わせる）。

4. FIDO/オリジン束縛の原理理解（フィッシング耐性の肝を説明できる）。

用語の要点（簡潔版）

• XSS：ユーザ入力がHTMLに無防備に出力され、ブラウザでスクリプトが実行される脆弱性。出力先のコンテキスト（本文/属性/URL/JS）に合ったエスケープが必要。

• CSP：ブラウザに「どのスクリプトを実行してよいか」を指示するヘッダ。script-src 'self'で同一オリジンのJSのみ許可。インラインや外部CDNは原則ブロック。

• SIEM：各システムのログを集約・相関分析して脅威検知・監査に使う基盤。

• IDaaS：クラウド型の認証・認可基盤。SaaSの認証を統合し、MFAなどを提供。

• FIDO：公開鍵認証＋ユーザ検証（生体/暗証）でフィッシング耐性がある。オリジン（アクセス中のサイトの“出自”）を署名に含めて偽サイトを弾く。

• ISO/IEC 27017/27018：クラウドのセキュリティ及びクラウドPII保護の実践規範。取得有無は信頼性判断材料。

• 法域リスク：海外データセンタの現地法によりデータ提出を強制される可能性。クライアント側暗号化＋自社鍵管理で低減。