こんにちは、中山（ @k1nakayama ) です。
皆さんの組織では、ランサムウェア対策にどこまで取り組まれていますか？昨今、ランサムウェアの被害が急激に増加しており、その手口も年々巧妙化しています。取引先や関連企業での被害報告を受けて、自社環境のセキュリティ対策を見直したいという声をいただくケースが増えてきました。
今回、Windows Server上で稼働する業務用Webサービスを提供しているお客様からの要望を受けて、ランサムウェア対策を徹底したAWSワークロードを構築しました。本記事では、その構成と設計意図を解説します。
ランサムウェア対策の3つの柱
ランサムウェアへの対策として、以下の3つの観点が重要とされています。
- 感染させない — 攻撃経路を遮断し、脆弱性を排除する
- 感染を拡大させない — 万一感染しても外部通信を制限し、被害の拡散を防ぐ
- ファイルやデータの復元が行える状態を保つ — バックアップと変更管理により、感染前の状態に戻せるようにする
今回構築した環境では、このそれぞれに対して徹底した対策を講じています。
アーキテクチャ全体像
まず、今回構築した環境のアーキテクチャ全体像です。
構成要素として、Route 53によるDNS、Internet Gateway、Network Firewall、ALB、Private SubnetのEC2（Windows Server）、RDS（SQL Server）を中心に、Security Hub / GuardDuty / Inspector によるセキュリティ監視、AWS Backupによるバックアップ、Systems Manager Patch Managerによるパッチ管理、EventBridge + Lambdaによる起動テンプレート自動更新を組み合わせています。
対策1: 感染させない
Private Subnetへの配置によるネットワーク分離
EC2インスタンスはPrivate Subnetに配置しています。インターネットとの直接的な接点を持たず、ALBからのヘルスチェック用およびWeb用のポートのみが外部からのリクエストを受け付ける構成です。この時点で、RDPやSSHといった管理ポートを含む大部分の感染ルートを遮断しています。
運用保守でRDP接続が必要な場合は、SSM Session Manager経由でポートフォワーディングを行います。VPC内にSSM用のVPCエンドポイント（ssm / ssmmessages / ec2messages）を配置しているため、NAT Gatewayを経由せずにSession Managerを利用できます。これにより、RDPポートをセキュリティグループで開放する必要がなくなります。
Patch Managerによるパッチ管理
Systems Manager Patch Managerを使用し、ベースラインに従ったパッチ管理を実施しています。SSMメンテナンスウィンドウにより、週次でパッチ適用を自動実行する構成としました。Windows Updateについても、定期的に実行されるようスケジューリングしています。
これにより、OS・ミドルウェアレベルの既知の脆弱性に対して、定期的にパッチが適用される状態を維持できます。
GitLab CI/CDによるセキュリティスキャンとデプロイ自動化
アプリケーション自体の脆弱性対策として、GitLabを使用したCI/CDパイプラインを構築しています。
mainブランチへのプッシュ時に、以下のセキュリティスキャンを自動実行しています。
- SAST（静的アプリケーションセキュリティテスト）
- Secret Detection（APIキー・パスワード等の漏洩検出）
- Dependency Scanning（依存パッケージの脆弱性スキャン）
- Gitleaks（Gitリポジトリ内のシークレット漏洩検出）
- Trivy（ファイルシステムの脆弱性スキャン）
デプロイブランチへのマージ後は、MSBuildによるビルド → 検証環境（大阪リージョン）への自動デプロイ → 手動トリガーで本番環境（東京リージョン）へデプロイという流れで、ビルドからデプロイまでを自動化しています。人的ミスの排除と、アプリケーション自体に対するセキュリティ対策を両立させています。
これらの対策により、Webサービス上の未知の抜け道等によりマルウェアを持ち込まれない限り、感染が極めて困難な構成を実現しています。
対策2: 感染を拡大させない — Network Firewallによるアウトバウンド制御
今回の構成で最も特徴的なのが、この「感染を拡大させない」ための対策です。
ランサムウェアが感染を拡大する場合、あるいは攻撃者がC2（Command and Control）サーバーと通信する場合、必ず感染対象のサーバーから外部に向かうアウトバウンドトラフィックが発生します。今回はこのアウトバウンドトラフィックをAWS Network Firewallで厳格に制限することで、感染拡大を防止する対策を講じました。
ドメインホワイトリスト方式
Network Firewallのステートフルルールグループとして、ドメインベースのホワイトリストを設定しています。VPCからインターネットへ出ていくアウトバウンドトラフィックについて、以下のドメインのみを許可しています。
| 許可ドメイン | 用途 |
|---|---|
| *.windowsupdate.com | Windows Update |
| *.microsoft.com / *.live.com / *.aka.ms | Microsoftサービス全般 |
| *.gitlab.com / *.gitlab-static.net | GitLab CI/CD |
| *.amazonaws.com | AWSサービス |
| *.cloudflare.com | CDN |
| *.azureedge.net / *.nelreports.net | Microsoft CDN・テレメトリ |
対象プロトコルはHTTP_HOSTおよびTLS_SNIで、HTTP/HTTPS通信のドメインフィルタリングを行っています。これにより、万一マルウェアに感染したとしても、攻撃者のC2サーバーへの通信がブロックされるため、感染した事実を攻撃者に伝えることができず、追加のペイロードのダウンロードや感染拡大も阻止できます。
Webサービス運用環境におけるNetwork Firewallのルーティング設計
ここで注意が必要なのが、Network Firewallのルーティング設計です。AWSが提供しているNetwork Firewallのワークショップやドキュメントでは、アウトバウンドトラフィックの制限方法は解説されていますが、原則としてWebサーバーを運用しているケースを想定した構成にはなっていません。そのため、ドキュメント通りに実装するだけでは、アウトバウンドは制限できるものの、Webサイトへのインバウンドアクセスもブロックされてしまいます。
今回の構成では、以下のようなトラフィックフローを設計しています。
【インバウンド（Webアクセス）】
Internet → IGW → Ingress Route Table → Network Firewall → ALB (Public Subnet) → EC2 (Private Subnet)
【アウトバウンド（ホワイトリスト制御）】
EC2 (Private Subnet) → NAT Gateway → Network Firewall → IGW → Internet（許可ドメインのみ）ポイントは、IGWにIngress Route Tableを関連付けて、パブリックサブネット宛の通信をNetwork Firewallエンドポイント経由で検査するルートを追加している点です。これにより、インバウンドトラフィックに対してもNetwork Firewallのステートフルルールで検査を行いつつ、Webサービスへのアクセスは正常に通過させることができます。
Statelessルールではすべてのトラフィックをステートフルエンジンへ転送（aws:forward_to_sfe）し、ステートフルエンジン側でドメインベースのフィルタリングとインバウンドルールの両方を評価する構成としています。
対策3: ファイルやデータの復元が行える状態を保つ
AWS Backupによる定期バックアップ
AWS Backupを使用して、EC2およびRDSのバックアップを1日2回（朝・夕）実施し、35日間保持する構成としています。
| 対象 | スケジュール | 保持期間 |
|---|---|---|
| EC2 (Windows Server) | 1日2回（朝・夕） | 35日 |
| RDS (SQL Server) | 1日2回（朝・夕） | 35日 |
万一感染した場合は、感染前のバックアップ（AMI / スナップショット）から復元できます。RDSについてもポイントインタイムリカバリにも対応しているため、より細かい時点への復元も可能です。
GitLabによる変更管理
前述の通り、EC2上のアプリケーションはGitLabでソースコードを管理し、CI/CDパイプラインでデプロイしています。Gitによる変更管理が行えているため、アプリケーションコードについては任意の時点に戻すことが可能です。
コスト最適化と可用性の工夫
シングルインスタンス + Auto Scaling Groupによる可用性確保
今回の業務用Webサービスは社内向けのシステムで、高トラフィックは想定されていません。また、運用するアプリケーション自体がオートスケーリングを想定した設計になっていないため、シングルインスタンス構成（min:1 / max:1 / desired:1）で運用しています。
ただし可用性を確保するため、Auto Scaling Groupを使用して常に1台のインスタンスが稼働し続ける構成としています。インスタンスに障害が発生した場合、ASGが自動的に新しいインスタンスを起動テンプレートから起動します。
起動テンプレートの自動更新によるRPO短縮
ここでさらに工夫しているのが、起動テンプレートのAMI自動更新です。AWS Backupで最新のバックアップ（AMI）が作成されると、EventBridgeがこのイベントを検知してLambda関数をキックし、起動テンプレートを最新のAMIで更新します。
これにより、ASGがインスタンスを再起動する際には常に最新のバックアップイメージが使用されます。Git管理されていないデータ（ローカルに保存された業務データ等）も含めて復元でき、RPOを最大12時間程度（バックアップは1日2回のため）に保つことができます。DBについてはポイントインタイムリカバリにより、直前の状態まで復元可能です。
Security Hubによる継続的なセキュリティ評価
Security Hubを有効化し、CIS AWS Foundations Benchmark、AWS Foundational Security Best Practices、PCI DSS v4.0.1のセキュリティ基準に対する評価を継続的に実施しています。重要度の高い検出結果については随時対応し、GuardDutyやInspectorと合わせて多層的なセキュリティ監視を行っています。
コストについて
今回の構成でコストが比較的大きいのはNetwork Firewallですが、1リージョンあたり月額$300程度で運用可能です。Network Firewallの料金は、エンドポイント料金（$0.395/時間）とデータ処理料金（$0.065/GB）で構成されますが、社内向けWebサービス程度のトラフィック量であれば、エンドポイント料金が大部分を占めます。
専用のセキュリティアプライアンスやEDR製品を導入するコストと比較すると、AWSのマネージドサービスだけでここまでの対策を講じられるのは、コストパフォーマンスとして優れていると言えます。
まとめ
今回構築した環境では、ランサムウェア対策の3つの柱に対して以下のように対応しました。
| 対策の柱 | 実装内容 |
|---|---|
| 感染させない | Private Subnet配置、SSM Session Manager経由のRDP、Patch Manager、GitLab CI/CDによるセキュリティスキャン |
| 感染を拡大させない | Network Firewallによるアウトバウンドドメインホワイトリスト、Ingress Route Tableによるインバウンド検査 |
| 復元できる状態を保つ | AWS Backup（1日2回/35日保持）、GitLabによる変更管理、起動テンプレート自動更新によるRPO最大12時間 |
ランサムウェアの被害は年々増加し、攻撃手法も巧妙化しています。対策を講じていない環境では、一度の感染で業務が長期間停止するリスクがあります。Network Firewallは月額$300程度から利用可能であり、AWSのマネージドサービスを組み合わせることで、比較的安価にここまでの対策を構成できます。まだ対策が十分でないと感じる方は、ぜひ本記事の構成を参考に検討してみてください。
