The Misleading Encryption State of Amazon Quantum Ledger Database (QLDB)
The Misleading Encryption State of Amazon Quantum Ledger Database (QLDB)
When doing research on one of Amazon Web Services's newer database offerings, Amazon Quantum Ledger Database, we discovered inconsistent and misleading encryption status reported via AWS APIs and the CLI for Amazon QLDB.
The encryption status for Amazon QLDB that was returned via the DescribeLedger calls could be misleading for compliance and security reasons. Accurate security depends on accurate reporting and visibility into configuration and state of data resources. In the case of Amazon QLDB and data security, misleading encryption status could lead to false positives and AWS customers believing their QLDB Ledgers to be unencrypted when in fact their Ledgers are encrypted.
The short summary:
- EncryptionStatus is undefined when QLDB is encrypted with an AWS owned KMS Key. This is currently undocumented.
- When Encryption is being updated, the "LedgerEncryptionDescription" will return "AWS_OWNED_KMS_KEY" for "KmsKeyArn" which is undocumented. the "AWS_OWNED_KMS_KEY" value will only return when the Ledger is updating and will not show otherwise. This is also currently undocumented.
We reported this to AWS Security in February 2024 and they're working on a documentation update.
Update: As of February 26th, 2024, AWS has completed their updates to the Amazon QLDB Developer Guide Documentation with our recommended clarifications. Thanks to the AWS team for the quick responses and collaboration.
Finding
When using the CLI or Amazon APIs to describe QLDB Ledgers and their encryption configuration, we observed the 2 following scenarios:
- EncryptionStatus is undefined and can be misleading when the QLDB is encrypted with an AWS owned KMS Key. This is in addition to the KmsKeyArn parameter being undefined (which is documented). One of the possible values for EncryptionStatus is "Enabled" which could to some be the proper value for any encrypted Ledger and not just ledgers encrypted with customer-managed KMS keys.
- When updating the EncryptionStatus of a Ledger from a Customer managed key to an AWS Owned Key, the "LedgerEncryptionDescription" object instead of returning null will return "KmsKeyArn": "AWS_OWNED_KMS_KEY" and "EncryptionStatus": "UPDATING":
Both of these are misleading for the following reasons:
- "KmsKeyArn" is stated to only return the ARN of the customer managed KMS Key or can be undefined (to specify an AWS owned KMS Key for encryption). The value "AWS_OWNED_KMS_KEY" is neither undefined nor an ARN of a customer managed KMS Key.
- If a security team or customer were to use EncryptionStatus for determining state and security posture, the lack of an "Enabled" Response may lead to the security team or customer incorrectly thinking their Ledger is unencrypted and insecure.
Walkthrough
Amazon Quantum Ledger Database (Amazon QLDB) is a fully managed ledger database provided by AWS. All data stored in Amazon QLDB is fully encrypted at rest by default using encryption keys in AWS Key Management Service (KMS). QLDB permits use of either an AWS owned key or a customer managed key.
Note: Amazon QLDB launched support for customer managed AWS Keys in July of 2021. Ledgers created prior to that date are protected by AWS owned keys by default.
With Amazon QLDB, the only way to retrieve encryption information about a QLDB Ledger is the `DescribeLedger` API call. This returns a LedgerEncryptionDescription Object including the "current status, the AWS KMS Key, and when the key became inaccessible (in the case of an error)".
To check encryption status, we first create a QLDB Ledger. This can be done either via AWS Console or programmatically. In this case, we create it programmatically via the AWS CLI:
Note that a ledger encrypted with an AWS Owned KMS Key can be created 2 ways: with the --kms-key value set to AWS_OWNED_KMS_KEY or left as undefined. By default, the creation of a ledger will use an Amazon Web Services owned KMS key.
Now, when we describe this ledger (and tested with both creation options of having a --kms-key value set to AWS_OWNED_KMS_KEY as well as undefined), we get the following:
Note in both these responses, there is no response for EncryptionDescription and the included fields: EncryptionStatus and KmsKeyArn. Those fields exist when describing a QLDB with a customer managed AWS Key.
Let's now update QLDB's encryption from a customer managed AWS Key to a AWS-owned KMS key. This can be done with the UpdateLedger API call. Describing a Ledger in the process of updating Encryption Status results in the following:
The "AWS_OWNED_KMS_KEY" is inconsistent and undocumented for the specific DescribeLedger CLI response.
We have shown the following 2 undocumented observations regarding encryption state of QLDB Ledgers:
- EncryptionStatus is undefined and can be misleading when the QLDB is encrypted with an AWS owned KMS Key.
- When updating the EncryptionStatus of a Ledger from a Customer managed key to an AWS Owned Key, the "LedgerEncryptionDescription" object instead of returning null will return "KmsKeyArn": "AWS_OWNED_KMS_KEY" and "EncryptionStatus": "UPDATING".
Conclusion
We are always looking to provide clarity on cloud data security and proper data asset management. The following steps can be taken to improve security.
- Improve accuracy of security reporting by ensuring security and compliance tools are not reporting false positives with QLDB for encryption at rest requirements. This can help reduce alert fatigue and build more trust in security.
- Validate proper usage of KMS keys and usage of AWS owned keys and customer managed keys. Customer managed keys and AWS owned keys have differences between them such as the ability to manage KMS keys and key policies for access and other differences that may influence desired usage or required usage for compliance.
If you have comments or questions about cloud data security, we're here to help. Reach out to our team!
AWS's Updated Documentation
Below are screenshot's of AWS's updated documentation with the clarifications for the above findings. Clarifications are highlighted in red.
