Creation of new AWS Bedrock long term access key with no expiration date
Cette page n'est pas encore disponible en français, sa traduction est en cours.
Si vous avez des questions ou des retours sur notre projet de traduction actuel,
n'hésitez pas à nous contacter.
Goal
Detects when a long term API key for AWS Bedrock is created without an expiration date
Strategy
This rule monitors CloudTrail and detects when any @eventName has a value of CreateServiceSpecificCredential, @responseElements.serviceSpecificCredential.serviceName:bedrock.amazonaws.com has a value of bedrock.amazonaws.com, and the expiration date begins with 21 (indicating an expiration date 100 years in the future). Long term access keys are vulnerable to compromise by infostealers and credential leaks, and a lack of an expiration date significantly increases the change of compromise.
Triage & Response
- Determine if the user
{{@userIdentity.arn}} intended to generate a Bedrock token with no expiration date. - If
{{@userIdentity.arn}} didn’t intend to generate the Bedrock token with no expiration date or the token is not compliant with your organization’s policies:- Delete the token
{{@responseElements.serviceSpecificCredential.serviceSpecificCredentialId}} by calling DeleteServiceSpecificCredential or deactivate it using UpdateServiceSpecificCredential
- Investigate calls made by the key’s associated IAM User
{{@responseElements.serviceSpecificCredential.userName}} for signs of malicious activity. - Begin your organization’s incident response process and investigate.
- Consider creating an IAM policy condition with the condition
iam:ServiceSpecificCredentialAgeDays to require expiration dates. - Consider the usage of temporary credentials over long-lived credentials associated with IAM users.
