N システムは，図1に示す構成であり，店舗で店員が利用するタブレット端末用店舗アプリケーションプログラム（以下，店舗アプリという），利用者が利用するスマートフォン用決済アプリケーションプログラム（以下，決済アプリという），及び決済，ログ取得，アラート通知などの機能をもつ Web サーバ N を用いて決済を実現する。
図1 N システムの構成（概要）
決済アプリの機能の概要を表1に，Web サーバ N の機能の概要を表2に，会員登録処理を表3に，決済処理を表4に示す。
表1 決済アプリの機能の概要（抜粋）表2 Web サーバ N の機能の概要（抜粋）表3 会員登録処理（抜粋）表4 決済処理（抜粋）
各店舗では，決済時に利用者のスマートフォンが確実に通信できるように，N システム導入に合わせて，各店舗に導入済みの無線 LAN ルータをインターネットに接続し，利用者に無線 LAN サービスを提供する予定である。無線 LAN ルータは全て同一の機種である。各店舗で管理者を決めて，管理者が手動で初期設定をしている。表5に無線 LAN ルータの管理者機能の設定項目を示す。
表5 無線 LAN ルータの管理者機能の設定項目（抜粋）
N システムの開発チームに所属する X さんが検討した N システムの仕様並びに店舗アプリ及び決済アプリの設計を，セキュリティの観点から情報処理安全確保支援士（登録セキスペ）の Y さんがレビューした。レビューでの Y さんの指摘を表6に示す。
表6 Y さんの指摘
X さんは，指摘について対策を検討した。
〔項番1への対策〕
X さんは，表6中の項番1への対策として，メッセージ認証を用いることにした。具体的には，決済機能利用時に決済アプリに表示する情報として，会員番号，Web サーバ N で生成した乱数，時刻，及びそれら三つの情報を基に生成される HMAC（Hash-based Message Authentication Code）値を含めることにした。バーコードで扱える桁数を超えてしまうので，代わりに QR コードを表示することにした。HMAC 値を含む QR コードを用いた決済フローを図2に示す。QR コード生成及び QR コード検証の手順を図3に示す。
図2 HMAC 値を含む QR コードを用いた決済フロー図3 QR コード生成及び QR コード検証の手順
〔項番2〜4への対策〕
表6中の項番2〜4の指摘を解決せずに無線 LAN サービスを提供し，①攻撃者が無線 LAN ルータの設定を変更すると，攻撃者が用意したサーバに利用者が接続しても気付かないおそれがある。
X さんは，項番2については，インターネットから管理者機能のログイン画面にアクセスされないようにするために，無線 LAN ルータのファームウェアを脆弱性が対策された最新のバージョンにアップデートしてもらうことにした。項番3については，管理者機能のパスワードを工場出荷時のパスワードから変更するように運用ルールを変更し，まだ変更していない場合は変更してもらうことにした。項番4については，サーバ証明書が図4に示す条件を満たしているかどうかを検証するように決済アプリ及び店舗アプリを改修した。
図4 サーバ証明書の検証条件（抜粋）
〔項番5への対策〕
攻撃者が，②事前にスクリーニングを実行したパスワードリストを用いて，パスワードリスト攻撃を行うと，Web サーバ N のアラート通知機能では検知されないおそれがある。そこで，X さんは，③表3の会員登録処理を修正することにし，さらに，パスワードリスト攻撃への追加対策として2段階認証を施し，アラート通知機能も見直すことにした。
N 社は，N システムの試行を幾つかの店舗で実施し，問題がないことを確認した。その後，N システムを全店舗に展開した。
下線①は，攻撃者が無線 LAN ルータの管理者機能にログインできた場合（項番2，3 の指摘）に，攻撃者の用意したサーバに利用者を誘導できるという話である。誘導に使える設定は，表5のうち，名前解決の向き先を決める“い DNS プロキシ”の“無線 LAN ルータが参照する DNS サーバの IP アドレス”である。これを攻撃者の DNS サーバの IP アドレスに書き換えれば，利用者のスマートフォンが Web サーバ N の名前を引いたときに，攻撃者のサーバの IP アドレスが返り，利用者は偽のサーバに接続する。
“う DHCP サーバ”の IP アドレス範囲やリース期間，“え パケットフィルタリング”のフィルタリングルールを変えても，名前を偽のアドレスに解決させることはできず，“あ”のパスワードは変更対象ではなくログインに必要な情報である。気付かないおそれがあるのは，項番4 のとおりサーバ証明書の検証に不備があると，偽のサーバでも接続が成立してしまうからである。
R 社では，電子メール（以下，メールという）を利用している。メールアドレスのドメイン名には，r-sha.co.jp（以下，R 社ドメイン名という）を使用している。R 社では，委託先との設計ドキュメントファイルの交換に当たって，F 社のファイル交換サービス（以下，F サービスという）の利用を推進している。ただし，委託先が社内ルールで外部のファイル交換サービスの利用を禁止している場合は，設計ドキュメントファイルをパスワード付き ZIP ファイルにし，メールに添付して，メーリングリスト（以下，ML という）のメールアドレス宛てに送信している。ZIP ファイルのパスワードは，平文のメールで ML のメールアドレス宛てに送信している。
ML には，G 社の ML サービス（以下，G サービスという）を利用している。ML のメールアドレスのドメイン名は，G 社が取得したものである。ML のメールアドレスのローカル部は，プロジェクト名と委託先の会社名を組み合わせている。例えば，B プロジェクトでの S 社との交換では，ML のメールアドレスのローカル部は，b-project_s-sha にする。
G サービスでは，メールを ML のメールアドレス宛てに送信すると，登録されたメンバ（以下，登録メンバという）のメールアドレス宛てに同報される。ML の登録メンバのメールアドレスの管理は，プロジェクトごとに R 社のそれぞれのプロジェクト管理者が行う。各プロジェクト管理者は，自身が管理するプロジェクトの ML の登録メンバでもある。
〔R 社の情報システム〕
R 社の情報システムは，情報システム部が運用している。R 社の情報システムのネットワーク構成を図1に示す。
図1 R 社の情報システムのネットワーク構成（抜粋）
内部システム LAN のサーバの機能概要を表1に示す。
表1 内部システム LAN のサーバの機能概要（抜粋）
内部システム LAN のサーバではサーバ証明書を利用している。それらのサーバ証明書は，ネットワークに接続していない証明書発行専用機器上の R 社認証局（以下，R 社 CA という）で発行している。R 社 CA は情報システム部が運用している。
DMZ のサーバの機能概要を表2に示す。
表2 DMZ のサーバの機能概要（抜粋）
ISP の DNS サービスを，DNS キャッシュサーバ及び R 社ドメイン名の権威 DNS サーバとして利用している。
R 社では，従業員ごとに 1 台の PC を貸与している。各 PC には，R 社 CA のルート証明書を信頼できる発行元として登録している。
PC の Web ブラウザでは，HTTPS でアクセスする Web サーバのサーバ証明書が失効していないことを，RFC 6960 で規定されている b を利用して確認できるようにしている。
〔要望への対応〕
営業部と開発部から，委託先とのメール利用についての要望が情報システム部の D 部長に提出された。D 部長はその要望を基に，表3の要件をまとめた。
表3 委託先とのメール利用についての要件
D 部長は，部下の E 主任と H さんに表3についての対応策の検討を指示した。
H さんは，メールの通信を暗号化することによって，表3の二つの要件に対応できるのではないかと E 主任に話した。
それに対して，E 主任は次の指摘をした。
①メールの通信を暗号化しただけでは，表3の項番1を満たせない。
攻撃者が委託先を装った c を用意するようななりすましは，送信元の c の真正性を確認して検出できる。一方，送信者メールアドレスとして委託先のメールアドレスを使うようななりすましは検出できないので，表3の項番2を満たせない。
そこで，E 主任と H さんが他の対応策を調査したところ，S/MIME を利用すれば表3の要件を実現できることが分かった。E 主任と H さんは，S/MIME の利用を想定した次の方式を考えた。
（あ）R 社 CA で，S/MIME で利用する鍵ペアを生成し，S/MIME に利用可能なクライアント証明書（以下，S/MIME 証明書という）を発行する。
（ア）R 社 CA のようなプライベート認証局のルート証明書を PC に登録することが，委託先によっては禁止されており，その場合，R 社の従業員が送信したメールの d を e することができない。
（イ）委託先に事前に S/MIME 証明書を渡す必要があり，その方法を決める必要がある。
（ウ）ML 宛てのメールを暗号化できない。
E 主任と H さんは，（ア）〜（ウ）それぞれの解決策を検討した。
（ア）については，認証局サービス事業者が発行する S/MIME 証明書であれば，委託先での R 社 CA のルート証明書を PC に登録しなくてもよいことが分かった。加えて，失効情報サーバの導入も不要であることが分かった。そこで，認証局サービス事業者が発行する S/MIME 証明書を利用することにした。
（イ）については，S/MIME 証明書を外部記憶媒体に保存して手渡す方法と，メールで送信する方法を調査した。調査の結果，S/MIME を用いて d を付与したメールを送信すれば，受信者は S/MIME 証明書も受け取れるし，送信者が他者になりすましていないことも確認できることが分かり，便利でもあるので，メールで送信する方法にすることにした。
（ウ）については，表3の項番1を完全に満たすわけではないが，次の案を考えた。
(1) R 社のプロジェクト管理者は，あらかじめ，G サービスに f のメールアドレスの S/MIME 証明書を登録する。
(2) R 社のプロジェクト管理者は，あらかじめ，g のメールアドレスの S/MIME 証明書の発行手続を G 社に依頼する。
表3の項番1は，送信者から受信者までメールが暗号化されたまま届くことを求めている。メールの通信の暗号化は，SMTP over TLS のように，メールサーバ間などの通信路ごとに行うものである。通信路の途中にあるメールサーバは，受け取ったメールをいったん復号して中身を扱い，メールボックスにもそのまま格納する。したがって通信を暗号化しただけでは，メールサーバ上でメールが暗号化されておらず，送信者から受信者までの暗号化にはならない。
講評は，SMTP over TLS 及び POP3 over TLS で通信が暗号化されても，メールサーバ上の電子メールは暗号化されていないことの理解を求めている。正答率は平均的であった。
設問2(1)は，正答率が平均的であった。SMTP over TLS及びPOP3 over TLSによって，通信は暗号されるが，メールサーバ上の電子メールは暗号化されていないということをよく理解してほしい。
設問2(2)10字以内解答欄1つ
本文中の c に入れる適切な字句を，10 字以内で答えよ。
〔c〕解答例
メールサーバ
解説
本文の根拠
〔要望への対応〕 E 主任の指摘
攻撃者が委託先を装った c を用意するようななりすましは，送信元の c の真正性を確認して検出できる。
表2 外部メールサーバ
SMTP over TLS にも対応している。
メールの通信を暗号化する方式（SMTP over TLS）では，メールを送ってくる相手のサーバが，サーバ証明書によって本物のメールサーバであることを確認できる。攻撃者が委託先を装ったメールサーバを用意しても，正しい証明書をもたないので，送信元のメールサーバの真正性を確認すれば検出できる。c は“メールサーバ”である。
一方，送信者のメールアドレスは，メールの利用者が自由に書ける情報で，通信の暗号化では真正性が確認されない。委託先のメールアドレスを使ったなりすましは検出できず，表3 の項番2 を満たせない，というのが E 主任の指摘の後半である。
R 社 CA で，S/MIME で利用する鍵ペアを生成し，S/MIME に利用可能なクライアント証明書（以下，S/MIME 証明書という）を発行する。
S/MIME で暗号化したメールは，宛先の利用者の公開鍵（S/MIME 証明書）で暗号化されていて，対応する秘密鍵がなければ復号できない。方式（あ）で R 社 CA が鍵ペアを生成するので，その秘密鍵が失われると，過去に受信した暗号化メールを開けなくなる。そこで（え）は，後で参照するメールを復号した状態でファイルサーバに保存することにしている。
本文中の d 〜 g に入れる適切な字句を，d，f は，それぞれ 10 字以内で，e，g は，それぞれ 5 字以内で答えよ。
〔d〕解答例
ディジタル署名
〔e〕解答例
検証
〔f〕解答例
MLの登録メンバ
〔g〕解答例
ML
解説
本文の根拠
〔S/MIME 利用に向けた課題と解決策〕（ア）
R 社 CA のようなプライベート認証局のルート証明書を PC に登録することが，委託先によっては禁止されており，その場合，R 社の従業員が送信したメールの d を e することができない。
（イ）の検討
調査の結果，S/MIME を用いて d を付与したメールを送信すれば，受信者は S/MIME 証明書も受け取れるし，送信者が他者になりすましていないことも確認できることが分かり，
（ウ）の案 (1)
R 社のプロジェクト管理者は，あらかじめ，G サービスに f のメールアドレスの S/MIME 証明書を登録する。
（ウ）の案 (2)〜(5)
G サービスは，f のメールアドレスのそれぞれの S/MIME 証明書を使い，受信後にそれぞれが復号できるようにしてメールを暗号化する。
d と e：S/MIME では，送信者がメールにディジタル署名を付与し，受信者はその署名を検証して，送信者のなりすましや改ざんを確認する。署名の検証には，署名者の証明書を発行した認証局のルート証明書を信頼できる発行元として登録している必要がある。（ア）はそれが禁止されている委託先の話なので，R 社の従業員が送信したメールのディジタル署名を検証できない。d はディジタル署名，e は検証である。（イ）の“S/MIME を用いて d を付与したメールを送信すれば，受信者は S/MIME 証明書も受け取れる”の d も同じ，ディジタル署名である。
f と g：（ウ）は，ML に送るメールを G サービスで暗号化したまま扱う案である。ML 自体のメールアドレスの S/MIME 証明書を用意して（g＝ML），送信者はそれで暗号化したメールを送る。G サービスは，それを復号し，ML の登録メンバそれぞれの S/MIME 証明書で，各メンバが復号できるように暗号化し直して送る（f＝ML の登録メンバ）。f の S/MIME 証明書は，プロジェクト管理者があらかじめ G サービスに登録しておく。
その後，指摘3に従い，U さんは運用グループに診断計画を説明して設定の変更を依頼した。運用グループから，設定の変更については承諾を得られたが，診断計画について，診断 2 の診断 PC を接続するポイントを，図1の(e)から(d)に変更する必要があるという提案があった。
この提案について，運用グループから説明があった。運用グループによれば，最近配属された担当者が，Web 管理 PC から本番 DB サーバにログインを試みた。その結果，警告灯が点灯し，運用グループは緊急対応体制をとることになってしまった。その再発防止策の一つとして，FW2 のルールを修正し，c 宛ての通信については，d からの通信だけを e することにした。その影響で，接続ポイントの変更が必要になるとのことだった。
U さんは T 主任の指摘及び運用グループからの提案を踏まえ，診断計画を確定し，診断実施に向けて準備を進めた。
N-IPS は現在，遮断モードで脅威通信判定が有効になっている。PF 診断は，全てのポートをスキャンし，開いているポートを使って OS やミドルウェアの脆弱性を検査する通信を大量に送るので，N-IPS から見ると脅威と判定される通信が多く，遮断される。遮断された通信については診断 PC に応答が返らず，その先にある脆弱性の有無を確認できない。
脅威通信判定を無効にすると，それらの通信が遮断されずに本番 Web サーバに届き，診断が進む。その結果，有効なまま診断するケースと比べて，より多くの脆弱性を検出する可能性がある。
診断 PC は，既存の機器とは別の IP アドレスを設定し，インターネット又は内部のネットワークに接続する。
N-IPS の判定は番号の小さい順に行われ，最初に合致したルールが適用される。ホワイトリスト判定（1番）に登録した IP アドレスからの通信は脅威ではないと判定され，脅威通信判定（2番）は行われない。したがって，診断 PC の IP アドレスをホワイトリストに登録すれば，診断 PC からの通信だけが遮断されなくなる。
脅威通信判定そのものを無効にすると，診断中は本物の攻撃も防げなくなる。ホワイトリストなら，診断 PC 以外の IP アドレスからの通信は引き続き脅威通信判定を受け，本物の攻撃を防げる。診断 PC は既存の機器とは別の IP アドレスをもつので，登録するアドレスも明確に決められる。現在ホワイトリストは空なので，登録した IP アドレスが診断 PC のものに限られる点も安全である。
本文中及び表2中の a に入れる診断 PC の接続箇所を，図1中の接続点(a)〜(f)の記号で答えよ。
〔a〕解答例
(a)
解説
本文の根拠
表2 診断1
攻撃者がインターネットから本番 Web サーバを攻撃し，本番 DB サーバの秘密情報を窃取する脅威を想定し，次の二つの診断を行う。
表1 N-IPS
インターネットから本番 Web サーバへの通信，本番 Web サーバから DB-LAN への通信を監視している。
会話 T 主任
インターネットからの PF 診断だけでなく，内部のネットワークからの PF 診断も実施すべきだ。
診断 1 は，攻撃者がインターネットから本番 Web サーバを攻撃する脅威を想定している。インターネットからの診断は，FW1 と N-IPS を通る経路で行う。内部のネットワークからの診断は，その経路の途中に置かれた N-IPS を通らずに，本番 Web サーバと直接通信できる箇所から行う。図1で，N-IPS の先にあって本番 Web サーバの属する DMZ の L2SW にある接続点は(a)で，a は(a)である。
(b)，(d)，(f) は管理 LAN の L2SW，(e) は管理 PC セグメント，(c) は DB-LAN にあり，いずれも診断 1 が想定する，インターネットから本番 Web サーバへの攻撃の経路とは別のものである。講評によると，管理 LAN にある接続箇所を選ぶ誤答が多く，正答率は低かった。管理 LAN からでは適切な診断ができない。
診断 2 は，管理 PC セグメントの接続点(e)から，本番 DB サーバに PF 診断を行う。本番 DB サーバのホスト型 IPS は，ホワイトリスト設定で，登録された IP アドレス（本番 Web サーバと DB 管理 PC）以外の通信を拒否し，拒否すると警告灯が点灯する。診断 PC の IP アドレスは登録されていないので，診断を始めた時点で警告灯が点灯し，運用グループが緊急対応体制をとってしまう。
そこで，本番 DB サーバのホスト型 IPS のホワイトリストに診断 PC の IP アドレスを登録する。さらに，ホワイトリストを通過した通信は侵入検知設定（脅威と判定した通信を拒否し，警告灯を点灯させる）による判定を受けるので，PF 診断の通信が脅威と判定されて拒否されないよう，侵入検知設定を無効にする。
55 字以内なので，“ホスト型IPSのホワイトリスト設定に，診断PCのIPアドレスを登録し，侵入検知設定を無効にする。”（解答例）のように，機器内の設定名と変更内容を具体的に書く。機器は図1 から“本番DBサーバ”を選ぶ（ホスト型 IPS が導入されているのは本番 DB サーバである）。
本文中の c，d に入れる適切な字句を，図1中から選び答えよ。また，本文中の e に入れる適切な字句は，許可又は拒否のいずれか。答案用紙の“許可”，“拒否”のいずれかを○印で囲んで示せ。
〔c〕解答例
本番DBサーバ
〔d〕解答例
DB管理PC
〔e〕解答例
許可
解説
本文の根拠
図1 注2)
このリモートメンテナンスは，DB 管理 PC からだけ行うよう運用ルールが定められている。
運用グループの説明
最近配属された担当者が，Web 管理 PC から本番 DB サーバにログインを試みた。その結果，警告灯が点灯し，運用グループは緊急対応体制をとることになってしまった。
運用グループの提案
診断 2 の診断 PC を接続するポイントを，図1の(e)から(d)に変更する必要がある
本番 DB サーバのリモートメンテナンスは，運用ルールで DB 管理 PC からだけ行うことになっている。ところが，Web 管理 PC からログインを試みる担当者がいて，ホスト型 IPS のホワイトリストに載っていない IP アドレスの通信が拒否され，警告灯が点灯した。その再発防止策として，FW2 のルールを修正し，本番 DB サーバ宛ての通信は，DB 管理 PC からの通信だけを許可することにした。c は本番 DB サーバ，d は DB 管理 PC，e は許可である。
このルールにすると，管理 PC セグメント内の接続点(e)から診断 PC が本番 DB サーバに通信しても，FW2 が拒否してしまう。そのため診断 2 の診断 PC は，FW2 を通らずに本番 DB サーバと通信できる(d)に接続することになる。これが運用グループの提案の理由である。
c，d は図1 から選ぶので，図中の機器名（本番 DB サーバ，DB 管理 PC）をそのまま書く。e は“許可”と“拒否”のうち，答案用紙の“許可”を○印で囲む。“DB 管理 PC からの通信だけ”に対する処理なので，拒否ではない。
