「うちはちゃんと多要素認証（MFA）を入れているから、ランサムウェアは大丈夫」――そう思っていませんか？でも実は、社員アカウントには厳格にMFAを適用していても、業務委託先の管理者アカウントだけが例外運用になっている、というケースは驚くほど多いです。情シス担当者の方からも「委託先アカウントの棚卸しをしようとしたら、誰が払い出したか分からないIDが出てきた」「サーバーの一部にEDRが入っていないのは知っているが、入れ替えが追いつかない」という声をよく伺います。

直近に公表された大規模ランサムウェア事案でも、侵入の入口が「例外的にMFA未適用だった業務委託先の管理者アカウント」であり、加えて侵害が発生したデータセンターでEDRが未導入だったことが、被害拡大の決定的な要因として報告されています。本記事では、なぜ例外運用が生まれるのか、そして自社で同じ被害を防ぐために情シス担当が今すぐ手を打つべきポイントを整理します。

何が起きているのか：典型的な侵入シナリオ

公開されているインシデント報告書や警察庁の統計を整理すると、近年のランサムウェア攻撃には共通するパターンがあります。

  • 侵入口はVPN・リモートデスクトップ経由が大半：警察庁の「令和6年におけるサイバー空間をめぐる脅威の情勢等」によると、ランサムウェア被害組織における感染経路の8割以上がVPN機器またはリモートデスクトップ経由とされています
  • 認証情報の悪用が前提：脆弱性悪用と並んで、漏洩した認証情報による正規ログインが多くを占めます
  • 長期潜伏：初期侵入から暗号化発動まで数ヶ月のラグがあるケースが報告されており、その間に内部偵察と権限昇格が進みます
  • EDR未導入領域が突破口：エンドポイント検知が効かないセグメント（旧式サーバー群、物流制御系、データセンター内の例外区画など）に攻撃者が居着くケースが多い

つまり、「例外的にMFAを外した1つのアカウント」と「EDRが入っていないサーバー群」という2つの穴が重なることで、攻撃者は長期間にわたって内部で活動する余地を得ます。逆に言えば、この2点を塞ぐだけで大半のランサムウェア事案は初動段階で検知・遮断できる可能性があります。

なぜ「例外」が生まれてしまうのか：現場のリアル

「MFAは原則として全アカウントに適用する」――これは多くの企業のポリシーに書かれている文言です。ところが現場では、次のような事情で例外が生まれます。

  • 委託先のシステムや端末がMFA非対応で、適用すると業務が止まる
  • 業務委託契約上、委託先側にMFA運用のオペレーション負荷をかけられない
  • バッチ処理用や保守用の「サービスアカウント」が、人間用アカウントと同じ運用枠で扱われている
  • 「期間限定だから」「テスト用だから」とその場の判断でMFAを外し、そのまま残り続ける

ビジネス用語に置き換えると、これは「業務優先で例外を作ったが、その例外がリスク資産として棚卸しされていない」という状態です。経営層に説明するときは、「MFA未適用アカウントの棚卸し台帳が存在するか、台帳上のリスクスコアが評価されているか」という問いかけが効きます。

何を得られるのか：例外なきMFA運用がもたらすベネフィット

委託先を含む全アカウントへの例外なきMFA適用と、全サーバーへのEDR展開を進めると、次のような効果が見込めます。

  • 初期侵入の確率を大幅に下げられる：認証情報悪用による侵入経路を直接ふさぎます
  • 「侵入後」の横展開を検知できるようになる：EDRが全サーバーに入っていれば、初期侵入の成功後にラテラルムーブメント（横展開）や権限昇格を試みる挙動を可視化できます
  • インシデント時の説明責任が果たせる：個人情報保護委員会への報告や取引先への説明において、「ポリシーが運用されていた」事実を示せます。事後のレピュテーション影響は、対策の有無で大きく変わります
  • 上司・経営層への報告がシンプルになる：「全アカウントMFA適用済み・全サーバーEDR適用済み」というKPIで管理できるようになり、四半期ごとのセキュリティ報告で「例外○件、解消計画○月まで」と進捗が示せます

実運用のハマりどころ：現場でやってわかるTips

公式ドキュメントには書かれていない、実際の運用で気をつけるべきポイントを共有します。

1. 「サービスアカウントだからMFA不要」は通用しない時代に入った
人間が使わないバッチ用・API用のサービスアカウントは、従来MFAの対象外として扱われてきました。しかし、これらのアカウントこそ高権限を持ち、認証情報がコードや設定ファイルに平文で書かれていることも多く、攻撃者の最初の標的になります。サービスアカウントは「マネージドID／ワークロードID」への移行、もしくは証明書ベース認証＋IPアドレス制限など、別の防御層で守ってください。

2. 委託先アカウントは「自社のポリシーで管理できる範囲」に絞るのが鉄則
委託先がどうしてもMFA非対応の場合、そのアカウントから到達できる範囲をジャンプサーバーやPAM（特権アクセス管理）製品の経由でしか動かせないように物理的に制限してしまうのが最も確実です。「委託先側の運用変更を待つ」と数ヶ月単位で遅延しますが、自社側のネットワーク制御だけなら数週間で実装できます。

3. EDRの「カバレッジレポート」を月次で出す
EDRは入れただけでは意味がなく、入っていないホストが何台あるかを可視化する仕組みが必要です。Microsoft Defender for Endpointなら「デバイスインベントリ」、Microsoft Sentinelと連携している場合はKQL（ログ検索の命令文）で「過去○日にEDRハートビートが届いていないサーバー一覧」を抽出できます。新規サーバー構築時の自動展開もセットで仕組み化しないと、必ず抜けが出ます。

4. MFAを外していい「例外」の承認プロセスを文書化する
「現場判断で例外にした」という状態を防ぐために、MFA例外には**情シス部門長以上の承認＋有効期限＋代替コントロール（IP制限など）**をセットで義務付けるルールを作ってください。台帳をExcelで管理するなら、有効期限が近いものを月次で抽出してアラートを出す運用にすると、放置を防げます。

次のアクション：自社環境の点検から始める

近年のランサムウェア事案が示しているのは、ひとことで言えば「ポリシーは原則ではなく例外で破られる」ということです。MFAやEDRを「導入したかどうか」ではなく、「例外が何件あるか、その例外の理由は妥当か」を点検することが、現実的な侵入抑止につながります。

とはいえ、自社環境で「どのアカウントが例外になっているか」「どのサーバーにEDRが入っていないか」を網羅的に把握するのは、運用しながらでは難しい作業です。Microsoft Entra ID／Defender for Endpoint／Sentinelを組み合わせた現状可視化や、PAM導入による委託先アクセスの分離設計など、設定や運用設計に不安がある場合は、専門家と一緒に短期間で棚卸しを進めるのが最短ルートです。Colorkrewでは、こうした「例外運用の可視化」と「再発防止策の設計」を一気通貫でご支援しています。お気軽にご相談ください。

参考文献