Since TDE relies on a certificate stored in master (which is used to encrypt the database encryption key), then this would work only work if you could restore the master database to another server in such a way that the certificate could be decrypted.
This is the TDE encryption hierarchy:
- Service master key (protected by Windows; tied to the service account credentials, and a machine key)
- Database master key (in this case, the one for the master database)
- Certificate
- TDE encryption key
The first three items are stored in the master database, and can all be backed up. The fourth is stored (encrypted by the certificate from #3) in the header of the encrypted database.
So in a failure scenario, you would have to restore enough of the encryption hierarchy to allow you to read the TDE key. SQL Server creates the service master key at installation; thus while restoring the master database to a different instance will also restore items 2 and 3, the necessary key(s) to decrypt them will not be present. Result: unreadable data.
The two best options are to either restore the certificate (#3) from a backup (a good option if master cannot be restored for whatever reason), or restore your master database and its master key (#2) from a backup. Restoring the master key may be a better option if you have a lot of certificates/keys protected by this key, and need to make them all accessible at once. This comes with the same precautions normally associated with restoring the master database (collations, logins, database names and file paths, etc.)
Generally, I'd only recommend restoring master in a recovery scenario. For a migration/scale-out scenario (such as using Availability Groups/mirroring with a TDE-encrypted database), it's better to backup/restore the certificate (#3) so that it's encrypted using the master keys unique to each instance it's moving to. You will need to include the private key with the certificate backup.
In any case, you're going to have to make key/certificate backups, so guard them well, and store them in redundant, secure locations. Simply having a backup of master will not get you out of a TDE disaster; you're going to need a backup of at least one key or certificate.
The files are stored in a blob in the sharepoint database and as TDE encrypts all the pages in the database all the files will be encrypted there within.
It's important to notice that while the database is mounted on the server the database server will serve the files unencrypted to the Sharepoint application server and it's clients.
The Sharepoint binary cache will store them unencrypted as well as all the clients. You are only encrypting the data at rest on the SQL Server when using TDE.
You can add to the security by using encrypted connections to the database server and HTTPS to connect to the Sharepoint application but after the files leave the database storage they will be unencrypted.
Best Answer
TDE encrypts data on disk, and decrypts on the fly when data is accessed from the database.
Introduction to Transparent Data Encryption
What you described is another feature, called Data Redaction.
Introduction to Oracle Data Redaction
Here is an example with steps: https://oracle-base.com/articles/12c/data-redaction-12cr1