S 社は，従業員 10 名のベンチャー企業である。S 社のファイル共有サービス（以下，S サービスという）は機能が豊富であり，登録会員（以下，S 会員という）の数を伸ばしている。
S サービスでは，利用者認証された S 会員が写真などのファイルを自身に割り当てられたフォルダにアップロードできる。さらに，当該ファイルにアクセスするための URL を電子メールなどで他者に示すことによって，当該ファイルを他者と共有できる。また，S サービス内でメッセージや“いいね”を送信できる。
S サービスの企画，開発及び運用は，CTO の F 氏が取り仕切っており，そのうち，開発と運用は，F 氏の指示の下，S 社エンジニア 2 名が行っている。S サービスは，外部セキュリティ企業による脆弱性診断を随時受けている。
〔S サービスの改修〕
前回の脆弱性診断では，利用者 ID とパスワードを用いて利用者認証する S サービスの認証モジュール（以下，S 認証モジュールという）の認証方式を，多要素認証にする方がよいとのアドバイスを受けたが，その対処が課題であった。そこで，F 氏は，認証及び認可を提供する SNS（以下，認証認可提供 SNS という）のうち，多要素認証などの機能をもつ T 社の T サービスと S サービスとを ID 連携する改修を CEO の X 氏に提案した。その改修によって，S 認証モジュールを用いない S 会員の登録と多要素認証の実現を目指す。ただし，今回の改修での ID 連携では，既存の S 会員は対象とせず，新規登録の S 会員だけを対象とする。改修後も当面は既存の S 会員の認証のために，S 認証モジュールも継続して稼働させる。
F 氏は，①S 認証モジュールの代わりに T サービスとの ID 連携を利用することにはどのような利点と欠点があるかを X 氏に説明した。X 氏は，ID 連携技術に詳しい情報処理安全確保支援士（登録セキスペ）の Y 氏を外部から招聘して，実装の最終段階でのレビューを受けることを前提に，S サービスの改修を承認した。
今回の改修では，OAuth の Authorization Code Grant を採用する。OAuth は，認証認可提供 SNS と認可情報を送受信するためのプロトコルの一つである。OAuth を用いた認可における三つの主体の説明を図1に，認可のシーケンスを図2に示す。
図1 OAuth を用いた認可における三つの主体の説明図2 OAuth を用いた認可のシーケンス図3 T サービスが提供する権限
次に，T サービスと S サービスとの ID 連携について，実装の最終段階で Y 氏のレビューを受けた。Y 氏はセキュリティ上の問題を三つ指摘した。
〔一つ目の問題〕
Y 氏は，一つ目の問題を，次の攻撃シナリオで説明した。
S サービスにログインしていない利用者が攻撃者の用意した罠サイトにアクセスすると，図4中に示すシーケンス X が走り，後に，②利用者が攻撃を受けているとは知らずに S サービスにファイルをアップロードすると，そのファイルを攻撃者にダウンロードされてしまうおそれがある。
図4 攻撃のシーケンス
この対策として，RFC 6749 は，図2のシーケンスで，推測困難な値である state パラメタを利用することを推奨している。S サービスは state パラメタを［ β ］を送信する際に付与する。S サービスは［ γ ］を受信する際に，そのセッションが，state パラメタを付与した際の［ β ］のセッションと同一であるか否かを確認する。同一である場合だけシーケンスを続ける。
〔二つ目と三つ目の問題〕
二つ目の問題は，③S サービスが T サービスに要求する権限が必要最小限のものになっていないことである。この問題については，要求する権限を一つだけにした。
三つ目の問題は，T サービスに深刻な脆弱性が報告された場合の対応方法を決めていなかったことである。この問題については，T サービスとの ID 連携を一時的に停止し，S 認証モジュールだけで認証することにした。ただし，このとき④一部の S 会員は S サービスを利用できなくなるので，対象の S 会員向けに代替策を検討することにした。
〔利用者認証の実現について〕
X 氏は，全面改修して S 認証モジュールを停止した後の利用者認証の実現方式について Y 氏に確認した。S サービスは利用者を直接認証していないが，⑤S サービスは，登録された S 会員をどのように利用者認証しているかを，Y 氏は X 氏に解説した。
S 社では，Y 氏から指摘された問題を解決した後，T サービスと S サービスとの ID 連携を開始した。
S 社の課題は，脆弱性診断で受けた“認証方式を多要素認証にする方がよい”というアドバイスへの対処である。S サービスは従業員 10 名の会社で，開発と運用は S 社エンジニア 2 名が行っているので，自前の認証モジュールに多要素認証を作り込むのは重い。多要素認証などの機能をもつ T サービスと ID 連携すれば，その機能を利用できる。したがって，利点は“多要素認証の実装を S サービス側に用意しなくてよい”ことである。
本文はこの改修によって“S 認証モジュールを用いない S 会員の登録と多要素認証の実現を目指す”と書いている。利点の問いなので，パスワードを S サービスで管理しなくてよくなる，といった一般論ではなく，課題（多要素認証）に直結する内容を書くのが“S 社の課題に即した”の意味である。
30 字以内なので，“多要素認証の実装を S サービス側に用意しなくてよい”（解答例は 25 字）のように，何を（多要素認証の実装）・どこで（S サービス側）・どうなる（不要）の三点に絞る。
設問1(2)30字以内
本文中の下線①について，可用性の観点での欠点を 30 字以内で述べよ。
解答例
Tサービスの障害時にSサービスを利用できない。
解説
本文の根拠
〔S サービスの改修〕
S 認証モジュールを用いない S 会員の登録と多要素認証の実現を目指す。
〔二つ目と三つ目の問題〕
T サービスに深刻な脆弱性が報告された場合の対応方法を決めていなかったことである。
ID 連携では，認証を T サービスに任せる。そのため，T サービスが停止したり障害が起きたりすると，T サービスで認証できず，S サービスにもログインできなくなる。可用性の観点での欠点は“T サービスの障害時に S サービスを利用できない”ことである。
本文の三つ目の問題（T サービスに深刻な脆弱性が報告された場合）でも，ID 連携を一時的に止めて S 認証モジュールだけで認証する，という対応が出てくる。これは認証を外部に依存していることの裏返しである。採点講評は，SNS と連携しない場合にも該当する欠点を書いた解答が散見されたと述べている。“問われているのは ID 連携を利用する場合に固有の欠点”なので，S サービス自身の障害や運用負荷を書かない。
30 字以内なので，“T サービスの障害時に S サービスを利用できない”（解答例は 23 字）のように，原因（T サービスの障害）と結果（S サービスが使えない）の二点を書く。
本文中の a ～ c に入れる適切な字句を解答群の中から選び，記号で答えよ。解答群 ア S サービス イ T サービス ウ 利用者
〔a〕解答例
ア
〔b〕解答例
イ
〔c〕解答例
ウ
解説
本文の根拠
図1
S サービス：T サービスでのアカウント名を要求する。
図1
T サービス：認証認可提供 SNS である。図3に示す権限を提供する。
図2
利用者と T サービスの間の双方向の矢印「認証，権限付与の確認」
OAuth（RFC 6749）では，リソースを持つ利用者（リソースオーナ）が，アプリケーション（クライアント）に，自分のリソースへのアクセスを許可する。この問題の三つの主体に当てはめると，T サービスのリソース（アカウント名など）にアクセスしようとするのが S サービス，権限を与えるのが利用者である。a は“他者が提供するリソースにアクセスする側”なので S サービス（ア），b はリソースを提供する T サービス（イ），c は“権限を与える”側なので利用者（ウ）になる。
図2では，利用者が T サービスで認証され（（え）），S サービスに与える権限を確認している。つまり権限を与えると決めているのは，T サービスではなく利用者である。T サービスは図3の権限を“提供する”が，それを S サービスに与えるかどうかを決めるのは，認証された利用者の同意である。採点講評が，仕組みを理解していない解答が多かったとしているのは，この対応づけである。
記号で答える設問なので字数の制約はない。a と b を入れ替えやすいので，“アクセスする側（S サービス）”と“リソースを持つ側（T サービス）”を，図2の矢印の向き（S サービスが T サービスに要求する）で確かめる。
攻撃者から利用者へd。利用者でリダイレクトし，利用者から S サービスへd。S サービスから T サービスへe。
図2
（お）T サービスから利用者へ「認可コード」。利用者でリダイレクトし，（か）利用者から S サービスへ「認可コード」。（き）S サービスから T サービスへ「アクセストークンの要求」。
図4は図2の正規のシーケンスと同じ流れで，違いは，T サービスとのやり取りの相手が利用者ではなく攻撃者になっていることである。図2では，T サービスが認可コードを返し，それが利用者を経由してリダイレクトで S サービスに渡り，S サービスがそれを使ってアクセストークンを要求する。したがって図4でも，攻撃者から利用者へ渡され，利用者から S サービスへ渡る d は認可コード（ウ），S サービスから T サービスへ送られる e はアクセストークンの要求（ア）である。
図4では，e の次の矢印（T サービスから S サービスへ）が「アクセストークン」になっているので，e はその要求（ア）であり，アクセストークンそのもの（イ）ではない。（エ）の認可の要求と（オ）の認証，権限付与の確認は，図4では d より前の矢印としてすでに現れている。
記号で答える設問なので字数の制約はない。図2と図4を並べ，同じ並びの矢印を対応づければよい。
設問2(2)解答欄2つ
本文中の下線②について，ファイルのアップロードと，ファイルのダウンロードは，それぞれ T サービスの誰のアカウントによって行われるか。それぞれ 6 字以内で答えよ。
〔ファイルのアップロード〕解答例
攻撃者
〔ファイルのダウンロード〕解答例
攻撃者
解説
本文の根拠
〔一つ目の問題〕
S サービスにログインしていない利用者が攻撃者の用意した罠サイトにアクセスすると，図4中に示すシーケンス X が走り
図4
攻撃者と T サービスの間の双方向の矢印「認証，権限付与の確認」
図4では，利用者が罠サイトにアクセスすると，S サービスとの認可のシーケンス X が走る。ところが，そこで T サービスにログインして権限付与を確認しているのは利用者ではなく攻撃者である。そのため，攻撃者の T サービスのアカウントで発行された認可コードが利用者のブラウザ経由で S サービスに渡り，S サービスは利用者のセッションを攻撃者の T-ID に結び付けてしまう。結果として，利用者は，自分では気付かないまま，攻撃者の T サービスのアカウントに結び付いた S サービスのセッションを使うことになる。したがって，アップロードされるときの T サービスのアカウントは攻撃者のもので，攻撃者は後から自分の T サービスのアカウントで S サービスにログインして，そのファイルをダウンロードできる。どちらも答えは“攻撃者”である。
採点講評は，利用者のアカウントによって行われると書いた解答が多かったとしている。図4のシーケンス X では，T サービスで認証されているのが攻撃者であることを確かめる。
RFC 6749 は，認可コードを受け取る側（クライアント）が，リクエストの state パラメタに推測できない値を入れて認可サーバに渡し，戻ってきた値を照合して CSRF を防ぐことを推奨している（4.1.1，10.12）。この問題の S サービスは，T サービスへの認可の要求を利用者に送る通信（い）に state を付与し，戻ってくる認可コードの通信（か）で，付与したときのセッションと同一かどうかを確認する。β は（い），γ は（か）である。
図4の攻撃では，攻撃者が自分の認可コードを利用者に渡している。その通信は，S サービスが state を付与した利用者のセッションから始まっていないので，state の照合で不一致になり，シーケンスは止まる。（う）は利用者のブラウザが T サービスへ送る通信で，S サービスが受信する通信ではない。
二つ目の問題は，③S サービスが T サービスに要求する権限が必要最小限のものになっていないことである。この問題については，要求する権限を一つだけにした。
図1
S サービス：T サービスでのアカウント名を要求する。
図3
（エ）利用者のアカウント名，電子メールアドレスなど登録情報を取得する権限。
S サービスが T サービスに要求する情報は，利用者の T サービスでのアカウント名（T-ID）である。図2の（け）（こ）で取得し，初回に S サービス内に登録して，2 回目以降の認証で確認する。この用途に必要なのは，図3のうち，利用者のアカウント名を取得する権限（エ）だけである。RFC 6749 も，クライアントは必要最小限のスコープでアクセストークンを要求すべきだと述べている（10.3）。
ただし，今回の改修での ID 連携では，既存の S 会員は対象とせず，新規登録の S 会員だけを対象とする。
〔二つ目と三つ目の問題〕
T サービスとの ID 連携を一時的に停止し，S 認証モジュールだけで認証することにした。
ID 連携を止めて S 認証モジュールだけで認証すると，S 認証モジュールで認証できるのは，利用者 ID とパスワードを S サービスに登録している既存の S 会員だけである。今回の改修以降に新規登録した S 会員は T サービスの ID 連携で登録されていて，S 認証モジュールには利用者 ID とパスワードがないので，S サービスを使えなくなる。
本文は“既存の S 会員は対象とせず，新規登録の S 会員だけを対象とする”と書いており，“既存の S 会員はそのまま S 認証モジュールで認証する”と読める。誤答しやすいのは“新規登録の S 会員”とだけ書くことで，下線④の“一部の S 会員”の条件は，S 認証モジュールに利用者 ID とパスワードがあるかどうかである。
A 社は，従業員 500 名の中規模の小売業であり，インターネットを介して消費者向けに商品を宣伝している。A 社のネットワークは，同社の情報システム部（以下，情シ部という）の L 部長と M 主任を含む 7 名で運用している。A 社のネットワーク構成を図1に，図1中の主な機器とその概要を表1に示す。
図1 A 社のネットワーク構成表1 図1中の主な機器とその概要
FW のフィルタリングルールを表2に示す。
表2 FW のフィルタリングルール
ある日，D ソフトの脆弱性を悪用した DoS 攻撃で同業他社が踏み台になったというニュースが配信された。情シ部では，脆弱性情報が公開されると，CVSS の値を参考にして自社への影響を評価し，影響が大きいケースでは，早期に脆弱性修正プログラムを適用している。今回の攻撃に使われた D ソフトの脆弱性に対する修正プログラムは既に適用されていた。A 社では，今回のニュースを契機に，DNS におけるリスクと対策の検討を，M 主任を中心に行うことにした。
〔リスクと対策の検討〕
M 主任は，まず，①A 社の外部 DNS サーバがサービス停止になった場合の影響を確認した。次に，外部 DNS サーバが攻撃を受けるリスク及び外部 DNS サーバにおけるその他のリスクを調査し，外部 DNS サーバが攻撃を受けるリスクについて，主なものを三つ挙げた。
一つ目のリスクは，踏み台になるリスクである。表1及び表2の構成では，攻撃者は，②送信元の IP アドレスを偽装した名前解決要求を外部 DNS サーバに送ることによって，外部 DNS サーバを踏み台とし，攻撃対象となる第三者のサーバに対し大量の DNS パケットを送り付けるという DoS 攻撃を行える。そこで，外部 DNS サーバを廃止した上で，DNS-K と DNS-F という DNS サーバを DMZ 上に新設し，権威 DNS サーバの機能を DNS-K に，フルサービスリゾルバの機能を DNS-F に移行することを考えた。これと併せて，FW のフィルタリングルールを表3のように変更することで一つ目のリスクへの対策となる。
表3 変更後の FW のフィルタリングルール
二つ目のリスクは，DNS キャッシュポイズニング攻撃によるリソースレコードの改ざんのリスクである。DNS キャッシュポイズニング攻撃が成功すると，攻撃対象のフルサービスリゾルバが管理するリソースレコードのうち，メールサーバの c レコードの IP アドレスが，例えば攻撃者のメールサーバのものに書き換えられてしまい，電子メールが攻撃者のサーバに送信されてしまう。この攻撃への対策として，M 主任は，三つの対策を考えた。一つ目の対策は，一つ目のリスクへの対策を流用することである。二つ目の対策は，送信元ポート番号を d する対策である。D ソフトでも可能である。三つ目の対策は，e という技術の利用である。この技術は，DNS サーバから受け取るリソースレコードに付与されたディジタル署名を利用して，リソースレコードの送信者の正当性とデータの完全性を検証するものである。ただし，この技術は，運用として，鍵の管理など新たな作業が必要になる。
三つ目のリスクは，中間者攻撃による DNS 通信内容の盗聴，改ざんのリスクである。この対策の一つとして，DNS 通信を暗号化する DNS over TLS（以下，DoT という）という技術が標準化されている。DoT は，f と g 間の通信を暗号化するために開発されたものである。
これらの調査と検討を踏まえ，M 主任は，外部 DNS サーバが攻撃を受けるリスク，外部 DNS サーバの機能を 2 台の DNS サーバに移行する対策案，及び送信元ポート番号を d する対策案を L 部長に報告した。
〔ホスティングサービス上に新設する DNS サーバの利用〕
M 主任は，外部 DNS サーバにおけるその他のリスクへの対策として，外部のホスティングサービス上に DNS サーバを新設して利用することを検討した。
M 主任は，DNS サーバの構成について，二つの案を考えた。
一つ目の案は，外部 DNS サーバを廃止した上で，DNS-K と DNS-F という DNS サーバを DMZ 上に，DNS-S という DNS サーバを X 社のホスティングサービス上に新設し，③プライマリの権威 DNS サーバの機能を DNS-K に，セカンダリの権威 DNS サーバの機能を DNS-S に移行し，フルサービスリゾルバの機能を DNS-F に移行するものである。M 主任は，DNS-K と DNS-S のゾーン情報を同期するために，DNS-K でのゾーン転送の内容を示す設定ファイル，正引きゾーンファイル，逆引きゾーンファイルを設定することにした。M 主任が設定することにした DNS-K の正引きゾーンファイルを図2に示す。
二つ目の案は，外部 DNS サーバを廃止した上で，DNS-HK，DNS-S，DNS-HF という DNS サーバを X 社のホスティングサービス上に新設し，プライマリの権威 DNS サーバの機能を DNS-HK に，セカンダリの権威 DNS サーバの機能を DNS-S に，フルサービスリゾルバの機能を DNS-HF に移行するものである。DNS-K と DNS-F の DMZ への設置は実施しない。この案の場合，FW のフィルタリングルールを表5のように変更する必要がある。
表5 二つ目の案の場合の FW のフィルタリングルール
その後，A 社では，更に検討を進め，外部 DNS サーバを X 社のホスティングサービスに移行することにした。
外部 DNS サーバは，A 社ドメイン（a-sha.co.jp）の権威 DNS サーバである。権威 DNS サーバが止まると，インターネット側の利用者が公開 Web サーバのホスト名（www.a-sha.co.jp など）から IP アドレスを引けなくなる。公開 Web サーバ自体は動いていても，名前では到達できないので，消費者向けの商品の宣伝という用途が果たせない。したがって影響は“A 社公開 Web サーバの名前解決ができなくなる”ことである。
外部 DNS サーバは，PC のプロキシサーバが使うフルサービスリゾルバも兼ねているので，止まるとインターネット上の Web サーバの名前解決もできなくなる（表1の注記2）。ただし，この設問が問うのは“A 社の公開 Web サーバへの影響”なので，権威 DNS サーバとしての影響を書く。
30 字以内なので，“公開 Web サーバの名前解決ができなくなる”のように，対象（公開 Web サーバ）と結果（名前解決不可）を書く（解答例は 23 字）。
設問1(2)20字以内
本文中の下線②の攻撃の名称を 20 字以内で答えよ。
解答例
DNSリフレクション攻撃
解説
本文の根拠
〔リスクと対策の検討〕
送信元の IP アドレスを偽装した名前解決要求を外部 DNS サーバに送ることによって，外部 DNS サーバを踏み台とし，攻撃対象となる第三者のサーバに対し大量の DNS パケットを送り付けるという DoS 攻撃
表2 項番6
項番6：インターネット，外部 DNS サーバ，DNS，許可。
送信元 IP アドレスを攻撃対象のものに偽装した問い合わせを DNS サーバに送ると，DNS サーバは応答を攻撃対象に返す。応答が問い合わせより大きければ，少ない通信量で攻撃対象に大量のパケットを送り付けられる。DNS サーバを“反射板”のように使うこの攻撃の名称が“DNSリフレクション攻撃”である（応答が大きくなることを使う場合は DNS アンプ攻撃とも呼ぶ）。
表2の項番6は，インターネットから外部 DNS サーバへの DNS を無条件で許可している。外部 DNS サーバは，権威 DNS サーバであるだけでなく，再帰的な名前解決も行うので，インターネットの誰からの問い合わせにも再帰的に答える構成になり，攻撃者がこの経路を使えてしまう。
20 字以内なので，“DNSリフレクション攻撃”（解答例は 12 字）と名称だけを書く。
設問1(3)解答欄2つ
表3中の a ，b に入れる適切な字句を解答群の中から選び，記号で答えよ。解答群 ア DNS-F イ DNS-K ウ PC エ 内部 DNS サーバ オ プロキシサーバ カ メールサーバ
〔a〕解答例
ア
〔b〕解答例
イ
解説
本文の根拠
〔リスクと対策の検討〕
DNS-K と DNS-F という DNS サーバを DMZ 上に新設し，権威 DNS サーバの機能を DNS-K に，フルサービスリゾルバの機能を DNS-F に移行することを考えた。
項番5は“送信元が a，宛先がインターネット”で，内部のサーバが外部へ DNS の問い合わせを出す通信を許可する。これを出すのはフルサービスリゾルバの DNS-F なので a はア。項番6は“送信元がインターネット，宛先が b”で，外部の利用者が A 社の名前を引きに来る通信を許可する。これを受けるのは権威 DNS サーバの DNS-K なので b はイ。
記号で答える設問なので字数の制約はない。機能の対応（権威 DNS サーバ＝DNS-K，フルサービスリゾルバ＝DNS-F）を先に確認する。
設問1(4)6字以内解答欄1つ
本文中の c に入れる DNS のリソースレコードのタイプ名を 6 字以内で答えよ。
〔c〕解答例
A
解説
本文の根拠
〔リスクと対策の検討〕
メールサーバの c レコードの IP アドレスが，例えば攻撃者のメールサーバのものに書き換えられてしまい，電子メールが攻撃者のサーバに送信されてしまう。
図2
mail IN A x1.y1.z1.t3
ホスト名に対応する IP アドレスを持つリソースレコードは A レコードである。図2でも，mail（メールサーバ）の IP アドレスは“mail IN A x1.y1.z1.t3”という A レコードで定義されている。キャッシュポイズニング攻撃でこの IP アドレスが攻撃者のメールサーバのものに書き換えられると，メールサーバの名前を引いた送信元の MTA が，攻撃者のサーバにメールを送ってしまう。
MX レコードは，メールの宛先ドメインに対する配送先のホスト名と優先度を示すもので，IP アドレスは持たない（図2の“IN MX 10 i”）。本文は“IP アドレスが書き換えられる”と言っているので，MX ではなく A である。採点講評が，攻撃や DNS の仕組みの理解を求めているのは，この区別である。
6 字以内の指定に対し，タイプ名は“A”（1 字）である。
採点講評（IPA）
設問1(4)は，正答率が低かった。DNSに対する攻撃の仕組みやDNSの仕組みをよく理解してほしい。
設問1(5)15字以内解答欄1つ
本文中の d に入れる適切な字句を 15 字以内で答えよ。
〔d〕解答例
ランダム化
解説
本文の根拠
〔リスクと対策の検討〕
二つ目の対策は，送信元ポート番号を d する対策である。D ソフトでも可能である。
DNS キャッシュポイズニング攻撃では，攻撃者は，フルサービスリゾルバが外部へ出した問い合わせに先回りして，偽の応答を返そうとする。偽の応答が受け入れられるには，問い合わせのトランザクション ID（16 ビット）と送信元ポート番号が合っている必要がある。RFC 5452 は，送信元ポートを予測できない値にする（ランダム化する）ことで，トランザクション ID の 16 ビットを超えて推測の難しさを高めることを推奨している。したがって d は“ランダム化”である。
この対策は，DNS サーバ（リゾルバ）側の設定で行うので D ソフトでも可能である。“固定”“変更”のように，固定の逆を言うだけの答えでは，何をするのかが曖昧になる。
本文中の f ，g に入れる適切な字句を解答群の中から選び，記号で答えよ。解答群 ア DNS Changer イ RADIUS クライアント ウ RADIUS サーバ エ 権威 DNS サーバ オ スタブリゾルバ カ フルサービスリゾルバ
〔f〕解答例
オ
〔g〕解答例
カ
〔備考〕順不同
解説
本文の根拠
〔リスクと対策の検討〕
DoT は，f と g 間の通信を暗号化するために開発されたものである。
表1 注
フルサービスリゾルバとしては，プロキシサーバとメールサーバが使用している。
DNS over TLS（RFC 7858）は，スタブリゾルバ（クライアント側の DNS の問い合わせ機能）と再帰的なリゾルバ（フルサービスリゾルバ）の間の通信を暗号化するものである。RFC は，スタブリゾルバと再帰サーバの間の通信が対象であり，再帰サーバと権威サーバの間の利用は DPRIVE ワーキンググループの対象外としている。この問題では，プロキシサーバやメールサーバがスタブリゾルバとして，フルサービスリゾルバ（DNS-F など）に問い合わせる。f，g はオ（スタブリゾルバ）とカ（フルサービスリゾルバ）で，順不同である。
権威 DNS サーバ（エ）は，フルサービスリゾルバからの問い合わせに答える側なので，DoT の対象にはならない。DNS Changer（ア）は DNS の設定を書き換えるマルウェアの名前，RADIUS クライアント・サーバ（イ・ウ）は認証・認可のプロトコルで，DNS の通信ではない。採点講評は，DoT の仕組みの理解を求めている。
設問1(7)は，正答率が低かった。DNS通信を暗号化するDNS over TLSは，DNSのセキュリティ対策にとって重要な技術の一つである。この仕組みを学習してほしい。
設問2(1)30字以内
本文中の下線③を実施することによって低減できるリスクを 30 字以内で具体的に述べよ。
解答例
権威DNSサーバがサービス停止になるリスク
解説
本文の根拠
〔ホスティングサービス上に新設する DNS サーバの利用〕
プライマリの権威 DNS サーバの機能を DNS-K に，セカンダリの権威 DNS サーバの機能を DNS-S に移行し
〔ホスティングサービス上に新設する DNS サーバの利用〕
外部のホスティングサービス上に DNS サーバを新設して利用することを検討した。
下線③は，権威 DNS サーバの機能を，A 社の DMZ にあるプライマリ（DNS-K）と，X 社のホスティングサービス上にあるセカンダリ（DNS-S）に分け，ゾーン情報を同期させる構成である。DNS-K が止まっても，A 社のネットワークとは別の場所にある DNS-S が A 社ドメインの名前解決に答え続けられる。したがって，低減できるのは“権威DNSサーバがサービス停止になるリスク”である。
設問1(1)で見たとおり，権威 DNS サーバが止まると公開 Web サーバの名前解決ができなくなる。一つの権威 DNS サーバだったときに残っていた単一障害点を，二つ目の権威 DNS サーバを別の場所に置くことで取り除いている。採点講評は，ホスティングサービス上に新設した後のシステム構成を正しく理解した解答が多かったとしている。
30 字以内なので，“権威DNSサーバがサービス停止になるリスク”（解答例は 21 字）のように，対象（権威 DNS サーバ）と起きること（サービス停止）を書く。
G 社は，従業員 1,500 名の製造業であり，研究開発に定評がある。従業員は，Web アクセスによる情報収集並びに電子メール（以下，メールという）による営業活動及び情報交換にインターネットを利用している。G 社では，情報セキュリティポリシを整備して運用している。G 社のシステム構成を図1に，機器及びソフトウェアの概要を表1に，OS の脆弱性修正プログラム（以下，セキュリティパッチという）の現状の配信手順を図2に示す。
図1 G 社のシステム構成（概要）表1 G 社の機器及びソフトウェアの概要（抜粋）表1 G 社の機器及びソフトウェアの概要（抜粋）（続き）図2 セキュリティパッチの現状の配信手順（抜粋）
〔同業他社の事例〕
ある日，情シ部の C 主任は，同業他社の H 社で発生したセキュリティインシデントの解説記事を見付けた。解説記事の要約を図3に示す。
図3 解説記事の要約
心配になった C 主任はログを調査した。その結果，1か月以上起動していない PC が 30 台あることが分かった。それらの PC をこのまま数か月起動しないでおくと，PC-H と同様の問題が発生する可能性があった。図3の内容及び G 社の状況を情シ部の B 部長に相談した上で，必要な対策を図4のようにまとめ，情シ部の D 君とともにそれぞれを具体化することにした。
図4 必要な対策
〔対策1〕
C 主任は，対策1については，L2SW のミラーポートに接続するタイプのパケット収集装置を導入し，J 社の J サービスを利用して通信内容を分析すればよいと考えた。J サービスは，インターネット VPN 経由でパケット収集装置から必要なパケット情報を取得し，その内容からセキュリティ侵害を検知するサービスである。
C 主任は，1台のパケット収集装置を，①マルウェア感染が DMZ 又はどの LAN で起きてもマルウェアからインターネットへの通信が通過することになる L2SW に接続することに決めた。
〔対策2〕
次は，対策2についての D 君，C 主任及び B 部長の会話である。
D 君：1か月間起動していない PC を自動的に起動して，セキュリティパッチが適用されるようにすれば図3のようなセキュリティインシデントを防ぐことができます。良い仕組みはありませんか。
C 主任：当社の PC は，WoL に対応しています。WoL とは，WoL に対応した PC に対し，特定の起動パケットを送信すると，当該 PC が起動するという仕組みです。PC を利用者 LAN に接続しておけば，資産管理サーバから起動パケットを送信することによって，PC を自動的に起動できます。
B 部長：なるほど。では，WoL とセキュリティパッチ適用の動作検証を頼む。
D 君は，WoL の動作検証を開始した。まず，検証 LAN に接続された PC-X と PC-Y を用いて試すことにした。PC-X は起動しておき，PC-Y はシャットダウンしておいた。その上で，PC-X から PC-Y に対し，b に続けて，起動したい PC の c を 16 回繰り返したデータを含む起動パケットを送信し，PC-Y が起動することを確認した。その後，資産管理サーバから PC-Y の起動を試みたが，起動しなかった。C 主任に相談したところ，②L3SW の設定を変更する必要があるという助言を受けた。D 君は，L3SW の設定を変更し，資産管理サーバから PC-Y を起動できることを確認した。続いて，資産管理サーバから利用者 LAN に接続された PC を起動できることを確認し，セキュリティパッチが適用されることも確認した。
〔WoL を悪用するマルウェアの脅威〕
WoL について調べていた D 君は，図5に示すマルウェア R の記事を見付けた。
図5 マルウェア R の記事（抜粋）
D 君は，昼間は PC が不審な振る舞いをすれば発見し対処できる可能性があるが，夜間は多くの従業員が不在となり発見することは難しいと考えた。そこで，マルウェア R に限らない，WoL を悪用するマルウェアへの対策について，C 主任に相談した。
C 主任は，PC が夜間に不審な振る舞いをしたときに，当該 PC をネットワークから隔離するという対策（以下，対策3という）を助言した。D 君は，④対策3を G 社で導入済のシステムを用いて実現する方法を立案した。対策3は対策1及び対策2と併せて承認された。各対策は運用を開始し，マルウェア対策が強化された。
パッチ担当者は，セキュリティパッチを検証 LAN の PC に適用し，社内で利用しているアプリケーションプログラムを2日間動作させてaを確認する。
図2 (3)
新たな不具合の情報が公開されていないことを確認した上で，セキュリティパッチを配信サーバに置く。
セキュリティパッチは，適用すると既存のアプリケーションが動かなくなるなどの副作用が出ることがある。そこで，全 PC に配信する前に，検証 LAN の PC に適用して，社内で使っているアプリケーションを 2 日間動作させ，問題が出ないことを確かめる。この検証の目的は“PCの動作に問題がないこと”の確認である。
PC-X から PC-Y に対し，b に続けて，起動したい PC の c を 16 回繰り返したデータを含む起動パケットを送信し
〔対策2〕
WoL とは，WoL に対応した PC に対し，特定の起動パケットを送信すると，当該 PC が起動するという仕組みです。
本文の起動パケットは，b の後に，起動したい PC の識別情報を 16 回繰り返す形をしている。WoL の起動パケット（マジックパケット）は，同期用に全ビットが 1 のバイト列（FF）を並べ，そのあとに対象の NIC の MAC アドレスを繰り返す形式として知られている。FF:FF:FF:FF:FF:FF は，全ビットが 1 の MAC アドレスで，ブロードキャストに使うアドレスと同じ並びである。したがって b は，この FF の並びに当たるエである。
本文中の c に入れる適切な字句を解答群の中から選び，記号で答えよ。解答群 ア IP アドレス イ MAC アドレス ウ 製造番号 エ プロダクト ID オ ホスト名
〔c〕解答例
イ
解説
本文の根拠
〔対策2〕
起動したい PC の c を 16 回繰り返したデータを含む起動パケット
表1 資産管理サーバ
Wake on LAN（以下，WoL という）の起動パケットを送信する機能をもつ。
WoL の対象は，電源が切れている PC である。電源が切れている間は，OS が動いていないので IP アドレスを使った通信は処理されず，NIC が受けた起動パケットの中の自分の MAC アドレスの並びを見て起動する。そのため，起動パケットに繰り返し入れるのは，起動したい PC の MAC アドレス（イ）である。
設問4(1)で扱う図5のマルウェアも，ARP テーブルから“起動していない PC の MAC アドレス”を読み取って，WoL の起動パケットを作る。IP アドレス（ア）は，起動した後の通信に必要な情報で，起動パケットには入れない。製造番号・プロダクト ID・ホスト名は，NIC の識別には使われない。
記号で答える設問なので字数の制約はない。“電源が切れている機器を，NIC のアドレスで起こす”という WoL の仕組みから選ぶ。
設問3(3)30字以内
本文中の下線②に示す設定変更の内容を，30 字以内で具体的に述べよ。
解答例
起動パケットを他のセグメントに転送するように変更する。
解説
本文の根拠
〔対策2〕
その後，資産管理サーバから PC-Y の起動を試みたが，起動しなかった。
図1
L3SW の左側は内部システム LAN で，L2SW4 に資産管理サーバ，ログ蓄積サーバ，EDR 管理サーバ，内部メールサーバ，内部 DNS サーバ，業務サーバ，配信サーバがつながる。
図1
検証 LAN は L2SW3 に複数の PC がつながる。
PC-X から PC-Y の起動は，同じ検証 LAN の中だったので成功した。資産管理サーバは内部システム LAN にあり，L3SW を越えて検証 LAN の PC-Y に起動パケットを届ける必要がある。WoL の起動パケットはブロードキャストで送られるのが一般的で，ブロードキャストは，ルータや L3 スイッチでは，既定では別のセグメントに転送されない（RFC 919 は，制限ブロードキャストは“転送してはならない”と定めている）。そのため，L3SW に，起動パケットを他のセグメントへ転送するよう設定を変更する必要がある。
採点講評は，WoL の制限事項とその解決方法を導けていない解答が多かったとしている。“L3SW の設定を変更する”という本文の記述だけでなく，“何を”“どこへ”転送するかまで書く。“資産管理サーバの IP アドレスを許可する”のような，通信制御の話にするのは違う。実際の設定項目の名称は機器によって異なる。
夜間に ARP テーブル中の PC 全てに ping コマンドを送信し，PC が起動しているかどうかを確認する。
図5 (4)
起動していない PC を発見したら，WoL を使ってそれらの PC を起動し，感染拡大を試みる。
〔対策2〕
起動したい PC の c を 16 回繰り返したデータを含む起動パケット
ARP テーブルは，同じセグメントの機器の IP アドレスと MAC アドレスの対応を保持している（RFC 826）。(2)は ping で PC が起動しているかを確かめる活動で，ping の宛先として必要なのは IP アドレスである。(4)は WoL で起動していない PC を起動する活動で，起動パケットに入れるのは設問3(2)で見たとおり MAC アドレスである。したがって，(2)の活動に必要な情報は“IPアドレス”，(4)の活動に必要な情報は“MACアドレス”である。
(4)で起動パケットを作るためには，ping に返事のない PC の MAC アドレスを，感染直後に ARP テーブルから読み取って保持しておく必要がある。(1)の“感染するとすぐに”が，ここに効いている。
10 字以内の指定に対し，“IPアドレス”（6 字）と“MACアドレス”（7 字）で足りる。
設問4(2)55字以内
本文中の下線④の方法を，55 字以内で具体的に述べよ。
解答例
エージェントによって，夜間にarpコマンドの実行を検知したら，当該PCをネットワークから隔離する。
解説
本文の根拠
表1 エージェント
指定した時間帯に指定したコマンドが実行された場合，EDR 管理サーバとの間の通信を除き，当該 PC の全ての通信を遮断する機能をもつ。
〔WoL を悪用するマルウェアの脅威〕
C 主任は，PC が夜間に不審な振る舞いをしたときに，当該 PC をネットワークから隔離するという対策（以下，対策3という）を助言した。
図5 (1)
感染するとすぐに，③自身が動作する PC の ARP テーブルから下記(2)及び(4)の活動に必要な情報を読み取って保持しておく。
対策3は，夜間に不審な振る舞いをした PC をネットワークから隔離するものである。G 社で導入済のシステムのうち，これを実現できるのはエージェント（EDR）である。エージェントは，指定した時間帯に指定したコマンドが実行された場合，EDR 管理サーバとの通信を除いて，当該 PC の全ての通信を遮断する機能をもつ。図5のマルウェアは，感染直後に ARP テーブルを読み取る（arp コマンドなどが使われる）ので，夜間の時間帯に arp コマンドが実行されたらその PC を隔離するように設定すれば，ping による調査や WoL による感染拡大の前に，通信を止められる。
