情報処理安全確保支援士 2018年 秋期 午後I 問題

共通の文章

ソフトウェア開発に関する次の記述を読んで,設問ユン3に答えよ。 U社は,IoT機器の開発を行う,従業員数400名の企業である。TIoT機器のソフト ウェアの開発にはCC++言語を使っている。IoT機器に搭載する0Sには,Linuxを 利用してきたが,今後はLinux以外も利用する予定である。これまで製品に大きなト ラブルはなかったが,2020年東京オリンピック・パラリンピックに向けてIoT機器 に関するセキュリティリスクが高まると経営層が判断し,開発におけるセキュリテ イィ対策を強化することになった。そこで,開発部のL部長とX主任がセキュリティ 対策技術を調査した。 〔メモリ破壊攻撃の概要】 メモリ破壊脆弱性は,プログラム実行時に,メモリ上にある制御情報を書き換え ることによって,実行制御を奪うなどのメモリ破壊攻撃に悪用される。メモリ破壊 脆弱性の一種にバッファオーバフロー脆航性がある。 例えば,1に示すプログラムWunがあったとする。Vuln lk,スタックバッファ オーバフロー脆弱性の学習用に作成した,32ビット版Linuxで実行可能なプログラ ムである。2はVuln内の関数fooが呼び出された後のメモリマップである。プロ グラム実行時に,変数bが指し示すデータが不正な場合.,そのデータによって, | 』|が|あ ]に書き換えられると,BK fooの終了時にshellコードへ 処理が騰移する。しかし,①このような居移があっても,データ実行防目機能(以 下,DEPという)が機能していると,攻撃は成功しない。 攻撃者が,DEPを回避するため,図2中のshellコードへ処理を遷移させる代わり に,|5|申の実行可能なコードや[|c|領域にマップされているWun の断片コードを利用するケースがある。例えば,攻撃の際,|』|を |b|関数の先頭アドレスで書き換えて,攻撃者の意図した| b|関数を 呼び出す| q』攻撃もある。 ーッー (省略) 1:int main(int argc,char*argv[]){ 2:char*a,*x; (省略,argvに応じてサイズを確保する。) (省略,ここでa,xがポイントする領域にargvからデータをコピーする。) 3!foo(a,x); (省略,ここでその他の必要な処理をする。) 4:} 5:int foo(char*b,char*c){ 6:char d[100]; (省略) 7:strepy(d,b); 8:if(d[9]==0){ 9:err_out(c); (省略) 10:} (省略) ti return Q; 12:} 13:int err_out(char*errmsg){ 14:char s1[100]; 15:int i=Q; (省略) 16:while((s1[i++]=*errmsgt+)!=’¥0’); 17 fprintf(stderr,"Error:%s¥n”,s1); (省略) 18:return Q; 19:} 図1スタックバッファオーバフロー脆弱性のあるプログラムVuln のーーテテan cS a CS i: OS erroここにaeュードが入っている。)| ②bffff29d上ととshe FRA STV Es Iベースポインタレジスタ保存値ABY DBI @—>bffdfe00 FF [eo BSS領域 データ領域 @—>08048350テキスト領域 注記メモリアドレスは4バイトの16進数表記である。 2関数fooが呼び出された後のメモリマップ zo 3ーー [メモリ破壊攻撃に対する対策技術] 現在,メモリ破壊攻撃に対する対策技術(以下,M対策技術という)が普及して いる。X主任は,DEPを含めた代表的なM対策技術を調査し,表1にまとめた。 表1 NM対策技術の概要 DEP(省略)(省略)プログラムによっては適 用できない、。 SSP(Stackスタック領域でcanaryと呼ばれる値を利用してス|スタックバッフアァ|(省略) Smashingタックバッファオーバフローの有無を確認する技|オーバフローを検 Protection)術知し,抑制する。 ASLR(Address|プログラムの実行時に,データ領域,ヒープ領|(省略)32ビットOS OWS,効 Space Layout域,スタック領域及びライブラリを,ランダムに果が限定的である。 Randomization)マップするOSの技術 PIE(Positionプログラムの実行時に,ASLRが対象とする領域|(省略)プログラムによっては適 Independentに加えて,テキスト領域もランダムにマップする用できない。 Executable)技術 Automaticバッファオーバフロー脆弱性の原因となりうる脆|境界チェックによ|境界チェックにおいて, Fortification弱なライブラリ関数を,コンパイル時に境界チェ|って,オーバフロ|書込み先のサイズが不明 ックを行う安全な関数に置換する技術ーを抑制する。な場合は機能しない。 (M対策技術の動作概要〕 例えば,Vulnのコンパイル時にSSPが適用されていると,関数fooを呼び出す際, 2のベースポインタレジスタ保存値より下位に| e|が挿入される。もしも, |<|]が上書きされた場合は,攻撃と判断し,Vulnの実行を停止する。 なお,Vulnの場合は簡単ではないが,攻撃者が| e|の値を正確に推測して 上書きできてしまうと,| a ]の書換えが可能となり,| d|攻撃を防げ ない。その対策としては,ライブラリ関数のアドレス推定を困難にさせる ーーcs。 しかし,|fj|は[|<|領紅にある実行可能なコードを用いる攻撃に対 しては効果がない。そうした攻撃はPIEによって緩和される。さらに,Wunの場合, Automatic Fortificationによって,ライブラリ関数|g|を安全な関数に置き換 えることで,バッファオーバフローの原因を排除することができる。 [脆弱性対策強化 L BRL X主任が表1の技術を確認したところ,表1の備考欄の指摘以外にも② ーー4ーー Automatic Fortificationではバッファオーバフローの原因を排除できないケースがある と分かった。 L部長は次に,表1の技術を適用することによる影響を確認した。その結果,次の ことが分かった。例えば,ソースコードに脆弱性があっても,SSPを適用してコンパ イルしていると,メモリ破壊攻撃が成立しないが,そのソースコードを③別の開発 環境でコンパイルすると問題となる場合があることが分かった。 これらについては,U社内でコーディングスタンダードを定め,それによって対処 することにした。検討の結果,U社は表1の技術を全て採用することにした。

共通の文章

セキュリティインシデント対応に関する次の記述を読んで,設問1ー4に答えよ。 G社は,従業員数1.200名の製造業者であり,本社と四つの工場がある。工場には, 無線LANアクセスポイント(以下,APという)を導入している。本社及び各工場 には,レイヤ3スイッチ(以下,L3SWという)RO,ネットワークセキュリティモ ニタリング(以下,NSMという)のセンサが設置されている。NSMセンサには,シ グネチャ型のIDS機能に加えて,ネットワークフロー情報(以下,NF情報という) を記録する機能がある。NF情報は,流れている全てのパケットについて,ヘッダ情 報を参照し,“コネクション開始日時,送信元IPアドレス,宛先TPアドレス,送信 元ポート,宛先ポート,プロトコル,コネクションステータス,コネクション時間, 送信バイト数,受信バイト数”をコネクション上単位でレコード化したものである。 NF情報は,NSMセンサから管理ネットワークを通じてNSM管理サーバに送信され, 統合管理されている。G社のネットワーク構成を図1に示す。 L2SW:レイヤ2スイッチ FW:ファイアウォールこインターネットン [ew[I Sin NN 0.100.024!|| 10.10.0.0/16 iLec}~-[ec]|! ~ec tLecdit=mis 1 oma||Ed サーバ」Le Lec JL PC][ce」-Le」_|工場 注記管理ネットワークの記載は省略している。 図1 G社のネットワーク構成 L3SWには,スイッチの特定の物理ポートを流れるパケットを,ミラーポートとい う別の物理ポートにミラーリングする機能があり,ネットワーク障害発生時にパケ ットを取得する用途でも使われている。L3SWでは,FWに接続している1Gビット グ秒(以下,ビットノ秒をbpsという)の物理ポートを流れるインとアウトのパケッ トを,NSMセンサに接続している10Gbpsのミラーポートにミラーリングしている。 =gu ミラーポートに流れる通信量は,全二重1Cbpsの1ポートの送受信をミラーリング する場合最大|。|bpsとなる。L3SW及びL2SWは,VLANをサポートし ている機器であるが,G社ではVLANの設定はしていない。VLANを設定する場合, L3SWでは,IEEE 802.1Qの|bp|を付与した状態でミラーリングできるので, 障害が発生しているVLANを識別できる。ミラーポートを使用せずにパケットを取 得する方法として,ネットワークを使用する方法もある。 [セキュリティインシデントの発生]〕 ある日,セキュリティ管理部のJ主任にNSM管理サーバからアラートメールが届 We,JERI,部下のM君とともに調査を開始した。NSM管理サーバのダッシュ ボード画面を確認したところ,IDS機能のアラートは発生していなかったが,通信量 が普段よりも2倍以上増えていたのでアラートメールが送られたことが分かった。 そこで,NSM管理サーバを使って,通信量が増えている原因を調べることにした。 まず,直近1時間のコネクション件数を表示してみた。表示内容を図2に示す。 送信元IPアドレス別の件数(Top10)宛先IPアドレス別の件数(Top10) a ee ee 宛先ポート別の件数(Top10)TCPステータス別の件数(Top10) 宛先ポート SVNに対して応答なし |SvNなしACKだけ|845396| ee a se ee 2 NSM管理サーバのダッシュボートド画面(直近1時間のコネクション件数) 宛先ポート別の件数で,445/TCPのコネクション件数が普段と比べて非常に多かっ た。JHE,セキュリティ機関から,ワームVに関する注意喚起を受け取っていた ーー7ーー ことを思い出した。ワームVに関する注意喚起を図3に示す。 .ワームVik,Windowsの脆弱性を悪用し,ファイル共有で使われる445/TCPのポートを経由 して感染を広めるものであり,複数の組織でネットワークに障害が発生している。 ・ワームVik,次の2種類のIPアドレス範囲に対して,並行して445/TCPのポートをスキャン し,①正常な応答がある場合に,脆弱性を悪用して感染を試みる。 (a)感染したPCと同一セグメントの徹囲 (b)1.1.1.1から223.255.255.255の範囲 スキャンでは,各IPアドレスに1パケットずつ接続要求を送信する。(a)のスキャンでは,IP アドレス範囲の最後までスキャンが完了した場合,5分間待機した後,IPアドレス範囲の先頭 からスキャンを繰り返す。()のスキャンは,IPアドレス範囲の最後までスキャンが完了した 場合,スキャンを終了する。 図3ワームVに関する注意喚起 ]主任はワームVが原因であると仮定して分析を進めた。送信元IPアドレス別の 件数では,10.100.130.1の件数が普段と比較して非常に多かった。宛先アドレス別 の件数では,ファイルサーバや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サーバ機能で設定していることから,APO 通信ログ及びDHCPサーバ機能のログ(LAF,DHCPサーバログという)を調査す ることにした。 DHCPサーバ機能では,IPアドレスのリース期間を1時間に設定しており,プー ーー8 co ルしているIPアドレス範囲から適宜リースする。APでの通信ログのうち宛先IPア ドレスがG社の利用していないIPアドレスであり,かつ,宛先ポートが445/TCPの ものを表1に示す。表2に10月28日のAPのDHCPサーバログを示す。M Ald, 表1と表2を基に,445/TCPのポートをスキャンしているPCを特定した。 表1 APの通信ログ 日時NAPT変換前NAPT変換後宛先IPアドレス宛先 IPアドレスIPアドレスポート 10/28 14:25:02|192.168.0.32 10.100.130.1 10/28 14:26:45?10.100.130.1 192,168.04 10/28 16:51:50"192.168.0.12 10.100.130.1 10/28 17:31:22 192.168.0.44 10.100.130.1 10/28 17:31:23 192.168.0.32 10.100.130.1 10/28 17:31:25 192.168.0.12 10.100.130.1 10/28 17:31:25 192.168.0.8 1.100.1.201 注記省略された期間のログにおいて,NAPT変換前IPアドレスは,本表に記載されているPTE レスだけが記録されている。 注りそれぞれのNAPT変換前IPアドレスが最初に記録された日時である。 表2 APのDHCPサーバログ NMACアドレス 10/28 10:45:38 10/28 10:46:49 192.168.0.32|P|PC301 10/28 10:46:53 192.168.0.21 10/28 10:47:11 192.168.0.44 PC277 10/28 10:48:20 10/28 10:49:03 192.168.0.55 PRC PC298 10/28 14:24:50 192.168.0.32 10/28 16:51:13 10/28 16:52:37 192.168.0.32 10/28 16:54:29 192.168.0.8 IP|PEC3Q1 10/28 22:53:45 192.168.0.8 PC333 10/28 22:55:04 10/28 22:55:32 192.168.0.55 .|IR|PC298 10/28 22:56:33 192.168.0.4 10/28 22:57:58 192.168.0.44 10/28 22:58:17 注記1 IPアドレスのリースは記録されているが,IPアドレスのリリースは記録されていない。 注記2本表ではMACアドレスを英字1字で表記している。 —9テー 〔セキュリティインシデントの再発防止策] M君は,無線LANのパケットをキャプチャしたところ,6台のPCが, ||リクエストをブロードキャストで送信して,同一セグメント内のPCを 探索していることを確認した。 M君は,無線LANに接続しているPCのうち6台がワームVに感染している可能 性を主任に報告した。J EM,感染有無を確認するよう指示した。セキュリティ 機関からは,ワームVのインディケータ情報が| c|形式で提供されていた。 そこでM君がそのインディケータ情報を使ってファイルを検索して,感染の有無を 確認したところ,6台ともワームYに感染していることが分かった。 通信ログ及びワームVのファイルの作成日時から,最初に感染したのは,IPアド レスが192.168.0.32のPC CH),このPCから他のPCへ感染が広がったことが分 かった。このPCは,社外に持ち出して公衆無線LANに接続した際,セキュリティ 修正プログラムが未適用で,PO,マルウェア対策ソフトのマルウェア定義ファイ ルが更新されていない状態だったので,ワームVに感染したと考えられた。G HT は,PCを社外に持ち出した際の情報漏えい対策を行っていたが,社外でワームに感 染したPCを持ち帰るリスクは想定していなかった。 J ERM,セキュリティインシデントの初動対応として,必要な措置を実施した。 また,ワームVに感染したPCがG社のネットワーク内に新たに持ち込まれる可能 性があるので,NSMセンサのTDS機能のシグネチャを更新して,ワームVによる感 染活動のパケットを監視することにした。 次に,再発防止策として,無線LANには,社外に持ち出したPCを接続すること が多いので,OPCを持ち帰った際に接続可否を判断するためにチェックを行うこと にした。さらに,有線LANでは,③④同じL2SWに接続されたPC AMtLOTI—-ARH を防ぐ対策を実施することにした。 主任は,調査結果を上司に報告し,再発防止策を実施して,セキュリティインシ デントの対応を完了した。 ー10一

共通の文章

ソフトウェアの脆弱性対策に関する次の記述を読んで,設問1こ5に答えよ。 B社は,従業員数500名の食品販売会社であり,インターネットを介して消費者向 けに食品を通信販売している。 通信販売で使用するシステム(以下,通販システムという)の運用,保守は,Be のKリーダを中心に,S君ほか3名と協力会社の従業員5名の計10名で行っている。 通販システムを含むB社情報システムのサーバの概要を表1に,構成を図1に示す。 表1 B社情報システムのサーバの概要(抜粋) Eサーバ・通販システムの購入受付処理を行うWebサーバである。また,通販システムのバ ッチ処理として購入集計処理も行っている。 待機サーバ-Eサーバの購入受付処理が停止するなど通販システムの利用者にサービスが提供 できなくなった場合に,サービス停止を告知するためのWebサーバである。コー ルドスタンバイしており,Eサーバがサービス提供できなくなった場合にEサー バの代わりにレイヤ2スイッチ(以下,L2SWという)に接続される。 ログ管理サーバ・B社情報システム中の全ファイアウォール(以下,ファイアウォールをFW EW う)及び全サーバのログをsyslogで受信し保存する。 ・FW1及びFW2のログには,通信の通過や遮断に関する記録がある。 ・各サーバのログには,OS上で実行されるSSHなどのコマンド履歴,アプリケー ションやミドルウェアのイベント記録がある。 ・Webサーバ及びプロキシサーバのログには,送信元及び宛先のIPアドレス, HTTPリクエストの内容,データ転送量などが含まれている。 ・ログ保全機能があり,それによって,保存したログが改ざんされていないことを 証明できる。 (ンターネッぴツL3SW:レイヤ3スイッチDBサーバ:データベースサーバ czZP23 edhe[ 1取っぁiT NTP|外部メール|。: !'1 6サーバ ||プロォッ|部pns|Be| HL3SWI|サーバ|]|サーバDMZ! eee 2 oy ログ管理内部DNS ESニーcrisis間間間 注記各和機器からログ管理サーバへのログの送信は管理ネットワークを使って行われる。管理ネッ トワークの記載は省略している。 図1 B社情報システムの構成 通販システムは,Eサーバ,待機サーバ,FW2及びDBサーバから構成される。E サーバの購入受付処理は,インターネットからHTTP over TLS(LAF,HTTPSとい う)でアクセスされる。購入集計処理は,バッチプログラムで実行される。BASF 前2時開始の日次,毎週土曜日の午前3時開始の週次,毎月1日午前4時開始の月 次のバッチプログラムがあり,それぞれ1時間以内で処理が完了する。 ログ管理サーバに保存されたログからイベントの発生順序を正しく追跡できるよ うに,①ログに書かれる各FW及び各サーバの時刻を整合させている。 FW1はステートフルパケットインスペクション型で。インターネットと通販シス テム間の通信は,インターネットからEサーバ及び待機サーバへのHTTPSアクセス とその応答が許可されている。そのほかのインターネットとDMZ内のサーバ間の通 信は,各サーバのサービスに必要なものだけ許可している。 プロキシサーバが中継するのはPCセグメントからインターネットへの通信だけで ある。 [脆弱性情報の公開と対応〕 HSH,S Blk,アプリケーションフレームワーク(以下,AFという)のうち, Eサーバで使用しているもの(以下,EAFという)の脆弱性(以下,脆弱性Tとい う)の情報が,前日に公開されていることを発見し,Kリーダに報告した。脆弱性T の情報を図2に示す。 ーー にed い。 ートからHTTPリクエストのContent-Typeヘッダフィールドに攻撃コードが挿入されることに よって任意のOSコマンドを実行される。 =”|。|は,基本評価基準,現状評価基準,環境評価基準の三つの基準で脆弱性の深刻さ を評価するシステムである。 2脆弱性Tの情報(概要) 脆弱性Tの情報が公開されると同時に,E-AFの脆弱性修正プログラム(以下,パ ッチという)が公開されていたが,Kリーダは,パッチを適用するには,通販システ ムの動作に影響がないことの確認が必要な上,もし何らかの影響がある場合,通販 ー13一 システムを修正するなど時間が掛かることになり,営業上大きな機会損失となるこ とを懸念した。Kリーダは,パッチを適用するために通販システムを直ちに停止させ るよりも,当面は稼働を継続させつつ,半月後の定期メンテナンス作業時に,影響 の確認と必要な修正をできるだけ短時間に実施する方が望まほしいと考えた。 [セキュリティインシデントの発生と対処 脆弱性Tの情報をS君が発見してから2日後,EEサーバの日次バッチ処理が異常 終了するという事象が発生した。S君が確認したところ,日次バッチプログラムの内 容が,見覚えのないスクリプト(以下,スクリプトUという)に書き換えられてい た。スクリプトUは,B社と関係のないサイトZからプログラムをダウンロードし て起動したり,コマンド履歴を参照したりするなどの内容であった。 S Blk,スクリプトUを外部記憶媒体に証拠保全した後,日次バッチプログラム をリカバリした。リカバリ後,日次バッチプログラムを実行し,正常に処理された ことを確認した。さらに,Eサーバのほかのバッチプログラムを調査して,改ざんさ れていないことを確認し,KKリーダに状況を報告した。 Kリーダは,顧客データが大量に漏えいするなどの重大なセキュリティインシデン ト(以下,セキュリティインシデントをインシデントという)の可能性もあると考 A,専門家による調査を緊急に行うことを経営陣に提案した。Kリーダは経営陣の承 認を得て,②被害拡大を防止するために必要な措置をS君に指示するとともに,セ キュリティ専門会社にインシデントの調査を依頼した。 【インシデントの調査 依頼を受けたセキュリティ専門会社は,インシデントを調査し,3日後に調査結果 をB社に報告した。セキュリティ専門会社による調査結果を図3に示す。 ー14一 調査によって,次が判明した。 1)脆弱性Tを悪用した攻撃の痕跡が見つかった。 (2)スクリプトUは,次の二つを並列で実行するものであったことから,今回の攻撃の主たる目的 は,仮想通貨採掘用プログラム(以下,AP1という)を実行することであったと考えられる。 a)AP1,及びAP1を動作させるのに必要な複数のライブラリをサイトZからHTTPを使ってダ ウンロードし,AP1を実行する。 b)コマンド履歴から,SSHコマンドの接続先IPアドレスを全て抽出する。IPアドレスが抽出 された場合は,IPアドレスで示される各機器に対し,SSHコマンドで接続を試行し,成功す るとその機器上でスクリプトUを実行する。IPアドレスが抽出されなかった場合は,何もし ない。 (3)FW1のログを調査した結果,上記(2)J9)でのダウンロードは,FW1Iでブロックされていた。ま た,B社情報システムのどの機器にもAP1は見つからなかった。 (4)⑧Eサーバのコマンド履歴には,SSHコマンドの接続先IFアドレスが含まれておらず,スク リプトUによるほかの機器への接続はなかったと考えられる。このことを確認するために,ほか の機器へのアクセス記録を調査したところ不審おなものはなかった。 (5)顧客データが大量に漏えいした可能性は低い。 図3セキュリティ専門会社による調査結果(抜粋) 重大な被害は認められなかったものの,脆弱性Tが悪用されて改ざんが行われて いたことが明らかになったことから,パッチを適用することにした。パッチを適用 し,サービスを再稼働できたのは,インシデント発生から10日後だった。 [リスク軽減策の検討] セキュリティ専門会社からは,脆弱性情報が公開されると,その後間もなく攻撃 が急増することが多いことから,脆弱性情報が公開された際に迅速に対応できるよ うにあらかじめ対応を検討しておくべきであるとアドバイスを受けた。そこで,今 回のインシデントも踏まえて,KリーダとS君はAFなどを利用しているシステムの 脆弱性が公開された際の対応について検討した。次は,このときのS君とKリーダ の会話である。 S君:AFの脆弱性情報が公開された際は,早期に対応することが望まれま す。その点では,暫定的な対策としてWAFの導入が有効との話をよく 聞くので,調査しました。 KKリーダ:どうだったかな。 Sa:脆弱性Tについては,情報が公開されてから1日以内にシグネチャが提 供されたWAFがありました。 Kリーダ:通販システムではパッチの適用作業に7日掛かったが,それより,WAF による対応の方が早かったようだな。しかし,WAFによる対応では,通 販システムへの影響があるのではないか。 SA:影響があるので,導入時には遮断はせずにアラートを通知するだけのモ ニタリングモードを用いて検証します。ただし,このモードでは,アラ ートが通知された際に検知した通信が|b|)であぁるかどうかを直 ちに確認しなければなりません。もし,| b|]であぁった場合は,場 合によってはEサーバの停止が必要となります。また,|b|で はなかった場合は,WAFのシグネチャの見直しが必要となります。これ ら一連の手順を決めておかなければなりません。 Kリーダ:分かった。次に,WAFの選定方法について,確認しておこう。 S君”:WAFには,大きく分けると,ソフトウェア型,ハードウェア型,クラウ ド型の3種類があります。いずれもモニタリングモードを実現する機能 と攻撃とみなされる通信を遮断する機能があります。さらに,OM Hs 信に関する機能が用意されているものがあります。 Kリーダ:なるほど。導入はどのようにするのかな。 SH”:ソフトウェア型WAFの場合は,Eサーバに導入します。ハードウェア 型WAFの場合は,図1中のDMZ内のL2SWとEサーバとの間に設軒 します。クラウド型WAFの場合は,サービス事業者がインターネット 上で運用しているものを利用します。クラウド型WAFを利用する場合 は,幾つか設定変更が必要です。例えば,図1中の|c|の設定 を変更して,Eサーバへのアクセス経路をクラウド型WAF経由に変え る必要があります。クラウド型WAFのIPアドレスが変更された場合で も|c ]の設定に影響が出ないように,|q|レコードを定 義して,そのレコードにEサーバの別名としてクラウド型WAFサービ スの事業者が指定するFQDNを記述することが推奨されています。 Kリーダ:なるほど。当社にはどの種類が適しているか調査してくれ。 SH。:分かりました。 ~16一 調査の後,B社では,WAFを選定し,導入した。以降,攻撃を数多く受けたが, WAFが遮断し,EEサーバへの侵入は起きていない。