こんにちは。タイミーでプラットフォームエンジニアをしている菅原です。普段はAWSを中心に、インフラの設計と運用に取り組んでいます。

今回は、ランサムウェア対策として構築したバックアップと、そのバックアップが正しく機能していることを継続的に監視する仕組みを紹介します。

ランサムウェア攻撃は、データを暗号化したり盗んだりするだけでは終わりません。復旧そのものを妨害するために、既存のバックアップまで削除や改ざんの対象にするケースが増えています。この脅威に備え、私たちはAmazon Auroraクラスタのバックアップを、クロスアカウントの論理エアギャップVault（Logically Air-Gapped Vault、以下LAGV）へ継続的にコピーする仕組みを作りました。

ただ、実際に手間がかかったのはバックアップの経路を組むことよりも、それが本当に機能し続けているかを検証することでした。設定上は正しく組まれているように見えても、タグの付け忘れやジョブの失敗、Vault Policyの不備などで、気づかないうちにコピーが止まっていることがあります。

背景クロスアカウントの論理エアギャップバックアップ

想定する脅威とアカウント分離

前提となる脅威シナリオはこうです。攻撃者はワークロードのAWSアカウントで管理者権限を奪うと、復旧を妨害するためにAWS Backupなどのバックアップ設定を無効化・改ざんし、IAMロールやユーザーの権限も書き換えて正規の管理者による復旧作業を封じます。そのうえでデータを外部に持ち出したのち、DB本体と既存バックアップ(スナップショット)を削除する、というのが想定する動きです。

この脅威に対応するため、バックアップに関わるアカウントは役割ごとに分離しています。なお、このアカウント分離は、AWS Storage Blog「Building cyber resiliency with AWS Backup logically air-gapped vault」で紹介されているData Bunker、Forensics、Recovery Accountの分離パターンを参考にしています。

アカウント種別	役割	アクセス
Backup Admin	AWS Backupのポリシー管理、Organization全体のバックアップ状況の監視	管理者による日常的なアクセスを許可(ワークロードアカウントと同等のセキュリティレベル)
Data Bunker	論理エアギャップVaultを保有し、バックアップデータを保管	管理者であっても日常的なアクセスは禁止
Forensics	Data Bunkerに保管されたバックアップを定期的にリストアし、復旧の整合性をテスト	管理者であっても日常的なアクセスは禁止
Workload Recovery	インシデント時の復旧先となるクリーンな環境	インシデント発生時のみ、Data Bunkerから共有された復旧ポイントを参照

バックアップの実体を持つData Bunkerアカウントには、平常時は誰もログインさせず、ワークロードアカウントとのネットワーク疎通もありません。加えてAWS Backupの論理エアギャップVaultは仕様上コンプライアンスモードが強制され、ルートユーザーであっても保持期間中は復旧ポイントもVault自体も削除できません。この多層の防御によって、攻撃者がワークロードアカウントの管理者権限を握ってもバックアップを壊すことが困難な構成になっています。

暗号化キーの種類とコピー経路

論理エアギャップVaultにコピーできるリソースには仕様上の制約があります。AWS Backupのドキュメントによれば、「フル AWS Backup 管理」をサポートしていないリソースタイプは、AWS管理のKMSキーで暗号化されている場合、論理エアギャップVaultへのコピーがサポートされません。カスタマーマネージドキーで暗号化されているか、暗号化されていないことが条件になります(参考: Copying backups to a logically air-gapped vault)。Auroraはこのフル AWS Backup 管理非サポートのリソースタイプに該当するため、サービスマネージドキーのままでは直接コピーできません。また、Auroraでは既存クラスタの暗号化キーを直接変更できず、異なるキーを使用する場合は新しいクラスタへの移行が必要です。

そこで、既存クラスタの構成変更を前提とせず、キー種別にかかわらずバックアップを論理エアギャップVaultへ保管できるよう、2つのコピー経路を用意しました。カスタマーマネージドキーであれば、定期実行されるバックアッププランでData Bunkerアカウントの論理エアギャップVaultへ直接コピーします。サービスマネージドキーの場合は、まず中間Vault(カスタマーマネージドキーを設定した通常のVault)にコピーして暗号化キーを変換し、そこから論理エアギャップVaultへコピーする形です。中間Vaultへのコピー完了イベントをトリガーに、Step Functionsが論理エアギャップVaultへのコピーを実行します。なお、この中間Vaultを介して暗号化キーを変換し、クロスアカウントコピーを行う構成は、AWS Storage Blog「Protecting encrypted Amazon RDS instances with cross-account and cross-Region backups」で紹介されている方式を参考にしています。

タグでバックアップ対象を制御する

各ワークロードアカウントに個別のバックアップ設定を持たせると設定漏れのリスクが上がるため、AWS Backupのバックアップポリシー機能でBackup Adminアカウントから組織標準のバックアッププランを配布しています。エンジニアがやることは、Auroraクラスタにバックアップ有効化と暗号化キー種別を示すタグを付けるだけです。ここでは例示名で記載します。

タグキー	設定値	説明
`BackupEnabled`	`true` `false`	組織標準バックアップを有効化するか
`KeyType`	`aws-managed` `customer-managed`	前述のコピー経路を切り替えるためのキー種別

このオプトイン方式には、タグの付け忘れがそのままバックアップ対象外につながるという副作用があります。これを防ぐため、AWS Organizationsのタグポリシーで許可されない値を検出できるようにし、Terraform AWS Providerとも統合して、plan実行時に必須タグの欠落をエラーとして検出できるようにしました。

背景の説明はここまでにして、ここからが本題の監視です。

バックアップが取れているはずを信じない

上のアーキテクチャを組んだだけでは、気づかないうちにバックアップが取れなくなっているリスクはまだ残ります。タグの付け忘れや意図しないタグ変更でバックアップ対象から外れることもあれば、バックアップジョブ自体が失敗することもあります。中間Vaultから論理エアギャップVaultへのコピーが、Step Functions経由で失敗することもあります。また、Data Bunker側のVault Policyに不備があり、OrganizationからのCopyIntoBackupVaultが許可されていないケースもあります。

どれも、バックアッププランは設定されているのに論理エアギャップVaultには実際のデータが届いていない状態を引き起こします。設定が存在することではなく、コピーが実際に完了したという事実を継続的に検証する必要があります。

なぜAWS標準のコントロールではなく自作したのか

論理エアギャップVaultにリソースが入っているかを確認する仕組みは、実はAWSの標準機能にも存在します。AWS Backup Audit Managerのフレームワークで「リソースは論理的に隔離された保管庫の中にある」というコントロールを有効にすると、内部的にAWS ConfigのマネージドルールAURORA-RESOURCES_IN_LOGICALLY_AIR_GAPPED_VAULTが作成されます。これにより自動でチェックできます。

まずはこの標準機能で要件を満たせないか検討し、クロスアカウントのコピー構成でも正しく評価できるかをAWSサポートに問い合わせましたが、クロスアカウントで復旧ポイントをコピーした場合、現時点ではこのコントロールではチェックできないことがわかりました。

つまりこのマネージドルールは、同一アカウント内でのVaultへのコピーは評価できます。一方で、私たちのようにコピー先の論理エアギャップVaultが別アカウント（Data Bunker）にあるクロスアカウント構成では、正しくコピーが完了していても常に非準拠として扱われます。責務分離のためにアカウントを分けたこと自体が、標準コントロールの前提と噛み合いませんでした。

この制約で標準のマネージドルールを使う選択肢は消え、クロスアカウントのコピージョブの実行結果を直接確認するカスタムルールを自作する方針に切り替えました。

監視の仕組み AWS Configカスタムルール

AWS ConfigのカスタムルールとしてLambda関数を実装し、各アカウント内のAuroraクラスタについて、一定期間内に論理エアギャップVaultへのコピーが完了した実績があるかを評価しています。評価結果は3種類で、期間内にLAGVへのコピー完了を確認できればCOMPLIANT、確認できなければNON_COMPLIANT、対象のAuroraクラスタが存在しなければNOT_APPLICABLEになります。

Lambdaの処理は大きく4ステップです。

AWS Configから定期評価イベントを受け取り、ルールパラメータを読み取ります。
Auroraクラスタ一覧を取得し、必要に応じてタグでフィルタをかけます。
各クラスタについて、評価対象期間内にLAGVへのコピー完了実績があるかを確認します。
最後に結果をAWS Configに報告します。

必要なIAM権限は、Auroraクラスタとバックアップジョブの参照、およびAWS Configへの評価結果登録に限定しています。

この監視をどう組織全体に展開するか

この監視は1つのLambda関数とConfig Ruleで構成していますが、対象となる全ワークロードアカウントに1つずつデプロイして回るのは現実的ではありません。今後アカウントが増えるたびに設定を追加する運用も避けたいところです。

そこでCloudFormation StackSetsを使い、対象OU配下の全アカウントに自動で配布する構成にしました。

工夫したところは3つあります。

1つ目はLambdaのデプロイ管理をCFn StackSets委任管理者アカウントに集約したことです。CFn StackSetsはOrganizationsの管理アカウントではなく委任管理者アカウントからスタックセットを管理できます。バックアップリソース自体はBackup AdminとData Bunkerのアカウントに閉じていますが、全アカウントにLambdaをばらまくという関心事は別の委任管理者に持たせ、責務を分けました。

2つ目はLambdaコードとインフラのリポジトリを分けつつ、S3のバージョンIDでつないだことです。Lambdaの実装は通常のアプリケーションと同じくアプリケーションリポジトリで管理し、GitHub ActionsからOIDCでAssumeRoleしてビルド成果物をS3にアップロードします。StackSetの定義はTerraformリポジトリ側で管理し、両者をつなぐためにTerraformからS3オブジェクトのversion_idを参照して、それをStackSetのCloudFormationパラメータとして渡します。Lambdaコードの更新はS3へのアップロードだけで完結し、インフラ側は参照するバージョンを更新してapplyするだけで全アカウントへの再配布が終わります。アプリケーションのデプロイフローとインフラのデプロイフローを混ぜずに済む構成です。S3バケットはバージョニングを有効化したうえで、noncurrent_version_expirationで古いバージョンを一定期間後に自動削除し、オブジェクトが無制限に溜まらないようにもしています。

3つ目はクロスアカウントの成果物配布をOrganization ID条件で絞ったことです。各メンバーアカウントのLambdaが実行時にS3から成果物を取得できるよう、バケットポリシーで組織内アカウントからのs3:GetObjectを許可しています。aws:PrincipalOrgID条件を使い、組織に所属するプリンシパルだけにアクセスを絞ることで、意図しない外部アカウントからの参照を防いでいます。

検知後の運用フロー

監視の仕組みだけ作っても、検知後にどう動くかが決まっていなければ意味がありません。NON_COMPLIANTが検出された場合の一次切り分け手順を運用ガイドラインとして整備しました。

日常的な状態確認はダッシュボードで行い、加えて全アカウントの評価結果はSecurity Hub CSPMを介して委任管理者アカウントに集約しています。このカスタムルールでの新規違反検出にフィルタするSecurity Hubのインサイトを作成することで、対応が必要な検出結果が残っているアカウントを一覧できるようにしています。これにより、個別のワークロードアカウントを一つずつ見て回らなくても、組織全体のバックアップの健全性を俯瞰できます。