AWS Backup Vault LockでDBバックアップ自体のセキュリティを強化する
はじめに
自分が開発しているサービスではAWSのAurora RDSを採用しており、いざという時に備えて日々バックアップを取得していましたが、バックアップ自体のセキュリティについてはそれほど意識していませんでした。
そんな中でランサムウェアをはじめとするマルウェア被害が増加しており、仮にDBがマルウェア被害を受けてデータが暗号化されたとしてもバックアップから正常に復旧できる体制を整えておくことの必要性を感じました。
しかし、通常のAuroraのバックアップ機能を利用しているままではバックアップ自体がマルウェアによって削除・暗号化される可能性があります。仮にバックアップ自体を攻撃された場合、正常な復旧ができなくなりサービス存続の危機に瀕してしまいます。
そこで本記事では、AWS Backup Vault Lock を利用して、削除・変更不可能なバックアップ体制を構築する方法を紹介します。
自サービスに導入してみてわかった導入・運用時の注意点に関する知見もあるので参考になれば嬉しいです。
現状のバックアップ体制の問題点
Amazon Auroraの標準機能である自動バックアップを利用している場合、以下のような設定が一般的です。
| 設定項目 | 設定値 |
|---|---|
| バックアップ保持期間 | 1〜35日（例：10日） |
| ポイントインタイムリカバリ（PITR） | 有効 |
| バックアップデータの保護 | なし |
問題点
-
バックアップデータが保護されていない
- マルウェアによりDBデータだけでなく、バックアップ自体を暗号化・削除される可能性がある
- 人為的なミスによるバックアップ削除も防げない
-
ルートユーザーでも削除可能
- AWSアカウントが侵害された場合、すべてのバックアップが危険にさらされる
つまり、悪意のある攻撃に弱いことに加えて、運用者の人為的なミスに対してもガードレールがない状態です。
AWS Backup Vault Lock とは
AWS Backup Vault Lock は、AWS Backupの機能で、バックアップデータを変更・削除不可能にするための仕組みです。この仕組みを用いれば上述した問題に対処できます。
2つのモード
AWS Backup Vault Lockには以下の2つのモードがあります。
| モード | 特徴 |
|---|---|
| ガバナンスモード | 十分なIAM権限があれば解除可能 |
| コンプライアンスモード | 猶予期間（Grace Time）経過後はルートユーザーでもAWSでも解除不可能 |
コンプライアンスモードの特徴
AWS Backup ensures that your backups are available for you until they reach the expiration of their retention periods. If any user (including the root user) attempts to delete a backup or change the lifecycle properties in a locked vault, AWS Backup will deny the operation.
つまり、コンプライアンスモードでロックされたVaultは：
- ルートユーザーでもバックアップの削除・変更が不可能
- AWS側でも操作不可能
- 設定した保持期間が経過するまで確実にバックアップが保護される
これにより、マルウェアがAWSアカウントを侵害したとしても、バックアップデータは安全に保たれます。また、人為的なミスによるバックアップ削除も防げます。
実装手順
AWS Backup Vault Lockを利用したバックアップ体制を構築する手順をterraformを用いて説明します。
必要なリソース
- Backup Vault - バックアップを保存するVault
- Vault Lock - Vaultをロックする設定
- Backup Plan - バックアップスケジュールの定義
- Backup Selection - バックアップ対象リソースの指定
- IAMロール - バックアップ/リストア用のロール
1. Backup Vaultの作成
resource "aws_backup_vault" "main" {
name = "my-db-backup-vault"
# kms_key_arn を省略するとAWS管理キー（aws/backup）が使用される
tags = {
Environment = "production"
}
}
2. Vault Lockの設定
resource "aws_backup_vault_lock_configuration" "main" {
backup_vault_name = aws_backup_vault.main.name
# コンプライアンスモードの場合は changeable_for_days を設定
# changeable_for_days = 3 # 3日間は設定変更可能（猶予期間）
min_retention_days = 7 # 最小保持期間
max_retention_days = 365 # 最大保持期間
}
3. IAMロールの作成
resource "aws_iam_role" "backup" {
name = "my-db-backup-role"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = {
Service = "backup.amazonaws.com"
}
}
]
})
}
resource "aws_iam_role_policy_attachment" "backup" {
role = aws_iam_role.backup.name
policy_arn = "arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForBackup"
}
resource "aws_iam_role_policy_attachment" "restore" {
role = aws_iam_role.backup.name
policy_arn = "arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForRestores"
}
4. Backup Planの作成
resource "aws_backup_plan" "main" {
name = "my-db-backup-plan"
rule {
rule_name = "daily-backup"
target_vault_name = aws_backup_vault.main.name
schedule = "cron(0 16 * * ? *)" # 日本時間 01:00
lifecycle {
delete_after = 30 # 30日後に削除
}
# PITRを有効化（継続的バックアップ）
enable_continuous_backup = true
start_window = 60 # 開始までの猶予（分）
completion_window = 480 # 完了までの猶予（分）
}
}
5. Backup Selectionの作成
resource "aws_backup_selection" "main" {
name = "my-db-backup-selection"
plan_id = aws_backup_plan.main.id
iam_role_arn = aws_iam_role.backup.arn
resources = [
aws_rds_cluster.main.arn
]
}
設定自体はこれで終わりです。設定したバックアップウィンドウ内でaws backupによりバックアップが作成されているはずなのでこれを確認できます。
この時点でガバナンスモードでVault Lockが適用されているので、Vault自体の削除や変更ができなくなっています（権限を持ったユーザーでVault Lock自体の設定を削除/変更することは可能）。
リストア手順
次に、ポイントインタイムリカバリ（PITR）でAWS Backupで取得したバックアップからリストアする手順を説明します。
AWS Backupからのリストアは、Terraformではなくマネジメントコンソールまたはaws CLIから実施します。
1. PITRでクラスターをリストア
マネジメントコンソールから：
- AWS Backup → Backup Vaults → 対象のVaultを選択
- 復旧ポイントを選択し「復元」をクリック
- リストア先の時刻を指定（PITRの場合）
- 必要な設定（インスタンスクラス、VPC、セキュリティグループなど）を入力
2. Writerインスタンスの作成
aws rds create-db-instance \
--db-instance-identifier my-aurora-instance-restored \
--db-instance-class db.r6g.large \
--engine aurora-mysql \
--db-cluster-identifier my-aurora-cluster-restored \
--availability-zone ap-northeast-1a
3. Readerインスタンスの作成（必要に応じて）
マネジメントコンソールまたはCLIからReaderインスタンスを追加します。
導入・運用時の注意点
1. Auroraに備わっているネイティブの自動バックアップ機能を停止することはできない
auroraの自動バックアップ機能については完全にOFFにすることはできない（最低1日のバックアップ設定が必要）ため、仮にAWS Backup Vault Lockに移行したとしてもaurora自体の自動バックアップは最低1日は保持する形となります。aws backupへの移行時は既存の設定は変えずにaws backupとネイティブの自動バックアップ機能を並行稼働し、aws backupでの安定運用が確認できたタイミングでaurora側の自動バックアップ保持期間を最低の1日に設定するなどの対応がよいかと思われます。
2. コンプライアンスモードの設定には注意
AWS Backup Vault Lockには「ガバナンスモード」と「コンプライアンスモード」の2種類がある。コンプライアンスモード設定後、猶予期間を過ぎた場合にはAWSアカウントを削除するまでそのVault Lockの設定を削除することができなくなるので、PRDであってもまずはガバナンスモードで導入することを推奨します。後でコンプライアンスモードに切り替えることも可能なので、安定運用を確認できた段階で切り替えると良いと思われます。
ただし、紐づいているDBクラスターの削除やAWSアカウント自体の削除はできるようになっているので、アカウントを畳む際やDB移設などでDBクラスターなどを切り替える際でも問題はありません。残存するaws vault lockの設定分のコストはかかり続ける可能性があるので注意しましょう。
3. バックアップウィンドウの設定
Aurora側の自動バックアップやメンテナンスウィンドウと重複しないように、AWS Backupのバックアップウィンドウを設定してください。
参考: Amazon RDS のバックアップ - AWS Backup
4. Backup Vault利用時にはCMKの利用には注意
AWS Backup Vault自体をLockしても、復号のためのKMSキー自体を悪意を持った攻撃で変更/破棄された場合には結局復旧できなくなるので注意してください。変更破棄ができないような権限をつけたとしても、マルウェアに感染した時点でここの権限を変えられる可能性もあります。AWS管理のキーを利用することで本問題を回避できます。
5. リストア後のデータ不整合
マイクロサービス環境では、1つのDBを過去時点にリストアすると、他サービスとのデータ不整合が発生する可能性があります。リストア手順書を作成する際は、この点も考慮してリストア戦略を策定するようにしましょう。
まとめ
AWS Backup Vault Lockを利用することで、マルウェアやアカウント侵害に対しても堅牢なバックアップ体制を構築できます。
| 項目 | Before | After |
|---|---|---|
| バックアップ保護 | なし | Vault Lockで保護 |
| ルートユーザーによる削除 | 可能 | 不可能（コンプライアンスモード） |
| マルウェア耐性 | 低い | 高い |
特にセキュリティ要件の高いシステムでは、コンプライアンスモードでのVault Lock運用を検討することをお勧めします。
参考リンク
We are Hiring!
自分のチームでは機密情報を取り扱っているという関係上このようなセキュリティ向上といったテーマに日々向き合っています。同じような課題に興味がある方、一緒にプロダクト改善していきたい方は、ぜひ採用ページも覗いてみてください。
▼募集要項・応募はこちら：
カジュアル面談からでも大歓迎です！
Discussion