Azure SQL databases with transparent data encryption turned off
What does ZopNight detect here?
ZopNight flags an Azure SQL database when its transparent data encryption state reads as disabled. Every new Azure SQL database gets service-managed TDE by default, so a finding usually means someone switched it off, the database predates May 2017, or it came from an unencrypted source. Data files, backups and transaction logs then sit unencrypted at rest.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1330 |
| Category | compliance |
| Severity | high |
| Metric | none — pure configuration read |
| Threshold | TDE state = disabled |
| Source | ZopNight |
| Permissions used | Microsoft.Sql/servers/databases/read · Microsoft.Sql/servers/databases/transparentDataEncryption/read |
Where it applies
TDE is on by default, so off is a choice
Transparent data encryption encrypts an Azure SQL database, its backups and its transaction log files at rest, in real time and without application changes. By default the database encryption key is protected by a built-in server certificate and AES 256 is used.
Microsoft states that TDE is enabled by default for all newly deployed Azure SQL databases, while databases created before May 2017 must have it enabled manually. A database without it was switched off deliberately, is one of those older databases, or was created from an unencrypted source: when the source database is not encrypted, restores, geo-replicas and database copies made from it are not encrypted either.
Checking TDE on a database
az sql db tde show --resource-group my-rg --server my-server --database my-dbstate reports Enabled or Disabled. Repeat per database; TDE is set at database level even
though the key protector is set on the server.
A per-database state decides it
ZopNight reads the TDE state Azure reports for each database and fires when it is explicitly disabled. The key type does not matter to this check: service-managed and customer-managed keys both count as encrypted. There is no metric or window.
What does not trigger the finding
When the TDE state was not returned for a database, ZopNight treats it as unknown and stays
silent. Tags claiming encryption are ignored. Encryption of the master database is out of
scope for TDE itself; Microsoft notes TDE cannot encrypt system databases, so do not keep
sensitive data there.
Data exposure at rest; no saving
The finding carries no saving. The risk is data readable from storage media or backup files outside the database engine.
Turning TDE back on
- Enable it on the database:
az sql db tde set --resource-group my-rg --server my-server --database my-db --status Enabled. - Watch the encryption scan complete with
az sql db tde show. - If your policy needs customer-held keys, set a Key Vault or Managed HSM key as the TDE protector at server level.
- Find the process that produced the unencrypted database (an import, restore or copy) and fix it so new databases arrive encrypted.