中小企業のランサムウェア対策：優先順位と管理者・従業員の確認事項

ランサムウェアの被害は、企業の規模にかかわらず報告されています。データが暗号化されて業務が止まるほか、盗まれた情報を公開すると脅される場合もあります。個別の事例の原因は、公表された内容の範囲でしか分からないため、ここでは推定しません。公表された被害事例を、侵入口と侵入後に被害を広げた要因に分けて整理した内容は、情報漏洩の原因とは？被害事例から見る侵入経路と対策で扱っています。

何から進めるかは、対象と根拠、事業への影響、緊急性、実行の条件を確認して決めます。見直す領域は、主に次の6つです。

• 資産と外部公開：使っている機器・サービス・アカウントと、インターネットから届く機器（VPN装置など）。
• 認証と権限：多要素認証（MFA）、管理者のアカウント、退職者や委託先のアカウント。
• 更新と脆弱性：OS・ソフトウェア・機器の更新と、悪用が知られた脆弱性への対応。
• 端末の防御と監視：ウイルス対策やEDR、通知を受けて対処する担当。
• バックアップと復旧：対象、保管と保護、復元の確認。
• 従業員・委託先の行動と連絡：不審なメールの扱い、報告の窓口、連絡先。

どの対策も、導入した後は日々の業務の中で運用を続けます。何を対象に、誰が担当し、いつ何を確かめたかを記録しておきます。

対策の順番は、製品の導入順や一律の点数では決まりません。外部に公開している機器、重要な業務、すでにある対策、依存しているサービスによって変わります。次の確認表で、対策の候補ごとに判断の材料と記録を残します。この表はこの記事のための整理で、IPAやNISTなどの公式の診断票や採点表ではありません。

確認表をもとに、対策を次の3つに分けます。点数の合計では決めず、影響と緊急性、実行の条件から判断します。

• 急いで確認・対応する：悪用が知られた脆弱性がある外部公開の機器や、重要な業務のバックアップを守れているか分からない状態など、影響と緊急性が高いもの。通常の改善の計画を待たずに、保守先や担当者と並行して進めます。
• 条件を整えて変更する：MFAの適用範囲を広げる、端末の状態でアクセスを制限するなど、対象・例外・元に戻す方法を決めてから進めるもの。
• 継続して運用を確かめる：更新の適用状況、アカウントの棚卸し、バックアップの復元の確認など、入れた後も定期的に確かめるもの。

確認できていないことを安全とみなしたり、0点として後回しにしたりはしません。確認できていないもののうち、影響の大きいものから根拠を確かめます。一方で、確認する前に、一律に機器を止める、データを削除する、全員のアクセスを遮断するといった対応はしません。すでに攻撃が疑われる場合は、通常の改善の計画を待たずに、社内の責任者と保守先・専門の窓口へ連絡します。

次の表は、受注業務がある中小企業を想定した説明用の記入例です。実際の事例や実績、公式の順位ではありません。

同じ企業でも、複数の対策を並行して進めることがあります。この例は、すべての企業に当てはまる決まった順番ではありません。自社の確認表をもとに順番を決めてください。

ツールを入れた後も、誰が、何を見て、いつ確かめるかを決めて運用を続けます。ここでは一般的な確認の観点を扱い、製品ごとの設定の手順は扱いません。

• 更新と脆弱性への対応：通常の更新は、IT担当から一部の部署、全社へと段階的に広げる方法があります。ただし、悪用が知られている脆弱性、外部に公開している機器、メーカーが緊急の対応を呼びかけているものは、段階的な展開を理由に後回しにしません。更新か暫定策と期限を決め、適用した結果を確かめます。IPAのガイドラインも、セキュリティに関するアップデートを速やかに適用する運用を定めることを挙げています（中小企業の情報セキュリティ対策ガイドライン 第4.0版、p.34）。適用しない例外を認める場合は、理由と期限、代わりの対策を記録します。
• MFAと認証：管理者や、外部から使うサービス・重要なデータにアクセスする人の認証から優先して、利用者全体へ適用範囲を広げます。適用していない人、例外、代わりの対策、期限を記録します。人が使わないサービス用のアカウントには、利用者と同じMFAの設定は求めず、権限の範囲、認証情報の管理、利用の監視など、別の保護を確認します。MFAは、パスワードが盗まれた場合のリスクを下げますが、すべての攻撃を防ぐものではありません。ワンタイムパスワードを手で入力する方式は、NIST SP 800-63B-4ではフィッシング耐性のある方式に含まれていません（NIST SP 800-63B-4、3.2.5節）。
• 管理者アカウント：管理者の権限は必要な人と範囲に絞り、メールやWebの閲覧などの日常の作業とは別のアカウントで使います。操作の記録を残し、定期的に確認します。これらの運用を文書化して続ける枠組みが必要になった段階では、ISMS（ISO/IEC 27001）の導入が選択肢になります。
• 退職者・委託先のアカウント：退職や契約の終了に伴う本人のアクセスの停止と、データの保持・引継ぎ、アカウントの削除は、分けて判断します。本人のアクセスは会社が定めた終了の日時に合わせて止め、各サービスで結果を確認します。保持・引継ぎに未確認の事項があっても、それを理由に本人のアクセスの停止を先送りしません。アカウントの削除は、データの保持・引継ぎや、ほかのサービスとの連携への影響を確認したうえで時期を決めます。詳しくは、SaaSのアカウント管理で扱っています。
• 端末の状態とアクセスの条件：端末を管理ツール（MDM）に登録していること、会社が所有していること、設定の基準を満たしている（準拠している）こと、業務アプリへのアクセスを許可することは、それぞれ別です。条件付きアクセスで端末の状態を条件にする場合は、対象のアプリと利用者、OS・契約・使える機能、通常の経路と例外・代わりの経路、締め出されたときの回復と元に戻す方法を確認し、許可と拒否の結果を確かめてから範囲を広げます。Microsoftも、ポリシーの対象と影響を計画し、レポート専用モードなどで影響を確かめ、緊急用のアカウントを除外したうえで段階的に展開することを説明しています（Microsoft Entra 条件付きアクセス展開の計画）。アクセスの設計は、ゼロトラストのロードマップで扱っています。
• EPP・EDRと監視：ウイルス対策（EPP）とEDRが、予防・検知・対処のどこまでを担うかは、製品と設定によって異なります。自動で隔離する範囲と人が判断する範囲、通知が届く時間帯と担当、隔離・解除の判断と記録、外部の監視サービスを使う場合の契約の範囲を確認します。通知が届いても誰も対処できない、という状態にならないよう、担当と対応できる時間帯を先に決めておきます。
• バックアップの保護と復元の確認：ネットワークから切り離して保管すること（オフライン）と、クラウドなどで変更・削除を制限する仕組みは、同じものではありません。対象の範囲、元の環境からの分離、保存先にアクセスできる人、変更・削除の保護の条件、復元の確認を分けて確かめます。IPAのガイドラインも、バックアップの対象と頻度を定め、遠隔地を含めた保管の方法と復元の手順書を整えることを挙げています（p.33）。バックアップを取っていても、実際に戻せるかは復元して確かめるまで分かりません。復元テストの計画と記録は、バックアップ復元テストの進め方で扱っています。

巧妙なフィッシングを、従業員が毎回見抜けるとは限りません。教育で見分け方を知ってもらうことに加えて、迷ったときに安全な行動をとれるようにしておきます。

報告では、気づいた時刻、行った操作、画面に表示されたことを伝えます。開いてしまったことを責めるより、すぐに報告できる環境にしておくほうが、被害の拡大を防ぐための時間を確保しやすくなります。私物の端末やUSBメモリの利用は、業務で使う条件、許可と禁止、管理の方法を会社として決め、従業員に伝えます。

パスワードは使い回さず、重要なサービスでは、使える場合はMFAやパスキーなどの認証を強める機能を使います（IPAのガイドライン、p.24）。覚えきれない場合は、会社が認めたパスワードマネージャを使えるようにします。

以前から続けている対策には、条件によって問題になるものがあります。一律にやめるか続けるかを決める前に、どのような条件で問題になるかと、見直すときに確認することを整理します。

IPAのガイドラインも、パスワードの使い回しを防ぐルールと、パスワードの管理の方法を決めることを挙げています（p.31）。どの値を拒否できるか、漏洩した値を確認できるかは、使っているサービスの機能と契約によって異なるため、確認してから運用を決めます。

次の30/60/90日は、進める順序と期間の一例です。日数が過ぎたら次へ進むのではなく、それぞれの成果物ができ、次へ進む条件を満たしてから進みます。悪用が知られた脆弱性への対応や、バックアップの保護・復元の確認は、最初の30日から並行して進め、後の区切りまで持ち越しません。

• 30日

  段階1：現状と急ぐ課題、担当を整理する

  • 確認表で対象・根拠・影響を整理し、急いで確認・対応するものを決める
  • 外部に公開している機器と、悪用が知られた脆弱性への対応の状況を確認する
  • MFAの適用範囲と例外、管理者のアカウントの使い方を確認する
  • バックアップの対象と保護の状態を確認し、復元テストの計画を立てる
  • 成果物：確認表と、担当・期限の一覧。次へ進む条件：急ぐものの担当と期限が決まっている
• 60日

  段階2：一部に適用し、結果・例外・戻し方を確かめる

  • MFAや端末の条件などの変更を一部の利用者で試し、許可と拒否の結果を確認する
  • 更新の適用状況と例外を棚卸しし、例外に理由・期限・代わりの対策を付ける
  • EDRなどの通知を受けたときの担当と手順を決め、通知が届くことを確かめる
  • 成果物：適用の結果と例外の記録、元に戻す手順。次へ進む条件：影響と例外の扱いを判断者が確認した
• 90日

  段階3：運用を続け、次の対象と引継ぎを決める

  • 適用の範囲を広げ、定期的に確かめる項目と担当を決める
  • 復元テストなどの結果をもとに、手順書と担当表を更新する
  • 次に見直す対象と、担当が替わったときの引継ぎを決める
  • 成果物：運用の確認の予定と、更新した手順書。アクセスの設計の続きは、ゼロトラストのロードマップで扱っています

90日で安全な状態が完成するわけではありません。確認した範囲と残った課題を記録し、次の対象へ進めます。

自社の状況を確かめるための項目です。すべてに印が付いても、安全であることや、正式な評価を示すものではありません。確認できていない項目は、誰がいつまでに確かめるかを記録します。