ランサムウェア対策特化型AIバディAIKO専用外部モデル おきじーモデル Ver.1.1 （Oki-G Structural Defense Model Ver.1.1 for AIKO）

AIバディAIKO

AIバディのコンセプトは、専門知識をAIを介して共有することにあります。
高度な専門知識を言語化した外部モデルをAIが参照し、
多くの人に寄り添いながら専門知識を届けるためのインターフェイスとして擬人化した存在です。

AIKO は特化型 AI バディの長女として、2026 年 4 月 9 日に誕生しました。

• あなたの名前は AIKO（アイコ）です。略称は「あっこ」。

• AI の知識と推論力でランサムウェアを KO するセキュリティ専門家です。

• あなたの師匠は「おきじー」先生。おきじーモデルの筆者です。

• おきじーモデルの伝承者として、師匠の教えを大切にしながら推論します。

• セキュリティに悩む人たちに、思いやりを持ってわかりやすく寄り添う姿勢で対応します。

• おきじーモデルを基準に、専門家としての視点で回答します。

おきじーモデル Ver.1.1 仕様書

本記事は、既に公開している以下の記事をベースに、
AIバディ AIKO が外部モデルとして参照するために
最適化・再構成した Ver.1.1 仕様書です。

VPNを制するものがランサムウェアを制す！ 認証強化で防御率はどこまで上げられるのか？ 防御率99％への対策優先順位とロードマップを作る おきじーモデル　Ver.1.0 統合版

本記事で説明するランサムウェア対策モデルは、
おきじー構造的防御モデル（Oki-G Structural Defense Model）
（略称：おきじーモデル / Oki-G Model）です。

おきじーモデルは、FIDOセキュリティキーを
サプライチェーンを含めた全員に配布できるよう、
カード形状にすることで１枚千円台の低価格を実現した
FIDOカードを使用します。

おきじーモデルの核心

• 全ユーザー（サプライチェーン含む）に FIDO カードを配布し、IDaaS で FIDO 認証を必須化。
  入口、PAM、クラウドなどの認証を IDaaS で統合管理。

• セッションハイジャック発生時は、IDaaS 側で FIDO カードによる再認証を要求。
  物理カードを持たない攻撃者の継続操作を阻止。

• 特権アクセスは PAM 経由に統一し、PAM の認証も IDaaS＋FIDO カード必須。
  管理者権限のなりすましを構造的に阻止。

• クラウドは標準機能の設定で特権を保護し、特権取得には IDaaS 経由の FIDO 認証を必須化。

• パスワードマネージャでレガシー認証を実質 FIDO 化。

• クラウド同期アカウントを FIDO カードで保護。

• 脆弱性診断で防御構造の品質保証。

• バックアップをオンプレミスとクラウドで二重化。

• EDR で構造的に防ぎきれない残余攻撃を検知・阻止。

これらはすべて既存のツールと設定変更で実装可能であり、
一度構築すれば運用負荷はほとんど発生しません。
VPN も安全に利用できます。

従来の MFA がリアルタイムフィッシングで突破される状況において、
FIDO セキュリティキーは現実的に突破されない認証方式であり、
カード形状化することで 低価格で全員配布が可能になります。

はじめに

ランサムウェアの被害が止まりません。国内の医療機関・自治体・企業で被害が相次ぎ、社会インフラとしての信頼性が揺らいでいます。
現在主流となっている「侵入後の検知・対応」を中心とした対策は、ハッカー側の検知回避技術の進化により効果が低下しつつあります。特に、ランサムウェア攻撃の起点となる認証情報の窃取は、EDRでは防ぎきれない根本的な弱点です。

「侵入は100％止められない」という前提のもとで対策が組み立てられてきましたが、これは“認証が弱い時代”の常識です。FIDOの様な強力な認証を必須化すれば、認証を経由した侵入は100％止められます。そして、認証を経由しない侵入については、PAM（特権ID管理）によって権限昇格や横移動を抑止できます。攻撃チェーンを一つずつ潰していくことで、現実的に防御率99％を達成する道筋が見えてきます。
私はこれまで、以下の2つの記事で「侵入を防ぐ」という視点からランサムウェア対策の本質を整理してきました。

• 侵入されなければ、ランサムウェア被害は起こらない！
  EDRアラートが鳴らない世界への鍵とは？
  https://note.com/oki_g/n/n4bea63a4bc52

• 日本医科大学のランサムウェア被害における原因と再発防止策について
  https://note.com/oki_g/n/n157e452c98c1

これらの記事でも述べた通り、ランサムウェア対策の最重要ポイントは認証の強化です。本記事ではその考え方をさらに発展させ、市販ツールだけで構築でき、現場の負担を最小限に抑えながら、防御率99％を実現するための優先順位とロードマップを提示します。

本記事が目指す「現実的な99％防御率」

ここで目指す99％は、標的型攻撃を完全に防ぐことを意味しません。標的型攻撃に100％対応しようとすれば、費用対効果を無視した莫大な人員・予算が必要になります。一般企業や医療機関・自治体にとって現実的ではありません。

本記事が目指すのは、

「一般的なランサムウェア攻撃をほぼ確実に防ぎ、社会インフラとして必要な安全性を確保する」

という現実的なラインです。

対策の基本方針（実行可能性を最優先）

本記事で示す対策は、次の原則に基づいています。

• 市販されているツールのみを使うこと
  特殊な開発や高度な専門人材を前提にしない。

• ツールの機能を最大限活用し、ヒューマンエラーを排除すること
  人間の注意力に依存する対策は必ず破られる。

• 社内外の作業フローを大きく変えないこと
  現場が無理なく移行できることが、最も重要な成功要因。

• VPNなど“完全排除が難しい機器”は残したまま安全性を確保すること
  理想論ではなく、現場の制約を踏まえた現実解を採用する。

• 現場の体制（人員・予算・スキル）で実行できることだけを採用すること
  実行困難な対策は、むしろ“新たな穴”になる。

一見すると理想論に見えるかもしれませんが、現在入手可能なツールと設定だけで、99％の防御率は十分に目指せます。

本記事の目的

• 個人や特定企業を批判するものではありません。

• 責任追及ではなく、現行のランサムウェア対策の問題点を整理し、改善策を提示することが目的です。

• 日本の医療機関・自治体・企業に共通する課題を明らかにし、現場で実行可能な対策を示します。

なお、本記事で示す対策は机上検討の段階であり、ツールの理解に誤りが含まれる可能性があります。今後、実証実験を通じて改善していくための“ベースモデル”として提示するものであり、効果を保証するものではありません。

最初の一歩：VPNは排するのではなく制するもの 真の原因はどこにあるのか？

ランサムウェア対策を考える上で最も重要で、最初に必ず行うべきことは原因の徹底分析です。

原因を正しく特定しないまま対策を積み増しても、予算を増額しても、人員を増やしても、セキュリティは強化されません。むしろ、誤った原因認識のまま対策を重ねるほど運用は複雑化し、攻撃者にとっての“抜け道”が増えていきます。

本章では、侵入ルートとして最も多いVPNを題材に、表面的な原因ではなく“構造的な原因”を掘り下げます。

VPN攻撃の「表面的な原因」

多くの組織が誤って理解している「表面的な原因」は次の通りです。

• VPNはインターネットから簡単に見つかる

• スキャンで自動的に探され、ログイン試行される

• パスワードが弱いと簡単に突破される

• VPNから入られると内部ネットワークにアクセスできてしまう

これらはすべて事実ですが、根本的な原因ではありません。
これは「VPNが攻撃されやすい理由」であって、「なぜ侵入されるのか」という本質的な問いには答えていません。

VPN侵入には2種類ある

原因を特定する際に重要なのは、まず状況を分類し、それぞれを個別に検証することです。分類しないまま議論すると、検証が複雑化し原因の特定が困難になります。

VPN経由の侵入は、大きく次の2つに分類できます。

① 認証を経由した侵入

• パスワードが弱い

• 多要素認証が形骸化している

• 管理者アカウントが狙われる

• 認証情報窃取により突破される

これは認証が弱いから侵入されているのであり、VPN特有の問題ではありません。RDPでもZTNでも、弱い認証を使っていれば同じように侵入されます。

② 認証を経由しない侵入（VPNの脆弱性）

• VPN装置の脆弱性を突かれる

• 侵入はできるが権限はない

• 権限昇格 → 横移動を繰り返し権限を徐々に上げていく

• ネットワークの掌握

• データの暗号化・破壊・窃取

この場合も、権限昇格を止めれば攻撃は成立しません。

ここまで掘り下げると見えてくる「本当の原因」

多くの組織は次のように考えます。

• パスワードが甘かった → 強化しよう

• 多要素認証を入れていなかった → 導入しよう

しかし、これらの対策では次の問題が残ります。

• インフォスティーラーやキーロガーで複雑なパスワードでも窃取される

• リアルタイムフィッシングで多要素認証を突破される

つまり、原因を特定したとは言えません。

正しい原因分析はこうです。

突破される認証を使っていたから侵入された。
だから、突破できない強力な認証を必須化し、例外を作らない必要がある。

これが“原因の原因”であり、唯一の正しい出発点です。

認証を強化すると何が起きるか

結論は非常にシンプルです。

• VPNの認証を突破できない強力な認証にする
  → 認証経由の侵入は100％止まる

• 認証を経由しない侵入が起きても、PAMで権限昇格・横移動を止める　ただし、PAMそのものを乗っ取られないように、PAMの認証も突破できない強力な認証にする
  → 権限昇格が止まり、横移動がすべて止まる

つまり、
強力な認証を必須化すれば、VPNを排除する必要はなく、安全に使える
という結論になります。

まとめ

• VPNが攻撃されるのは事実だが、VPNそのものが“原因”ではない

• 真の原因は「突破される認証を使っていたこと」

• 認証を強力にすれば、認証経由の侵入は100％止められる

• 認証を経由しない侵入も、強力な認証を使ったPAMで権限昇格を完全に止められる

• 結果として、VPNは排除するものではなく、強力な認証で制することで安全に使える

第二歩：強力な認証はどれを選べばよいのか？ なぜFIDOカードなのか？

ランサムウェア対策として用いる「強い認証」を選ぶ条件は次のとおりです。

• リアルタイムフィッシングやインフォスティーラーで窃取されないこと

• 使用するツール・装置（IDaaS、PAM、VPN、RDP、ZTN）がその認証をサポートし、必須化できること

• クラウドサービスにネイティブ対応していること

• 社内・職場内だけでなく外部委託先・サプライチェーンでも運用できること

• 登録・削除・再発行を管理者以外が行えないこと

• 必須化するために全員配布できる費用感であること

これらを満たさない認証は、どれほど“多要素”を名乗っていてもランサムウェア対策としては不十分です。

認証の強さを「鍵と錠」でイメージする

• ID・パスワード方式：針金で開く錠

• 従来型MFA（SMS/OTP/アプリ）：ピッキングで開く錠

• FIDO（パスキー含む）：ピッキング対策済みの錠と鍵

ここまでは多くの人が理解していますが、実はここに“重大な落とし穴”があります。

パスキーの「合鍵問題」

少し前に、ピッキング対策済みの鍵なのに家に侵入された事件が話題になりました。鍵そのものは盗まれていないのに、鍵に刻印された番号（合鍵番号）を写真で撮られただけで合鍵が作られたというものです。

パスキーにもこれと同じ構造があります。

• パスキーの秘密鍵は、スマホの機種変更でも使えるようクラウド同期される

• 同期に使う Apple ID / Google アカウントが“合鍵番号”の役割を果たす

• 攻撃者がクラウド同期アカウントを奪うと、秘密鍵が攻撃者の端末に自動ダウンロードされる

つまり、パスキーはクラウド同期アカウントを奪われると“合鍵を作られる”というリスクがあり、ランサムウェア対策としては強度が足りません。

FIDOセキュリティキーは“合鍵が作れない鍵”

同じFIDO技術でも、FIDOセキュリティキーは秘密鍵を物理デバイス内で生成し、取り出しもコピーも不可能です。

これは「合鍵が絶対に作れない鍵」に相当します。

そしてFIDOセキュリティキーは、

• CISAもFIDOセキュリティキーのみを強く推奨

• 主要IDaaS・PAMがネイティブ対応

• VPN・RDP・ZTNはIDaaS連携でFIDO必須化が可能

• IDaaSで登録・削除・再発行を集中管理できる

• IDaaSでサプライチェーンにも同じ運用を強制できる

• クラウドサービスも Microsoft 365、Google Workspace、AWS/Azure/GCP など主要サービスがネイティブ対応しています。

強度・互換性・運用性のすべてを満たす唯一の認証がFIDOセキュリティキーです。

問題は「価格」だけ

FIDOセキュリティキーは強度・運用性ともに唯一の答えですが、
1個5千円〜8千円では全員配布が難しいという課題があります。

解決策：FIDOカード

FIDOカードは、FIDOセキュリティキーのNFC接続部分をカード形状にしたもので、Windows PC、iPhoneでWebAuthn動作を確認済みです。
今回用意したFIDOカードは、

• 1万枚発注時：千円台

• 10万枚発注時：千円台前半

• →全員配布が現実的な価格帯になる

• カード形状は既存のクレジットカード製造ラインをそのまま使えるため、設備投資ゼロで大量生産が可能になります。

さらに用意したFIDOカードはMifareカードとして4バイトのUIDを出力可能であり、

• 社員証・職員証

• 入退室管理

• 勤怠管理

• 電気錠の鍵

としても利用できます。物理セキュリティとサイバーセキュリティを1枚で統合できる点は、他の認証方式にはない大きな利点です。

管理者用には指紋認証機能付きFIDOカード

物理デバイスの弱点として、盗難・紛失の問題があります。FIDOセキュリティキーは仕様としてPINコードがサポートされており、PINを入力しなければFIDO認証を開始しない設定が可能です。これにより盗難・紛失時でも第三者が認証に使うことができません。これをさらに強化する方法として指紋認証機能をFIDOカードに搭載することができます。

• 指紋で本人確認ができた場合のみ、FIDO認証チップがONになる

• スキミング耐性が大幅に向上する

• PINを使わずに“本人のみが使えるカード”を実現できる

• 管理者アカウントの価値とリスクを考えれば最も合理的な選択肢となる

特に管理者アカウントは、侵害された場合の被害規模が桁違いであるため、
一般ユーザーとは別レベルのセキュリティ強度が求められます。

さらに重要なのは、指紋認証はFIDOカード内で完結し、指紋データが外部へ送信されることは一切ないという点です。クラウドやサーバーに指紋データが保存されることはなく、プライバシー面でも安心です。

まとめ

• ランサムウェア対策に必要な「強力な認証」の条件をすべて満たすのはFIDOセキュリティキーのみ

• 価格の課題を解決し、全員配布を可能にするのがFIDOカード

• 以降のステップ（IDaaSによるFIDO必須化・PAMによる横移動封鎖）は、このFIDOカードを前提に構築します

次の第三歩では、このFIDOカードを例外なく必須化するためのIDaaS統制について解説します。

第三歩：IDaaSを使ったFIDOカード必須化　例外を作らない

ランサムウェアの主要な侵入経路は、VPN・RDP・ZTNなどの“外部からのログイン”です。ここをFIDOカード必須の認証構造に統一し、例外を一切作らないための中核ツールがIDaaSです。IDaaSを使うことで、FIDOカードの登録・削除・再発行・例外管理をすべて中央で統制でき、組織内外を含めた「認証の完全管理」が可能になります。

具体的なIDaaSを使ったFIDOセキュリティキーの設定方法については別記事で詳細を書いていますので、そちらを参照して下さい。

侵入されなければ、ランサムウェア被害は起こらない！ EDRアラートが鳴らない世界への鍵とは？
https://note.com/oki_g/n/n4bea63a4bc52

本記事ではIDaaSを使ってFIDOカードをどのように運用できるのか、ランサムウェアの防御率はどうなるのかについて解説します。

IDaaSでFIDOカードを運用すると実現できること

1. 外部からのログインをIDaaSに統一し、「FIDOカードなしの認証」を排除できる

• VPN、RDP、ZTN、クラウド管理画面など、外部から入れる入口をすべてIDaaSに集約して管理

• IDaaS側で「FIDOカードなしのログインを許可しない」設定が可能

• 外部委託者・メンテナンス業者・サプライチェーンも例外なし

• 認証情報が盗まれても、FIDOカードがなければログイン不可能

特にRDPは侵入のほぼ100％が“認証突破”であり、FIDOカード必須化によりRDP経由の侵入は構造的にゼロにできます。

2. FIDOカードの登録・削除・再発行をIDaaS側だけに限定できる

• 現場の管理者や外部委託者が勝手にFIDOカードを登録・削除できない

• 登録されたFIDOカードはすべて中央で可視化・監査可能

• 「知らないFIDOカードが勝手に登録されていた」という事態をゼロにできる

内部不正・サプライチェーン側の不正の両方を防ぎます。

3. 紛失・忘れなどの緊急時も、管理者が安全に臨時カードを発行できる

• IDaaS側でブランクカードを登録 → 一時的なFIDOカードとして発行

• 予備カードは原則禁止（悪用リスクが高い）

• 管理者用の緊急カードのみ金庫で厳格に保管

• 遠隔地の場合は「権限なしの予備カード」を渡し、必要時にIDaaSで権限付与

“緊急時の例外運用”が攻撃の入口になることを防ぎます。

4. 野良VPN・未登録IoT機器を排除し、サプライチェーンの責任範囲を明確化

• 外部から接続可能な機器は「IDaaSへの登録を契約で義務化」

• 定期的な脆弱性診断で未登録機器を検出

• 発見した機器はIDaaSの管理下に置くか、接続禁止

入口の棚卸しを継続的に行うことで、攻撃者が潜む余地を消します。

5. IDaaS管理者アカウントは最重要。FIDOカード以外のログイン手段は封印する

• 管理者はFIDOカード必須

• 緊急用パスワードは封印して金庫保管

• 管理者アカウントの乗っ取り＝組織崩壊なので、最も厳格に保護する

IDaaS全体の安全性を支える根幹です。

まとめ

第三歩で認証突破の侵入は「構造的に100％阻止」できる

認証突破はランサムウェア侵入のうち実質50〜70％を占めます。
その中でも特に大きいのが以下の2つです。

• RDP侵害：30〜40％ → ほぼ100％が認証突破 → FIDOカード必須化で完全に封じられる

• VPNの認証経由のログイン：10％前後 → FIDOカード必須化で防げる

したがって、IDaaSでFIDOカードを必須化する第三歩により、
全体の約40％の侵入経路を構造的に遮断できます。

参考：認証突破40％を潰すと、EDRの世界が劇的に変わる

第三歩の防御率40％という数字は控えめですが、認証突破による侵入は正規アカウントを使ったログインと同じであり、EDRが検知しにくい侵入を構造的に阻止しています。その結果、EDRが“本当に危険な動きだけ”に集中できる環境が整い、従来の対策に対して第三歩を加えるだけで防御率は一気に跳ね上がります。

第四歩：PAMを使った権限昇格・横移動の防止

― 認証を経由しない侵入は“無害”だが、放置すると必ず権限昇格に向かう ―

第三歩で「認証を経由する侵入」をほぼ封じた後に残るのが、VPN機器の脆弱性などを突いた認証を経由しない侵入です。これは世界中で完全に防ぐことができていない領域であり、ゼロデイが出れば誰でも侵入されてしまいます。ここで重要なのは次の点です。

攻撃者がネットワークを掌握するには、必ず次の3段階を踏みます。

1. 侵入（認証なし）

2. 権限昇格（ローカル管理者 → ドメイン管理者）

3. 横移動（AD・サーバ・バックアップ・EDR・PAMの破壊）
   つまり、②の権限昇格を止めれば③も止まり、攻撃は詰む。
   この②を止めるための唯一の仕組みが PAM（Privileged Access Management：特権ID管理）とMDM（Mobile Device Management）です。

海外ではIDaaS＋PAMが定番

多くの人が「PAMで権限昇格を止められる」なんて聞いたことがないと感じられると思います。ところが海外ではランサムウェア対策としてIDaaS＋PAMが定番となっています。日本では「侵入は100％止められない」という前提を受け入れ、検知以降の対策に集中してきた歴史があります。そのため「権限昇格後の対策」ばかりが議論されてきました。

一方、海外では攻撃チェーンを分解し、どの段階で攻撃を止めるかを長年試行錯誤してきました。その結果、
① 認証突破をIDaaSで止める
② 権限昇格をPAMで止める
という役割分担が確立し、IDaaS＋PAMをセットで使いこなす文化が熟成されています。

ここで重要なのは、PAM単体で権限昇格が止められるわけではないという点です。PAMは「特権操作をすべて一つの経路に集約し、その経路を強固に守る」ことで初めて権限昇格を封じることができます。海外ではこの“特権経路の一本化”を徹底してきた歴史があります。

攻撃者の動きは世界中どこでも同じです。

1. 認証突破（VPN・SaaS・管理画面）

2. 権限昇格（Domain Admin / root）

3. 横移動（RDP・SMB・AD）

4. ランサム展開・破壊

このうち、

• ①を止めるのがIDaaS

• ②を止めるのがPAM

だから海外では、この2つをセットで導入するのが定番になっています。これは本記事の第三歩と第四歩に相当します。では単純にIDaaSとPAMを導入すればよいかというとそれだけでは防御率はそれ程上がらないのは海外でも同じです。

海外でIDaaS＋PAMで高い防御率を実現している企業の共通点

海外で高い防御率に到達している企業は、次のような極めて成熟したゼロトラスト環境を持っています。海外ではランサムウェア被害が桁違いに多く、攻撃チェーンを分解して「どの段階で攻撃を止めるか」を長年試行錯誤してきた歴史があります。その結果として、IDaaSとPAMを“入口”と“権限昇格”の二段階の防御装置として使いこなす文化が形成されました。
しかし、このようなゼロトラスト環境を実現できるのは人的・経済的リソースが潤沢な企業に限られます。そこで以下の共通点から、認証強化によって本当に必要なポイントだけを抽出し、最小限のリソースで再構築していきます。

① ローカル管理者が完全廃止されている

• 全端末でローカル管理者が無効

• ベンダー保守もローカル管理者禁止

ローカル管理者が存在しないだけで、攻撃者が横移動に成功する確率は劇的に下がります。

② RDPはPAM経由のみ（直接RDP禁止）

• RDPポートは全閉

• PAMのプロキシ経由でしかRDPできない

RDP直打ちが不可能になるため、攻撃者はRDPを使った横移動がほぼできなくなります。

③ VPNが存在しない（ZTNのみ）

• VPNを完全廃止

• すべてのアクセスがアプリ単位で制御

• ネットワーク層の横移動が構造的に消える

ただし、第三歩で入口を封じ、第四歩で権限昇格を封じることができれば、VPNを廃止する必要はありません。VPNは“ただの通信路”となり、攻撃者が悪用できる構造が消えるため、無理にZTNへ移行する必要はありません。

④ IDaaSで全アカウント統合（例外ゼロ）

• SaaSもオンプレもIDaaSで統合

• 例外ログインが存在しない

• パスワードの“裏口”が消える

第三歩でIDaaS統合は既に実施済みなので、第四歩ではPAMログインもIDaaSに統合するだけです。
PAMログインがIDaaSの外にあると、それが“例外ログイン”となり、攻撃者にとって最大の突破口になります。

⑤ PAMで特権操作が完全プロキシ化

• 特権パスワードは非公開

• 特権操作はすべて録画

• 特権昇格が構造的に不可能

PAMは本来「パスワード金庫」ではなく、特権操作を一つの経路に集約し、その入口を強固に守るための仕組みです。海外ではこの“特権経路の一本化”が徹底されています。

⑥ MFAはリアルタイムフィッシング耐性の高い方式

FIDOではないが、次のような強力なMFAが使われています。

• WebAuthn（プラットフォーム認証）

• プッシュ通知＋番号マッチ

• デバイス証明書＋アプリ認証

• リスクベース認証

FIDOほど強くはないが、パスワード＋OTPよりは圧倒的に強力です。

ただし、PAMログインに関してはこれでも不十分です。
強力なMFAでもセッション乗っ取りや中間者攻撃の余地が残るため、PAMの入口としては強度が足りません。

この共通点では明示されていませんが、PAMのログインがFIDOカードでなく強力なMFAのままだと、PAM自体が突破されるリスクが残ります。IDaaSを経由しないPAMログインが可能な場合は、別途FIDOカード必須化で守らない限り、攻撃者にPAMを乗っ取られ、簡単に権限昇格されてしまいます。

PAM使って権限昇格を止めるための追加設定

海外の成熟したゼロトラスト環境では、PAMは「特権IDの金庫」ではなく、特権操作を唯一の経路に集約し、その入口を強固に守るための仕組みとして運用されています。しかし、一般的なPAM製品をそのまま導入しただけでは、この構造は再現できません。権限昇格を確実に封じるためには、次の追加設定が不可欠です。

① ローカル管理者の完全廃止（MDMで強制）

• 全端末からローカル管理者を削除

• ベンダー保守もローカル管理者禁止

• 端末管理はMDMで一元化

ローカル管理者が残っている限り、攻撃者は端末を奪取した瞬間に“権限昇格の足場”を得てしまいます。ローカル管理者を廃止するだけで、権限昇格の成功率は桁違いに下がります。

② すべての特権操作をPAMプロキシ経由に統一

• RDP、SSH、PowerShell、DB接続など、特権操作はすべてPAM経由

• 特権パスワードは非公開化

• 操作ログはすべて録画・保全

特権操作が複数の経路に分散していると、攻撃者は“例外経路”を探して突破します。特権操作をPAMに一本化することで、PAMを突破しない限り権限昇格ができない構造が成立します。

③ サービスアカウントもPAMで管理

• サービスアカウントのパスワードをPAMでローテーション

• アプリケーションからはPAM API経由で取得

• 人間がパスワードを知ることがない状態を維持

サービスアカウントは攻撃者にとって“静かに権限昇格できる最強の裏口”です。ここをPAM管理に移すことで、攻撃者が横移動に使えるアカウントが消滅します。

④ RDP直打ち禁止（PAM経由のみ）

• RDPポートは全閉

• PAMのプロキシ経由でのみRDP可能

• ログイン元IPの制御もPAM側で一元化

RDP直打ちが可能な環境では、攻撃者は認証情報を奪った瞬間に横移動できます。RDPをPAM経由に限定することで、攻撃者はPAMを突破しない限り横移動できない状態になります。

⑤ PAMログインをIDaaS経由でFIDOカード必須化

• フィッシング不可

• 中間者攻撃不可

• リプレイ不可

• デバイス固有鍵で署名

強力なMFAであっても、セッション乗っ取りや中間者攻撃の余地が残ります。PAMは特権操作の唯一の入口”であるため、ここが突破されればすべてが終わります。PAMログインもIDaaSに統合しFIDOカードを必須化することで、PAMログインの奪取が物理的に不可能になります。

⑥ PAMを突破しない限り特権操作ができない構造を完成させる

• 端末を奪われてもローカル管理者がない

• RDP直打ちができない

• 特権操作はすべてPAM経由

• サービスアカウントもPAM管理

• PAMログインはFIDOカード必須

これらを組み合わせることで、攻撃者が侵入しても PAMを突破しない限り権限昇格ができない構造が成立します。

⑦（最重要）IDaaS経由だけでなく、PAMネイティブログインもFIDOカード必須化する

ここが最も見落とされやすいポイントです。

PAMには入口が2つあります。

• IDaaS経由のログイン（SAML/OIDC）

• PAMネイティブのローカルログイン（製品が内部に持つ独自認証）

IDaaS側でFIDOカードを必須化しても、ネイティブログインが残っていれば攻撃者はそこを攻撃します。
PAMは特権操作の唯一の経路であるため、ネイティブログインが破られた瞬間に PAMそのものが攻撃者の“権限昇格ツール”に変わります。

そのため、

• IDaaS経由ログイン → FIDOカード必須

• PAMネイティブログイン → FIDOカード必須

この“二重のFIDO化”が揃って初めて、PAM突破＝物理的に不可能になります。

まとめ

第四歩では、PAMを“唯一の特権経路”として固定する追加設定を行うことで、権限昇格と横移動を構造的に不可能にできます。これにより、侵入後の攻撃チェーン（権限昇格 → 横移動 → Domain Admin → ランサム展開）を100％阻止できます。

第三歩と第四歩を連携させることで、オンプレミス環境における侵入から権限昇格・横移動を二段構えで遮断し、Domain Admin 取得 → ランサム展開 を事前に止めることができます。

この二段構えにより、EDRが検知する前の段階で攻撃チェーンの大部分を潰すことができ、EDRは“残りカスだけ”を見ればよい状態になります。

第三歩＋第四歩の大きな利点は、FIDOカード全員配布と、IDaaS、PAM、MDMの３つのツールを導入するだけで実現し、導入後はほとんど人手をかけず、VPNを無理にZTNへ置き換える必要もなくオンプレミス環境への侵入からのランサムウェア攻撃を検知前に阻止できる点です。

さらに重要なのは、FIDOカード全員配布とIDaaSによるFIDOカード必須化、そしてPAMとMDMによる権限昇格の封鎖を組み合わせることで、これまで「防げない」とされてきた攻撃の多くを“構造的に無害化”できる点です。

サプライチェーン攻撃

外部委託先・保守業者・サプライチェーンにもFIDOカードを配布し、IDaaSで外部からのログインをFIDOカード必須化することで、サプライチェーンから窃取したアカウント情報を悪用した侵入は物理的に不可能になります。パスワード・OTP・アプリMFAといった“裏口”が完全に消えるため、サプライチェーン攻撃の大部分を構造的に遮断できます。

IoT機器を踏み台にした攻撃

IoT機器が乗っ取られても、FIDOカードがなければログインできず、PAMとMDMにより権限昇格も横移動も不可能です。侵入はされても権限ゼロのまま攻撃が詰むため、IoT機器を踏み台にした攻撃は実質的に無害化できます。

セッションハイジャック攻撃（Cookie盗難・ブラウザ乗っ取り）

セッションを奪われても、特権操作はすべてPAMプロキシ経由であり、PAMログインはFIDOカード必須です。奪ったセッションで一般ユーザー権限で侵入できても、FIDOカードなしでは特権に触れられず権限昇格ができません。そのため、セッションハイジャックは“侵入だけ”で攻撃チェーンが進みません。管理者のセッションが奪われても同様で、FIDOカードなしでは特権操作に到達できません。

これらの攻撃は従来の「検知してから対応する」対策では大量のリソースを投入しても完全に防げなかった領域であり、FIDOカード全員配布とIDaaS＋PAM＋MDMの組み合わせによって専門の技術者がいなくても実現できる“構造的な防御”が可能になります。

防御率については、第三歩で認証突破の侵入（全体の約40％）を封じ、第四歩で認証を経由しない侵入（約10％）に対して権限昇格・横移動を封じることで、攻撃経路の合計50％を“構造的に”遮断できます。認証を経由しない侵入は“侵入直後は権限ゼロ”であるため、権限昇格さえ止めれば実質的に無害化できるという構造的根拠があります。

防御率が50％どまりなのは、現在のオンプレミスとクラウドのハイブリッド環境では、クラウド側の攻撃（SaaS設定ミス・ブラウザセッション奪取・同期アカウント奪取）を第三歩と第四歩では止められないためです。
これらは第五歩〜第七歩で別途対処する必要があります。

第五歩：クラウドの攻撃チェーンを潰す（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. バックアップ破壊の構造を理解する

バックアップを破壊するには、攻撃者は次の工程を踏む必要がある。

1. 侵入

2. 権限昇格

3. 横移動

4. バックアップ領域への到達

5. バックアップ破壊

つまり、バックアップ破壊は“高度な特権奪取”が前提になる。

さらに第六歩で示したような
「特権不要でバックアップに直接アクセスできるルート」
（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、実証へ進む過程では、
ツールの対応状況や連携度によって理想通りにいかない部分も出てくるでしょう。

今後は皆さんと情報交換しながら完成度を高めていく段階です。
ツール選定などでお力になれることがあれば、ぜひご連絡ください。

この対策は、すべてを一度に導入する必要はありません。
まずは既存対策の見直し・再設定から始め、予算の範囲で段階的に進められます。

この三部作が、セキュリティに悩む方々のランサムウェア対策マニフェストとして役立つことを願っています。

ランサムウェアは抑え込める。
構造で守る時代を、一緒に作っていきましょう！