【令和7年秋期 午後】情報処理安全確保支援士 問題別・学ぶべき知識(Web権限・暗号鍵・リモート接続・OTセキュリティ)
令和7年秋期 午後で問われたWeb権限・暗号鍵・リモート接続・OTセキュリティの知識を、攻撃・影響・対策の流れと、全設問で必要になる補足知識に分けて整理します。
午後 問1 Webアプリケーションの脆弱性対策
攻撃・原因 → 影響(成立の流れ)
起点:締切後も残るタスク操作とロール変更を順番に組み合わせる
攻撃の進行:一般利用者が管理者ロールを取得
結果・補足:同一オリジンへアップロードしたスクリプトを格納型XSSから読込み、権限操作を実行する
対策・確認
アップロード時に拡張子だけでなく実体形式・MIME・保存先を検証し、ユーザー値はHTML出力時にエスケープする。
業務仕様を知る専門家が締切、ロール、タスク名を跨ぐ手動シナリオで認可を検査する
設問別の補足知識(全4設問)
設問1:
空欄a:図1のCSPは default-src 'self' であり,個別の取得元を指定していないリソースはSサービスと同じオリジンからだけ読み込めます。したがって,外部ドメイン上のスクリプトはブラウザに拒否されます。
空欄b:同じ設定には 'unsafe-inline',nonce,hashのいずれもありません。そのため,script要素内に直接記述したJavaScriptも実行されません。
設問2:
(1):図3は /management/role からcsrf_tokenを取得し,/management/rolesetへis_adminとuser_idを送っています。この二つのパスとパラメータは表1のロール管理の処理と一致します。
(2)・(3):図2の期限切れタスク一覧では,li要素の先頭にタスク名が出力されています。そこにscript要素を含む文字列がそのまま入っているので,空欄cは表示対象の項目,空欄dはli要素から抜き出した当該文字列になります。
(4):期限切れになったタスク名を管理者が画面で表示すると,同一オリジン上のファイルがスクリプトとして読み込まれます。そのスクリプトが元従業員Zの利用者IDについてis_admin=1を送るため,ロールが管理者へ変更されます。
(5):外部スクリプトとインラインスクリプトはCSPに阻止されます。一方,スレッドへアップロードしたファイルはSサービス内の /files/ 配下に置かれるので,同一オリジンを許可する'self'の条件を満たします。
攻撃者はこの仕様を利用して図3のコードを読み込ませています。
設問3:
(1):現状は許可された拡張子かどうかしか確認していないので,JavaScriptを記述したファイルでも.xlsxという名前なら通過します。拡張子だけでなく,ファイルヘッダーや内部構造を調べ,実際の形式との一致を検証する必要があります。
(2)・(3):スクリプトが実行されたのは,登録済みのタスク名を期限切れタスク一覧へ出力するプロジェクト進捗管理です。
入力時の禁止だけに頼らず,HTMLへ出力する時点で特殊文字をエスケープすれば,script要素として解釈されることを防げます。
設問4:
診断ツールXは一つのリクエストとレスポンスから脆弱性を探し,SASTはソースコードを解析します。
今回の攻撃は,ファイルの保存場所,CSP,期限切れ表示,管理者の操作という複数機能の組合せで成立するため,個々の自動検査だけでは再現しにくいものです。業務仕様と機能間の流れを理解した専門家が,成立条件を組み立てて検査する必要があります。
午後 問2 暗号資産交換業における暗号鍵の管理
攻撃・原因 → 影響(成立の流れ)
起点:施設外から鍵管理PCの作動音・電磁波を観測
攻撃の進行:署名鍵を推定するサイドチャネル攻撃
結果・補足:遮音・電磁遮蔽した区画と、秘密鍵を外へ出さず署名するHSMで観測と持出しを抑える
対策・確認
移転情報にはMACを付け、作成・署名・搬送を複数担当者が相互確認する。
暗号化した署名鍵と復号パスワードを同送せず別経路・別管理者に分離し、復旧用鍵と手順を定期検証する
設問別の補足知識(全4設問)
設問1:
ECDSAとEdDSAは,いずれも楕円曲線上の演算を利用するデジタル署名方式です。AESは共通鍵暗号,ECDHは鍵共有,SHA-256はハッシュ関数です。
RSAは署名にも使えますが,安全性の根拠は素因数分解問題であり楕円曲線暗号ではありません。
設問2:
下線①は,鍵管理PCの暗号処理に伴って装置の外へ漏れる情報を利用する攻撃への対策を指しています。施設Kの外から観測できる作動音や電磁波を分析すれば,処理内容と相関する特徴から署名鍵Sを推測される可能性があります。
入退室やネットワーク遮断だけでは防げない物理的な漏えい経路に着目するのがポイントです。
設問3:
(1):手順2(i)後は,マルウェアXが業務用メディアへ不正な移転情報を追加できます。手順2(iv)では内容を確認せず全ファイルに署名するので,不正な情報にも署名が付きます。
施設Kから戻った後に署名済み不正ファイルを攻撃者へ送り,メディアから削除すれば,基幹サーバの照合対象に残らず警告も発生しません。
(2):メッセージダイジェストだけでは,ファイルを書き換えられるマルウェアが照合ファイル側も再計算できます。基幹サーバと署名アプリだけが知る共通鍵を計算に使えば,その鍵を持たないマルウェアは正しい認証値を作れません。
(3):想定事例(b)は担当者自身による不正なので,研修だけでは機会をなくせません。複数人が同じ作業に立ち会い,相互に確認する運用にすれば,一人だけで署名鍵を持ち出すことが難しくなります。
設問4:
(1):図6では,暗号化された署名鍵Sを入れたメディアと,復号に使うパスワードを書いた紙を同時に運びます。両方を一度に奪われると暗号化の効果がなくなるため,最も高いリスクです。
(2):図7では,HSM内でRSAの暗号鍵Eと復号鍵Dを生成します。施設Kでは署名鍵Sを暗号鍵Eで暗号化し,M社では外部へ出ない復号鍵Dで復号してHSMへ登録する,という対応関係を追うと各空欄を決められます。
(3):移送用メディアにあるのは暗号化されたデータだけで,復号鍵DはHSM内に残ります。メディアだけを盗んでも復号に必要な秘密鍵を得られないことが根拠です。
(4):作業1の暗号鍵Eを攻撃者自身の公開鍵へすり替えると,施設Kでは署名鍵Sを攻撃者の鍵で暗号化してしまいます。攻撃者は対応する秘密鍵を持つため,作業5で読み取った暗号文から署名鍵Sを復元できます。
午後 問3 リモートワーク環境のセキュリティ対策
攻撃・原因 → 影響(成立の流れ)
起点:偽DNS応答でリモート接続先を攻撃者サイトへ誘導
結果・補足:認証情報や通信を窃取する。DNSSECで応答署名、DoHでDNS経路、TLSで接続先と内容を保護し、設定サイトは社内固定IPだけに制限する
対策・確認
SASEの固定グローバルIPを取引先の許可リストへ登録し、端末からは業務サービス・OS更新・IdP・管理サイトのHTTPSだけを許可する。
MFAに個人電話番号を登録させず、接続ログから旧OS端末と利用者を特定して更新を督促する
設問別の補足知識(全5設問)
設問1:
(1):表2の「DNS応答にデジタル署名を付与する」はDNSSECの機能です。受信側は署名を検証することで,応答の偽装や改ざんを検知できます。
(2):HTTPSを使ってDNSを送る方式がDoHです。DoTは名称どおりDNS over TLSなので,暗号化に用いるプロトコルはTLSです。いずれも指定された英字数に収まります。
設問2:
空欄d:操作担当者は偽画面を正規画面だと思っているため,最初は本来の振込先口座番号を数字入力トークンへ入力します。これは攻撃者が書き換える前の値です。
空欄e:偽サーバは,攻撃者口座への取引に有効な認証番号を得るため,図5の偽ポップアップで別の数字を入力させます。図5の注記から,その数字は図4の(16)で届いたもの,すなわち書換え後の攻撃者口座番号だと分かります。
設問3:
図6の項番8では,Kサービス設定サイトへ接続できる送信元IPアドレスを指定できます。表3によると,P社内から外部へ出るときの送信元はM-FWのa1.b1.c1.d1です。
この値だけを許可すれば,「P社内だけ」という下線①の要件を具体的な設定にできます。
設問4:
(1):取引先サービスはM-FWのグローバルIPアドレスだけを許可しています。Kサービス経由では送信元がP社専用の固定グローバルIPアドレスに変わるので,各取引先の許可リストにもそのアドレスを追加してもらう必要があります。
(2):社内でKサービスを必須にしても,Kサービスを使う前の初期設定や,対象外とした業務には直接HTTPS通信が必要です。
本文の手順をたどると,IB,OS更新,認証基盤のMFA設定,Kソフト取得・設定の四用途が残るため,それぞれの宛先をM-FWの許可先へ追加します。
設問5:
(1):認証方式3では,利用時にSMSの認証方式1と認証アプリの認証方式2を選べます。社有スマホの故障時は個人所有スマホの利用が規程で認められているので,SMSの送信先としてその電話番号をあらかじめ登録しておけば代替できます。
(2):Kサービスのログには,接続したPCのOSバージョンとアカウント名が残り,管理者が検索できます。
そこで旧バージョンXのPCを抽出し,アカウントから利用者と所属部を特定して,各部の情報セキュリティ推進者へ働き掛ければ,既存の移行管理体制を使ってバージョンYへの移行を促進できます。
午後 問4 製造業におけるセキュリティ管理
攻撃・原因 → 影響(成立の流れ)
起点:感染した一般PCが大量パケットを送信
攻撃の進行:SCADAと工作機械の制御通信を妨害
結果・補足:生産を停止させる。SCADA・工作機械・監視PCだけの独立LANへ切替えられる機器と手順を事前に準備する
対策・確認
持込みUSBは社内LANから切り離した検査用PCで実動作まで確認し、SCADAのNCプログラムを復元できる媒体・ソフト・リストア手順を検証する。
共有ファイル権限は部門ごとの読取・書込・変更職務まで限定する
設問別の補足知識(全4設問)
設問1:
空欄a:パターンマッチング型は,登録済みの特徴と一致する既知のマルウェアを検知します。実行時の振る舞いを見るサンドボックス型のメリットとの対比から,前者が苦手なのは特徴が未登録のものです。
空欄b:添付ファイルが暗号化されていると,どちらの方式も内容を開いて検査できません。表2で両方式に共通するデメリットを見れば,この状態を表す語を導けます。
設問2:
(1):図8は,リスクへの対応を低減を含む四つに分類しています。リスク源をなくす対応,保険や委託で他者へ分担する対応,残るリスクを受け入れる対応を,それぞれ図中の空欄へ対応させます。
(2):図4の業務では,営業部は保存と確認のため読込・書込が必要で,設計課,製造課,品質保証課は参照のため読込だけが必要です。総務課は業務上の利用がなく,情報システム課は権限管理だけを担当します。
この業務上の必要性に限定して表3の権限を残すのが最小権限です。
設問3:
空欄f:表4のシナリオでは,一般PCからSCADAへ感染が広がります。図3の(け)は製造課側を他の社内LANから分ける境界なので,ここに通信を制御するFWを追加すれば,個々のPCへ対策するより上流で横展開を止められます。
空欄g:購入直後のUSBメモリ自体が感染源なので,SCADA操作用PCへ接続してから検知するのでは遅れます。
社内LANから切り離した検査用PCで,接続時の振る舞いを確認してから製造環境へ持ち込む構成なら,業務への影響を抑えて事前に検査できます。
設問4:
(1):表6にあるOSやSCADAアプリの復旧媒体だけでは,工作機械を動かすNCプログラムまでは戻りません。製造再開に必要なデータもバックアップしておき,復旧したSCADAへ戻す手順まで用意する必要があります。
(2):一般PCと制御系がL社のネットワークを共有しているため,感染PCが大量の妨害パケットを送ると,SCADAと工作機械の正常な通信までできなくなる可能性があります。
制御に必要な機器だけで独立LANを作れるネットワーク機器と,障害時にそれらをL社ネットワークから切り離す手順を準備すれば,社内LANの障害中も製造を継続できます。
この記事に関連する教科書用語
この記事に関連する過去問演習
次におすすめの学習
編集・検証について
編集・検証:IT資格ラボ編集部
IPAが公開する試験要綱・シラバス・過去問題と、各技術の公式資料を優先して内容を確認しています。制度変更や誤りを確認した場合は、記事を見直して更新します。
編集方針・情報源・訂正方針を見る


