What should a database specialist do to mitigate this risk?
Change all the databases to use AWS IAM for authentication and remove all the cleartext passwords in CloudFormation templates.
Use an AWS Secrets Manager resource to generate a random password and reference the secret in the CloudFormation template.
Remove the passwords from the CloudFormation templates so Amazon RDS prompts for the password when the database is being created.
Remove the passwords from the CloudFormation template and store them in a separate file. Replace the passwords by running CloudFormation using a sed command.
Explanations:
While using AWS IAM for authentication is a good security practice, it does not address the immediate issue of cleartext passwords in the CloudFormation templates. This option alone does not provide a way to mitigate the risk associated with the existing templates.
Using AWS Secrets Manager to generate and manage a random password is a best practice for handling sensitive information. It allows for secure storage and retrieval of passwords without exposing them in CloudFormation templates, thus effectively mitigating the security risk.
Removing passwords so that Amazon RDS prompts for them during database creation does not provide a secure method for managing credentials. This approach may lead to human error and does not automate the deployment process securely, making it less reliable.
Storing passwords in a separate file and using a sed command to replace them is not a secure method for managing sensitive information. This approach could still expose passwords if the file is not adequately secured and does not leverage AWS’s secure services for handling credentials.
If I’m not mistaken, the answer is:
Use an AWS Secrets Manager resource to generate a random password and reference the secret in the CloudFormation template.
From my perspective, the answer is:
Use an AWS Secrets Manager resource to generate a random password and reference the secret in the CloudFormation template.