Backup credentials stored separately

Backup credentials stored in the same secrets store as primary credentials collapse the security boundary between your production system and your recovery system. If primary credentials are compromised, the attacker also has the backup credentials — and the backup process may have elevated permissions to access data that the primary application cannot touch. NIST CP-9 requires protecting backup data with the same rigor as the primary system. CWE-522 applies when backup credentials are insufficiently protected. Over-broad backup credentials also create a data exfiltration vector: an attacker with backup access can pull a full database dump without triggering normal access controls.

Store backup credentials in a separate secrets path or vault namespace with explicitly restricted permissions. Backup accounts should have read-only or restore-only access — they must not be able to drop tables, alter schemas, or modify production data.

// Retrieve from separate secrets paths
const primaryDb = await secretsClient.get('prod/primary/db-credentials')
const backupDb  = await secretsClient.get('prod/backup/db-credentials')  // separate path

// AWS IAM: backup role policy (restore-only)
// Allow: rds:RestoreDBInstanceFromDBSnapshot
// Allow: rds:DescribeDBSnapshots
// Deny: rds:DeleteDBInstance, rds:ModifyDBInstance

Document which team members have access to backup credentials separately from who has access to primary credentials. Audit access quarterly and revoke permissions for anyone not actively responsible for disaster recovery.