「Qilin（キリン）」やランサムウェア集団に関する話題を見かけると、まず自社は大丈夫か、何から対策すればよいかが気になるでしょう。けれど、固有の攻撃グループ名だけを追っても、明日の業務を守る準備には直結しません。攻撃者の名称、個別事件の捜査状況、被害の範囲は情報が更新されやすく、未確認の投稿が混ざることもあります。
企業にとって優先度が高いのは、感染を完全に防げると考えることではなく、異変が起きたときに被害を広げず、重要な仕事を安全な順序で再開できるようにすることです。データを暗号化して使えなくするだけでなく、データを持ち出したと示して公表をほのめかす手口もあるため、単に「PCを直す」だけでは足りません。業務、取引先、顧客、従業員への影響を小さくするには、復旧を中心に据えた準備が必要です。
この記事では、Qilinが話題になったことを入口に、ランサムウェア対策を一般的な組織運用として整理します。個別の侵害が疑われる場合は、社内のインシデント対応手順、契約している保守・セキュリティ事業者、関係当局や専門家の案内を優先してください。ここで紹介する内容は、被害を必ず防いだり、復旧を保証したりするものではありません。身代金、個人情報の通知、保険、契約、法的責任は、事実関係と契約内容で扱いが大きく変わります。
まず整理したい：ランサムウェア対策は「侵入防止」だけではない
ランサムウェアは、端末やサーバー内のファイルを暗号化し、利用できなくする不正プログラムとして知られています。しかし実務上の影響は、暗号化されたファイルの数だけでは測れません。受発注が止まる、勤怠や給与の処理ができない、工場や物流の予定が確認できない、顧客対応の履歴にアクセスできない、といった業務停止へ広がる可能性があります。クラウドサービス、委託先、リモート接続、共有アカウントなども関係するため、1台のPCだけの問題として切り分けられないことがあります。
また、攻撃の入口は添付ファイルだけとは限りません。漏えいした認証情報、弱いパスワード、更新されていない機器、外部公開されたリモート接続、取引先を装う連絡など、複数の経路があり得ます。原因を一つに決めつけて対策を選ぶと、別の弱点が残ります。IPAのランサムウェア対策特設ページやCISAのガイドは、予防、検知、初動、復旧、事後の改善を一続きのものとして扱っています。
ここでいう「復旧優先」は、身代金を払えば元に戻る、という意味ではありません。どの業務を最初に戻す必要があるかを平時から決め、復元に使うデータやシステムが実際に使えることを確かめ、復旧中に再び侵害を広げないようにする考え方です。バックアップの有無だけで安心せず、「どの時点のデータを」「誰が」「どの環境へ」「何時間または何日で」戻せるかを説明できる状態を目指します。
1. 重要業務を先に決める：機器の台数ではなく、止まる仕事から考える
備えの出発点は、社内に何台PCがあるかの一覧ではありません。止まると誰が困るのか、どの業務が最初に再開できなければならないのかを、部門横断で確認することです。たとえば、受注、出荷、支払い、顧客への連絡、予約、医療・安全に関わる業務などは、組織によって優先順位が異なります。情報システム部門だけでは判断しにくいため、現場、経理、総務、営業、経営層を交えて整理する価値があります。
一覧には、業務名だけでなく、依存しているものも書きます。担当者のアカウント、メール、ネットワーク、クラウドサービス、端末、認証アプリ、連携先、手作業へ切り替えるための帳票などです。「販売管理を戻す」と決めても、本人確認の仕組みやネットワークが使えなければログインできません。反対に、最初から全社ファイルサーバーを戻そうとすると、優先度の高い業務まで待たせることになりかねません。
この整理は、平時の投資判断にも役立ちます。すべてのシステムに同じ対策を施すのではなく、停止が安全、人命、顧客対応、資金繰り、法定期限に大きく影響する資産から、復旧計画、アクセス権、ログ、バックアップを厚くできます。CISAも、健康・安全、収益、重要サービスに関わる資産と依存関係を把握し、復旧の優先順位に使う考え方を示しています。
ただし、重要度の高い業務を一度決めて終わりにしないことも大切です。組織変更、サービス追加、委託先の変更、クラウド移行、連絡先の交代で依存関係は変わります。四半期ごと、半年ごとなど、自社の変化に合わせて見直す日を決め、紙や隔離された場所にも必要な連絡先と最小限の業務一覧を置くと、社内システムが使えないときに参照しやすくなります。
2. バックアップは「あるか」より「戻せるか」：隔離と復元テストを分けて確認する
ランサムウェアへの備えでよく挙がるのがバックアップです。しかし、同じネットワークに常時接続され、同じ管理者権限から削除できる保存先だけに頼ると、元のデータと一緒に暗号化・削除されるおそれがあります。CISAは、重要データのオフラインまたは隔離されたバックアップを保ち、災害復旧の場面を想定して可用性と完全性を定期的に確認するよう勧めています。
隔離には複数の方法があります。バックアップ用アカウントを通常の運用アカウントと分ける、削除や書き換えに保護をかける、世代を残す、クラウドの保存先と運用環境を分ける、物理的に接続しない媒体を管理する、といった選択肢があります。どれが適切かは、データ量、復旧目標、費用、クラウド事業者の仕様、保存義務によって変わります。特定の設定をそのまま採用する前に、サービスの公式文書と自社の要件を確認しましょう。
そして最も見落とされやすいのが復元テストです。バックアップのジョブが「成功」と表示されていても、必要な世代が残っていない、暗号化キーや認証情報が見つからない、容量不足で復元先を準備できない、アプリケーションとデータの順番が分からない、といった問題は実際の復旧時に初めて分かることがあります。少なくとも重要業務については、隔離した環境で復元できるか、必要な担当者が手順を実行できるか、想定時間内に業務確認まで進めるかを定期的に試します。
テストの記録には、成功か失敗かだけでなく、復元したデータの日時、かかった時間、つまずいた点、必要だった権限、次に直すべき手順を残します。これは監査のためだけではありません。実際の緊急時には、詳しい担当者が不在のこともあります。誰が読んでも次の行動を選べる短い手順書に直すことが、復旧の速さを左右します。
3. 初動は自己流にしない：隔離・連絡・記録の順序を事前に合わせる
画面に見慣れない拡張子が並ぶ、ファイルが開けない、身に覚えのないログイン通知が続く、共有フォルダの更新が急に増えるといった異変が起きたとき、現場の人は何とか直そうとしてしまいがちです。しかし、自己判断で削除、再起動、初期化、外部への連絡を始めると、原因の確認や影響範囲の把握を難しくすることがあります。何を保存し、誰へ伝え、どこまで切り離すかを、普段から決めておくことが重要です。
IPAの従業員向け初動対応の例では、ランサムウェア被害が疑われる場合に、PCをネットワークから切断し、メールやファイルを削除せず、PCの電源を切らないといった初動を定めています。ただし、実際に取るべき操作は端末の状態や組織の対応手順で異なります。電源断が必要になる場面も、逆に証跡を失わないために避けるべき場面もあるため、現場の個人が一般論だけで決めないことが大切です。
連絡先も、情報システム部門だけで完結させない方が安全です。夜間・休日を含む連絡窓口、意思決定者、保守事業者、クラウド事業者、法務・広報、事業継続の担当者を、連絡網に含めます。取引先や顧客への連絡が必要になり得る場合は、誰が事実確認をし、誰が文面を承認し、どのチャネルで知らせるかを事前に決めます。推測で原因や被害範囲を外部に伝えないためにも、情報の集約先が必要です。
初動の訓練は大がかりな演習でなくても構いません。「月曜の朝、共有フォルダに異常が起きた」「担当者が休みの日に不審なログインがあった」といった短い想定を置き、連絡が届くか、連絡先が現役か、担当者が判断に必要な情報へアクセスできるかを確かめます。訓練で見つかった連絡漏れや権限の偏りは、実害がないうちに直せる貴重な発見です。
4. 権限・更新・ログを日常業務に組み込む：一つの対策に頼らない
復旧の準備と並行して、侵入や横展開を難しくする基本的な運用を続けます。代表的なのは、多要素認証の利用、不要なアカウントや権限の見直し、ソフトウェアや機器の更新、外部公開している接続経路の棚卸し、ログの保全と確認です。すべてを同時に完璧にする必要はありませんが、利用頻度と影響の大きい資産から順に進めると、限られた人員でも優先順位を付けやすくなります。
権限では、「管理者だから何でもできる」状態を日常利用に混ぜないことが重要です。通常のメールや事務作業に使うアカウントと、設定変更に使う高い権限を分け、退職・異動・委託終了のタイミングで見直します。共有アカウントが必要な場合も、誰が使えるか、どの操作ができるか、いつ見直すかを記録します。多要素認証も有効な対策の一つですが、認証情報を電話やチャットで求められたときの連絡ルール、復旧コードの保管、端末紛失時の手順まで含めて整える必要があります。
更新については、端末だけでなく、ルーター、VPN、NAS、クラウドの設定、古い業務ソフトなど、見落としやすい資産を一覧に入れます。更新が業務に影響するためすぐ適用できない場合は、例外として放置せず、代替の制限、監視、更新予定日、責任者を決めます。外部から接続できる機器やサービスは、使っていないものを閉じるだけでも管理対象を減らせます。
ログは、事故が起きた後に犯人を特定するためだけのものではありません。通常と異なる大量のログイン失敗、普段と違う場所からのアクセス、権限変更、バックアップの削除、短時間での大量ファイル更新などに気づくための手がかりになります。すべてのログを人が毎日読むのは難しいため、重要な資産に絞って、保存場所、保存期間、見る人、通知条件を定めます。ログ自体が同じ侵害で失われないよう、保管先やアクセス権も確認しましょう。
5. 復旧後に終わらせない：原因探しと再開判断を分ける
業務が一部戻ると、早く通常運転へ戻したくなります。しかし、急いで元のネットワークやアカウントをつなぎ直すと、侵害が残っていた場合に再び広がるおそれがあります。復旧は、バックアップを戻す作業だけではなく、影響を受けた範囲を確認し、再侵入の経路を閉じ、清浄性を確認した環境で優先業務を再開する一連の工程です。
このとき、技術調査と経営判断を混ぜないことが役立ちます。技術側は、どの端末・アカウント・データに影響があり得るか、何が分かっていて何が未確認かを記録します。事業側は、どの業務を優先するか、代替手段をいつまで使うか、顧客や取引先への影響をどう減らすかを決めます。広報や法務、個人情報保護、契約の担当者は、通知や公表の要否を事実と規制・契約に照らして判断します。役割を分けることで、技術的な推測を断定として伝えるリスクを下げられます。
身代金の要求を受けた場合も、支払いの可否やその後の対応を単純に決めることはできません。復号やデータ削除が保証されるわけではなく、法令、制裁、保険、捜査、契約、事業継続など多くの論点が関係します。現場の担当者だけで交渉や送金を進めず、経営、法務、保険会社、専門家、関係機関と連携し、適用されるルールと自社の対応計画を確認してください。
事後には、責任追及だけを目的にせず、何が機能し何が詰まったかを振り返ります。連絡網は使えたか、バックアップは復元できたか、権限の把握に時間がかからなかったか、代替業務は回ったか、情報共有で混乱がなかったか。改善項目を担当者、期限、確認方法に分け、次の訓練で試します。このサイクルを回すことで、脅威の名称が変わっても、組織としての対応力を少しずつ高められます。
小さな組織でも始められる、最初の一週間の見直し方
専任の情報システム部門がない会社では、対策の話が大きく見え、何も始められないと感じるかもしれません。その場合は、すべての端末やシステムを一度に調べようとせず、最も止められない仕事を一つ選びます。たとえば「翌営業日に出荷するための受注一覧を確認できること」「顧客からの緊急連絡を受け取れること」「給与計算に必要な情報へ安全にアクセスできること」といった単位です。その仕事について、使うサービス、担当者、連絡先、保存されるデータ、代替手段を一枚に書き出します。
次に、その業務のバックアップを誰が見られるか、最後に復元テストをしたのはいつか、復元先を用意できるかを確認します。答えがすぐ出なくても問題ではありません。「分からない」を残さず、サービス提供元、保守担当、社内の管理者へ確認する作業に変えることが重要です。クラウドサービスを使っている場合も、自動保存や履歴機能が自社の復旧要件を満たすとは限りません。契約プラン、保存期間、削除保護、アカウントを失った場合の復旧方法を公式資料で確認します。
三つ目に、異変を見た人の連絡先を決めます。代表電話、専用メール、チャット、外部の保守窓口など、夜間や休日も含めて最初に使う方法を一つに絞ります。連絡先を社内ポータルだけに載せると、ポータルが使えないときに見つけられません。紙、電話帳、管理端末など、少なくとも一つの別経路に置くことを検討します。ただし、パスワードや復旧コードをそのまま連絡網に書かないようにします。
最後に、15分程度の短い確認をします。仮に重要なPCがネットワークへつながらなくなった場合、誰が連絡を受け、どの業務を手作業へ切り替え、どの責任者が再開を判断するのかを口頭で追います。この確認だけでも、連絡先の古さ、担当の重複、必要な書類が紙でないと見られない点などが見つかります。見つけた問題を一つ直し、次月にもう一度試す方が、完成を待って何もしないよりも実務的です。
外部の委託先に任せている場合も、丸投げにしないことが大切です。委託先が担う範囲、緊急時の連絡手段、ログやバックアップの保管場所、復旧支援の条件、通知や費用の扱いを契約書やサービス仕様で確認します。委託先の名称を知っているだけでは、インシデント時に誰が何を決めるかは分かりません。自社の経営・業務側の責任者と、技術支援側の担当をつなぐ窓口を平時に決めておくと、緊急時の確認が速くなります。
まとめ：固有名詞に振り回されず、復旧できる組織へ
Qilinのような固有名詞が話題になると、最新の手口やニュースを追いたくなります。情報収集は重要ですが、それだけで業務停止への備えは完成しません。まずは自社の重要業務と依存関係を把握し、隔離されたバックアップを実際に復元できるか試し、異変時の連絡・隔離・記録の順序を共有することが、現実的な第一歩です。
- 重要な業務と依存関係を、部門横断で優先順位にする
- バックアップは隔離し、復元テストと手順書まで用意する
- 異変時の操作は自己流にせず、連絡網と対応計画に従う
- 多要素認証、最小権限、更新、ログ確認を日常運用に組み込む
- 復旧後は再開判断と原因確認を分け、次の訓練へ反映する
ランサムウェア対策は、製品を一つ導入して完了するものではありません。人、業務、データ、委託先、復旧手順をつなげて確認し続けることが、被害の有無にかかわらず事業を守る基盤になります。自社にすでにある事業継続計画、情報セキュリティ規程、委託先との契約、バックアップ運用を見直し、分からない点は専門家や公式窓口に相談しながら、できる範囲から更新していきましょう。
