【情報処理安全確保支援士】午後試験対策！セキュリティ運用（監視・ログ・バックアップ・RPO/RTO）の要点を徹底解説

情報処理安全確保支援士試験の午後問題、特にセキュリティ運用のシナリオで手が止まってしまった経験はありませんか？「膨大なログからインシデントの原因を特定せよ」「適切なバックアップ計画を答えよ」といった問いに、知識が断片的で繋がりが見えず、戸惑ってしまう方は少なくありません。

セキュリティ運用とは、いわばシステムの「防犯カメラの監視」と「健康診断」を常に行うようなものです。平時からログを記録・監視し、異常の兆候をいち早く察知する。そして万が一の障害やサイバー攻撃が発生した際には、その記録を元に原因を特定し、バックアップから迅速に復旧する。この一連の流れは、組織を守るための根幹となる極めて重要な業務です。

この記事では、支援士試験で頻出する「監視・ログ管理」「SIEM/SOC」「時刻同期」「バックアップと復旧」という重要テーマを、単なる用語解説で終わらせません。それぞれの技術が実際の現場でどのように連携し、一つの防御壁として機能するのか、その全体像を体系的（A to Z）に、そして身近な例え（C）や実務での活用例（D）を交えながら徹底解説します。

読み終える頃には、点在していた知識が線で繋がり、午後問題の長文シナリオを「現場で起きているリアルな物語」として読み解く力が身についているはずです。合格へ向けた盤石な土台を、ここで一緒に築き上げましょう。

セキュリティ運用の第一歩「監視とログ管理」｜不正アクセス検知の基礎

セキュリティ対策と聞くと、ウイルス対策ソフトやファイアウォールといった「防御壁」をイメージするかもしれません。しかし、プロの攻撃者はあの手この手で防御壁をすり抜けてきます。そこで重要になるのが、侵入されたことをいち早く察知し、何が起きたのかを正確に把握するための「監視とログ管理」です。これは、セキュリティ運用の最も基本的な、そして最も重要な活動と言えます。

ログ監視の目的：なぜシステムの「日記」が必要なのか？

ログとは、一言でいえば「システムが自動で書き残す行動日記」です。誰かがログインした、ファイルが変更された、エラーが発生した、といった出来事がすべて時系列で記録されます。この日記を監視する目的は、不正アクセスやシステムの異常といった「いつもと違う動き」を早期に発見し、迅速なインシデント対応に繋げることです。

【身近な例え：お店の防犯カメラ】(C)
ログ管理は、24時間365日稼働する防犯カメラのようなものです。何もなければただ録画データが溜まっていくだけですが、万引き（不正アクセス）や従業員の不正（内部不正）が疑われたとき、その映像（ログ）は犯人を特定し、被害状況を明らかにするための決定的な証拠となります。いつ、誰が、何をしたかが分からなければ、有効な対策も打てません。

【実務での活用例】(D)
実際に、深夜2時に海外からの不審な管理者ログインが記録されたログをきっかけに、アカウント乗っ取りが発覚したケースがあります。ログがなければ、この不正アクセスに気づくことすらできず、被害が拡大していたことでしょう。インシデント対応の専門家は、まずログの提出を求め、そこから攻撃者の足跡を辿っていくのです。

ログの三大要素：「いつ」「誰が」「何をしたか」

試験でも問われるログの基本は、以下の3つの要素（+α）で構成されていることです。

1. When（いつ）：イベントが発生した正確な時刻（タイムスタンプ）
2. Who（誰が）：アクションを起こした主体（ユーザーID、IPアドレスなど）
3. What（何をしたか）：実行された操作の内容（ログイン成功、ファイル削除など）

例えば、Webサーバーのアクセスログには、以下のような記録が残ります。
2025-08-26 02:15:30 (When) 198.51.100.78 (Who) GET /admin/login.php (What)

この1行から、「怪しい海外IPアドレスから管理画面へのアクセスがあった」というインシデントの兆候を掴むことができます。

ログの種類：アクセスログとイベントログの違い

ログには様々な種類がありますが、支援士試験では特に以下の2つの違いを理解しておくことが重要です。

これらを組み合わせることで、「Aさんがお店に入ってきて（アクセスログ）、レジのお金を盗んだ（イベントログ）」というように、より詳細な状況を把握できます。

ログの信頼性を守る「改ざん防止策」

攻撃者は、侵入後に自分の足跡であるログを消去・改ざんしようとします。そのため、ログが証拠として機能するためには、その完全性（改ざんされていないこと）が保証されなければなりません。

主な改ざん防止策は以下の通りです。

• ログサーバーへの転送：各機器からログを専用の外部サーバー（Syslogサーバーなど）にリアルタイムで転送します。攻撃者が侵入したサーバー上のログを消しても、転送先のサーバーには記録が残ります。
• WORMメディアへの保存：CD-Rや専用のストレージなど、一度書き込んだら変更・削除ができない（Write Once Read Many）メディアにバックアップします。

これらは、防犯カメラの映像を、犯人に壊されないようクラウドストレージにも同時に保存しておくのと同じ考え方です。
しかし、日々膨大な量が出力されるログを人間が常に監視するのは現実的ではありません。そこで、この課題を解決するために登場するのが、次のセクションで解説する「SIEM」や「SOC」という仕組みです。

SIEMとは？SOCの役割とCSIRTとの違い【支援士 午後試験対策】

前のセクションで解説したように、サーバーやネットワーク機器は日々膨大なログを生成し続けます。これを人力ですべてチェックするのは、干し草の山から1本の針を探すようなもので、現実的ではありません。この課題を「テクノロジー」と「専門家チーム」で解決するのが、SIEM (Security Information and Event Management) と SOC (Security Operation Center) です。

SIEMの役割：ログ分析を自動化する「超高性能な監視システム」

SIEMは、日本語では「セキュリティ情報イベント管理」と訳されます。その主な役割は、組織内の様々な機器からログを１箇所に集約し、それらを自動的に相関分析して、インシデントの兆候となるような怪しい動きを検出・通知することです。

【身近な例え：AI搭載の統合監視システム】(C)
SIEMは、ショッピングモールのAI搭載・統合監視システムに似ています。

• ログ収集：入口、各店舗、レジ、駐車場など、あらゆる場所の防犯カメラ映像（ログ）を１つの監視センターに集めます。
• 相関分析：AIがそれらの映像を自動で分析し、「Aという人物が、入口のカメラに映った3分後、全く関係ないB店のバックヤードに侵入し、30秒で出てきた」といった、単体の映像では気づけない怪しい行動パターンを検出します。
• アラート通知：AIが「不審行動を検知！」と、監視室のモニターに警告（アラート）を表示します。

このように、SIEMはログの分析を自動化・高度化し、人間が確認すべき重要なポイントを絞り込んでくれるのです。

SOCの役割：アラートを分析する「セキュリティ監視の司令塔」

SOCは、その名の通りセキュリティ運用（監視・分析・対応）を専門に行うチームです。彼らの主な業務は、SIEMが発したアラートを24時間365日体制で監視し、それが本当に対応すべきインシデントなのかを判断・分析することです。

【実務での活用例】(D)
SOCアナリストは、SIEMから「深夜に特定のサーバーへ、通常ではありえない量のデータ転送がありました」というアラートを受け取ると、以下のような分析を開始します。

1. トリアージ：そのアラートの危険度を評価する。
2. 調査：誰が、どこから、何のためにその通信を行ったのか、関連するログを深く掘り下げて調査する。
3. 判断：調査の結果、「これは定時のバックアップ処理による正常な通信だ（＝誤検知）」あるいは「マルウェアによる情報窃取の可能性が高い（＝インシデント）」と判断します。
4. 報告・連携：インシデントと判断した場合、CSIRTなどの関連部署へ状況を報告し、対応を引き継ぎます。（これをエスカレーションと呼びます）

【図解】ログ収集からインシデント対応までの流れ

ここまでの関係性を図にすると以下のようになります。ログがSIEMに集約され、SOCが分析し、インシデント発生時にはCSIRTが対応するという流れを掴みましょう。

    graph TD
        subgraph "① ログ生成元"
            A[Webサーバー]
            B[ファイアウォール]
            C[クライアントPC]
        end

        subgraph "② 収集・分析"
            D[SIEM]
        end

        subgraph "③ 監視・検知"
            E[SOC]
        end

        subgraph "④ インシデント対応"
            F[CSIRT]
        end

        A -- ログ転送 --> D
        B -- ログ転送 --> D
        C -- ログ転送 --> D
        D -- アラート通知 --> E
        E -- インシデントと判断 --> F
    

( mermaid.js 形式のテキストです。HTML出力時に図として表示されます )

SOC・CSIRT・NOCの違い

試験の午後問題では、これらのチームが連携するシナリオが出題されるため、それぞれの役割の違いを正確に理解しておくことが不可欠です。

【身近な例え：警察と交通整理員】(C)

• SOC：監視カメラで街の異常を24時間見守る警備員。
• CSIRT：通報を受けて現場に駆けつけ、犯人確保や捜査を行う警察官。
• NOC：道路の渋滞や事故がないかを見守る交通監視員（交通整理員）。

それぞれのミッションと業務内容を表で整理します。

このように、SOCが「見つけるプロ」なら、CSIRTは「対処するプロ」です。そして彼らが正確な分析を行う上で、すべてのログの「時刻」が揃っていることが大前提となります。次のセクションでは、そのために不可欠な「時刻同期」について見ていきましょう。

インシデント調査の要！時刻同期(NTP)とログの証跡能力

SIEMとSOCによって、膨大なログからインシデントの兆候を効率的に見つけ出せるようになりました。しかし、その分析精度は、大前提として「すべてのログのタイムスタンプが正確に揃っていること」に依存します。もし各機器の時計がバラバラだったら、高性能な分析エンジンも役に立ちません。ここでは、インシデント調査の成否を分ける「時刻同期」の重要性と、ログが証拠として扱われるための条件について解説します。

なぜ時刻同期が重要なのか？：時間のズレが引き起こす致命的な問題

インシデントが発生すると、SOCやCSIRTは複数の機器のログを突き合わせ、攻撃の経路や影響範囲を特定します。このとき、各ログの時刻が正確に同期されていないと、イベントの発生順序を誤って解釈してしまうという致命的な問題が発生します。

【身近な例え：刑事ドラマの捜査会議】(C)
事件の捜査で、複数の目撃者の証言（ログ）を元に犯人の足取りを追っているとします。

• 目撃者A：「犯人らしき人物がA駅の改札を通ったのは、10時5分です」
• 目撃者B：「その人物は、Bコンビニで買い物をしました。レシートの時刻は10時3分です」
• 目撃者C：「C公園の防犯カメラに映っていたのは10時8分でした」

この証言だけを見ると「Bコンビニ → A駅 → C公園」という経路が見えます。しかし、もし「目撃者Bの腕時計が5分進んでいた」としたらどうでしょう？実際の犯行時刻は10時3分 - 5分 = 9時58分となり、経路は「Bコンビニ → A駅」ではなく、全く別の可能性が浮上します。このように、時刻のズレは調査を混乱させ、原因究明を著しく困難にするのです。

【実務での活用例】(D)
実際のインシデント調査では、「①Webサーバーのアクセスログ」「②データベースの操作ログ」「③ファイアウォールの通信ログ」などを突き合わせます。もしWebサーバーの時計が5分遅れていたら、「データベースから情報が盗まれた後に、Webサーバーへの不正アクセスがあった」という全く逆の時系列で分析してしまい、攻撃の侵入経路の特定に失敗する可能性があります。

NTP (Network Time Protocol) の仕組み

この時刻のズレを防ぐために使われるのがNTP (Network Time Protocol) です。NTPは、ネットワークに接続された機器同士で、基準となる時刻情報を交換し、お互いの時計を正確に同期させるためのプロトコルです。

NTPはStratum (ストラタム) と呼ばれる階層構造を持っており、より上位の正確な時刻ソースから順々に時刻情報が伝搬されていきます。

【図解】NTPの階層構造 (Stratum)

    graph TD
        subgraph Stratum 0
            A[原子時計 / GPS]
        end
        subgraph Stratum 1
            B[公開NTPサーバー]
        end
        subgraph Stratum 2
            C[組織内のNTPサーバー]
        end
        subgraph Stratum 3
            D[Webサーバー]
            E[クライアントPC]
        end
        A -- 正確な時刻 --> B
        B -- 時刻同期 --> C
        C -- 時刻同期 --> D
        C -- 時刻同期 --> E
    

( mermaid.js 形式のテキストです。HTML出力時に図として表示されます )

【身近な例え：テレビの時報】(C)
これは、国の管理する標準時（Stratum 0）を元に、テレビ局（Stratum 1）が正確な時報を流し、それを見た各家庭（Stratum 2以下）が家の時計を合わせる、という流れに似ています。組織内では、インターネット上の公開NTPサーバー（Stratum 1 or 2）と同期するNTPサーバーを立て、そこから社内の全機器へ時刻を配信するのが一般的です。

NTPを悪用した「NTPリフレクション攻撃」

NTPは非常に重要なプロトコルですが、その仕様を悪用したDDoS攻撃（サービス妨害攻撃）も存在します。これが「NTPリフレクション攻撃」です。攻撃者は、送信元IPアドレスを攻撃対象のIPアドレスに偽装して、NTPサーバーに「時刻情報を大量にください」という小さなリクエストを送ります。すると、NTPサーバーは偽装されたIPアドレス、つまり攻撃対象のサーバーに対して、リクエストの何十倍もの大きさの応答（レスポンス）を大量に送りつけてしまい、サーバーをダウンさせるのです。

証跡管理：ログが「証拠」であるための3条件

時刻同期が完璧でも、ログそのものが改ざんされていたり、必要な時に読めなければ意味がありません。インシデント調査や法的な証拠としてログを利用するためには、以下の3つの条件（証跡能力）を満たす必要があります。

正確な時刻が同期され、これら3条件を満たしたログが揃って初めて、セキュリティ運用の土台が整います。
しかし、どれだけ完璧な監視体制を敷いても、インシデントによってシステムが停止してしまう可能性はゼロではありません。万が一の事態に備え、いかにして事業を継続し、システムを復旧させるか。次のセクションでは、そのための重要な鍵となる「バックアップ」について掘り下げていきます。

事業継続の生命線「バックアップ」｜フル・差分・増分の違いと3-2-1ルール

どれほど強固な監視体制を築いても、ランサムウェアによるデータ暗号化、ハードウェア障害、あるいは人為的な操作ミスなど、データが失われるリスクをゼロにすることはできません。そのような事態に陥った際、事業を継続するための唯一の希望となるのがバックアップです。これは、システムの「保険」であり、インシデント対応における最後の安全網と言えます。

バックアップの目的と重要性

バックアップの目的は至ってシンプルです。それは、障害や攻撃によってデータが失われた場合に、正常な状態に復旧できるように備えることです。特に、データを人質に身代金を要求するランサムウェア攻撃が猛威を振るう現代において、有効なバックアップの有無が事業の存続を直接左右します。

【身近な例え：スマートフォンの機種変更】(C)
バックアップは、スマートフォンの機種変更を想像すると分かりやすいです。古いスマートフォンが壊れても（障害発生）、事前にクラウドやPCに写真や連絡先をバックアップしておけば（平時のバックアップ）、新しいスマートフォンで元通りに復元（復旧）できます。この備えがなければ、大切なデータはすべて失われてしまいます。

バックアップの3つの基本方式

    graph TD
        subgraph "フルバックアップ (Full)"
            F1[月: 全データ] --> F2[火: 全データ] --> F3[水: 全データ]
        end
        subgraph "差分バックアップ (Differential)"
            D1[月: 全データ] --> D2[火: 月からの変更分]
            D1 --> D3[水: 月からの変更分]
        end
        subgraph "増分バックアップ (Incremental)"
            I1[月: 全データ] --> I2[火: 月からの変更分] --> I3[水: 火からの変更分]
        end
    

( mermaid.js 形式のテキストです。HTML出力時に図として表示されます )

• フルバックアップ: 最もシンプルで復旧が速いですが、毎回すべてのデータを保存するため時間と保存容量が最も大きくなります。
• 差分バックアップ: 復旧はフルバックアップと差分バックアップの2つだけで済むため比較的速いです。しかし、日が経つにつれてフルバックアップとの差分が大きくなり、バックアップ時間と容量が増加します。
• 増分バックアップ: 毎回のバックアップは変更分のみなので最も速く、容量も最小限で済みます。しかし、復旧時にはフルバックアップ以降のすべての増分バックアップを適用する必要があり、手順が複雑で時間もかかります。

バックアップ戦略の鉄則「3-2-1ルール」

バックアップはただ取れば良いというものではありません。そのバックアップデータ自体が失われるリスクも考慮する必要があります。そこで重要になるのが、バックアップの信頼性を高めるための経験則「3-2-1ルール」です。

• 「3」: データを3つ保持する（原本データ + 2つのバックアップ）
• 「2」: バックアップは2種類の異なるメディアに保存する
• 「1」: バックアップのうち1つはオフサイト（遠隔地）に保管する

【実務での活用例】(D)
ある企業では、以下のように3-2-1ルールを実践しています。

1. 原本データ：社内のファイルサーバーに保存 (1つ目のデータ)
2. バックアップ1：社内のNAS（Network Attached Storage）に毎日バックアップ (2つ目のデータ / 異なるメディア)
3. バックアップ2：NASのバックアップデータを、さらにクラウドストレージへ自動転送 (3つ目のデータ / オフサイト保管)

これにより、社内で火災や自然災害が発生しても、遠隔地に保管されたクラウド上のバックアップデータから復旧することが可能になります。

データをバックアップしただけでは、まだ準備は万全ではありません。そのバックアップを使って「どの時点のデータを」「どれくらいの時間で」復旧させるのか。次のセクションでは、事業継続計画（BCP）と密接に関わる復旧の目標設定について解説します。

復旧目標(RPO/RTO)とDRサイトとは？BCPを支える技術【午後試験対策】

前セクションでバックアップの重要性を解説しましたが、ただデータを保存しているだけでは不十分です。「どの時点のデータまで戻せれば許容できるのか？」「どれくらいの時間で業務を再開しなければならないのか？」といった具体的な目標を定め、それを実現する仕組みを準備しておく必要があります。これらは、災害やサイバー攻撃に備える**BCP（事業継続計画）**の根幹をなす考え方です。

BCP（事業継続計画）における復旧の位置づけ

BCP (Business Continuity Plan) とは、自然災害、システム障害、感染症の流行といった不測の事態が発生しても、重要な業務を中断させず、または中断しても可能な限り短い時間で復旧させるための方針や手順をまとめた計画です。ITシステムの復旧は、このBCPを実現するための極めて重要な要素となります。

復旧の2大指標：RPOとRTO

BCPを策定する上で、システム復旧の目標レベルを具体的に定義するのが RPO と RTO です。この2つの指標は、支援士試験の午後問題で頻出する最重要キーワードです。

• RPO (Recovery Point Objective / 目標復旧時点)
  • 「Point = 時点」 と覚えましょう。
  • 障害発生時に、どのくらい過去の時点までデータを復元する必要があるかを示す指標です。これは、許容できるデータ損失量を意味します。
  • 例えば、RPOを「1時間」と設定した場合、最低でも1時間に1回はバックアップを取得する必要があります。
• RTO (Recovery Time Objective / 目標復旧時間)
  • 「Time = 時間」 と覚えましょう。
  • システム障害が発生してから、どれくらいの時間内に復旧し、業務を再開する必要があるかを示す指標です。これは、許容できるシステム停止時間を意味します。
  • RTOが短いほど、迅速に復旧できる高度な仕組み（後述のホットサイトなど）が必要になります。

【身近な例え：レポート作成】(C) 大学の卒業論文をPCで書いている状況を想像してください。

• RPO： 「何分おきに上書き保存（バックアップ）をするか」。もし15分おきに保存していれば、PCがクラッシュしても最大で15分前の状態には戻せます。この「15分」がRPOです。
• RTO： 「PCがクラッシュした後、何分以内に予備のPCを立ち上げて作業を再開できるか」。予備PCがすぐ使えるならRTOは数分ですが、買いに行かなければならないならRTOは数時間になります。

DRサイト：災害復旧のためのバックアップ拠点

DR (Disaster Recovery) サイトとは、本番環境が稼働するメインのデータセンターが、地震や火災などの大規模災害で壊滅的な被害を受けた際に、業務を引き継ぐための代替拠点です。RTOを達成するために、どのようなDRサイトを準備するかが重要になります。

【実務での活用例】(D) 金融機関や大手ECサイトなど、サービスの停止が社会的に大きな影響を与えるシステムでは、メイン拠点（例：東京）とは地理的に離れた場所（例：大阪）に、本番とほぼ同等のシステム構成を持つDRサイトを構築しています。これにより、首都直下型地震のような広域災害が発生しても、DRサイトに処理を切り替えることでサービスを継続できます。

DRサイトは、準備レベルとコストに応じて、主に以下の3種類に分類されます。

どのレベルのDRサイトを選択するかは、対象業務の重要性と、定められたRPO/RTO、そして許容されるコストによって決定されます。

まとめ

本記事では、情報処理安全確保支援士試験におけるセキュリティ運用の核心的なテーマを、一連の物語として解説してきました。

平時におけるシステムの「防犯カメラ」である監視とログ管理から始まり、その膨大な情報を「AI搭載の監視システム(SIEM)」と「警備員チーム(SOC)」で効率的に分析・検知する体制。そして、すべての分析の信頼性を担保する時刻同期の重要性。

さらに、万が一インシデントが発生した際に事業を守る「最後の保険」であるバックアップ戦略と、それを「いつまでに(RTO)」「どの時点へ(RPO)」復旧させるかという具体的な復旧計画まで、各要素が密接に連携し合って一つの堅牢なセキュリティ体制を築いていることをご理解いただけたかと思います。

試験の午後問題では、「ログを分析して攻撃経路を特定させる」「事業インパクトを考慮して適切なRPO/RTOを選択させる」といった、まさにこの一連の流れを理解しているかが問われます。本記事で解説した体系的な知識と具体例は、断片的だった知識を線で繋ぎ、複雑なシナリオ問題を読み解くための強力な武器となるはずです。基礎を固め、自信を持って本番に臨みましょう。