【開催報告】ランサムウェアに備える「防御」「復旧」「説明責任」— AI エージェント時代に見直す対策と次の一歩

2026 年 10 月 26 日、アマゾン ウェブ サービス ジャパン麻布台オフィスにて、招待制セキュリティセミナー「ランサムウェアに備える『防御』『復旧』『説明責任』— AI エージェント時代に見直す対策と次の一歩」を開催しました。当日は 84 名のお客様にご参加いただきました。

本セミナーは、2026 年 5 月に開催した「ランサムウェアに備える『防御』と『復旧』」の続編です。前回の相談会とアンケートで多くいただいたのが、「万一のとき、経営や顧客、監督官庁に何を根拠に説明すればよいのか」というご質問でした。この声を受けて、今回は「説明責任」を 3 つ目の軸として加えました。3 つの軸は互いにつながっています。たとえば、ログから侵入の時期がわかれば、どの時点のバックアップに戻せばよいかを早く絞り込めます。

アジェンダ

基調講演：変わらない原則と、見直したい「先送りしてきた対策」

シニアセキュリティソリューションアーキテクトの中島 智広より、ランサムウェアをめぐって「変わること」と「変わらないこと」を整理しました。

攻撃側も防御側も AI を使う時代になっても、変わらないのはセキュリティの原則、つまりこうすれば守れるという考え方です。これまで取り組んできた対策は、設計どおりに動きます。一方で「変わったこと」は、過去にシステムの重要度や運用負荷、コストを理由に「ここまでは後回しでいい」と判断してきた対策の位置づけです。AI によって脆弱性が短時間で大量に見つかるようになり、ソースコードが公開されている OSS では、修正前後の差分から攻撃コードまで作れてしまいます。その結果、かつて合理的だった水準をもう一段上げないと十分とは言えなくなりました。

MITRE ATT&CK の 14 のフェーズのうち、ランサムウェア固有のデータ暗号化は最後の段階にあたります。裏を返せば、暗号化に至るまでに止められる機会が 13 段階あるということです。だからこそ前段で「クイックにできること」が重要で、この整理が続くセッションの土台になりました。

復旧については、ディザスタリカバリ（DR）とサイバーリカバリの違いが改めて論点になりました。東京が被災したら大阪に切り替えるという DR は、既存の環境を信頼できることが前提です。侵害からの復旧では既存環境を信用できないため、新しい環境にクリーンに作り直す手順やプレイブックを用意しておく必要があります。

防御・検知：暗号化に至る前の段階で止める

AWS：GuardDuty と Security Hub の有効化、組織からの離脱禁止から始める

続いて、シニアセキュリティソリューションアーキテクトの須田 聡が「防御・検知」の軸を担当しました。扱うのは最終段階より前の 13 フェーズ、つまりマルウェア全般に共通する対策です。

最もお伝えしたかったのは、「今すぐやれることがある」ということです。Amazon GuardDuty と AWS Security Hub CSPM は、既存のシステムに影響を与えずに後から有効化できます。独自ルールを作る前に、重要度の高い検知から確実に対応する。体制が整ってからカバレッジを広げる。この順番です。検知結果の調査を AI で自動化する GuardDuty の AI-powered investigations も紹介しました。

組織単位でまず入れてほしい設定として挙がったのが、AWS Organizations からのアカウント離脱の禁止です。特権を取られたアカウントを組織から切り離して別の組織に移す手口があり、離脱を組織単位で禁止しておけばこれを防げます。最近はコンソールで新しく作成した組織には既定で入るようになったので、既存の組織は一度確認してみてください。あわせて、IAM ユーザーを使わず IAM Identity Center に寄せること、ルートユーザーの一元管理も推奨されました。

アプリケーションの領域では、10 月に一般提供を開始した AWS Continuum for code vulnerabilities を紹介しました。自社コードの脆弱性の検証から修正の提案までを AI エージェントが担います。

Zscaler：攻撃対象を見つけさせず、横移動させない

Zscaler 様のテーマはゼロトラストによる侵入・拡散対策です。攻撃者が弱点を探す工程に AI が使われるようになった、という現場の観察が共有されました。ファイアウォールと VPN で 30 年守ってきた境界型の構造的な課題は、VPN がグローバル IP として公開されていることです。公開されている限り攻撃対象として見つかります。そして一度認証を通れば内部のどこへでも行ける構成では、侵入後の横移動を止める手立てがありません。

対策の要点は 2 つ、公開された部分を見つからないようにすること、そして侵入後に横移動させないことです。アプリケーションをインターネットから隠蔽し、毎回検証してアプリケーション単位で接続させるゼロトラストに加え、即効性のある施策としておとりを配置するデセプションが紹介されました。AWS をデータセンター裏に専用線でつなぐ構成をやめ、本来のパブリッククラウドとしてインターネット経由で使う。そうすれば、全トラフィックがデータセンターに集中するボトルネックも解消します。

CrowdStrike：振る舞いで見る EDR と、人の目による脅威ハンティング

CrowdStrike 様はエンドポイントと AWS 上のワークロードの保護を扱いました。EDR などの対策の導入が進んでいるのに被害が減らない要因として示されたのが、マルウェアを使わず OS 標準のツールを悪用する「マルウェアフリー攻撃」の主流化です。同社の観測ではその比率が 2020 年の 51% から 82% に上がっています。悪意あるファイルを見つける対策だけでは足りず、どのプロセスがどの順番で動いたかという振る舞いを見る検知が必要になる、という整理です。

保護は NGAV、EDR、そして人の目で見る脅威ハンティング（Falcon OverWatch）の「3 つの壁」で構成され、導入後の運用は調査から対処まで MDR サービスの Falcon Complete が担います。GuardDuty が VPC やフローログを見るのに対し、エージェントは内部のプロセス起動やファイル実行を即時に見て止められるという、AWS サービスとの使い分けの整理も示されました。

説明責任：侵入後に何が起きたかを、時間内に説明できるようにする

今回新たに置いた「説明責任」の軸は、2 社に分担していただきました。Cyber Security Cloud 様が「正規の権限を奪われてもデータを消させず、戻せて、異変に気づける状態を普段の設定でつくる」側を、Splunk 様が「ログを横断して使い、経路を再構成する」側です。

Cyber Security Cloud：消させない・戻せる・気づくの 3 層で備える

Cyber Security Cloud 様は、AWS 環境を実際に構築して攻撃を仕掛け、どんな痕跡が残るかを検証している脅威インテリジェンスグループの立場から登壇されました。あえて「ランサムウェア」と言わず「ランサム」と呼ぶ理由は、クラウド環境の削除や暗号化はマルウェアなしで起きているからです。脅威の主体は人であり、使われるのは AWS の脆弱性ではなく正規の API です。逆に言えば、守る仕組みはすでに用意されていて、それを適切に使えるかどうかで差がつきます。

同社が対応してきたインシデントの多くは、壊せる権限を持ちながらデータの窃取で止まっています。ただし、同じ権限があれば削除まで進めます。窃取で止まっている今のうちに、削除された場合の備えを入れておいてほしい、という問題提起でした。

聴講者に投げかけられた 3 つの問いは、「復旧できますか」「保護していますか」「権限設定は適切ですか」。これに対応する備えが「消させない・戻せる・気づく」の 3 層です。

「消させない」では S3 Object Lock と RDS の削除保護を入れたうえで、それらを外す操作を SCP で組織全体で拒否すること、「戻せる」では AWS Backup の Vault Lock と別アカウント・別リージョンへのコピーが挙がりました。説明責任の軸で特に重要なのが「気づく」です。AWS CloudTrail は有効でも、S3 のデータイベントや RDS の監査ログまでは取得していない企業が多いのではないか、という指摘がありました。大量削除や暗号化の兆候に早く気づくための土台なので、取得設定を確かめておきたいところです。攻撃者は削除の前に大量の読み取りを行うため、GuardDuty の S3 Protection で窃取の段階に気づける可能性も示されました。

Splunk：ログを横断して分析し、侵入の経路を組み立てる

Splunk 様のテーマは「何かあったときの説明責任をどう果たすか」です。GuardDuty で Critical の Finding が上がり、マルウェア感染が疑われるとき、隔離や証跡保全といった対処は当然重要です。しかし「そもそもなぜこうなったのか」は対処とは別の軸で追わなければなりません。単一の Finding からは「どこから感染したのか」は分かりません。入口を特定して塞ぐことが、再発防止にも説明にもつながります。

ここで必要になるのがログの横断分析です。不審なリクエスト、不審なドメインへの問い合わせ、不審な宛先への通信は、1 つずつ見ても判断できませんが、横断的に見れば C2 サーバーとの通信という像が浮かび上がります。また基調講演の「13 段階」を引いて、途中で止まった攻撃の記録も次の備えの手がかりになる、という指摘がありました。

どのログを SIEM に入れるかは、AWS でよく言う Working Backwards の発想で、最終的にやりたいことから逆算して決めます。さらに SIEM（Splunk Enterprise Security）と SOAR を組み合わせれば、検知から調査、端末の隔離までを自動化し、SOC や CSIRT の運用を省力化できる、という紹介もありました。

復旧：消されないバックアップを持ち、戻せることを確かめておく

AWS：Vault Lock、リストアテスト、IaC の 3 ステップ

「復旧」の軸は、シニアストレージソリューションアーキテクトの焼尾 徹が AWS Backup を中心に話しました。冒頭では、起きることを前提に「そのとき誰が何をするか」を社内で決めておき、防災訓練のように一度試しておきましょう、と呼びかけました。

現場に共通する 3 つの疑問が示されました。バックアップの保持期間は何日にすべきか、確実にイミュータブルにするにはどうするか、そして「いつの時点のデータなら安心して戻せるのか」。3 つ目については、攻撃者が侵入後すぐには動かず潜伏するため、ログのフォレンジックと組み合わせると「侵害前」の時点を判断しやすくなります。ここが、今回「説明責任」を復旧の前に置いた構成の意図でもあります。

設計指針として 3-2-1-1-0 ルールが示され、今日から取り組める 3 ステップにまとめられました。

1 つ目は AWS Backup の Vault Lock の有効化です。コンプライアンスモードにしておけば、強い権限を奪われても保持期間中は誰も削除できません。

2 つ目はリストアテストの実行です。データベースの件数照合のような独自の確認を組み込むこともできます。Amazon EC2・EBS・S3 は GuardDuty Malware Protection for AWS Backup でリストアせずにリカバリポイントがクリーンかどうかを確認できます。

3 つ目は IaC です。データに加えてアプリケーションも立ち上げられるよう、環境定義を AWS CloudFormation や Terraform で持ち、定義ファイルも Object Lock で守ります。小さな環境、少ないリソースからで構わない、というのが登壇者の勧めです。

Clumio：クラウドではまず「1-1-0」とリストア訓練から

Clumio 様のテーマは、AWS 上のバックアップを確実に戻せる状態にしておくことです。亀田様は、バックアップからすぐ戻せる体制は、いまや平時に整えておくべき標準的な備えになりつつある、との見方を示しました。

復旧の現場を見てきた立場からの助言は、訓練していない組織が当日いきなりバックアップを戻すのは難しい、ということでした。推奨は、今週中にでもリストア訓練を実施すること。確認するのは「バックアップが取れているか」と「運用チームが戻せるか」の 2 点です。クラウドではまず 3-2-1-1-0 のうち「1-1-0」、つまりイミュータブル保存、管理者権限を切り離した別アカウントへのエアギャップ、戻せることの検証をしっかりやることがスタート地点です。

ランサムウェアの復旧で RTO が伸びる理由として、「いつに戻すか」を決められない問題が挙がりました。5 時間かけて戻してマルウェアを確認し、残っていれば 2 日前へ、それが無事なら 1 日前へ、とリストアを繰り返すことになります。Clumio は S3 をオブジェクト単位、EBS をファイル単位で任意の時点から取り出せるため、CloudTrail や GuardDuty のログで「どのオブジェクトが暴れたか」が分かっていれば、中身を確かめて混入時点を絞り込み、そのうえで一気に戻せます。ここでも、ログがあるかどうかが復旧時間を左右します。

おわりに：3 つの軸それぞれに「今日できること」がある

本記事では、2026 年 10 月 26 日に開催したセミナーをレポートしました。参加いただいたお客様からは「セキュリティ担当でなくても理解しやすかった。次回は担当以外のメンバーも誘って参加したい」という声もいただき、経営層や事業部門と一緒に聞いていただく価値があるテーマだと感じています。

参加者アンケートで「まず点検したいこと」の上位に挙がったのは、リストア手順と復旧検証、バックアップの保護・分離、GuardDuty と Security Hub の組織展開、侵害時に何が起きたかを説明できるログの保全・分析でした。多くの参加者が「復旧」から手を付けると答えたのは、当日の内容がそのまま次の一手になった結果だと受け止めています。

最後に、軸ごとにまず着手したいことと、AWS・パートナーそれぞれの選択肢をまとめます。

• 防御・検知: まず GuardDuty と Security Hub CSPM の有効化、Organizations からの離脱禁止。既存システムに影響なく今日できます。侵入経路や端末の対策を強めるなら、Zscaler のゼロトラスト、CrowdStrike の EDR と脅威ハンティングが選択肢になります
• 説明責任: まず CloudTrail のデータイベント（S3 のオブジェクト操作）を取っているか確認する。有効にしておけば、万一のときに「何が起きたか」を説明する根拠になります。データを消させず戻せる設定と運用は Cyber Security Cloud、ログの横断分析は Splunk が選択肢になります。
• 復旧: まず AWS Backup の Vault Lock を有効化し、リストアテストを 1 回実行して現状の復旧力を把握する。オブジェクト単位や任意の時点からの取り出しが必要なら、Clumio が選択肢になります

基調講演の言葉を借りれば、いま求められているのは「これまで合理的だった水準をもう一段上げること」です。セキュリティの責任者と実務担当者で、3 つの軸のうち自社でいちばん薄いところと、最初の一手を決めてみてください。ご相談は担当営業、ソリューションアーキテクト、または各パートナー様までお寄せください。ご参加いただいた皆様、ご登壇いただいたパートナー各社様、ありがとうございました。