業務システムやデータをAWS・Azure・Google Cloudなどのクラウドに移す企業が増えています。情報漏えいや不正アクセスへの備えも、従来のオンプレミス（自社保有のサーバー）前提から見直しが必要になっています。いざクラウドで事故が起きたとき、自社で検知・調査・復旧まで対応できるのか、不安を感じる担当者は少なくありません。
クラウドのインシデント対応は、一般的な対応の流れをそのまま持ち込めば済むものではなく、物理サーバーに触れられない、ログが既定では残らない、といったクラウド特有の勝手の違いがあります。これを知らないまま事故に直面すると、肝心の証拠が手元に残っていないという事態になりかねません。
本記事では、クラウドのインシデント対応とは何かを整理したうえで、オンプレミスとの違いとクラウド特有の落とし穴、責任共有モデルで変わる自社の調査範囲、準備から事後までの対応フロー、平時の準備チェックリスト、証拠保全と報告義務までを解説します。自社のログ設定や対応計画を点検し、足りない備えを洗い出すための材料としてご活用ください。
目次
一括ダウンロードする
クラウドのインシデント対応とは
クラウドのインシデント対応とは、IaaS・PaaS・SaaSといったクラウド環境で起きたセキュリティインシデント（情報漏えい・不正アクセス・マルウェア感染など）を、検知・調査・封じ込め・復旧する一連の対応を指します。対象がクラウドに移っても、やるべきことの骨格は従来のインシデント対応と変わりません。
その骨格としてよく参照されるのが、米国国立標準技術研究所（NIST）が示すインシデント対応のライフサイクルです。NIST SP 800-61 Rev.2 は、対応を「準備」「検知・分析」「封じ込め・根絶・復旧」「事後活動」の4つの段階に整理しています。
この Rev.2 は2025年4月に廃止され、現行の Rev.3 ではサイバーセキュリティフレームワーク（CSF 2.0）をベースに再編されましたが、4段階の枠組み自体は現在も実務で広く使われています。
国内では、JPCERTコーディネーションセンター（JPCERT/CC）が、「『インシデント』が発生した後の被害を最小限にするための『事後』対応を、インシデント対応（レスポンス）と呼んでいます」と説明しています。発生前の予防と、発生後に被害を抑える対応は別物であり、本記事が扱うのは後者にあたります。
出典・参考資料（3件）
本記事はこのあと、クラウド特有の勘所に絞って解説していきます。クラウドに限らないインシデント対応そのものの進め方（初動の手順・やってはいけないこと・報告先と期限）を一通り確認しておきたい方は、以下の記事にまとめています。
オンプレミスとの違いとクラウド特有の落とし穴
クラウドのインシデント対応でつまずきやすいのは、オンプレミス時代の進め方がそのまま通用しない点です。まずは両者の違いを一覧で押さえ、そのうえでクラウドならではの落とし穴を確認します。
| 観点 | オンプレミス | クラウド |
|---|---|---|
| 機器への物理アクセス | サーバー室に立ち入り、ディスクを直接取り外して確保できる | 物理サーバーには触れられず、事業者のサービス機能を通してしか調査できない |
| 守る責任の範囲 | 原則としてすべて自社 | 責任共有モデルにより、自社と事業者で分かれ、IaaS/PaaS/SaaSで変わる |
| ログ・証拠の残り方 | 自社が設計したログが手元に残りやすい | 詳細なログは事前に有効化しないと残らないことがある |
| 調査対象の消えやすさ | 物理サーバーは放置しても残る | オートスケールやリソース削除で、調査対象が短時間で消えることがある |
| 主な侵害対象 | サーバーや端末そのもの | サーバーだけでなく、クラウドを操作できるID（アカウント・ロール）も狙われる |
この違いを踏まえると、クラウド特有の落とし穴は次の5点に整理できます。
- 物理サーバーに触れない：ディスクを直接取り外して保全する従来の手法が使えず、スナップショットなどクラウドの機能を使って証拠を確保する必要があります。
- 責任共有モデルで自社責任の範囲が変わる：どこまでが自社の調査・対応範囲で、どこからが事業者の領域かが、利用形態（IaaS/PaaS/SaaS）によって変わります。
- ログが既定では無効で証拠が残らない：詳細な操作やデータアクセスのログは、事前に有効化していなければ記録が残らず、後から調べられないことがあります。
- オートスケール・リソース削除で揮発性の証拠が消える：負荷に応じて自動で増減するインスタンスや、削除されたリソースは、調べようとしたときには跡形もなくなっていることがあります。
- 侵害されるのがサーバーでなく操作権限を持つID：攻撃者が盗むのはサーバーそのものより、クラウドを操作できるアカウントやアクセスキーであることが多く、IDが新しい防御の境界になります。
とりわけ落とし穴③の「ログが既定では無効」は、クラウド各社に共通する勝手の違いです。主要なクラウドで、どのログが初期状態で有効なのかを一覧にすると、以下のようになります。
| クラウド | ログの種類 | 既定の状態 |
|---|---|---|
| AWS | CloudTrail 管理イベント（API操作・設定変更） | 記録される |
| AWS | CloudTrail データイベント（S3オブジェクト操作など） | 記録されない（別途有効化が必要） |
| AWS | VPCフローログ（ネットワーク通信） | 作成しないと記録されない |
| Google Cloud | 管理アクティビティ監査ログ | 常に記録される（無効化できない） |
| Google Cloud | データアクセス監査ログ | 既定で無効（BigQuery を除く） |
| Azure | アクティビティログ | 設定なしで自動収集される |
| Azure | リソースログ | 診断設定を作成しないと収集されない |
この表のとおり、AWS・Google Cloud・Azure のいずれも、操作・管理系の粗いログは既定で残りますが、どのデータに触れたか・どんな通信が流れたかといった詳細なログは、平時に有効化しておかなければ残りません。各社の公式ドキュメントの記載で確かめてみます。
AWSの公式ドキュメントは、CloudTrailについて「By default, trails and event data stores log management events, but not data or Insights events.」（既定では管理イベントは記録するが、データイベントは記録しない）と記載しています。
ネットワーク通信を記録するVPCフローログも、利用者が明示的に作成するまで記録は始まりません。
この構図はAWSに限りません。Google Cloudは、「Admin Activity audit logs are always written; you can’t configure, exclude, or disable them.」（管理アクティビティ監査ログは常に記録され、無効化できない）としています。
一方でデータアクセス監査ログについては、「Except for BigQuery, Data Access audit logs are disabled by default」（BigQueryを除き、データアクセス監査ログは既定で無効）と明記しています。
出典・参考資料（1件）
Azureも同様で、Microsoftのドキュメントはアクティビティログを「Automatically collected without configuration.」（設定なしで自動収集される）としています。
一方でリソースログは、「Aren’t collected by default. Create a diagnostic setting to collect resource logs.」（既定では収集されず、収集には診断設定の作成が必要）としています。
出典・参考資料（1件）
責任共有モデルで変わる自社の調査範囲
落とし穴②の「責任共有モデル」は、クラウドのインシデント対応の前提になる考え方です。クラウドでは、守るべき範囲を事業者と利用者で分担します。AWSはこれを「Security of the Cloud（クラウド本体の安全は事業者）」と「Security in the Cloud（クラウド上の安全は利用者）」という言葉で区別しています。
自社がどこまで調査・対応しなければならないかは、IaaS・PaaS・SaaSのどれを使うかで変わります。Microsoftが示す責任分担を整理すると、以下のようになります。
| 項目 | オンプレミス | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| データ | 自社 | 自社 | 自社 | 自社 |
| ID・利用者 | 自社 | 自社 | 自社 | 自社 |
| OS（基本ソフト） | 自社 | 自社 | 事業者 | 事業者 |
| 物理ホスト・ネットワーク・データセンター | 自社 | 事業者 | 事業者 | 事業者 |
IaaSからSaaSへ進むほど、OSやインフラの責任は事業者側へ移り、自社が直接調べられる範囲は狭まります。ただし、どの形態でも変わらないのが、データとIDは常に自社の責任だという点です。Microsoftはこの原則を次のように明記しています。
For all cloud deployment types, you own your data and identities. You’re responsible for protecting the security of your data and identities, on-premises resources, and the cloud components you control.
出典：Shared responsibility in the cloud｜Microsoft Learn
この「データとIDは常に自社責任」という原則は、先ほどの落とし穴⑤とも重なります。SaaSのように自社で触れる範囲が狭いサービスでも、不正ログインや権限の悪用といったID経由の侵害は、自社が検知・調査しなければなりません。
Google Cloudも同じ考え方で、「customers always remain responsible for their access policies and data」（利用者は常に自社のアクセスポリシーとデータに責任を持つ）としています。
出典・参考資料（2件）
クラウドでのインシデント対応フロー
ここからは、インシデントが起きたときの対応を段階ごとにたどります。NIST SP 800-61 Rev.2 の4段階（準備／検知・分析／封じ込め・根絶・復旧／事後活動）を土台に、各段階でクラウドだからこそ必要になる動きを添えます。本記事では、復旧（リカバリ）をクラウド特有の論点として独立させ、5つの見出しに分けて解説します。全体像を先に図でつかんでから、各段階を読み進めてください。
準備
対応のスピードは、発生前の備えでほぼ決まります。ログの有効化・保存設計、証拠の取得手順、連絡体制、対応計画の整備とテストをあらかじめ用意しておくことが起点になります。具体的な点検項目は、次章の準備チェックリストにまとめます。
検知・分析
異常の検知には、クラウドが提供する検知サービスを使うのが近道です。AWSのGuardDuty、Microsoft Defender for Cloud、Google CloudのSecurity Command Centerなどが、不審な操作やアクセスをアラートとして上げてくれます。
これらは各クラウドが用意するクラウドネイティブな検知サービスで、本格的な脅威検知の機能は有料プランが前提になることが多い点は押さえておきます。
アラートが上がったら、各種ログを突き合わせて、いつ・どのIDが・何に対して・何をしたのかを分析することになります。
封じ込め・根絶
被害の拡大を止める封じ込めでは、侵害されたIDの無効化、流出したアクセスキーの失効、対象リソースのネットワーク分離などを行うのが一般的です。続く根絶では、侵入の入口になった設定ミスや不要な公開など、原因そのものを取り除くことになります。侵害されたのがサーバーよりもIDであることが多いクラウドでは、この権限まわりの封じ込めが要になります。
復旧
クラウドの復旧では、汚染された環境を手作業で直すより、クリーンな状態から作り直すほうが速く確実なことがあります。AWSのセキュリティインシデント対応ガイドも、設定ミスが原因の場合は再デプロイで解決できる場合があるとしています。
再デプロイのメカニズムを使用する – セキュリティの異常が設定ミスに起因する場合は、設定ミスを修正してリソースを再デプロイするだけで解決できる場合があります。
出典：クラウド内でのインシデント対応｜AWS セキュリティインシデント対応ガイド
設定の修正が済んだら、クリーンなスナップショットやコード（Infrastructure as Code）からリソースを再構築し、正常な状態に戻します。インフラを定義ファイルから作り直せるのは、オンプレミスにはないクラウドの強みです。
事後活動
収束後は、何が起きてどう対応したかを振り返り、検知の抜けや対応の遅れを次の備えに反映します。Microsoftのクラウドセキュリティベンチマーク（MCSB）も、インシデント後の活動として教訓の反映と証拠の保持を挙げています。調査に使ったログやスナップショットは、再発防止や報告・訴訟に備えて適切に保管します。
出典・参考資料（3件）
平時にやっておく準備チェックリスト
クラウドのインシデント対応は、発生時の初動より前の備えで結果が大きく変わります。以下は、自社の体制を点検するためのチェックリストです。
- ログの有効化と保存設計：CloudTrailのデータイベント、VPCフローログ、Google Cloudのデータアクセス監査ログ、Azureのリソースログなど、既定では残らない詳細ログを有効化し、改ざんされにくい保存先に一定期間ためておく。
- スナップショット・ディスクイメージの取得手順：侵害が疑われるインスタンスのディスクスナップショットやメモリの取得を、どの権限で・どの手順で行うかを事前に定めておく。MCSBも、証拠としてディスクのスナップショットやメモリダンプを取得する想定を示している。
- 証拠の保全先：ログやスナップショットを、侵害された環境とは別の保全用アカウントにコピーして保持する運用を決めておく。攻撃者が証拠に触れられない場所に集約することが重要。
- 連絡体制：発見者・社内の責任者・外部の支援先・報告先（個人情報保護委員会など）への連絡経路と、それぞれの役割を文書にしておく。
- 対応計画の整備とテスト：段階ごとの対応手順（ランブック）を用意し、机上演習などで実際に動くかを確かめておく。手順は作って終わりにせず、定期的に見直す。
出典・参考資料（2件）
クラウドでの証拠保全と報告義務の留意点
インシデント発生時に実際に証拠を保全するときは、消えやすいデータを先に確保するのが原則です。メモリの内容、一時ディスク、削除が予定されているリソースなどは、時間が経つと失われます。
AWSのガイドは、ログ・スナップショット・その他の証拠を一元化したセキュリティ用のクラウドアカウントにコピーして保持するよう勧めています。調査目的では、dd（Linux）などのコマンドでデータの完全なコピーを作成できるとしています。
保全の際に注意したいのが、攻撃者による証拠の改ざんです。MCSBは、調査のためにデータを取得する場合の留意点を次のように述べています。
注: インシデント関連のデータを調査のためにキャプチャする場合は、実行中のデータ侵害アクティビティ中に攻撃者が実行できるログの無効化やログの削除など、不正な変更からデータを保護するための適切なセキュリティが確保されていることを確認します。
出典：Microsoft クラウド セキュリティ ベンチマーク – インシデント対応｜Microsoft Learn
証拠を確保したうえで、個人データの漏えいがあった場合には、国内では報告義務が生じることがあります。個人情報の保護に関する法律（個人情報保護法）第26条は、一定の漏えい等が生じたときの個人情報保護委員会への報告を次のように定めています。
個人情報取扱事業者は、その取り扱う個人データの漏えい、滅失、毀損その他の個人データの安全の確保に係る事態であって個人の権利利益を害するおそれが大きいものとして個人情報保護委員会規則で定めるものが生じたときは、個人情報保護委員会規則で定めるところにより、当該事態が生じた旨を個人情報保護委員会に報告しなければならない。
出典：個人情報の保護に関する法律 第26条｜e-Gov法令検索
同条第2項では、本人への通知も義務付けられています。報告の対象となる事態は、施行規則第7条が次の4つの類型として定めています。
- 要配慮個人情報が含まれる漏えい等
- 不正に利用されると財産的被害が生じるおそれがある漏えい等
- 不正の目的をもって行われたおそれがある行為による漏えい等
- 本人の数が1,000人を超える漏えい等
いずれも「漏えい等が発生したおそれがある事態」も含む点に注意が必要です。
出典・参考資料（1件）
報告の期限について、施行規則第8条は時期を次のように定めています。
当該事態を知った日から三十日以内（当該事態が前条第三号に定めるものである場合にあつては、六十日以内）に
出典：個人情報の保護に関する法律施行規則 第8条｜e-Gov法令検索
ここで誤解しやすいのが「60日」の扱いです。60日以内が認められるのは、前条第三号（不正の目的をもって行われたおそれがある行為による漏えい）に限られます。不正アクセスによる漏えいだからといって一律に60日になるわけではなく、原則は30日以内です。また条文上は、第8条第1項で「速やかに」報告すること（概要の第一報）が求められています。
この第一報と詳細報告は、個人情報保護委員会の案内では「速報」「確報」と呼ばれています。委員会は実務上の目安として、速報を発覚から3〜5日以内、確報を30日以内（不正の目的で行われたおそれがある場合は60日以内）としています。条文の文言は「速やかに／30日以内／（例外）60日以内」であり、「速報・確報」という呼び方や「3〜5日」という日数の目安は委員会のガイダンスに基づくものです。
出典・参考資料（1件）
ここではクラウドでの証拠保全と報告義務の要点に絞りましたが、実際に個人データの漏えいが起きたときは、事実調査から個人情報保護委員会への報告・本人への通知・再発防止まで、組織としての対応フロー全体を押さえておく必要があります。その流れは以下の記事で詳しく解説しています。
よくある侵入の流れから学ぶ（設定ミスを起点とするケース）
クラウドのインシデントは、高度な攻撃よりも設定ミスを入口にすることが少なくありません。ここでは、よくある典型例を「何が起きたか→何を調べたか→教訓」の流れで一般化して紹介します。
以下は特定の事案ではなく、設定ミスを起点とする典型的な侵入の流れを一般化したものです。
何が起きたか：検証用に立てたサーバーで、管理用の接続（SSH）がパスワードのまま外部に公開されていたとします。攻撃者はこの弱点から侵入し、保存されていたアクセスキーを使って別のクラウドリソースへ横に移動し、データの保管先に到達します。入口は一つの設定ミスでも、ID経由で被害が広がるのがクラウドの特徴です。
何を調べたか：まず操作ログ（CloudTrailなど）で、どのIDがいつ・どのリソースを操作したかをたどるのが一般的です。次に、侵害が疑われるインスタンスのディスクスナップショットを取得して保全し、通信記録から外部への不審な転送がなかったかを確認します。前章までで触れたとおり、これらのログや通信記録が平時に有効化されていなければ、この調査自体が成り立ちません。
教訓：必要なログを事前に有効化しておくこと、アクセスキーや権限を必要最小限にとどめること、公開設定を定期的に点検することが、被害の発生と拡大の両方を抑えます。設定ミスは誰にでも起こり得るため、起きた後にすぐ気づき、たどれる状態をつくっておくことが鍵になります。
一括ダウンロードする
自前対応が難しいときの選択肢（外部IR・支援サービス）
ここまでの対応を専任の人材だけで回すのは、多くの企業にとって容易ではありません。自前で難しい部分は外部の力を借りることになりますが、やみくもに依頼する前に「どういうときに何が要るか」を押さえておくと、過不足のない選択ができます。
先に役割分担をはっきりさせておきます。クラウドのインシデント対応そのものの実行支援、すなわち事故が起きた後の調査・封じ込めの代行は、外部のインシデント対応（IR）・フォレンジック専門会社が担う領域です。
ここで取り上げるのは、その前段にあたる「平時から備える・侵害の痕跡を調べる」部分です。端末側の痕跡を調べる仕組みと、ネットワーク通信の証跡を残す仕組み（NDR＝Network Detection and Response、通信を監視して脅威を検知する仕組み）の2つを紹介します。
クラウド特有の最大の勘所であるID経由の侵害（不正ログイン）への備えは、GuardDuty・Defender for Cloud・Security Command Center といったクラウドネイティブの検知サービスが担います。
加えて、端末を監視して脅威に対応するEDR（Endpoint Detection and Response）や、ID管理をクラウドで提供するIDaaS（Identity as a Service）も、この備えを受け持つ領域です。
守る対象別の全体像は、後述する社内セキュリティソリューションの比較記事で確認できます。
そのうえで、課題の段階ごとに選択肢を整理します。すでに事故が起きている、あるいは侵害が強く疑われるときは、調査・封じ込めを専門に行う外部のIR・フォレンジック支援会社への依頼が選択肢になります。
依頼先を選ぶときは、自社が使うクラウド（AWS・Azure・GCPなど）での対応実績や、連絡から初動までの速さ・24時間受付の有無を確かめておくとよいでしょう。あわせて、証拠保全の手順と報告書の形式、復旧後の再発防止まで支援してもらえるかも、依頼先を絞る判断材料になります。
「侵害されているかどうか自体を確かめたい」という段階では、端末の痕跡を調べる侵害診断が向きます。発生時に通信をさかのぼって調べられるようにしておきたいなら、平時からネットワークの通信を記録しておくNDRが役立ちます。課題の段階によって、必要な手当ては変わります。
費用については、調査範囲や対象規模によって大きく変わるため、個別見積りが一般的です。公開された定価がないサービスも多く、まずは資料や見積りで対応範囲と費用感を確かめるのが現実的です。
ここで挙げた端末の侵害診断やNDRに限らず、端末・ネットワーク・ID・データ・監視運用といった守る対象ごとに社内セキュリティ製品のタイプと代表サービスを俯瞰したい場合は、以下の比較記事が全体像の把握と候補の絞り込みに役立ちます。
社内セキュリティソリューション比較｜守る対象別のタイプ・代表サービスと選び方
社内のセキュリティを強化したいものの、端末の保護から不正アクセス対策、情報漏えいの防止まで課題が広く、何から手をつければよいか判断がつかないという声は少なくありません。テレワークやクラウド利用が定着し、社外に持ち出される端末やIDが増えたこ…
| サービス名 | CoWorker 端末侵害診断サービス | Network Blackbox |
|---|---|---|
| 対応領域 | 端末（PC） Windows・Mac | ネットワーク（通信） クラウドへの不正ログインなど通信に現れない事象は対象外 |
| 調べる・記録する対象 | 端末から収集したログ （マルウェアの痕跡・認証情報の漏えい・個人クラウドへの同期・不審なUSBや大量ダウンロード・生成AI利用やMCP連携の痕跡など） | ネットワークを流れる全パケット（通信そのもの）を保存 保存したパケットを遡り、宛先・時系列・転送ファイルを確認 |
| 使いどころ | 退職時・インシデント疑い時・年1〜2回の棚卸しに実施 「すでに侵害や持ち出しの痕跡がないか」を調べる事後・平時の診断 | 平時から通信を記録しておき、発生時にさかのぼって調査・証跡に使う （フルパケットキャプチャ／フォレンジック） |
| 検知・調査の仕組み | 自社AI「Blue Agent」による解析＋専門家レビュー 速報は1週間以内、最終レポートは1か月以内 | フルパケットキャプチャを基盤に、シグネチャ検知・ユーザー行為ベースの検出（BAD）・コンテンツ分析を併用 MITRE ATT&CKベースのハンティング |
| 証拠保全 | 訴訟対応を見据えた電子証拠保全に対応 | 保存トラフィックによる時系列分析・通信記録の証跡収集 |
| 提供形態 | 専用ツールを実行しZIPを送信する遠隔診断 最大100台まで一括診断 | ミラーリング方式で導入 EDR・SIEMと連携（Syslog／REST API） |
| 費用の目安 | 端末1台あたりの単価制（税別） 台数に応じた割引あり・要問い合わせ | 要問い合わせ |
| 詳細情報 | 公式資料を見る | 公式資料を見る |
※上記は2026年11月時点の各社公式サイト・公開情報をもとに整理したものです。最新の仕様・料金・対応範囲は各社の情報をご確認ください。
1. CoWorker 端末侵害診断サービス（CoWorker株式会社）
退職者のパソコンや、侵害が疑われる端末を対象に「すでに情報の持ち出しや侵害が起きていないか」を事後に調べるのが、CoWorker株式会社の端末侵害診断サービスです。対象端末から専用ツールでログを集め、自社開発のAI「Blue Agent」とセキュリティ専門家が解析する仕組みを採っています。
常駐してリアルタイムに防ぐEDR/XDRとは位置づけが異なり、退職時・インシデント疑い・年1〜2回の定期棚卸しなど、タイミングを区切って実施する調査型のサービスです。Windows・Macに対応し、最大100台までの一括診断ができます。
診断は、送られてきた実行ファイルをダブルクリックして集めたログのZIPを送る遠隔方式で進みます。速報レポートは1週間以内、最終レポートと報告会は1か月以内に提供されます。マルウェア感染や認証情報の漏えいに加え、生成AIツールの利用ログに含まれる情報漏えいの痕跡も調査対象に含めている点が特徴です。
料金は端末1台あたりの単価制で、台数に応じたボリュームディスカウントが用意されています。総額は診断台数や範囲によって変わるため、個別の見積りが前提です。
2. Network Blackbox（株式会社クワッドマイナージャパン）
株式会社クワッドマイナージャパンが提供するNetwork Blackboxは、ネットワークを流れる通信（パケット）を収集・保存し、脅威を可視化・分析するNDR（Network Detection and Response）製品です。収集・検知・ハンティング・フォレンジック・対応の5つの機能を備えています。
ミラーリング方式で導入するためエージェントが不要で、ネットワークへの影響を抑えながら通信を記録できます。検知はシグネチャベース・ユーザー行為ベース（BAD）・コンテンツ分析の複数方式を併用します。保存したパケットを後から検索・再構成できるため、インシデント後に通信をさかのぼって調べるフォレンジックに使えます。
EDRやSIEM（Security Information and Event Management、ログを集約・分析する仕組み）とは、Syslog・REST API経由で連携する設計です。
ここで押さえておきたいのが、対象範囲の切り分けです。NDRはあくまでネットワークを流れる通信を記録・分析する仕組みであり、クラウドサービスへの不正ログインのように、ネットワーク上に現れない事象は対象外になります。端末内の操作やID経由の不正までカバーするには、EDRやIDaaSなど別の仕組みと組み合わせる前提で考える必要があります。
料金や提供形態は公表されておらず、要お問い合わせとなっています。自社のネットワーク構成に合うかを含め、まずは資料やデモで対応範囲を確かめるとよいでしょう。
まとめ
クラウドのインシデント対応は、検知・調査・封じ込め・復旧という骨格こそ従来と同じですが、物理サーバーに触れない、ログが既定では残らない、揮発性の証拠が消える、IDが新しい境界になる、といったクラウド特有の勝手の違いがあります。責任共有モデルにより、自社が調べるべき範囲も利用形態で変わります。
だからこそ、発生前の準備が結果を大きく左右します。必要なログを有効化し、証拠の取得・保全手順を定め、対応計画を用意してテストしておくことが、いざというときの初動を支えます。あわせて、個人データの漏えい時には個人情報保護法に基づく報告義務が生じ得る点も押さえておきましょう。
本記事のチェックリストを使って、自社のログ設定・証拠保全・対応計画に抜けがないかを点検してみてください。自前での対応が難しいと分かった場合は、外部のインシデント対応・フォレンジック支援、端末の侵害診断、通信を記録するNDRといった選択肢を、課題の段階に合わせて検討してください。
一括ダウンロードする
よくある質問（FAQ）
Q. クラウドのインシデント対応とは何ですか？
A. クラウドのインシデント対応とは、IaaS・PaaS・SaaSなどのクラウド環境で起きたセキュリティインシデント（情報漏えい・不正アクセス・マルウェア感染など）を、検知・調査・封じ込め・復旧する一連の対応を指します。
やるべきことの骨格は従来のインシデント対応と同じですが、物理サーバーに触れられない・ログが既定では残らないといったクラウド特有の勝手の違いがあるため、オンプレミス時代の進め方をそのまま持ち込めない点に注意が必要です。
Q. クラウドのインシデント対応はオンプレミスと何が違いますか？
A. クラウドのインシデント対応がオンプレミスと違うのは、物理サーバーに触れられない・責任共有モデルで自社の責任範囲が変わる・ログが既定では無効で証拠が残らない・オートスケールやリソース削除で証拠が消える・侵害されるのがサーバーでなく操作権限を持つIDになる、という5つの点です。
とりわけログと証拠の残り方が大きく異なり、オンプレミスでは手元に残りやすい証拠が、クラウドでは事前に設定していなければ残らないことがあります。
Q. クラウドでログが残っていない場合、インシデントの調査はできますか？
A. クラウドでログが残っていない場合、調査できる範囲は大きく狭まり、何が起きたかを後からたどれないことがあります。AWS・Google Cloud・Azureのいずれも、操作・管理系の粗いログは既定で記録されますが、どのデータに触れたかなどの詳細なログは事前に有効化しなければ残りません。
だからこそ、CloudTrailのデータイベント、VPCフローログ、Google Cloudのデータアクセス監査ログ、Azureのリソースログなど、既定では残らないログを平時に有効化しておくことが欠かせません。
Q. 責任共有モデルでは、クラウドのインシデント対応はどこまでが自社の責任ですか？
A. 責任共有モデルでは、OSやインフラの責任は利用形態（IaaS→PaaS→SaaS）が上がるほど事業者側へ移りますが、データとID（アカウント）は形態を問わず常に自社の責任です。したがって、SaaSのように自社で直接触れる範囲が狭いサービスでも、不正ログインや権限の悪用といったID経由の侵害は、自社が検知・調査しなければなりません。
Q. クラウドでインシデントが発生したら、まず何をすべきですか？
A. クラウドでインシデントが発生したら、まず消えやすい証拠（メモリ・一時ディスク・削除が予定されているリソースなど）を確保し、操作ログから「いつ・どのIDが・何をしたか」を特定することが初動の要です。
そのうえで、侵害されたIDの無効化、流出したアクセスキーの失効、対象リソースのネットワーク分離などで被害の拡大を止めます。クラウドでは証拠が短時間で揮発するため、封じ込めと並行して証拠保全を急ぐ点がオンプレミスとの大きな違いです。
Q. クラウドのインシデント対応を外部に依頼すべきなのはどんなときで、費用はどのくらいですか？
A. クラウドのインシデント対応を外部に依頼すべきなのは、すでに事故が起きている・侵害が強く疑われるのに、自社の人材だけでは調査や封じ込めが回らないときで、課題の段階に応じて外部のIR・フォレンジック支援、端末の侵害診断、通信を記録するNDRなどを使い分けます。
費用は調査範囲や対象規模によって大きく変わり、公開された定価がないサービスも多いため、個別見積りが一般的です。まずは資料や見積りで対応範囲と費用感を確かめるのが現実的です。
Q. クラウドで個人データが漏えいした場合、個人情報保護委員会への報告はいつまでに必要ですか？
A. 個人データの漏えいが報告対象の事態にあたる場合、確報は原則として事態を知った日から30日以内、不正の目的をもって行われたおそれがある行為による漏えいに限って60日以内に個人情報保護委員会へ報告する必要があります。
あわせて、概要の第一報（速報）を速やかに（委員会の実務上の目安では発覚から3〜5日以内に）行うことも求められます。不正アクセスによる漏えいだからといって一律に60日になるわけではなく、原則は30日以内である点に注意してください。
出典・参考資料（2件）
クラウドインシデント対応・社内セキュリティの資料を一括チェック
MCB FinTechカタログでは、クラウドの侵害調査・端末フォレンジック・ネットワーク通信記録(NDR)などのサービス資料を無料で一括請求できます。対応範囲や費用感を並べて比較できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
