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

SaaSを使っていても、ランサムウェアの被害は起こり得ます。被害には、SaaS事業者のシステムが攻撃されるケースと、利用企業のPCや管理者IDが入口になるケースがあり、前者の防御は事業者、後者の設定と運用は利用企業の責任範囲です。IPAの「情報セキュリティ10大脅威 2026」では、組織向けの1位が「ランサム攻撃による被害」で、2位にも「サプライチェーンや委託先を狙った攻撃」が入っています。本記事では、責任分界点、被害のパターン、事業者側の対策実態、初動対応、契約前の確認項目、失敗パターンを、利用企業の立場から順に整理します。

目次

開く

閉じる

1. SaaSのランサムウェア対策｜責任分界点(共有責任モデル)と自社の守備範囲
2. SaaSのランサムウェア被害範囲｜事業者側と利用企業側
3. SaaS事業者の対策実態｜Assured調査から見る課題
4. 被害発生時の初動対応フロー
5. 契約前に確認すべき項目チェックリスト
6. よくある失敗パターン5つ(バックアップ・監視体制・アカウント管理の不備)
7. 対策の効果をどう確認するか
8. よくある質問(FAQ)
9. まとめ
10. 参考文献

SaaSのランサムウェア対策｜責任分界点(共有責任モデル)と自社の守備範囲

SaaSのセキュリティは、事業者と利用企業が分担して守る共有責任モデルが基本です。サーバーやアプリケーションの保護は事業者が、IDや権限、端末、自社データの保全は利用企業が担います。

グループウェアのように全社員が使い、ファイルが集まるSaaSを例に、責任範囲を整理しました。

対策の領域	主に責任を持つ側	SaaSでの具体例(グループウェアなど)
サーバー・ネットワーク・アプリケーションの保護	SaaS事業者	脆弱性の修正、不正侵入の監視、データセンターの管理
事業者側のバックアップと復旧	SaaS事業者	システム全体のバックアップ取得、障害時の復旧手順
IDとパスワードの管理	利用企業	多要素認証の有効化、退職者アカウントの削除、パスワードの使い回し防止
権限の設定	利用企業	管理者権限を持つ人数の絞り込み、フォルダごとの閲覧・編集権限の見直し
端末とアクセス元の管理	利用企業	IPアドレス制限、私物端末からのアクセス制御、PCのウイルス対策
自社データの保全	利用企業(契約内容による)	重要ファイルのエクスポート、ゴミ箱・版管理の保存期間の確認

自社でAWSなどのクラウド上に業務システムや顧客向けのサービスを構築している場合は、立場が変わります。AWSの公式ページによれば、AWSはホストOSと仮想化レイヤーから施設の物理的なセキュリティまでを運用・管理し、お客様はゲストOS(更新とセキュリティパッチを含む)、関連するアプリケーションソフトウェア、セキュリティグループのファイアウォール設定に責任を持ちます。つまり、SaaS事業者に確認してきた監視・バックアップ・復旧の項目が、そのまま自社の課題になります。夜間や休日に異常へ気づく体制を外部に任せる手段として、ビジネスコンシェルジュに掲載されている2つのサービスを、役割の違いで整理しました。SaaSそのものを守る製品ではなく、AWS上で動かす場合の運用側のサービスです。AWSを使っていない会社は、この節のサービス紹介は読み飛ばして構いません。

AWS上で自社の業務システムや自社サービスを動かし、夜間や休日の監視に人手を割けない場合の一例が、GMOグローバルサイン・ホールディングス株式会社が提供する「AWS監視・運用 マネージドクラウド for AWS」です。AWSの運用保守・監視・障害対応を代行するサービスで、24時間365日の有人監視体制を備え、監視ツールはAmazon CloudWatch、Zabbix、Mackerelから選べると商品ページに記載されています。注意したいのは、障害発生時の一次対応が手順書に沿った復旧になる点と、プランによってはAWS請求代行の契約が必要で最低利用期間がある点です。ランサムウェアの兆候の検知まで監視の対象に含まれるかどうかは、資料や公式サイトで確認してください。料金はプランによって異なるため、資料や公式サイトで確認してください。

「データベースに障害があった際、バックアップはしっかりとっているものの、復旧に時間がかかってしまうのではないかという心配もあり、クラウドサービスの利用で解決できないかと考えていたのです。」

出典：CloudCREW byGMO 導入事例(GMOペパボ株式会社。ネットショップ作成サービス「カラーミーショップ」のデータベースをAWSへ移設)

SaaS事業者の側に立つ会社でも、「バックアップはあるが復旧に時間がかかる」という不安は共通しています。この不安は、利用企業が事業者に確認する復旧の観点と同じものです。続く節では、被害の範囲から順に見ていきます。責任範囲の全体像は、SaaSセキュリティとは｜利用者の責任範囲とリスク・対策の基本でも確認できます。

SaaSのランサムウェア被害範囲｜事業者側と利用企業側

SaaSのランサムウェア被害は、事業者のシステムが攻撃されて全利用企業に影響が出るケースと、利用企業側のPCやIDが入口となって自社のデータだけが被害を受けるケースの2つに大きく分かれます。どちらが起きたかで、取るべき対応も変わります。

ランサムウェアは、データを暗号化して使えなくし、元に戻すことと引き換えに身代金を要求する不正プログラムです。近年は暗号化に加えてデータを盗み出し、「支払わなければ公開する」と脅す二重恐喝の手口が主流になっています。IPA(独立行政法人情報処理推進機構)の「情報セキュリティ10大脅威 2026」でも、組織向けの1位は「ランサム攻撃による被害」で、11年連続の選出となっています。

警察庁の「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」によると、令和8年上半期のランサムウェア被害報告は123件で、半期の件数としては統計を取り始めた令和2年下半期以降で最多でした。被害企業の規模では中小企業が約6割を占め、被害組織へのアンケートでは侵入経路がVPN機器で約5割とされています。二重恐喝が被害の多くを占め、長期にわたって企業活動が阻害される被害も続いています。VPN機器やリモート接続の弱点から社内に入られると、PCと同期しているSaaS上のファイルにまで暗号化が波及し得る点が、SaaS利用企業にとっての現実的なリスクです。

被害のパターン	主な入口	影響範囲
事業者側のシステムが攻撃される	事業者のサーバーの脆弱性、VPN機器、事業者社員のID	そのSaaSを使う全利用企業。サービス停止、データの暗号化や流出
利用企業のPCが感染し、同期ファイルが暗号化される	メールの添付ファイル、不正なWebサイト、脆弱なリモート接続	同期フォルダやファイル共有を通じて、クラウド上のファイルまで暗号化される
利用企業の管理者IDが乗っ取られる	パスワードの使い回し、フィッシング、多要素認証の未設定	自社テナント内のデータの削除・改ざん・持ち出し、設定の変更
連携先サービスを経由した被害	API連携しているほかのSaaSや外部ツールの侵害	連携の権限の範囲内でデータが読み出される、書き換えられる
自社でクラウド上に構築したシステムが狙われる	設定不備のあるストレージ、盗まれた認証情報	スナップショットやバックアップ、データベースが暗号化・削除され、復旧手段が失われる

「クラウドにあるデータは安全」と考えがちですが、PCとクラウドのファイルを自動で同期している場合、PCで暗号化されたファイルがそのままクラウドにも反映されてしまいます。また、正規の管理者IDでログインされると、SaaS側からは通常の操作と見分けがつきにくく、事業者の監視だけでは気づけないこともあります。メールのリンクから偽のログイン画面に誘導され、ID・パスワードを入力してしまうフィッシングは、管理者IDの乗っ取りの代表的な入口です。多要素認証の強制に加えて、不審なメールを受け取ったときの報告先を決めておくことが、SaaS上のフィッシング対策になります。

事業者側のシステムが攻撃された場合、利用企業にできることは限られます。業務が止まる期間の代替手段と、自社データのコピーを持っているかどうかが、被害の大きさを左右します。IPAの10大脅威で「サプライチェーンや委託先を狙った攻撃」が2位に入っているとおり、委託先であるSaaS事業者の被害が自社の業務停止につながる構図は、SaaSでも同じです。

自社でクラウド上に構築したシステムが狙われる場合

トレンドマイクロのレポートによれば、ランサムウェアグループはクラウド環境への攻勢を強めており、設定不備のあるクラウド上のストレージや盗まれた認証情報を悪用する動きが目立つとされています。AWSでは、EBSのスナップショット、S3バケット、データベース、バックアップや災害復旧用のシステムなどが、復旧を妨げる目的で狙われやすいリソースとして挙げられています。スナップショットが失われると、システムをゼロから再構築するのに数日以上かかることもあります。自社でクラウド上にシステムを持つ会社は、SaaS事業者と同じく、アクセス権限の絞り込み、バックアップの分離保管、管理画面へのアクセス監視を自社で担う必要があります。

SaaS事業者の対策実態｜Assured調査から見る課題

クラウドサービスのセキュリティ評価を行うAssuredが公開した調査では、ペネトレーションテストの実施率は39.6%、EDRの導入率は40.2%、リストアテストの実施率は48.1%でした。対策が十分とはいえない事業者も一定数あり、「SaaSだから安全」とは言い切れないのが実態です。

この調査は、Assuredのセキュリティ調査に回答したクラウドサービス事業者3,887件のデータを分析したもので、2025年10月16日時点の集計です。ランサムウェア対策を「予防」「検知・監視」「バックアップ・復旧」の3つの観点で整理すると、次のようになります。

観点	調査項目	実施率
予防	アプリケーションの脆弱性診断の実施	75.1%
予防	ペネトレーションテストの実施	39.6%
予防	設定診断(セキュリティポスチャーアセスメント)の実施	27.8%
予防	EDR(端末の不審な挙動を検知する仕組み)の導入	40.2%
予防	インフラやデータベース、IaaS等のアカウントに、多要素認証等の認証方式でアクセス制御を実施	61.3%(未実施は38.7%)
検知・監視	攻撃の兆候の監視	69.2%
検知・監視	IaaS/PaaSの管理画面へのアクセス監視	65.3%
バックアップ・復旧	バックアップの定期的な確認	82.0%
バックアップ・復旧	バックアップの物理的な分離保管	57.1%
バックアップ・復旧	オフラインまたは不変(イミュータブル)なストレージでの保管	48.3%
バックアップ・復旧	リストア(復元)テストの実施	48.1%
バックアップ・復旧	実機訓練を含むBCPの策定	33.4%

特に注目したいのは、バックアップ・復旧の項目です。バックアップを定期的に確認している事業者は82.0%と多い一方、ランサムウェアに強い保管方法であるオフラインまたは不変ストレージでの保管は48.3%にとどまります。バックアップを取っていても、本番環境と同じネットワークや権限で管理されていれば、攻撃者にバックアップごと暗号化・削除される恐れがあります。また、実際に復元できるかを試すリストアテストを行っている事業者は半数に届いていません。攻撃を受けたときに「バックアップはあったが、戻せなかった」「戻すまでに何週間もかかった」という事態は、利用企業の業務にそのまま響きます。

この数字は事業者全体の傾向であり、個々のサービスの対策状況は契約前・更新前に利用企業が自ら確認する必要があります。確認の具体的な項目は、後の「契約前に確認すべき項目チェックリスト」で整理しています。

被害発生時の初動対応フロー

SaaSでランサムウェア被害が疑われたら、感染の疑いがある端末をネットワークから切り離し、該当IDのパスワード変更とセッションの無効化を行ったうえで、SaaS事業者と社内の責任者に連絡します。ログの保全を先に済ませ、原因が分かるまで端末の初期化は行いません。

初動の遅れは、暗号化されるファイルやデータを持ち出されるアカウントを増やします。一方で、慌てて端末を初期化したりログを消したりすると、侵入経路の調査ができなくなります。利用企業側で行う初動対応を、時系列で整理しました。

段階	行うこと	注意点
1. 検知・報告	ファイルが開けない、拡張子が変わった、脅迫文が表示された等の異常を社内窓口に報告する	現場の社員がすぐに報告できる連絡先を、事前に決めて周知しておく
2. 隔離	感染が疑われるPCをLANケーブルやWi-Fiから切り離す。同期ソフトを停止する	電源は切らずにネットワークだけを切る(メモリ上の痕跡を残すため)
3. アカウントの保護	影響が疑われるIDのパスワード変更、ログイン中のセッションの強制ログアウト、APIキーの再発行	管理者IDが侵害された可能性があれば、別の管理者IDから操作する
4. 証拠の保全	SaaSの監査ログ・ログイン履歴をエクスポートし、画面の表示や脅迫文を記録する	ログの保存期間が短いサービスもあるため、最初に保存する
5. 事業者・関係先への連絡	SaaS事業者のサポート窓口へ連絡し、事業者側の障害かどうかを確認する。経営層に報告する	個人情報の漏えいのおそれがある場合は、個人情報保護委員会への報告と本人への通知が必要になる場合がある
6. 復旧	版管理やゴミ箱、バックアップから暗号化前のデータを復元する	侵入経路をふさぐ前に復元すると、再び暗号化される恐れがある
7. 届出・再発防止	警察への相談・被害届、原因の分析と設定の見直し	身代金の支払いは、データが戻る保証がなく、さらなる攻撃を招く恐れがあるため推奨されない

この流れのうち、3のアカウントの保護と4の証拠の保全は、SaaSの管理画面の機能に大きく左右されます。強制ログアウトの操作ができない、監査ログが残っていない、残っていても保存期間が数日しかない、といった状態では、侵入経路や被害範囲を特定できません。保存期間を過ぎた監査ログは、事業者側から確認できなくなることもあります。ファイルが集まり、アカウントも多い主要なSaaSについて、こうした機能が備わっているか、実際に設定されているかを平時のうちに確認しておきましょう。感染した端末側の復旧手順を含むランサムウェア対策全般は、ランサムウェア対策7ステップ｜3-2-1バックアップと感染時の初動対応を解説で解説しています。

警察と個人情報保護委員会への連絡

警察庁の統計資料によると、警察は被害組織の状況に応じて、初動対応への助言やデータ復号ツールの提供などの支援を行うことがあり、被害に遭った際は早期に警察や関係機関へ通報・相談するよう呼びかけています。個人データの漏えい等(そのおそれを含む)が一定の要件に当たる場合は、個人情報保護委員会への報告が義務付けられています。同委員会の案内では、発覚したらまず速やかに報告するものとされ、期限の目安は、速報が発覚日から3-5日以内、確報が30日以内(不正な目的で行われたおそれがある場合は60日以内)です。ここでの説明は一般的な整理であり、法的助言ではありません。自社が報告の対象になるか、SaaS事業者との役割分担がどうなるかは、同委員会の案内や顧問の弁護士に確認してください。

被害が長期化し、費用が大きくなりやすい点も、平時の備えが大切な理由です。警察庁の統計資料では、令和8年上半期に被害に遭った企業・団体等へのアンケートで、復旧に総額1,000万円以上を要した組織が全体の約6割、1か月未満で復旧した組織は5割弱とされています。ここまでの初動対応を、自社の今の体制に当てはめて確認できるチェックを用意しました。

契約前に確認すべき項目チェックリスト

SaaSを契約する前、または更新する前には、認証・ログ・バックアップ・障害時の連絡体制・第三者認証の5つの観点で、事業者の対策を確認します。公開資料で分からない項目は、セキュリティチェックシートなどで事業者に直接問い合わせましょう。

観点	確認する項目	確認のポイント
認証・アクセス制御	多要素認証、シングルサインオン、IPアドレス制限、端末制限に対応しているか	上位プランのみの機能になっていないか、全ユーザーに強制できるか
権限の分離	管理者、バックアップ操作、本番データの操作で権限が分かれているか	1つのIDが侵害されても、バックアップまで同時に消されない設計か
ログ	ログイン履歴・操作ログを取得でき、エクスポートできるか	保存期間の長さ、管理者の操作も記録されるか
バックアップ・復旧	バックアップの取得頻度と保存期間、分離保管の有無、リストアテストの実施	利用企業の依頼で特定時点に戻せるか、目標復旧時間が示されているか
データの持ち出し	自社データを一括でエクスポートできるか、版管理・ゴミ箱の保存期間	事業者が止まったときに、手元のデータで業務を続けられる形式か
データの保管場所	データセンターやクラウド基盤の所在(国・リージョン)が示されているか	契約や社内規程で定める保管場所の条件に合っているか
障害時の連絡体制	インシデント発生時の通知方法・通知までの時間、サポート窓口の受付時間	SLA(サービス品質の保証)や利用規約に通知義務が書かれているか
第三者認証・診断	ISMS(ISO/IEC 27001)、ISMSクラウドセキュリティ認証(ISO/IEC 27017)、ISMAPへの登録、脆弱性診断の実施	認証の対象範囲に、そのサービスが含まれているか
連携・委託先	外部サービスとのAPI連携の権限管理、再委託先のクラウド基盤	連携アプリに与える権限を必要最小限に絞れるか

すべての項目を満たすサービスを探すのは現実的ではありません。業務への影響が大きいSaaS(顧客情報や基幹データを扱うもの、全社員が毎日使うもの)ほど確認項目を厳しくし、影響の小さいSaaSは最低限の項目に絞る、というように重要度で優先順位をつけると、確認作業を続けやすくなります。すでに契約中のSaaSについても、更新のタイミングで同じ観点から見直しましょう。ISMAPや個人情報保護法の観点を含むSaaS全般の確認項目は、SaaSセキュリティとは｜利用者の責任範囲とリスク・対策の基本も参考になります。

よくある失敗パターン5つ(バックアップ・監視体制・アカウント管理の不備)

SaaS利用企業のランサムウェア対策でよくある失敗は、バックアップを事業者任せにする、同期フォルダを無制限に使う、管理者IDを共有する、ログを見ていない、退職者アカウントや部署ごとの契約を放置する、の5つです。いずれも設定と運用ルールの見直しで改善できます。

失敗パターン	Before(よくある状態)	After(改善後)
1. バックアップを事業者任せにする	事業者がバックアップを取っていると思い込み、自社で個別のデータを戻せる期間や方法を把握していない	復元できる期間と手順を確認し、重要データは定期的にエクスポートして別の場所に保管する
2. 同期フォルダを無制限に使う	全社員のPCで共有フォルダ全体を自動同期しており、1台の感染で共有ファイルがまとめて暗号化される	同期する範囲を業務に必要なフォルダに絞り、版管理を有効にして暗号化前の状態に戻せるようにする
3. 管理者IDを共有する	1つの管理者IDとパスワードを複数人で使い回し、多要素認証も設定していない	管理者は個人ごとのIDにして人数を絞り、多要素認証を必須にする
4. ログを見ていない	監査ログは取得しているが誰も確認しておらず、深夜の大量ダウンロードや海外からのログインに気づかない	不審なログインや大量操作の通知を設定し、確認する担当者と頻度を決める
5. 退職者アカウントと部署ごとの契約を放置する	退職者のIDが残ったままで、部署が個別に契約したSaaSは情報システム部門が把握していない	人事の在籍者リストとSaaSのアカウント一覧を突き合わせ、契約中のSaaSを一覧にして管理者と責任者を決める

このほか、連携アプリに必要以上の権限を与えている、といった状態も侵入の入口になります。年に1回から2回、アカウントと権限の棚卸しを行う日を決めておくと、放置を防げます。優先順位のつけ方は、ランサムウェア対策の手順と実践ガイド｜中小企業が優先すべき7つの施策【2026年版】でも整理しています。

対策の効果をどう確認するか

対策の効果は、多要素認証の設定率や、不要なアカウント・管理者権限の数、リストアにかかった時間などの数値で定期的に確認します。数値で追うと、設定の抜け漏れや運用の形骸化に早く気づけます。

確認する指標	確認方法	目安
多要素認証の設定率	管理画面のユーザー一覧で、設定済みのユーザーの割合を確認する	全ユーザー100%(強制設定)
不要なアカウントの数	人事の在籍者リストとSaaSのアカウント一覧を突き合わせる	0件
管理者権限を持つ人数	権限ごとのユーザー数を確認する	業務上必要な最小人数(複数名で相互確認できる体制)
リストアにかかる時間	テスト用のファイルを削除・上書きし、復元できるまでの時間を計る	業務で許容できる停止時間内に収まるか
初動対応の訓練	被害を想定した机上訓練で、報告から隔離・事業者への連絡までの流れを確認する	年1回以上

これらの指標の多くは、SaaSの管理画面からどれだけ情報を取り出せるかで確認のしやすさが変わります。ユーザーごとの多要素認証の設定状況や権限の一覧、ログのエクスポートといった機能が不足していると、数値を集めるだけで手間がかかり、確認が続かなくなりがちです。まずは社内で最も利用者が多いSaaSで指標を確認できるかを試し、必要な機能がそろっているかを見直すことをおすすめします。

自社でAWSなどのクラウド上にシステムを持つ場合は、設定や脆弱性の状態を第三者に診断してもらい、レポートで確認する方法もあります。その一例が、GMOグローバルサイン・ホールディングス株式会社が提供するCloudCREW byGMOを通じた「CloudCREW AWS請求代行」です。基本のサービスはAWSの利用料を円建ての請求書と銀行振込で支払えるもので、セキュリティ監視・運用やAWS対応脆弱性診断が有料オプションとして用意されていると商品ページに記載されています。商品ページによれば、セキュリティ監視では検知したリスクが月次レポートで報告され、脆弱性診断では結果レポートをもとに具体的な対策が提案されます。また、東京海上日動火災保険株式会社と連携したサイバーリスク保険が標準で付帯すると記載されていますが、補償の対象や条件にランサムウェア被害が含まれるかは資料や問い合わせで確認してください。注意したいのは、監視や診断は有料オプションである点と、申込から利用開始まで1か月以上かかる場合がある点です。料金はプランによって異なるため、資料や公式サイトで確認してください。

よくある質問(FAQ)

Q1. SaaSを使っていればランサムウェアの被害は受けませんか？

A. 被害を受ける可能性はあります。事業者のシステムが攻撃されるケースのほか、利用企業のPCの感染で同期ファイルが暗号化されるケースや、管理者IDの乗っ取りでデータが削除・持ち出されるケースがあります。

Q2. SaaSのセキュリティは事業者と利用企業のどちらの責任ですか？

A. サーバーやアプリケーションの保護は事業者の責任ですが、IDとパスワードの管理、権限の設定、端末とアクセス元の管理などは利用企業の責任です。自社データの保全も、契約内容によっては利用企業が担います。AWSなどのクラウド上に自社で構築したシステムでは、ゲストOSの更新やアプリケーション、ファイアウォールの設定も利用企業の責任範囲です。

Q3. SaaS事業者のランサムウェア対策はどの程度進んでいますか？

A. Assuredが公開した事業者3,887件の調査では、ペネトレーションテストの実施率は39.6%、EDRの導入率は40.2%、リストアテストの実施率は48.1%でした。インフラ等のアカウントに多要素認証などの認証方式を用いていない事業者も38.7%あり、対策には事業者ごとにばらつきがあります。

Q4. SaaSでランサムウェア被害が疑われたら、最初に何をすべきですか？

A. 感染が疑われる端末をネットワークから切り離し、影響が疑われるIDのパスワード変更とセッションの無効化を行います。そのうえで監査ログを保全し、SaaS事業者と社内の責任者に連絡します。

Q5. SaaSの契約前には何を確認すればよいですか？

A. 多要素認証やIPアドレス制限への対応、ログの取得とエクスポート、バックアップの保存期間と分離保管、インシデント発生時の通知体制、ISMSなどの第三者認証を確認します。公開資料で分からない項目は事業者に問い合わせましょう。

Q6. ランサムウェアの身代金は支払うべきですか？

A. 支払ってもデータが戻る保証はなく、盗まれたデータが公開されない保証もありません。警察も、支払いは犯罪グループ等の活動資金となることが懸念され、復号が保証されるわけではないと説明しています。警察に相談し、バックアップからの復旧を進めましょう。

まとめ

SaaSでもランサムウェアの被害は起こり得ます。事業者のシステムが攻撃されるケースに加え、利用企業のPCやIDが入口になるケースも多く、IDや権限、端末の管理は利用企業自身の責任です。事業者側の対策にもばらつきがあるため、契約前・更新前に認証、ログ、バックアップ、連絡体制、第三者認証を確認し、被害が疑われたときの初動対応の流れを決めておくことが大切です。AWSなどのクラウド上に自社システムを持つ会社は、事業者と同じ立場で監視と復旧の体制を整える必要があります。まずは次の4つから始めてみてください。

1. 全社員が使うSaaSなど主要なSaaSで、多要素認証の強制と管理者IDの個人化を行い、退職者・異動者のアカウントを棚卸しする
2. 利用中のSaaSについて、バックアップから戻せる期間とログの保存期間を確認し、重要データを定期的にエクスポートする
3. 被害が疑われたときの報告先と初動対応の手順を決め、社内に周知して訓練する
4. AWSなどのクラウド上に自社システムがある場合は、夜間・休日の監視と診断を自社で担えるかを確認し、外部サービスの資料も比較検討する

参考文献

• 独立行政法人情報処理推進機構(IPA)「情報セキュリティ10大脅威 2026」 https://www.ipa.go.jp/security/10threats/10threats2026.html
• 警察庁「サイバー空間をめぐる脅威の情勢等」(令和8年上半期における情勢等についてを掲載) https://www.npa.go.jp/publications/statistics/cybersecurity/index.html
• 個人情報保護委員会「漏えい等の対応とお役立ち資料」 https://www.ppc.go.jp/personalinfo/legal/leakAction/
• Amazon Web Services「責任共有モデル」 https://aws.amazon.com/jp/compliance/shared-responsibility-model/
• トレンドマイクロ「クラウドストレージ「S3」を狙うランサムウェア攻撃のパターンと対策」 https://www.trendmicro.com/ja_jp/research/25/k/s3-ransomware.html
• Assured「クラウドサービス(SaaS)事業者のランサムウェア対策実態」 https://assured.jp/column/ransomware_saas
• CloudCREW byGMO「導入事例 GMOペパボ株式会社」 https://managed.gmocloud.com/case/case02.html