OK people, here's a challenge for you all. How is file-system level encryption (like BitLocker) less secure than TDE in SQL Server? I can't see any way you can get around BitLocker that you can't get around TDE.
Relevance: this comment chain
Side note #2: FS encryption can often be implemented inside the drive itself (on modern enterprise SSDs) so the overhead is sometimes nil. — CharliefaceNov 23 at 15:47
I wouldn't say it's any more or any less secure without a specific example, but both are not secure if as stated in the comments someone has the admin password
@Charlieface Non-admin login that doesn't have access to SQL Server as a login and can't gain access to SQL Server but can open files.
@SeanGallardy So you gave such user permission to shut down SQL service (otherwise files would be locked) and gave them permission over the Data folder? More fool you. This is a non-default setup.
I'm looking forward to this classic challenge where people provide solutions to the original challenge, and @Charlieface adds rules each time to make them not valid (e.g., "This is a non-default setup").
@SeanGallardy True, still a weird setup, but that doesn't help you for open files. You can't read those unless you close the handles, which you can't do unless you're admin or can shut down the service.
@JoshDarnell I'm talking about a standard installation of SQL Server, with the data files stored in a location set up correctly, with the correct permissions. Obviously if you break recommended guidelines you're going to burn: if you set up a sysadmin and publish the password on Facebook you'd also be broken.
@Charlieface lol I probably have nothing useful to add, other than redundancy with security can only help not hurt, most times. But there's even times when redundancy with security can make things less secure, so 🤷♂️