Resources in your AWS Account could still be unencrypted at rest. While AWS has been making it easier to ensure all resources are encrypted such as newer services without support for unencrypted resources (such as Amazon Aurora DSQL) and adding encryption by default for AWS S3, there are still resources that can be unencrypted.

We found 15 AWS Services still have support for unencrypted resources. For more research and conversations about cloud encryption and data perimeters, reach out to us at info@fogsecurity.io.

Background

In our research from July 2024 on encrypted or unencrypted by default, we found that out of 43 AWS services and 51 different types of resources, 23.53% (12 resources) were unencrypted by default. We decided to take our research one step further to find out which AWS resources and services still have no encryption as an option.

Keep in mind that unencrypted resources created prior to default encryption changes in other services such as S3 can still be unencrypted.

AWS Services with Unencrypted Options

Out of those prioritized 43 AWS services which include compute, database, storage, AI and machine learning, and management services, we found:

The following 15 AWS services have an unencrypted option:

• Amazon Relational Database Service (RDS)
• Amazon Elastic File System (EFS)
• Amazon Redshift
• Amazon Elasticache
• Amazon Aurora
• Amazon Neptune
• AWS Systems Manager Parameter Store
• Amazon Elastic Block Store (EBS)
• Amazon Simple Notification Service (SNS)
• Amazon Simple Queue Service (SQS)
• AWS Glue
• Amazon Kinesis
• Amazon Comprehend
• Amazon OpenSearch
• Amazon DynamoDB Accelerator (DAX)

Methodology

Determining if resources can be unencrypted is not straightforward in AWS. For our research we used either of the following approaches (or both):

• AWS Documentation

• AWS CLI/API calls to validate encryption options on resources

Note: in some cases when polling AWS APIs for encryption state, results may not be logical.  For example, we discovered that for Amazon QLDB, an undefined response for the encryption description when describing a ledger returns undefined when the ledger uses an AWS owned key, AWS has since updated their documentation after we reported this inconsistency.

Observations

• Services with unencrypted options tend to be those without support for AWS Owned Keys. However, there are services that both support AWS Owned Keys and unencrypted data such as Amazon SQS.

• Encryption options also are predicated on AWS's architecture. Certain AWS services share architecture (or are built on top of other services).  For example, Amazon Neptune shares operational technology with Amazon RDS and both database services support unencrypted resources.

• In certain cases, resources that were not encrypted prior to changes with default encryption may still be unencrypted. If you have examples, let us know at info@fogsecurity.io.

• Out of the 15 AWS services and resources that can be unencrypted, 10 of them had resources that by default are created unencrypted. Keep in mind these may change depending on whether resources are created via API/CLI or via AWS's management console.

Recommendations

As encryption can be a core component of data security, we recommend the following:

• Enforce encryption via account settings and security controls

An example of how to enforce encryption via preventative controls such as Resource Control Policies can be found on our research on creating data perimeters with RCPs and AWS KMS and is shown below. Other security controls such as Infrastructure-as-code linters or security tools to scan for configuration can also be used.  Additionally, account settings such as EBS encryption by default can be used to always encrypt new EBS volumes.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EnforceKMSEncryption",
            "Effect": "Deny",
            "Principal": "*",
            "Action": [
            	"s3:PutObject",
                "s3:ReplicateObject"
                ],
            "Resource": "*",
            "Condition": {
                "Null": {
                    "s3:x-amz-server-side-encryption-aws-kms-key-id": "true"
                }
            }
        }
    ]
}

‍

• Encrypt existing unencrypted resources

While enforcing encryption via account settings and security controls will ensure new resources are encrypted, this does not change existing unencrypted resources. In AWS, certain resources can have encrypted updated in place without recreating the resource. Other cases, the resource must be recreated. In previous research over 45 AWS services, we found 24 resources across 18 services (36.92%) have support for updating encryption while 41 resources across 27 services (63.08%) need to be recreated.

More information can be found in our research on protecting data and preventing ransomware by managing and updating encryption for AWS resources. This research includes the IAM permissions and API actions necessary to update encryption.

‍

• Define encryption guidelines

We recommend setting encryption guidelines for your organization.  These can include guidelines such as:

• Types of acceptable encryption keys (AWS Owned, AWS Managed, CMKs)
• Required Key policy components for CMKs
  • This could include guidelines for cross-account usage, how delegation is managed.
• Setting encryption (KMS) guardrails such as leveraging RCPs for data perimeters.  When using KMS for encrypting AWS resources, you can take advantage of using RCPs to create a data perimeter - even if the underlying AWS service is not supported by RCPs yet. RCPs today only support S3, STS, KMS, SQS, and Secrets Manager. By using KMS and RCPs, we can create an identity perimeter to services and data stored in services such as DynamoDB, EBS, EFS, and more. An example from our previous research on creating multi-layer data access guardrails within an organization to help with zones of trust (such as preventing environment cross over from development to production) is as follows:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EnforceEncryptionReadPerimeter",
            "Effect": "Deny",
            "Principal": "*",
            "Action": [
                "kms:Decrypt"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEqualsIfExists": {
                    "aws:PrincipalOrgPaths": [
                      	"<ProductionOrgPath1>",
                        "<ProductionOrgPath2>"
                    ]
                },
                "BoolIfExists": {
                    "aws:PrincipalIsAWSService": "false"
                }
            }
        },
        {
            "Sid": "EnforceProductionConfusedDeputyProtection",
            "Effect": "Deny",
            "Principal": "*",
            "Action": [
                "kms:Decrypt"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEqualsIfExists": {
                    "aws:SourceOrgPaths": [
                        "<ProductionOrgPath1>",
                        "<ProductionOrgPath2>"
                    ]
                },
                "Null": {
          			"aws:SourceAccount": "false"
        		},
                "Bool": {
                    "aws:PrincipalIsAWSService": "true"
                }
            }
        }
    ]
}

‍

Conclusion

Encryption can be a useful tool for data perimeters and cloud data security. When cloud encryption is used correctly, it can function as another layer of access control and can help with creating multi-layered data perimeters. We can be reached at info@fogsecurity.io to talk more about data perimeters and cloud encryption.