ランサム時代における企業情報管理の基本

「何を守るか」を決めなければ、何も守れない　～ツール導入前に読むべき、意思決定のためのガイドライン～

1．はじめに――なぜ今、情報管理の整理が必要か

ランサムウェアの被害が国内外で急増している。IPAの調査によれば、企業へのランサムウェア攻撃は年々増加しており、大企業から中小企業まで業種を問わず標的となっている。

しかし多くの企業では、「何を守るか」についての考え方が部門やITベンダーによってまちまちで、体系的に整理されていないのが実態だ。IT部門はバックアップの技術論に傾き、経営層はコスト感覚で判断し、事業部門は「全部重要」と主張する。この三者がかみ合わないまま、場当たり的な対策が積み上がっていく。

さらに近年、SplunkやMicrosoft Sentinelに代表される高額なログ管理ソリューションが「ランサム対策の要」として語られるようになり、IT担当者の間では「重要データの保護」と「ログ管理」が同列に扱われて混乱が生じることも多い。

本コラムでは、この混乱を整理するために2つの問いに答える。

• 企業にとって本当に「失ってはならないデータ」とは何か、どうやって決めるか
• ランサム対策で重要視されるログ管理は、重要データの保護とどう違うのか

この2つを明確に分けて理解することが、限られた予算と人員の中で実効性のある情報管理体制を構築する第一歩となる。

2．「失ったら会社が潰れるデータ」の正体

2-1．よくある誤解：「全部重要」は判断ではない

企業の情報管理を議論すると、必ずといっていいほど「うちのデータは全部重要です」という声が出る。しかしこれは判断ではなく、判断の放棄だ。

バックアップの対象が際限なく広がれば、バックアップに時間がかかりすぎて「毎日取れない」という現実が生まれる。ランサムウェアに暗号化された際、本当に1時間以内に復旧しなければならないデータと、数日後に戻れれば十分なデータを同列に扱えば、復旧の優先順位が定まらず、かえって復旧に失敗するリスクが高まる。

「重要度に差はない」という前提を捨て、構造的に優先度を決めることが情報管理の出発点だ。

2-2．最重要データを絞り込む3つの問い

どのデータが「失ったら会社が潰れるか」を判断するには、以下の3つの問いを組み合わせる。

問い	判断の内容	Yesなら
① 再生成できないか？	失ったとき、人の手で作り直せるか	最重要候補
② 即座に事業に致命傷を与えるか？	キャッシュフロー・契約・信頼に直撃するか	最重要確定
③ 法的保存義務があるか？	法令で保存が義務付けられているか	問答無用で最重要

重要なのは問いの順序だ。まず「再生成できるか否か」でデータを半分以下に絞り込み、次に「事業への即効性」で最重要を確定させ、最後に法的義務で強制昇格させる。この3段階で、「なんとなく重要そう」な主観を排除できる。

2-3．「業務」から逆算する発想の転換

データそのものを起点にするのではなく、「止まったら会社が死ぬ業務」を先に特定し、そこから必要なデータを逆引きすることが正しいアプローチだ。

【逆算の手順】 Step 1：「何日止まったら致命的か」を業務ごとに決める Step 2：停止限界が短い業務だけを対象に、業務再開に最低限必要なデータを特定する Step 3：そのデータを3つの問いでスクリーニングし、最重要を確定する

この発想の転換により、「念のため」「あれば助かる」というデータが自動的に脱落し、真に守るべきデータだけが残る。

2-4．最重要データの典型例

上記のプロセスを経ると、多くの企業で以下のデータが最重要（Tier 0）として浮かび上がる。

データの種類	根拠
会計・債権債務データ	再生成不能＋法的保存義務＋キャッシュフロー直結
顧客契約・取引履歴	再生成不能＋事業継続の根幹
認証基盤（AD/IdP）	これが失われると全システムが止まる
プロダクトのソースコード	再生成不能＋競合優位性の消失
法令保存義務データ（帳簿等）	電子帳簿保存法・会社法・労基法等

逆に、社内Wiki、マーケティング資料、過去のプロジェクト資料、BIの集計レポート、ログのキャッシュといったデータは、多くの場合「重要だが最重要ではない」か「バックアップ不要」に分類される。

3．最重要データを組織として決めるプロセス

最重要データの決定はIT部門だけで完結できない。「何が止まったら会社が死ぬか」はビジネスの問題であり、経営・各事業部門の判断なしには正しく決まらないからだ。以下の6フェーズで進める。

フェーズ	内容	主な関係者
PHASE 0 経営合意	RTO・RPO目標値とオーナーを決める	経営層・CIO
PHASE 1 業務棚卸し	止まったら致命的な業務と停止限界時間を特定	経営層・事業部門長
PHASE 2 逆引き	業務を動かす最小データセットを3問でスクリーニング	IT・事業部門
PHASE 3 法的チェック	法令保存義務データを問答無用で最重要に昇格	法務・経理
PHASE 4 格付け確定	Tier 0 / Tier 1 / 対象外の3層に分類	IT・経営
PHASE 5 承認・文書化	経営会議での承認取得と文書整備	経営層
PHASE 6 定期見直し	年1回＋新規事業・法改正等の際に更新	CIO・IT部門

【RTO・RPOとは】

RTO（Recovery Time Objective）：システム障害が発生してから、業務を再開するまでの目標時間。例：最重要データは1時間以内に復旧する。

RPO（Recovery Point Objective）：障害発生時に、どの時点まで遡って復元できれば許容できるか。例：最大15分前の状態まで許容する。 この2つの数値を経営として決めることが、バックアップ設計の出発点となる。

4．ログ管理は「重要データ保護」とは別の戦略である

4-1．そもそも目的が違う

ランサムウェア対策の文脈でSplunkやMicrosoft Sentinelが語られると、「ログ管理も重要データ保護の一環では？」という混同が生じやすい。しかし両者は、根本的に目的が異なる。

	重要データ管理	ログ管理
目的	事業を継続させる	攻撃を検知・追跡する
失った時の影響	業務が止まる・会社が潰れる	攻撃の全容が分からなくなる
守り方	バックアップ・冗長化	改ざん不能な形で長期保管
使うタイミング	平時から常に参照する	インシデント発生時に初めて使う
価値の性質	常に高い	平時はゼロ、有事に突然極めて高くなる
考え方の枠組み	BCP・バックアップ戦略	セキュリティ監視（SOC）戦略
代表的なツール	バックアップソフト・ストレージ	Splunk・Microsoft Sentinel

簡単に言えば、重要データは「会社を動かし続けるため」に守り、ログは「攻撃者を見つけ、被害を封じるため」に残す。担当者も、予算も、本来は別々に設計すべきものだ。

4-2．なぜランサム対策でログが重要視されるのか

現代のランサムウェア攻撃には、見えにくい構造的特徴がある。攻撃者は侵入から暗号化（実害発生）まで平均200日前後潜伏するとも言われている。この間、攻撃者は静かに内部を偵察し、管理者権限を奪い、バックアップサーバーにまで到達してから、一斉に暗号化する。

【ランサムウェア攻撃の典型的な時系列】

Day 1　　　　侵入（VPN脆弱性・フィッシングメール等）

Day 1〜60　  内部偵察・権限昇格

Day 60〜150  バックアップサーバーへのアクセス・汚染 Day 150〜200 一斉暗号化・身代金要求

ここに根本的な問題がある。バックアップを復元しても、攻撃者はまだ社内にいる可能性がある。復元した翌日に、また暗号化されるケースが実際に報告されている。

復旧後の再感染を防ぐには、「攻撃者がどこから侵入し、どの端末・アカウントが侵害され、バックアップに汚染が及んでいるか」を特定しなければならない。これはすべて過去のログを遡ることでしか判明しない。

「ログは、復旧の地図である。」

ログがなければ、原因不明のまま「とりあえず復旧」することになる。 地図なき復旧は、同じ入口から再侵入を招く。

4-3．金庫と防犯カメラのたとえ

重要データとログの関係を、次のたとえで理解するとわかりやすい。

重要データは「金庫の中の現金」。ログは「金庫の前に設置した防犯カメラの録画」。

現金を守ることと、防犯カメラを設置することは目的が違う。

しかしどちらか一方だけでは不完全で、

泥棒が入った後に「誰がいつ来たか」を調べるには録画が必要だ。 そして最も重要なのは――泥棒は現金だけでなく、録画テープも消して逃げるという点だ。

4-4．だからこそ「接点」だけを連動させる

完全に分けて考えていいかというと、1点だけ連動させなければならない重要な接点がある。それは「バックアップ自体のログを、バックアップとは物理的に別の場所に保管する」ことだ。

攻撃者はバックアップサーバーに到達した後、バックアップの操作ログも合わせて消去する。ログが消えると、「バックアップが改ざんされた事実」すら確認できなくなる。

ログの種類	保管場所の原則	理由
認証・アクセスログ	別テナント・別クラウド	攻撃者に到達させないため
バックアップ操作ログ	バックアップと物理的に分離	改ざん・削除の証拠を残すため
ネットワーク通信ログ	イミュータブルストレージ	潜伏期間の動きを遡るため

5．企業規模別の現実的な対応指針

SplunkやSentinelは年間数千万円規模のコストになることもあり、すべての企業に同じ対策を求めることは非現実的だ。規模に応じた優先順位を整理する。

5-1．大企業（売上500億円以上・IT専任チームあり）

統合ログ管理ソリューションの導入が選択肢に入る規模だ。ただし最も多い失敗パターンは「ツールだけ導入して運用が空洞化する」ことだ。ツール導入と同時に、「誰がアラートを見て、どう動くか」というSOC（Security Operations Center）の運用体制をセットで設計しなければ、高額なシステムが機能しない飾りになる。

• 重要データ：Tier 0 / Tier 1の明確な分類と、RPO/RTOに基づく自動バックアップ設計
• ログ管理：SIEMツール導入（Splunk / Microsoft Sentinel等）＋SOC運用体制の整備
• 連動設計：バックアップ操作ログの別テナント保管を必須要件として設計

5-2．中堅企業（売上30〜500億円・IT担当者数名）

まずMicrosoft 365やAzure ADの監査ログを有効化し、90日以上保管する設定にするだけで、コストをほぼかけずに大きな改善が得られる。次のステップとして、Microsoft Sentinelの最小構成（重要ログだけを取り込む）が現実的な選択肢だ。

• 重要データ：バックアップツールで最重要データ（Tier 0）のみを対象に日次＋差分バックアップ
• ログ管理：Microsoft 365監査ログ有効化 → Sentinel最小構成 → 段階的に拡張
• 連動設計：クラウドストレージへのバックアップ操作ログの自動転送

5-3．中小企業（売上30億円未満・IT専任不在）

専任のセキュリティ担当者がいない環境では、「最低限これだけ」を確実に実施することが最優先だ。高額ツールより、基本的な設定変更とルールの徹底の方が費用対効果が高い。

• 重要データ：クラウドバックアップ（最重要データのみ）＋オフライン保管（USBや外付けHDD）
• ログ管理：VPN・ファイアウォールのログを90日以上保管 / Windows ServerのイベントログをNAS等に転送 / クラウドサービスの管理者操作ログを有効化
• 連動設計：バックアップと同じ場所にログを置かない（分離の原則だけは守る）

6．まとめ――整理すると、やるべきことは明快になる

本コラムで論じてきたことを、最後にシンプルに整理する。

論点	結論
「重要データ」の決め方	再生成不能×事業即効×法的義務の3問で絞り込む。「全部重要」は判断ではない。
決め方のプロセス	データからではなく、「止まったら死ぬ業務」から逆算する。IT部門だけで決めない。
ログ管理との関係	目的が違う別の戦略。重要データ保護はBCP、ログ管理はSOCの文脈で設計する。
唯一の連動ポイント	バックアップ操作ログは、バックアップとは物理的に別の場所に保管する。
企業規模と対応	高額ツールより「最重要データの特定」と「ログの分離保管」が先。規模に応じて拡張する。

「何を守るか」を決めることなしに、どんな高額なセキュリティツールも機能しない。ランサム時代における情報管理の出発点は、技術論ではなく、この問いへの経営の答えだ。

【最後に：自社の最重要データを確かめる問い】   明日、オフィスと全サーバーが消滅したとして、 USBメモリ1本分だけデータを魔法で復元できるなら、何を入れるか？   それが「顧客名簿」「未入金リスト」「直近のソースコード」であれば、 あなたの会社の最重要データは正しく見えている。