BeeX のジャニです。
今回AWS re:Inventに参加し、数多くのセッションの中でも、Security に関するのセッションが特に強く印象に残りました。
ランサムウェア攻撃を疑似体験できるBreakout Sessionの演習で、「もし本当に起きたらどうなるのか」を段階的に体験し、Securityに携わるエンジニアとして、非常に現実的で重いコンテンツを実感しました。当時書いた雑なメモを残しておきます。
演習の概要：Zero Hour社へのランサムウェア攻撃
この演習では、「Zero Hour」という架空の企業がランサムウェア攻撃を受ける、というシナリオが設定されていました。Zero Hour社は、世界中に店舗と事業を展開するグローバルな小売企業です。
演習に入る前に、次の3つの問いが提示されました。
-
Observe：どのような脆弱性が今回の攻撃を引き起こしたのか
-
Reflect：この経験を自社の環境にどう活かせるか
-
Participate：質問や自身の経験を共有する
Scene 1：Detection（検知）
日曜日の早朝6時。
深夜のITオペレーションセンターで異変が検知されます。
- EBSのレイテンシは高い
- 読み取りI/Oは完全にフラット
- ネットワークトラフィック自体は正常
日曜日にこの状態は明らかに不自然です。
調査を進めると、特定のプロセスが継続的に書き込みを行っていることが分かります。
S3には毎分数千回のAPIコールが発生し、S3上のデータは暗号化、Webサイトは503エラーを返し始めました。
すべてのリソースが暗号化されているように見え、もしRDSが利用不能になれば、オンライン・実店舗を含むすべてのビジネスが停止します。
ランサムウェアの暗号化速度は非常に速く、数分で数十万オブジェクトを暗号化します。
S3のバージョニングを有効にしていても、すべてのバージョンが暗号化されます。
Scene 2：Assessment（影響評価）
米国東部時間午前8時30分。
今回の攻撃は、一般ユーザーアカウントの侵害が原因でした。すでに顧客の購買行動に影響が出始め、メディアも報道を開始。現時点での損失は1時間あたり数十万ドル。
要求された身代金は400万ドル、支払い期限は3日以内。
EC2：AWS Backupから復旧可能
S3：バージョニングを含め、すべて暗号化
Key Takeaways
- 攻撃は人とプロセスの失敗を突く
- VersioningはBackupではない
- 今日の侵害は、昨日削減されたセキュリティ予算の結果
クラウド侵害の初期侵入経路の約35%は正規アカウントの悪用
ハッカーは「侵入」するのではなく、「ログイン」している
また、仮に複数バージョンから復旧できたとしても、どの時点まで巻き戻すべきか分からないという問題が残ります。
Scene 3：Failed Recovery（復旧失敗）
これまで試みたすべての復旧策は失敗。
バックアップから新しいシステムを再構築しても、再び暗号化されます。
株価は下落を始め、攻撃者から新たなメールが届きます。バックアップからの復旧失敗を確認したため、身代金は600万ドルに引き上げる
Scene 4：Sensitive Data（機微情報）
事件発生から40時間以上が経過。
経営層は、S3からどの情報が漏洩したのかを強く気にしています。
法的観点では、PII（個人識別情報）の漏洩が確認された瞬間に、重大な規制・法的インシデントとなります。
A PII data breach changes everything.
Final Scene：最終判断
システムをゼロから再構築するには3週間。
PII漏洩という状況下では、結局翌年度の予算から身代金を支払うという判断に至ります。
経営層は「二度と起こさない」と断言しますが、
統計によると ランサムウェア被害の 80%は6か月以内に再発すると言われています。
学んだ教训と実践的対策
▪️ランサムウェアは「技術」より「人と運用」を狙う
- IAM 最小権限の定期レビュー
- IAM User から Role + MFA への移行
- 異動・退職時の権限棚卸し
▪️VersioningはBackupではない
▪️S3 Object Lock（WORM）の活用
▪️別アカウント・別リージョンへのバックアップ
▪️バックアップアカウントのアクセス経路分離