ITサービスマネージャ 2016年 秋期 午後I 問題

共通の文章

サービス継続及び可用性管理に関する次の記述を読んで,設問1ー3に答えよ。 R社は,中堅の製薬会社である。R社の本社は関東地方のC市にあり,工場,関 東支店及びサーバ室(全て同じ建物内にある)は市に隣接するD市に,近畿支店 ,は近畿地方のE市にある。両支店には倉庫が併設されており,関東支店は東日本地 域の注文受付と入出庫,近畿支店は西日本地域の注文受付と入出庫を担当している。 R社の製造部の部員は,工場に勤務して製品の製造記録及び倉庫への輸送記録を端 末から生産管理システムに入力している。R社の販売部の部員は,関東支店又は近畿 支店に勤務して注文の入力を行っている。顧客からの注文は,両支店で毎日8時か ら19時までの間,電話又はファックスで受け付け,端末から販売管理システムに入 力している。また,端末から製品の入出庫を販売管理システムに入力している。 [システム全体の構成 R社のシステム全体の構成を図1に,システム全体の概要を表1に示す。 GONE|生産管理システム1・ [{se Han) ||生産管理>1 ーーにーー|rsw||販売管理システム Let Le) 売9| ーーCapen)au 市|aE[cw| しL3SW:レイヤ3スイッチ 図1 R社のシステム全体の構成 表1 R社のシステム全体の概要 ィ工場と同じ建物内のサーバ室には,製品の製造から倉庫への輸送までを管理する生産管理システ ム,及び顧客との取引と製品の入出庫を管理する販売管理システムが設置されている。 4生産管理システムのストレージには製品の製造及び倉庫への輸送の記録ファイルが格納され,販売 管理システムのストレージには受注ファイル及び在庫ファイルが格納されている。 ーーの3でここ 〔両システムの運用〕 R社の情報システム部員は,本社に勤務して両システムを運用している。両システ ALY,毎日4時から23時までオンライン処理を行う。23時から24時までは,テ ープ媒体にファイルのフルバックアップを取得し,サーバ室に保管している。 システムのオペレーションは,販売管理システム専任のAチームと,生産管理シ ステム専任のBチームの2チームに分かれている。部員は自身が担当するシステム について教育を受け,オペレーションを実施している。 なお,部員は自身が担当するシステム以外のオペレーションは実施していない。 両チームともシフト体制を組み,それぞれ1シフト1名でオペレーションを実施し TUS, 〔事業継続計画の策定] 関東地方に震度6弱レベルの地震が発生した場合の,R社の建物が損傷を受けるリ スクについて調査した。その結果は次のとおりである。 (1)C市にある本社の建物は耐震性能が高く,震度6弱レベルの地震で損傷を受け る確率が低い。 (2)D市にあるR社の敷地の地盤は軟弱であって,R社の建物(工場,関東支店, 倉庫及びサーバ室)は,震度6弱レベルの地震で損傷を受ける確率が高い。 (3)E市にある近畿支店の建物及び倉庫は,損傷を受ける確率が低い。 この調査結果を受け,R社では情報システム部も参加する検討チームを設置して, 事業継続計画(DK,BCPという)の策定に着手した。BCPの概要を表2に示す。 表2 BCPの概要(抜粋) = 近畿支店は在庫を活用して,注文受付と出庫を通常どおり継続する。 移転までの間に被災した場合は,一時的に工場の操業及び近畿支店への輸送を停止する。 [災害対策用システムの検討】 工場,関東支店及びサーバ室の建物の被災によって両システムが停止することが 想定された。一方で,近畿支店の販売活動は可能なので,販売管理システムのRTO (目標復旧時間)は被災時点から120分,生産管理システムのRTOは被災時点から 5日と設定した。ただし,RPO(目標復旧時点)は関係部署との調整が必要なので, 継続して検討することになった。 RTOの設定を受け,ITサービスマネージャであるG氏は,被災時の技術的対策の 6検討を始めた。検討した結果,現在稼働中の販売管理システムと同一機能で,被災 時だけ使用する災害対策用システム(以下,災対システムという)を構築すること になった。概要は次のとおりである。 ・炎対システムと本社との間に専用線を新規に敷設し,本社の運用端末から遠隔 操作を行う。 ・クラウドサービスの活用も検討する。現在稼働中の販売管理システムとの互換 性を考慮し,クラウド事業者が提供するPaaSを利用する。PaaSは,サービスの 利用量に応じた料金体系であり,システム環境の構築だけであれば少額の費用 で利用できる。 G氏はこれらの検討結果を踏まえ,災対システムの方式案を表3のようにまとめた。 表3災対システムの方式案 ・炎対システムを近畿支店に構築し,被災時はフルバックアップか sae?|RPO| らデータを復元する。被災当日の Kl|・フルバックアップの取得先を,現在のテープ鑑体から,近畿支店|13||』|]オンライン に新設するストレージに変更する。取得対象データと取得時期は開始時点 現在のままとする。 ・災対システムはクラウドサービスを使用して構築し,現在稼働中。 ・災対システムはクラウドサービスを使用して構築し,被災時はフ eg WO DT ETE GE—AEE Bs;67 ne[>] ・フルバックアップの取得方式を,データ保管サービス3の利用に時点 変更する。取得対象データと取得時期は現在のままとする。 SE”MAAR(TCO)のことである。数値は,案2を10とした場合の相対的な倍率である。 2インシデントの発生(被災時点)からサービスが再開されるまでの所要時間である。被災時点から災対シス テムの起動開始までには,被災状況の確認作業などが必要であり,所要時間は30分である。また,その後の作 業内容は案ごとに異なるが,必要となる場合には,災対システムの起動作業に30分,フルバックアップからの データ復元に30分,システムの正常稼働の確認に30分掛かる。 9クラウドサービスの利用者が指定するデータを,利用者が指定する時期に複写し,クラウド事業者のデータ センタに保管するクラウドサービスのことである。 案1で,RPOを被災当日のオンライン開始時点と設定した場合,(ア)情報システ ーー5 ai ム部が販売部とあらかじめ合意すべき内容がある。 G氏は。案1ご3について検討した結果,案3を推奨案として検討チームに提案し, 案3に決定した。 復旧手順の検討及びクラウドサービスの選定〕 案3の決定を受けて,G氏は,販売管理システムの復旧手順の検討と,使用するク ラウドサービスの選定に着手した。 ①)復旧手順の検討 ①災対システムは,平常時は停止状態としておき,被災時に運用端末から起動 する。被災状況の確認作業などに30分,その後,災対システムの起動作業に30 分,さらに,フルバックアップからのデータ復元に30分掛かる。データ復元の 完了後,システムの正常稼働の確認に30分掛かるが,RTO内に復旧できる。 ②ストレージは,平常時は最低限の容量だけを確保しておき,被災時点のデー タ量に応じて,災対システムの起動作業と並行して容量の追加を行う。 (2)災対システム稼働中にインシデントが発生した場合の対応 災対システム稼働中にインシデントが発生し,災対システムが停止した場合, クラウド事業者がインシデントの解決及び災対システムの起動を実施する。その 後,R社でフルバックアップからのデータ復元及びシステムの正常稼働の確認を実 施し,サービスを再開する。 3)クラウドサービスの選定 G氏は,災対システムの候補として,表4の4社のクラウドサービスを選んだ。 表4 G氏が検討したクラウドサービス _クラウドデータセンタストレージ容量インシデントが発生した場合 事業者の所在地”追加の所要時間9クラウド事業者が行う作業所要時間? |」|ee|amen[ome LO rep se|emis[soa[OH sue[wes[orm|6@分5 Pa|W衝|ramus[om[OR 注りサービスを提供しているクラウド事業者のデータセンタの所在地 2利用者がクラウド事業者に申込みを行ってから,利用可能となるまでの時間 9災対システム稼働中にPaaSでインシデントが発生し,災対システムが停止した場合,クラウド事業者は イィインシデントの解決を行い,災対システムを起動する。作業所要時間とは,インシデントの発生から解決ま での時間であり,災対システムを起動する時間は含まない。 ーー6ーー G氏は,各社のサービスを比較し,次の条件に合致するクラウドサービスを提供す る1社を選定した。 ・事業継続に関する要求事項として,サービスを提供するデータセンタが,RHO サーバ室と同じ地方にないこと ・災対システム稼働中にインシデントが発生し,災対システムが停止した場合, インシデントの発生から120分以内にサービスが再開可能なこと | [炎対システムの構築〕 G氏は変更計画として,災対システムの構築計画,災対システムに関連する既存シ ステムの稼働環境の修正計画,及び既存システムのオペレーションマニュアルの修 正計画をまとめた。変更計画はR社で規定する変更管理プロセスに従って承認され, 炎対システムが構築された。災対システムの構築が完了した後,G氏は災害対策用マ ニュアル(以下,災対マニュアルという)も作成した。 当初,災対システムと本社との間は,1本の専用線で接続する予定であった。しか し,災対システムの構築完了後,G氏は予備の専用線を追加して,可用性を向上させ ることにした。この場合,災対システムの正常稼働の確認で予備の専用線の切替え 作業と疎通確認作業が増えるが,想定している30分の範囲内で作業可能と判断した。 予備の専用線の追加は,変更管理プロセスに従って承認された後,予備の専用線の 敷設作業が実施された。 【和炎害復旧訓練の準備・実施] 炎対システムの構築完了後,G氏は和災害復旧訓練(以下,訓練という)の実施を計 画した。訓練には,実施日時に勤務中の販売管理システム専任のAチームのオペレ ータと運用責任者が参加し,実機を使用して災対システムへの切替えなどを行う。 G氏は訓練の計画書を作成し,参加者向け会議で訓練計画及び災対マニュアルにつ いて説明を行った。会議において,“被災時には,勤務中のAチームのオペレータが 何らかの理由で作業を行えなくなり,非番のオペレータも招集できないという不測 の事態も考えられる。RTO内に復旧するために,こうしたリスクへの備えも必要で HS,”という指摘を受け,GRA)対策を検討した。 =i= 訓練は予定した日時に実施された。訓練終了後,訓練実施者の会議において, “(ウ)災対マニュアルの復旧手順では,予備の専用線の疎通確認が漏れていたので, 作業に手間取ってしまった。"という報告があった。

共通の文章

キャパシティ管理に関する次の記述を読んで,設問1ー3に答えよ。 F社は,通信事業者である。F社の情報システム部門では,F社の願客が利用する インターネット受付サービス,代理店が利用する代理店サービス,及び社員が利用 する顧客管理サービスを運用している。これらのサービスは社の営業部門が統括 している。 [サービスの概要]〕 インターネット受付サービス及び代理店サービスは,オンライン処理形態で提供 されている。インターネット受付サービスはインターネット受付システムで,代理 店サービスは代理店システムで処理されている。インターネット受付サービスのサ ービス提供時間帯は24時間365日で,代理店サービスは平日の8て21時である。 顧客管理サービスは,契約管理,課金管理,問合せ管理,請求・入金,受注分析 の五つのサービスで構成され,顧客管理システムで処理されている。 ・契約管理サービス,課金管理サービス及び問合せ管理サービスは,オンライン でサービスを行っている。サービス提供時間帯は,平日の8てこ21時である。 ・請求・入金サービスは毎週1回提供されるサービスである。毎週日曜日の22時 に起動する顧客管理システムのバッチ処理として運用されている。 ・受注分析サービスは毎日1回提供されるサービスである。請求・入金サービス のバッチ処理との競合を避けるために9時以降に処理を開始する必要があり, 毎日9時に起動する顧客管理システムのバッチ処理として運用されている。 各サービスのSLA項目(抜粋)を,表1に示す。 表1各サービスのSLA項目(抜粋) eae ha 注りオンライン応答時間とは,サービスを提供するシステムのコンポーネントである業務サーバが要求 を受け付けてから応答するまでの時間のことである。 —9ーー F社のシステム構成を図1に示す。 FAA|」代理店|」インターネット| 1システム」システム」1受付システム|: |i|! ||||ヽ_ヽ=1 ||凍客管理||代理店||rem i Lod eal サーバパryサーバ1ュサーパバ32 iF eee pice aig 1|FW] トーニーナー!ミニーーー」ェーーーー| Pd FW:ファイアウォール 注記代理店システムでは,代理店からインターネットを経由して処理要求があると負荷分散サーバ1で振り 分け処理をしている。負荷分散サーバ1は,同じ処理能力をもった代理店サーバ1又は代理店サーバ2の どちらかの業務サーバに,負荷が均等になるように処理要求を振り分ける。負荷分散サーバ1では,ソフ トウェアで負荷分散機能を実行している。インターネット受付システムも,負荷分散サーバ2を用いて同 様に負荷分散を行っている。 図1 F社のシステム構成 なお,受注分析サービスは,F社でサービス提供を開始した当初は,1時間で処理 を完了していたが,処理対象データの増加に伴って処理時間が長くなり,現在では 処理完了までに1時間30分掛かっている。 [キャパシティ計画の策定〕 情報システム部門のL氏は,ITサービスマネージャとしてキャパシティ管理を担 当している。L氏は,F社の規程に従ってキャパシティ計画を次のとおり策定した。 ・営業部門から入手した,現在及び将来のサービスに対する直要とサービス利用 者の見通しから,データ処理量の増加を見積もる。 ・営業部門と合意したオンライン応答時間などの要求事項,データ処理量を基に, ハードウェア,ソフトウェアなどのコンポーネントのキャパシティ及び構成を 計画する。 ・コンポーネントのキャパシティを増強するための方式及び構成を計画する。 なお,F社の規程では,サービス開始後は,実際のオンライン応答時間,キャパシ ティのニーズなどに基づいて,"毎年,キャパシティ計画を変更する"”としている。 [サービス運用段階のキャパシティ管理] L氏は,サービス運用段階のキャパシティ管理として次の活動を実施している。 (1)キャパシティ監視 ①サービスがオンライン処理形態の場合は,サーバのCPU使用率,サーバの処 理件数及びオンライン応答時間を監視項目とする。これらの監視項目は,監視 システムによって1分間隔で測定し,監視データとして収集される。一方,サ ービスがバッチ処理形態の場合は,サーバのCPU使用率及びバッチ処理完了時 刻を監視項目とする。 なお,LAN及び社内ネットワークには十分なキャパシティがあり,サービス 提供に支障がないので,監視項目を設定していない。 ②オンライン応答時間の測定値がが.あらかじめ決められたしきい値を超えた場 合は,監視アステムがインシデントとして検知する。しきい値には,各サービ スのSLA項目の目標値を設定しており,キャパシティに関わるインシデントが 発生した場合は,直ちに監視システムからL氏に通知される。 (2)分析及び対策 ①監視システムによって収集した監視データについて,各サービスのSLA項目 の目標値の達成に影響を与える可能性がないか,キャパシティ計画どおりにコ ンポーネントのキャパシティが使われているかなどの視点で分析する。 ②キャパシティ不足が懸念される場合には,キャパシティの増強計画を作成す Boキャパシティの増強は,サービス提供時間以外の計画停止時間帯に実施す る。 [顧客管理サービスのインシデントとその対策〕 ある月曜日の10時に,顧客管理サービスにおいてオンライン応答時間がしきい値 を超えるというインシデントが発生し,監視システムからL氏に通知があった。そ の後,11時までの間に同二インシデントが数回発生した。また,営業部門からサー ビスデスクに,“サービスの応答が遅くなっている”とのクレームが寄せられた。L 氏が監視データを調査したところ,10~11時の時間帯で顧客管理サーバのCPU使用 率が90て100%で推移していたことが判明した。その調査結果を表2に示す。 ー11一 表2顧客管理サーバのCPU使用率の調査結果 [.SESESSeee 注り1分間隔で測定された結果に基づく,1時間の平均値 |-sEEESSSS== 契約管理サービス[oT 20|5|2| |諸求・入金サービス[oo|0|oO| o| 受注分析サービス。|60|4|9o|0o| 願客管理サービス全体 顧客管理サーバの利用状況を調査したところ,1日のオンライン処理件数のうち約 2割が10ご11時のピーク時間帯に集中していた。L氏は,根本対策として,MEP 理サーバのキャパシティの増強が必要と判断した。しかし,増強には時間が掛かる OC,暫定対策を策定し,営業部門と協議することにした。 [代理店サービスのオンライン応答時間の悪化 ある日の22時に,負荷分散サーバ1の機器障害が発生した。機器障害の発生時刻 はサービス提供時間帯ではなかったので,サービス利用者に影響しなかったが,翌 日のサービス提供開始までには回復する必要があった。情報システム部門でサーバ 運用を担当しているT氏は,負荷分散サーバ1の交換作業が必要と判断し,次の手 順で対応した。 ・変更管理プロセスに従って,緊急変更の作業計画を策定し,実施の許可を得た。 ・翌日の6時から,負荷分散Hサーバのメーカ作業員とともに変更作業を実施した。 ・変更作業の最後の作業項目として,代理店システムの機能の確認作業を行った。 この作業で代理店サービスが利用できることを確認して,8時までに作業を終了 した。 代理店サービスは,予定どおり8時に開始されたが,9~10時のピーク時間帯に代 理店からサービスデスクに“サービスの応答が遅くなっている"というクレームが 多数寄せられた。サービスデスクから調査を依頼されたL氏は,今回の緊急変更作 業が影響したと判断し,T氏に調査を依頼した。 しばらくして,T KMS,“緊急変更作業で,負荷分散機能を実行するソフトウェ アの負荷分散先サーバの登録を誤り,代理店サーバ1に処理が集中してボトルネッ ai 1= クとなってしまった。直ちに,設定を修正する。"”という回答があった。 [キャパシティ計画の変更] インターネット受付サービスは,サービスを開始してから1年が経過し,F社では, キャパシティ計画を変更することになった。そこで,L氏はインターネット受付サー ビスの現状を次のとおり整理した。 ・オンライン応答時間は,SLA項目の目標値は達成しているが,サービス開始時 に比べて悪化している。 ・インターネット受付システムはWeb型のシステムであって,主にサーバの処理 能力がパフォーマンスに影響を与える。 ・オンライン応答時間のSLA項目の目標値を達成するために,将来の需要の予測 が必要である。 そこで,L氏は,EV,(ア)サービスの需要と達成されているパフォーマンスの 状況を調査することにした。

共通の文章

インシデント管理に関する次の記述を読んで,設問1ー4に答えよ。 M社は,中堅の通信販売会社である。M社では,数年前からインターネット経由 で注文を受け付ける販売サービスを開始した。サービス提供時間は24時間365日で ある。最近では,インターネット経由の注文が増えており,更なる売上拡大のため に販売サービスの充実が課題となっている。また,受注した商品を顧客に配送する 業務を支援する配送管理サービスがM社の社員向けに提供されている。サービス提 供時間は毎日6時から23時までである。 [システムの概要) システム部では,販売サービスを提供する販売システム,及び配送管理サービス を提供する配送管理システムを開発し,運用している。システムの開発は開発チー ムが担当し,運用は運用チームが担当している。 ①販売システムは,外部の顧客が利用するM社の重要システムであり,5 BO Webサーバで冗長システムを構成している。M社では,Web管理端末からWeb サーバにコンテンツを登録している。また,外部の顧客との連絡手段として電 子メールを使っていることから,社員間でも利用するメールサーバを販売シス テムのコンポーネントとして管理している。 ②⑨販売システム及び配送管理システムは,運用チームが監視システムを利用し て常時監視し,インシデントが発生した場合は1次対応を行っている。インシ デントはインシデント管理システムで管理している。 @監視システムに表示されるメッセージ(以下,表示メッセージという)lk,M 社の統一基準に従って分類されている。表示メッセージの種類を表1に示す。 表1表示メッセージの種類 ——— A)バッチ処理の正常終了 9システム資源使用状況のしきい値超過 2システムの異常終了 =fg,a | | [システム部のインシデント管理〕 システム部では,表示メッセージの種類が“警告”又は“異常”の場合,インシ デントとして扱い,インシデント管理システムに記録する。また,サービスを早期 に回復させるために,既知の誤りのデータベース(以下,KEDBという)を利用し ている。KEDBには,過去のインシデントの発生原因と,サービスの回復方法又は サービスへの影響を低減する有効な回避策が登録されている。運用チームはインシ デントの対応手順の中で,KEDBを参照する。 運用チームが実施するインシデントの対応手順を表2に示す。 表2インシデントの対応手順 ne監視システムの表示メッセージの種類からインシデントの発生を認識する。インシデントを受 °け付け,インシデント管理システムに記録する。 優先度の|・全てのインシデントに優先度?として,“BR”,"中",“UE”のいずれかを割り当て,目標復旧時 割当て間2?を設定する。 .インシデントをサービスごとに決められたカテゴリに分類する。 記録の.割り当てた優先度及び分類したカテゴリの内容で,インシデント管理システムの記録を更新す 更新る。 aan・優先度が“高”及び“中”の場合は,MHF-ACHSICRAMBETS.RBA“KR”の ON場合も開発チームに連絡する。 ・目標復旧時間内に回復できないおそれがある場合は,開発チームに回復処理を依頼する。 spit・サービスを早期に回復させるために,回復を試みる。 ・KEDBを参照して,サービスを早期に回復させる回避策を探し,必要な回復処理を行う。 ・インシデントが解決したことを確認する。 ery・開発チームに回復処理を依頼した場合は,開発チームからの回復処理完了の連絡を受けた後, -回復状況を確認する。 ・回復内容などの記録を更新し,終了する。 EDサービスごとに表3,表4で定める優先度判定ルールに従って優先度を割り当てる。 2インシデントの記録の開始から解決までの最長時間。優先度に基づく目標復旧時間を表5に示す。 表3販売サービスの優先度判定ルールR4配送管理サービスの優先度判定ルール 表5優先度に基づく目標復旧時間 |ュ|き|sz| 発生したインシデントが情報セキュリティインシデントに該当するおそれがある 場合,運用チームの担当者は,システム部の情報セキュリティ担当要員に連絡して, 指示に従って対応する。情報セキュリティ担当要員は,インシデントが情報セキュ リティインシデントに該当するかどうかを判断する。該当する場合は,M社の情報 セキュリティ管理プロセスの規程に従って対応を指示し,自ら迅速に対応策を実施 して被害を最小限に抑える。 〔販売サービスのインシデント〕 ある日,販売システムの5台のWebサーバのうち,1台のCPU使用率がしきい値 を超え,監視システムで“警告"のメッセージが表示された。監視していた運用チ ームのY氏は,インシデントの対応手順に従って対応した。対応状況は次のとおり である。 ①インシデントをインシデント管理システムに記録した。 ②表3及び表5を参照し,優先度を“中”と割り当て,目標復旧時間を2時間 に設定した。その後,分類したカテゴリの内容で記録の更新を行った。 インシデントの解決を図るために,解決策を立案し実施することにした。そ こで,必要な回復処理を行うためにKEDBを参照したところ,特定の条件の下 で販売システムのバッチ処理プログラムの負荷が高くなって,CPU使用率が上 昇した事例を見つけた。回避策として,バッチ処理プログラムを強制終了させ る方法,又はWebサーバの再起動を行う方法が記載されていた。そこで,Web サーバを確認したが,バッチ処理プログラムは稼働していなかった。 ④CPU使用率のしきい値超過は,販売システムのWebサーバ1台だけで発生し THY,他の4台のWebサーバでは発生していない。Y氏は,サービス継続の 観点から,利用者への影響は小さいと判断し,インシデントの原因を調査する ー16一 ことにした。Y氏は,CPU使用率のしきい値超過が発生しているWebサーバを 調査し,CPU使用率が高いプログラムを特定した。 ©CMDBに登録されている販売システムのプログラム一覧を確認したところ, 特定したプログラムはCMDBには登録されていなかった。そこで,Y氏は開発 チームのZ氏に調査を依頼した。 Z氏は,稼働環境で販売サービスを利用したところ,応答遅延が発生する場合があ ることを確認した。次に,Z氏は,CMDBを確認し,当該プログラムはCMDBに登 録されておらず,M社が開発したプログラムではないことが分かった。更に調査し たところ,不正プログラムであることが判明した。Z氏はY氏に調査結果を回答し, 強制終了する手順を伝えた。Y氏はZ氏の指示に従って,不正プログラムを強制終了 した。その結果,WebサーバのCPU使用率の低下を確認できたことから,Y氏はイ ンシデントが解決したと判断した。 なお,Z氏は,CMDBに登録されていないプログラムが稼働していた場合に強制 終了する手順を回避策として整備し,後日KEDBに登録することにした。 [標的型攻撃メールの検出] Z氏は,インシデントの根本原因を特定するために調査し,次の事実が判明した。 ①Web管理端末にも不正プログラムがあった。 ②不正プログラムは,販売システムの5台のWebサーバのうち,1台のWebサ ーバだけに存在していた。 ③メールサーバのログには,不審おファイルが添付されたWeb管理者宛ての電 子メールの受信記録があった。また,同じファイルが添付された電子メールが 社内の他部署の社員にも送信されている記録があった。 そこで,Z氏は,“外部から送付された標的型攻撃メールに添付されたファイルを Web管理端末で開封した。その際,不正プログラムが起動され,Web管理端末と, メンテナンス作業のために接続していた該当の1台のWebサーバに不正プログラム がコピーされ,動作するよう設定された。"と推定した。Z氏は,今回のインシデン トが情報シセキュリティインシデントに該当するおそれがあるとして,情報セキュリ ティ担当要員のK氏に連絡した。K氏は,情報セキュリティインシデントに該当す ると判断し,2Z氏に,1台のWebサーバとWeb管理端末をLANから切り離すように ー17一 指示した。そこで,2氏はY氏に,該当機器をLANから切り離すよう依頼した。 次に,K Kid,類似の標的型攻撃メールが送付された宛先を,|』|から調 査し,標的型攻撃メールが届いた全ての社員に対して,次の内容を直ちに指示した。 ・社員が添付ファイルを開封していた場合,開封操作を行った機器をLANから切 り離す。その後,指示に従って不正プログラムの確認をすること。 ・社員が深付ファイルを開封していなり場合|b|をすること。 そして,K氏は,社内に今回の標的型攻繋メールに対する注意喚起を行った。 [標的型攻撃メールの対策〕 システム部の部長は,K氏から,“今回の標的型攻撃メールには,WARN AY として,マルウェアを仕掛けたファイルが添付されていた。幸い外部への情報漏え いは確認されなかった。KK,社内への注意喚起も完了した。"という報告を受けた。 システム部では,標的型攻撃メールへの対策として,マルウェアが仕掛けられた標 的型攻撃メールを検出した場合,電子メールから添付ファイルを削除したり,不正 な通信を検出したりすることができるシステム(以下,防御システムという)ER NL,導入することにした。システム部は,防御システムを販売システムのコンポ ーネントとして管理する。また,システム部は,標的型攻撃メールを検出した場合 の対応として,次のとおり決定した。 ①検出された電子メールの添付ファイルは,調査用に防御システムのストレー ジに保存される。情報セキュリティ担当要員は,保存されたファイルの内容を 定期的に調査し,対策が必要と判断した場合は,適切な対策を立案し実施する。 ②防御システムで,特定の基準以上の危険性がある不正な通信を検出した場合| は監視システムに通知する。(ア)通知された監視システムでは,“BE”OX ッセージを表示する。 @運用チームは,インシデントを記録し,管理する。 [配送管理サービスの変更] M社では,顧客へのサービス充実を目的に,インターネット経由の注文について, 配送時間を短縮することを決定した。そのためには,M社の物流拠点間で深夜に商 品を配送する必要がある。営業部とシステム部は,配送管理サービスのサービス要 ー18— 求事項について,次のとおり合意した。 ①物流拠点からいつでも配送管理サービスを利用できるように,配送管理シス テムを24時間稼働に変更する。 ②システム障害による配送業務の停止は。サービスの低下につながるので,シ ステム停止を伴うインシデントが発生した場合には,インシデントの対応手順 に従って,30分以内に回復させる。 システム部では,サービス要求事項を基に,サービス変更の活動を開始した。