Notta

SaaSのランサムウェア対策とは？被害範囲・初動対応・確認項目を解説

お役立ち記事

Share

Notta

Check!

  • SaaSへのランサムウェア攻撃3パターンと影響範囲がわかる
  • 事業者側・利用者側で分担すべき対策の整理がわかる
  • 被害発生時の初動対応と報告義務の押さえどころがわかる

SaaSは自社でサーバーを持たずに業務アプリを利用できる一方、ランサムウェア被害は「事業者側の障害」「利用者端末の感染」「ID侵害によるデータ消去や窃取」に分かれて影響が出やすいサービスです。契約先がクラウド上でシステムを管理しているからといって、利用者側の確認や初動対応が不要になるわけではありません。特に顧客情報や取引情報を扱うSaaSでは、停止時の代替手段と報告判断を事前に決めておくことが重要です。本記事では、SaaSとランサムウェアの関係を、攻撃パターン、被害範囲、選定時の確認項目、利用者側の運用、個人情報保護法上の報告判断、BCPへの組み込み方に分けて整理します。SaaS利用時のセキュリティ責任範囲・ISMAP・個情法の要点を全般的に確認したい場合はSaaSのセキュリティの記事もあわせてご覧ください。

おすすめ記事

目次

開く

閉じる
  1. SaaSのランサムウェア対策は「事業者任せ」にしない
  2. SaaSで想定するランサムウェア攻撃の3パターン
  3. 被害範囲はデータ・業務・信用の3層で見る
  4. SaaS選定時はセキュリティ確認項目を契約前にそろえる
  5. 利用者側はID・端末・バックアップを分けて守る
  6. 被害発生時は初動対応を時系列で進める
  7. 個人情報保護法・業法・BCPへの組み込み方
  8. よくある質問（FAQ）
  9. まとめ｜今日からできる3つのこと
  10. 参考文献

SaaSのランサムウェア対策は「事業者任せ」にしない

SaaSのランサムウェア対策とは、事業者側が守る範囲と利用者側が守る範囲を分けたうえで、両方の視点から確認・運用することです。クラウド利用だからといって、利用者側の責任がゼロになるわけではありません。

SaaSはクラウド利用でも責任がゼロにならない

SaaSのランサムウェア対策では、まず「どこまでをSaaS事業者が守り、どこからを利用者が守るのか」を分けて考えることが大切です。National Institute of Standards and Technology「The NIST Definition of Cloud Computing, SP 800-145」では、クラウドコンピューティングを、ネットワーク、サーバー、ストレージ、アプリケーション、サービスなどの共有資源へ、必要に応じてアクセスできるモデルとして整理しています。SaaSもこの枠組みに含まれますが、利用者側のID、端末、権限、データの扱いまで自動で整うという意味ではありません。

たとえば、会計SaaSや人事SaaSを使っている場合、アプリケーション基盤の保守は事業者側が担うことが多い一方、誰に管理者権限を付けるか、退職者アカウントをいつ止めるか、CSV出力した個人データをどこに保管するかは利用者側の運用です。

本記事の対象範囲

本記事は、SaaSセキュリティ全般ではなく、ランサムウェアに関係する影響範囲と初動対応に絞ります。攻撃者の手口を詳しく解説するのではなく、利用者が自社のリスク管理、委託先管理、BCP、個人情報保護法上の報告判断に落とし込むための観点を整理します。本記事では、独立行政法人情報処理推進機構（IPA）「情報セキュリティ10大脅威 2026」で組織向け脅威の上位に挙げられているランサム攻撃を、SaaS利用の現場に引き寄せて扱います。

SaaSで想定するランサムウェア攻撃の3パターン

SaaSにおけるランサムウェア攻撃は、利用者端末からの感染拡大、ID侵害によるデータ操作、SaaS事業者・委託先の被害波及の3パターンに分けて考えると見落としを減らせます。

1. 端末・同期 感染端末から 同期先へ拡大 暗号化済みファイルが 同期・共有される 対策：端末保護と 世代管理の確認 2. ID侵害 管理者権限の 悪用 削除・窃取・ 外部共有 対策：認証強化と 操作ログ確認 3. 委託先波及 事業者・保守先 の被害 停止・通知・ 復旧判断 対策：契約前の 確認体制
図1：SaaSで想定するランサムウェア攻撃の3パターン

利用者端末からSaaS上のデータへ影響が広がる

1つ目は、利用者のPCやファイルサーバーが感染し、SaaSと同期しているファイルや出力データに影響が出るパターンです。SaaSそのものが侵害されていなくても、端末側で暗号化されたファイルがクラウドストレージへ同期されたり、ダウンロード済みの請求書・顧客リスト・勤怠データが使えなくなったりすることがあります。SaaSを使っている企業ほど、端末とクラウドの境界が見えにくくなるため、同期設定とバックアップ世代の確認に加え、端末側の感染そのものを防ぐ対策が重要になります。

ID侵害によりSaaS内データが消去・窃取される

2つ目は、管理者IDや一般ユーザーIDが侵害され、SaaS内のデータを削除、変更、窃取されるパターンです。ランサムウェアというと端末の暗号化を想像しがちですが、JPCERTコーディネーションセンター「侵入型ランサムウェア攻撃を受けたら読むFAQ」では、情報窃取や暗号化が組み合わさるケースが示されています。SaaSでは、強い権限を持つIDが使われると、API連携、外部共有、CSV出力、退避データの削除まで影響が広がることがあります。

SaaS事業者や委託先の被害が利用者に波及する

3つ目は、SaaS事業者、運用保守会社、データセンター、外部連携先などの被害が、利用者の業務に波及するパターンです。IPA「情報セキュリティ10大脅威 2026」では、サプライチェーンや委託先を狙った攻撃も組織向け脅威として示されています。利用者はSaaS事業者の内部調査までは担えませんが、契約時に通知体制、復旧方針、委託先管理、データの所在、ログ提供の可否を確認しておくことで、被害時の判断を早めやすくなります。

被害範囲はデータ・業務・信用の3層で見る

SaaSのランサムウェア被害は、データの暗号化だけでなく、業務停止と信用への影響を合わせた3層で確認する必要があります。

データ層 個人データ・取引データ・ログ・バックアップの改ざん・暗号化・窃取 業務層 受発注・請求・給与・顧客対応の停止と代替運用 信用層 顧客・取引先・委託元・所管庁・従業者への説明と報告
図2：被害範囲はデータ・業務・信用の3層で確認する
層 確認すること 主な対応
データ 個人データ、取引データ、添付ファイル、ログ、バックアップ 改ざん・暗号化・窃取の有無を分けて確認する
業務 受発注、経理、人事、顧客対応、社内承認 停止業務と代替運用を整理する
信用 顧客、取引先、委託元、所管庁、従業者への説明 事実確認後に通知・報告・広報を進める

個人事業主・中小企業・中堅大企業で重点が変わる

個人事業主は、会計、予約、顧客管理など少数のSaaSに業務が集中しやすいため、ログインできない場合の代替手段とデータ出力の保管場所を確認しておくことが現実的です。中小企業は、管理者権限が特定担当者に集中しがちなため、承認フロー、退職者アカウント、バックアップの保護を見直します。中堅・大企業は、複数部門・子会社・委託先にまたがるため、SaaS停止時の連絡系統、広報、法務、CSIRTの役割をBCPに入れる必要があります。

SaaS選定時はセキュリティ確認項目を契約前にそろえる

ランサムウェア対策は導入後の運用だけで補うのではなく、契約前の確認項目にバックアップ・ログ・復旧目標・通知体制を含めることが重要です。

特に、バックアップの世代、復旧時の優先順位、ログの保存期間、障害・インシデント時の通知、データエクスポート、管理者権限の分離は、SaaS選定時に確認しやすい項目です。

ISMAPや第三者評価は「参考情報」として扱う

政府情報システム向けのクラウドサービス評価制度である国家サイバー統括室・デジタル庁・総務省・経済産業省（ISMAP運営）「ISMAP概要」は、政府が求めるセキュリティ要求を満たすクラウドサービスを評価・登録する制度として運営されています。民間企業がすべてのSaaS選定でISMAP登録を条件にする必要はありませんが、どのような管理基準や監査の考え方があるかを知る参考になります。選定時は、認証や第三者評価の有無だけで判断せず、自社で扱うデータの種類、業務停止の影響、復旧までの許容時間に合うかを確認します。

確認項目 見るポイント 確認先
バックアップ 世代管理、復旧単位、削除後の保持、復旧試験 サービス仕様、契約、管理画面
ログ 認証ログ、操作ログ、APIログ、保存期間、提供可否 管理画面、監査資料
通知 障害・漏えい・侵害時の通知期限と連絡先 利用規約、SLA、個別契約
権限管理 管理者分離、SSO、多要素認証、退職者管理 セキュリティ設定、IdP連携
委託先管理 再委託、運用保守、データセンター、外部連携 契約、セキュリティ白書、審査票

利用者側はID・端末・バックアップを分けて守る

SaaS利用者側の対策は、ID管理、端末対策、バックアップの3点を分けて整えることが基本です。

SaaS事業者側 基盤、アプリ、脆弱性管理 バックアップ、復旧体制 障害・侵害時の通知 再委託先の管理 利用者側 ID、権限、SSO設定 端末保護、同期・持ち出し管理 データ退避、代替業務 報告、広報、BCP判断
図3：SaaS事業者側と利用者側で対策を分担する

SSO・多要素認証・権限管理で入口を狭める

SaaS利用者側の対策では、IDを守ることが入口になります。SSOを使うと、複数SaaSの認証を集約し、退職者の停止や多要素認証の適用を管理しやすくなります。ただし、SSOそのものを導入すれば十分という話ではありません。管理者権限の棚卸し、共有アカウントの廃止、緊急時のアクセス停止手順、APIキーの管理を合わせて整える必要があります。

端末を守るウイルス対策・不正アクセス対策ソフトの選び方

前述のとおり、SaaSのランサムウェア被害は「利用者端末の感染」を起点に広がるケースが少なくありません。端末そのものの感染を防ぐことは、SSOやバックアップと並ぶ基本対策の一つです。日常的に業務で使う端末には、ウイルス対策・不正アクセス対策ソフトを導入し、常に最新の状態を保つことが前提になります。JPCERT/CCのFAQでも、被害を免れたバックアップを保護する考え方が示されていますが、そもそも端末への侵入・感染を防げれば、同期先のSaaSデータへ被害が広がるリスク自体を下げられます。

選ぶ際は、業務端末が使用しているOSへの対応状況、新しい攻撃手法に追随できる更新頻度、不正アクセスの検知・遮断機能の有無を確認します。導入前に無料トライアルでPCの動作への影響を確認しておくと、業務用端末での運用トラブルを避けやすくなります。すでに複数のSaaSを併用している企業ほど、端末側の対策が甘いと影響範囲が広がりやすいため、契約中の全端末に対策ソフトが行き届いているかを棚卸ししておくとよいでしょう。

端末同期とバックアップの上書きリスクを管理する

SaaSでも、クラウドストレージや業務データの同期設定によっては、暗号化されたファイルや削除操作が同期されることがあります。自動同期を使う場合は、復元できる世代数、削除後の保持期間、管理者による一括復元の可否、バックアップの分離を確認します。個人事業主や小規模チームでも、月次で出力する会計データや顧客データを別領域に保管するだけで、復旧の選択肢を増やせます。

被害発生時は初動対応を時系列で進める

被害が疑われる場合は、影響拡大の防止と証跡保全を並行して進め、原因調査を終える前に復旧を急がないことが重要です。

検知 異常を記録 隔離 端末・ID停止 共有 窓口を一本化 調査 範囲と原因 復旧 安全確認後 再発防止：侵入経路・権限・バックアップ・契約確認を更新
図4：被害発生時は検知から再発防止まで時系列で進める

検知直後は隔離・連絡・証跡保全を並行する

被害が疑われる場合は、まず影響拡大を防ぎながら状況を記録します。感染が疑われる端末はネットワークから切り離し、関係者に連絡し、画面、通知、ログ、メール、SaaS管理画面の状態を保存します。すぐに初期化や削除を進めると、原因調査に必要な情報が失われることがあります。JPCERT/CCは、被害範囲の把握、原因の対処、バックアップからの復旧といった方針を示しており、社内だけで判断しにくい場合は専門機関や専門企業への相談も検討します。

初動対応で起こりやすい3つの失敗パターン

初動対応では、次のような失敗が繰り返し起こりやすいことが知られています。1つ目は、原因調査より先に端末の初期化や復旧を急いでしまい、侵入経路の特定に必要なログが失われるケースです。2つ目は、バックアップから戻したデータが汚染されていないかを確認せず復旧し、同じ経路で再侵入されるケースです。3つ目は、情報システム部門だけで対応を抱え込み、法務・広報・経営層への共有が遅れて、報告義務の判断や顧客対応が後手に回るケースです。いずれも、検知直後に対応体制と役割分担を決めておくことで防ぎやすくなります。

原因対処と復旧判断を切り分ける

復旧を急ぐほど、侵入経路が残ったまま同じ被害を繰り返すおそれがあります。SaaS利用時は、影響を受けた端末、侵害されたID、SaaS上の操作、外部連携、APIキー、共有リンクを切り分けて確認します。バックアップから戻す場合も、戻すデータが汚染されていないか、復旧後に同じIDで再侵入されないかを確認します。復旧判断は情報システム部門だけで抱えず、法務、広報、経営、現場部門を含めた体制で進めることが現実的です。

個人情報保護法・業法・BCPへの組み込み方

SaaS上の個人データに影響が出た場合は、個人情報保護委員会の報告基準を確認したうえで、BCPに代替業務と連絡系統を組み込む必要があります。

個人情報 漏えい等報告 本人通知の判断 業法・契約 所管庁報告 委託元への通知 BCP 代替業務 復旧優先度
図5：報告判断とBCPを同じタイムラインで管理する

個人データ漏えい等の報告対象を確認する

SaaS上の個人データに影響が出た場合は、個人情報保護委員会「漏えい等の対応とお役立ち資料」を確認します。同ページでは、報告期限や報告が必要な場合が整理されており、ランサムウェア等により個人データが暗号化され復元できなくなった場合も例として示されています。SaaS事業者が被害を受けた場合でも、自社が個人情報取扱事業者として説明・報告を求められる場面があります。報告要否は、データの種類、件数、不正目的の有無、本人への影響をもとに判断します。詳細な判断基準は個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」で確認できます。

BCPにはSaaS停止時の代替業務を入れる

BCPに入れるべき内容は、システム復旧だけではありません。SaaSにログインできない場合の連絡先、手作業で続ける業務、復旧まで止める業務、顧客への説明文、委託先への確認先、法務判断の担当を決めておきます。医療、金融、教育、自治体関連など、各業法や契約で報告・通知の上乗せがある業務では、個人情報保護法だけで完結しないことがあります。SaaSを含む外部委託と連動している場合は、委託先との連絡手順もBCPに含めます。

なお、本記事の法令に関する記載は一般的な整理を目的としたものであり、個別事案における法的な判断は、所管の行政機関または弁護士にご確認ください。

よくある質問（FAQ）

Q1. SaaSならランサムウェア対策は事業者だけで十分ですか？

A. 十分とは言い切れません。SaaS事業者が基盤やアプリを守る一方、利用者側にはID管理、端末管理、権限棚卸し、データ出力後の保管、初動連絡の責任が残ります。契約前の確認と利用中の運用を分けて整えることが重要です。

Q2. バックアップがあれば復旧できますか？

A. バックアップがあっても、世代管理、復旧単位、削除後の保持、復旧試験が不十分だと戻せない場合があります。同期型のクラウドストレージでは、暗号化や削除が同期されることもあるため、バックアップの分離と復元手順を確認します。

Q3. 個人情報が暗号化されただけでも報告が必要ですか？

A. 個人情報保護委員会の資料では、ランサムウェア等により個人データが暗号化され、復元できなくなった場合が報告対象の例として示されています。実際の判断は、対象データ、件数、不正目的の有無、本人への影響を踏まえて確認します。

Q4. SSOを入れればランサムウェア対策になりますか？

A. SSOは認証管理を整える有効な手段の一つですが、それだけで完結するものではありません。多要素認証、権限分離、退職者アカウント停止、APIキー管理、管理者操作ログの確認と組み合わせて運用します。

Q5. ウイルス対策・不正アクセス対策ソフトはSaaS利用でも必要ですか？

A. 必要です。SaaS事業者がクラウド上のアプリケーション基盤を守っていても、利用者側の端末が感染すると、同期設定を通じてSaaS上のファイルや出力データに影響が広がることがあります。対応OS、更新頻度、不正アクセスの検知・遮断機能を確認したうえで、無料トライアルなどでPCの動作を確認しながら導入を検討するとよいでしょう。

Q6. 小規模事業者でもBCPに入れるべきですか？

A. 小規模でも、会計、予約、請求、顧客管理などのSaaSが止まると業務に影響します。大きな規程を作る前に、ログインできない場合の連絡先、手作業の代替手順、月次データの退避先を1枚にまとめるだけでも実務に役立ちます。

Q7. まず何を確認すればよいですか？

A. 利用中SaaSの管理者一覧、SSO・多要素認証の設定、端末のウイルス対策・不正アクセス対策ソフトの導入状況、バックアップと復旧手順、ログ保存期間、インシデント時の通知先、個人データの有無を確認します。これらを一覧化すると、契約更新や新規選定時の確認表にも転用できます。

まとめ｜今日からできる3つのこと

SaaSのランサムウェア対策は、情報システム部門だけの技術対策ではなく、契約、法務、広報、現場業務をまたぐ運用課題です。選定前の確認表、利用中の権限棚卸し、被害時の初動フロー、個人情報保護法上の報告判断を同じ資料にまとめると、個人事業主から中堅大企業まで、自社の規模に合わせた現実的な備えにできます。

  1. 利用中SaaSの管理者、権限、SSO、多要素認証の状態を棚卸しする。
  2. 端末のウイルス対策・不正アクセス対策ソフトを最新の状態に保ち、バックアップの世代・削除後の保持・ログ保存・インシデント通知の条件を確認する。
  3. 個人データを扱うSaaSについて、漏えい等報告とBCPの担当者を決める。

これらは一度整えれば終わりではなく、SaaSの契約更新やID・端末の入れ替わりに合わせて定期的に見直す運用項目です。特に端末側の対策とバックアップの世代管理は、被害の有無を左右する最初の分岐点になるため、担当者を明確にしたうえで、四半期ごとなど定期的な棚卸しのタイミングをあらかじめ決めておくと、対応が後回しになるのを防げます。

参考文献

この記事に興味を持った方におすすめ

同じカテゴリの記事を探す

同じタグの記事を探す

同じタグの記事はありません

掲載希望の方はこちら
top