AWS SecretsManager
Best practices and references below are based on published guidance from the cloud service provider and may reference native capabilities the cloud service provider offers. If you are not using the native security capabilities, the same security requirement can be met using other security capabilities your organization utilizes
AWS Security Best Practices
There are a number of security considerations when attempting to secure your Secrets Manager. See below for some key considerations. Refer to oak9's security blueprint for S3 for more details.
Add retries to your application
Your AWS client might see calls to Secrets Manager fail due to rate limiting. When you exceed an API request quota, Secrets Manager throttles the request. To respond, use a backoff and retry strategy
Mitigate the risks of logging and debugging your Lambda function
When you create a Lambda rotation function, be cautious about including debugging or logging statements in your function. These statements can cause information in your function to be written to Amazon CloudWatch, so make sure the log doesn't include any sensitive data from the secret. If you do include these statements in your code for testing and debugging, make sure you remove them before using the code in production. Also remove any logs that include sensitive information collected during development.
Mitigate the risks of using the AWS CLI to store your secrets
When you use the AWS CLI and enter commands in a command shell, there is a risk of the command history being accessed or utilities having access to your command parameters.
Run everything in a VPC
We recommend that you run as much of your infrastructure as possible on private networks that are not accessible from the public internet
Rotate secrets on a schedule
If you don't change your secrets for a long period of time, the secrets become more likely to be compromised. We recommend that you rotate your secrets every 30 days
Monitor your secrets
Monitor your secrets and log any changes to them. You can use the logs if you need to investigate any unexpected usage or change, and then you can roll back unwanted changes. You can also set automated checks for inappropriate usage of secrets and any attempts to delete secrets
Use Secrets Manager to provide credentials to Lambda functions
Use Secrets Manager to securely provide database credentials to Lambda functions without hardcoding the secrets in code or passing them through environmental variables
Design Guidance:
Secret Id | ||
Resource Policy-Statement | ||
Statement-Sid | ||
Statement-Effect | ||
Statement-Action | ||
Statement-Principal | ||
Statement-Resource | ||
Statement-Condition |
Design Guidance:
Secret Id | ||
Hosted Rotation Lambda | ||
Hosted Rotation Lambda-Rotation Type | ||
Hosted Rotation Lambda-Rotation Lambda Name | ||
Hosted Rotation Lambda-Kms Key Arn | ||
Hosted Rotation Lambda-Master Secret Arn | ||
Hosted Rotation Lambda-Master Secret Kms Key Arn | ||
Rotation Lambda Arn | ||
Rotation Rules-Automatically After Days |
Design Guidance:
Hosted Rotation Lambda-VPC Security Group Ids | ||
Hosted Rotation Lambda-VPC Subnet Ids |
Design Guidance:
Kms Key Id |
Generate Secret String | ||
Generate Secret String-Password Length |
Design Guidance:
Tags | ||
Name |
Secret Id | |
Target Type | |
Target Id |
Last modified 6mo ago