What’s the issue?
Transparent Data Encryption (TDE) protects SQL Server databases at rest by encrypting database files, log files, and backups so that the underlying file contents are unreadable without the protecting certificate or key. When TDE is not enabled, the database files and backups are stored in clear form, meaning anyone with file system access to the SQL Server data, log, or backup locations can potentially read the data.This finding identifies one or more databases on the instance that are not currently encrypted with TDE. It is not necessarily a problem, but it is worth noting in case the team is unaware that some databases are unencrypted or has not consciously decided whether TDE is appropriate for them.
The decision to use TDE is usually driven by compliance requirements, the sensitivity of the data, and the threat model for the storage environment.
Why is this a problem?
Without TDE, an attacker who obtains a copy of a database file or a backup file has direct access to the data inside it. This is particularly relevant in environments where backups are stored on shared storage, copied to offsite locations, or transmitted across networks where they could be intercepted.Many compliance frameworks, including PCI DSS, HIPAA, GDPR, and various industry specific regulations, require encryption at rest for sensitive data. An unencrypted database that holds regulated data may violate these requirements directly, even if other security controls are strong.
Encryption decisions are sometimes made inconsistently across an environment. A common pattern is for production databases to be encrypted while development, test, or reporting copies are not, even though those copies often contain the same sensitive data. The unencrypted copies become the weakest link, since attackers will target the easiest path to the data.
Note that TDE is one of several available encryption options and protects only data at rest. It does not encrypt data in motion (which requires TLS for client connections), does not protect against authorized users reading the data through SQL Server, and does not replace column level encryption, Always Encrypted, or application-level encryption for protecting specific sensitive fields from privileged database users.
What should you do about this?
No action is required if the unencrypted state is intentional and the team has consciously decided that TDE is not necessary for these databases. Document the decision and the rationale so the choice is defensible during audits and remains visible to future administrators.If the team has not yet evaluated whether TDE is appropriate, review each unencrypted database against the data it contains, the applicable compliance requirements, and the threat model for the storage and backup environment. Pay particular attention to databases that hold regulated data such as cardholder information, personal health information, or personally identifiable information.
For databases that should be encrypted, plan a TDE rollout that includes creating and backing up the protecting certificate, configuring the database encryption key, enabling encryption with ALTER DATABASE [DatabaseName] SET ENCRYPTION ON;, and verifying progress through sys.dm_database_encryption_keys. Remember that enabling TDE on any user database automatically encrypts tempdb for the entire instance, which has performance and operational implications worth reviewing in advance.
Read more…
Transparent data encryption (TDE) – SQL Server | Microsoft Learn