VPNを制するものがランサムウェアを制す！ 認証強化で防御率はどこまで上げられるのか？ 防御率99％への対策優先順位とロードマップを作る 第３回 クラウド・検証・検知編
第２回（認証選定・実装編）の振り返り
前回は、ランサムウェア対策の“中核”となる認証強化の実装について掘り下げました。
FIDOカードを全員に配布し、IDaaSでFIDO必須化、さらにPAMで権限昇格と横移動を止める。
この３点による二段構えの防御で、これまで「防げない」とされてきた以下の攻撃を、VPNを無理にZTNへ置き換えることなく、EDRの検知前に構造的にブロックできるという結論に至りました。
サプライチェーン攻撃
IoT機器を踏み台にした侵入
セッションハイジャック
オンプレミス環境を狙う典型的な攻撃の大半
つまり、侵入させない・突破させないというゼロトラストの本質を、現実的なコストと運用負荷で実現できることを示したわけです。
第３回では、ここまでで固めたオンプレミス側の防御に加えて、次の３つの領域を扱い、三部作としてのランサムウェア対策を完成させます。
クラウド側の対策
脆弱性診断による継続的な検証
バックアップと“最後の砦”としての検知
第五歩：クラウドの攻撃チェーンを潰す（SaaS／IaaSの権限管理）
オンプレミス側の突破をFIDOカード全員配布、IDaaSによるFIDOカード必須化とPAMによる権限昇格の防止でほぼ封じた今、攻撃者が次に狙うのはクラウド側のIDと権限です。
クラウドは便利である一方、ログイン経路が複数あり、攻撃者にとって入口が多い構造になっています。
ここでは、クラウドへの侵入経路を理解したうえで、SaaS／IaaSの権限管理によって攻撃チェーンをどのように断ち切るかを整理します。
1. SaaS／IaaSとは何か（簡単な整理）
● SaaS（Software as a Service）
企業が日常的に使うクラウドアプリ。
例：Microsoft 365、Google Workspace、Salesforce、Box、Slack
ID乗っ取りが最大のリスク
OAuthアプリの悪用が起きやすい
外部共有設定が攻撃に利用される
● IaaS（Infrastructure as a Service）
クラウド上のサーバー・ネットワーク・ストレージ。
例：AWS、Azure、GCP
管理者権限を奪われると全破壊される
APIキー漏洩が致命的
バックアップ削除が容易
どちらも
IDの乗っ取り → 権限昇格 → 破壊・窃取
という攻撃チェーンは共通です。
2. 「クラウドへの侵入経路」を理解する
クラウドにログインするとは、実際には
SaaS（Microsoft 365、Google Workspace、Salesforceなど）
または
IaaS（AWS、Azure、GCPなど）
にログインすることを意味します。
クラウドには複数のログイン経路があるため、攻撃者は弱い入口を狙って攻撃してきます。
① パスワード・MFA突破によるクラウドIDの乗っ取り
弱い認証では簡単にクラウドIDを奪われ、
攻撃者は正規ユーザーとしてクラウドに侵入します。
② OAuthアプリの権限悪用（SaaS）
OAuth は“ログインしない侵入”であり、FIDO/MFAでは止まらないため、
クラウド攻撃の中でも特に厄介です。
攻撃者が便利なアプリに偽装した悪意のある外部アプリを用意し、
ユーザーにアプリ連携を承認させます。
承認した瞬間、
攻撃者はログインせずにメール・ファイルへアクセスできます。
アプリ連携を解除しない限り攻撃者のアクセスは維持されます。
③ APIキー・アクセストークンの窃取（IaaS）
最も破壊力が大きい攻撃です。
開発者アカウントやCI/CD環境から漏れたキーを使って侵入し、キーに付与された権限次第でクラウド環境にフルアクセスが可能になります。
APIキーはパスワード・MFA・FIDOカードのすべてをバイパスするため、漏洩すると最も危険です。
④ ネイティブログイン（IDaaSを経由しない裏口）
IDaaSのFIDOカード必須化の保護を受けないため、攻撃者にとって最も狙われやすい入口です。
⑤セッションハイジャック
SaaSは長寿命のセッションを採用しているため、インフォスティーラー等でCookie やトークンを盗まれると、ログインなしで長期間侵入されます。
3. 通常ログインはIDaaSに統合してFIDOカード必須化する
クラウドへの通常ログインは、基本的にIDaaSに統合できます。
Microsoft 365 → Entra ID
Google Workspace → Googleアカウント（IDaaSとして機能）
Salesforce、Box、Slack → SAML/OIDCでIDaaS連携
AWS/Azure/GCP → SSO連携
つまり、FIDOカード必須化したIDaaSに統合すれば、クラウドへの通常ログインも自動的にFIDOカード必須になります。
4. ネイティブログインは“できるだけ排除”した上でFIDOカード必須化する
クラウドにはIDaaSを経由しない以下のような「ネイティブログイン」が存在します。これが攻撃者にとっての裏口です。
AWS root
Azureのローカル管理者
Google Workspaceのスーパーユーザー（IDaaS連携後も残るローカル管理者）
各種SaaSのローカル管理者
古い管理者アカウント
外部委託業者のアカウント
対策は、
① ネイティブログインは原則廃止
ローカルユーザー削除
ローカル管理者無効化
パスワードログイン停止
② 廃止できないものは「例外アカウント」として扱う
AWS root
SaaSローカル管理者
③ 例外アカウントは FIDOカード 必須化＋利用制限
FIDOカードでのみログイン可能
利用時にアラート
JIT（必要な時だけ有効化）
ログイン元IP制限
監査ログ強化
5. クラウド標準機能を組み合わせて権限昇格と横移動を止める
クラウドにはオンプレミスのPAMのような製品はありませんが、
クラウドは最初からPAM相当の機能を標準搭載しています。
標準機能を組み合わせて特権管理が実現できます。
目的はオンプレミスと同じです。
「特権操作を最小化し、必要な時だけ、必要な人に、必要な権限だけを与える」
● Just-In-Time（JIT）権限付与
管理者ロールを“常時付与”しない。
必要な時だけ短時間だけ付与する。
● Just-Enough-Administration（JEA）
管理者ロールを丸ごと付与せず、
操作単位で細かく権限を分割する。
● 特権操作時のFIDO再認証
管理者ロールのアクティベーション時にFIDOカードで再認証。
セッションを奪われても特権操作に進めない。
● ロール乱立の抑制と棚卸し
使われていないロールの削除
過剰権限の棚卸し
管理者ロールの最小化
● OAuthアプリの権限悪用を防ぐ
高権限アプリの棚卸し
外部アプリの承認は原則禁止
管理者が許可したアプリのみ利用可能にする（AllowList方式）高権限アプリのFIDO再認証
Microsoft 365 と Google Workspace は、外部アプリの OAuth 同意を“完全禁止”できる公式機能を備えています。これにより、ユーザーが勝手に外部アプリへ権限を付与することを構造的に防ぎ、OAuth フィッシングをほぼゼロにできます。
外部アプリの承認を禁止した後は、すでに同意済みのアプリを“必ず”削除（取り消し）する必要があります。
まとめ
オンプレミス側の突破をFIDOカードとPAMでほぼ封じたとしても、
攻撃者はクラウド側のIDと権限を狙ってきます。
クラウドは便利である一方、ログイン経路が多く、
「弱い入口を一つでも残すと突破される」 という構造を持っています。
第五歩では、このクラウド特有の攻撃面をすべて洗い出し、
IDaaS統合・ネイティブログインの排除・クラウド標準のPAM機能
を組み合わせることで、クラウド側の攻撃チェーンを構造的に断ち切ることができます。
クラウドはオンプレミス以上に“権限の世界”なので、
権限管理を正しく設計すると攻撃者はほぼ動けなくなります。
防御率については、第三歩（40％）＋第四歩（+10）に続き、
第五歩ではクラウド側の主要な侵入経路をほぼ封じるため、
防御率は+20％向上 し合計70％の攻撃を構造的に防ぎます。
第六歩：パスワードマネージャによるインフォスティーラー対策とレガシー認証の実質FIDO化
第五歩まででオンプレミスとクラウドの両方において、
ログインはFIDOカード必須化を徹底し、
侵入後の権限昇格も封じる二段構えの防御を構築しました。
セッションハイジャックも実質的に無効化されています。
しかし、それでもレガシー認証（ID＋パスワード）が残っている限り、
ランサムウェア攻撃の主要ルートは閉じていません。
インフォスティーラー経由の攻撃の大半は「パスワード窃取 → レガシー認証突破」
ランサムウェア攻撃のうち、インフォスティーラー経由の侵入は約 30〜40％を占め、そのうちセッションハイジャック利用は10～20％程度と推定されています。
つまり残りの大部分は：
パスワード窃取 → レガシー認証突破 → SMB横展開
という“本丸ルート”で成立しています。
だからこそ、どのレガシー認証が初期侵入に使われているか を理解することが重要になります。
ランサムウェア対策として“最優先で守るべきレガシー認証”
1位：SMB（ファイル共有）
理由：SMB は FIDOが一切効かない領域 であり、横展開の大動脈です。
破られた瞬間に全社暗号化が成立する。最優先で保護する必要があります。
NAS
ファイルサーバ
バックアップ領域
管理共有（C$、ADMIN$）
弱い or 盗まれたパスワードで起きること：
他端末へランサムウェアをコピー
バックアップ破壊
ドメインコントローラへ到達
2位：オンプレAD（ドメインアカウント）
理由：盗まれると横展開の“万能鍵”になる。
IDaaS経由にできないため、レガシー認証のまま残っています。
ドメインユーザーのパスワード
サービスアカウント
管理者アカウント（最悪）
盗まれると以下がすべて開く：
SMB
RDP
PsExec
WMI
3位：SaaS / IaaS のレガシー認証（IDaaSを経由しない部分）
理由：FIDO必須化の“例外”が残っていると突破される。
SMTP/IMAP
古いAPIキー
Basic認証
管理コンソールのバックドア的ログイン
4位：NAS / ルーター / IoT の管理パスワード
理由：弱いパスワードが多く、バックアップ破壊に直結する。
IDaaS経由にできないため、レガシー認証のまま残っています。
NAS管理者パスワード
ルーターの管理画面
ストレージの管理UI
これらは SMB と同じく バックアップ破壊の入口 になります。
これらのレガシー認証が突破された場合の被害は甚大で、第五歩までの対策が瓦解するくらいの破壊力があります。
そして、インフォスティーラーはレガシー認証の情報窃取のツールであって、パスワードが弱ければインフォスティーラーを使うまでもなく簡単に突破されてしまいます。
最優先すべきはレガシー認証のパスワード強化！
表面的なインフォスティーラー対策ではなく、
本質的には以下を徹底することが重要です。
長くて複雑なパスワードを使う
パスワードを覚えない（パスワードマネージャで管理）
認証情報を盗まれない場所へ保管する
パスワードマネージャのログインをFIDOカード必須にする
その結果として、
インフォスティーラーでも盗めなくなる
というのが正しい対策になります。
レガシー認証の保護の手順（実質FIDO化）
レガシー認証は FIDO カードの保護が届かない領域であり、
ランサムウェアの横展開・バックアップ破壊・ドメイン支配の“本丸”となります。ここを守るために、以下の5つの工程で レガシー認証を“実質FIDO化” します。
1. ランサムウェアで保護が必要なレガシー認証のリストアップ
まずは 攻撃者が狙う順番 に沿って、
守るべきレガシー認証をすべて洗い出す。
SMB（NAS、ファイルサーバ、バックアップ領域、管理共有）
オンプレAD（ドメインユーザー、サービスアカウント、管理者）
SaaS/IaaS のレガシー認証（SMTP/IMAP、古いAPIキー、Basic認証）
NAS / ルーター / IoT の管理パスワード
“FIDOが効かない領域”を可視化することが最初の工程。
2. パスワードマネージャの選定
レガシー認証のパスワードは、
人間が覚えるのではなく、FIDOで守られた金庫に閉じ込める。
選定基準は次の3つ：
インフォスティーラー耐性があること
IDaaS連携で「FIDOカード必須」にできること
パスワードマネージャ単体ログインも「FIDOカード必須」にできること
これにより、
レガシー認証のパスワードは“FIDOで守られた場所”にしか存在しなくなる。
3. ブラウザ／旧パスワードマネージャからの認証情報の移行とパスワード強化
Chrome/Edge/Firefox の保存パスワード
旧パスワードマネージャのデータ
これらを 新しいパスワードマネージャへ移行 しパスワードマネージャの機能を使って長くて複雑なパスワードに変更する。
ここが非常に重要で、
「強いパスワードに変更する」こと自体がレガシー認証保護の核心です。
4. パスワードマネージャの IDaaS 連携設定と FIDOカード登録
IDaaS 側で「パスワードマネージャ＝FIDOカード必須」に設定
パスワードマネージャ単体ログインも FIDOカード必須に設定
これにより、
レガシー認証のパスワードは“FIDOの外側に出ない構造” が完成する。
5. ブラウザ／旧パスワードマネージャから認証情報を削除し、自動保存をOFF
ブラウザの保存パスワードを削除
自動保存機能をOFF
旧パスワードマネージャをアンインストール
インフォスティーラーが盗める場所にレガシー認証情報が存在しなくなる。
まとめ
第五歩まででクラウドとオンプレミスのログインはFIDO化され、
セッションハイジャックもほぼ無効化されました。
しかし、
レガシー認証突破による侵入ルートという大きな穴が残っていました。
第六歩では、保護が必要なレガシー認証をリストアップし、
パスワードマネージャで長くて複雑なパスワードへ変更するとともに、
レガシー認証を実質FIDO化することで、
インフォスティーラーでも盗めないレガシー認証を実現します。
防御率については、レガシー認証突破による侵入ルートを塞ぐことで、
第六歩で防御率は+10％向上 します。
これにより、合計80％の攻撃を構造的に防ぐことができます。
第七歩：FIDOカードを使ったクラウド同期アカウントの保護
第六歩ではインフォスティーラーを使った認証情報の窃取について触れました。このインフォスティーラーよりも強力で、現在では必ず対策が必要になるのが、クラウド同期アカウントを悪用した攻撃です。
クラウド同期アカウントは「本人の根本権限」である
クラウド同期アカウントとは、具体的には次の3つです。
Apple ID
Google アカウント
Microsoft アカウント
これらは単なるログインアカウントではありません。
現代のデジタル環境では、本人のすべてのデバイス・データ・認証情報を束ねる“根本権限”になっています。
例えば、これらのアカウントには次の情報が紐づいています。
パスワードや同期パスキー
写真・ファイル・連絡先・メモ
メール・カレンダー
サブスクリプションや支払い情報
などで、この3つのアカウントが奪われることは「本人を乗っ取られる」ことと同義になります。
いったん乗っ取られると、攻撃者は本人としてあらゆる操作が可能になり、パスワードを変更されたり、端末を初期化されたりして、
奪還することすら非常に困難になります。
クラウド同期アカウントはFIDOカードで保護する
Apple、Google、Microsoftは、これらのアカウントを保護するために
二要素認証としてFIDOセキュリティキー（FIDOカード）を公式にサポートしています。
ただし重要なのは、
FIDOカードを登録しただけではFIDOカード必須にはならない
という点です。
多くの読者が誤解しやすい部分なので、ここを明確にしておきます。
また、完全なFIDOカード必須化を行うと、カード紛失時の復旧が難しくなるため、予備カードの作成や復旧コードの取得が必要です。
【Apple ID の場合】
FIDOカード + 盗難デバイス保護 の“2つ”が必須
Apple ID は、初回登録時に FIDOカードを2枚登録する必要があります。
これにより、遠隔から Apple ID にサインインする際には FIDOカードが必須になります。
しかし、問題は iPhone の機種変更プロセスです。
新しい iPhone には FIDOカードなしで Apple ID を移行できる
移行後の端末には誰の生体情報でも登録できる
登録された生体情報で“本人”と判断され、
同期パスキーを含むすべての操作が可能になる
つまり、FIDOカードだけでは 端末側の本人確認が弱いという構造的問題があります。
これを解決するために Apple は 「盗難デバイスの保護」 を iOS 17.3 で導入しました。
この機能を ON にすると：
重要な操作には生体認証での本人確認が必須
生体情報の追加登録にも本人確認が必要
端末を奪われても本人としての操作ができない
つまり、Apple ID を守るには
① FIDOカード登録
② 盗難デバイスの保護を ON
この2つがセットで必要です。
【Android の場合】
生体認証による本人確認ができる機種は限られる
Android も Appleの盗難デバイスの保護 と同様の仕組みを一部導入していますが、
メーカーごとに仕様が異なる
OSアップデートタイミングがメーカーごとにバラバラ
生体情報追加で本人確認を強制できる機種は限られる
という現状があります。
そのため、Android では、
クラウド同期アカウントの保護が iPhone より甘くなる傾向があります。
【Google / Microsoft の場合】
FIDOカード登録後に“弱い認証方法を削除”する必要がある
Google アカウントや Microsoft アカウントは、
FIDOカードを登録しても既に登録したサインイン時の認証が残っています。
SMS
メール
認証アプリ
バックアップコード
これらが残っていると、攻撃者は
弱い認証を使ってアカウントへのサインインができてしまうため、
FIDOカードを登録した後は、
サインイン時の弱い認証を停止・削除することが必須です。
予備の FIDOカードは“1枚で複数人分”登録できる
FIDOカードは空き容量にもよりますが、
100個以上の秘密鍵を登録可能です。
そのため、
職場単位で1枚の予備カードを共有
家族全員分を1枚にまとめる
といった運用が可能です。
サインイン時には
FIDOカード
各個人の ID・パスワード
の両方が必要になるため、
予備カードに複数人分を登録しても安心です。
まとめ
クラウド同期アカウントは 本人の根本権限
奪われると 本人としての全操作が可能
インフォスティーラーより強力で、今後悪用が増えると予想される
FIDOカードで保護することが必須
Apple は FIDOカード + 盗難デバイス保護 がセット
Google / Microsoft は 弱い認証方法の削除 が必須
予備カードは 1枚で複数人分登録可能
防御率については、クラウド同期アカウントをFIDOカード必須化で保護することで、第七歩の防御率は+10％向上 します。
これにより、合計90％の攻撃を構造的に防ぐことができます。
そして何より重要なのは、
第七歩まで対策済みの組織は攻撃者にとって“割に合わないターゲット”になるため攻撃をあきらめる可能性が非常に高いという点です。
第八歩：脆弱性診断で設定ミスや未登録の穴を塞ぐ
第七歩までで、企業の防御構造はすでに“攻撃の大半を跳ね返す形”に整っています。しかし、どれほど美しい構造を描いても、現場の設定や運用がズレていれば防御率は一気に落ちてしまいます。
そこで必要になるのが、第八歩の「脆弱性診断」です。
ここでは、単なるスキャンではなく、
第一歩〜第七歩で構築した防御構造が“実際にその通り動いているか”を保証する工程として位置づけます。
1. 設定ミスの検出だけでは不十分：構造の整合性を確認する
診断の目的は「設定ミス探し」ではない。
むしろ重要なのは、構造モデルと現場の実態が一致しているか の確認である。
想定していない経路で内部に入れるルートが残っていないか
認証強化の例外が“意図した例外”と一致しているか
管理者権限の割り当てが構造モデルと矛盾していないか
外部委託業者のアクセス経路が“裏ルート化”していないか
これは「構造の美しさ」を重視する本モデルにおいて、
第八歩の核心となるポイントである。
2. 未登録端末だけでなく“影のネットワーク”も探索する
攻撃者が最も好むのは、
企業が把握していない設定・経路・アカウントだ。
そのため、診断では以下も対象に含める。
未登録の Wi-Fi アクセスポイント
使われていないが生きている VLAN
退職者アカウントの残骸
古い VPN 設定が残った端末
監視されていない IoT・医療機器・プリンタ
これらは“影のネットワーク”として、
第一歩〜第七歩の防御をすり抜ける典型的な経路になる。
影のネットワークを発見した場合は、まず即時にネットワークから隔離する。その上で、用途が不明な機器は廃棄し、必要な機器は再登録して正規の管理下に戻し、台帳に統合する。
3. 例外の棚卸し：例外こそ攻撃者の入口
例外は必ず増える。そして例外こそ攻撃者が最も狙うポイントである。
まず最初に確認すべきは「例外が正式に記録されているか」である。
記録されていない例外は、構造モデルの外側に存在する“野良例外”であり、
攻撃者にとって最も利用しやすい入口になる。
そのため、例外台帳に載っていない例外は即時是正の対象とする。
診断では以下を棚卸しする：
例外の理由
例外の期限
例外の代替防御
例外の承認者・承認日時
実際の運用が理由と一致しているか
例外管理は、構造の健全性を保つための“定期メンテナンス”である。
4. 境界の二重化が機能しているかを検証する
第一歩〜第七歩で構築した境界（認証・ネットワーク・端末）は、
二重化されていることが前提だ。
境界の二重化とは、認証境界・ネットワーク境界・端末境界の三つの境界が
それぞれ独立して攻撃を止める構造を指す。
どれか一つが突破されても、次の境界で必ず止まるため、
侵入後の横移動やセッションハイジャックを構造的に防ぐことができる。
診断では以下を確認する：
古い認証方式が裏で生きていないか
ネットワーク分離しても、管理者用の裏ルートが残っていないか
端末制御の例外が“実質無制限”になっていないか
裏ルートの残骸は、攻撃者にとって最高の入口になる。
発見した場合はまず該当機器や経路を即時にネットワークから隔離し、
その上で「影のネットワーク」なのか「例外」なのかを分類し、
それぞれの処理フロー（廃棄・再登録・台帳統合）に従って処理し、承認者と承認日時を含めて記録する。
5. 外部・内部からの攻撃シナリオを再現する
遠隔診断で十分だが、外部視点と内部視点の両方を必ず含める。
外部からの侵入 → 内部横移動
古い SMB や VPN 設定を悪用した認証回避
管理者端末からの権限昇格
IoT・医療機器からの内部 pivot
これは“攻撃者視点の QA（品質保証）”として、診断の質を大幅に高める。
遠隔診断にする理由は、診断能力のある経験者に任せつつ、費用を抑えられるため合理的である。
内部端末1台を“攻撃者視点”として扱う内部診断であれば遠隔からでも十分な診断が可能です。
診断頻度は月1回の軽量診断 + 四半期の深度診断
費用を抑えつつ品質を担保するため、以下の二段構えが最適です。
月1回（軽量）
外部・内部の軽量スキャン
未登録端末の探索
設定の差分チェック
例外の棚卸し
四半期に1回（深度）
攻撃シナリオ再現
構造の整合性チェック
境界二重化の検証
この二段構えにより、
日常的な劣化を早期に検知しつつ、構造全体の健全性を保証できる。
まとめ
第八歩は、第一歩〜第七歩で構築した防御構造の“品質保証（QA）工程” です。
設定ミス
影のネットワーク
例外の暴走
裏ルートの残存
構造と運用のズレ
これらを定期的に診断し潰すことで、
防御構造が“常に正しく動いている状態”を維持できます。
防御率については、脆弱性診断で防御構造の健全性を担保することで、
第八歩の防御率は+5％向上します。
これにより、合計95％の攻撃を構造的に防ぐことができます。
第九歩：バックアップの導入
破壊されないバックアップと、復旧のための“前提条件”を整える
ランサムウェア攻撃では、データ暗号化よりも先にバックアップ破壊が行われる。攻撃者にとってバックアップは“身代金ビジネスの障害”であり、破壊されていれば組織は復旧できず、支払いに追い込まれる。
したがって、バックアップは単に「取っているか」ではなく、
① 被害前の状態に戻せること（復旧可能性）
② 攻撃者に破壊されないこと（生存性）
この2つが揃って初めて意味を持つ。
本記事の本論は「インシデントを発生させないこと」であり、
復旧手順そのものは対応マニュアル側で扱うべきもので詳しくは触れない。
ここでは、復旧が可能になるための“前提条件”として、
破壊されないバックアップの構造と、最低限の初動だけを扱う。
1. バックアップ破壊の構造を理解する
バックアップを破壊するには、攻撃者は次の工程を踏む必要がある。
侵入
権限昇格
横移動
バックアップ領域への到達
バックアップ破壊
つまり、バックアップ破壊は“高度な特権奪取”が前提になる。
さらに第六歩で示したような
「特権不要でバックアップに直接アクセスできるルート」
（NAS の弱い認証、SMB 共有、管理者パスワードのブラウザ保存など）
を塞いでおくことが大前提となる。
2. オンプレミスとクラウドのバックアップは攻撃経路が独立している
バックアップを破壊するには、攻撃者は次のどちらかの特権を奪う必要がある。
オンプレミス側の特権
クラウド側の特権
バックアップ破壊はランサムウェアの自動機能ではなく、
特権を奪取した攻撃者が手動で行う作業である。
特権を奪われなければ、攻撃者にはバックアップがどこにあるかさえ見えない。
従って、攻撃経路が異なるオンプレミスとクラウドの両方にバックアップを保存すると、両方が破壊される可能性は極めて低くなる。
これは単なる“多重化”ではなく、
攻撃経路を考慮した多重化であり、構造的に強い。
3. 物理的バックアップも依然として有効
NAS や外付け HDD にバックアップし、
普段はネットワークから切り離しておく方法も有効だ。
メリット：破壊されにくい、コストが低い
デメリット：運用負荷が高い、接続の瞬間にリスクがある
組織の規模や運用能力に応じて選択すればよい。
4. 何をバックアップするかも重要
インシデント発生後は、ネットワークを遮断し、
すべての端末・プリンタ・通信機器が“侵害の可能性あり”として長期間利用停止になる。
そのため、データだけでなく、次のような“復旧のためのバックアップ”も重要になる。
重要端末のクローン（SSD/HDD）を作成する
重要端末については、事前に内蔵のSSD/HDDのクローンを
クローン作製ソフトを使って別のHDDまたはSSDに作成しておくことが推奨される。
インシデント時は物理交換することで重要端末が即時復旧できる。
元のSSD/HDDは証拠保全として保持する。
これはフォレンジック（証拠保全）と事業継続（即時復旧）の両方を同時に満たすことができる、唯一かつ非常に有効な方法である。
5. 通信手段のバックアップを確保する
バックアップというとデータの話に見えるが、
実際には通信手段のバックアップがなければ復旧は始まらない。
インシデント時に長期間使えなくなるもの：
社内メール
社内ネットワーク
社内電話（IP-PBX）
IDaaS 経由のクラウドサービス
社用スマホ（調査対象になる）
つまり、組織は“完全に孤立”する。
だからこそ必要なのが
IDaaS を経由しない FIDOカード認証で使える外部サービス（Salesforce など）を事前に確保しておくこと。
これにより：
IDaaS が落ちてもログインできる
外部との連絡が維持できる
復旧チームの指揮系統が保たれる
これは“生存系の通信手段”であり、バックアップの一部と考えるべきだ。
6. 非常時のための“代替デバイス”を準備する
用意したFIDOカードは iPhone と Windows では安定して動くが、
Android の NFC 接続では現状安定して使えない。
そのため、次のような“通信用デバイスのバックアップ”が必要になる。
①中古 iPhone を SIM なしで数台確保
FIDO カードが確実に動く
必要時に社用スマホの SIM を差し替えて使える
モバイル Wi-Fi でも運用可能
セキュリティモデルが強固で侵害リスクが低い
②USB 接続の FIDO セキュリティキー
Android でも利用可能で、個人スマホでも使える。
③モバイル Wi-Fi
社内ネットワーク遮断時でも外部 SaaS にアクセスできる。
これらを組み合わせることで、
“IDaaS・社内ネットワーク・社用スマホのすべてが死んでも動く通信経路”
を確保できる。
7. インシデント発生時の“最小限の初動”
復旧作業そのものは専門ベンダーが担当するため、
本記事では復旧手順の詳細には踏み込まない。
インシデント発生時に必要なのは、次の3つだけである。
① 復旧サポート（外部ベンダー）への即時連絡
連絡手段は Salesforce（FIDOカードログイン）や代替端末で確保
連絡がつかない場合は複数ルートを試す
② 内部ネットワークの“最小限の遮断”
感染拡大を防ぐための LAN 側の遮断は実施
ただし全面遮断は専門家の指示を待つ
端末の電源は落とさない（証拠保全）
③ バックアップの更新停止（即時）
上書き停止
同期停止
世代保持の固定
外部通信は復旧の生命線であり、
むやみに止めず、専門家の指示を待つのが最も安全である。
まとめ
バックアップは“生存戦略の前提条件”である
バックアップとは、
データのバックアップだけではなく、
認証手段のバックアップ
通信手段のバックアップ
端末のバックアップ
を含む“総合的な生存戦略”だ。
第九歩は、単に「バックアップを取りましょう」ではなく、
攻撃者が破壊できない構造を作り、
復旧のための指揮系統と通信手段を維持するための前提条件を整えるステップである。
防御率については、第九歩は直接防御しないためカウントしません。
第十歩：EDRやウイルス対策ソフトによる最後の砦
ドメル攻撃が消え、それでも来る攻撃を99％防ぐ
第九歩までの構造的防御によって、
攻撃者が企業ネットワークに侵入するための主要な工程、
認証突破、横移動、ドメイン特権奪取、バックアップ破壊、クラウド乗っ取りは物理的に不可能となり、
ローカル権限昇格も構造的に極めて困難となった。
その結果、従来のEDRが大量に検知していた ドメル攻撃（ドメイン内攻撃） はそもそも成立しない概念となる。
しかし、攻撃そのものが完全に消えるわけではない。
攻撃者は依然としてローカル端末に対して“残りカス”の攻撃を仕掛けてくる。
1. ドメル攻撃は来ない。しかし“カス攻撃”は来る
第九歩までの構造により、以下の攻撃は完全に不可能になる。
Mimikatz
Pass-the-Hash
Pass-the-Ticket
Kerberoasting
LSASSダンプ
AD探索
lateral movement
ドメインコントローラ侵害
バックアップ破壊
ドメイン特権奪取は不可能。ローカル権限昇格も構造的に極めて困難
つまり、ドメル攻撃は歴史から消える。
しかし、それでも攻撃者は諦めない。
彼らができるのは、次のような “ローカル限定の空虚な攻撃”だけだ。
本記事ではこれを比喩的に「ギレン攻撃」と呼ぶ。
2. それでも来るギレン攻撃
① 軽量インフォスティーラー
ブラウザのCookieやパスワードDBを盗む
しかし盗んでも認証突破は不可能
横移動も不可能
企業被害にはつながらない
② キーロガー
キーボード入力を記録しようとする
管理操作にパスワードや秘密文字列を使用しないため、
キーロガーが盗むべき情報そのものが存在しない
③ 単発ランサムウェア
ローカルの一部ファイルを暗号化
企業データにはアクセスできない
バックアップ破壊もできない
④ 不審スクリプト（PowerShell, WSH）
C2通信を試みる
しかしネットワーク境界で遮断
認証突破できないため何もできない
⑤ OneNote・マクロ型の単発感染
端末内で実行される
しかし横移動も特権奪取もできない
これらはすべて “ギレン攻撃”＝演説だけで終わる空虚な攻撃 であり、
企業ネットワークに影響を与えることはできない。
3.ウイルス対策ソフトは“掃除係”として働く
第八歩までの構造的防御によって、攻撃者が企業ネットワークに到達する経路はすべて封じられた。
しかし、ローカル端末に侵入する軽量マルウェア（インフォスティーラー、単発ランサム、マクロ型マルウェアなど）がゼロになるわけではない。
ここで役に立つのが ウイルス対策ソフト（Defenderで十分） である。
既知のスティーラー
既知のランサムウェア
不審な実行ファイル
マクロ型の既知マルウェア
こうした“残りカス”のマルウェアは、
ウイルス対策ソフトが自動的に掃除してくれる。
ウイルス対策ソフトが失敗しても企業被害にはつながらないため、
無料のDefenderで十分 という合理的な世界が成立する。
4. EDRは“ギレン攻撃”を確実に止める
ここでEDRが本来の役割を発揮する。
不審プロセスの生成
権限昇格の試行
不審なファイル暗号化
C2通信の試行
スクリプトの異常挙動
これらはEDRが最も得意とする領域であり、
第八歩までの構造によってノイズが消えているため、
EDRは100％近い精度で検知できる。
つまり、
EDRは“本物の攻撃だけ”を確実に止める最後の砦になる。
5. そして全体として99％の攻撃が防がれる
第二歩〜第三歩で認証経由の侵入阻止で40％
第四歩で権限昇格阻止で10％
第五歩～第八歩でクラウド、脆弱性診断で45％
第八歩までの合計で攻撃チェーンの95％を構造的に破壊
残り4％のローカル攻撃はEDRが確実に止める
結果として 99％以上の攻撃が防がれる
これは“理論値”ではなく、
実際に第十歩まで実装したときに現場で観測される現象 である。
まとめ
第十歩の最大の驚き：EDRアラート激減後の“静寂”
ドメル攻撃が消え、ギレン攻撃だけが来る世界では、
EDRアラートは劇的に減少する。
誤検知が消える
ノイズが消える
SOCが疲弊しない
本物の攻撃だけが浮かび上がる
そして最後に訪れるのは、
“静寂”という最大の驚き である。
おわりに
第十歩を書き終え、これで私の提案するランサムウェア対策、
「おきじー構造的防御モデル」（Oki-G Structural Defense Model）
は Ver.1.0 として完成しました。
おきじーモデルは、
FIDOカードによる最高強度の認証統一
IDaaSで外部入口・PAM・クラウドのログインをすべてFIDO必須化し、サプライチェーン攻撃を遮断
PAMのFIDO認証でセッションハイジャックを無効化
クラウドは標準機能の設定で特権を保護
パスワードマネージャでレガシー認証を実質FIDO化
クラウド同期アカウントをFIDOカードで保護
脆弱性診断で防御構造の品質保証
バックアップをオンプレミスとクラウドで二重化
EDRで構造的に防ぎきれない残余攻撃（いわゆる“ギレン攻撃”）を検知
という構造的防御により、ランサムウェアの攻撃チェーンを徹底的に潰すモデルです。
今まで「防ぐのは無理」とされてきた攻撃を、
市販ツールと設定だけで今すぐ実施でき、
初期設定さえ専門家に委託すれば、あとは現場の負担をほとんど増やさず運用できます。
現場の作業はパスワード入力からFIDOカードのタッチに変わるだけ。
VPN も FIDO カード必須化と PAM による権限制御で安全に使えるため、
無理に廃止したり ZTN へ全面移行する必要はありません。
予算を最小化しつつ、小規模組織から大企業まで導入できる現実的なランサムウェア対策です。
もちろん、理論からPoC、実証へ進む過程では、
ツールの対応状況や連携度によって理想通りにいかない部分も出てくるでしょう。
今後は皆さんと情報交換しながら完成度を高めていく段階です。
ツール選定などでお力になれることがあれば、ぜひご連絡ください。
この対策は、すべてを一度に導入する必要はありません。
まずは既存対策の見直し・再設定から始め、予算の範囲で段階的に進められます。
この三部作が、セキュリティに悩む方々のランサムウェア対策マニフェストとして役立つことを願っています。
ランサムウェアは抑え込める。
構造で守る時代を、一緒に作っていきましょう！
