本セミナーは、同年5月に開催された「防御」と「復旧」をテーマにしたイベントの続編です（AWS 公式ブログ、11/10確認）。
事前の相談会やアンケートでは、「万一のとき、経営や顧客、監督官庁に何を根拠に説明すればよいのか」という疑問が多く寄せられました。この疑問に応えるため、今回は「説明責任」が3つ目の軸として新たに追加されました（AWS 公式ブログ、11/10確認）。
これら3つの軸は互いにつながっています。例えばログから侵入時期が分かれば、どの時点のバックアップに戻せばよいかを素早く絞り込めます（AWS 公式ブログ、11/10確認）。
画像：AWS（公式発表）基調講演：変わらない原則と、見直したい先送りしてきた対策
シニアセキュリティソリューションアーキテクトの中島智広氏は、ランサムウェアをめぐって「変わること」と「変わらないこと」を整理しました（AWS 公式ブログ、11/10確認）。
攻撃側も防御側もAIを使う時代になっても、セキュリティの原則自体は変わりません（AWS 公式ブログ、11/10確認）。一方で変わったのは、システムの重要度や運用負荷、コストを理由に後回しにしてきた対策の位置づけです（AWS 公式ブログ、11/10確認）。
AIによって脆弱性が短時間で大量に見つかるようになりました。かつて合理的だった水準を、もう一段引き上げる必要があります（AWS 公式ブログ、11/10確認）。
MITRE ATT&CKの14のフェーズのうち、ランサムウェア固有のデータ暗号化は最後の段階にあたります（AWS 公式ブログ、11/10確認）。裏を返せば、暗号化に至るまでに止められる機会が13段階あります。そのため、前段での素早い対策が重要になります（AWS 公式ブログ、11/10確認）。
画像：AWS（公式発表）防御・検知：暗号化に至る前の段階で止める
シニアセキュリティソリューションアーキテクトの須田聡氏は、マルウェア全般に共通する防御・検知の軸を担当しました（AWS 公式ブログ、11/10確認）。
Amazon GuardDutyとAWS Security Hub CSPMは、既存のシステムに影響を与えずに後から有効化できます。独自ルールを作る前に、重要度の高い検知から確実に対応する順番が推奨されています（AWS 公式ブログ、11/10確認）。
組織単位でまず入れてほしい設定として、AWS Organizationsからのアカウント離脱の禁止が挙げられました（AWS 公式ブログ、11/10確認）。特権を奪われたアカウントが別の組織に移される手口を防ぐため、既存の組織も一度確認が必要です（AWS 公式ブログ、11/10確認）。
さらに、Zscalerによるゼロトラストを活用した侵入・拡散対策が紹介されました。また、CrowdStrikeによるOS標準ツールを悪用するマルウェアフリー攻撃への対応と、振る舞い検知の重要性も紹介されました（AWS 公式ブログ、11/10確認）。
説明責任：侵入後に何が起きたかを時間内に説明する
「説明責任」の軸では、Cyber Security CloudとSplunkが登壇しました（AWS 公式ブログ、11/10確認）。
Cyber Security Cloudは、正規の権限を奪われてもデータを消させず、戻せて、異変に気づける状態を普段の設定で作る重要性を指摘しました（AWS 公式ブログ、11/10確認）。S3 Object LockやRDSの削除保護に加え、それらを外す操作をSCPで組織全体で拒否することが解説されました。AWS CloudTrailでS3のデータイベントやRDSの監査ログも取得しておく方法が解説されました（AWS 公式ブログ、11/10確認）。
Splunkは、ログを横断して分析し、侵入の経路を組み立てる手法を紹介しました（AWS 公式ブログ、11/10確認）。
単一の警告だけでは感染経路は分かりません。不審なリクエストや通信を横断的に見ることで、C2サーバーとの通信という像が浮かび上がります（AWS 公式ブログ、11/10確認）。その像が、再発防止や説明責任につながります。
判断ガイド今すぐ有効にするか、順番に進めるか2つの迷いに、状況ごとのおすすめと理由開く閉じる
判断ガイド
今すぐ有効にするか、順番に進めるか
状況ごとのおすすめと理由です。どれを選ぶかは、ご自身の状況で決めてください。
GuardDutyとSecurity Hubは今すぐ有効にすべき？
- 状況
- まだ有効にしていない
- おすすめ
- 確認して早めに検討する価値がある
- 理由
- 既存のシステムに影響を与えずに後から有効化できると説明されています。ただし、体制が整ってからカバレッジを広げる順番が推奨されています。
- 出どころ
- 出典・aws.amazon.com
バックアップ対策はどこから始めればいい？
- 状況
- バックアップの保護がまだ不十分
- おすすめ
- 1-1-0の3点から始めるのが出発点
- 理由
- イミュータブル保存、管理者権限を切り離した別アカウントへのエアギャップ、戻せることの検証がクラウドでのスタート地点と説明されています。
- 出どころ
- 出典・aws.amazon.com
不安Q&A
バックアップは本当に戻せる？
QAWSのデータを消されても、元に戻せますか？▾
バックアップのVault Lockをコンプライアンスモードにすると、強い権限を奪われても保持期間中は誰も削除できないと説明されています。ただし、実際に戻せるかはリストア訓練で確かめる必要があるとされています。
出典・aws.amazon.com今できることAWS BackupのVault Lockを有効にし、リストアテストを1回実行して戻せるかを確かめる。
Q侵入されたとき、いつの時点に戻せばいいか分からない▾
ログから侵入の時期が分かれば、どの時点のバックアップに戻せばよいかを早く絞り込めると説明されています。攻撃者は侵入後すぐには動かず潜伏するとも示されました。
出典・aws.amazon.com今できることCloudTrailなどのログが残る設定にしておき、侵入時期を追えるようにする。
QS3のファイルを誰かに読まれたり消されたりしても気づける？▾
大量削除や暗号化の兆候に早く気づくための土台がデータイベントの取得だと説明されています。攻撃者は削除の前に大量の読み取りを行うため、GuardDutyのS3 Protectionで窃取の段階に気づける可能性も示されました。
出典・aws.amazon.com今できることS3のデータイベントの取得状況を確認し、GuardDuty S3 Protectionの有効化も検討する。
Qバックアップがあれば、いざというとき安心？▾
訓練していない組織が当日いきなりバックアップを戻すのは難しいと、Clumioは指摘しています。確認するのは、バックアップが取れているかと運用チームが戻せるかの2点だと示されました。
出典・aws.amazon.com今できること今週中にでもリストア訓練を1回行い、運用チームが戻せるかを確かめる。
QAWS BackupのVault Lockを有効にするとどうなる？▾
コンプライアンスモードに設定しておけば、強い権限を奪われた場合でも保持期間中は誰もオブジェクトを削除できなくなります。
QAWS Organizationsで確認すべき設定とは？▾
アカウントの組織からの離脱を禁止する設定です。特権を奪われたアカウントが別の組織に移される手口を防ぐために確認が推奨されています。
