AWS securityagent documentation change
Summary
Updated documentation for AWS Security Agent's customer-managed keys feature to include Secrets Manager secrets as a supported resource, added clarification about encryption context format for integrations, refined descriptions of KMS access identities (changing 'IAM credentials' to 'administrator role'), added a note about service-created resources (CloudWatch Logs log groups and Secrets Manager secrets), and updated policy requirement explanations to cover resources created by the service.
Security assessment
The changes enhance documentation for a security feature (encryption with customer-managed keys) by expanding the list of supported resources and clarifying access patterns. There is no evidence of addressing a specific security vulnerability, incident, or weakness. The updates are routine documentation improvements for feature completeness and clarity.
Diff
diff --git a/securityagent/latest/userguide/customer-managed-keys.md b/securityagent/latest/userguide/customer-managed-keys.md index 58f055c11..3ce87d0bc 100644 --- a//securityagent/latest/userguide/customer-managed-keys.md +++ b//securityagent/latest/userguide/customer-managed-keys.md @@ -13 +13 @@ By default, AWS Security Agent encrypts all data at rest using AWS-managed encry -AWS Security Agent supports resource-level customer managed keys. When you create a top-level resource such as an Agent Space or integration, you can specify a KMS key to encrypt all data belonging to that resource and its subresources. For example, specifying a customer managed key when creating an Agent Space encrypts all data associated with that Agent Space, including Agent Space configurations, penetration test configurations, jobs, and execution details, security findings, discovered endpoints, and screenshots. You can also provide AWS resources that are already encrypted with your own customer managed key, such as S3 buckets or CloudWatch Logs log groups. For the required KMS permissions, see Required KMS permissions. +AWS Security Agent supports resource-level customer managed keys. When you create a top-level resource such as an Agent Space or integration, you can specify a KMS key to encrypt all data belonging to that resource and its subresources. For example, specifying a customer managed key when creating an Agent Space encrypts all data associated with that Agent Space, including Agent Space configurations, penetration test configurations, jobs, and execution details, security findings, discovered endpoints, and screenshots. You can also provide AWS resources that are already encrypted with your own customer managed key, such as S3 buckets, CloudWatch Logs log groups, or Secrets Manager secrets. For the required KMS permissions, see Required KMS permissions. @@ -33,0 +34,4 @@ The encryption context key follows the format `aws:securityagent:_<resource-type +###### Note + +For integrations, the encryption context key includes the `aws-crypto-ec:` prefix, resulting in the format `aws-crypto-ec:aws:securityagent:integration`. + @@ -82 +86,3 @@ AWS Security Agent accesses your KMS key using different identities depending on - * **AWS Management Console operations** – When administrators create or manage resources in the AWS Console (for example, creating an Agent Space or updating an application), the service uses your IAM credentials to call AWS KMS. + * **AWS Management Console operations** – When administrators create or manage resources in the AWS Management Console (for example, creating an Agent Space or updating an application), the service uses the administrator role to call AWS KMS. + + * **Web application operations** – When IAM Identity Center users access data through the AWS Security Agent web application (for example, viewing penetration test results or starting a penetration test), the service uses the application role created during AWS Security Agent setup to call AWS KMS. @@ -84 +90 @@ AWS Security Agent accesses your KMS key using different identities depending on - * **Web application operations** – When users access data through the AWS Security Agent web application (for example, viewing penetration test results or starting a penetration test), the service uses the application role created during AWS Security Agent setup to call AWS KMS. + * **Accessing customer-provided resources** – When the service accesses customer-provided AWS resources during penetration testing (such as S3 buckets, CloudWatch Logs log groups, and Secrets Manager secrets), it uses the penetration test service role to call AWS KMS. @@ -294,0 +301,4 @@ If you provide AWS resources encrypted with a customer managed key to AWS Securi +###### Important + +AWS Security Agent may also create CloudWatch Logs log groups and Secrets Manager secrets on your behalf. When configuring your KMS key policy, include the corresponding statements for these service-created resources as well. + @@ -428 +438 @@ Replace the following placeholder values in the policy: - * The `AllowKmsKeyAccessForCloudWatchLogsLogGroups` statement grants the CloudWatch Logs service principal (`logs._us-east-1_.amazonaws.com`) the permissions it requires to encrypt and decrypt log data. For more information, see [Encrypt log data in CloudWatch Logs using AWS KMS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html). + * The `AllowKmsKeyAccessForCloudWatchLogsLogGroups` statement grants the CloudWatch Logs service principal (`logs._us-east-1_.amazonaws.com`) the permissions it requires to encrypt and decrypt log data. This statement is also required if AWS Security Agent creates a log group on your behalf when you don’t provide an existing one. For more information, see [Encrypt log data in CloudWatch Logs using AWS KMS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html). @@ -520 +530 @@ During penetration testing, AWS Security Agent assumes the penetration test serv - * **CloudWatch Logs log groups** – If the CloudWatch Logs log group used for storing penetration test execution logs is encrypted with a customer managed key, the service role needs `kms:DescribeKey` permission to validate the key. The CloudWatch Logs service principal handles the actual encryption and decryption of log data, and those permissions are granted through the key policy (see Key policy). For more information about encrypting log data, see [Encrypt log data in CloudWatch Logs using AWS KMS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html). + * **CloudWatch Logs log groups** – If the CloudWatch Logs log group used for storing penetration test execution logs is encrypted with a customer managed key (including log groups created by AWS Security Agent on your behalf), the service role needs `kms:DescribeKey` permission to validate the key. The CloudWatch Logs service principal handles the actual encryption and decryption of log data, and those permissions are granted through the key policy (see Key policy). For more information about encrypting log data, see [Encrypt log data in CloudWatch Logs using AWS KMS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html). @@ -611 +621 @@ Replace the following placeholder values in the policy: - * The `AllowKmsKeyValidationForCloudWatchLogsLogGroups` statement is required only if your CloudWatch Logs log group is encrypted with a customer managed key. Update the `Resource` ARN to match the KMS key used to encrypt your log group. + * The `AllowKmsKeyValidationForCloudWatchLogsLogGroups` statement is required only if your CloudWatch Logs log group is encrypted with a customer managed key, including log groups created by AWS Security Agent on your behalf. Update the `Resource` ARN to match the KMS key used to encrypt your log group.