正解：ア
各選択肢の解説
ア全PCの定義ファイルの更新日を管理サーバで一覧にし、古いPCを見つけて対処する。
正解。問題は「更新が失敗していても誰も気づけなかった」ことです。 設定ではなく実際の状態を一か所で確かめ、遅れた端末を拾う仕組みにすれば、ほかのPCの同じ失敗も見つかります。
イ自動更新の間隔を、1日1回から1時間ごとに短くする設定に変える。
誤り。間隔を短くすると、更新が成功している端末では新種への対応が早まります。 しかし今回の端末はエラーで更新が止まっていたので、試す回数を増やしても失敗が続くだけです。 止まっていることに気づく手段が加わりません。
ウ全社員に、毎朝始業時に手動で定義ファイルを更新するよう指示する。
誤り。人が操作を加えるので一見確実そうですが、忘れた人やエラーに気づかない人がいれば同じことが起きます。 実施されたかを誰も確かめない点は今と変わらず、利用者に判断を任せる対策です。
エ感染したPCのマルウェア対策ソフトを入れ直し、自動更新を設定し直す。
誤り。感染したPCの更新は直りますが、対処はその1台に限られます。 同じ原因で更新が止まっているPCがほかにもあるかもしれず、それを見つける手段がないままです。
理解を深めるために
「設定した」と「更新されている」は別のこと
目覚まし時計をセットしても、電池が切れていれば鳴りません。 大事なのはセットしたかどうかではなく、実際に鳴る状態かどうかです。
定義ファイルの自動更新も同じです。設定していても、通信の不具合やライセンスの期限切れ、 ディスクの空き不足などで更新が止まることがあります。止まったことに誰も気づかなければ、 その端末は古い定義ファイルのまま、新しいマルウェアを素通しします。
なぜ一元的な確認が要るのか
- パターンマッチング法は、定義ファイルに載った特徴としか照合できない
- 定義ファイルが古い端末は、その後に出回ったマルウェアを検知できない
- 更新の失敗は、利用者の画面に小さく表示されるだけで、見過ごされやすい
- 管理サーバで全端末の定義ファイルの日付や更新結果を集めれば、 遅れている端末を管理者の側から見つけられる
今回の事故から学ぶべきことは「更新の頻度」ではなく、更新が成功しているかを確かめる手段がなかったことです。
混同しやすいものとの違い
| 対策 | 何が変わるか | 更新の失敗に気づけるか |
|---|---|---|
| 管理サーバで更新日を一覧にする | 全端末の実際の状態が見える | 気づける |
| 自動更新の間隔を短くする | 成功している端末の反映が早まる | 気づけない |
| 毎朝の手動更新を指示する | 利用者の操作が増える | 利用者しだいで、確かめる人がいない |
| 感染PCだけ入れ直す | その1台が直る | ほかの端末は分からない |
試験では、対策が「設定を変える」ものか「状態を確かめる」ものかを見分けます。 設定が守られなかったことが原因なら、確かめる仕組みを選びます。