Amazon Aurora クラスターのバックトラッキング有効化手順について

このブログシリーズ 「クラウドセキュリティ 実践集」 では、一般的なセキュリティ課題を取り上げ、「なぜ危険なのか?」 というリスクの解説から、 「どうやって直すのか?」 という具体的な修復手順(コンソール、AWS CLI、Terraformなど)まで、分かりやすく解説します。
この記事では、Amazon Aurora クラスターのバックトラッキングについて、リスクと対策を解説します。

ポリシーの説明
すべてのAurora DBクラスターでバックトラッキングを有効にしてください。これにより、特定の時点への迅速な復元が可能になり、インシデントからの復旧時間を短縮できます。バックトラック期間を適切に設定し、定期的にバックトラック機能をテストしてください。
リスク
Amazon Aurora クラスターのバックトラッキングが有効になっていない場合、以下のリスクが発生します:
ビジネスリスク
- 誤操作からの復旧困難: 誤ったDELETE、UPDATE、DROPコマンド実行後、数秒ではなく数時間かかる復元作業が必要になります
- ダウンタイムの長期化: バックアップからの復元では、スナップショットの復元とbinlogの適用に数時間要する場合があります
- データ損失のリスク: ポイントインタイムリカバリでは、最終バックアップ以降のデータが失われる可能性があります
技術的制約
- Aurora MySQLのみ対応: バックトラッキングはAurora MySQL 5.6および5.7互換バージョンでのみ利用可能です(Aurora PostgreSQLやMySQL 8.0互換では利用不可)
- クラスター作成時のみ設定可能: 既存クラスターに後からバックトラッキングを追加することはできません
- コスト増加: バックトラック期間に応じて追加コストが発生します(時間あたり約0.012 USD)
修復方法
重要: バックトラッキングはクラスター作成時にのみ有効化できます。既存のクラスターに後から追加することはできません。既存クラスターの場合は、スナップショットから新しいクラスターを作成する必要があります。
コンソールでの修復手順(新規クラスター作成)
- AWSマネジメントコンソールにログインし、RDSサービスに移動します
- 「データベースの作成」をクリックします
- 「エンジンオプション」で「Amazon Aurora」を選択します
- 「エディション」で「Amazon Aurora with MySQL compatibility」を選択します
- 「バージョン」でAurora MySQL 8互換バージョンを選択します
- 「追加設定」セクションで「バックトラッキングを有効化」にチェックを入れます
- 「ターゲットバックトラックウィンドウ(時間)」に72を入力します(最大72時間まで巧き戻し可能)

- その他の必要な設定を完了し、「データベースの作成」をクリックします
既存クラスターの場合はスナップショットから復元する際にバックトラッキング期間を設定するようにしましょう。
Terraformでの修復手順
# Aurora MySQLクラスターの定義(バックトラッキング有効)
resource "aws_rds_cluster" "aurora_with_backtrack" {
cluster_identifier = "${var.environment}-aurora-cluster"
engine = "aurora-mysql"
engine_version = "5.7.mysql_aurora.2.11.2" # バックトラッキング対応バージョン
# データベース設定
database_name = var.database_name
master_username = var.master_username
master_password = random_password.master.result
# バックトラッキング設定
backtrack_window = 72 # 最大72時間までのバックトラッキングを有効化
# バックアップ設定
backup_retention_period = 7
preferred_backup_window = "03:00-04:00"
preferred_maintenance_window = "sun:04:00-sun:05:00"
# セキュリティ設定
storage_encrypted = true
kms_key_id = aws_kms_key.aurora.arn
deletion_protection = true
# ネットワーク設定
db_subnet_group_name = aws_db_subnet_group.aurora.name
vpc_security_group_ids = [aws_security_group.aurora.id]
# ログ設定
enabled_cloudwatch_logs_exports = [
"audit",
"error",
"general",
"slowquery"
]
# スナップショット設定
skip_final_snapshot = false
final_snapshot_identifier = "${var.environment}-aurora-final-snapshot-${formatdate("YYYY-MM-DD-hhmm", timestamp())}"
tags = {
Name = "${var.environment}-aurora-cluster"
Environment = var.environment
Backtrack = "Enabled"
ManagedBy = "Terraform"
}
}
# Auroraインスタンスの定義
resource "aws_rds_cluster_instance" "aurora_instances" {
count = var.instance_count
identifier = "${var.environment}-aurora-instance-${count.index + 1}"
cluster_identifier = aws_rds_cluster.aurora_with_backtrack.id
instance_class = var.instance_class
engine = aws_rds_cluster.aurora_with_backtrack.engine
engine_version = aws_rds_cluster.aurora_with_backtrack.engine_version
performance_insights_enabled = true
performance_insights_retention_period = 7
monitoring_interval = 60
monitoring_role_arn = aws_iam_role.rds_enhanced_monitoring.arn
tags = {
Name = "${var.environment}-aurora-instance-${count.index + 1}"
Environment = var.environment
}
}
# バックトラッキングを実行するためのnull_resource(オプション)
resource "null_resource" "backtrack_test" {
depends_on = [aws_rds_cluster.aurora_with_backtrack]
provisioner "local-exec" {
command = <<-EOT
echo "バックトラッキングが有効化されたクラスター: ${aws_rds_cluster.aurora_with_backtrack.id}"
echo "バックトラッキング期間: ${aws_rds_cluster.aurora_with_backtrack.backtrack_window} 時間"
EOT
}
}
最後に
この記事では、Amazon Aurora クラスターのバックトラッキングについて、リスクと対策を解説しました。
この問題の検出は弊社が提供するSecurifyのCSPM機能で簡単に検出及び管理する事が可能です。 運用が非常に楽に出来る製品になっていますので、ぜひ興味がある方はお問い合わせお待ちしております。 最後までお読みいただきありがとうございました。この記事が皆さんの役に立てば幸いです。