Which solution will meet these requirements?
Locate the compromised IAM access key and deactivate or delete the key. Generate new access keys for the Lambda deployment process. Apply the new keys to the deployment system. In the account that contained the compromised key, create a new support case in AWS Support to detail these remediation steps.
Delete or deactivate the compromised IAM access key. Discontinue the use of IAM access keys. Create a new IAM role for the Lambda deployment process. Apply the IAM role to the deployment system Lambda functions. Respond directly to the abuse report message to detail these remediation steps.
Locate the compromised IAM access key. Delete the IAM user that is associated with the access key. Generate a new access key. Store the new key as an AWS Secrets Manager secret. Encrypt the secret with an AWS Key Management Service (AWS KMS) customer managed key. Update the Lambda functions to retrieve the access key from AWS Secrets Manager at runtime. In the account that contained the compromised key, create a new support case in AWS Support to detail these remediation steps.
Delete or deactivate the compromised IAM access key. Generate and store a new access key as an environmental variable within the configuration of the deployment system’s Lambda functions. Respond directly to the abuse report message to detail these remediation steps.
Explanations:
While deactivating the key and generating a new one is necessary, creating a support case and applying new keys to the system without addressing security best practices (e.g., using IAM roles instead of access keys) is inadequate for long-term security.
This option deactivates the compromised key and eliminates the use of IAM access keys by replacing them with an IAM role for Lambda, which is a security best practice for service-to-service communication. Responding to the abuse report is appropriate.
Deleting the IAM user and using AWS Secrets Manager to store the key introduces unnecessary complexity. Storing access keys in Secrets Manager, while secure, is less optimal than using an IAM role, which provides better security for Lambda functions.
Storing the new access key as an environment variable within the Lambda functions is insecure as it exposes the key within the Lambda configuration. It is better to use IAM roles for such tasks to avoid manual key management.
I rank that the answer is:
Delete or deactivate the compromised IAM access key. Discontinue the use of IAM access keys. Create a new IAM role for the Lambda deployment process. Apply the IAM role to the deployment system Lambda functions. Respond directly to the abuse report message to detail these remediation steps.