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

Check!

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

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

目次

開く

閉じる

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

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

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

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

たとえば、会計SaaSや人事SaaSを使っている場合、アプリケーション基盤の保守は事業者側が担うことが多い一方、誰に管理者権限を付けるか、退職者アカウントをいつ止めるか、CSV出力した個人データをどこに保管するかは利用者側の運用です。SaaSの基本から確認したい場合は、先にSaaSとはの整理を参照すると、クラウドサービス全体の位置づけを把握しやすくなります。

S-031との棲み分けと本記事の対象範囲

本記事は、SaaSセキュリティ全般ではなく、ランサムウェアに関係する影響範囲と初動対応に絞ります。SaaSの認証、暗号化、監査ログ、脆弱性管理、契約確認などを広く見たい場合は、saas セキュリティの記事で全体像を確認してください。本記事では、IPA「情報セキュリティ10大脅威 2026」で組織向け脅威の上位に挙げられているランサム攻撃を、SaaS利用の現場に引き寄せて扱います。

また、攻撃者の手口を詳しく解説するのではなく、利用者が自社のリスク管理、委託先管理、BCP、個人情報保護法上の報告判断に落とし込むための観点を整理します。DX全体のセキュリティ対策を並行して見たい場合はdx セキュリティ、外部委託先を含む管理を見たい場合はbpo セキュリティも合わせて確認すると、SaaS単体では見落としやすい周辺リスクを補えます。

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

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

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

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

2つ目は、管理者IDや一般ユーザーIDが侵害され、SaaS内のデータを削除、変更、窃取されるパターンです。ランサムウェアというと端末の暗号化を想像しがちですが、JPCERT/CCの侵入型ランサムウェア攻撃FAQでは、情報窃取や暗号化が組み合わさるケースが示されています。SaaSでは、強い権限を持つIDが使われると、API連携、外部共有、CSV出力、退避データの削除まで影響が広がることがあります。ID連携や認証強化の詳細はsaas ssoの記事で扱っています。

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

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

図1:SaaSランサムウェアの3パターン 端末感染、ID侵害、事業者・委託先被害の3つの入口から影響範囲を整理する図 SaaSで見る3つのランサムウェア影響経路 1 端末・同期 感染端末から同期先へ 暗号化済みファイルが広がる 世代管理の確認が必要 2 ID侵害 管理者権限の悪用 削除・窃取・外部共有 認証ログ確認が重要 3 委託先波及 事業者・保守先の被害 停止・通知・復旧判断 契約前の確認が鍵
図1:SaaSランサムウェアの3パターン

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

データ暗号化だけでなく業務停止と情報漏えいを確認する

SaaSのランサムウェア被害は、暗号化されたファイルを戻せるかだけで判断すると見落としが出ます。確認すべき範囲は、データ、業務、信用の3層です。データ層では個人データ、取引データ、ログ、バックアップの状態を見ます。業務層では受発注、請求、給与、顧客対応など、止まる業務と代替手段を見ます。信用層では取引先への説明、顧客通知、所管庁への報告、広報窓口を整理します。

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

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

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

図2:被害範囲を3層で整理する データ、業務、信用の3層でランサムウェア被害を整理する図 被害範囲は3層で切り分ける データ 暗号化・改ざん・窃取・バックアップの状態 業務 受発注・請求・顧客対応・社内承認の停止範囲 信用 顧客通知・取引先説明・報告・広報体制
図2:被害範囲はデータ・業務・信用の3層で確認する

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

非機能要件としてバックアップ・ログ・復旧目標を確認する

ランサムウェア対策は、導入後に運用で補うだけでなく、契約前の確認項目に入れることが重要です。特に、バックアップの世代、復旧時の優先順位、ログの保存期間、障害・インシデント時の通知、データエクスポート、管理者権限の分離は、SaaS選定時に確認しやすい項目です。可用性、性能、保守、セキュリティなどの幅広い観点はsaas 非機能要件の記事で整理しています。

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

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

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

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

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

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

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

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

図3:SaaS事業者側と利用者側の分担 SaaSランサムウェア対策を事業者側と利用者側に分ける図 事業者側と利用者側で確認を分担する SaaS事業者側 ・基盤、アプリ、脆弱性管理 ・バックアップ、復旧体制 ・障害、侵害時の通知 ・再委託先の管理 利用者側 ・ID、権限、SSO設定 ・端末、同期、持ち出し管理 ・データ退避、代替業務 ・報告、広報、BCP判断 片方だけでなく、契約・設定・運用をつなげて確認する
図3:SaaS事業者側と利用者側で対策を分担する

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

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

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

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

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

図4:SaaSランサムウェア被害時の初動対応フロー 検知、隔離、共有、調査、復旧、再発防止の流れを示す図 初動対応は時系列で進める 検知異常を記録 隔離端末・ID停止 共有窓口を一本化 調査範囲と原因 復旧安全確認後 再発防止:侵入経路、権限、バックアップ、契約確認を更新
図4:被害発生時は検知から再発防止まで時系列で進める

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

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

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

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

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

図5:報告判断とBCPの接続 個人情報、業法、BCPを接続して確認する図 法務判断とBCPを分けずにつなげる 個人情報 漏えい等報告 本人通知の判断 業法・契約 所管庁報告 委託元への通知 BCP 代替業務 復旧優先度 事実確認、報告、業務継続を同じタイムラインで管理する
図5:報告判断とBCPを同じタイムラインで管理する

よくある質問(FAQ)

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

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

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

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

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

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

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

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

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

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

Q. まず何を確認すればよいですか?

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

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

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

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

関連する社内規程への落とし込み

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

出典一覧

セキュリティ・初動対応に関する出典

  • 独立行政法人情報処理推進機構(IPA)/「情報セキュリティ10大脅威 2026」/2026年1月29日公開・2026年5月21日最終更新/https://www.ipa.go.jp/security/10threats/10threats2026.html/取得日:2026-06-14
  • JPCERTコーディネーションセンター/「侵入型ランサムウェア攻撃を受けたら読むFAQ」/2025年12月5日最終更新/https://www.jpcert.or.jp/magazine/security/ransom-faq.html/取得日:2026-06-14
  • 国家サイバー統括室(NCO)/「インターネットの安全・安心ハンドブック Ver 5.10」/2025年3月11日/https://security-portal.cyber.go.jp/guidance/handbook.html/取得日:2026-06-14

クラウド・個人情報に関する出典

  • 国家サイバー統括室・デジタル庁・総務省・経済産業省(ISMAP運営)/「ISMAP概要」/2026年3月更新資料を含む制度案内/https://www.ismap.go.jp/csm?id=kb_article_view&sysparm_article=KB0010005/取得日:2026-06-14
  • 個人情報保護委員会/「漏えい等の対応とお役立ち資料」/令和7年10月1日以降の共通様式案内を含む公開ページ/https://www.ppc.go.jp/personalinfo/legal/leakAction//取得日:2026-06-14
  • 個人情報保護委員会/「個人情報の保護に関する法律についてのガイドライン(通則編)」/公開ガイドライン/https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku//取得日:2026-06-14
  • National Institute of Standards and Technology/「The NIST Definition of Cloud Computing, SP 800-145」/2011年9月28日公開・2026年5月7日更新/https://www.nist.gov/publications/nist-definition-cloud-computing/取得日:2026-06-14

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

同じタグの記事を探す

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

top