ガバメントクラウドでのランサムウェア対策

2026/07/31 JAWSUG名古屋/Gov-JAWS#8登壇資料です。

Transcript

1. ガバメントクラウドでのランサムウェア対策 2026/07/31 JAWS UG 名古屋 × Gov JAWSコラボ
2. Profile 名古屋市総務局デジタル改革推進課 課長補佐（システム標準化担当） 高橋 広和 ◆ 1998年 名古屋市入庁 区役所市民課 住基・戸籍・印鑑業務従事 ◆ ２００２年 健康福祉局医療福祉課 ホスト分散化対応、後期高齢者医療システム開発 ◆ 2009年 健康福祉局総務課 福祉総合情報システム保守運用 ◆ 2012年 愛知県後期高齢者医療広域連合 マイナンバー制度導入対応 ◆ 2017年 健康福祉局保険年金課 保険年金システム保守運用 ◆ 2022年 現職（2024年より課長補佐） ◆ ２０２４年 デジタル改革共創ＰＦアンバサダー就任 担当業務：ガバメントクラウドCoE 趣味：読書・ゲーム X 所属グループ：JAWS-UG名古屋/Gov-JAWS Note：https://note.com/techniczna/ 好きなAWSサービス：AWS Cost Explorer Qiita：https://qiita.com/Seria_GovCloud ：https://twitter.com/Seria_GovCloud 2
3. 本日は、ガバメントクラウド環境における ランサムウェア対策についてお話しします。
4. 今回「GCASアップデート情報」はお休みです。 資料自体はありますので、以下を参照ください。 https://speakerdeck.com/techniczna/gcasatupudeto-202605-202607
5. 近年の国内大手企業ランサムウェア被害状況 • 飲料・ビール系会社（2025年9月） ➢ グループ拠点のネットワーク機器経由で侵入され、複数サーバーや一部PCが暗号化 ➢ 約191万件の個人情報等の漏えいのおそれ ➢ システム復旧は12月初旬であり２か月以上停止、業務や物流への多大な影響が生じた • 事務用品通販会社（2025年10月） ➢ 6月に業務委託先のアカウントを用いてシステム侵入され、物流・社内システムに感染拡大し、10 月にランサムウェア起動 ➢ 約72万件の顧客情報を含む業務情報流出、約2か月間の業務停止 ➢ AI-DLCの活用により、被害前以上の価値創造を実現 • 冷凍食品会社（2026年7月） ➢ 7月13日に大規模な障害を検知、緊急措置としてグループ全体のネットワークを遮断 ➢ 一時的に物流機能が停止し、多くのサプライチェーン被害が発生 ➢ 確保していたイミュータブル/オフラインバックアップからシステムを復旧し、10日後に業務再開
6. 国のガイドライン・基準等における位置づけ • 地方公共団体における情報セキュリティポリシーに関するガイドライン(令和8年３月版) ➢ ランサムウェアに感染した端末等からアクセスできる領域にある場合、バックアップを含め暗号化 されてしまう可能性があるため、端末のOSからアクセスできないネットワークから切り離されたオ フラインのディスクや媒体等へ保管することも検討が必要となる。 • 地方公共団体情報システム非機能要件の標準【第1.2版】 ➢ A.3.2.2【注意事項】近年のランサムウェアによるセキュリティインシデントが多発していることに 鑑みると、リモートバックアップに加えて媒体による外部保管（バックアップ）を取得することも考え られる。 • ガバメントクラウド（AWS）における評価 ➢ ガバメントクラウド環境はベースラインセキュリティやユーザー管理面で外部からの攻撃にかなり 堅牢ではあるが、内部犯に対しては堅牢とは言えない。 ➢ より進化した攻撃パターンやオペレーションミスによるデータ喪失も考慮しておく必要がある。 義務規定では無いものの対策することが望ましい
7. 対策は、①多層防御＋②イミュータブルバックアップ
8. 対策は、①多層防御＋②イミュータブルバックアップ
9. ガバメントクラウドにおける多層防御 検討事項 対策内容と関係サービス ガバメントクラウドでの対応 ユーザー側での対応 アカウント境界 Organizations、Control Tower ユーザーと認証 長期クレデンシャルの排除、IAMユー ベースラインで対応済 ザー廃止とIdP連携、MFA強制 適切なIAMロール設計、管理者権限 を乱用しない リソース管理 IaC、タグ付け、Config 適切なリソース管理設計 管理コンソール 制御 接続元制限、端末制御、条件付きアク ベースラインで対応済 セス 適切な端末管理 脆弱性管理 Inspector、Security Hub、 Systems Manager Patch Manager、サーバレス モダン化の推奨、Security Hub CSPM有効化 Inspectorの有効化、OSへのパッチ 適用、Security Hub CSPM指摘事 項の対応 検知 GuardDuty（保護プラン含む） GuardDuty有効化 （基本＋一部の保護プラン） GuardDutyの他の保護プランの有 効化 環境種別に応じたアカウントの払い出 適切なアカウント分離設計 し Config有効化
10. Security Hub CSPM（Cloud Security Posture Management） • セキュリティ基準に基づき、リスクを評価し可視化してくれるサービス • 2026年6月の自動適用テンプレート更新で最新バージョンに対応 ➢ CIS AWS Foundations Benchmark v1.2.0 → v5.0.0 へ • 必要な対応事項 ➢ 適用されるセキュリティ基準が変更されるため、セキュリティスコアやコントロールステータスが更新される ➢ 不合格のうち、重大度がCriticalやHighのものはなるべく早めに対処を
11. Amazon GuardDuty保護プラン • GuardDuty保護プランは、保険の追加特約のようにGuardDutyのサポート範囲を拡張してくれる オプション機能 • ガバメントクラウドにおいて、GuardDutyの基本機能と一部の保護プランは有効化されているが、残 りの保護プランについては対処が必要 保護プラン 有効化の方法 機能 S3 Protection ディフォルトで有効化 S3 のAPIログを監査（ふるまい検知） EKS Protection ディフォルトで有効化 Kubernetes APIを監査（ふるまい検知） ランタイムモニタリング Malware Protection（EC2） 対象クラスタに「キー:GuardDutyManaged, Pod / コンテナ全体を監査（ふるまい検知） 値:true」のタグを付与 対象インスタンスに「キー:GuardDuty, 値:true」の GuardDutyで特定のふるまいを検知した際、EC2をスキャン（スキャン） タグを付与 Malware Protection（AWS Backup） 各アカウントにて有効化する AWS Backup 増分データをスキャン（スキャン） Malware Protection（S３） 各アカウントにて有効化する S3バケットの新規オブジェクトをスキャン（スキャン） RDS Protection ディフォルトで有効化 RDSログインイベントを監査（ふるまい検知） Lambda Protection ディフォルトで有効化 Lambdaのネットワーク関連ログを監査（ふるまい検知） ※ GCASヘルプデスクFAQ「「Amazon GuardDuty」の保護プランを利用することはできますか」参照
12. 対策は、①多層防御＋②イミュータブルバックアップ
13. ガバメントクラウド利用イメージ Management Console Tokyo Region 庁内LAN Direct Connect Osaka Region 運用管理アカウン ト 本番環境アカウント Transit Gateway VPC DXGW Attachment EC2 RDS 災対用バックアップ S3 AWS Backup Backup vault • オンプレミス環境と専用線及びDirect ConnectとでAWS環境と接続し、庁内ネットワークと同一のネットワーク空間としている • 東京リージョンをメインサイト、大阪リージョンをバックアップ＆DRサイトとしている • AWS Backupを利用せず、クロスリージョンレプリケーションで大阪リージョンのS3にスナップショット等を保管するケースもある 13
14. 想定するランサムウェア感染シナリオ Management Console 認証の突破 内部犯行 Osaka Region 潜伏期間中に災対用 Tokyo Region 庁内LAN Direct Connect 運用管理アカウン ト 本番環境アカウント Transit Gateway VPC DXGW Attachment EC2 RDS バックアップが汚染 あるいは破壊 S3 AWS Backup Backup vault 庁内経由の感染 内部犯行 • 庁内感染PC経由、管理コンソールの認証突破、内部犯行等の要因で感染し、GuardDutyの発報に気付かないまたは 発報内容の確認中のタイミングに暗号化が実施されてしまう状況を想定する 14
15. イミュータブルバックアップ導入のポイント 1. バックアップ保管専用の金庫アカウントを開設し、アカウントを要塞化する 2. 本番環境アカウントから金庫アカウントにデータの変更・削除ができないバックアップ（イ ミュータブルバックアップ）を保存する 3. 用いるKMSキーについて整理する（場合によっては現状の変更を行う） 4. 適切なバックアッププランを検討する 5. 復旧時の手順やルールについて整備する
16. ランサムウェア対策のイメージ① Management Console Tokyo Region 庁内LAN Direct Connect Osaka Region 運用管理アカウン ト 本番環境アカウント Transit Gateway VPC DXGW Attachment EC2 災対用バックアップ RDS S3 AWS Backup 金庫アカウント 平常時はアクセスで きず、削除も上書き もできない 16 Backup vault AWS Backup LAG vault
17. ランサムウェア対策のイメージ② Management Console Tokyo Region 庁内LAN Direct Connect Osaka Region 運用管理アカウン ト 本番環境アカウント Transit Gateway VPC DXGW Attachment EC2 RDS S3 AWS Backup 金庫アカウント ランサムウェア感染以前の状態にリカバ リーできるバックアッププランとする 17 Backup vault AWS Backup LAG vault
18. イミュータブルバックアップ導入のポイント 1. バックアップ保管専用の金庫アカウントを開設し、アカウントを要塞化する 2. 本番環境アカウントから金庫アカウントにデータの変更・削除ができないバックアップ（イ ミュータブルバックアップ）を保存する 3. 用いるKMSキーについて整理する（場合によっては現状の変更を行う） 4. 適切なバックアッププランを検討する 5. 復旧時の手順やルールについて整備する
19. 金庫アカウントの要塞化 • 本番環境相当のデータバンカーアカウント（金庫アカウント）を新規に払い出す ➢ 既存アカウントの流用は行わない • 金庫アカウントに登録するSSOユーザーを限定する • 管理者ロール（AWSAdministratorAccess）は極力使用せず、なるべく運用に必要な最小権限の ロールを設計する ➢ 運用作業用ロールと復旧作業用ロールを分ける ➢ 構築完了後、GCASシステム管理にて管理者ユーザーを無くす • 不審なイベントを検知したら全て発報するようにしておく ➢ IAM関連操作（ロール引き受けは除く） ➢ Vault Policy 変更 ➢ RAM 共有変更 ➢ KMS Key 変更 ➢ Vault のリカバリー ➢ CloudTrail、 • 本番環境アカウントが為替固定の場合、金庫アカウントも為替固定を適用する必要がある
20. 為替固定プログラムの影響① • 為替固定プログラムとは、地方公共団体の希望により、年間の請求時為替レートを固定できる仕組み （ガバメントクラウドAWS特有） • 対象アカウントを為替変動（通常）のOrganizations から 為替固定のOrganizationsに移行させる ことにより実現 為替変動 Organizations 本番 アカウント 為替固定 Organizations 本番 アカウント
21. 為替固定プログラムの影響② • AWS Backupの仕様により、クロスアカウントでBackupを行う場合、２つのアカウントは同じ Organizationsに属していなければならない https://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/create-crossaccount-backup.html 為替変動 Organizations 為替固定 Organizations 金庫 アカウント 本番 アカウント • そのため、本番アカウントが為替固定の場合には、金庫アカウントも為替固定にしておく必要がある 為替固定 Organizations 金庫 アカウント 本番 アカウント
22. イミュータブルバックアップ導入のポイント 1. バックアップ保管専用の金庫アカウントを開設し、アカウントを要塞化する 2. 本番環境アカウントから金庫アカウントにデータの変更・削除ができないバックアップ（イ ミュータブルバックアップ）を保存する 3. 用いるKMSキーについて整理する（場合によっては現状の変更を行う） 4. 適切なバックアッププランを検討する 5. 復旧時の手順やルールについて整備する
23. ２つのイミュータブルバックアップ① 観点 Vault Lock LAG Vault バックアップ削除耐性 Compliance modeなら非常に強い Compliance modeを標準装備。同等に強い KMS依存 コピー元のKMSキー・キーポリシーへの依存が大き い AWS所有キーを選択可能 復旧手順 復旧ポイントを金庫アカウントから復旧先アカウント にコピー後、復旧先アカウントで復元 RAM共有された復旧先アカウントから直接復元可能 復旧時のRTO コピー時間等が加算される 事前共有により短縮しやすい 対応リソース AWS Backup対応範囲が比較的広い 対応リソース・暗号化方式に制限あり 為替固定の影響 全てのアカウントの為替固定ルールは同じでなけれ ばならない 金庫アカウントと復旧先アカウントの為替固定ルール は異なっても良い ユースケース 誤削除防止、コンプライアンス対応 ランサムウェア対策
24. ２つのイミュータブルバックアップ② • Vault Lockを含む通常のBackup Vaultは、異なるアカウントに直接復元はできず、復元 先アカウントにコピーしてから復元する必要がある ➢ この場合も同じOrganizationsに属していなければならないため、復元先アカウントの為替固定 適用を先にやらなければならない場合がある 為替固定 Organizations 金庫 アカウント ② 復旧先 アカウント ③ ① 為替変動 Organizations 復旧先 アカウント
25. ２つのイミュータブルバックアップ③ • LAG Vault（Logically air-gapped vault） の場合は、VaultをRAM共有することで復 旧先アカウントに直接復元できる ➢ この際、同じOrganizationsの制約がないため、為替固定は考慮しなくてよい 為替固定 Organizations ① 復旧先 アカウント 為替変動 Organizations 金庫 アカウント • Vault Lockの場合、暗号化方式がCMKになる場合があり、キー破壊等による復元不可の リスクがある（後述） ランサムウェア対策においては、RTOやオペレーション等の面で LAG Vault の利用が適している
26. イミュータブルバックアップ導入のポイント 1. バックアップ保管専用の金庫アカウントを開設し、アカウントを要塞化する 2. 本番環境アカウントから金庫アカウントにデータの変更・削除ができないバックアップ（イ ミュータブルバックアップ）を保存する 3. 用いるKMSキーについて整理する（場合によっては現状の変更を行う） 4. 適切なバックアッププランを検討する 5. 復旧時の手順やルールについて整備する
27. AWS BackupにおけるKMSキー暗号化の仕様① （独立した暗号化の可否） • AWS Backup が Full management をサポートするリソースか否かで挙動が異なる https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-featureavailability.html#features-by-resource • Full management 対応リソースの場合、「独立した暗号化」が可能 独立した暗号化が可能なリソース 独立した暗号化が不可能なリソース S3 Amazon Aurora DSQL Amazon EFS DynamoDB（高度バックアップあり） Amazon EKS Amazon EC2 Amazon EBS Amazon RDS / Aurora FSx AWS Storage Gateway DynamoDB（高度バックアップ無し）
28. AWS BackupにおけるKMSキー暗号化の仕様② （Primary Vault） • 「独立した暗号化」が可能な場合、元々のリソースの暗号化方式に関わらず、AWS Backupで指定した 暗号化方式が採用される • 「独立した暗号化」が出来ない場合、元々のリソースの暗号化方式が採用される https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html 独立した暗号化が可能なリソース SSE-S3 S3 aws/backup AWS Backup Backup vault Vaultで aws/backup を指定 独立した暗号化が不可能なリソース aws/rds RDS aws/rds AWS Backup Backup vault Vaultで aws/backup を指定
29. AWS BackupにおけるKMSキー暗号化の仕様③ （リージョン間コピー） • 復旧ポイントを同一アカウントの別リージョンのVaultにコピーする場合、コピー先のVaultで指定さ れている暗号化方式が採用される • 即ち、カスタマーマネージドキー（CMK）またはAWS BackUp管理キー（aws/backup） https://docs.aws.amazon.com/ja_jp/awsbackup/latest/devguide/encryption.html#copy-encryption • ただし「独立した暗号化」に対応していないリソースの場合、コピー先でAWS BackUp管理キー （aws/backup）を指定しても利用できないため、元々のリソースの暗号化方式で暗号化される ➢ カスタマーマネージドキー（CMK）は利用可能 独立した暗号化が不可能なリソースのリージョン間コピー Osaka Region Tokyo Region aws/rds aws/rds Backup vault AWS Backup Backup vault CMK
30. AWS BackupにおけるKMSキー暗号化の仕様④ （クロスアカウントコピー） • コピー元がAWS管理キー（aws/rds、aws/backup など）で暗号化されている場合、キーポリシーの 変更ができないため、クロスアカウントのコピーができない https://docs.aws.amazon.com/ja_jp/awsbackup/latest/devguide/encryption.html#copy-encryption • 回避策としては、コピー元VaultをCMKに変更するか、同一アカウントでCMKの中間Vaultにクロス リージョンコピーしてから、クロスアカウントコピーを実施する https://aws.amazon.com/jp/blogs/storage/protecting-encrypted-amazon-rdsinstances-with-cross-account-and-cross-region-backups/ • LAG VaultはディフォルトでAWS所有キーで暗号化されるが、コピー元AWS管理キー不可の制約は 残る https://docs.aws.amazon.com/awsbackup/latest/devguide/logicallyairgappedvault.html#lag-creation
31. 独立した暗号化が不可能なリソースの対応イメージ Tokyo Region aws/rds Osaka Region aws/rds CMK 現行がaws/rdsなら 変更の必要あり 本番環境アカウント VPC RDS Backup vault AWS Backup 金庫アカウント Backup vault AWS Backup AWS owned key LAG vault 31
32. イミュータブルバックアップ導入のポイント 1. バックアップ保管専用の金庫アカウントを開設し、アカウントを要塞化する 2. 本番環境アカウントから金庫アカウントにデータの変更・削除ができないバックアップ（イ ミュータブルバックアップ）を保存する 3. 用いるKMSキーについて整理する（場合によっては現状の変更を行う） 4. 適切なバックアッププランを検討する 5. 復旧時の手順やルールについて整備する
33. バックアッププランの検討① • 近年、ランサムウェアの侵入から暗号化までの時間（dwell time）は検知や対策を嫌って短 期化傾向にある ➢ Palo Alto Networks Unit 42 グローバルIRレポート 2025では7日間 ◼ https://www.paloaltonetworks.com/resources/research/2025-incident-response-report ➢ トレンドマイクロ社ブログでは平均6.47日、28.6％のケースで24時間以内 ◼ https://www.trendmicro.com/ja_jp/jp-security/23/l/securitytrend-20231211-03.html ランサムウェア事例における初期侵入からランサムウェア実行までの期間 トレンドマイクロ社ブログより引用
34. バックアッププランの検討② • また、実際にランサムウェアが暗号化を実施するタイミングは、監視やインシデント対応が手 薄な休日夜間のタイミングに集中している ➢ Google / Mandiant「They Come in the Night」 では76%が業務時間外（49％が平日夜 間、27%が週末） ◼ https://cloud.google.com/blog/topics/threat-intelligence/they-come-in-the-nightransomware-deployment-trends ➢ Semperisのレポートでは86%が週末祭日 ◼ https://www.semperis.com/resources/2024-ransomware-holiday-risk-report/ ➢ Packetlabsのブログでは43%が金曜または土曜 ◼ https://www.packetlabs.net/posts/what-is-attack-dwell-time/ ➢ ESETのブログでは「ランサムウェア攻撃は祝日や週末に30%増加」 ◼ https://www.packetlabs.net/posts/what-is-attack-dwell-time/
35. バックアッププランの検討③ • 例えば、週次２世代、保持期間2週間とする • またターゲットはオリジンデータの毎週最初の平日取得分とする • 潜伏期間が２週間を超えるランサムウェアには対応できないため、必要に応じてより期間の 長い世代を保持する必要がある • LAG vaultはその性質上、常にフルバックアップとなるため、コストに留意が必要
36. バックアッププランの例① 大規模災害対策として 毎日増分バックアップ 平日 増 分 増 分 増 分 土日 増 分 増分 土日 平日 増 分 増 分 増 分 増 分 増分 平日 増 分 増 分 増 分 土日 増 分 増分 本番アカウント LAG vault ランサムウェア策として 週次２世代を２週間保持 LAG vault LAG vault 金庫アカウント
37. バックアッププランの例② 土曜日に暗号化 平日 増 分 増 分 増 分 土日 増 分 増分 土日 平日 増 分 増 分 増 分 増 分 増分 平日 土日 発覚 本番アカウント LAG vault 水曜日に本番環境が感染し、同 日夜間にバックアップにも伝播 先々週月曜日時点の データで復旧 LAG vault こちらの世代は感染済の ため使えない 金庫アカウント
38. イミュータブルバックアップ導入のポイント 1. バックアップ保管専用の金庫アカウントを開設し、アカウントを要塞化する 2. 本番環境アカウントから金庫アカウントにデータの変更・削除ができないバックアップ（イ ミュータブルバックアップ）を保存する 3. 用いるKMSキーについて整理する（場合によっては現状の変更を行う） 4. 適切なバックアッププランを検討する 5. 復旧時の手順やルールについて整備する
39. 復旧にかかるポイント • 復旧開始判断の基準やフローを決めておく ➢ ガバクラのみならずオンプレミスも被害を受けている可能性がある ➢ 運用チームのみで判断せず、組織全体（CSIRT）の決定に従う • 復旧時の手順を確立する ➢ 基本的に復旧先は新規アカウントであり、バックアップ元の本番環境に戻すことは想定しない ➢ 新規復旧アカウントに対してLAG VaultをRAM共有する ➢ 以後は新規復旧アカウント側で作業を実施 • Organizations 管理アカウントが利用できないため、Multi-party approval は利用しない https://aws.amazon.com/jp/blogs/news/improve-recovery-resilience-with-aws-backupsupport-for-multi-party-approval/ • 定期的にリカバリー訓練を行う
40. 住民のデータをしっかりと守り、サイバー攻撃に強い 名古屋市を目指していきたいと思います ご清聴ありがとうございました！