SQL TDE and Certificate Handling Recommendations

Question

I've seen the information on this post: But I don't think it answers this particular question/concern:

I have multiple SQL servers with multiple databases. We want to use TDE on a few of them.

Should I use one certificate for all TDE use, or one certificate for each database? Or maybe another way? What would be the reasons for choosing one over the other?

If using one cert for all databases, if the cert is 'compromised' then all databases that use it could be decrypted by an attacker? And if we use one certificate per database, would that gives us a level of isolation?

Answer 1

I just have in the back of my mind, that if using one cert for all databases, that if the cert is 'compromised' then all databases that use it could be decrypted by an attacker?

I assume that (compromised means), when "someone can steal database files .mdf and .ldf or backups and TDE Certificate along with it's Private key and could know the Password that been used to encrypt Certificate backup". Do you think that can happen?

My question is, should I use one certificate for all TDE use, or one certificate for each database?

I don't think that having multiple certificate per each database can prevent it (above mentioned scenario). Because, there is possibility that someone who can steal one certificate can also steal multiple certificates.

Answer (in my opinion)

However, in my opinion, database encryption alone cannot be full solution on security, you could also consider following:

• Infra level: Building strong firewall around the database servers
• OS level: Avoiding multiple users as builtin\administrators in database servers etc..

Also, the physical security (which is out of scope technical scope)

I believe, if you could implement TDE as per Standard TDE Architecture, would be fine and focus on surrounding security hiccups that may arise (as mentioned above).

...

Edit Post:

How strong your password (Source)?

---

To check the strength of your passwords and know whether they're inside the popular rainbow tables, you can convert your passwords to MD5 hashes on a MD5 hash generator, then decrypt your passwords by submitting these hashes to an online MD5 decryption service.

For instance, your password is 0123456789A, using the brute-force method, it may take a computer almost one year to crack your password, but if you decrypt it by submitting its MD5 hash C8E7279CD035B23BB9C0F1F954DFF5B3 to a MD5 decryption website, how long will it take to crack it? You can perform the test yourself.

Answer 2

Personally, I'd generate a unique certificate for each database encrypted with TDE. Having a single certificate for all your TDE-encrypted databases means any leak of the certificate would allow an attacker to easily decrypt every database they can locate.

If you have one cert-per-database, any leaked certificate can only be used to decrypt that individual database. An attacker would need both the particular database and the certificate for that database.

Security is about defense-in-depth. Obviously you need to protect the certificates for TDE-encrypted databases; having one cert-per-database allows you to build a layered approach to certificate storage. Store certificates for highly-sensitive databases separately from databases that are less sensitive.

Having a certificate-per-database also means you can renew individual certificates as needed. For instance, if you suspect a certificate has been compromised, you can issue a new certificate for the database affected, re-encrypt the database using the new certificate, and not worry about all the other databases.