为何SAM模板SQS权限配置与文档不符仍可运行？潜在风险解析

我正在开发一款通过AWS SQS消息队列将文件从SFTP服务器迁移至AWS S3存储桶的应用，当前应用可正常运行，但SAM模板中的权限策略与预期不符。

生产者应用权限配置（template.yaml） #

- Effect: "Allow"
  Action:
    - kms:Encrypt
    - kms:Decrypt
  Resource: "arn:aws:kms:${aws.region}:${aws.account}:key/${kms.key}"
- Effect: "Allow"
  Action:
    - s3:GetObject
    - s3:ListBucket
    - s3:PutObject
  Resource:
    - arn:aws:s3:::${aws.prefix}.${environment}.${functionalArea.lowerCase}.${integrationId.lowerCase}/*
- Effect: "Allow"
  Action:
    - sqs:SendMessage
    - sqs:SendMessageBatch
    - sqs:GetQueueUrl
  Resource: !ImportValue 'lambda-sftp-to-s3:${environment}:SftpToS3QueueArn'

消费者应用权限配置 #

- Effect: "Allow"
  Action:
    - kms:Encrypt
    - kms:Decrypt
    - kms:GenerateDataKey
  Resource: "arn:aws:kms:${aws.region}:${aws.account}:key/${kms.key}"
- Effect: "Allow"
  Action:
    - sqs:GetQueueAttributes
    - sqs:ReceiveMessage
    - sqs:DeleteMessage
    - sqs:GetQueueUrl
  Resource:  !Join [':',['arn:aws:sqs:${aws.region}:${aws.account}',!Ref QueueName]]
- Effect: "Allow"
  Action:
    - s3:GetObject
    - s3:PutObject
  Resource:
    - arn:aws:s3:::esint.${environment}.*
    - arn:aws:s3:::${aws.prefix}.${environment}.*

根据AWS官方文档，生产者应具备kms:GenerateDataKey权限，但当前该权限仅配置在消费者侧。现咨询为何此“反向”配置仍能正常工作，以及该配置存在哪些潜在风险。

为什么当前配置能正常工作？ #

主要有两种可能性：

1. SQS队列未启用服务器端加密（SSE）：如果你的SQS队列没有用KMS密钥加密消息，生产者发送消息时无需调用KMS的GenerateDataKey接口——没有加密操作就不会触发权限校验，自然不会报错。
2. 生产者角色继承了额外KMS权限：生产者的IAM角色可能通过其他渠道获得了kms:GenerateDataKey权限，比如附加的管理型策略、KMS密钥的密钥策略直接授权，或者角色所在的权限边界外的继承权限，只是当前SAM模板里没有显式配置。

潜在风险 #

1. 加密配置变更引发故障：后续如果给SQS队列启用KMS加密（SSE-KMS），生产者因缺少kms:GenerateDataKey权限会立刻触发AccessDenied错误，导致消息无法发送，整个迁移流程中断。
2. 维护成本升高：当前权限逻辑不符合AWS最佳实践与文档规范，后续维护人员接手时容易误解设计逻辑，排查问题会消耗大量时间。
3. 消费者过度授权：消费者实际仅需kms:Decrypt权限（若无需发送加密消息，连kms:Encrypt都多余），额外的kms:GenerateDataKey权限会增加滥用风险——如果角色被攻破，攻击者可生成大量数据密钥，消耗KMS配额或产生不必要的费用。
4. 隐性权限依赖风险：如果生产者的GenerateDataKey权限来自KMS密钥策略而非SAM模板，后续密钥策略被修改时，会直接导致生产者发送消息失败，且这种变更不会在SAM模板中体现，难以提前预警。

内容的提问来源于stack exchange，提问作者pbuchheit