平成27年度 秋期 午後Ⅰ（旧試験）

本文の根拠

冒頭

E システムは Q 社の販売チャネルの大部分を担っており，保守のための時間帯を除き，常時稼働している。

冒頭

F システムは投資家などに対する財務情報・会社情報を提供している。

情報セキュリティの3要素は，機密性・完全性・可用性である。JIS Q 27000 は，可用性を“認可されたエンティティが要求したときに，アクセス及び使用が可能である特性”，完全性を“正確さ及び完全さの特性”と定めている。どれを重視すべきかは，そのシステムが Q 社のビジネスで何を担っているかで決まる。E システムは販売チャネルの大部分を担って常時稼働しているので，止まれば売上がそのまま失われる。したがって可用性を重視する。F システムは投資家などに財務情報・会社情報を提供しているので，内容が改ざんされたり誤っていたりすると投資家の判断を誤らせる。したがって完全性を重視する。

本文の“販売チャネルの大部分”“常時稼働”と“投資家”“財務情報・会社情報”がそれぞれの根拠である。F システムは静的な HTML コンテンツを公開しているだけで，公開情報なので機密性は問題になりにくい。講評は，3要素の意味を誤解している解答が散見されたとしている。“止まっては困る”が可用性，“正しくなければ困る”が完全性，“漏れては困る”が機密性と結び付けて覚えるとよい。

要素は5字以内で，解答例は“可用性”（3字）と“完全性”（3字）。理由は 25 字以内で，解答例は E システムが“販売チャネルの大部分を担い，常時稼働が必要なため”（24字），F システムが“投資家に正確な財務情報，会社情報を提供するため”（23字）。E は“常時稼働”，F は“正確な”という語を入れて，要素との結び付きを示す。

採点講評（IPA）

設問1は，情報セキュリティの3要素とその根拠となる理由を問う問題であったが，3要素の意味を誤解している解答が散見された。情報セキュリティの3要素は，基本的な知識であり，正確に理解してほしい。

本文の根拠

表2 項番1

WAS ログの出力先を公開ディレクトリ上に変更する。

表2 項番6

shell1.jsp を呼び出すことで，コマンド“XXXX”を WAS と同じ動作権限で実行する。

表2の攻撃は，WAS ログの設定を書き換えて，ログファイルを JSP ファイルとして実行させるものである。項番1で WAS ログの出力先を公開ディレクトリ上に変え，項番2～4でファイル名を shell1.jsp にし，項番5でコマンドを実行するコードをログに書き込ませる。したがって，WAS ログのファイルは公開ディレクトリに作成される。

公開ディレクトリに置かれるからこそ，項番6の“GET /shell1.jsp”で外部からこのファイルを呼び出せ，ログに記録されたコードが WAS と同じ動作権限で実行される。講評は，この設問の正答率は高かったとしている。

15 字以内で表2中の字句を用いる。解答例は“公開ディレクトリ”（8字）で，表2 項番1の説明の字句そのままである。“webapps/ROOT”のようなパスを書くより，設問の指示どおり表2の日本語の字句を使う。

採点講評（IPA）

設問2は，攻撃コードによるアクセスログのファイルをどこに作成するかを表中の字句を用いて解答する問題であり，正答率は高かった。

本文の根拠

T さんの発言

今回の脆弱性情報によると，GET メソッドに限らず POST メソッド，Multipart/form-data の POST メソッド，Cookie による攻撃の可能性もあります。

図2

ANY：任意のメソッドのパラメタ名を検証対象とする。COOKIE：Cookie の名前を検証対象とする。Multipart：Multipart/form-data のフィールド名を検証対象とする。

図3 注記

Multipart/form-data による HTTP リクエストは，[検証対象]に Multipart が指定されたときだけ[パターン]とのマッチングを行う。

図2

遮断：通信を遮断し，ログに記録する。

攻撃の経路は，GET・POST のパラメタ，Multipart/form-data の POST，Cookie の四つである。GET と POST はどちらも[検証対象]の ANY（任意のメソッドのパラメタ名）で一度に覆える。Multipart/form-data のリクエストは図3の注記により Multipart を指定したときだけマッチングされるので，ANY では検証されず，別に Multipart の行が要る。Cookie は COOKIE で検証する。よって b・d・f は ANY・COOKIE・Multipart（順不同）で，攻撃を止めるのが目的なので[動作]の c・e・g はどれも遮断である。

講評は，この設問の正答率は低く，問題文中の全ての攻撃パターンと WAF のルールを比較すれば解答できるのに，完全には防御できない組合せの解答が散見されたとしている。GET と POST を別々の行にすると3行では Cookie か Multipart のどちらかが漏れる。また“検知”は通信を通過させるので，攻撃を防ぐ設定にならない。

字数制限は無く，図2中の字句を用いる。解答例は b が“ANY”，d が“COOKIE”，f が“Multipart”（b，d，f は順不同），c・e・g が“遮断”。図2の表記どおり COOKIE は大文字，Multipart は先頭だけ大文字で書く。

採点講評（IPA）

設問3(1)は，WAFの設定を攻撃内容から判断して，解答する問題であったが，正答率は低かった。問題文中の全ての攻撃パターンとWAFのルールを比較することで解答できる問題であったが，完全には防御できない組合せの解答が散見された。

本文の根拠

T さんの発言（下線①）

①“^class¥..*”という[パターン]がセキュリティ専門家によって公表されましたが，これでは遮断されない攻撃が見つかりました。

図2

^：文字列の先頭にマッチする。

図2

¥.：“.”とマッチする。*：直前の要素と0回以上マッチする。

“^class¥..*”は，先頭（^）に“class”があり，その直後が“.”（¥.）で，その後に任意の文字（.）が0回以上（*）続く文字列にマッチする。つまり“class.”で始まる文字列である。イ“class.ClassLoader”とウ“class.classLoader”は“class.”で始まるのでマッチする。アは先頭が“anObject”なのでマッチせず，エは“class”の直後が“[”なのでマッチしない。

アとエがマッチしないことが“これでは遮断されない攻撃が見つかりました”の中身である。表3の正しいパターン“(^|¥W)[cC]lass¥W”は，先頭か非英数字の直後にある“class”又は“Class”で，その後が非英数字であるものにマッチする。アの“.class.”もエの“class[”も捕まえられる。

字数制限は無く，全て選ぶ。解答例は“イ，ウ”。“^”があるので“class”が文字列の先頭にあることが条件になる点と，“¥.”は任意の文字ではなく“.”そのものである点を読み落とさないこと。

本文の根拠

T さんの発言（h）

攻撃ではない HTTP リクエストを遮断してしまう h に注意する必要があります。例えば，表3のルールでは，“class.abc”を含む HTTP リクエストが遮断されてしまいます。

攻撃ではない正常な通信を攻撃と誤って判定することをフォールスポジティブ（偽陽性，誤検知）という（エ）。表3のパターンは“class”の前後が非英数字であればマッチするので，攻撃と関係の無い“class.abc”のようなパラメタ名を含む正常なリクエストまで遮断してしまう。

誤りの選択肢との違い。フォールスネガティブ（ウ）は逆に，攻撃を見逃して通してしまうことで，下線①のパターンで遮断されない攻撃が見つかったのがこれに当たる。フェールセーフ（ア）は故障時に安全側に倒す設計，フェールソフト（イ）は故障時に機能を縮小しても稼働を続ける設計で，どちらも誤判定の話ではない。

字数制限は無く，記号で答える。解答例は“エ”。“ポジティブ＝攻撃と判定した”“フォールス＝その判定が誤り”と分解すると，ウとエを取り違えにくい。設問5の“誤検知”も同じ意味である。

本文の根拠

表1

WAS：管理者権限，－。Web アプリ E（WF 使用）：－，WAS の動作権限と同一。

〔脆弱性の確認〕

攻撃者が“class.classLoader”という文字列を含む HTTP リクエストを送信することによって，任意のファイルへの書込みなど，WAS の動作権限で任意の攻撃コードを実行できる。

脆弱性 X を突かれると，攻撃コードは WAS の動作権限で実行される。表1によると WAS は管理者権限で動作しているので，攻撃が成功すれば E サーバ上で何でもできてしまう。WAS を業務に必要な最小限の権限で動作させれば，WAF をすり抜ける攻撃があっても，攻撃者ができることはその権限の範囲に限られる。これが下線②の“攻撃時のリスク軽減対策”である。

Web アプリ E と WF も WAS と同じ権限で動作する（表1 備考）ので，WAS の権限を下げればまとめて被害を小さくできる。最小権限の原則と呼ばれる考え方で，攻撃そのものを防ぐのではなく，侵入されたときの影響を抑える対策である。

25 字以内で，解答例は“WASを必要最小限の権限で動作させる。”（19字）。“管理者権限をやめる”だけでなく“必要最小限の権限で動作させる”と，見直し後の設定を書く。

本文の根拠

〔脆弱性への対策〕

一方，WAF による対策は，脆弱性 X を悪用した攻撃を防ぐ効果があり，動作検証を含めて2日間で実施可能と分かった。

〔脆弱性への対策〕（下線③）

開発検証用のシステムで③動作検証を実施し，問題ないことを確認後，本番環境のシステムで設定を行い，E システムを再稼働させた。

T さんの発言（h）

攻撃ではない HTTP リクエストを遮断してしまう h に注意する必要があります。

WAF にルールを追加したときに確かめるべきことは二つある。一つは，追加したルールで脆弱性 X を突く攻撃を実際に防げること（表2のような攻撃コードが遮断されること）。もう一つは，E システムを利用するための正常な通信が遮断されずに許可されること（設問3(3)のフォールスポジティブが起きないこと）である。

E システムは Q 社の販売チャネルの大部分を担うので，攻撃を防げても正常な注文まで止めてしまえば再稼働の意味が無い。講評は，正答率は高かったが，WAF ではなく修正モジュール適用に関する検証内容を解答した例も散見されたとしている。設問は“WAF に関して”検証すべきことを問うており，Web アプリ E の動作検証（10日間を要する方）を書くのは誤りである。

それぞれ 30 字以内で，解答例は①“脆弱性Xを突く攻撃を防げること”（15字），②“Eシステム利用のための正常な通信が許可されること”（24字）。“防げる”と“正常な通信を止めない”の両面を一つずつ書く。

採点講評（IPA）

設問4は，WAFに関する検証内容を問う問題であったが，正答率は高かった。ただし，WAFではなく修正モジュール適用に関する検証内容を解答した例も散見された。問題文をよく読んで解答してほしい。

本文の根拠

図2

検知：通信を通過させ，ログに記録する。

〔脆弱性への対策〕（下線④）

本来ならば，追加した WAF のルールで攻撃を遮断する前に，④本番環境のシステムに追加したルールの[動作]に“検知”を指定し，一定期間運用するのが望ましい。

冒頭

E システムは Q 社の販売チャネルの大部分を担っており，保守のための時間帯を除き，常時稼働している。

“検知”は通信を通過させたうえでログに記録する。これで本番環境を一定期間運用すれば，実際の利用者の通信のうちどれがルールにマッチしたかをログで確かめられる。正常な通信がマッチしていれば誤検知（フォールスポジティブ）であり，ルールを直してから“遮断”に切り替えればよい。その間も通信は止まらないので，販売機会の損失などビジネスへの影響を与えずに誤検知を検証できる。

開発検証用のシステムでの動作検証（設問4）では，本番の多様な利用者の通信までは再現しきれない。E システムは販売チャネルの大部分を担っているので，いきなり遮断して正常な注文を止めると売上に直結する。この利点を捨ててでも急いで遮断したのが本文の“今回は緊急対応のため，そのような運用はしなかった”である。

45 字以内で，解答例は“販売機会損失など，ビジネスへの影響を与えずに誤検知の検証ができる。”（33字）。“誤検知の検証ができる”という利点に，“ビジネスへの影響を与えずに”という Q 社の事情を添える。

本文の根拠

保守作業の手順 1.

Y 社の管理者が作業依頼書を作成し，S 社へ送付する。

保守作業の手順 7.

作業完了の連絡を受けて，Y 社の管理者は，ケーブル A を FW3 から取り外すよう YDC 作業員に依頼し，作業報告書によって作業内容を確認する。

表2 作業計画の入力と特権 ID の使用申請

保守責任者が，作業者の個人 ID，作業者氏名，作業期間，作業対象サーバ及び作業内容を入力し，委託用特権 ID の使用を申請する。

表2の a は，委託用特権 ID と個人 ID の登録，使用申請の確認と使用許可，作業完了報告の確認と使用解除，作業内容のレポートの確認を行う者である。申請するのは S 社の保守責任者なので，それを確認して許可し，結果をチェックするのは委託元の Y 社の側でなければならない。現行の手順でも，作業を依頼し，作業報告書で作業内容を確認しているのは Y 社の管理者である。したがって a は Y 社の管理者である。

申請する者と許可・確認する者を分けるのは，特権 ID の管理の基本である。S 社の保守責任者や作業者が自分で許可や確認をすると，表1 項番3 のモニタリングの不備が解消しない。講評は，この設問の正答率は高かったとしている。

10 字以内で，解答例は“Y社の管理者”（6字）。“情報システム部”や“L 主任”のように対策を検討した者を書くのではなく，本文の保守手順に出てくる役割名を使う。

採点講評（IPA）

設問1は，特権IDの管理者について問う問題であったが，正答率は高かった。

本文の根拠

冒頭

各業務アプリは，DBMS 操作 ID を用いて，DB サーバから顧客情報を取得して Y 社の従業員にサービスを提供している。

冒頭

DBMS 上のデータに対する操作権限をもつ ID（以下，それぞれ，システム管理 ID，DBMS 管理 ID，DBMS 操作 ID という）

指摘2（下線①）

①使用される委託用特権 ID によっては，DB サーバへアクセスした者を DB サーバ上のアクセスログから特定することができない。

委託用特権 ID のうち DBMS 操作 ID は，4台の業務サーバの業務アプリが DB サーバにアクセスするときにも使っている ID である。作業者が DBMS 操作 ID で DB サーバにアクセスしても，DB サーバ上のアクセスログには業務アプリのアクセスと同じ ID で記録されるので，そのアクセスが業務アプリによるものか作業者によるものかを区別できない。

システム管理 ID は作業対象サーバごとに異なり，DBMS 管理 ID も業務アプリは使わないので，製品 Q で個人 ID と結び付ければ使用者をたどれる。DBMS 操作 ID だけが業務アプリと共用になっている点が指摘2の中身である。講評は，この設問の正答率は低く，特権 ID の利用状況の違いによって，利用者の特定ができない場合があることを理解してほしいとしている。

委託用特権 ID は 10 字以内，理由は 35 字以内。解答例は“DBMS操作ID”（8字）と“業務アプリがDBサーバにアクセスするIDと同じIDであるから”（30字）。“共用されているから”だけでは表1 項番1 と同じになるので，“業務アプリと同じ ID”であることを書く。

採点講評（IPA）

設問2(1)は，特権IDの種類によるモニタリングの可否について問う問題であったが，正答率が低かった。特権IDの利用状況の違いによって，利用者の特定ができない場合があることを理解してほしい。

本文の根拠

案2

管理用サーバはサーバ LAN 上に設置する。作業者は，S 社 PC から個人 ID でプログラム K にログインした後に，プログラム K から作業対象サーバへ自動ログインによってアクセスし，操作する。

冒頭

Y システム保守用 LAN からサーバ LAN へのアクセスは，FW3 で保守作業に必要となるプロトコルだけに限定しているが，送信元 IP アドレスは限定していない。

要件3（b，c）

bからは cへのアクセスだけを許可するように FW3 の設定を変更することによって，アクセス先を作業対象サーバに限定できると説明し，L 主任の了解を得た。

案2では，作業者は S 社 PC から管理用サーバ上のプログラム K にログインし，作業対象サーバへはプログラム K が自動ログインでアクセスする。作業者の通信が FW3 を通るのは“S 社 PC から管理用サーバへ”の部分だけになる。そこで FW3 で S 社 PC（b）からは管理用サーバ（c）へのアクセスだけを許可すれば，作業者は作業対象サーバに直接アクセスできず，プログラム K を経由するしかなくなる。プログラム K は使用が許可された作業対象サーバにしか自動ログインしないので，アクセス先を作業対象サーバに限定できる。

これで表1 項番2 の“作業計画書に記載された作業対象サーバ以外のサーバにもアクセスできてしまう”が解消される。FW3 は今は送信元 IP アドレスを限定していないので，送信元も宛先も機器単位で絞ることになる。

字数制限は無く，機器名で答える。解答例は b が“S社PC”（4字），c が“管理用サーバ”（6字）。c に“作業対象サーバ”を書くと，作業者が直接アクセスできてプログラム K の操作履歴を経由しなくなるので誤りである。

本文の根拠

表2 操作履歴の取得

作業対象サーバでの操作履歴は管理用サーバに保存される。保存された操作履歴へのアクセスには管理用サーバのシステム管理権限が必要であり，Y 社内の限られた者だけがアクセスできる。

要件4についての指摘

作業者が作業対象サーバ上のアクセスログを書き換えると，作業計画の作業内容以外の操作，つまり不正操作が検知できなくなるのではないかと指摘した。

表2 作業内容の確認

プログラム K の機能によって，操作履歴と委託用特権 ID の使用申請で入力された作業内容を突き合わせ，その結果をレポートに出力する。

作業者が作業対象サーバ上のアクセスログを書き換えても，プログラム K は委託用特権 ID による操作履歴を管理用サーバにも保存している。管理用サーバの操作履歴へのアクセスにはそのシステム管理権限が要り，Y 社内の限られた者しかアクセスできないので，作業者は書き換えられない。プログラム K はこの操作履歴と使用申請の作業内容を突き合わせるので，不正操作の記録が管理用サーバの操作履歴に残り，検知できる。

入力コマンドのテキストは作業対象サーバにも保存されるが，そちらは作業者が書き換えうる。管理用サーバに入力コマンドのテキストと操作画面の動画が別に残ることが，L 主任の指摘への答えになる。

35 字以内で，解答例は“不正操作の記録が管理用サーバの操作履歴に残るから”（24字）。“作業者が書き換えられない場所に記録が残る”ことを，“管理用サーバの操作履歴”という本文の語で書く。

本文の根拠

指摘1

製品 Q の導入だけではこの要件を満たすのに不十分である。

要件2

委託用特権 ID を使用した者を特定可能にすること

〔追加対策の検討〕（下線③）

③S 社におけるプログラム K の個人 ID の管理状況を Y 社が確認する。

保守作業の手順 5.

作業者は，共用の ID を用いて S 社 PC にログインした後に，委託用特権 ID とパスワードを用いて，S 社 PC から作業対象サーバにアクセスし，作業する。

製品 Q は，委託用特権 ID の使用をプログラム K にログインした個人 ID と結び付けて記録する。しかし個人 ID のパスワードが他人に教えられていたり，共用されていたりすれば，記録上の個人 ID の持ち主が実際に操作した者とは限らない。要件2の“使用した者を特定可能にすること”を満たすには，個人 ID が本人以外に使われるおそれがないように S 社で管理されていることを，Y 社が確認する必要がある。これが指摘1の“製品 Q の導入だけでは不十分”の中身である。

S 社では現に S 社 PC へのログインに共用の ID を使っており，ID を共用する運用があることが本文から読み取れる。講評は，この設問の正答率は低く，特権 ID を管理するシステムを導入しても不適切な利用を放置すれば効果が期待できず，システムによる管理に加えて，人的，組織的な管理策が必要であることを理解してほしいとしている。

35 字以内で，解答例は“個人IDが本人以外に使われるおそれがないように管理していること”（31字）。“パスワードを適切に管理していること”のような一般論より，“本人以外に使われない”という要件2につながる点を書く。

採点講評（IPA）

設問3(1)は，特権IDの利用に関し，委託先に確認すべき事項を問う問題であったが，正答率が低かった。特権IDを管理するシステムを導入したとしても，不適切な利用を放置すればシステム導入の効果が期待できない。システムによる管理に加えて，人的，組織的な管理策が必要であることを理解してほしい。

本文の根拠

〔追加対策の検討〕（下線④）

④委託用特権 ID を使った者が特定されることをプログラム K のログイン画面に表示し，作業者に周知させる。

〔調査の実施と対策方針の策定〕

Y 社と同業の C 社で，C 社の保守作業委託先の従業員が個人情報を不正に持ち出して名簿業者に売却するという情報漏えい事件が起きた。

“あなたの操作は記録され，誰が使ったか特定される”と作業者に周知すると，不正を働こうとする者は発覚をおそれて思いとどまる。このように，不正をしにくい・割に合わないと思わせて実行を思いとどまらせる効果を抑止効果という。下線④はログイン画面に表示することで，毎回の作業の前に作業者に意識させている。

C 社の事件は委託先の従業員による内部不正であり，技術的に防ぐだけでなく，そもそも不正をさせない心理面の対策が有効である。下線④の表示は，設問2(3)の操作履歴や設問3(1)の個人 ID の管理によって実際に使用者を特定できることが前提で，それを作業者に知らせることで効果が生まれる。

“効果”を含めて5字以内で，解答例は“抑止効果”（4字）。“防止効果”“牽制効果”などでは，記録と周知によって不正を思いとどまらせるという意味が弱い。

本文の根拠

案1

製品 P は，管理用サーバにインストールするプログラム（以下，プログラム H という）と，PC にインストールするプログラム（以下，プログラム J という）で構成される。

案2

製品 Q は，管理用サーバにインストールするプログラム（以下，プログラム K という）だけで構成される。

冒頭

S 社 PC と FW1 は，S 社の資産である。

〔追加対策の検討〕（下線⑤）

⑤案1に比べて案2の方が必要な資産管理を実施しやすい

案1では，作業者が使う PC，つまり S 社 PC にプログラム J をインストールしなければならない。S 社 PC は S 社の資産なので，Y 社は委託先の PC に入れたプログラムのバージョンや設定を管理する必要が生じ，それは自社の資産のようには管理できない。案2のプログラム K は Y 社がサーバ LAN 上に置く管理用サーバにだけインストールするので，委託先の PC にプログラムを入れずに済み，資産管理は自社のサーバだけで完結する。

“Y 社の状況においては”とあるのは，作業者の PC が委託先 S 社の資産であることを指している。委託先の PC にインストールしたプログラムが改変されたり，古いまま放置されたりしても，Y 社からは把握しにくい。

40 字以内で，解答例は“委託先PCにインストールするプログラムの資産管理をせずに済むから”（32字）。“導入が容易だから”は本文で既に案2を選んだ理由として出ているので，設問の“資産管理”に絞って書く。

本文の根拠

表3 WebAP サーバ1のログイン履歴

2015/01/22 12:32:20，192.168.0.30，administrator，成功。

表2 Web サーバのログイン履歴

2015/01/22 12:42:07，192.168.0.20，administrator，成功。

B 氏の発言

運用では，“unyou”を使用しており，“administrator”は使用していません。

図1

WebAP サーバ1（192.168.0.20），WebAP サーバ2（192.168.0.30）

攻撃者は運用で使わない“administrator”でログインしている。表3では 12:32:20 に 192.168.0.30（図1より WebAP サーバ2）から WebAP サーバ1へ，表2では 12:42:07 に 192.168.0.20（WebAP サーバ1）から Web サーバへログインしている。したがって WebAP サーバ2（a）から WebAP サーバ1（b）へ，WebAP サーバ1（b）から Web サーバ（c）への順である。

表4の WebAP サーバ2には“administrator”のログインが無い。講評のとおり，WebAP サーバ2はサーブレットコンテナ（の管理画面）から侵入されたので，OS のログイン履歴には記録が残らない。“ログイン履歴に攻撃者の記録が無いサーバ”が出発点になっているので，最初に侵入されたのは WebAP サーバ2で，そのアクセスログを調べることになる。講評は，最初に侵入されたサーバを正しく答えられていない解答が見受けられたとしている。

字数制限は無く，図1中の字句で答える。解答例は a が“WebAPサーバ2”，b が“WebAPサーバ1”，c が“Webサーバ”。表3・表2の接続元 IP アドレスを図1のアドレスと突き合わせるのが要点で，日時だけで並べて“WebAP サーバ1が最初”とする誤りに注意する。

採点講評（IPA）

設問1は，サーバのOSのログイン履歴を基に侵入された順番を判断する問題であったが，最初に侵入されたサーバを正しく答えられていない解答が見受けられた。WebAPサーバ2は，サーブレットコンテナから侵入されているため，OSのログイン履歴には記録が残らないことを理解してほしい。

本文の根拠

表5 No.2

2，10:36:23，GET /demo/ HTTP/1.1，404，1,277。

表5 No.13，No.14

13，11:02:27，POST /manager/html/upload HTTP/1.1，200，21,453。14，11:02:34，GET /demo/index.jsp HTTP/1.1，200，2,588。

A 氏の発言

demo ディレクトリは攻撃者が No. fの直前で作成したことが分かります。

No.2 の“GET /demo/”のステータスコードは 404 で，この時点では demo ディレクトリが存在しなかった（d=2，e=404）。No.13 で管理画面からアップロード（POST /manager/html/upload）が行われ，直後の No.14 の“GET /demo/index.jsp”は 200 で成功している（f=14，g=200）。よって demo ディレクトリは No.14 の直前，つまり No.13 のアップロードで作成された。

404（Not Found）は要求された資源が見つからないこと，200（OK）は要求が成功したことを表す HTTP のステータスコードである（RFC 9110）。図2 のとおり管理画面では Web アプリケーションのアップロードと配置ができるので，攻撃者は攻撃ツール index.jsp を demo という名前で配置したと読める。

字数制限は無く，数値で答える。解答例は d が“2”，e が“404”，f が“14”，g が“200”。d に No.1（/test/）を書かないこと。調べているのは demo ディレクトリなので，同じ /demo/ を要求した No.2 を使う。

採点講評（IPA）

設問2は，WebAPサーバ2のアクセスログを読み解く問題であったが，ベーシック認証の仕組みを正しく理解できていない解答が見受けられた。ベーシック認証のアクセスログ解析においては，ステータスコードに着目してほしい。

本文の根拠

図2

管理画面へのログインは，ベーシック認証で行われる。成功時は 200，失敗時は 401 のステータスコードを返す。

表5 No.3～No.11

10，10:59:13，GET /manager/html HTTP/1.1，401，2,550。11，10:59:14，GET /manager/html HTTP/1.1，200，19,689。

〔侵入された原因の特定〕（下線①）

①サーブレットコンテナの管理画面に対して，よく使われる利用者 ID とパスワードでログインが試行され，その結果，ログインが成功したものと推測された。

図2によると管理画面のベーシック認証は成功時に 200，失敗時に 401 を返す。表5の No.3～No.10 は管理画面（/manager/html）へのリクエストがどれも 401 で，ログインの失敗が続いている。No.11 は同じ URL で 200 となり，ログインに成功している。10:59:12 から 10:59:14 までの約2秒で8回の失敗の後に成功しているので，人が手で入力したのではなく，よく使われる利用者 ID とパスワードの組を次々に試したと推測できる。

ベーシック認証では，Web ブラウザなどが利用者 ID とパスワードをリクエストに付けて送り，サーバは認証できなければ 401（Unauthorized）を返す（RFC 7617，RFC 9110）。講評は，ベーシック認証の仕組みを正しく理解できていない解答が見受けられ，ステータスコードに着目してほしいとしている。応答のバイト数も 2,550 から 19,689 に増えており，管理画面の本体が返されたことと合う。

60 字以内で，解答例は“No.3から10までのステータスコードが401で失敗を繰り返しており，No.11は200でログインに成功しているから”（58字）。“失敗の繰返し（401）”と“その後の成功（200）”の両方を，No. とステータスコードを示して書く。

採点講評（IPA）

設問2は，WebAPサーバ2のアクセスログを読み解く問題であったが，ベーシック認証の仕組みを正しく理解できていない解答が見受けられた。ベーシック認証のアクセスログ解析においては，ステータスコードに着目してほしい。

本文の根拠

表6 項番3，項番4

項番3：192.168.0.20，192.168.0.30，192.168.50.10，JDBC 接続，許可。項番4：192.168.0.20，192.168.0.30，192.168.50.20，ファイル共有，許可。

表6 注記

注記2 FW は，ステートフルインスペクション型のものである。注記3 全てのルールについて，ログを取得する設定となっている。

A 氏の発言

OS のファイル共有機能を使って他のサーバにファイルを転送する機能，OS のファイル共有機能を使って他のサーバ上で OS コマンドを実行する機能，及び DBMS に対して SQL を発行する機能をもっています。

侵入されたのは DMZ の3台である。表6で DMZ のサーバから内部 LAN（192.168.50.0/24）への通信を許可しているのは，WebAP サーバ1・2 から DB サーバへの JDBC 接続（項番3）と，ファイルサーバへのファイル共有（項番4）だけである。index.jsp はファイル共有で他のサーバにファイルを転送したりコマンドを実行したりし，DBMS に SQL を発行する機能をもつので，内部 LAN への影響はこの二つのルールで取得されるログで確認する。

項番7 は内部 LAN から Web サーバへの NTP で，送信元が内部 LAN 側なので DMZ から始まる通信には当たらない。FW はステートフルインスペクション型なので，項番3・4 で許可した通信の戻りもそのセッションの一部として扱われる。項番5・6 は管理 LAN からの通信である。

字数制限は無く，該当するものを全て答える。解答例は“3，4”。表6の“宛先”が内部 LAN のアドレスである行だけでなく，送信元が侵入されたサーバであるかまで確かめて選ぶ。

本文の根拠

表6 項番5

項番5：192.168.90.20，192.168.0.0/24，192.168.50.0/24，全て，許可。

図2

運用端末では，ファイル共有とリモートデスクトップのサービスを使用して各サーバを操作できる。

〔影響範囲の特定〕（下線②）

W 社のポリシでは，業務上必要なサービスだけを FW で許可することになっているが，②FW のフィルタリングルールにはポリシを満たしていないものがあることが判明した。

表6の項番5は，運用端末（192.168.90.20）から DMZ と内部 LAN への“全て”のサービスを許可している。図2によると運用端末が各サーバの操作に使うのはファイル共有とリモートデスクトップのサービスだけなので，業務上必要なサービスだけを許可するというポリシを満たしていない。項番5 のサービスをファイル共有とリモートデスクトップの二つに絞るべきである。

ほかのルールは，Web サーバへの HTTP，WebAP サーバへの HTTP・HTTPS，JDBC 接続，ファイル共有，ログ収集，NTP と，どれも図2の業務に対応するサービスに限られている。最後の項番9 で残りを全て拒否している。

字数制限は無い。解答例は項番が“5”，サービスが①“ファイル共有”，②“リモートデスクトップ”。サービスは図2の字句どおりに書く。

本文の根拠

〔対策とシステム再稼働〕(a)

(a) WebAP サーバ1と WebAP サーバ2に，図4のアクセス制御の設定を行うことで，送信元の IP アドレスが 127.0.0.1 である場合だけ，サーブレットコンテナの管理画面へのアクセスを許可する。

〔侵入された原因の特定〕

担当者にヒアリングしたところ，設定に誤りがあり，インターネットから管理画面にアクセスできるようになっていたことが分かった。

今回の侵入の入口は，設定の誤りによってインターネットからサーブレットコンテナの管理画面にアクセスでき，よく使われる利用者 ID とパスワードでログインされたことである。(a)は管理画面へのアクセスを送信元 127.0.0.1（そのサーバ自身）に限るので，インターネットからの管理画面への不正アクセスを防ぐ。

127.0.0.1 はループバックアドレスで，サーバの外から来る通信の送信元にはならない。図4 の設定は /manager/ 以下（表5 の /manager/html など）を対象にしており，攻撃者が No.3～No.13 で使った管理画面へのリクエストはどれも拒否される。

40 字以内で，解答例は“サーブレットコンテナの管理画面に対するインターネットからの不正アクセス”（35字）。“どこへの”（管理画面）と“どこからの”（インターネット）の両方を書く。

本文の根拠

〔対策とシステム再稼働〕(b)

(b) 各サーバの利用者 ID“administrator”を無効化し，利用者 ID“unyou”は，サーバごとに異なる利用者 ID に変更し，さらに，パスワードもサーバごとに異なるものに変更する。

A 氏の発言

そうした設定では，あるサーバから他のサーバにアクセスする際，自動的にログインが行われます。攻撃者は，そのような OS の仕様を利用して，他のサーバにもログインしたようです。

A 氏の説明のとおり，DMZ の各サーバは“unyou”“administrator”を全サーバに同じパスワードで設定していたので，あるサーバから他のサーバにアクセスすると自動的にログインが行われた。攻撃者はこの OS の仕様を利用して，WebAP サーバ2 から WebAP サーバ1，Web サーバへと侵入を広げた。(b)で利用者 ID とパスワードをサーバごとに異なるものにすれば自動的なログインが起きなくなり，この他のサーバへの侵入を防げる。

サーブレットコンテナのプロセスが“administrator”の権限で動作していたので，管理画面から侵入した攻撃者は“administrator”として他のサーバにアクセスできた。“administrator”の無効化はこの経路そのものを断つ。講評は，この設問の正答率は低く，サーブレットコンテナの管理画面から侵入され，OS の自動的なログインという仕様を利用して侵入が拡大したというポイントを理解し，それぞれの原因に対する適切な対策を立案できるようになることを期待したいとしている。

40 字以内で，解答例は“自動的にログインを行うOSの仕様を利用した，他のサーバへの侵入”（31字）。“パスワードの推測”のように一般的な攻撃を書くのではなく，今回の侵入拡大の手口（OS の自動的なログイン）を書く。

採点講評（IPA）

設問4は，セキュリティインシデントで発生した一連の攻撃を正しく理解できているか，対策の内容を通じて問う問題だったが，設問4(b)は正答率が低かった。サーブレットコンテナの管理画面から侵入され，OSの自動的なログインという仕様を利用して侵入が拡大したというポイントを理解し，それぞれの原因に対する適切な対策が立案できるようになることを期待したい。