L 社は，金融業向けにシステムを開発している従業員 1,000 名の企業である。L 社のシステム開発プロジェクトでは，プラットフォーム G というソフトウェア開発プラットフォームを利用している。プラットフォーム G の機能には，ソースコード及び開発ドキュメントのバージョンを管理する機能，CI/CD パイプラインの管理機能，開発対象の SBOM 作成機能がある。CI/CD パイプラインの管理機能を利用してテストやリリースの自動実行が可能である。開発対象の SBOM 作成機能はプラットフォーム G 上のリポジトリサーバ内のソースコード及びライブラリをシステム構成要素として一覧化する。開発対象の SBOM 作成機能は現状では特に利用していない。また，L 社が採用している SAST ツール（以下，ツール F という）は，プラットフォーム G 上のリポジトリサーバや開発者の端末にインストールして利用するツールであり，コンパイルエラーが解消されたソースコードに対してだけ正常な検査が可能である。プラットフォーム G の CI/CD パイプラインの管理機能で，ツール F でのチェックを自動的に行うようなワークフローを構成することができる。
近年，業務委託先でのセキュリティ侵害に起因する情報セキュリティインシデントが大きく報道されるなど外部環境が変化し，L 社経営陣もサプライチェーンリスク対策の強化を考えるようになった。経営陣の指示で，情報セキュリティ担当の B さんは，サプライチェーンリスク対策を強化したセキュリティガイドライン（以下，ガイドラインという）を作成し，全てのシステム開発プロジェクト及び運用サービスを点検することになった。B さんは，L 社が契約しているセキュリティコンサルタントで情報処理安全確保支援士（登録セキスペ）の D 氏にガイドラインの作成について相談することにした。
〔ガイドラインの作成〕
次は，ガイドラインの作成についての B さんと D 氏の会話である。
B さん：ガイドラインはどのような構成がよいでしょうか。
D 氏 ：システムライフサイクルの工程に合わせるのがよいでしょう。L 社のシステム開発業務を踏まえて，調達，開発，リリース・デプロイ，運用の工程に分類し，さらに全ての工程で共通するような項目も抜き出して記載しましょう。
B さんは，ガイドライン案を表1のように作成した。
表1 ガイドライン案（抜粋）
次は，ガイドライン案についての B さんと D 氏の会話である。
B さん：①セキュリティ・バイ・デザインの考え方を一部取り入れました。その他，留意すべき点などはありますか。
D 氏 ：項番5には，②業務委託先が再委託を行う場合に備えて，L 社と業務委託先との間の契約書に明記すべき事項を具体的に示しておくとよいでしょう。
B さんが修正したガイドライン案を経営陣に報告したところ，過去に外部ベンダーでのセキュリティ侵害に起因して L 社でインシデントが何度か発生したことがあったので，それらのインシデントに対するガイドライン案の有効性を評価するように指示があった。
〔過去のインシデントの確認〕
B さんは，過去のインシデントに対するガイドライン案の有効性を評価することにした。次は，1件目のインシデントについての D 氏と B さんの会話である。
D 氏 ：はじめに，インシデントの内容を確認しておきましょう。
B さん：L 社が開発し，運用していたシステム（以下，システム Q という）では，古い Web ブラウザをサポートするための JavaScript（以下，スクリプト P という）を利用していました。スクリプト P は，当時広く使われていた T 社製のものです。スクリプト P は，T 社が運営するサーバ（以下，サーバ T という）に配置され，システム Q にアクセスした Web ブラウザがスクリプト P を都度読み込むようにシステム Q は構成されていました。ある日，サーバ T が乗っ取られてしまい，スクリプト P が改ざんされたことによって，システム Q への利用者のアクセスが悪意のある Web サイトにリダイレクトされてしまいました。
D 氏 ：発見の経緯を教えてください。
B さん：システム Q の利用者からの問合せで気付き，対策を実施しました。当時の情報セキュリティ担当は，サーバ T が侵害されたというニュースは知っていましたが，システム Q へのアクセスが影響を受けることを把握していませんでした。
D 氏 ：他社の発表によると，③スクリプト P を利用していたシステムでもスクリプト P の配置方法が違えば，影響を受けなかったようですね。
B さん：はい。違う配置方法にするという対策もありました。しかし，Web ブラウザ開発元での古い Web ブラウザの公式サポートが終了していたことから，当社の対策としては，④システム Q のソースコードに変更を加えて，古い Web ブラウザのサポートを終了しました。
D 氏 ：1件目のインシデントについてはおおむね理解できました。
B さん：案の項番10が，1件目のインシデントを未然に防ぐために有効ではありませんか。
D 氏 ：いいえ，開発対象の SBOM 作成機能で SBOM を作成していたとしても，スクリプト P は SBOM に含まれないので，インシデントは防げなかったでしょう。
B さんは，⑤ SBOM 以外の手段で，システムが利用している外部のスクリプトを把握できるよう，案の項目を一つ修正した。D 氏とともに，そのほかの過去のインシデントについても案を評価したところ，案は有効であると確認できたので，経営陣に報告して承認を得た。
〔ガイドラインを用いた点検の実施〕
ガイドラインを用いて，現在進行中の全てのシステム開発プロジェクト及び運用サービスを点検することになった。最初の点検対象は，システム S の開発プロジェクト及び運用サービスである。B さんがプロジェクト計画書，運用計画書などからまとめたシステム S の開発プロジェクト及び運用サービスの概要を図1に，開発環境の構成図を図2に示す。
図1 システム S の開発プロジェクト及び運用サービスの概要図1 システム S の開発プロジェクト及び運用サービスの概要（続き）図2 システム S の開発環境の構成図（抜粋）
B さんは，システム S の担当者へのヒアリング前に論点を整理しておこうと考え，表1の各項番について，図1に基づき，対策状況を確認した。結果は表2のとおりである。
表2 システム S の事前確認結果（抜粋）
B さんは，システム S の担当者である C さんにヒアリングを行った。
〔SBOM についての確認〕
次は，表1の項番10についての C さんと B さんの会話である。
C さん：システム S のソフトウェア構成は設計書で把握できると考えていますが，SBOM の作成も必要でしょうか。
B さん：SBOM を利用すると，⑥将来，脆弱性管理がしやすくなります。プラットフォーム G で作成することができます。
C さん：なるほど。それでは，SBOM の作成を検討します。
〔開発工程のセキュリティ対策についての確認〕
B さんは，表1の項番7，8について確認した。次は，そのときの B さんと C さんの会話である。
B さん：表1の項番7の対策は実施できていますか。
C さん：オフショア拠点から開発 LAN へのアクセスについては VPN-GW でアクセスログを取得できているものの，社内からのアクセスについては取得できていません。
B さん：アクセスログは図2中の d で取得するのがよいでしょう。
C さん：分かりました。
B さん：表1の項番8の対策はどのようにしていますか。
C さん：現在はソースコードの変更内容を開発リーダーがレビューしています。
B さん：開発リーダーによるレビューに加えて，ツール F でチェックするのがよいでしょう。
C さん：開発フローのどこでツール F を実行するのがよいでしょうか。
B さん：ツール F の特性を踏まえると，図3のシステム S の開発フロー中の（あ）又は（い）で実行するのがよいと考えられます。⑦それぞれ利点が異なります。
L 社から業務委託先に要求しているセキュリティ対策と同じ水準の対策を，業務委託先から再委託先に対しても要求させることを契約書に明記しておけば，再委託先の段階でセキュリティ対策が緩んでしまうことを防げる。これは図1の項番4で N 社（委託先）との契約に“N 社が再委託を行わないこと”を明記している例とも対応する，再委託時の対策の作り方の一つである。
スクリプト P は，T 社が運営するサーバ（以下，サーバ T という）に配置され，システム Q にアクセスした Web ブラウザがスクリプト P を都度読み込むようにシステム Q は構成されていました。ある日，サーバ T が乗っ取られてしまい，スクリプト P が改ざんされたことによって，システム Q への利用者のアクセスが悪意のある Web サイトにリダイレクトされてしまいました。
〔過去のインシデントの確認〕
③スクリプト P を利用していたシステムでもスクリプト P の配置方法が違えば，影響を受けなかったようですね
インシデントが起きた原因は，システム Q が自分のサーバではなく T 社のサーバ T からスクリプト P をその都度読み込む構成にしていたことにある。サーバ T が乗っ取られてスクリプト P が改ざんされると，その改ざんがそのままシステム Q の利用者に届いてしまう。
影響を受けない配置方法は，スクリプト P を外部のサーバから都度読み込むのではなく，あらかじめダウンロードしておいて自分（システム Q）のサーバ上に置き，そこから読み込ませる方法である。この場合はサーバ T が後から改ざんされても，システム Q が参照するのは自分のサーバに保存した時点のスクリプト P のままなので影響を受けない。
字数制限は無いので，“スクリプト P をダウンロードしておく”という取得の仕方と，“システム Q のサーバ上に配置する”という置き場所の両方を残して答える。
SBOM 作成機能はリポジトリサーバ内のソースコードとライブラリしか一覧化しないので，サーバ T のように外部で運用され，実行時に都度読み込まれるスクリプト P は SBOM に現れない。つまり SBOM を作っても，このインシデントで使われたような外部スクリプトの存在には気付けない。
ガイドライン案で情報資産を一覧化する項番1を見ると，対象はサーバ・ネットワーク機器・ソースコード・リポジトリ内のライブラリに限られており，スクリプト P のように外部のサービスから読み込んで使う資産が抜けている。そこで B さんは，項番1に「連携している外部サービスを管理対象に含める。」という一文を加え，スクリプト P のような外部提供のスクリプトも一覧化の対象にした。
a は，表1の項番2「責任追跡性を確保するためにアカウントの利用者を特定できるようにすること」についての問題点である。図1の項番10では，踏み台サーバへのログインは会社ごとの共用アカウントで行い，ログインごとに利用記録簿へ記載するとしている。共用アカウントでは，ログインした個人までは特定できないので，責任追跡性の要件を満たしていない。
（あ）は，開発者の端末でコンパイルが通った直後，開発者が自分でテストを始める前の位置である。ここでツール F を実行すると，開発者は自分の変更をリポジトリにアップロードする前に，ツール F が検知できる不備に気付ける。問題が見つかればその場で直してからアップロードできるので，より早い段階でエラーを発見できる。
（い）は，プラットフォーム G 上で他の開発者の変更も取り込んだコンパイルが通った直後の位置である。プラットフォーム G の CI/CD パイプラインの管理機能を使えば，ここでのツール F の実行をワークフローとして自動化でき，開発者が手作業でツール F を実行し忘れる心配がない。
M 社は，従業員 3,000 名の情報サービス業を営む企業である。ソフトウェアの開発・販売を行っており，自社ホームページのほか，販売したソフトウェアのサポート用 Web サイトなど複数の Web サイト（以下，Web サイトをサイトという）を保有している。M 社では，メンテナンスのために管理者が自宅や外出先からサイトにリモートアクセスする。セキュリティに関する問合せ窓口は，情報システム部が担当している。
M 社が保有するサイトのうち，重要なサイト（以下，重要サイトという）は，プラットフォームに対する脆弱性診断（以下，PF 診断という）及び Web アプリケーションプログラムに対する脆弱性診断（以下，Web アプリ診断といい，PF 診断と Web アプリ診断を併せて両診断という）を初回リリース前に実施するルールになっている。初回リリース後の両診断の実施については任意である。重要サイトの指定は，扱う情報の重要性，停止による影響などを勘案し，各サイトの所管部門が判断している。重要サイト以外のサイトに対する両診断の実施は任意である。
両診断は，情報システム部の選定した専門ベンダー P 社に依頼して実施，又は情報システム部の選定した脆弱性診断ツール（以下，診断ツールという）を用いて各サイト担当者が実施する。ただし，緊急の場合，情報システム部が実施することもある。P 社の Web アプリ診断は，脆弱性が実際に悪用できることを確認した上で報告してくれるので，評判がよい。
ある日，M 社のキャンペーンサイト X（以下，サイト X という）のキャンペーンページに SQL インジェクションの脆弱性が存在しているという指摘が問合せ窓口に報告された。報告内容についてサイト担当者に確認したところ，脆弱性が存在する可能性があるとの回答であった。サイト X は重要サイトに指定されていなかった。サイト X の仕様を図1に示す。
図1 サイト X の仕様（抜粋）
情報システム部の E さんと J 課長は，報告の内容を確認するために，情報システム部が診断ツールを実行する旨をサイト X の担当者に伝えた。
Web アプリ診断用の診断ツールを該当ページに対して実行したところ，深刻度レベルが High の SQL インジェクションの脆弱性が検出された。SQL インジェクションの脆弱性検出時のクエリパラメータ及び応答を表1に示す。
表1 クエリパラメータ及び応答（概要）
E さんは，速やかにサイト担当者に連絡し，インターネットからサイト X にアクセスできないようネットワーク構成を変更した上で，該当するプログラムを修正するよう依頼した。これに対してサイト X の担当者は，“重要情報の漏えいなどの問題が発生することはない。DB には重要情報もない。サイト X にアクセスできないようにする必要はない。”と主張した。それに対して E さんは，“本脆弱性はブラインド SQL インジェクションの脆弱性に該当する。そのため，表1と同様の手法を用いることによって，DB のテーブル名が特定できることになる。”と説明した。E さんは，DB のテーブル名を使うと攻撃者が次にどのような攻撃を行えるかを説明し，対応する必要性を説いた。これを受け，迅速に対応が行われた。
〔脆弱性が存在していた状況の確認と一斉診断の実施〕
対応完了後，情報システム部では，公開サイトは全て重要サイトに指定するようにルールを変更することにした。同時に，M 社が保有する全ての公開サイトに対する一斉の両診断（以下，一斉診断という）を実施することにし，その診断を P 社に依頼した。診断対象サイトの情報を表2に示す。
表2 診断対象サイトの情報
診断の結果，深刻度レベル High 以上の脆弱性が検出されたサイトが数サイトあり，Medium 以下の脆弱性が数十件検出されたサイトも多数あった。
サイトによっては，初回リリース時の両診断以降にアップデートや設定変更をしていないにもかかわらず，初回リリース時の両診断結果と今回の一斉診断結果が異なっている場合もあった。P 社の診断は，決められた手順に従って行い，診断結果は技術レビューを行うので，診断員による差異はほぼないと，E さんは P 社から聞いていた。また，初回リリース時の両診断では，サイトに不具合はなかったと報告を受けている。E さんが，改めて P 社に確認すると，診断結果が異なっていた要因は，f や g だった。これらのことから，E さんは初回リリース後も定期的な両診断が必要であると結論づけた。
〔PF 診断で検出された脆弱性〕
PF 診断で検出された脆弱性を表3に示す。
表3 PF 診断で検出された脆弱性（抜粋）
脆弱性 PA-1 と PB-3 について，CRYPTREC が作成し，IPA が発行している“TLS 暗号設定ガイドライン Ver.3.1.0”の“4. 推奨セキュリティ型の要求設定”には，表4に示す鍵交換におけるビットセキュリティの基準を満たすよう記載されていた。そのため，サイト A 及びサイト B は基準を満たす設定に変更することにした。
表1中の a 〜 e に入れる応答を，解答群の中から選び，記号で答えよ。なお，解答は重複して選んでもよい。解答群：ア “コンテンツがありません”というメッセージが返される。，イ 2025年4月1日のキャンペーンのコンテンツが返される。，ウ サーバから応答が返されない。，エ 内部サーバエラーが返される。
〔a〕解答例
ア
〔b〕解答例
ア
〔c〕解答例
ア
〔d〕解答例
ア
〔e〕解答例
イ
解説
本文の根拠
図1
コンテンツ番号が DB サーバ上に存在しない場合，又は SQL が構文エラーになる場合は，“コンテンツがありません”というメッセージを返す。
図1
Web アプリケーションプログラムにおいて，クエリパラメータ article の値は SQL での検索では数値型として扱われる。
脆弱性 PB-2 は，送信元 IP アドレス制限が対策の一つだが現実的な運用が難しい。代わりの対策として，ログイン画面のアカウントロックがあるが，採用する場合はロック解除の運用方法や実装について検討が必要である。サイト B では，②アクセス元の PC を認証する対策を採用した。
表3
PB-2：管理者用の Web のログイン画面に認証試行が何回でも可能
脆弱性 PB-2 は，管理者用ログイン画面に認証試行の回数制限がなく，パスワードを何度でも試せてしまう問題である。送信元 IP アドレス制限は管理者がリモートアクセスする場所が一定しないため運用が難しく，アカウントロックは正規の管理者を誤って締め出したときの解除作業が課題になる。
サイト B で採用した“アクセス元の PC を認証する対策”は，あらかじめ許可した PC にだけ証明書を配布し，ログイン画面にたどり着く前に PC 自体を認証する，クライアント認証（クライアント証明書による認証）である。証明書を持たない PC からはログイン画面へのアクセス自体ができなくなるので，パスワードの総当たり試行そのものができなくなる。
20 字に収めるには，“クライアント認証を行う”という対策の名称を端的に答える。
設問4(1)解答欄2つ
本文中の下線③について，脆弱性 WA-1 の AC が L と評価された評価根拠と脆弱性 WB-1 の AC が H と評価された評価根拠を，それぞれ具体的に答えよ。
WA-1 は，パラメータ item の値が5桁の数字というだけで，総当たりや値を一つずつ変えていくだけで本来閲覧できない画面に行き着ける。特別な事前情報を入手する必要がないので AC は L である。WB-1 は，閲覧に必要な URL のパス（“administrator0001”）が推測しにくい値になっており，しかも管理者用アカウントで一度ログインするなどしてこの URL をあらかじめ入手しておく必要がある。攻撃者の努力だけでは成立させにくい条件が必要なので AC は H である。
WC-1：OS コマンドインジェクション，Critical，9.8，補足：問合せフォームが直接シェルに入力値を渡す作りになっていて，任意の OS コマンドが実行できた。ただし，管理者権限が必要な操作はできなかった。
図2
3. Web アプリケーションプログラムは，一般利用者権限の専用アカウントでプロセスを実行している。
WC-1 は OS コマンドインジェクションにより任意の OS コマンドが実行できる脆弱性であるが，管理者権限が必要な操作まではできなかった。OS コマンドは，それを実行している Web アプリケーションプログラムのプロセスの権限で動くので，そのプロセスがどの権限のアカウントで動いているかによって，できる操作の範囲が決まる。
図2の項番3には，Web アプリケーションプログラムは一般利用者権限の専用アカウントでプロセスを実行していると書かれている。管理者権限を持たないアカウントで動いている以上，OS コマンドインジェクションが成功しても，実行できるコマンドは一般利用者権限の範囲に限られ，管理者権限が必要な操作はできない。これはサイト C がもともとそのように設計されていたこと（仕様どおり）を示している。
まず表7・表8の各脆弱性が1次評価で領域I〜IIIのどれに区分されるかを，表3・表5の基本値としきい値 A（7.0），EPSS 値としきい値 B（1％）で判定する。基本値がしきい値 A 以上かつ EPSS 値がしきい値 B 以上なら領域I，基本値が A 以上で EPSS 値が B 未満なら領域II，基本値が A 未満で EPSS 値が B 以上なら領域IIIである。PB-1（基本値8.1，EPSS 39％）は領域I，PC-1（基本値5.9，EPSS 96.54％）は領域III，PD-1（基本値7.2，EPSS 0.0％）は領域II，PD-2（基本値9.8，EPSS 2.6％）は領域I，PE-1（基本値6.5，EPSS 8.7％）は領域IIIになる。Web アプリ診断の WA-1〜WC-1 は，下線⑥のとおり EPSS 値がしきい値 B より高いとみなすので，基本値だけで領域IかIIIかが決まる。WA-1（基本値4.3），WB-1（基本値5.3），WC-1（基本値9.8）はいずれも基本値がしきい値 A 未満又は以上のどちらでも，EPSS が B 以上という前提なので領域I又はIIIになる。
区分した領域と表7・表8の環境値を，表6の対応優先度表に当てはめる。PB-1（領域I，環境値8.1）は7.0〜8.9の行で A，PC-1（領域III，環境値7.7）も領域I，IIIの行なので7.0〜8.9で A，PD-1（領域II，環境値5.7）は領域IIの行の4.0〜6.9で C，PD-2（領域I，環境値8.0）は7.0〜8.9で A，PE-1（領域III，環境値6.5）は領域I，IIIの行の4.0〜6.9で B になる。WA-1（環境値5.0）は領域I，IIIの行の4.0〜6.9で B，WB-1（環境値7.1）は同じ行の7.0〜8.9で A，WC-1（環境値9.8）は同じ行の9.0〜10.0で S になる。
A 社は，撮影機器の販売や写真のプリントサービスを全国に 200 店舗で展開する従業員 2,000 名の企業である。実店舗の運営に加え，インターネットを介して撮影機器の販売を行う EC サイト事業を有している。このたび，会員がスマートフォン（以下，スマホという）用アプリケーションプログラム（以下，スマホ用アプリケーションプログラムをスマホアプリという）を通じて，写真入りのカレンダーなどのグッズ（以下，フォトグッズという）を注文できるサービス（以下，E サービスという）を新規に開始することになった。E サービス用スマホアプリ（以下，F アプリという）は国内で流通する主要なスマホ OS である OS-α と OS-β の過去5年以内に正式リリースされたバージョンをサポートする。
〔E サービスの説明〕
E サービスは，F アプリとサーバサイドのシステム群で構成される。F アプリは，インターネットを介して E サービス用 Web サーバ（以下，A 社 Web サーバといい，FQDN は www.a-sha.co.jp とする）及び大手クラウドサービスプロバイダ C 社のクラウドストレージサービス（以下，C サービスという）との間で HTTPS を使用して通信する。フォトグッズの作成に使う写真は，F アプリから C サービスにアップロードする。E サービスのネットワーク構成を図1に，機能概要を図2に，F アプリの画面構成を図3に，フォトグッズの注文処理の流れを図4に，C サービスの仕様を図5に示す。
図1 E サービスのネットワーク構成（概要）図2 E サービスの機能概要（抜粋）図3 F アプリの画面構成（抜粋）図4 フォトグッズの注文処理の流れ図5 C サービスの仕様（抜粋）図5 C サービスの仕様（抜粋）（続き）
E サービスで使う C サービスのストレージ名は，e-service である。F アプリでは，方式a を利用する。アクセスキーは，鍵長 256 ビットの共通鍵と AES-CBC アルゴリズムで暗号化し，F アプリ内にリソースとして保存する。C サービスのストレージ名並びに AES-CBC の共通鍵及び初期ベクトルは，F アプリのコード中に定数として定義する。
〔キャンペーン案内機能の実装方法〕
F アプリでのキャンペーンページの表示には，WebView という仕組みを用いる。WebView は，スマホ OS の提供する仕組みであり，スマホアプリの画面の一部に Web ページを表示させることができる。キャンペーンページの HTML は，WebView を用いて，F アプリの画面上に表示させる。
キャンペーンページ以外から getToken 関数を悪用されないように，getToken 関数の内部では，図7のように呼出し元の Web ページの URL を確認する。
図7 getToken 関数の処理の流れ
F-URL の例を図8に示す。
図8 F-URL の例
〔F アプリの脆弱性診断結果〕
A 社は，セキュリティ専門会社の D 社に依頼して F アプリの脆弱性診断を実施した。その結果，表1に示す脆弱性が検出された。
表1 脆弱性診断結果（抜粋）
〔脆弱性1〕
F アプリの開発チームに所属する U さんは，D 社の S さんが開催する診断結果報告会に参加した。
U さんは，脆弱性1が作り込まれた経緯を説明した。U さんによると，F アプリと A 社 Web サーバとの間の通信内容に異常がないかどうかを調査するために，開発用 PC で通信解析ツールを利用した。この通信解析ツールはプロキシサーバとして動作する。このツールを利用すると，F アプリでは，サーバ証明書の検証エラーが発生し，F アプリと A 社 Web サーバとの間の通信が中断されてしまった。そこで，インターネット上のある記事でエラーが発生しても通信を続行する方法が紹介されていたのを参考にして，F アプリのコードを変更したということであった。
U さんは，通信解析ツールを利用してテストを行う際も通信を正常に続行させる方法をチーム内で話し合った。その結果，今後，開発用のスマホに⑥必要な設定を行うことにした。加えて，OS-α ではテストを行う際だけその設定を有効化するように，F アプリの中にも設定を追加した。
〔脆弱性2〕
脆弱性2への対応について，S さんからは方式bを利用し，その際に署名付き URL の生成を図4中の i の時点で行ってはどうかとの提案があった。U さんは S さんの提案を了承した。
〔脆弱性3〕
次は，脆弱性3についての U さんと S さんの会話である。
U さん：対策として，図7の処理を修正します。
S さん：図7の処理を修正すれば，認証トークンを盗まれるリスクは回避できます。しかし，Web ブラウザと比べると，⑦フィッシングサイトにアクセスしてしまっても気付くことができないという F アプリの仕様上の問題点が残ります。フィッシングサイトに気付くことができるようにするための機能か，そもそもフィッシングサイトにアクセスできないようにする機能が必要です。
U さん：はい。図7の処理の修正に加えて，⑧フィッシングサイトにアクセスできないようにする機能を実装します。
TLS のサーバ証明書には，その証明書がどのホスト名に対して有効かを示す Subject Alternative Name（SAN）が含まれる。スマホはアクセス先のホスト名 www.a-sha.co.jp と証明書の SAN を照合して正当性を確認しようとするので，通信解析ツールが生成する証明書の SAN には，アクセス先と同じ www.a-sha.co.jp を設定しておく必要がある。
したがって，SAN の値は www.a-sha.co.jp である。
設問2(2)解答欄8つ
図9中の a 〜 h に入れる適切な字句を，解答群の中から選び，記号で答えよ。解答群：ア Certificate，イ Certificate Verify，ウ Client Hello，エ CONNECT ○○○.○○○.○○○.○○○:443 HTTP/1.1，オ CONNECT www.a-sha.co.jp:443 HTTP/1.1，カ Finished，キ GET /campaign/□□□ HTTP/1.1，ク HTTP ステータスコード 101（Switching Protocols），ケ HTTP ステータスコード 200（OK），コ Server Hello
ハンドシェイクが終わって暗号化チャネルが確立すると，スマホは h として実際の HTTP リクエスト“GET /campaign/□□□ HTTP/1.1”（キ）を送る。通信解析ツールは A 社 Web サーバとの間でも同様に TCP 接続と TLS ハンドシェイクを行った上で，この h を中継し，A 社 Web サーバからの応答 b（200 OK）をスマホへそのまま中継する。
設問2(3)
本文中の下線⑥について，設定の内容を，具体的に答えよ。
解答例
通信解析ツールのプライベート認証局のルート証明書をインストールし，信頼設定を行う。
解説
本文の根拠
図9 注1
通信解析ツールは，自身のプライベート認証局機能を用いる。
〔脆弱性1〕
このツールを利用すると，F アプリでは，サーバ証明書の検証エラーが発生し，F アプリと A 社 Web サーバとの間の通信が中断されてしまった。そこで，インターネット上のある記事でエラーが発生しても通信を続行する方法が紹介されていたのを参考にして，F アプリのコードを変更したということであった。
通信解析ツールが生成するサーバ証明書は，世の中の Web ブラウザや OS があらかじめ信頼している公的な認証局ではなく，ツール自身のプライベート認証局が発行したものである。スマホの OS はこのプライベート認証局を知らないので，証明書の検証エラーになっていた。
図4では，A 社 Web サーバが注文内容を DB サーバに登録して注文番号を採番した直後が（い）であり，その後に「注文番号を通知」が続く。この時点で注文番号（＝アップロード先のファイル名）が確定しているので，A 社 Web サーバはここで署名付き URL を生成し，注文番号の通知と合わせて F アプリに渡せる。（あ）は注文番号が決まる前なのでファイル名を確定できず，（う）（え）は F アプリ側の処理であり，秘密鍵であるアクセスキーを使う署名の計算をクライアント側で行うことになってしまう。
V 社は，従業員 3,000 名の製造業である。東京に本社，大阪，名古屋，福岡に支社がある。V 社は，J 事業部，K 事業部，情報システム部（以下，情シ部という），総務部，経理部などから成る。
V 社の社内システム及びネットワークの運用並びに情報セキュリティ管理は，情シ部の B 部長と S 主任を含む8名の部員が担当している。V 社のネットワーク構成を図1に示す。
図1 V 社のネットワーク構成
公開 Web サーバでは，V 社製品のキャンペーンなどを紹介している。V 社本社と各支社及び V 社データセンターの間は UTM の VPN 機能を使用して通信を行っている。各支社には，UTM を除いてインターネットからアクセス可能な IT 機器はない。
V 社の IT 資産管理，ドメイン名及び IP アドレスの管理，導入ソフトウェア（以下，ソフトウェアを SW という）の管理並びに脆弱性管理の現状を表1に示す。
表1 V 社の IT 資産管理，ドメイン名及び IP アドレスの管理，導入 SW の管理並びに脆弱性管理の現状表1 V 社の IT 資産管理，ドメイン名及び IP アドレスの管理，導入 SW の管理並びに脆弱性管理の現状（続き）
最近，次のようなサイバー攻撃のニュースが報道された。
(1) CVE-20XX-XXXXX という Web サーバでの通信の暗号化に関する脆弱性が公表され，それを悪用した攻撃で，ある広告代理店に大きな被害が発生した。
(2) 著名な会社が1年前，CDN 事業者のサービスを利用して Web サーバを立ち上げ，1か月間商品のキャンペーンを行った。この Web サーバには，その会社のサブドメインを使用した。キャンペーン後すぐに，CDN サービスを解約したが，今になって，そのサブドメインが海外の会社の広告サイトとして使われていることが発覚した。
(3) 競合他社で，不要になったにもかかわらず公開されたままとなっていた Web サーバが改ざんされ，フィッシングに悪用されていることが発覚した。
これらを受けて，V 社の経営層は，V 社でも対策が必要だと考え，対策の検討と実施を情シ部に指示した。(2)については，V 社でも，CDN 事業者のサービスを利用して Web サーバを立ち上げてキャンペーンを行った後，CDN サービスを解約した経緯があったので，緊急に確認した。その結果，問題があることが分かり，①図1中のサーバの設定を変更した。この事態も踏まえて，公開 IT 資産管理及び脆弱性管理を見直すことにした。
〔公開 IT 資産管理及び脆弱性管理の目標の設定〕
情シ部の B 部長と S 主任は，まず，公開 IT 資産管理の現状を分析し，公開 IT 資産管理及び脆弱性管理の主な目標を表2にまとめた。
表2 公開 IT 資産管理及び脆弱性管理の主な目標（抜粋）
〔目標 K-1 の実現〕
まず，目標 K-1 について検討を行い，各事業部への未登録の公開 IT 資産の調査依頼を図2にまとめた。
図2 事業部への調査依頼
次は，目標 K-1 の実現に関する B 部長と S 主任の会話である。
B 部長：事業部への調査依頼だけでは漏れが出そうだ。情シ部としても調査すべきだが，どのような方法があるのか。
S 主任：自分でインターネットをスキャンする方法（以下，オンアクセス型という）と，既に外部に構築されているデータベースを検索する方法（以下，検索エンジン型という）があります。
B 部長：どちらの方がよいだろうか。
S 主任：オンアクセス型では他社の環境に負荷を与える可能性があります。また，スキャンするには時間が掛かります。今回は検索エンジン型を使用したいと思います。
B 部長：分かった。検索エンジン型だと，具体的には，どのような方法があり，どのような情報が収集できるのかな。
表3 X サービスで検索可能な情報（抜粋）表4 Y サービスで検索可能な情報（抜粋）表5 Z サービスで検索可能な情報（抜粋）
B 部長：当社が管理すべき公開 IT 資産をできるだけ多くリストアップしてほしい。
S 主任：事業部から提出されるリストと突合せができるように，当社が取得した GIP，ドメイン名，GIP の組織名，部署名及び担当者名，ドメイン名の組織名，部署名及び担当者名並びに FQDN を抽出してまとめたリスト（以下，F リストという）を作成してみます。F リストの作成手順を図3に示します。
図3 F リストの作成手順
〔V 社の管理すべき IT 資産の確認と管理の強化〕
事業部の提出した未登録の公開 IT 資産一覧と S 主任の調査結果を突合したところ，幾つか F リストだけにあるもの（以下，調査漏れという）が見つかった。次は，B 部長と S 主任の会話である。
B 部長：どのような調査漏れが見つかったのか。
S 主任：調査漏れのリストは表6のとおりです。事業部からの説明では，古いケースで調査しきれなかったとのことでした。
表6 調査漏れのリスト（抜粋）
S 主任：表6の結果1については，SSH では接続できませんでしたが，公開サービスは Web だけが稼働しているようだということが，X，Y，Z サービス以外の②調査から分かりました。しかし，G 事業部はもはや存在しません。調べたところ，K 事業部が業務継承部門です。また，利用 OS や SW もバージョンが古く，多くの脆弱性が内在しているようだということが，③別の調査から分かりました。
S 主任：攻撃を受けて被害が発生しないようにするために，④表6の結果1の公開 IT 資産を継続利用する場合としない場合のそれぞれの場合に K 事業部が行うべき具体的な対応方法を伝えます。
〔脆弱性管理の改善〕
次に，目標 K-2 及び目標 K-3 に対する実現方法を検討した。目標 K-2 については，S 主任が必要なルールを決めた。次は，目標 K-3 の実現方法についての B 部長と S 主任の会話である。
B 部長：目標 K-2 が実現できたとしても，次々発表される脆弱性に対して，対策の優先度などはどのように判断すればよいのか。
S 主任：脆弱性についての⑤ CVSS の深刻度と⑥ KEV カタログへの掲載の有無に基づいて判断するのがよいです。対策の優先度などの判断ルールを作成します。
B 部長：分かった。そのルールも踏まえ，目標 K-3 を実現するために，⑦表1の脆弱性管理の改善策を考えてほしい。
S 主任：分かりました。
さらに，目標 K-4 について，公開 IT 資産の利用終了時に行うべき措置を S 主任がまとめた。
経営層に対応策を説明し，了承を得た。その後，B 部長と S 主任が作成したルールに従って，V 社の公開 IT 資産管理及び脆弱性管理の運用が開始された。
(2) 著名な会社が1年前，CDN 事業者のサービスを利用して Web サーバを立ち上げ，1か月間商品のキャンペーンを行った。この Web サーバには，その会社のサブドメインを使用した。キャンペーン後すぐに，CDN サービスを解約したが，今になって，そのサブドメインが海外の会社の広告サイトとして使われていることが発覚した。
本文
(2)については，V 社でも，CDN 事業者のサービスを利用して Web サーバを立ち上げてキャンペーンを行った後，CDN サービスを解約した経緯があったので，緊急に確認した。その結果，問題があることが分かり，①図1中のサーバの設定を変更した。
表1 ドメイン名及び IP アドレスの管理
事業部が V 社のドメイン名を使用する場合は，情シ部にドメイン使用申請を行う。この際，情シ部は，必要な DNS レコードを登録している。
ニュース(2)は，CDN 事業者のサービスで使ったサブドメインを，サービス解約後もドメイン名の DNS レコード（CNAME レコードなど）から削除しないままにしていたために，解約で空いた CDN 側のアドレスを他者（攻撃者）が取得し，V 社のサブドメイン名でアクセスすると攻撃者のサイトが表示されてしまう，いわゆるサブドメインテイクオーバーの事例である。
V 社でも同様に CDN サービスを使ってキャンペーンサイトを立ち上げ，解約した経緯があった。V 社のドメイン名の DNS レコードは情シ部が登録しており，図1の DMZ にある権威 DNS サーバがこれを保持している。キャンペーン終了後も，そのサブドメインを CDN サービスに向ける CNAME レコードが残っていれば同じ問題が起き得るので，緊急に確認した結果，このレコードが残っていたことが分かった。
したがって，設定を変更したサーバは権威 DNS サーバであり，変更内容は終了したサブドメインの CNAME レコードを削除することである。
IP アドレスの割当てやドメイン名の登録者情報など，レジストラ・レジストリが管理する情報を問い合わせるための標準プロトコルは WHOIS である。WHOIS プロトコルは RFC 3912 で定義されている，簡潔なテキストベースの問合せ・応答プロトコルで，ドメイン名や IP アドレスを指定して問い合わせると，登録者や管理者の情報が返ってくる。
本文で紹介されている X サービス・Y サービス・Z サービスは，いずれもこの WHOIS などの情報を基にした検索サービスである。
手順1は，検索キーワード d（V 社）を指定して，FQDN e と GIP f を得ている。組織名を検索キーワードにして FQDN や GIP が得られるのは，表5の Z サービス（検索キーワード“ドメイン名，GIP，又は組織名”で GIP・FQDN などが得られる）である。したがって あ は Z である。
手順2-1，2-2 は，手順1で得たドメイン名（FQDN に含まれる .jp ドメイン）を検索キーワードにして，その組織名や担当者識別番号，さらに部署名・担当者名を得ている。ドメイン名を検索キーワードにして組織名や担当者識別番号が得られるのは，表3の X サービスである。したがって い は X である。
手順3-1，3-2 は，手順1で得た GIP（f）を検索キーワードにして，その組織名や担当者識別番号，部署名・担当者名を得ている。GIP を検索キーワードにして組織名や GIP の担当者識別番号が得られるのは，表4の Y サービスである。したがって う は Y である。
設問2(4)解答欄5つ
図3中の d 〜 h に入れる適切な内容を，次の解答群の中から選び，記号で答えよ。解答群：ア FQDN，イ GIP，ウ GIP 割振り元の事業者名，エ OS，オ V 社，カ 位置情報，キ 担当者識別番号，ク ドメイン名，ケ ポート番号，コ メールアドレス
攻撃を受けて被害が発生しないようにするために，④表6の結果1の公開 IT 資産を継続利用する場合としない場合のそれぞれの場合に K 事業部が行うべき具体的な対応方法を伝えます。
ニュース(3)
(3) 競合他社で，不要になったにもかかわらず公開されたままとなっていた Web サーバが改ざんされ，フィッシングに悪用されていることが発覚した。
表6の結果1は，既に存在しないはずの G 事業部名義で公開されたままの古いサーバで，利用 OS・SW のバージョンが古く多くの脆弱性が内在している。このまま放置すれば，ニュース(3)のように改ざんされてフィッシングなどに悪用されるおそれがある。
継続して利用する場合は，脆弱性を抱えたまま公開を続けるわけにはいかないので，一旦サービスを停止し，脆弱性を修正してから公開を再開する必要がある。継続して利用しない場合は，もはや不要な公開 IT 資産を放置する理由がないので，速やかにネットワークから切り離して停止し，機器そのものを廃棄してしまうのがよい。
