AIファーストを主導して先見の明があると言われながら ── ナデラと楊植麟、いますぐすること

K3対策を考えたら、Microsoft対策になった

2026年7月16日、Moonshot AIがKimi K3を発表した。総パラメータ2.8兆、文脈100万トークン。開発したのは楊植麟——同社の創業者である。完全な重みを本日（7月27日）に修正MITで公開すると約束している。

性能は正確に書いておきたい。総合ではFable 5とGPT-5.6 Solに及ばない。だがOpus 4.8とGPT-5.5を上回り、前端コードの盲検比較では首位に立った。少し前のフロンティアが、無償で開かれようとしている。

ただし、重みが出ても個人には動かせない。読み込むだけでH100 80GBが8基要る。それでも前提は変わる。 攻める側は個人ではないからだ。犯罪組織にも、国家にも、その規模の計算資源はある。

その対策を考えていたら、ほとんどがMicrosoft対策になってしまった。

WindowsのPCをLinuxへ移し、適切に管理するのが最善である。だが、すぐにはできない現実がある。だから、いまできることを以下に記す。

目指すのは、無傷ではなく倒れないこと

前稿では、ソフトのコストが下がったことで攻撃も検証も安くなり、安くなった攻撃は集中しているところに当たる、という構造を書いた。本稿はその実装である。

最初に目標を置き直したい。目指すのは、攻撃されないことではない。

ときどき攻撃され、被害も出て、それでも業務が続く。火事や盗難と同じ扱いになる、ということだ。店は時々空き巣に入られるが、それで閉店はしない。施錠があり、保険があり、盗まれても続けられる構えがあるからである。

セキュリティだけが長いあいだ「一度でもやられたら終わり」という異常な基準で語られてきた。その基準は二つの失敗を生む。到達できないので諦めるか、一度破られたときに全部が間違っていたと結論するかだ。

無傷ではなく、倒れないこと。 目標をそこに置き直すと、やるべきことが決まる。

いますぐすること ── 届く範囲を、層ごとに決める

攻撃者に対してできることは、二種類ある。何をできるかを制限することと、どこまで行けるかを決めることだ。

倒れる範囲を決めているのは後者である。だからネットワークから始める。

ネットワーク ── どこからどこへ通れるか

いま多くの中小企業のLANは、平坦である。全端末が全端末と話せ、外向きは無制限。これは選ばれた設計ではなく、買ってきた状態がそうだっただけだ。

決めるべきことは四つ。

セグメントを分ける。 事務、製造、サーバ、来客、そして監視カメラや複合機のような機器。一枚のLANに全部を載せない。分けた瞬間、一台の侵入で届く範囲が「全部」から「その区画」に変わる。二人の情報システム担当でもできる作業である。

そして区画を越える通信は、HTTPSかSSHに限る。 経路を信用しない以上、暗号化が要るからだ。効果はそれだけではない。この一行の規則が、平坦なLANを前提にしたプロトコルを締め出す。SMBも、名前の問い合わせも、印刷の探索も、区画を越えられなくなる。何を止めるかを個別に数え上げるより、通していい形を一つ決めるほうが短く、確かめやすい。

端末が数台の会社なら要らない。届く範囲が、もともと狭いからだ。そしてLinuxが増えるほど、必要は薄くなる。 Windows端末は既定で互いを信頼し、認証情報の再利用を許し、共有と遠隔操作の経路を最初から開けている。セグメント分割は、その既定値を網の側で打ち消す作業でもある。端末が最初から互いを信頼していなければ、区画で塞ぐ仕事は減る。

端末どうしを通さない。まず手をつけるのは、ここである。 PC同士が直接通信しなければならない場面は、実務ではほとんどない。ファイルサーバとは話す、隣の席のPCとは話さない。ランサムウェアが社内で広がるのは、たいていここを通る。一台やられたときに一台で済むかどうかは、SMBを閉じ込めたかどうかで決まる。

そしてこの一つが、Windowsでは簡単ではない。 ファイル共有と横展開が同じSMBを使っているので、プロトコルごと止めるわけにいかない。宛先で分けるしかなく、その規則を全端末へ配るには集中管理の仕組みが要る——ADか、クラウド側の管理基盤か。この記事が離れよと言っている先である。 印刷や遠隔管理の道具が端末間の到達を前提にしていることもあり、切ると何が止まるかも事前に読み切れない。

Linuxなら、この問題は起きない。 既定で445番を待ち受けているものが無いからだ。切る作業ではなく、最初から開けない作業になる。

外向きを既定で塞ぐ。 侵入されても、外部の指令元に繋がらなければ指示を受け取れず、データも持ち出せない。倒れるかどうかは端末間の遮断が決め、情報が出るかどうかはここが決める。 必要な宛先だけを開ける運用は面倒に見えるが、必要な宛先は思ったより少ない。

名前解決を自分で持つ。 社内DNSを自分で管理し、フィルタをかける。あわせて自ドメインのSPF・DKIM・DMARCを設定する——なりすましメールは、いまも最大級の侵入経路である。そして退役したサービスを指したままのCNAMEを掃除する。放置されたレコードは、サブドメイン乗っ取りの入口になる。

要するに、どこからどこへ通れるかを、自分で決める。 前稿に書いたとおり、説明できないものは守れない。いまのLAN構成を図に描いて説明できる中小企業は、ほとんどない。

認証 ── Active Directoryから離れる

ADは、ドメイン管理者を頂点にした一枚岩である。設計上、一箇所を破られれば全部が取れる。認証情報の使い回しを突く手口も、チケットを偽造する手口も、この構造の帰結として存在している。

中小企業に必要なのは、端末へのログイン、ファイルへの認可、そしていくつかのSaaSへのログインくらいだ。ディレクトリなしで組める。

なお、クラウド側の認証基盤に移しても構造は変わらない。集中の場所が社内からクラウドへ動くだけで、一つ破られれば全部という形はそのままである。

文書 ── VBAを切る

文書を開くと任意のコードが走る。この設計が異常なのだが、1990年代の決定で、互換性のために取り消せない。マクロは今も初期侵入の古典的な経路であり続けている。

実務上の障害は、業務が既存のマクロに依存していることだ。だからこれまでは「移行費用が高いので無効化できない」で止まってきた。

その壁が低くなった。 AIがマクロを読み、何をしているかを説明し、別の形に書き直せる。切れない理由が、切らない理由ではなくなった。

そして同じ形が、いま新しく積まれている。文書に組み込まれたAIは、文書に書かれた指示に従う。 三十年前は、文書がプログラムでもあった。いまは、文書が指示でもある。

受け取ったメールや共有された資料に、AIへの指示を紛れ込ませる。間接的なプロンプト注入と呼ばれる手口で、まだ解かれていない。そして製品に埋め込まれたAIは、テナントの中身をまとめて読める。読める範囲が広いほど、一回の注入で持ち出せるものが増える。集中の上に、集中が重なっている。

そして、二つが同じ面に載っていることの意味は、もう一段深い。VBAはOSに手が届く。 ファイルの操作も、外部プログラムの起動も扱える。文書の中で完結する話ではない。

つまり、指示に従うAIと、OSに届く実行系が、同じところに同居している。この二つを隔てているのは、注入への防御だけである。そしてその防御は、まだ解かれていない問題の上に立っている。 未解決の問題を、唯一の仕切りとして使っていることになる。

そして、その面に外から物を置ける経路がある。電子メールである。

受信箱は、見知らぬ相手が自社の内側に内容を置ける唯一の場所だ。添付を開けば関連付けられたアプリが立ち上がり、そこにマクロの実行系がある。本文と添付は、テナントを読むAIも読む。入口が一つで、その先に実行系が二つある。

しかも入口の設計そのものに問題がある。開くことと実行することが、同じ動作になっている。 受け取った側はクリックするだけで、その結果が「中身を見る」なのか「動かす」なのかは、ファイルの側が決める。押す前に区別する手立てがない。

危険な拡張子を止める仕組みは足されてきた。だがそれは一覧で塞ぐ方式であり、一覧は必ず後から追いつく。 設計が「押せば動く」を前提にしている限り、塞ぐ側は追いかけ続けることになる。

これで三度目である。文書がプログラムでもあり、文書が指示でもあり、そして添付は読むことと動かすことが分かれていない。データと実行を混ぜないという原則が、この経路には一度も通っていない。

順序も間違っている。VBAを無効にしてから、Copilotを入れるべきだった。 文書から実行される経路が一つ開いたままのところへ、二つ目を足したことになる。しかも一つ目を閉じられなかった理由は「移行費用が高い」だった。その費用を出せなかった組織が、二つ目の導入には出している。 手が無かったのではない。古いものを閉じるより、新しいものを開くほうへ向いていただけである。

前稿の「ベンダー同梱のAIで済ませない」は、検証の質だけの話ではなかった。攻撃面の話でもある。

アプリ ── Webを静的にする

会社案内に動的なCMSを使う必要はない。静的サイトには、データベースも、サーバ側の実行環境も、管理画面も、プラグイン更新の追いかけっこもない。

破られても、ファイルが書き換わるだけである。 盗るデータがなく、踏み台にする実行環境もない。倒れる範囲が、構造的に小さい。

復旧 ── 改変不能なバックアップ

ここまでの四つは、被害の範囲を決めるものだった。倒れるかどうかを決めるのは、これである。

オフラインか、書き換えられない形式の複製を一つ持つ。復旧を実際に試して、何時間で戻せるかを測っておく。これがあれば、ランサムウェアは損害であって死ではなくなる。

「ときどき攻撃され、被害も出て、それでも業務が続く」を成立させている部品は、最終的にここだ。

Windowsは、手のかかる選択肢になる

AIによる攻撃を相手にすると、この差は一段大きくなる。

攻撃する側は、あなたの設定を読む必要がない。製品を読めばいい。同じ製品が同じ形で世界中に入っているので、一度読めばどこでも効く。この利点は、WindowsでもLinuxでも変わらない。

守る側は逆で、自分の状態を読ませられるかどうかで決まる。 Linuxでは、設定がほぼ全部テキストである。/etcの下も、サービスの定義も、通信の規則も、そのままAIに渡して説明させ、差分を取り、書き換えまで作らせられる。Windowsでは、状態の多くがレジストリとポリシーオブジェクトと画面の中にある。取り出せないわけではないが、読ませられる形にするまでが一仕事になる。

同じAIを持っても、守る側が受け取るものが違う。 前稿に書いた「攻撃と防御が同等になる均衡」は、状態が読める土台のほうから先に来る。

そのうえで、五つを並べると別のことも見えてくる。手間の多くが、既定値を打ち消す作業である。

端末どうしの通信を止めにくいのは、ファイル共有と横展開が同じSMBだからだ。セグメントを分けたくなるのは、端末が既定で互いを信頼するからだ。規則を配るのに集中管理が要るのは、その道しか用意されていないからだ。VBAを切る手間があるのは、文書がプログラムでもあるからだ。

Linuxなら、この列のほとんどが発生しない。開いていないものを閉じる作業は、要らない。

前節の「区画を越えるのはHTTPSかSSH」にも、同じことが起きる。Linuxでは鍵もscpもrsyncも最初からその環境の言葉だが、Windowsではクライアントの追加から始まり、鍵の作り方も配り方も社内の慣行になっていない。動くかどうかではなく、標準の道かどうかの差である。Unix系で生まれた道具をWindowsへ持ち込むには移植が要り、移植は本家に遅れ、周辺までは追いつかない。いま道具を作る側の大半はUnix系にいるので、使うたびに移植という関門があること自体が、消えない費用になる。

そして規則を一つ決めると、もう一つが決まる。区画を越えるのがHTTPSとSSHだけなら、Windowsサーバを置く理由が無くなる。 ファイルサーバの役目はSMBの上に立ち、そのSMBが区画を越えられない。受け渡しをHTTPSに寄せれば区画は自然に越えられるが、その形ならWindowsである必要はどこにもなく、ADから離れればドメイン管理の役目も残らない。

ここまで並べたものを見返すと、一つのことに気づく。層ごとに挙げた具体名が、ほとんど同じ一社である。 端末間を塞ぎにくくしているSMB、規則を配るのに要るAD、文書を実行可能にしているVBA、そこへ重ねられたCopilot、押せば動く添付、そして契約の大きさで扱いが変わる送信基盤。別々の問題として並べたが、出所は一つの設計系譜だった。

これがMythos時代の意味である。AIが数時間でゼロデイを見つけられるようになると、狙われる価値はどれだけ均一に置かれているかとどれだけ中を見られないかで決まる。Windowsは両方で最大になる。同じ物が同じ形で世界中に入っていて、しかも使う側から中身を確かめる手立てがない。

開示から修正までの間、開いた土台なら、自分が該当するかを確かめて先に手を打てる。閉じた土台では待つしかない。待つ時間の長さを決めるのは、自分ではなく売る側である。

だから、時代への備えという抽象的な話は、実務では一行に落ちる。Mythos級の対策とは、Windows対策のことである。

Windowsは、ハードウェアとクラウドを結びつけている

ここまでは手間の話だった。手間は払える。払えないものが、この先にある。

原理は一行で言える。Windowsは、ハードウェアとクラウドを結びつけている。 TPMは機械の中の部品で、封をするのも解くのも手元で完結する仕組みだった。そこへアカウントを繋いだ。以下に見るのは、その結びつきが現れる三つの形である。

一つ。繋がない自由が、消える。 Windows 11の初期設定は、インターネット接続とMicrosoftアカウントを求める。回避の手立ては順に塞がれてきた。2025年3月にbypassnroが外され、10月にはms-cxh:localonlyも外された。Microsoftの説明は「デバイスが正しく設定されるために、接続とアカウントでOOBEを完了する必要がある」である。出荷中の版によってはまだ動く手もあるが、方向は一つしかない。残っているのは、応答ファイルによる無人展開と、ドメイン参加の経路——どちらも、配備の仕組みを持った組織の道具だ。 一台だけ繋がずに置きたい個人や小さな事業者には残らない。閉じ込めの最も確実な形は繋がないことだったのに、それが大きいほうにだけ残った。

二つ。ディスクの鍵が、外へ出ていく。 24H2以降、TPMとセキュアブートのある機械にクリアインストールしてMicrosoftアカウントで入ると、ディスクの暗号化が自動で有効になる。Home版も含まれる。回復キーは、そのアカウントへ自動で預けられる。使う側は暗号化も預託も選んでいない。どちらも既定で起きる。2026年1月、Microsoftはその鍵を法的要請に応じてFBIへ渡すことを認めた。年に20件ほど、鍵は暗号化されない形で保持され、渡したことを本人に知らせる義務もない。暗号化はされている。ただし、鍵は自分の側にない。

ここで、事故の段の違いを見ておきたい。サービスが止まるのと、機械が起動しないのは、別の事故である。 クラウドの資格情報を失えば、メールも書類も開けなくなる。痛いが、手元の機械は起動するし、ローカルにあるものは開く。止まったのは一つの層だ。BitLockerは違う。回復モードに入った機械は、48桁の回復キーが無ければ起動しない。そして回復モードは事故ではなく、通常の保守で起きる。 UEFIの更新、TPMのファームウェア更新、セキュアブートの構成変更、起動に関わる部品の交換——どれもTPMが記録している測定値を変え、TPMは鍵を渡さなくなる。2026年4月、これが大規模に起きた。Microsoft自身の更新がセキュアブートの検証を変え、古いファームウェアの機械が回復画面から戻らなくなった。修正は翌月まで待つことになった。止めたのは売る側の更新で、開ける鍵を持っているのも売る側である。

鍵の在り処は、既定でアカウントの中だけだ。別の端末を用意し、インターネットに繋ぎ、そのアカウントに入って、初めて手元の機械が起動する。組織なら鍵はADやEntraにあり、管理者がまとめて取り出せる。個人と小さな事業者には、その経路がない。アカウントが凍結されていたら、乗っ取られていたら、設定した担当者が辞めていたら——その機械は、もう起動しない。 閉じ込めとは事故を層の中に留めることだったのに、ここでは逆が起きている。クラウドのアカウントの問題が、物理的な機械が起動するかどうかまで降りてくる。

三つ。認証が、世界中から届くようになる。 手元のアカウントなら、試せるのは機械に届く者だけだ。区画を分け、端末どうしを通さず、外向きを既定で塞ぐ——ここまでやってきたことは全部、誰が認証を試せるかを絞る作業でもあった。 オンラインのアカウントには、その全部が効かない。IDが分かれば、世界中のどの端末からでも試せる。 そしてIDは秘密ではない。多くの場合それはメールアドレスで、署名にも名刺にも入っており、過去の流出にも載っている。

これは静かに恐ろしい。手元のアカウントに、遠くの誰かが試せる回数はゼロだった。機械に届かないからである。オンラインに置いた瞬間、その回数は止まらなくなる。世界中から、毎日、こちらの知らないところで試行が続く。手元のアカウントは、強いパスワードで守られていたのではない。届かないことで守られていた。 締め出しはあるが、攻める側はそれを避ける。多数のIDに一度ずつ試し、流出した組み合わせをそのまま一度だけ試す。締め出しは一つの入口を守るが、面としての試行は止めない。 多要素認証はこの上に足す防御で、効くが、届く範囲を狭めてはいない。層で絞るのと、関門で止めるのは、別のことだ。

そして同じアカウントに、さっきの回復キーがある。機械に触れずに、ディスクを開ける鍵まで届く経路ができている。

三つとも、同じ一つの結びつきの現れである。封を解く鍵は外へ預けられ、機械を業務に入れる最初の一歩も外を通り、外から配られた更新が封を壊す。手元の機械が動くかどうかが、外側の状態で決まるようになった。境界が、自分の側に無くなったのである。

機械の側へ、引き戻す

この結びつきは、攻める側の動機まで変える。

身代金要求型の攻撃は、これまで手数のかかる仕事だった。侵入し、実行環境を取り、暗号化を走らせ、検知を避け、鍵を握る。いまは暗号化が済んでいる。 既定で有効になっていて、鍵は一つのアカウントの中にある。やることは、機械に触れることではなく、そのアカウントに入ることだけになった。これは想定の話ではない。BitLockerそのものを使って暗号化し、既定の保護機能を削除して回復の手立てを断つ不正プログラムが、2024年から観測されている。感染した機械に出るのは「このPCにBitLockerの回復オプションはもうありません」という表示である。攻める側は、暗号化の仕組みを持ち込む必要すらなくなった。

被害の出方も違う。鍵を消しても、その場では何も起きない。機械は普通に起動し続ける。壊れるのは、次にファームウェアが更新されたとき、部品を替えたとき、セキュアブートの構成が変わったときである。数か月かけて、一台ずつ起動しなくなる。 その頃には、侵入との関係を誰も結びつけない。前稿の「攻撃が安くなる」は道具が安くなる話だったが、ここで起きているのは別の値下がりである。攻める側が用意すべきものを、売る側が先に据え付けてしまった。

逃げ場として自社に預けても、同じ集中になる。ADに預けた鍵は、ドメイン管理者の権限で読み出せる。 そしてドメイン管理者を取ることは、侵入する側の標準的な到達点である。一つ抜かれれば全部出る場所に、鍵をまとめて置いたことになる。自社に置けば守る力の乏しい場所に集まり、外に置けば守りは堅いが自分では動かせず法的要請には開いている。選べるのは、どちらの弱さを引き受けるかだけだ。

ではどうするか。クラウドを使うことが問題なのではない。 Google Workspaceが全面的に侵害されても、手元の機械は起動する。ローカルにあるものは開く。止まるのはサービスの層で、境界はそこに引かれている。 問題はハードとクラウドを結んだことであって、クラウドそのものではない——それを分けて見せているのが、この対比である。

しかもサービスの層には、締め方がある。パスキーだけで認証する設定は、どの契約階層でも使えて、費用もかからない。推測される秘密が無くなり、偽の入口に鍵を渡すこともなくなる。残る経路は端末そのものを取ることだけで、それは本稿がここまで書いてきた措置が効く場所である。 攻める側を機械の上に引き戻せれば、区画も、遮断も、外向きの拒否も、また意味を持つ。管理者のアカウントから先に固めるとよい。

結びつけてはいけないのは、ハードウェアとクラウドである。 その一線さえ引けていれば、あとは層ごとの話に戻る。

それでもWindowsを選ぶ理由は、これまで三つあった。業務アプリがそこにしかない。文書の互換性が要る。扱える人がいない。三つとも、いま弱くなっている。 アプリは作れるようになり、文書の形式は公開され、設定はAIが読んで書く。Windowsが使えなくなるという話ではない。格下げである。 何も考えずに選ぶ既定の選択肢から、管理の手間に見合う理由があるかを毎回問われる選択肢へ移る。答えられるなら、選べばいい。

近い将来の話としては、それでいい。だが長い目で見ると、もう一段はっきりしたことが言える。逃げ道は、毎年ひとつずつ減っている。 繋がずに設定する手立ても、鍵を自分の側に置く既定も、順に外されてきた。そして減らしている側には、止める理由がない。痛みを引き受けているのが、契約の小さい側だからである。大口顧客が免除されている限り、市場からの圧力でこの向きが変わることは期待できない。

だから、待つことは方針にならない。企業の情報を預かる立場にある人は、Linuxへの移行を計画として持っておくべきである。 今すぐ全部を入れ替えろという話ではない。順序がある。新しく置くサーバをLinuxにする。区画を分けるとき、境界に置く機器をLinuxにする。端末は、業務アプリの依存が切れたところから始める。移行は、置き換えの機会に合わせて進めればよい。 費用のかかる一斉更新ではなく、更新のたびに向きを決める作業である。決めておくべきなのは、期限ではなく向きだ。次に何かを買うとき、どちらを選ぶか。それを先に決めていない組織は、決めたつもりのないまま、決められていくことになる。

なぜ、今までやられなかったのか

まず正直に書く。難しかったからである。

メールサーバの自前運用は、長いあいだ「届かない」との戦いだった。SPF・DKIM・DMARC、ブラックリスト、大手プロバイダのフィルタ。設定を一つ誤れば、自社のメールが取引先に届かない。認証も同じで、ADは実際の問題を解いていた——Windows端末を束ねて一元管理する仕組みは、当時ほかになかった。Officeの代替も、複雑な表計算や社外とやり取りする文書では互換性の問題が残った。

ベンダーを選んだのは、合理的な判断だった。 騙されていたわけではない。

そのうえで、難しさにはもう一段ある。本当に難しい部分の上に、難しくなくてもよかった部分が積んである。

既定値が繋がっている。 買ってきた状態で全部が相互接続されていて、切るのは客の仕事になっている。既定値は方針である。何もしなければ最も広く繋がった状態が残る、という設計を選んだのは売る側だ。

複雑さが注意を食い尽くす。 二人の情報システム担当がADとメールと端末管理で埋まれば、ネットワーク設計まで手が回らない。ネットワークの放置は、独立した怠慢ではなく複雑さの帰結である。

束ねてあるので、設計する機会が来ない。 認証もメールも名前解決も一つのテナントに入っていると、それらを自分で設計する場面が発生しない。ウィザードが書いた設定がそのまま残り、退役したサービスを指したレコードも残る。

そして、ここが構造の核心になる。顧客が自分でできないことが、商品である。 難しさは副作用ではない。売り物のほうだ。前稿でSIerについて書いたことが、そのまま当たる。

なぜ、いまならできるのか

変わったことが、二つある。

一つは、本当の難しさが下がったこと。認証は公開規格が成熟し、実装が手に入るようになった。文書は形式が公開され、変換も修正もAIができる。ネットワークの設計も、構成を読ませて洗い出せる。かつて「自前では無理だ」と判断した根拠は、もう残っていない。

もう一つは、複雑さを読む費用が落ちたこと。自社のネットワーク構成を説明させる。マクロが何をしているかを読ませる。どのサービスがどこに依存しているかを洗い出させる。何を開けて何を塞ぐべきかの候補を出させる。どれも、以前は外部の専門家に頼んで数週間かかったことだ。いまは手元で回る。

メールも、もう難しくない。 大手プロバイダは受け入れの要件を公開しており、SPF・DKIM・DMARCの設定は数分で検証できる。一式をまとめた実装も出回っていて、部品から組み立てる必要はない。

ただし、設定を正しくすれば届く、という話ではない。同じ規則が、規模によって違う形で適用されている。

Azureは仮想マシンからの送信ポート25を塞いでいる。ただし全部ではない。企業向けの大口契約——EAとMCA-E——では塞がれていない。従量課金、MSDN、無料試用、教育、CSPでは塞がれていて、しかも解除の申請は認められないと明記されている。 同じ基盤の上で、同じ技術的な危険があり、違うのは契約の大きさだけである。

認証の側も同じ形をしている。Microsoftは自社のonmicrosoft.comドメインにDKIM署名を自動で付ける。テナントを作った初日から、SPF・DKIM・DMARCが揃った状態で送信できる。実績は要らない。中にいることが、実績の代わりになる。 この性質は実際に悪用されていて、正規の手続きで作られたテナントから出た詐欺メールが、認証を全部通過して届く事例が報告されている。

外で同じことをすれば、三つを正しく設定しても、履歴のないアドレスからの少量のメールは疑われる。規則は同じで、通り方が違う。正しさでは買えないものが、ここに残っている。

だから外に出すのは、この一点だけでいい。残る外部依存は配送の評判であり、送信の中継だけを外に出せば済む。 認証付きの中継(587番)はAzureでも制限されておらず、Microsoft自身がその使用を案内している。郵便受けも、アカウントも、過去のやり取りも自社に置いたまま、届ける工程だけを他社に通す。中継業者は身元も蓄積も持たないので、集中は起きない。いちばん難しかった部分が、いちばん素直に切り出せる部分だった。

だから順序も決まる。一度に全部やる必要はない。まず、SMBを閉じ込める。 一台やられたときに一台で済むかどうかが、そこで決まるからだ。次に外向きの既定拒否、それからセグメント分割。認証の移行はいちばん重いので最後でいい。

前稿に書いたとおり、当面の課題は取り外しではなく閉じ込めである。閉じ込めの線は、責任を置ける単位に引く。

観測点

ネットワーク。 侵害が起きたとき、業務が止まった範囲が全体の何割だったか。外向き通信を既定拒否にしている企業の比率。

認証。 ディレクトリを持たずに運用している中小企業の比率。

復旧。 復旧試験を年に一度でも実施している企業の比率。実施していない復旧手順は、手順ではなく願望である。

そして本稿が外れる条件。本稿の措置を実施した組織が、実施していない組織と同じ確率で全面停止に至った場合、この論は成り立たない。外れたら、外れたと書く。

参考

前稿「AI時代に必要な人」── https://aiseed.dev/blog/three-conditions-ai-era/