AWS SQS Queue Missing Server-Side Encryption (CKV_AWS_27)

High Risk Infrastructure Security

awssqsencryptiondata-at-restkmsmessage-queuecomplianceterraformcloudformationcheckovckv-aws-27

What it is

A critical security vulnerability where Amazon SQS queues are configured without server-side encryption, leaving sensitive message data unprotected at rest. This security check specifically identifies SQS queues that lack KMS-backed encryption configuration, exposing message contents to unauthorized access if AWS storage systems are compromised. SQS messages often contain authentication tokens, personal information, financial data, or business-critical information that requires encryption protection according to compliance standards.

Language:

# VULNERABLE: SQS queue without encryption (CKV_AWS_27 violation)
resource "aws_sqs_queue" "payment_notifications" {
  name                      = "payment-notifications"
  delay_seconds             = 30
  max_message_size          = 2048
  message_retention_seconds = 86400
  visibility_timeout_seconds = 300
  
  # SECURITY ISSUE: Missing encryption configuration
  # Messages containing payment data stored in plaintext
  
  tags = {
    Environment = "production"
    Service     = "payment-service"
    DataType    = "payment-data"
  }
}

# VULNERABLE: CloudFormation without encryption
Resources:
  PaymentNotificationQueue:
    Type: AWS::SQS::Queue
    Properties:
      QueueName: payment-notifications
      DelaySeconds: 30
      MaxMessageSize: 2048
      MessageRetentionPeriod: 86400
      VisibilityTimeout: 300
      # MISSING: KmsMasterKeyId property
      Tags:
        - Key: Environment
          Value: production
        - Key: Service
          Value: payment-service

# SECURE: SQS queue with AWS managed KMS encryption (CKV_AWS_27 compliant)
resource "aws_sqs_queue" "payment_notifications" {
  name                      = "payment-notifications"
  delay_seconds             = 30
  max_message_size          = 2048
  message_retention_seconds = 86400
  visibility_timeout_seconds = 300
  
  # SECURE: Enable server-side encryption with AWS managed key
  kms_master_key_id                 = "alias/aws/sqs"
  kms_data_key_reuse_period_seconds = 300
  
  tags = {
    Environment = "production"
    Service     = "payment-service"
  }
}

# SECURE: SQS with customer-managed KMS key
resource "aws_kms_key" "sqs_key" {
  description             = "KMS key for SQS encryption"
  enable_key_rotation     = true
}

resource "aws_sqs_queue" "custom_key_queue" {
  name = "custom-encrypted-queue"
  
  # SECURE: Use customer-managed KMS key
  kms_master_key_id = aws_kms_key.sqs_key.arn
  
  tags = {
    Environment = "production"
  }
}

# SECURE: CloudFormation with encryption
Resources:
  PaymentNotificationQueue:
    Type: AWS::SQS::Queue
    Properties:
      QueueName: payment-notifications
      KmsMasterKeyId: alias/aws/sqs
      Tags:
        - Key: Environment
          Value: production

💡 Why This Fix Works

The vulnerable examples show SQS queues created without encryption configuration, violating CKV_AWS_27. The secure implementations demonstrate proper KMS encryption setup using both customer-managed and AWS-managed keys, ensuring payment and sensitive data protection.

ℹ️ Configuration Fix

Configuration changes required - see explanation below.

💡 Explanation

This configuration shows how to integrate Checkov scanning specifically for CKV_AWS_27 in CI/CD pipelines to automatically detect and prevent unencrypted SQS queues from being deployed to production environments.

Why it happens

Amazon SQS queues are created using default settings that do not include server-side encryption. This commonly occurs when developers prioritize rapid deployment over security configuration, or when using basic tutorials and examples that don't include security best practices. The default SQS behavior stores messages in plaintext unless explicitly configured otherwise.

Root causes

Default SQS Configuration Without Encryption

Missing KMS Key Configuration in Infrastructure Code

Infrastructure as Code templates (Terraform, CloudFormation) define SQS queues without specifying the kms_master_key_id or KmsMasterKeyId properties. This results in unencrypted queues even when organizational encryption policies exist. Often occurs when copying starter templates or when security requirements are not communicated to development teams.

Inadequate Security Review Process

Lack of automated security scanning or manual review processes that would catch unencrypted SQS queues before deployment. Organizations may lack the tools or processes to validate that all data storage resources meet encryption requirements, leading to production deployments with unencrypted queues.

Fixes

Enable KMS Server-Side Encryption

Configure server-side encryption using AWS KMS keys by setting the kms_master_key_id parameter in Terraform or KmsMasterKeyId in CloudFormation. Use AWS managed keys (alias/aws/sqs) for simple encryption or customer-managed keys for enhanced control and compliance requirements. This ensures all messages are encrypted at rest.

Implement Encryption Policy Enforcement

Create organizational policies using AWS Config rules, Service Control Policies (SCPs), or tools like Checkov to automatically detect and prevent unencrypted SQS queue creation. Establish security gates in CI/CD pipelines that scan infrastructure code before deployment to ensure all queues have encryption enabled.

Configure KMS Key Management

When using customer-managed KMS keys, enable automatic key rotation and implement least-privilege access policies. Ensure that only necessary services and IAM roles have permissions to use the KMS keys for SQS operations. Document key usage and establish key lifecycle management procedures.

Detect This Vulnerability in Your Code

Sourcery automatically identifies aws sqs queue missing server-side encryption (ckv_aws_27) and many other security issues in your codebase.

Scan Your Code for Free Explore More Vulnerabilities