![【Security Hub修復手順】[RDS.50] RDS DB クラスターには十分なバックアップ保持期間を設定する必要があります](https://images.ctfassets.net/ct0aopd36mqt/wp-refcat-img-cea52bc8a6ec5cad9021b38df4a08b9e/24c76ee7c1ae7aa7f9676a59c77f8702/aws-security-hub?w=3840&fm=webp)
【Security Hub修復手順】[RDS.50] RDS DB クラスターには十分なバックアップ保持期間を設定する必要があります
こんにちは、クラウド事業本部コンサルティング部の村瀬です。
皆さん、お使いの AWS 環境のセキュリティチェックはしていますか？
本記事では、AWS Security Hub による AWS 環境のセキュリティ状況スコアリングに該当する項目についての修復手順をご紹介します。
本記事の対象コントロール
[RDS.50] RDS DB クラスターには十分なバックアップ保持期間を設定する必要があります
[RDS.50] RDS DB clusters should have enough backup retention period set
前提条件
本記事は AWS Security Hub で「AWS 基礎セキュリティのベストプラクティススタンダード」を利用されている方向けの内容となります。
AWS Security Hub の詳細についてはこちらのブログをご覧ください。
対象コントロールの説明
このコントロールは、RDS DB クラスターのバックアップ保持期間が、指定した日数以上に設定されているかをチェックします。
保持期間がしきい値（minimumBackupRetentionPeriod パラメータ。デフォルトは 7 日）より短い場合、このコントロールは失敗（FAILED）します。
保持期間をしきい値以上に設定すると、このコントロールは成功（PASSED）します。
なお、このコントロールは Aurora DB クラスターだけでなく、DocumentDB クラスターや Neptune DB クラスターなど、すべてのタイプの RDS DB クラスターが対象です。
ここで押さえておきたいのが、バックアップ保持期間は「クラスター単位」の設定だという点です。
Aurora をはじめとする DB クラスターは、ストレージ（データ）とコンピュート（インスタンス）が分離した構成で、データに関わる設定はクラスター側に紐づきます。そのため、修復はクラスターに対して行います（インスタンス側ではありません）。
バックアップ保持期間とは
バックアップ保持期間は、自動バックアップを「何日分」保持するかの設定です。
RDS / Aurora は、設定した保持期間の範囲内であれば、任意の時点へ復元できる「ポイントインタイムリカバリ（PITR）」が利用できます。
つまり保持期間がそのまま「どこまで過去に巻き戻せるか」の範囲になります。
対応しない場合のリスク
保持期間が短いと、PITR で復元できる範囲が狭くなります。
たとえば保持期間が 1 日の場合、アプリケーションの不具合によるデータ破損や、誤ったデータ削除に 2 日後に気づいても、正常だった時点まで復元できません。
障害や誤操作、ランサムウェアなどは、発生から気づくまでにタイムラグが生じることが少なくありません。復元できる範囲が狭いほど、いざというときにデータを取り戻せない可能性が高まります。
そのため本番環境では、最低でも 7 日間（要件に応じてそれ以上）の保持期間を確保することが必須です。
本番以外の環境での考え方
本番以外の検証・開発環境では、バックアップストレージのコスト最適化を優先し、保持期間を短くしても問題ありません。
バックアップ保持期間が長くなるほど、保持されるバックアップのストレージ料金が増えるためです。
なお、手動スナップショットや AWS Backup など、別の手段で必要なバックアップを確保できている場合は、ワークフローステータスを「抑制済み」に設定することも可能です。
コントロールの確認方法
-
Security Hub コンソールを開く
-
左メニューから「検出結果」を選択
-
フィルターで対象のコントロール ID「RDS.50」を検索
-
検出結果の詳細（対象の DB クラスターと現在のバックアップ保持期間）を確認する
ステークホルダーに確認
修復を行う前に、以下の点をステークホルダーに確認してください。
- 設定する保持期間（要件に応じて 7〜35 日。RPO やコンプライアンス要件に基づいて決定）
- バックアップ保持期間を延ばすことによるバックアップストレージの追加コスト
- バックアップが実行される時間帯（バックアップウィンドウ）が業務に影響しないか
Aurora DB クラスターの場合、バックアップ保持期間の変更はダウンタイムなしで即時に適用できます。
変更後は新しい保持期間が適用され、過去にさかのぼれる範囲が順次広がっていきます。
修復手順
RDS コンソールから、対象の DB クラスターのバックアップ保持期間を変更します。
-
RDS コンソールを開く
-
左メニューから「データベース」を選択
-
対象の DB クラスターを選択し、「変更」を選択
-
「追加設定」の「バックアップ」セクションを開き、「バックアップ保持期間」を 7 日以上（しきい値以上）に変更する
-
「続行」を選択し、変更のスケジュールで「すぐに適用」を選択する
-
「クラスターの変更」を選択して変更を適用する
参考までに、AWS CLI で変更する場合は次のコマンドです。
aws rds modify-db-cluster \
--db-cluster-identifier <DB クラスター識別子> \
--backup-retention-period 7 \
--apply-immediately
修復確認
修復後、Security Hub で検出結果が「PASSED」になることを確認します。
本コントロールは AWS Config の rds-cluster-backup-retention-check ルールによる変更検知（change-triggered）型の評価のため、Security Hub への反映には数分〜数十分かかる場合があります。
カスタムコントロールパラメータについて
このコントロールが「合格」と判定する基準となる日数は、minimumBackupRetentionPeriod というパラメータで決まります。デフォルトは 7 日で、7〜35 日の範囲で変更できます。
例えば、「保持期間は 14 日以上を必須にしたい」という場合は、このパラメータを 14 に変更します。すると、バックアップ保持期間が 14 日未満のクラスターが FAILED として検出されるようになります。
最後に
今回は、AWS Security Hub による AWS 環境のセキュリティ状況スコアリングに該当する項目についての修復手順をご紹介しました。
コントロールを修復して、お使いの AWS 環境のセキュリティをパワーアップさせましょう！
