H 社では，コンサルティング業務で利用する SaaS（以下，S サービスという）を提供している。コンサルティング業務を行う企業 50 社程度が S サービスを利用しており，総利用者数は 1,000 名程度である。
〔S サービスの概要〕
S サービスでは，利用企業ごとに複数のプロジェクトを登録できる。S サービスの利用者には 2 種類のロールがある。自社の全てのプロジェクトの情報にアクセスできる管理者と，自身に割り当てられているプロジェクトの情報だけにアクセスできる一般利用者である。
S サービスには，プロジェクトを管理する機能（以下，プロジェクト管理機能という）のほか，利用者がプロジェクト内で特定の話題ごとに“スレッド”と呼ばれるページを作成する機能（以下，スレッド作成機能という），スレッドに文章を投稿したりファイルをアップロードしたりする機能（以下，スレッド投稿機能という）などが設けられている。
S サービスの主な機能を表1に示す。
表1 S サービスの主な機能（抜粋）
S サービスでは，半年ごと及び新機能リリース前に診断ツール X による脆弱性診断を実施することにしている。診断ツール X は，送信したリクエストとそれに対するレスポンスから脆弱性を検出する。
S サービスでは，HTTP レスポンスヘッダーに Content Security Policy（CSP）を設定している。図1に，S サービスの HTTP レスポンスヘッダーの例を示す。
図1 S サービスの HTTP レスポンスヘッダーの例
図1の設定では，リソースの読込みとスクリプトの実行に関する動作は次のようになる。
S サービス以外のドメインからのリソースの読込み：a
script タグ内に直接記述されたスクリプトの実行：b
〔インシデントの発生とその調査〕
ある日，S サービスを利用している B 社の管理者から H 社に対して，“S サービスの一般利用者であった元従業員 Z のローカル PC 上に，元従業員 Z が割り当てられていなかったプロジェクトのファイルが保存されていたので，S サービスに不具合がないか調査してほしい”との依頼があった。
S サービスのシステム担当者である U さんは，ログを確認するとともに，B 社の許可を得た上で，B 社の管理者の利用者 ID を使ってログインし，幾つかの画面を確認した。そのうち，プロジェクト進捗管理画面の HTML を図2に，その HTML が参照していた F1234567890.xlsx というファイルをテキストエディターで開いたときの内容を図3に示す。
図2 プロジェクト進捗管理画面の HTML図3 F1234567890.xlsx の内容
U さんは，調査の結果，図4に示す攻撃が実行されていたことを確認した。
図4 実行されていた攻撃
U さんは，図4の項番 2 と類似した文字列が指定されたタスクが登録されていないかどうかを確認したところ，完了済みタスクの中に類似したものがあることを確認した。しかし，このタスクによる攻撃は，CSP の設定で防御できていた。
U さんは，攻撃者がこの失敗の原因を分析し，失敗したときに使用した文字列に①工夫を加えることによって図4の項番 2 の文字列を作成し，攻撃を成功させたと推測した。
〔インシデントへの対応及び攻撃への対策〕
U さんは，まず必要なインシデント対応を行った。その結果，図4以外に成功した攻撃はないことが分かった。U さんは，結果を B 社の管理者に報告した。また，ほかの利用企業で同様の攻撃がなかったかどうかを調査したところ，なかったことも分かった。
図3のスクリプトは，まず“/management/role”を GET で呼び出して応答の HTML から csrf_token を取り出し（2〜6行目），次に“/management/roleset”へ csrf_token，is_admin=1，user_id=U00331001 を POST している（7〜15行目）。表1によれば，この二つのパスはどちらもロール管理機能の処理の流れ（1. ロール設定画面の表示，2. ロールの変更）そのものである。
つまりスクリプトは，ロール管理機能の正規の手順をなぞって，利用者 U00331001 のロールを管理者（is_admin=1）に変えようとしている。ロール管理は管理者が使う機能なので，このスクリプトが管理者の Web ブラウザで実行されると，管理者の権限でロールの変更が通ってしまう。
間違えやすい点。fetch の宛先だけを見て“利用者管理”と答えないこと。利用者 ID は利用者管理機能で発行されるが，ロール（管理者か一般利用者か）を設定するのは表1のロール管理機能である。
f は，攻撃用のタスク名が画面に出力される条件である。表1によれば，プロジェクト進捗管理画面にタスク名が出るのは“未完了のタスクのうち締切日を過ぎたもの”なので，図4の条件“未完了の状態で，かつ，f”の残りは“タスクの締切日を過ぎる”である。
e は，その画面を開いてスクリプトを実行させられた人である。図3のスクリプトが呼ぶロール管理機能は管理者しか使えないので，攻撃が成功するには管理者の Web ブラウザで実行される必要がある。U さんが“B 社の管理者の利用者 ID を使ってログイン”して図2の HTML を確認していることとも合う。e は“管理者”。g は図3の12・13行目のとおり，U00331001 に is_admin=1 を送る処理，つまり利用者のロールを管理者に設定する処理である。管理者になった Z は，割り当てられていないプロジェクトのファイルも含め，自社の全てのプロジェクトの情報にアクセスできるようになり，図4の項番8でファイルをダウンロードした。
図2では，タスク名の“<”や“>”がそのまま HTML に書き出されたため，Web ブラウザはそれを文字ではなく script タグとして解釈した。タスク名を HTML に出力するときに，“<”を“<”，“>”を“>”，“"”を“"”，“&”を“&”のように，HTML で特別な意味を持つ文字を文字参照に置き換えるエスケープ処理を施せば，タスク名は画面上に文字列として表示されるだけになり，スクリプトは実行されない。
S サービスでは，半年ごと及び新機能リリース前に診断ツール X による脆弱性診断を実施することにしている。診断ツール X は，送信したリクエストとそれに対するレスポンスから脆弱性を検出する。
〔インシデントへの対応及び攻撃への対策〕
なお，この処理が行われていないという脆弱性は，診断ツール X では検知されない。
〔開発プロセスの見直し検討〕
U さんは，図4の項番 4 の脆弱性のように診断ツール X で検知されないものであっても，検知できる可能性のある検査として，次の二つも実施するという開発プロセスの見直し案を作成した。
診断ツール X は，送ったリクエストとそれに対するレスポンスを見て脆弱性を探す。ところが今回の脆弱性は，タスク名を登録したリクエストの応答には現れず，そのタスクが未完了のまま締切日を過ぎた後に，別の画面（プロジェクト進捗管理画面）を開いたときに初めて出力に現れる。入力と出力が別の機能・別の時点にまたがるので，リクエストと応答を突き合わせるだけのツールでは検知されない。
A 社は従業員 50 名の暗号資産交換業者である。A 社では，3 年前から暗号資産 B コインを取り扱っており，20 万人の顧客が暗号資産口座を開設している。A 社には財務部があり，顧客の預けた時価 200 億円相当の B コインを顧客に代わって保有し管理している。
〔B コインの仕組み〕
B コインは，楕円曲線暗号を用いたデジタル署名方式を用いて，分散型台帳で管理される。B コインの保有者が，別の者に B コインを送ることを移転という。B コインを移転する際は，まず，B コインの移転先，移転数量などを含むバイナリ形式で表現された B コインの移転指示情報（以下，移転情報という）に対して，移転元の署名鍵を用いてデジタル署名し，次に，そのデジタル署名済みの移転情報を B コインの分散型台帳を保存するサーバ（以下，B コインノードという）の一つに送付する。デジタル署名済みの移転情報は，移転元の署名鍵に対応する検証鍵を用いて検証することができる。同一の移転情報は一度しか分散型台帳に記録されず，重複して B コインが移転されることはない。B コインノードは，誰でも自由にインターネット上に立ち上げることができる。
〔A 社のシステム構成〕
A 社のシステム構成を図1に，機器の概要を表1にそれぞれ示す。
図1 A 社のシステム構成（抜粋）表1 A 社の機器の概要（抜粋）
施設 K には鍵管理 PC と監視カメラだけが設置してあり，施設 K はネットワークから遮断されている。監視カメラの映像は，監視カメラの内蔵ストレージに保存され，定期的に内蔵ストレージから別の媒体にコピーして保管される。施設 K の出入口には金属探知機がある。A 社が保有し管理する B コインの署名鍵（以下，署名鍵 S という）は鍵管理 PC に保存してあり，対応する検証鍵（以下，検証鍵 V という）は基幹サーバに保存してある。施設 K には，①サイドチャネル攻撃を防ぐ対策が施されている。A 社は施設 K について平常時の運用ルールを図2のとおり定めている。
A 社の経営陣は，保有し管理する B コインの不正移転のうち，第三者の攻撃によるもの及び従業員一人の不正によるものの防止策を強化したいと考えた。そこで，セキュリティ部に所属する情報処理安全確保支援士（登録セキスペ）の J さんに，そういった不正移転の想定事例をまとめるよう指示した。J さんは図4のとおり想定事例をまとめた。
図4 想定事例
A 社の経営陣は出庫業務の処理手順を見直すよう財務部に指示した。財務部は，想定事例(a)に対しては，不正な移転情報を検知できるように，図5に示すシステム及び手順の改修案を考えた。
図5 システム及び手順の改修案
A 社の経営陣がこの改修案を J さんにレビューさせたところ，J さんは，この改修案では，正規の移転情報を記録したファイルの一つを不正な移転情報に書き換えた上で，メッセージダイジェストが一致するように照合ファイルを書き換えることができてしまうと指摘し，改修案において，照合ファイルにメッセージダイジェストを記録する代わりに基幹サーバ及び署名アプリに共通鍵をもたせ，その共通鍵を使った a を記録するよう提言した。
A 社の経営陣がセキュリティ部に業務 PC のログと監視カメラの映像を分析させたところ，事業開始以来，流出事案につながる不正の兆候は発見されなかった。
〔M 社による A 社の買収〕
半年後，従業員 200 名で暗号資産交換業を営む M 社が A 社を買収し，A 社の事業は M 社に統合されることになった。M 社では，M 社の署名鍵を T 社製ハードウェアセキュリティモジュール（以下，HSM という）に格納し，HSM を HSM 管理用のサーバ（以下，HSM 管理サーバという）に USB ケーブルで接続してから操作している。HSM 管理サーバは，M 社内の LAN に接続されている。
事業統合に伴って，施設 K を閉鎖し，署名鍵 S を M 社に移管する方針になった。M 社では署名鍵のネットワーク経由での送信を禁止する業務規程がある。そこで M 社は A 社に，図6に示す署名鍵 S の移送及び確認方法を提案した。
図6 署名鍵 S の移送及び確認方法
A 社の経営陣から指示があり，J さんがこの方法によって安全に署名鍵 S を移送できるかどうかを検討したところ，図6の方法には④幾つかの問題点があることが分かった。そこで，J さんは，図7を起案した。
図7 J さんの案
J さんは当初，図7の案では，⑤図7の作業 4 で移送用メディアが盗難に遭ったとしても署名鍵 S は漏えいしないと考えていた。しかし，J さんが図7の案を詳細に検討したところ，作業 2 及び 4 で移送用メディアを安全に持ち運びできたとしても，HSM 管理サーバが仮にマルウェアに感染し，その結果，攻撃者の指示によって⑥図7の作業1で移送用メディアに保存されるファイルが書き換えられ，かつ，図7の作業 5 で移送用メディアの内容を読み取られてしまった場合には，署名鍵 S が攻撃者に漏えいするリスクがあると分かった。
そこで J さんは，HSM の機能を利用して，移送用メディアに保存されるファイルの改ざんを検知できるように改良した手順を A 社及び M 社の経営陣に提案した。その結果，改良した手順を用いて施設 K から HSM まで署名鍵 S を移送することが決定した。
楕円曲線暗号を使ったデジタル署名アルゴリズムは，ECDSA（Elliptic Curve Digital Signature Algorithm）と EdDSA（Edwards-curve Digital Signature Algorithm。Ed25519 など）である。どちらも名前の“DSA”が示すとおり署名方式で，NIST FIPS 186-5 に規定されている。正解はウとエ。
施設 K には鍵管理 PC と監視カメラだけが設置してあり，施設 K はネットワークから遮断されている。
〔A 社のシステム構成〕
施設 K には，①サイドチャネル攻撃を防ぐ対策が施されている。
表1 鍵管理 PC
鍵管理 PC の製造元から調達して以降，一度もネットワークに接続しておらず，他の機器とのデータの授受には USB メモリだけを用いている。
サイドチャネル攻撃は，暗号処理をしている機器から漏れ出る物理的な情報（処理時間，消費電力，電磁波，音など）を観測して，内部の秘密鍵を推測する攻撃である。署名鍵 S は鍵管理 PC の中にあり，鍵管理 PC はネットワークにつながっていないので，ネットワーク越しには盗めない。残る手段は，鍵管理 PC がデジタル署名の計算をしているときに出す電磁波や作動音を外から観測することである。
施設 K は入室できる人も持ち込める物も限られている（図2）。そのため攻撃者は施設 K の中には入れず，施設 K の外から観測することになる。解答例は“施設 K の外から，鍵管理 PC の作動音や鍵管理 PC から放出される電磁波を観測し，署名鍵 S を推測する。”で，施設の電磁シールドや防音が下線①の対策に当たる。
書き方の注意。“具体的に”とあるので，何を（作動音・電磁波を）どこから（施設 K の外から）観測し，何を得るのか（署名鍵 S）まで書く。施設 K に侵入して鍵管理 PC を盗むような答えは，サイドチャネル攻撃ではない。
(ⅰ)と(ⅱ)の間は，正規のファイルを業務用メディアに保存した直後，施設 K に持ち込む前である。ここでマルウェア X が，B コインを攻撃者に移転する移転情報のファイルを業務用メディアに追加する。当日担当者は手順2(ⅳ)で移転情報の中身を確かめないので，署名アプリは不正なファイルにも署名鍵 S で署名してしまう。
(ⅵ)と(ⅶ)の間は，署名済みのファイルを持ち帰って業務 PC に接続した直後，アップロードする前である。ここでマルウェア X は，攻撃者向けの署名済み移転情報のファイルをインターネット経由で攻撃者に送り，業務用メディアから削除する。攻撃者は，誰でも立ち上げられる B コインノードにこれを送付すれば移転を成立させられる。削除しておくのは，手順3の基幹サーバの検査を通すためである。ファイルが残っていると，手順1で生成していない移転情報が混じって“一致しなかった”と判定され，警告の電子メールが送られてしまう。
J さんは，この改修案では，正規の移転情報を記録したファイルの一つを不正な移転情報に書き換えた上で，メッセージダイジェストが一致するように照合ファイルを書き換えることができてしまうと指摘し，改修案において，照合ファイルにメッセージダイジェストを記録する代わりに基幹サーバ及び署名アプリに共通鍵をもたせ，その共通鍵を使った a を記録するよう提言した。
メッセージダイジェスト（ハッシュ値）は，誰でも同じ計算ができる。業務 PC に感染したマルウェア X は，移転情報のファイルを書き換えたうえで，そのダイジェストを計算し直して照合ファイルも書き換えられるので，照合は素通りになる。
基幹サーバと署名アプリだけが持つ共通鍵を使い，ファイルと鍵からメッセージ認証符号（MAC。HMAC など）を計算して照合ファイルに記録すれば，鍵を持たない攻撃者は正しい MAC を作れない。署名アプリは自分の鍵で MAC を計算し直して照合ファイルの値と比べることで，ファイルの改ざんを検知できる。a は“メッセージ認証符号”である。
想定事例(b)は，当日担当者が一人で施設 K に入り，誰にも見られずに署名鍵 S を業務用メディアにコピーできることから起きる。不正の“機会”を減らすには，一人で作業する時間を無くせばよい。当日担当者を複数名にし，互いに確認しながら作業する（二人以上での作業，相互けん制）手順に変えれば，一人だけでは署名鍵 S を持ち出せない。
鍵管理 PC を用いて署名鍵 S をパスワード注1)付き圧縮ファイルに圧縮し，この圧縮ファイルを空の移送用メディアに保存する。パスワードは紙に書き留める。
図6
作業2 A 社の従業員と M 社の従業員が移送用メディア及びパスワードを書き留めた紙を M 社まで持ち運ぶ。
図6では，署名鍵 S をパスワードで暗号化した圧縮ファイルと，そのパスワードを書き留めた紙を，作業2で一緒に持ち運んでいる。パスワード自体はオフライン解析に耐える強度のものを選んでいても，移送中に移送用メディアと紙の両方を盗まれたり紛失したりすれば，誰でも圧縮ファイルを展開して署名鍵 S を手に入れられる。暗号化の意味がなくなるので，これが最もリスクの高い問題点である。
図6には，HSM 管理サーバに接続してそのメディア上で展開する点（作業3）など他の問題もあるが，移送という作業そのものに一番大きな穴があるのは作業2である。解答例は“作業 2 において，パスワードで暗号化した署名鍵 S と紙に書き留めたパスワードを一緒に移送している点”である。
図7中の b 〜 e に入れる適切な字句を b〜e の解答群の中から，［ あ ］，［ い ］ に入れる適切な字句をあ，いの解答群の中から，それぞれ選び，記号で答えよ。なお，解答は重複して選んでもよい。b〜e の解答群：ア（暗号鍵 E），イ（検証鍵 V），ウ（署名鍵 S），エ（復号鍵 D）。あ，いの解答群：オ（暗号化），カ（検証），キ（デジタル署名），ク（復号）
〔b〕解答例
ウ
〔c〕解答例
ア
〔d〕解答例
エ
〔e〕解答例
ウ
〔あ〕解答例
オ
〔い〕解答例
ク
解説
本文の根拠
図7 作業1
HSM 管理サーバを操作して HSM 内に 3,072 ビットの RSA 暗号の鍵ペアとして暗号鍵（以下，暗号鍵 E という）及び復号鍵（以下，復号鍵 D という）を生成し，暗号鍵 E を HSM 管理サーバに接続した空の移送用メディアに保存する。
図7 作業3
そして，b を c で ［ あ ］ し，生成されたデータを移送用メディアに保存する。
図7 作業6
HSM 内でこのデータを d で ［ い ］ し，得られた e を HSM に登録する。
図7は，公開鍵暗号を使った鍵の受け渡しである。受け取る側（HSM）が RSA の鍵ペアを作り，公開してよい暗号鍵 E だけを施設 K に届ける。施設 K では，署名鍵 S（b＝ウ）を暗号鍵 E（c＝ア）で暗号化（あ＝オ）し，その暗号文を移送用メディアに入れて持ち帰る。HSM の中では，HSM から出ない復号鍵 D（d＝エ）で復号（い＝ク）し，得られた署名鍵 S（e＝ウ）を登録する。
復号鍵 D は HSM の外に出ないので，署名鍵 S が平文で HSM の外に現れることは一度もない。
間違えやすい点。“デジタル署名”“検証”は署名鍵と検証鍵の組で使う操作で，ここで行うのは秘密を守るための暗号化と復号である。e は復号して“得られた”もの，つまり移送の対象だった署名鍵 S で，b と同じ記号になる（設問の“重複して選んでもよい”はこのため）。
設問4(3)
本文中の下線⑤について，J さんが考えていた根拠を答えよ。
解答例
復号鍵Dがないので，暗号化された署名鍵Sは復号できない。
解説
本文の根拠
本文
J さんは当初，図7の案では，⑤図7の作業 4 で移送用メディアが盗難に遭ったとしても署名鍵 S は漏えいしないと考えていた。
図7 作業3
移送用メディアから暗号鍵 E を削除する。
作業4で持ち運ぶ移送用メディアに入っているのは，暗号鍵 E で暗号化した署名鍵 S だけである（暗号鍵 E も作業3で削除している）。これを元に戻すには，対になる復号鍵 D が要るが，復号鍵 D は作業1で HSM の中に生成され，HSM の外には出ていない。
したがって，移送用メディアを盗んだ者には暗号化された署名鍵 S を復号する手段がなく，署名鍵 S は漏えいしない。解答例は“復号鍵 D がないので，暗号化された署名鍵 S は復号できない。”である。
HSM 管理サーバが仮にマルウェアに感染し，その結果，攻撃者の指示によって⑥図7の作業1で移送用メディアに保存されるファイルが書き換えられ，かつ，図7の作業 5 で移送用メディアの内容を読み取られてしまった場合には，署名鍵 S が攻撃者に漏えいするリスクがあると分かった。
図7 作業1
暗号鍵 E を HSM 管理サーバに接続した空の移送用メディアに保存する。
作業1で移送用メディアに保存されるファイルは暗号鍵 E である。HSM 管理サーバに感染したマルウェアがこれを，攻撃者が自分で生成した鍵ペアの暗号鍵（公開鍵）にすり替えると，施設 K の鍵管理 PC は気付かずにその鍵で署名鍵 S を暗号化する。作業5で移送用メディアが再び HSM 管理サーバに接続されたとき，マルウェアがその暗号文を読み取って攻撃者に送れば，攻撃者は手元の復号鍵で署名鍵 S を復号できる。
F さんは，これらの検討結果を踏まえ，攻撃者口座に振り込んでしまうリスクは Z-IB の方が低いと T 主任に報告した。T 主任は報告の内容に加えて他の機能も比較し，P 社での利用において Z-IB のセキュリティ対策に問題がないことを確認した。T 主任は G さんに，Y-IB より Z-IB の方が被害に遭うリスクが低く，利用しても問題がないと回答し，経理係では Y-IB から Z-IB に変更することにした。
〔リモートワークの検討〕
各部から育児，看護及び介護を理由とした，自宅でのリモートワーク導入の要望が挙がったことから，H 部長は，経理係の IB の利用及び情報システム係の情報システムの管理はリモートワークの対象外にする前提で，全従業員のリモートワークに必要なインフラを検討するよう T 主任に指示した。また，リモートワーク実施に当たって必要となる情報セキュリティ対策を併せて検討するように指示した。
T 主任と F さんは，最初に，リモートワークに必要なインフラを検討することにした。まず，R 社のモバイルルータ（以下，R-MR という）及び R-MR を用いるインターネット接続サービス（以下，R サービスという）について調査した。その結果，R サービスではインターネットに接続したときに割り当てられるグローバル IP アドレスに，固定グローバル IP アドレスを割り当てることはできないことが分かった。次に，HTTPS を用いた VPN サービスである K 社セキュリティサービス（以下，K サービスという）を調査した。K サービスの利用方法は図6のとおりである。
図6 K サービスの利用方法
次に，T 主任と F さんは，リモートワーク用の新規社有 PC 導入時の追加の初期設定手順及び P 社におけるリモートワークでの K サービスの利用方針を検討し，検討結果をそれぞれ図7，図8にまとめた。
図7 リモートワーク用の新規社有 PC 導入時の追加の初期設定手順（抜粋）図8 P 社におけるリモートワークでの K サービスの利用方針
T 主任と F さんは検討を進め，K サービスを用いれば，リモートワーク用の社有 PC が P 社内の LAN に接続されている場合でも HTTPS 通信の URL フィルタリングサービスが適用できると考えた。そのため，リモートワーク時に限らず，P 社出勤時も経理係の IB の利用及び情報システム係の情報システムの管理を除き，社有 PC での K サービスの利用を必須にする方針とした。
F さんと T 主任は，まとめた内容を H 部長に報告し，了承を得た。
〔段階的な利用計画〕
T 主任と F さんは，R サービス及び K サービスを，T 主任と F さんが情報システムの管理以外の業務に利用する先行利用と，全従業員で利用する全体利用の 2 段階で行うことにした。
F さんは，図8以外に必要となる変更について，次の案を T 主任に報告した。
(1) W 社に設定変更を依頼する。
(2) M-FW のファイアウォール機能では社内からの HTTP 通信を禁止とし，HTTPS 通信の宛先は K サービスだけを許可する。
(3) 各取引先サービスについて，次の依頼を取引先に行う。依頼：f。
T 主任は，(2)について，問題を指摘し，許可する宛先の追加を指示した。F さんは，②追加する宛先を T 主任に報告し，了承を得た。
T 主任は，これまでの検討結果を H 部長に報告し，先行利用実施の許可を得た。
〔先行利用の実施と OS 移行の施策〕
先行利用では，利用中に社有スマホが故障し，認証ができないという問題が発生した。そこで，H 部長とも相談し，社有スマホの故障時でも K サービスが利用できるように，MFA 設定画面で次の二つを行った。
管理者のアカウントで，認証方式を表2の認証方式 3 に変更する。
先行利用の利用者アカウントについては，g。
T 主任と F さんは，1 か月間，K サービスを社内から利用し，基本サイトの利用などに問題がないことを確認した。
次に，T 主任と F さんは，社有 PC を R サービスに接続し，K サービスを利用することにした。1 か月間利用し，同様に問題がないことを確認した。
T 主任と F さんは，現状，社有 PC の OS の移行が滞っていることから，③情報システム係が K サービスを活用して移行を促進させる施策を考えた。
T 主任は，先行利用の振返り及び OS 移行の施策を H 部長に報告した。H 部長は，K サービスがリモートワーク及び情報セキュリティの強化に有効であると判断し，リモートワークの導入を進めていくことにした。
DNS の応答にデジタル署名を付けて，応答が正しい権威 DNS サーバのもので途中で改ざんされていないことを，問い合わせた側が検証できるようにする仕組みは DNSSEC（DNS Security Extensions。RFC 4033〜4035）である。権威 DNS サーバはゾーンのレコードに署名（RRSIG レコード）を付け，リゾルバは公開鍵（DNSKEY）と親ゾーンからの信頼の連鎖でそれを検証する。DNS キャッシュポイズニングへの対策になる。
8. 契約企業向けに用意された設定画面（以下，K サービス設定サイトという）へのアクセスを許可する接続元 IP アドレスを設定することができる。
図8
8. 図6の項番 8 については，①K サービス設定サイトへのアクセスは P 社内だけからできるよう制限する
表3
M-FW のインターネット側インタフェース：a1.b1.c1.d1。
図6の項番8で設定できるのは，K サービス設定サイトへのアクセスを許す接続元 IP アドレスである。P 社内の LAN からインターネットへ出る通信は M-FW を通り，送信元は M-FW のインターネット側インタフェースのグローバル IP アドレスになる。表3によれば，それは a1.b1.c1.d1 である。
したがって，K サービス設定サイトへのアクセスを許可する接続元 IP アドレスを a1.b1.c1.d1 だけに制限すれば，P 社内からだけアクセスできるようになる。図7の項番4で，K ソフトのダウンロードとインストールを P 社内から行うとしているのもこの設定と合っている。解答例は“K サービス設定サイトへのアクセスが許可される接続元 IP アドレスを a1.b1.c1.d1 に制限する。”である。
書き方の注意。“設定内容を具体的に”なので，“P 社の IP アドレスに制限する”ではなく，表3から a1.b1.c1.d1 を拾って書く。K サービス経由の通信の送信元になる K サービス用固定グローバル IP アドレスを指定すると，自宅から K サービス経由でもアクセスできてしまい，“P 社内だけ”にならない。
取引先サービスは複数あり，各取引先サービスで接続元 IP アドレス制限を行っている。各取引先サービスでは，M-FW のグローバル IP アドレスからの接続は許可されている。
図6
4. K サービス経由でのインターネットアクセス時の送信元 IP アドレスとして，契約者専用の K サービス用固定グローバル IP アドレスを指定することができる。
図8
5. 図6の項番 4 を利用する。
K サービスを使うと，社有 PC からインターネットへの通信は K サービスを経由し，送信元 IP アドレスは K サービス用固定グローバル IP アドレスになる（図6の項番4，図8の項番5）。社内からでも自宅（R サービスは固定 IP を割り当てられない）からでも同じ IP アドレスになる。
一方，各取引先サービスは接続元 IP アドレスで制限していて，今は M-FW のグローバル IP アドレスだけを許可している。このままでは K サービス経由の通信は拒否されるので，各取引先に，P 社専用の K サービス用固定グローバル IP アドレスを接続許可の IP アドレスとして登録してもらう必要がある。
書き方の注意。図8の項番7の除外リストは HTTPS の終端をしない指定であって，通信は K サービスを経由したままなので，送信元 IP アドレスの問題は解決しない。“どの IP アドレスを”“何として登録してもらうか”を書く。
(2) M-FW のファイアウォール機能では社内からの HTTP 通信を禁止とし，HTTPS 通信の宛先は K サービスだけを許可する。
〔リモートワークの検討〕
そのため，リモートワーク時に限らず，P 社出勤時も経理係の IB の利用及び情報システム係の情報システムの管理を除き，社有 PC での K サービスの利用を必須にする方針とした。
図7
3. 項番 1 でアカウントが作成された場合，利用者は社有スマホに認証アプリをインストールする。利用者は自身のアカウントを使い，P 社内から社有 PC を使って MFA 設定画面にログインし，社有スマホの認証アプリを登録する。4. 利用者は P 社内から社有 PC を使って K サービス設定サイトにアクセスし，K ソフトのダウンロード及びインストールを行う。
図8
4. 図6の項番 3 については，表1の項番 1(2)を満たしていない PC からの接続を拒否するように設定する。
社内から HTTPS で K サービスにしか出られないと，K サービスを使わない通信や，K サービスにつなぐ前に必要な通信が止まってしまう。一つ目は，K サービスの利用対象から外した経理係の IB，つまり Z-IB である。二つ目は，K サービスに接続する前の初期設定で使う通信で，MFA 設定画面での認証アプリの登録（図7の項番3）と，K サービスへの接続時の SAML 認証に使う認証基盤サービス，K ソフトを入手する K サービス設定サイト（図7の項番4）である。
三つ目は OS ベンダーの OS アップデート配布サイトである。図8の項番4により，脆弱性修正プログラムを期限内に適用していない PC は K サービスへの接続を拒否される。その PC が修正プログラムを入手するには，K サービスを経由せずに OS アップデート配布サイトへ直接接続できなければならない。解答例は“Z-IB，OS ベンダーの OS アップデート配布サイト，認証基盤サービス及び K サービス設定サイトへの HTTPS サービス”である。
講評のとおり，初期設定時と VPN 接続前に必要な通信を踏まえることがポイントである。K サービスに接続できれば K サービス経由で届く宛先（Q 社のマルウェア定義ファイル配布サイトや W サービスなど）は，追加しなくてよい。
K サービス接続時に，接続元 PC の OS のバージョン，OS の脆弱性修正プログラム適用状況，マルウェア定義ファイルのバージョン（以下，三つを併せて PC 情報という）をチェックし，接続の可否を判定できる。アカウント名，PC のシリアル番号，PC 情報及び接続可否はログに記録される。
図6
7. 契約企業の管理者アカウントでログの検索及び参照ができる。
〔社有 PC の OS の現状〕
移行は，各部の情報セキュリティ推進者の管理の下，6 か月以内に完了させることになっている。
K サービスのログには，接続した PC の OS のバージョンを含む PC 情報と，アカウント名，PC のシリアル番号が残る。K サービスの管理者である T 主任と F さんは，管理者アカウントでログを検索できる。社有 PC での K サービスの利用は必須なので，ログからまだ OS がバージョン X の社有 PC を漏れなく洗い出せ，アカウント名から使っている利用者も特定できる。
OS の移行は各部の情報セキュリティ推進者の管理の下で進めることになっているので，特定した利用者を，その利用者が所属する部の情報セキュリティ推進者に報告し，バージョン Y への移行を促してもらう。解答例は“K サービス接続時のログから OS がバージョン X の社有 PC を抽出し，アカウント名から利用者を特定後，利用者の所属する部の情報セキュリティ推進者に報告し，バージョン Y への移行を促してもらう。”である。
書き方の注意。“具体的に”なので，何から（K サービスのログ）何を抽出し，どうやって利用者を特定し，誰を通じて促すかの流れを書く。図6の項番3の条件でバージョン X の PC の接続を拒否する案は，まだサポート中のバージョン X を規程（表1の項番1(2)）が認めているので，業務を止めてしまい適切でない。
今年度，L 社は，J 社から，経済産業省及び IPA が策定した“サイバーセキュリティ経営ガイドライン Ver 3.0”（以下，経営ガイドラインという）に基づき，対策を整備することを求められた。
要求を受けた L 社は，サイバーセキュリティの専門企業である N 社のコンサルティングを受けることを決め，コンサルタントで情報処理安全確保支援士（登録セキスペ）である C 氏が担当になった。L 社では最高情報セキュリティ責任者（CISO）である E 取締役を中心にして，整備を開始した。
〔L 社の状況〕
L 社の組織図を図1に，L 社と J 社の関係など，L 社の状況を図2に示す。
図1 L 社の組織図図2 L 社の状況
C 氏は，E 取締役に対して L 社内のネットワークの説明を求めたが，L 社にはネットワーク図がなかった。L 社では，急ぎ，ネットワークの調査を行い，図3に示す L 社のネットワーク図並びに表1に示す L 社で使用している SaaS 及び機器の説明をまとめた。
図3 L 社のネットワーク図表1 L 社で使用している SaaS 及び機器の説明（抜粋）表2 電子メール SaaS のマルウェア対策機能
C 氏が E 取締役に対して部品の製造の流れの説明を求めたところ，E 取締役は，試作時の製造の流れとして図4を，量産時の製造の流れとして図5を示した。
図4 試作時の製造の流れ図5 量産時の製造の流れ
C 氏は，E 取締役に対してファイルサーバの権限の設定状況について説明を求めた。表3は，その時に提示された設計情報ファイルの保存領域での権限の設定状況である。
表3 設計情報ファイルの保存領域での権限の設定状況
〔経営ガイドライン〕
図6は，経営ガイドラインに示された“サイバーセキュリティ経営の重要 10 項目”である。C 氏は，この指示 1〜10 に沿って L 社に対策の助言を始めた。
図6 サイバーセキュリティ経営の重要 10 項目
〔指示 4 に関する助言〕
経営ガイドラインにおける指示 4 の説明は，図7のとおりである。
図7 経営ガイドラインにおける指示 4 の説明
C 氏は，経営ガイドラインの指示 4 では，サイバー攻撃に関してリスクアセスメントを行い，対応計画を策定することを求めていると説明した。C 氏は，リスクの識別と対応計画の策定を図8の手順で進めるように助言した。
図8 リスクの識別と対応計画の策定の手順（概要）
次は，その時の C 氏と E 取締役の会話である。
C 氏：例えば，J 社から受け取った設計情報ファイルに影響を与えるリスクについて，図8の項番 3 と 4 は実行できそうでしょうか。
E 取締役：はい。例えば，LAN に接続された PC がマルウェアに感染して情報の漏えいが起きるリスクがありますが，マルウェア対策ソフトを導入していますので，追加の対策は不要だと考えています。
C 氏：マルウェアによっては，パターンマッチング型のマルウェア対策ソフトでは検知できないおそれがあります。そう考えると，追加の対策は必要でしょう。リスクのレベル分けについては，別の機会に説明します。
E 取締役：分かりました。
C 氏：項番 4 について例を挙げると，設計情報ファイルを扱う業務が図4だけなら，①最小権限の原則に沿って表3の権限の設定を見直すことによって，PC がマルウェアに感染したときの設計情報ファイルに影響を与えるリスクを低減することができます。
E 取締役：分かりました。
〔指示 5 に関する助言〕
経営ガイドラインにおける指示 5 の説明は，図9のとおりである。
図9 経営ガイドラインにおける指示 5 の説明
C 氏は，経営ガイドラインの指示 5 では，指示 4 で識別したリスクに対応するための保護対策として，効果的な仕組みの導入と見直しを求めていると説明した。C 氏は，リスクに対応するための具体的な保護対策を考えるため，図8で洗い出したリスクが顕在化する具体的な攻撃シナリオと，そのシナリオから情報やシステムを保護する対策を並べた表を作るよう助言した。C 氏の助言を受けながら L 社が作成した表が表4である。
表4 攻撃シナリオと対策
〔指示 8 に関する助言〕
経営ガイドラインにおける指示 8 の説明は図10のとおりである。
図10 経営ガイドラインにおける指示 8 の説明（抜粋）
C 氏は，経営ガイドラインの指示 8 では，業務停止に至るインシデントを想定して，復旧計画及びその体制を整えることを求めていると説明した。次は，その時の C 氏と E 取締役の会話である。
C 氏：何らかの理由で工作機械が停止してしまった場合の復旧対応体制は整備していますか。
E 取締役：今まで 2 時間を超える停止は起こっていなかったので，整備していません。
C 氏：最大許容停止時間 2 時間以内を実現するには，まず製造が停止する被害に至るシナリオ（以下，被害のシナリオという）を想定します。次に，被害のシナリオが実際に起こった場合に 2 時間以内で製造を再開するために必要となるソフトウェアやハードウェアなど（以下，必要な仕組みという）及び必要な手順をまとめます。例として，表5に SCADA の偶発的な故障を発端とした被害のシナリオ，必要な仕組み及び必要な手順を挙げました。
表5 被害のシナリオ，必要な仕組み及び必要な手順の例
E 取締役：分かりました。まとめてみます。
C 氏：必要な仕組み及び必要な手順が整備できた後に，演習を行う必要もあります。
この後，L 社では C 氏の助言を受けながら，外部からのサイバー攻撃を発端とした被害のシナリオ，必要な仕組み及び必要な手順について表6にまとめた。
表6 外部からのサイバー攻撃を発端とした被害のシナリオ，必要な仕組み及び必要な手順
C 氏は，その他の指示についても対策を助言し，L 社は助言に従って対策を実施した。その後，L 社は，対策の整備状況を報告書にまとめて J 社に報告した。
(2) 製造課員は，SCADA 操作用 PC に，(1)の USB メモリを接続して，試作用 NC プログラムを SCADA 内の試作用 NC プログラム領域に保存する。
f（項番3）は，一般 PC から SCADA へネットワーク経由で感染が広がるのを止める対策である。図3では，SCADA と工作機械は L3SW から(け)を通る線にだけつながり，一般 PC・CAD PC・NC PC はそれぞれ別の線でつながっている。(け)に FW を追加して SCADA と工作機械の区画を他から分け，必要な通信だけを通すようにすれば，一般 PC からの感染の拡大を一か所で止められる。NC プログラムは USB メモリで SCADA 操作用 PC から入れているので（図4），業務への影響も小さい。解答例は“図3中の(け)の箇所に，追加で FW”である。
g（項番4）は，購入した USB メモリそのものが感染している場合の対策である。SCADA 操作用 PC に入れるマルウェア対策ソフトはすでに挙がっているので，それより前の段階で，USB メモリを接続したときの動きを確認するソフトウェアを入れた検査用 PC を用意し，社内 LAN から切り離しておく。新しい USB メモリは必ずこの PC で検査してから使う。解答例は“USB メモリを接続したときの動きを確認するためのソフトウェアを導入した，社内 LAN から切り離された検査用 PC”である。
講評のとおり，SCADA の利用者認証を強化する答えが多かったが，マルウェアは脆弱性の悪用や正規の利用者をだますことで動くので，認証の強化は効果が薄い。設問は“導入箇所を含めて”求めているので，f は(あ)〜(す)の記号を，g は検査用 PC を社内 LAN から切り離すことを書く。
j は，外部からのサイバー攻撃を発端に，表6の既出の行とは違う形で製造が止まるシナリオである。図3では，SCADA と工作機械は L3SW を通じて社内の全ての PC と同じネットワークにつながっている。メールなどで一般 PC がマルウェアに感染し，正常な通信を妨害するパケットを大量に送れば，SCADA や工作機械が感染していなくても，SCADA と工作機械の間の通信ができなくなり工作が止まる。一般 PC は数が多く，電子メールでマルウェアに触れやすいので，起こる可能性が高い。
このとき 2 時間以内に製造を再開するには，SCADA・工作機械と，稼働状況を受け取る製造監視用 PC だけで動く独立した LAN を構成するネットワーク機器（k）を用意しておき，それらを L 社のネットワークから切り離す手順（l）を決めておく。妨害の元を探して止めるより，製造に必要な機器だけを切り離して動かす方が早い。
![機能名，機能概要，備考の3列の表。ログイン：機能概要（省略），備考（省略）。利用者管理：管理者が，利用者の登録，変更及び削除を行う。備考：登録された利用者には，利用企業内で一意となる利用者 ID が発行される。利用者 ID の形式は次のとおりである。“U”と数字 8 桁をつなげた文字列。ロール管理：管理者が，利用者のロールを設定する。備考：処理の流れは次のとおりである。1. ログイン後の画面からロール管理機能を選択すると，パス“/management/role”にリクエストが GET メソッドで送信される。csrf_token という一時的でランダムな文字列のトークンが発行され，ロール設定画面が表示される。2. ロール設定画面で任意の利用者のロールを変更し，確定ボタンをクリックすると，パス“/management/roleset”に対して，パラメータ csrf_token，is_admin 及び user_id を含むリクエストが POST メソッドで送信される。パラメータ is_admin は指定した利用者のロールに応じて次のいずれかが設定される。- 管理者：is_admin=1，- 一般利用者：is_admin=0。プロジェクト管理：管理者が，プロジェクトの登録及び変更を行う。また，プロジェクトに一般利用者を割り当てる。備考：プロジェクトには，利用企業内で一意となるプロジェクト ID が発行される。プロジェクト ID の形式は次のとおりである。“P”と数字 8 桁をつなげた文字列。タスク管理：利用者が，プロジェクトのタスク管理画面からタスクを登録し，タスクの担当者を割り当てる。また，タスクの更新を行う。備考：タスクには，次の項目を設定する。・タスク名，・タスクの詳細説明，・タスクの担当者，・タスクの締切日，・タスクの進捗状況，・タスクの完了フラグ。スレッド作成：利用者が，スレッドを作成する。備考：スレッドの作成時は，アクセスできる一般利用者を指定する。管理者は利用企業内の全てのスレッドにアクセスできる。スレッド投稿：利用者が，アクセスできるスレッドに文章の投稿とファイルのアップロードを行う。アップロードされたファイルは，ファイル識別子が一意になるように変更されてからサーバに保存される。備考：アップロードできるファイルの拡張子は，docx，xlsx，pptx，pdf，jpg，gif 及び png の 7 種類である。アップロードされたファイルは，スレッドにアクセスできる利用者だけがアクセスできる。ファイルの参照時及びダウンロード時のパスは次のとおりである。/files/[一意のファイル識別子].[拡張子]。プロジェクト進捗管理：利用者が，プロジェクトの進捗を管理する。スケジュールの作成及び管理並びにタスクの進捗確認を行う。備考：未完了のタスクのうち締切日を過ぎたものは，プロジェクト進捗管理画面にそのタスク名と締切日からの経過日数が表示される。](/data/figures/2025r07a-sc-pm/q1-t1.png)
![枠で囲んだスクリプト（全16行。原本に行番号は無い）。1行目 (async function() {。2行目 const response = await fetch("/management/role");。3行目 const text = await response.text();。4行目 // 次の 2 行で csrf_token を取得。5行目 const tokenMatch = text.match(/id="csrf_token"[^>]*value="([^"]+)"/);。6行目 const csrfToken = tokenMatch[1];。7行目 await fetch("/management/roleset", {。8行目 method: "POST",。9行目 // POST メソッドのリクエスト body。10行目 body: new URLSearchParams({。11行目 "csrf_token": csrfToken,。12行目 "is_admin": "1",。13行目 "user_id": "U00331001"。14行目 })。15行目 });。16行目 })();。注記 整形とコメントの追記は，U さんによるものである。](/data/figures/2025r07a-sc-pm/q1-f3.png)
