Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ランサムウエア対策してますか?やられた時の対策は本当にできてますか?AWSでのリスク分析と対応...

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers.

 ランサムウエア対策してますか?やられた時の対策は本当にできてますか?AWSでのリスク分析と対応フローの泥臭いお話。

昨今話題のランサムウエア被害。本番環境を外部に公開している以上は他人ごとではありません。
AWSは責任共有モデルであり、ランサムウエア被害にあえば、その責任は企業側にあります。
入口対策、出口対策をしただけで満足していませんか?
AWS独特のリスクとはなにか?リスクに関する備えはなにをすべきか?いざやられたときの対応はどうすべきか?
実際はAWSのサービスだけでは防御もできなければ、実際に被害にあったときの対策もできません。
被害にどう向き合い、解決できるかは日頃のAWSインフラエンジニアの準備にかかっているといっても過言ではないです。
今回は、実際にランサムウエア被害にあった際、どう対応するかを時間軸で整理し、必要な対応策をお伝えできればと思います。

Avatar for ひろのぶ

ひろのぶ

March 07, 2026
Tweet

Other Decks in Technology

Transcript

  1. #jawsug #jawsdays2026 #jawsdays2026_x 名前:大瀧広宣(おおたきひろのぶ) 自己紹介 2 経歴: IT業界歴30年以上、時代のトレンドに沿ったカテゴリーを選んで転職。 • ソフトウェアエンジニアとして、JavaやHTMLの創成期にWebシステム構築に従事。

    • ネットワークエンジニアとして、R&D、自社ネットワークアプリ開発に従事。 • 大手中古車情報サイト運営企業でAWS事業責任者を務め、データセンターのAWS延伸を実現。 • クラウド会計のフリーでCIO補佐を務め、コロナ禍による情シスのクラウド化、モダン情シス化を実現。 • AWSプレミアティアパートナーのサーバーワークスで急成長顧客を担当するPM兼マネージャーを務める。 • 大手ブランド買取企業でAWSのセキュリティ対策PM(DLP対策、個人情報保護)を務める。 • 株式会社SHIFTにて、AWSセキュリティコンサルタント、CCoE推進リーダー、初代AWSアンバサダーを務める。 • 現在はAmazonWebServiceのプロフェッショナルサービスでセキュリティコンサルやってます(新米アマゾニアン)
  2. #jawsug #jawsdays2026 #jawsdays2026_x ランサムウエア対策してますか? やられた時の対策は本当にできてますか? AWSでのリスク分析と対応フローの泥臭いお話 3 • はじめに(お話すること、お話しないこと) •

    ランサムウエアとは • 直接原因はAWS側だけでは対策できない • 実際はいろいろなケースが想定される • AWSでできること、できないこと • AWSセキュリティ対策の基本 • 実際にやられるとなにがおこるのか? • ほとんどの企業ではセキュリティの神様的エンジニアは存在しない • 止血ベンダーがいないとどうなるか? • 止血と復旧は両軸で進める体制を整備する • 復元先はどこなのか? • まとめ Agneda
  3. #jawsug #jawsdays2026 #jawsdays2026_x はじめに • お話しすること • 実際のコンサル経験からランサムウエアに対するAWS対 策の考え方の一例お話します。 •

    お話しないこと • 登壇時間の関係上、資料上の細かい設定の説明、ランサムウ エアの具体的な攻撃手法の詳細はお話できません。 セキュリティ全般そうですが、これをやれば完璧は存在しないです。 皆様のAWS環境におけるランサムウエア対策の考え方の参考になればうれしいです。 4 ランサムウエア対策してますか? やられた時の対策は本当にできてますか?AWS でのリスク分析と対応フローの泥臭いお話
  4. #jawsug #jawsdays2026 #jawsdays2026_x ランサムウエア対策してますか? やられた時の対策は本当にできてますか?AWS でのリスク分析と対応フローの泥臭いお話 直接原因はAWS側だけでは対策できない • ランサムウェア攻撃の8割がVPN・リモートデスクトップ経由 •

    警察庁 サイバー警察局が2025年9月に発表した「令和7年上半期におけるサイバー空間 をめぐる脅威の情勢等について」 • 被害に至る感染経路の約8割がVPN機器やリモートデスクトップを経由したもの • VPN機器の脆弱性の放置、VPN機器およびリモートデスクトップに設定され た推測可能なIDやパスワードの使用などが原因。 • 想定される主なケース •PCのシステム管理者パスワードの共通化(使い回し) •VPN機器、PCの脆弱性の放置 •一般ユーザーへの管理者権限の付与(過剰な権限付与) 出典:令和7年上半期におけるサイバー空間をめぐる脅威の情勢等について 対策はAWS環境の管理者だけでは完結できない 6
  5. #jawsug #jawsdays2026 #jawsdays2026_x ランサムウエア対策してますか? やられた時の対策は本当にできてますか?AWS でのリスク分析と対応フローの泥臭いお話 実際はいろいろなパターンが想定される パターン1:S3データの人質化 • 侵入経路

    • 開発者がGitHub等に誤って公開したアクセスキー(AK/SK)や、マルウェア感染したPCから漏洩 した認証情報。 • 攻撃手法 • 攻撃者が漏洩したキーを使ってCLIからAWS環境へアクセス。 • S3バケット内のデータを全てダウンロード(窃取)。 • データを攻撃者しか復号できない鍵(SSE-Cなど)」で暗号化して上書きする • 被害範囲 • 攻撃されたAWSアカウント内のデータ消失・漏洩。 AWS環境に対するランサムウェア攻撃ってそもそもどういう状況か? 7
  6. #jawsug #jawsdays2026 #jawsdays2026_x ランサムウエア対策してますか? やられた時の対策は本当にできてますか?AWS でのリスク分析と対応フローの泥臭いお話 実際はいろいろなパターンが想定される パターン2:踏み台からの横断的侵害 • 侵入経路

    • 脆弱性があるサーバーや比較的セキュリティ要件の低い「開発用アカウント」や、共通機能を持つ 「共有サービスアカウント」への侵入。 • 攻撃手法 • 脆弱性を利用しEC2やIAMユーザーを乗っ取る。 • そのリソースに付与されている「他アカウントへのスイッチロール(AssumeRole)権限を悪用する。 • 乗っ取った権限を利用し、他サーバー、他環境へ移動し、サーバーやDBを暗号化する。 • 被害範囲: • システム全体への感染拡大 • SSRF(=Server Side Request Forgery)的、横展開攻撃 9
  7. #jawsug #jawsdays2026 #jawsdays2026_x ランサムウエア対策してますか? やられた時の対策は本当にできてますか?AWS でのリスク分析と対応フローの泥臭いお話 10 • 一番怖いのはSSRF •

    SSRF(=Server Side Request Forgery)は、例えばクラウド上にある外部に公開されているサーバから、内部 のサーバに送られるリクエストを偽造し、本来公開されてないサーバにアクセスするという手法。 Virtual private cloud (VPC) Public subnet Private subnet 脆弱性放置の サーバー (Amazon EC2) 個人情報が入っ てるサーバー (Amazon EC2) IMDSv1.0でサーバー情報取 得 クレデンシャル入手 悪意のある ユーザー 脆弱性をついて 不正アクセス、 情報搾取 強力なRole どこでもいけるルートがある 実際はいろいろなパターンが想定される 搾取、侵害、漏洩
  8. #jawsug #jawsdays2026 #jawsdays2026_x ランサムウエア対策してますか? やられた時の対策は本当にできてますか?AWS でのリスク分析と対応フローの泥臭いお話 <入口対策(どちらかというと情シスの仕事)> フィッシング対策 • 開発者のPCがマルウェアに感染し、AWSのアクセスキーや接続情報が盗まれるケース

    (一番怖いケース) • メールから不正なリンクを踏んで、そこから不正アクセスツールを入れられる、または不正サイ トでID、パスワードを窃取される • AWSからは正規のユーザーの処理に見えてしまう • 情シス対応で、PCにウイルスソフトを入れる • 情シス担当者とのコミュニケーションは欠かせない時代となっている ◼ 入口対策、出口対策を分けて考えましょう。 ランサムウエア対策の深堀①
  9. #jawsug #jawsdays2026 #jawsdays2026_x ランサムウエア対策してますか? やられた時の対策は本当にできてますか?AWS でのリスク分析と対応フローの泥臭いお話 ランサムウエア対策の深堀② <出口対策(こちらはAWSでできることが多い)> 実はランサムウェア対策に特化したものではなく、AWSセキュリティのベストプラクティスに沿えば実現できます。 ①バックアップ、復旧対策

    対象はDB、S3、EBS、EC2をしっかりバックアップ ②アクセスキーの漏洩対策 Guard Duty、トラステッドアドバイザーで漏洩を検知する ③操作履歴はCloudTrailで追う習慣をつける、日頃から見る ④被害範囲の最小化対策を行う ネットワークセグメント分けして、アクセスできる範囲を絞る ⑤脆弱性があって改善困難なサーバーの権限を絞る 踏み台になったときの動きを最小にするため攻撃者の移動範囲を狭くする ⑥不正アクセスの検知 Amazon Guard Dutyのアラートは必ず定期的に分析する
  10. #jawsug #jawsdays2026 #jawsdays2026_x ランサムウエア対策してますか? やられた時の対策は本当にできてますか?AWS でのリスク分析と対応フローの泥臭いお話 AWSネイティブサービスセキュリティ構成例 ワークロード環境 log Archive

    (証跡) Audit (監査) Amazon Detective AWS WAF AWS Security Hub AWS Shield Amazon GuardDuty Amazon Inspector AWS Trusted Advisor AWS CloudTrail AWS Config 可視化 多層防御 AWS Config AWS CloudTrail Amazon S3 インターネットアクセス Amazon Cognito 認証 1 2 3 4 6 5 CloudWatch※ 7 API-GW AWS Security Hub インシデント集約 ログ集約 8 10 9
  11. #jawsug #jawsdays2026 #jawsdays2026_x ランサムウエア対策してますか? やられた時の対策は本当にできてますか?AWS でのリスク分析と対応フローの泥臭いお話 AWSにおける脅威対策マップ 項番 脅威内容 対策

    番号(構成図) 1 OSSの脆弱性 Amazon Inspector ⑧ 2 ランサムウェア AWS-Backupのコンプライアンスモードによるバック アップ保護 3 SQLインジェクション、XSS、 DDoS、ブルートフォースなど OWASP Top 10に該当する攻撃 AWS Shield、AWS WAF+マネージドルールセット ⑨+④ 4 AWS設定ミス、アクセスキー漏洩 AWS Config、CloudTrail、TrusedAdvisor (有償オプションのセキュリティ設定) ②+①+⑩ 5 仮想通貨マイニング AWS Budgetsによるリソース課金監視 6 マルウェア、その他の未知の脅威 Amazon GuardDuty (ランタイムモニタリング、S3プロテクション、S3マ ルウェアスキャン) ⑥ ◼ AWSにおけるセキュリティサービスは、カバーする脅威対策を想定し実装を行います。 ◼ 以下1,3,4,6についてはインシデントを統合し、インシデントレベルの高いものから対策を行うのが基本です。
  12. #jawsug #jawsdays2026 #jawsdays2026_x ランサムウエア対策してますか? やられた時の対策は本当にできてますか?AWS でのリスク分析と対応フローの泥臭いお話 AWSにおける最低限のセキュリティ ◼ AWSにおけるセキュリティ設定は最低限以下を推奨します。 ◼

    こちらの内容はAWSのプレミアパートナー企業であれば最低限実施されている項目となり、AWS マネージド サービスプロバイダー (MSP) プログラム MSP 検証チェックリストでも定義されているものです。 出典:https://partners.awscloud.com/GLOBAL-homekey-IND-Managed-Service-Provider-Program-2025-interest.html
  13. #jawsug #jawsdays2026 #jawsdays2026_x ランサムウエア対策してますか? やられた時の対策は本当にできてますか?AWS でのリスク分析と対応フローの泥臭いお話 有事の際に備え、ログはしっかり残そう 項番 ログ内容 対応サービス

    番号(構成図) 1 AWS APIのCallの履歴(いつ、誰が、何をしたか) AWS CloudTrail ① 2 AWS設定変更操作ログ AWS Config ② 3 公開APIのユーザー認証ログ AWS Cognito ③ 4 L7レベルの不正アタックログ AWS WAF ④ 5 公開APIへのアクセスログ API-GW ⑤ 6 AWS環境への不正アクセスの検知ログ Amazon GuardDuty ⑥ 7 各種アプリケーションの動作ログ CloudWatch ⑦ ▪不正検知の際に、事象を追跡、影響範囲を特定するためにセキュリティログはしっかり残しましょう。 ▪ログの改ざんを防ぐため、ログ専用のAWSアカウントにログを集約しましょう。 ▪集約したログは1年間は即時参照可能な形式で保存し、1年経過後は3年間アーカイブ保存することを推奨しま す。企業がもつ情報セキュリティポリシーに合わせた形で決定することが好ましいです。
  14. #jawsug #jawsdays2026 #jawsdays2026_x ランサムウエア対策してますか? やられた時の対策は本当にできてますか?AWS でのリスク分析と対応フローの泥臭いお話 ほとんどの企業ではセキュリティの神様 的エンジニアは存在しない • ランサムウエア被害の原因究明は特殊な技術が必要

    • フォレンジック調査作業の実施 • 状態の保全のため、フォレンジックツールでインスタンス等をミラーリングし分析する手法 • 各種ログの回収 • 原因特定(侵入経路の特定、影響範囲の特定)のため必要なログを収集し分析する。 • これらの技術は通常のAWS運用管理者、開発者だけでは事実上不可能 • 社内ネットワーク管理者(情シス)との連携も必要 • いざというときのフォレンジック業者(止血ベンダー)を決めて、連携体制をとること は必須 • 止血の手順方法の確立、調査に必要なログの確認(不足しているものはないか) • 業者との連携手順、情シスとの連携手順を含めた避難訓練(★)も必須 ★避難訓練とは、有事の際を想定し外部通信の遮断や、インフラ環境の復元、作業分担、作業フローを 定義しシュミレーションすることです。 20
  15. #jawsug #jawsdays2026 #jawsdays2026_x ランサムウエア対策してますか? やられた時の対策は本当にできてますか?AWS でのリスク分析と対応フローの泥臭いお話 Days-0 脆弱性を突 かれ開発者 PC乗っ取

    り等で認証 情報が漏洩 Days-1 外部通信遮 断し環境を 閉鎖 被害状況を 確認 漏洩した認証情報で重要データの人質化→対象業務の停止 Days2-7 止血ベンダー選定( 費用交渉、社内予算確保、 納期交渉、被害状況のす り合わせ、対応手順のブ リーフィングを実施) Days8-14 止血ベンダーと被害環 境の保全作業実施(対 象箇所のフォレンジッ ク取得)調査に必要な ログの提供 Days15-30 止血ベンダーによる調査 で運がよければ全容が判 明する(侵入経路、被害 範囲の特定、今後の対策 方針) 顧客やメディアへの報告 対応、業務復旧作業の開 始がやっと始まる。。 初動対応から遅れから、業務復旧が長引き被害が増大、焦りから2次被害を引き起こす可能性もある 大抵の場合、AWSの運用責任者がその重圧を担うことになるケースが多い。 ※注:おおよその目安です。実際は被害規模によってはもっと長くなると想定しています 止血のベンダーがいないとどうなる? 21
  16. #jawsug #jawsdays2026 #jawsdays2026_x ランサムウエア対策してますか? やられた時の対策は本当にできてますか?AWS でのリスク分析と対応フローの泥臭いお話 • 原因究明と環境の復元は同時進行させる方法も検討してみる • ※注:期間、対応内容はおおよその目安です。被害規模、システム規模によって実際は異なります

    • 業務復旧が早期にできることで、経営面でもダメージを最小限にすることができる 止血と復旧は両軸ですすめる体制を整備する 外部通信遮断 別環境での インフラ環 境復元 バック アップ データ 復元 フォレンジック対応 業者による原因調査 Xday(事象発覚日) Xday+1week 新環境での早期 業務開始 業務 復旧 原因究明 業者への通信ロ グ、侵害インス タンスの提供 対策のフォロー バック実施 止血(インバ ウンド、アウ トバウンド通 信遮断 影響範囲の特定と原因報告 Xday+2week 機能 確認 Xday+3week メディア対応、 お客様への報告 作業など 業者との連携作 業(不足ログの 抽出&QA) 原因に基づくセキュリ ティ強化対策策定 ★クラウド利用のメリットである“アジリティ”を最大限に利用する セキュリティ強化 対策を実施 Xday+4week 22
  17. #jawsug #jawsdays2026 #jawsdays2026_x ランサムウエア対策してますか? やられた時の対策は本当にできてますか?AWS でのリスク分析と対応フローの泥臭いお話 ケース2:新規にAWSアカウントを用意し復元するパターン ★漏洩した可能性のある部分が完全に切り離されるため、2次被害が防止できる。 • 隔離された環境を事前に用意しておく

    • ネットワーク、AWSアカウント( AWS Organizationsごと分離)、認証情報、AWS環境に接続する PCも分離する • AWSアカウントとVPC、必要なデータのバックアップ程度であれば、維持費用もさほどかから ない • インフラのコード化は必須 • コンプライアンスモードでBackUpしたデータをしっかり定期的に保存 • リアルタイムはむずかしいので、ある程度古いデータからの復元は制約としてある • 日頃からの避難訓練は必須(インフラコードでの環境復元とデータの復元方法確認) • 但し、このやり方でもGitHub等のリポジトリからアクセスキーが漏れた場合は、アクセス キーの無効化と変更作業が必要。 • 原因究明と環境の復元は同時進行させる • 業務復旧が早期にできることで、経営面でも、現場のエンジニアの精神的な負荷面でもダメージを 最小限にすることができる 復元先はどこなのか? 24
  18. #jawsug #jawsdays2026 #jawsdays2026_x ランサムウエア対策してますか? やられた時の対策は本当にできてますか?AWS でのリスク分析と対応フローの泥臭いお話 まとめ • 有事に備える •

    原因究明に必要なログを確りとる • システム復旧に必要なデータはしっかりバックアップ(コンプライアンスモード推奨) • インフラはコード化し、いつでも復元可能な状態にする • いざというときの環境を、完全分離で用意する(開発者PC、ネットワーク分離、AWSアカウ ント分離) • フォレンジックのパートナーを確り確保 • 連携して業務復旧するフローの確立、避難訓練の実施 • 入口対策にも気を配る • AWS環境は商用インフラ、社内環境は情シスと組織が分離しているパターンがほとんど • いざというときの連携は必須なので、定期的なセキュリティ対策の情報交換は忘れず 26