はじめに
第1回で「バックアップの隔離」を、第2回で「クリーンなリカバリポイントの特定」を扱いました。ここまでで、守られたバックアップの中から「いつの時点のバックアップを戻せば安全か」を特定できる状態になりました。
最後に残る問いは「その安全なバックアップから、実際にどこへ・どうやって復旧するか」です。
ランサムウェア感染後、感染した環境にそのまま復旧すると、攻撃者がまだ環境内に潜んでいた場合に復旧作業そのものが二次被害の起点になり得ます。このため、本番とは分離した Isolated Recovery Environment（IRE）へ復旧することが推奨されます。
本稿では、隔離された安全な環境（IRE）へ段階的に復旧していく、具体的な実装フローを解説します
WAFのベストプラクティス：SEC10-BP03「フォレンジック機能を備える」
WAF の SEC10-BP03 の中では、次のように述べています。
「インシデント対応には、セキュリティ OU および フォレンジック OU を含むインシデント対応の機能をサポートする AWS アカウント構造があると便利です。
〜中略〜
新しいアカウントのプロビジョニングには時間がかかるため、インシデントのかなり前にフォレンジックアカウントを作成して実装し、対応担当者が効果的に対応できるように準備しておくことが重要です。」
参考：SEC10-BP03 Prepare forensic capabilities
このベストプラクティスでは、インシデント対応のためのアカウント構造として、セキュリティ OU（ログ集約アカウント・セキュリティツールアカウント）とフォレンジック OU（リージョンごとのフォレンジックアカウント）をあらかじめ分離しておくことを推奨しています。ポイントは「発生してから作る」のではなく「事前に環境を用意しておく」ことです。
また、バックアップ・スナップショットの確保についても明記されています。
「主要なシステムとデータベースのバックアップをセットアップすることは、セキュリティインシデントからの回復とフォレンジックのために重要です。」
このように WAF では、バックアップを「復旧のため」だけでなく「フォレンジックのため」の証拠としても位置づけています
AWSでの実装ポイント
フォレンジックと IRE による復旧環境構成
ここからは、この WAF の考え方をベースとした具体例の AWS のブログを紹介しながら、「調査」と「復旧」の2つに分けて見ていきます。
① 調査のための環境：フォレンジックアカウント
SEC10-BP03 の中でフォレンジック機能の構築を開始するための情報として次の ブログを参照しています。
参考：Forensic investigation environment strategies in the AWS Cloud (翻訳版)
ここで示されているのは、証跡を保全して調査するための環境です。侵害されたアカウントから渡されたスナップショットやログを、フォレンジック OU の専用アカウントで分析します。目的は攻撃者の挙動や根本原因の特定であり、業務を再開するための環境ではありません。調査ごとにアカウントを作り直す、法的保全の対象にできる、セキュリティチームとは別チームで扱う、といった運用も想定されています。
② 復旧のための環境：Isolated Recovery Environment（IRE）
もうひとつの具体例として、次のブログを紹介します。
参考：Cyber recovery on AWS: A reference approach for recovering from ransomware and destructive events
こちらでは業務を再開するための環境を扱っています。
核となる考え方は、復旧環境を、その認証基盤・鍵・ネットワーク経路も含めて、復旧対象の環境と同じ信頼境界に置かないことです。本番アカウントが侵害されても、復旧はそれに依存せず進められなければなりません。構成要素は次のとおりです。
表1：復旧のためのアカウント構成要素
そのうえで、2つのデプロイモデルが示されています。
表2：復旧のための2つのデプロイモデル
復旧ワークフローは次の 5 ステージで、1、2、4 は並行して進める設計です。
調査
CloudTrail・VPC Flow Logs・GuardDuty・Security Hub 等から、インシデント発生の最も早い兆候を特定する（これ以前のリカバリポイントが候補になる）。検証
発生時点より前の候補を新しい順に検証パイプライン（Restore Testing、GuardDuty、ワークロード固有のチェック、ログ監査）へ通す。承認
検証を通過したリカバリポイントだけを承認し、選定の根拠を記録する。再構築・復元
IaC で IRE のインフラを再構築しつつ、承認後に検証済みデータを LAG ボールトから復元する。この段階で認証情報もローテーションする。カットオーバー
DNS で本番トラフィックを切り替える。切り替え前に、IAM ロールの信頼ポリシーや KMS キーの付与など、旧本番アカウントを指すクロスアカウント参照を更新する。調査が完了するまで、影響を受けた本番アカウントは隔離したままにする。
なお、ステージ 2 の検証パイプラインで注意したいのが、マルウェアスキャンの実施タイミングです。同ブログによると、GuardDuty Malware Protection for AWS Backup が検知できるのは、リカバリポイントの作成時にスキャンされる EBS・EC2・S3 のものに限られ、LAG ボールトにコピーされたリカバリポイントに対するスケジュールスキャンには対応していません。そのため、IRE 側で GuardDuty Malware Protection for EC2 を使い、復元したあとのボリュームをスキャンする運用が示されています。つまり、復元してからスキャンし、脅威が見つかれば一つ前の候補に戻って再度復元・スキャンする、という流れとなります。なお、AWS Backup のドキュメントでは、既存のバックアップに対するオンデマンドスキャン自体は提供されているものの、LAG ボールト内の EC2 リカバリポイントではインクリメンタルスキャンに対応せず、フルスキャンのみとされています。そのため、スキャンに時間がかかる点は変わらないと考えられます。
第2回で触れた Restore Testing と同様に、復元してからスキャンする流れでは、スキャンの待ち時間や再試行の手間が発生し、試行錯誤によって RTO が長期化するおそれがあります。
また、同ブログの検証パイプラインの表中に、AWSネイティブの機能とは別に「AWS Partner（AWS Marketplace のパートナーソリューション）」の項目があり、「バックアップコンテンツ内でのコンテンツレベルのランサムウェアスキャン」の役割が示されています。ここは、Rubrik が担える役割であり、復元してからスキャンする流れでは時間がかかりトライアンドエラーになりがちな部分を補う選択肢になります。
AWS Backupでクロスアカウントに復旧するための前提
デプロイモデルの Model 1 では、LAG ボールトを AWS RAM で IRE に共有していました。この構成が採用されている背景には、AWS Backup のクロスアカウントリストアの制約があります。AWS Backup の標準的なボールトは、別アカウントへの直接リストアをサポートしていません。クロスアカウントで復旧するには、いったん復元先アカウントのボールトへリカバリポイントをコピーし、コピー先のアカウント内で改めてリストアする、というステップが必要です。
これに対し LAG ボールトは、AWS RAM を使ってボールトそのものを他アカウントと共有でき、コピーの工程を経ずに直接リストアできるという特徴を持ちます。AWS の参照構成で LAG ボールトと RAM 共有が採用されているのは、このクロスアカウントリストアの制約を踏まえた設計と考えられます。
ただし、これは LAG ボールトにバックアップが入っていることが前提です。AWS Backupのドキュメントによると、EBS/EC2、Aurora、FSx などでは、AWSマネージドキー（`aws/ebs`、`aws/rds`など）で暗号化されていると LAG ボールトへコピーできず、標準ボールトにしかバックアップが作成されません。LAG ボールトに入れるには、CMKで暗号化するか非暗号化にする必要があります。つまり、AWSマネージドキーのままのEBS/EC2 では、LAG＋RAM 共有による「コピー不要のクロスアカウントリストア」の対象になりません。
参考：Primary backups to logically air-gapped vaults
クロスアカウントリストアにおける KMS の壁
本番アカウントと IRE を分離する構成を実際に組む際、見落とされがちですが避けて通れないのが KMS 暗号鍵の扱いです。EBS や RDS のスナップショットを暗号鍵ごと別アカウントへ渡す場合、暗号化に使っているキーの種類によって難易度が変わります。
表3：鍵の種類によるクロスアカウント共有可否
AWS マネージドキーで暗号化されたスナップショットを別アカウントへ渡すには、いったん同一リージョン内でスナップショットをコピーし、その際に CMK を指定して再暗号化してから共有する、という一手間が標準的な回避策になります。デフォルト設定のまま AWS マネージドキーで運用している環境は珍しくないため、フォレンジックアカウントや IRE へスナップショットを渡す設計をする段階で「どのワークロードが AWS マネージドキーで暗号化されているか」を事前に棚卸ししておく必要があります。有事の最中に「このスナップショットはそのままではクロスアカウントに復元できない」と気づくのは避けたい事態です。そのため、以下の点について事前に設計しておくことが重要となります。
バックアップをどこに置くか（本番アカウントの LAG ボールトか、別アカウントへのコピーか）
暗号化キーをどうするか（ソースリソースのキーの種類、LAG ボールトの AWS所有キー／CMK、共有設定）
Rubrik による強化
Isolated Recovery Environments（IRE）復旧フロー
IRE は AWS だけの用語ではなく Rubrik も採用している概念です。ここからは、WAF とAWS ブログが示した考えに、Rubrik の考え方を重ねて整理します。Rubrik では復旧先を次の 3 つのゾーンで捉えています。
表4：復旧先の 3 つのゾーン定義
第2回で紹介した Threat Monitoring（TM）・Anomaly Detection（AD）・Threat Hunting（TH） と、後述の Orchestrated Application Recovery（OAR）という Rubrik の機能を活用し、それぞれのゾーンに当てはめたフローを下図に示します。
図1：Rubrik の Isolated Recovery Environments（IRE）復旧フロー
攻撃検知・本番隔離
本番を隔離・封じ込めゾーン1｜フォレンジック
TM/AD で攻撃検知時点のクリーン候補を推定
疑わしい候補を復元し、ハッシュ・IP 等の IOC を特定
（フォレンジック調査用に即時共有可能）Threat Hunting によるバックアップ照合
特定した IOC で全スナップショットを高速スキャン
（数万件のスナップショットを数分でスキャンし、クリーンなバックアップを高速に確定）ゾーン2｜ステージング：リカバリ・検証
確定済みのクリーンなバックアップを復元しアプリ動作検証ゾーン3｜新本番：段階昇格
検証済みのワークロードを重要度順に昇格、業務再開
TM/AD で異常が検出されずに調査対象外と判断できたワークロードは、2、3 のフォレンジック・照合ステップを経由せず直接 4 へ進めます。すべてのワークロードに同じ調査コストをかける必要はありません。このフローに基づいた AWS アカウント構成例を次に示します。AWS ブログでは、本番と IRE の 2 アカウント構成を示していますが、これに加えて WAF が示すフォレンジック用のアカウントを加えた 3 アカウント構成としています。
図2：IRE 復旧フロー AWS アカウント構成例
Orchestrated Application Recovery（OAR）による自動選択
OAR のリカバリプランを利用し、リカバリ対象とするリソースを登録しておくことで「確定済みのクリーンなポイントはどのスナップショットか？」を複数リソースにまたがって自動的に選択することができます。異常と判定されたスナップショットは自動的に選択肢から除外されます。例えば、異常のない（攻撃を受けていない）EC2 では最新のスナップショットが選択され、異常を含む EC2 では、異常ではない最新のスナップショットが選択されます。なお、フォレンジック目的で異常のあるスナップショットのみを選択することも可能です。
図3：複数リソースに跨がったクリーンなポイントを自動的に選択
図4：異常判定されたスナップショットを自動で除外
表5：リカバリプランでの選択オプション
ゲートウェイキーによるクロスアカウント KMS の壁越え
AWS ネイティブでは、AWS マネージドキーをクロスアカウントで共有できないため、ゾーン間の移行をするうえでも無視できない壁がある点について解説しました。
Rubrik では、あらかじめゲートウェイキーとして Rubrik の指定したエイリアスを持つキーを用意しておくだけで、再暗号化処理を Rubrik が内部で代行します。バックアップ元が AWS マネージドキーで暗号化されている場合でも、スナップショットのコピー時にゲートウェイキーで再暗号化されるため、別アカウントへリストアすることができます。ただし、この方式はスナップショットのコピーを伴うため、次の点に注意する必要があります。
コスト
余分なスナップショットコピーが発生し、その分のコストがかかる。スケール
AWS ではスナップショットの同時コピーに関するクォータがあり、大規模環境で多数のスナップショットを一斉にリストアする場合に制限がある。
とはいえ、AWS マネージドキーで運用しており、CMK への変更が難しいお客様にとっては、キーを変更せず、手動での再暗号化の手間も省いて、クロスアカウントリストアの選択肢を確保できる点で有用な仕組みと言えるでしょう。
※構成やバックアップ対象によっては、ゲートウェイキーが不要（さらに容易）な場合もあります。
まとめ
第1回から第3回まで、WAF のベストプラクティスに沿って「バックアップの隔離」「クリーンなリカバリポイントの特定」「クリーン環境へのリカバリ実装」という 3 つのテーマを扱ってきました。
AWS ネイティブでは、Object Lock・LAG ボールト・GuardDuty Malware Protection for AWS Backup・Organizations によるアカウント分離など、いずれも強力な基盤を提供します。一方で、安全なリカバリのための IRE におけるクロスアカウントでのリストアでは AWS マネージドキーの共有制約という見落とされがちな制約もあり、平時の鍵管理設計を怠ると有事の際の復旧時間の長期化に繋がってしまいます。Rubrik では、デフォルトイミュータブル構成、RCV による論理エアギャップ、TM/AD/TH による脅威分析、OAR による自動化されたクリーンポイントの特定と復旧、そしてゲートウェイキーによるクロスアカウント KMS の壁越えを組み合わせることで、この 3 つのテーマに安全かつ容易に一貫して対応することができます。
次回は WAF の運用上の優秀性をテーマに、日々の運用の効率化について取り上げます。