U 社は,IoT 機器の開発を行う,従業員数 400 名の企業である。IoT 機器のソフトウェアの開発には C/C++言語を使っている。IoT 機器に搭載する OS には,Linux を利用してきたが,今後は Linux 以外も利用する予定である。これまで製品に大きなトラブルはなかったが,2020 年東京オリンピック・パラリンピックに向けて IoT 機器に関するセキュリティリスクが高まると経営層が判断し,開発におけるセキュリティ対策を強化することになった。そこで,開発部の L 部長と X 主任がセキュリティ対策技術を調査した。
現在,メモリ破壊攻撃に対する対策技術(以下,M 対策技術という)が普及している。X 主任は,DEP を含めた代表的な M 対策技術を調査し,表1にまとめた。
表1 M 対策技術の概要
攻撃者が,DEP を回避するため,図2中の shell コードへ処理を遷移させる代わりに,b 中の実行可能なコードや c 領域にマップされている Vuln の断片コードを利用するケースがある。例えば,攻撃の際,a を b 関数の先頭アドレスで書き換えて,攻撃者の意図した b 関数を呼び出す d 攻撃もある。
〔M 対策技術の動作概要〕
例えば,Vuln のコンパイル時に SSP が適用されていると,関数 foo を呼び出す際,図2のベースポインタレジスタ保存値より下位に e が挿入される。もしも,e が上書きされた場合は,攻撃と判断し,Vuln の実行を停止する。
なお,Vuln の場合は簡単ではないが,攻撃者が e の値を正確に推測して上書きできてしまうと,a の書換えが可能となり,d 攻撃を防げない。その対策としては,ライブラリ関数のアドレス推定を困難にさせる f が有効である。
しかし,f は c 領域にある実行可能なコードを用いる攻撃に対しては効果がない。そうした攻撃は PIE によって緩和される。さらに,Vuln の場合,Automatic Fortification によって,ライブラリ関数 g を安全な関数に置き換えることで,バッファオーバフローの原因を排除することができる。
〔脆弱性対策強化〕
L 部長と X 主任が表1の技術を確認したところ,表1の備考欄の指摘以外にも②Automatic Fortification ではバッファオーバフローの原因を排除できないケースがあると分かった。
L 部長は次に,表1の技術を適用することによる影響を確認した。その結果,次のことが分かった。例えば,ソースコードに脆弱性があっても,SSP を適用してコンパイルしていると,メモリ破壊攻撃が成立しないが,そのソースコードを③別の開発環境でコンパイルすると問題となる場合があることが分かった。
攻撃者が,DEP を回避するため,図2中の shell コードへ処理を遷移させる代わりに,b 中の実行可能なコードや c 領域にマップされている Vuln の断片コードを利用するケースがある。
〔メモリ破壊攻撃の概要〕
攻撃の際,a を b 関数の先頭アドレスで書き換えて,攻撃者の意図した b 関数を呼び出す d 攻撃もある。
図1の関数 foo は,7行目の strcpy(d, b) で,書込み先 d(100 バイトの配列)の大きさを確かめずに b の内容をコピーしている。図2のメモリマップでは,スタックの下位(図の下側)に char d[100],その上位に ベースポインタレジスタ保存値 とリターンアドレス X が並ぶので,長すぎるデータで d を溢れさせると,上位にあるリターンアドレス X が書き換えられる。関数 foo が終了するとき,処理はスタックに保存されたリターンアドレスへ戻るので,ここを shell コードの先頭アドレスにしておけば,shell コードへ処理が遷移する。したがって a にはキ(リターンアドレス X)が入る。
b と c は,DEP を回避する攻撃が使う領域である。DEP でも実行が許されるのは,プログラムのコードが置かれたテキスト領域やライブラリである。リターンアドレスをライブラリ関数の先頭アドレスで書き換えて,攻撃者が選んだライブラリ関数を呼び出す攻撃が Return-to-libc で,b はカ(ライブラリ),d はア(Return-to-libc)になる。c はテキスト領域(図2で Vuln が載っている領域)で,ここにあるコードの断片を次々につないで実行する手法が ROP であり,空欄 d にはならない。
解答群の取り違えに注意する。オ(ベースポインタレジスタ保存値)は d[100] とリターンアドレス X の間にあるが,shell コードへ処理を移すために書き換えるのはリターンアドレス X の方である。ウとエでは,ヒープは書込み可能なデータ領域で,攻撃者が使う“実行可能なコード”の置き場所にはならないので,c はウ(テキスト)になる。
ASLR(Address Space Layout Randomization):プログラムの実行時に,データ領域,ヒープ領域,スタック領域及びライブラリを,ランダムにマップする OS の技術
〔M 対策技術の動作概要〕
その対策としては,ライブラリ関数のアドレス推定を困難にさせる f が有効である。
e は,SSP が関数呼出しの際にベースポインタレジスタ保存値より下位(図2の下側)に挿入する値で,表1の SSP の概要にある“canary と呼ばれる値”である。スタックバッファオーバフローでリターンアドレス X まで書き換えようとすると,その手前にある canary も上書きされるので,関数の終了時に値の変化を調べて攻撃を検知し,Vuln の実行を停止する。攻撃者が canary の値を正確に推測して同じ値で上書きできれば,検知をすり抜けてリターンアドレス X を書き換えられる。
f は,“ライブラリ関数のアドレス推定を困難にさせる”技術で,表1の中でライブラリを含む領域をランダムにマップするのは ASLR である。続く文の“f は c 領域にある実行可能なコードを用いる攻撃に対しては効果がない。そうした攻撃は PIE によって緩和される”とも合い,PIE は ASLR が対象とする領域に加えてテキスト領域もランダムにする技術と表1に書かれている。
表1の用語で答える指定なので,e は canary,f は ASLR と書く(PIE や DEP は,それぞれ“テキスト領域もランダム化”“実行禁止”の技術で,空欄の説明とは合わない)。
したがって,どのような問題かは“メモリ破壊攻撃を防げないこと”,どのような開発環境かは“SSPを適用できないコンパイラを利用する開発環境”である(解答例)。IoT 機器に搭載する OS は今後 Linux 以外も使う予定とされており,OS やコンパイラが変わる場面が現実にある。採点講評も,SSP はコンパイラに依存することに気付いてほしかったと述べている。
宛先ポート別の件数で,445/TCP のコネクション件数が普段と比べて非常に多かった。J 主任は,セキュリティ機関から,ワーム V に関する注意喚起を受け取っていたことを思い出した。ワーム V に関する注意喚起を図3に示す。
図3 ワーム V に関する注意喚起
J 主任はワーム V が原因であると仮定して分析を進めた。送信元 IP アドレス別の件数では,10.100.130.1 の件数が普段と比較して非常に多かった。宛先 IP アドレス別の件数では,ファイルサーバや Web サーバなどが件数の上位になっており,普段と比べて大きな違いはなかった。②ワーム V が行うスキャンは,宛先 IP アドレス別の件数の上位に登場していない。TCP ステータス別の件数では,“SYN に対して応答なし”が多くなっているが,これはワーム V のスキャンに対して,宛先 IP アドレスから応答がないことを示していると考えた。ここまでの調査結果から,10.100.130.1 の IP アドレスをもつ機器がワーム V に感染している可能性があると判断し,ネットワークの停止をアナウンスして,L2SW で,10.100.130.1 の機器がつながっている物理ポートをシャットダウンした。
〔無線 LAN セグメントの調査〕
10.100.130.1 は,ルータとして動作している AP に割り当てた IP アドレスであることが分かった。AP では NAPT で IP アドレスの変換をして PC と接続していることから,AP に接続している PC がワーム V に感染している可能性があると判断した。これらの PC の IP アドレスは AP の DHCP サーバ機能で設定していることから,AP の通信ログ及び DHCP サーバ機能のログ(以下,DHCP サーバログという)を調査することにした。
DHCP サーバ機能では,IP アドレスのリース期間を 1 時間に設定しており,プールしている IP アドレス範囲から適宜リースする。AP での通信ログのうち宛先 IP アドレスが G 社の利用していない IP アドレスであり,かつ,宛先ポートが 445/TCP のものを表1に示す。表2に 10 月 28 日の AP の DHCP サーバログを示す。M 君は,表1と表2を基に,445/TCP のポートをスキャンしている PC を特定した。
表1 AP の通信ログ表2 AP の DHCP サーバログ
〔セキュリティインシデントの再発防止策〕
M 君は,無線 LAN のパケットをキャプチャしたところ,6 台の PC が,d リクエストをブロードキャストで送信して,同一セグメント内の PC を探索していることを確認した。
M 君は,無線 LAN に接続している PC のうち 6 台がワーム V に感染している可能性を J 主任に報告した。J 主任は,感染有無を確認するよう指示した。セキュリティ機関からは,ワーム V のインディケータ情報が e 形式で提供されていた。そこで M 君がそのインディケータ情報を使ってファイルを検索して,感染の有無を確認したところ,6 台ともワーム V に感染していることが分かった。
通信ログ及びワーム V のファイルの作成日時から,最初に感染したのは,IP アドレスが 192.168.0.32 の PC であり,この PC から他の PC へ感染が広がったことが分かった。この PC は,社外に持ち出して公衆無線 LAN に接続した際,セキュリティ修正プログラムが未適用で,かつ,マルウェア対策ソフトのマルウェア定義ファイルが更新されていない状態だったので,ワーム V に感染したと考えられた。G 社では,PC を社外に持ち出した際の情報漏えい対策を行っていたが,社外でワームに感染した PC を持ち帰るリスクは想定していなかった。
J 主任は,セキュリティインシデントの初動対応として,必要な措置を実施した。また,ワーム V に感染した PC が G 社のネットワーク内に新たに持ち込まれる可能性があるので,NSM センサの IDS 機能のシグネチャを更新して,ワーム V による感染活動のパケットを監視することにした。
次に,再発防止策として,無線 LAN には,社外に持ち出した PC を接続することが多いので,③PC を持ち帰った際に接続可否を判断するためにチェックを行うことにした。さらに,有線 LAN では,④同じ L2SW に接続された PC 同士のワーム感染を防ぐ対策を実施することにした。
d は,同一セグメント内の PC を探索するためにブロードキャストで送るリクエストである。同一セグメントの機器の MAC アドレスを調べる ARP リクエストが該当し,エ(ARP)になる。e は,セキュリティ機関が提供するワーム V のインディケータ情報の形式で,脅威情報を記述する仕様の STIX が該当する。
図3の下線①は,445/TCP へのスキャンに“正常な応答がある場合”である。TCP のコネクション確立は,クライアントが SYN を送り,サーバがポートの開いている場合に SYN と ACK のフラグを立てた応答(SYN+ACK)を返し,クライアントが ACK を返す 3 ウェイハンドシェークで進む。ワーム V は SYN を送るスキャンで,SYN+ACK が返ってきたポートに対して脆弱性を悪用する。
表1は,各 NAPT 変換前 IP アドレスがスキャンを始めた(その IP アドレスが最初に記録された)日時と,17:31 台のスキャンを示す。表2の DHCP サーバログで,その時刻にその IP アドレスをリースされていた PC を探す。リースは記録されるがリリースは記録されないので,ある IP アドレスは次に別の PC へリースされるまで同じ PC のものとみなす。
感染した PC による通信を調べてみると,DHCP によって IP アドレスが変わったので,感染した複数の PC が同じ送信元 IP アドレスを使っている場合がある。感染した複数の PC によって使われた送信元 IP アドレスを解答群から全て選び,記号で答えよ。解答群 ア 192.168.0.4 イ 192.168.0.8 ウ 192.168.0.12 エ 192.168.0.21 オ 192.168.0.32 カ 192.168.0.44 キ 192.168.0.55 ク 192.168.0.112
(1)で求めた感染 PC を,使っていた送信元 IP アドレスごとに整理する。192.168.0.8 は PC101 と PC301,192.168.0.32 は PC321 と PC340,192.168.0.44 は PC277 と PC133 の,それぞれ 2 台の感染 PC が使っている。192.168.0.12 は,感染が確認できるのは PC101 だけで,同じ IP アドレスを使った別の PC(J の PC204,K の PC104)は感染と判断していない。したがって答えはイ(192.168.0.8),オ(192.168.0.32),カ(192.168.0.44)である。
192.168.0.12 の PC101 は 192.168.0.8 とも重なるが,この設問は“同じ IP アドレスを複数の感染 PC が使っている”アドレスを問うているので,ウは選べない。ア(192.168.0.4),エ(192.168.0.21),キ(192.168.0.55),ク(192.168.0.112)は,表1のスキャンのログに現れないので感染 PC の送信元ではない。
解答群から全て選ぶ形式なので,(1)の結果を IP アドレスごとの表にしてから選ぶと漏れにくい。
設問4(1)解答欄2つ
本文中の下線③について,チェックすべき内容を二つ挙げ,それぞれ 30 字以内で述べよ。
〔①〕解答例
セキュリティ修正プログラムが適用されていること
マルウェア定義ファイルが更新されていること
PCがマルウェアに感染していないこと
〔②〕解答例
セキュリティ修正プログラムが適用されていること
マルウェア定義ファイルが更新されていること
PCがマルウェアに感染していないこと
〔備考〕このうち異なる二つを答える(順不同)
解説
本文の根拠
〔セキュリティインシデントの再発防止策〕
この PC は,社外に持ち出して公衆無線 LAN に接続した際,セキュリティ修正プログラムが未適用で,かつ,マルウェア対策ソフトのマルウェア定義ファイルが更新されていない状態だったので,ワーム V に感染したと考えられた。
〔セキュリティインシデントの再発防止策〕
③PC を持ち帰った際に接続可否を判断するためにチェックを行う
感染の原因は,社外に持ち出した PC が,セキュリティ修正プログラム未適用で,マルウェア定義ファイルも更新されていない状態で公衆無線 LAN に接続したことである。再発防止策では,持ち帰った PC を G 社の無線 LAN に接続してよいかを,同じ観点で確かめる。チェックする内容は,セキュリティ修正プログラムが適用されていること,マルウェア定義ファイルが更新されていること,そして社外で既にマルウェアに感染していないこと(解答例はこの 3 つのうち異なる 2 つ)である。
本文の感染要因に沿った 2 つ(修正プログラムの適用,定義ファイルの更新)に,“感染していないこと”を加えた 3 つから 2 つを書けばよい。“社外に持ち出した際の情報漏えい対策”は既に実施済みなので,ここでは持ち帰った PC を接続させる条件を答える。
ワーム V は,感染した PC と同一セグメントの IP アドレス範囲にスキャンをかけて感染を広げる。同じ L2SW に接続された PC 同士は L3SW を介さず直接通信できるので,このスキャンと感染を止めるには,L2SW のレベルで PC 間の通信を分ける必要がある。本文は,L3SW・L2SW が VLAN をサポートしているが G 社では VLAN を設定していないと述べており,VLAN を設定して PC ごとに通信を分離し,PC 間の直接通信を禁止すればよい。
解答例は“VLANを使い,PC間の通信を禁止する。”である。採点講評は,L2SW に接続された PC 同士が直接通信するというワームの特性を踏まえ,VLAN によるセグメントの分離といったネットワーク層(レイヤ)での対策が立案できるようになることを期待するとしている。
25 字以内なので,“VLAN で PC ごとにセグメントを分離する”のように,手段(VLAN)と効果(PC 間の通信の分離・禁止)の 2 つを入れる。“ワームに感染した PC を隔離する”だけでは,感染前の予防にならない。解答例は 20 字である。
FW1 はステートフルパケットインスペクション型で,インターネットと通販システム間の通信は,インターネットから E サーバ及び待機サーバへの HTTPS アクセスとその応答が許可されている。そのほかのインターネットと DMZ 内のサーバ間の通信は,各サーバのサービスに必要なものだけ許可している。
プロキシサーバが中継するのは PC セグメントからインターネットへの通信だけである。
〔脆弱性情報の公開と対応〕
ある日,S 君は,アプリケーションフレームワーク(以下,AF という)のうち,E サーバで使用しているもの(以下,E-AF という)の脆弱性(以下,脆弱性 T という)の情報が,前日に公開されていることを発見し,K リーダに報告した。脆弱性 T の情報を図2に示す。
図2 脆弱性 T の情報(概要)
脆弱性 T の情報が公開されると同時に,E-AF の脆弱性修正プログラム(以下,パッチという)が公開されていたが,K リーダは,パッチを適用するには,通販システムの動作に影響がないことの確認が必要な上,もし何らかの影響がある場合,通販システムを修正するなど時間が掛かることになり,営業上大きな機会損失となることを懸念した。K リーダは,パッチを適用するために通販システムを直ちに停止させるよりも,当面は稼働を継続させつつ,半月後の定期メンテナンス作業時に,影響の確認と必要な修正をできるだけ短時間に実施する方が望ましいと考えた。
〔セキュリティインシデントの発生と対処〕
脆弱性 T の情報を S 君が発見してから 2 日後,E サーバの日次バッチ処理が異常終了するという事象が発生した。S 君が確認したところ,日次バッチプログラムの内容が,見覚えのないスクリプト(以下,スクリプト U という)に書き換えられていた。スクリプト U は,B 社と関係のないサイト Z からプログラムをダウンロードして起動したり,コマンド履歴を参照したりするなどの内容であった。
S 君は,スクリプト U を外部記憶媒体に証拠保全した後,日次バッチプログラムをリカバリした。リカバリ後,日次バッチプログラムを実行し,正常に処理されたことを確認した。さらに,E サーバのほかのバッチプログラムを調査して,改ざんされていないことを確認し,K リーダに状況を報告した。
K リーダは,顧客データが大量に漏えいするなどの重大なセキュリティインシデント(以下,セキュリティインシデントをインシデントという)の可能性もあると考え,専門家による調査を緊急に行うことを経営陣に提案した。K リーダは経営陣の承認を得て,②被害拡大を防止するために必要な措置を S 君に指示するとともに,セキュリティ専門会社にインシデントの調査を依頼した。
〔インシデントの調査〕
依頼を受けたセキュリティ専門会社は,インシデントを調査し,3 日後に調査結果を B 社に報告した。セキュリティ専門会社による調査結果を図3に示す。
図3 セキュリティ専門会社による調査結果(抜粋)
重大な被害は認められなかったものの,脆弱性 T が悪用されて改ざんが行われていたことが明らかになったことから,パッチを適用することにした。パッチを適用し,サービスを再稼働できたのは,インシデント発生から 10 日後だった。
〔リスク軽減策の検討〕
セキュリティ専門会社からは,脆弱性情報が公開されると,その後間もなく攻撃が急増することが多いことから,脆弱性情報が公開された際に迅速に対応できるようにあらかじめ対応を検討しておくべきであるとアドバイスを受けた。そこで,今回のインシデントも踏まえて,K リーダと S 君は AF などを利用しているシステムの脆弱性が公開された際の対応について検討した。次は,このときの S 君と K リーダの会話である。
S 君:AF の脆弱性情報が公開された際は,早期に対応することが望まれます。その点では,暫定的な対策として WAF の導入が有効との話をよく聞くので,調査しました。
K リーダ:どうだったかな。
S 君:脆弱性 T については,情報が公開されてから 1 日以内にシグネチャが提供された WAF がありました。
K リーダ:通販システムではパッチの適用作業に 7 日掛かったが,それより,WAF による対応の方が早かったようだな。しかし,WAF による対応では,通販システムへの影響があるのではないか。
S 君:影響があるので,導入時には遮断はせずにアラートを通知するだけのモニタリングモードを用いて検証します。ただし,このモードでは,アラートが通知された際に検知した通信が b であるかどうかを直ちに確認しなければなりません。もし,b であった場合は,場合によっては E サーバの停止が必要となります。また,b ではなかった場合は,WAF のシグネチャの見直しが必要となります。これら一連の手順を決めておかなければなりません。
K リーダ:分かった。次に,WAF の選定方法について,確認しておこう。
S 君:WAF には,大きく分けると,ソフトウェア型,ハードウェア型,クラウド型の 3 種類があります。いずれもモニタリングモードを実現する機能と攻撃とみなされる通信を遮断する機能があります。さらに,④暗号通信に関する機能が用意されているものがあります。
K リーダ:なるほど。導入はどのようにするのかな。
S 君:ソフトウェア型 WAF の場合は,E サーバに導入します。ハードウェア型 WAF の場合は,図1中の DMZ 内の L2SW と E サーバとの間に設置します。クラウド型 WAF の場合は,サービス事業者がインターネット上で運用しているものを利用します。クラウド型 WAF を利用する場合は,幾つか設定変更が必要です。例えば,図1中の c の設定を変更して,E サーバへのアクセス経路をクラウド型 WAF 経由に変える必要があります。クラウド型 WAF の IP アドレスが変更された場合でも c の設定に影響が出ないように,d レコードを定義して,そのレコードに E サーバの別名としてクラウド型 WAF サービスの事業者が指定する FQDN を記述することが推奨されています。
K リーダは経営陣の承認を得て,②被害拡大を防止するために必要な措置を S 君に指示するとともに,セキュリティ専門会社にインシデントの調査を依頼した。
表1
待機サーバ:・E サーバの購入受付処理が停止するなど通販システムの利用者にサービスが提供できなくなった場合に,サービス停止を告知するための Web サーバである。コールドスタンバイしており,E サーバがサービス提供できなくなった場合に E サーバの代わりにレイヤ 2 スイッチ(以下,L2SW という)に接続される。
インシデントの原因は,E サーバで脆弱性 T が悪用され,日次バッチプログラムがスクリプト U に書き換えられたことで,パッチはまだ適用されていない。調査を依頼している間も E サーバをネットワークにつないだままにすると,攻撃が続いて被害が拡大するおそれがある。そこで,E サーバをネットワークから切り離す。ただし通販システムの利用者へのサービス提供ができなくなるので,表1の待機サーバに差し替えて,サービス停止を告知する。待機サーバはコールドスタンバイで,E サーバが提供できなくなったときに E サーバの代わりに L2SW に接続される構成である。
図3中の下線③について,コマンド履歴に SSH コマンドの接続先 IP アドレスが含まれていた場合,スクリプト U の内容を考慮すると更に調査が必要となる。仮に接続先 IP アドレスとして外部メールサーバが履歴に含まれていた場合,どの機器のログで,何を調査すべきか。調査すべき機器の名称を図1中から選び答えよ。また,調査すべき内容を 30 字以内で,具体的に述べよ。
スクリプト U は,(a)でサイト Z から AP1 などを HTTP でダウンロードして実行し,(b)でコマンド履歴にある接続先へ SSH で接続できればその機器上でスクリプト U を実行する。E サーバのコマンド履歴に外部メールサーバが含まれていた場合は,E サーバから外部メールサーバへ SSH 接続され,外部メールサーバ上でスクリプト U が動いた可能性がある。感染が拡散したかを調べるには,このスクリプト U の動作の痕跡を調べる。
痕跡の調べ方は 3 通りあり(解答例は①,②又は③の組合せ)。①外部メールサーバ(又はログ管理サーバ)のログで,外部メールサーバからサイト Z への接続の有無を確認する。外部メールサーバ上でスクリプト U が動けば(a)のダウンロードを試みるからである。②E サーバ(又はログ管理サーバ)のログで,外部メールサーバへの SSH コマンドの接続の有無を確認する。③FW1(又はログ管理サーバ)のログで,サイト Z との HTTP の通信を確認する。FW1 のログには通信の通過や遮断の記録があり,ログ管理サーバは全 FW・全サーバのログを保存している。機器の名称と調査内容は,同じ番号どうしの組合せで答える。
S 君:影響があるので,導入時には遮断はせずにアラートを通知するだけのモニタリングモードを用いて検証します。
会話
もし,b であった場合は,場合によっては E サーバの停止が必要となります。また,b ではなかった場合は,WAF のシグネチャの見直しが必要となります。
モニタリングモードは遮断せずにアラートを通知するだけなので,アラートが出た通信が本当に攻撃かどうかを確認する必要がある。攻撃であれば,既にその通信が E サーバに届いて被害が出ている(又は出るおそれがある)ので,場合によっては E サーバの停止が必要になる。攻撃ではなかった場合は,WAF が正常な通信を誤検知したことなので,シグネチャの見直しが必要になる。したがって b は“攻撃”である。
本文中の c に入れる適切なサーバ名を図1中から選び答えよ。また,本文中の d に入れる適切なレコードの名称を答えよ。
〔c〕解答例
外部DNSサーバ
〔d〕解答例
CNAME
解説
本文の根拠
会話
例えば,図1中の c の設定を変更して,E サーバへのアクセス経路をクラウド型 WAF 経由に変える必要があります。
会話
クラウド型 WAF の IP アドレスが変更された場合でも c の設定に影響が出ないように,d レコードを定義して,そのレコードに E サーバの別名としてクラウド型 WAF サービスの事業者が指定する FQDN を記述することが推奨されています。
図1
DMZ の L2SW には NTP サーバ,外部メールサーバ,プロキシサーバ,外部 DNS サーバが接続し
クラウド型 WAF は,利用者のアクセスを一度 WAF が受けて検査してから E サーバへ転送する構成なので,E サーバの FQDN の名前解決の結果を,E サーバの IP アドレスからクラウド型 WAF 側へ変える必要がある。インターネットから E サーバ名を引く問合せに答えるのは,図1の DMZ にある外部 DNS サーバである。したがって c は外部 DNS サーバで,その設定を変更して,アクセス経路をクラウド型 WAF 経由にする。
d は,E サーバの別名としてクラウド型 WAF サービスの事業者が指定する FQDN を記述するレコードで,別名を定義する CNAME レコードである。A レコードのように IP アドレスを直接書くと,クラウド型 WAF の IP アドレスが変わったときに外部 DNS サーバの設定を直す必要が生じるが,CNAME なら事業者の指定する FQDN を指しているだけなので,IP アドレスの変更の影響を受けない。
内部 DNS サーバ(サーバセグメント)は社内向けの名前解決を行うので,インターネットからのアクセス経路は変えられない。d で MX や NS を選ぶ誤りも,“別名”という説明から除ける。採点講評も,クラウド型 WAF を使う上での留意点をよく理解してほしかったとしている。