Description
SQS server-side encryption protects message bodies stored in a queue. Disabling it leaves subsequently arriving messages without that protection. For new queues, omitting both KmsMasterKeyId and SqsManagedSseEnabled currently enables SSE-SQS by default, so omission alone does not mean unencrypted storage.
Potential impact
Unencrypted message bodies have less protection if stored data is exposed. Server-side encryption does not prevent authorized message retrieval or correct excessive queue permissions.
Remediation
Set SqsManagedSseEnabled: true for SQS-managed encryption. If KMS key control is required, specify KmsMasterKeyId and grant producers and consumers the necessary key permissions. Changes do not retroactively encrypt existing messages; retain any required old-key permissions and test sending and receiving. Manage TLS and queue access policies separately.
Examples
These excerpts define two distinct queues. Supply a usable KMS key through QueueKeyId.
Before
Resources:
MyQueue:
Type: AWS::SQS::Queue
Properties:
QueueName: SampleQueue
MyQueue2:
Type: AWS::SQS::Queue
Properties:
QueueName: SampleQueue2
SqsManagedSseEnabled: false
MyQueue uses current default SSE-SQS. MyQueue2 explicitly disables managed encryption and specifies no other encryption key.
After
Resources:
MyQueue:
Type: AWS::SQS::Queue
Properties:
QueueName: SampleQueue
KmsMasterKeyId: !Ref QueueKeyId
MyQueue2:
Type: AWS::SQS::Queue
Properties:
QueueName: SampleQueue2
SqsManagedSseEnabled: true
MyQueue uses the specified KMS key, while MyQueue2 uses SSE-SQS. These settings do not encrypt all metadata, such as message attributes.