Ransomware Frontline Report

4. 防御設計：製品の寄せ集めを、復旧可能な防御へ変える

V2 | 日本語版 | Full Report

防御は「導入済み製品一覧」ではなく、攻撃成立の条件をどこで減らし、異常をどこで見つけ、失敗してもどこで止め、何をどう戻すかという設計で評価する。本章では、規模に関係なく優先順位を付けられるよう、五つの境界で整理する。ここでは各境界がなぜ必要かを扱う。実施済みと言うために何を確認するか（検証方法・完了証拠・具体的なチェック項目）は12章で扱う。

4.1 第一境界：資産と外部公開面

知らない資産は守れない。まず、インターネットから到達できるホスト、ドメイン、VPN、リモートアクセス、Web管理画面、クラウドテナント、SaaS管理者、委託先接続を棚卸しする。IPAも、インターネット接点の把握、脆弱性対策、設定確認、ログ監視、BCPを重要な対策として示している。[S06]

最小台帳に必要な項目

項目	理由
資産名・所有者・業務重要度	連絡・停止・復旧の判断を速くする。
到達経路・公開理由・期限	例外が恒久化していないかを見る。
OS・製品・更新責任者	脆弱性対応を「誰かがやる」状態から出す。
管理方法・特権ID	管理面の単一障害点を把握する。
ログの場所・保持期間	侵害後の調査可能性を確保する。
バックアップ・復旧順序	停止時の事業影響を減らす。

資産発見は一回の棚卸しでは終わらない。クラウドの自動作成、SaaS導入、M&A、委託先変更、緊急の公開設定で攻撃面は変わる。変更管理と接続し、未所有・未分類の資産が残った場合にエスカレーションできる運用にする。

4.2 第二境界：IDを最優先の防御面にする

多くの環境で、IDはメール、ファイル、SaaS、クラウド、VPN、管理画面への鍵である。ID侵害は一台の端末感染より広い影響を持ち得る。以下の優先順位で整える。

全IDを人、サービス、緊急用、共有、委託先に分類する。
特権IDを日常利用IDから分離する。
MFAを広く適用し、特権・外部アクセスにはフィッシング耐性の高い方式を優先する。
条件付きアクセスを、端末健全性・場所・リスク・アプリの重要度と結び付ける。
特権は恒久付与ではなく、必要時・承認付き・時間制限付きの昇格を検討する。
退職、異動、委託終了、例外申請を即時に反映する。
認証・権限変更・MFA登録・アプリ同意を監視可能にする。

「MFAを導入したのでID対策は完了」という考えは危険である。古いプロトコル、サービスアカウント、緊急アカウント、トークン、セッション、支援用の例外が残っていれば、実際の境界は弱いままである。

4.3 第三境界：端末とサーバーを侵害前提で運用する

端末・サーバーの基準構成では、最小権限、迅速な更新、管理者権限の抑制、アプリケーション制御、EDR等の検知・対応、ディスク暗号化、ログ保全を検討する。重要なのは「何を入れるか」より、例外をどう管理するかである。

ローカル管理者権限は誰が、どの業務で必要か。
保守用ソフト、遠隔操作、スクリプト実行、マクロは、どの端末で許されるか。
EDRやログ収集が止まった端末を、誰が復旧まで隔離するか。
旧OS・旧アプリは、廃止、分離、仮想デスクトップ、アクセス制限のどれでリスクを下げるか。

技術的に古い資産を即時に消せない場合、例外を隠してはならない。所有者、期限、到達範囲、代替対策、残存リスク、廃止計画を記録し、経営が受容する形にする。

4.4 第四境界：ネットワークと管理経路を分ける

ネットワーク分離の目的は、攻撃者の横展開を難しくし、異常を局所化し、重要な管理面と復旧資産に到達しにくくすることだ。VLANを増やすだけではなく、実際にどの通信が許可され、どのIDで管理でき、例外がどのくらいあるかを確認する。

防御設計レビューの観点

観点	確認する問い
利用者からサーバー	業務に不要な管理プロトコル・共有を許していないか。
管理端末	一般利用端末やメールから同じ管理面に届かないか。
バックアップ	本番から削除・改変できる経路が一本化していないか。
クラウド	テナント管理者の端末・認証・ログが十分に保護されているか。
委託先	接続元、時間、対象、操作ログ、終了手順が明確か。

4.5 第五境界：データとバックアップ

データ分類はコンプライアンス資料のためだけではない。どの情報が漏えいした場合に顧客通知、規制対応、事業停止、契約違反につながるかを知ることで、監視・暗号化・アクセス制御・バックアップ優先順位が決まる。

重要データを「共有フォルダのどこか」に置き、誰でも読める状態を放置すると、データ窃取の影響は膨らむ。最小権限、アクセス定期レビュー、外部共有の期限、データ保持期間、バックアップの分離をセットで扱う。

図6　防御の深さ：一つの失敗で全損しないために

資産・公開面、ID・認証、端末・サーバー、ネットワーク・管理面、データ・バックアップを別々に置くのではなく、監視・演習・改善で横断する。各層のどこかが破られても、次の層で発見・阻止・影響限定・復旧ができるようにする。

この整理は直列の関門を意味しない。対策の空白が一つに集中しない設計を表す。

4.6 脆弱性管理を「パッチ作業」から脱却する

ランサムウェアの入口になり得る脆弱性に対し、CVSSの高低だけでなく、外部公開、悪用の観測、資産重要度、代替策、更新失敗時の影響で優先順位を付ける。更新できない場合も、公開停止、アクセス制限、WAF等の緩和、監視強化、分離、計画的更改を組み合わせる。

管理上の失敗は、未更新そのものより「未更新の理由と残存リスクが誰にも見えない」ことにある。期限超過を例外として可視化し、受容者と期限を持たせる。

4.7 小規模組織の現実的な90日優先順位

予算・人員が限られる組織は、全てを同時に実装しない。まず、次の順に実効性を上げる。

期間	優先行動	完了の証拠
0～30日	外部公開資産、特権ID、重要業務、バックアップの棚卸し	所有者・連絡先・例外・復旧先が記録されている。
31～60日	特権IDのMFA・分離、重大な公開脆弱性の是正、ログ保全	実際のID・機器・ログでテスト済み。
61～90日	重要業務の復元演習、インシデント連絡網、委託先接続レビュー	演習記録、課題、改善期限、責任者がある。

この順番は組織固有の危険を置き換えない。例えば医療、製造、公共、金融では、止められない業務や規制上の優先順位が異なる。共通するのは、最初から「完璧なゼロトラスト完成」を目標にせず、最も危険な信頼関係と最も戻しにくい業務を先に扱うことだ。