情報処理安全確保支援士試験 過去問 2021年（令和3年） 秋期 午後Ⅱ 問1
協力会社とのファイルの受渡し
U社は，従業員10,000名の半導体製造業であり，国内に工場を置いている。U社では，幾つかの工程を国内の40社の協力会社に委託しており，生産計画や設計書類のファイルを協力会社との間で受け渡す必要がある。ファイルの受渡し件数は，協力会社によって異なるが，1日当たり1件から10件である。U社では，生産管理課が協力会社とのファイルの受渡しを担当している。ファイルの受渡しには，Webページのファイル交換システム（以下，Dシステムという）を使用している。Dシステムは，HTTPサーバ及びU社が開発したWebアプリケーションプログラム（以下，Uアプリという）から成る。DシステムではWebページに関するファイルは取り扱っていない。
図1は，Dシステムに関係する機器の全体構成である。
U社の生産管理課及び協力会社に設置したファイル受渡し用PCからDシステムまでのアクセスは，HTTPSで行われている。U社ネットワーク内からDシステムにアクセスできる端末は，FWの設定によって，生産管理課に設置したファイル受渡し用PCだけに制限している。
Dシステムのアカウントは，協力会社の拠点ごとに一つ，U社が発行している。Dシステムの利用者認証は，利用者IDとパスワードによって行われている。
セキュリティインシデントの発生
ある日，Dシステムのトップページが改ざんされるというセキュリティインシデントが発生した。調査したところ，HTTPサーバの既知の脆弱性を悪用した攻撃によって改ざんされたと分かり，脆弱性修正プログラムの適用などをしてから復旧した。
セキュリティインシデントの調査の過程で，HTTPサーバのアクセスログから，協力会社P社に発行したアカウントを用いて海外のIPアドレスからアクセスした履歴が見つかった。このアクセスは，Dシステムの利用規約や法令に違反しているおそれがあるので，P社に問い合わせたところ，P社の従業員の1人が海外出張先からアクセスしていることが分かった。
Dシステムの利用規約では，ファイル受渡し用PCには，各協力会社の社内への設置，並びに盗難対策，マルウェア対策及びファイルの不正持出し対策を求めている。また，Dシステムには，ファイル受渡し用PCからだけアクセスすることを求めている。しかし，U社ではいずれの遵守状況も確認していなかった。
こういった利用規約違反への対策として，海外からのアクセスをFWで禁止した。さらに，協力会社以外からのアクセスを検知するために，SIEM（Security Information and Event Management）を導入した。
Dシステムの脆弱性診断
U社は，ほかにもDシステムに対策が必要な脆弱性がないかどうかを確認するために，脆弱性診断をセキュリティ専門会社であるN社に依頼した。
診断の結果，クロスサイトスクリプティング（以下，XSSという）脆弱性などが発見された。XSS脆弱性が発見された箇所を，図2に示す。
N社の，XSS脆弱性についての報告を図3に示す。
- XSS脆弱性の診断は，URLをWebブラウザのアドレスバーに入力し，HTTPレスポンス及び表示される画面の内容を確認することによって行った。
- まず，図2の画面Aと画面Bの診断のために，診断用URL1と診断用URL2の二つを入力し先，診断用URL1を図4，診断用URL1を入力した時に得られたサーバからのHTTPレスポンスのボディ部を図5，診断用URL2を図6，診断用URL2を入力した時に得られたサーバからのHTTPレスポンスのボディ部を図7に示す。
- 図5から，descriptionパラメタの値を画面Bの備考に出力する際には，エスケープ処理が正しく行われており，XSS脆弱性は認められない。
- 診断用URL2を入力した時に表示された画面B上で，参考URLのリンクをクリックすると，"XSS!"という内容のダイアログボックスが表示された。
- 上記(4)と，図7から，refURLパラメタの値を画面Bの参考URLのリンクとして出力する際の処理に問題があり，XSS脆弱性が存在すると認められる。
- 上記(5)で示した脆弱性の原因は，refURLパラメタの出力部において，プログラミングに関する次の二つの誤りのうちのどちらかによるものと想定される。
- XSSを防ぐための処理を一切していない。
- XSSを防ぐための基本的な処理はしているが，HTMLタグの属性値の出力時に必要な処理が行われていない。
- 次に，いずれの誤りなのかを調べるために，図8に示す診断用URL3を入力した。その時に得られたサーバからのHTTPレスポンスのボディ部が図9である。
https://dsys.u-sha.co.jp/submitdescription?fileID=0010238&description=<script>alert('XSS!')</script>&checkbox=on&refURL=http%3A%2F%2Fwww.u-sha.co.jp/
（省略） 備考：ascriptbalert('XSS!')a/scriptb<br> （省略） 参考URL：<a href="http://www.u-sha.co.jp/">http://www.u-sha.co.jp/</a> （省略）
https://dsys.u-sha.co.jp/submitdescription?fileID=0010238&description=test2&checkbox=on&refURL=c
（省略） 備考：test2<br> （省略） 参考URL：<a href="c">c</a> （省略）
https://dsys.u-sha.co.jp/submitdescription?fileID=0010238&description=test3&checkbox=on&refURL="%20onmouseover=alert('XSS!')%20foo="
（省略）
備考：test3<br>
（省略）
参考URL：<a href="" onmouseover=alert('XSS!') foo="">"
onmouseover=alert('XSS!') foo="</a>
（省略）
Dシステムの脆弱性対策
XSS脆弱性の報告を受けたU社は，N社の支援を受けて，DシステムのXSS脆弱性対策を進めることにした。支援を担当した情報処理安全確保支援士（登録セキスペ）であるR氏は，二つの対策を提案した。
一つ目の対策は，①図3で特定されたXSS脆弱性を解消するためのUアプリの改修である。
二つ目の対策は，"Content-Security-Policy: script-src 'self';" というヘッダフィールドを，HTTPレスポンスのヘッダに追加することによって，Webブラウザに対して②指定したスクリプトファイルの実行だけを許可するというものである。この対策は，一つ目の対策に比べて短期間で実施可能であるが，Dシステムが用いている正規のスクリプトが意図したとおりに動作するように，③実行が制限されてしまうスクリプトの有無を確認し，もしあれば，当該箇所の呼出し方法を変更する必要がある。
一部の古いWebブラウザはContent-Security-Policyに対応していないので，万全の対策のためには，二つの対策を両方実施することが必要である。
U社は，R氏の提案どおり，Content-Security-Policyを速やかに追加するとともに，Uアプリの改修計画の策定を開始した。
DシステムのSaaSへの移行の検討
U社の情報システム部のYさんがUアプリの改修を計画していたところ，将来にわたりU社でUアプリのメンテナンスを続けるよりもSaaSに移行する方が機能面でもセキュリティ対策の面でもよいのではないかという意見が出た。
そこで，YさんはUアプリのメンテナンス継続とSaaSへの移行のメリットとデメリットを比較した。比較の結果，表1に概要を示すG社提供のSaaS（以下，Gサービスという）に移行する方が，Uアプリのメンテナンスを継続するよりもメリットが多そうなので，更に詳細に検討することにした。
| 項目 | 内容 |
|---|---|
| 基本機能 |
・利用者は，Webブラウザでアクセスする。 ・Gサービス上のストレージにファイルをアップロードしたり，ローカルのストレージにダウンロードしたりできる。 ・アップロードしたファイルは，親子関係によるフォルダで管理される。利用者は，アクセス権に従ってフォルダを作成することができる。 |
| アクセス権 | ・ファイル及びフォルダに対して，利用者ごとにアクセス権を設定できる。 |
| 契約に伴う制限 |
・契約で定められた容量が割り当てられる。 ・ほかの契約者に割り当てられた領域には，アクセスできない。 ・契約では発行できるアカウント数の上限が定められている。 |
YさんはGサービスへの移行について，Dシステムの利用規約の継続を前提として，次の項目を検討することにした。
項目1：必要なセキュリティ対策のGサービスでの実現可否
項目2：SIEMとの連携
項目1の検討
Yさんは，項目1について検討した。表2は，その検討結果である。
| 必要なセキュリティ対策 | Gサービスでの実現可否 |
|---|---|
| 協力会社以外からのアクセス禁止 | Gサービスで，送信元IPアドレスの制限を行うことができないので否 |
| Webアプリケーションプログラムの脆弱性への対応 | G社が実施するので可 |
| サーバOS及びHTTPサーバへの脆弱性修正プログラムの適用 | G社が実施するので可 |
| ファイルをGサービス上のストレージに保存するときの暗号化 | Gサービスの機能として，自動的に暗号化され，暗号鍵はG社が管理するので可 |
| ファイルの完全削除 | ファイルを削除しても，Gサービス上のストレージに情報が残る可能性があるので否 |
| 災害時の業務継続 | ファイルや管理情報が，日本国内とF国の両方のデータセンタに保存されており，片方が災害に遭ってもデータの消失とサービスの停止を防ぐことができるので可 |
次は，検討結果に関するYさんとU社のCSIRTリーダーであるTさんの会話である。
Yさん： 表2のとおり，セキュリティ対策の大部分はGサービスで実現できますが，Gサービスが信頼できるかどうかの見極めが必要です。
Tさん： そのとおりだね。例えば，クラウドサービスのためのdの実践の規範であるISO/IEC 27017に基づく認証や，Dシステムとは直接関係がないが，パブリッククラウドにおけるeの実践の規範であるISO/IEC 2018に基づく認証を取得しているサービスであれば信頼してよいのではないかな。
Yさん： Gサービスは，ISO/IEC 27017に基づく認証を取得しているので，信頼できそうですね。
Tさん： そうだね。ところで，F国では安全保障上の要請があれば，F国内に保存されているデータを，F国政府に強制的に提出させる国内法が存在する。④Gサービスを経由して協力会社との間で受け渡すファイルの内容を保護するという観点で，どのような措置が当社として取り得るか，考えてほしい。
Yさん： 分かりました。
項目2の検討
現行のDシステムでは，協力会社以外からのアクセスを検知するためにSIEMを利用しているが，GサービスではSIEMの機能は提供していない。Yさんが調査した結果，Gサービスに移行した場合でも，GサービスのAPIを利用すれば，表3に示すログをU社のSIEMへ取り込むことが分かった。
| 対象 | 実行された操作 |
|---|---|
| アカウント | ログイン，ログアウト，作成，削除，権限変更 |
| フォルダ | 作成，削除，名称変更，アクセス権変更 |
| ファイル | ダウンロード，アップロード，削除，名称変更，アクセス権変更 |
ログには，操作対象，実行された操作とともに，日付，時刻，実行した利用者ID，アクセス元IPアドレス，及び結果（成功又は失敗）が記録される。
続いて，Yさんは，Gサービスが提供している，利用者IDとパスワードによる認証を利用した場合に，SIEMを利用してログから不正アクセスが検知できるかどうかを検討した。表4は，Yさんが考えた，ログから不正アクセスを検知する方法である。
| 項番 | 不正アクセスの方法 | 検知の方法 |
|---|---|---|
| 1 | 利用者IDを固定して，パスワードを総当たりする。 | 一定時間当たりのfの回数がしきい値を超えたら，不正アクセスとして検知する。 |
| 2 | 少数のパスワードについて，利用者IDを総当たりする。 | 一定時間当たりの同一IPアドレスからの異なる利用者IDによるログイン失敗の回数がしきい値を超えたら，不正アクセスとして検知する。 |
表4を確認したTさんは，いずれの不正アクセスもゆっくりと実行された場合には見逃すことがあることと，項番2については，⑤ほかの場合にも見逃すことがあることを指摘した。さらに，不正アクセスを防ぐには，多要素認証を採用する方がよいこと，多要素認証は，Gサービス単独では実現できないが，IDaaSとの連携で実現できることを説明した。
IDaaSとの連携による多要素認証の実現方式の検討
Yさんは，IDaaSとの連携による多要素認証の実現方式の検討を開始した。幾つかのIDaaSを検討した結果，国内の互いに地理的に離れた複数のデータセンタで運用されているKサービスとの連携による実現が最適であると考えた。Kサービスでは，様々な認証方式を選択できるが，Yさんは，Gサービスを利用した新たなファイル交換システム（以下，Eシステムという）には，FIDO認証が最もふさわしいと考え，FIDO認証器として何を選択するべきか，検討を開始した。まず，Kサービスで利用できるFIDO認証器の仕組みについて調査し，表5にまとめた。
| 認証器 | Webブラウザとの通信方法 | 認証器使用時の利用者確認（User Verification） | 複数利用者による認証器の共用 | 組合せ注1） |
|---|---|---|---|---|
| スマートフォン | Bluetooth経由 | スマートフォンに組み込まれた生体認証装置による生体認証 | できない | 制限される |
| USB接続外部認証器 | USBポート経由 | なし | できない | 制限される |
| OS内蔵の生体認証機能 | OS内部処理 | OSに内蔵された生体認証機能による生体認証 | OSの利用者ID間で可能 | 制限される |
注1）KサービスにアクセスするPCと，認証器の組合せ
認証器としてスマートフォンを利用した場合の利用者認証の流れは図10のとおりであった。
Yさんは，図10中の(3)〜(5)のメッセージの生成にオリジンbが使われていることについてTさんにその目的を尋ねた。Tさんは，攻撃者が，gするための特別なサーバをインターネット上に用意し，何らかの方法で被害者をそのサーバに誘導し，認証情報を不正に入手して悪用するという攻撃を防御するためだと答えた。
続いてYさんは，Eシステムにおいて，それぞれの認証器を使用した場合を想定し，認証器の取扱いを表6に，運用上のリスクと対策を表7にまとめた。
| 認証器 | Kサービスにおける取扱い | Eシステムにおける認証器の所有者 | Eシステムにおける認証器の配布方法 |
|---|---|---|---|
| スマートフォン | 供給せず，要件を提示している。 | 各協力会社又は利用者個人 | 協力会社によって異なる。 |
| USB接続外部認証器 | 専用機器を契約者だけに販売している。 | U社の一括購入となるので，U社 | U社から必要個数を各協力会社に配布する。 |
| OS内蔵の生体認証機能 | 供給せず，要件を提示している。 | 各協力会社 | ファイル受渡し用PCが認証器を兼ねるので，認証器の別途配布は不要である。 |
| 認証器 | 認証器の紛失・盗難時のリスクと対策 | 退職時のリスクと対策注1） |
|---|---|---|
| スマートフォン | 認証器の使用時にhが必要なので，不正利用される可能性は低い。 | 退職者による不正なアクセスを防ぐために，個人所有のスマートフォンを利用していた場合も想定して，退職時又は退職後直ちに，iでは，jする必要がある。 |
| USB接続外部認証器 | 第三者による不正利用を防ぐために，直ちにkする必要がある。 | （省略） |
| OS内蔵の生体認証機能 | 認証器の使用時にhが必要なので，不正利用される可能性は低い。 | 休眠アカウントを悪用した不正アクセスを防ぐために，ファイル受渡し用PCにログインするためのアカウントを忘れずに削除する必要がある。 |
Yさんは，各認証器を比較し，次のようにまとめた。
- Kサービスのアカウントに対して認証器を登録する際は，いずれの認証器でも，不正がないように確認する必要があり，登録について大きな差はない。
- USB接続外部認証器は，紛失・盗難に備えた体制を整えるのが難しいので，採用しない。
- スマートフォン及びOS内蔵の生体認証機能は，認証器として大きな差はないが，⑥Dシステムで要求されていたセキュリティ要件を技術的に実現できるので，OS内蔵の生体認証機能の方が望ましい。
上記からYさんは認証器としてOS内蔵の生体認証機能を採用することにした。
その後，Yさんは検討を続け，DシステムをEシステムに移行する案をまとめた。U社では，その案を承認し，Eシステムへの移行を開始した。