DocumentDBクラスターのバックアップの有効化手順について

2025.06.18

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

この記事では、Amazon DocumentDBクラスターに最小バックアップ保持期間が設定されていない状態について、リスクと対策を解説します。

ポリシーの説明

Amazon DocumentDB の Security Hub コントロール – AWS Security Hub

このコントロールは、Amazon DocumentDB クラスターのバックアップ保持期間が指定された時間枠以上であるかどうかをチェックします。バックアップ保持期間が指定された時間枠未満の場合、コントロールは失敗します。バックアップ保持期間に対してカスタムパラメータ値を指定しない限り、Security Hub はデフォルト値の 7 日を使用します。

リスク

Amazon DocumentDB (MongoDB 互換) は、高性能かつスケーラブルなドキュメントデータベースサービスです。DocumentDBクラスターのバックアップ保持期間が適切に設定されていない場合、データ損失のリスクが高まり、以下のような重大な運用上およびコンプライアンス上の問題が発生する可能性があります。

データ損失と復旧不能: バックアップ保持期間が短すぎる、または全く設定されていない場合、誤ってデータが削除されたり、データベースが破損したりした際に、データを復旧できる時点が非常に限られてしまいます。これにより、重要な業務データが永久に失われる可能性があります。
RPO (Recovery Point Objective) への影響: RPOは、障害発生時に許容できるデータの損失量を示します。バックアップ保持期間が短いと、設定されたRPOを満たせず、ビジネス継続性に深刻な影響を与える可能性があります。
コンプライアンス違反: 多くの業界規制やコンプライアンス基準（例: GDPR, HIPAA, PCI DSS）では、データのバックアップと復旧に関する厳格な要件が定められています。十分なバックアップ保持期間がない場合、これらの規制に準拠できず、罰金や法的措置のリスクにさらされる可能性があります。
インシデント対応の遅延: データベースの整合性問題やセキュリティ侵害が発生した場合、特定の時点にデータベースを復元してフォレンジック分析を行うことが必要になる場合があります。保持期間が短いと、必要な時点のバックアップが存在せず、原因究明や対策が遅れる可能性があります。
監査証跡の欠如: データベースの変更履歴を追跡するためにバックアップが利用されることもあります。保持期間が短いと、過去の監査証跡が失われ、コンプライアンス監査に対応できなくなる恐れがあります。

対策

Amazon DocumentDBクラスターに適切なバックアップ保持期間を設定することは、データ損失のリスクを軽減し、ビジネス継続性とコンプライアンスを確保するために不可欠です。

十分な保持期間の設定: アプリケーションのRPO要件、コンプライアンス基準、およびデータ損失がビジネスに与える影響を考慮し、十分なバックアップ保持期間を設定します。一般的には、最低でも7日間、可能であれば30日以上の設定が推奨されます。
自動バックアップの活用: DocumentDBは自動で増分バックアップを取得するため、この機能を最大限に活用し、設定した保持期間に基づいてバックアップが自動的に作成・管理されるようにします。
手動スナップショットの併用: 大規模な変更やデプロイの前など、特定の重要な時点のバックアップが必要な場合は、自動バックアップとは別に手動スナップショットを作成し、より長期的に保存することを検討します。手動スナップショットは自動バックアップの保持期間の影響を受けません。
復元テストの実施: 設定したバックアップと復元プロセスが期待通りに機能するかどうかを定期的にテストします。実際にデータを復元できることを確認することで、緊急時の対応能力を高めることができます。
コストと保持期間のバランス: バックアップのストレージにはコストがかかります。必要な保持期間とコストのバランスを考慮し、最適な設定を見つけることが重要です。

修復方法

AWSコンソールでの修復手順

AWSコンソールを使用して、Amazon DocumentDBクラスターのバックアップ保持期間を設定します。

DocumentDBサービスへ移動:
- AWSコンソールにログインし、DocumentDBサービスを開きます。
クラスターの選択:
- 左側のナビゲーションペインで「クラスター」を選択します。
- バックアップ保持期間を設定したいDocumentDBクラスターを選択します。
クラスターの変更:
- クラスターの詳細ページの上部にある「変更」をクリックします。
バックアップの設定:
- 「バックアップ」セクションまでスクロールします。
- *「バックアップ保持期間」で、目的の期間（例: 7日、30日など）を選択します。DocumentDBは最大35日間まで設定できます。
- 「バックアップウィンドウ」は通常自動で設定されますが、特定の時間帯にバックアップを開始させたい場合は、手動で設定することも可能です。
変更の適用:
- 変更画面の最下部にある「変更の適用」セクションで、変更をいつ適用するかを選択します。
  - すぐに適用: クラスターのメンテナンスウィンドウを待たずに変更が適用されます。場合によっては、クラスターの短時間のダウンタイムが発生する可能性があります。
  - 次のメンテナンスウィンドウで適用: 次に予定されているメンテナンスウィンドウ中に変更が適用されます。
- 選択後、「クラスターを変更」をクリックして設定を完了します。

Terraformでの修復手順

TerraformでAmazon DocumentDBクラスターのバックアップ保持期間を設定するには、aws_docdb_cluster リソースの backup_retention_period パラメータを設定します。

# DocumentDBクラスターの定義
resource "aws_docdb_cluster" "main_docdb_cluster" {
  cluster_identifier      = "my-docdb-cluster"
  engine                  = "docdb"
  engine_version          = "4.0.0" # 使用するエンジンバージョンに合わせて変更
  master_username         = "your_username"
  master_password         = "your_password" # 適切なシークレット管理ツールを使用してください
  skip_final_snapshot     = true # 本番環境では false に設定し、最終スナップショットを取得することを推奨
  db_subnet_group_name    = aws_docdb_subnet_group.main_docdb_subnet_group.name
  vpc_security_group_ids  = [aws_security_group.docdb_sg.id]

  # バックアップ保持期間を7日に設定 (必要に応じて変更)
  backup_retention_period = 7 # 1から35までの整数

  # その他の設定
  port                    = 27017
  preferred_backup_window = "07:00-09:00" # UTC時間でバックアップウィンドウを指定 (オプション)
  preferred_maintenance_window = "mon:03:00-mon:04:00" # メンテナンスウィンドウを指定 (オプション)
  storage_encrypted = true
  tags = {
    Name        = "MyDocumentDBCluster"
    Environment = "Development"
  }
}

# DocumentDBインスタンスの定義 (クラスターに紐づくインスタンス)
resource "aws_docdb_cluster_instance" "cluster_instances" {
  count              = 1 # 必要なインスタンス数に調整
  identifier         = "my-docdb-instance-${count.index}"
  cluster_identifier = aws_docdb_cluster.main_docdb_cluster.id
  instance_class     = "db.r5.large" # インスタンスクラスを適切なものに調整
  engine             = "docdb"
}

# DBサブネットグループの定義
resource "aws_docdb_subnet_group" "main_docdb_subnet_group" {
  name       = "main-docdb-subnet-group"
  subnet_ids = [aws_subnet.private_a.id, aws_subnet.private_c.id] # あなたのプライベートサブネットIDに置き換え
  tags = {
    Name = "MainDocDBSubnetGroup"
  }
}

# セキュリティグループの定義
resource "aws_security_group" "docdb_sg" {
  name        = "docdb-security-group"
  description = "Allow inbound traffic to DocumentDB"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port   = 27017 # DocumentDBのデフォルトポート
    to_port     = 27017
    protocol    = "tcp"
    # ここにDocumentDBにアクセスするEC2インスタンスやLambdaのセキュリティグループIDなどを設定
    # 例: security_groups = [aws_security_group.app_sg.id]
    # または、より限定されたCIDRブロックを設定
    cidr_blocks = ["10.0.0.0/16"] # 適切なIP範囲に制限してください
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  tags = {
    Name = "DocDBSecurityGroup"
  }
}

# VPCおよびサブネットの定義例 (必要に応じて)
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  tags = {
    Name = "main-vpc"
  }
}

resource "aws_subnet" "private_a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.10.0/24"
  availability_zone = "ap-northeast-1a" # あなたのリージョンに合わせて変更
  tags = {
    Name = "private-subnet-a"
  }
}

resource "aws_subnet" "private_c" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.11.0/24"
  availability_zone = "ap-northeast-1c" # あなたのリージョンに合わせて変更
  tags = {
    Name = "private-subnet-c"
  }
}

上記の例では、aws_docdb_cluster リソース内で backup_retention_period = 7 を設定することで、バックアップ保持期間を7日間に指定しています。この値は、ビジネス要件に合わせて 1 から 35 の間の整数で設定できます。

your_username や your_password、my-docdb-cluster などのプレースホルダーは、実際の環境に合わせて修正してください。特にパスワードはHashiCorp VaultやAWS Secrets Managerなどの安全な方法で管理してください。

最後に

この記事では、Amazon DocumentDBクラスターに最小バックアップ保持期間が設定されていない状態について、リスクと対策を解説しました。DocumentDBのバックアップ保持期間を適切に設定することは、データの耐久性と可用性を確保し、ビジネス継続性およびコンプライアンス要件を満たす上で非常に重要です。適切なバックアップ戦略を確立することで、予期せぬデータ損失からシステムを保護し、迅速な災害復旧を可能にすることができます。

この問題の検出は弊社が提供するSecurifyのCSPM機能で簡単に検出及び管理する事が可能です。

運用が非常に楽に出来る製品になっていますので、ぜひ興味がある方はお問い合わせお待ちしております。

最後までお読みいただきありがとうございました。この記事が皆さんの役に立てば幸いです。