Whenever you run
BACKUP CERTIFICATE or
BACKUP MASTER KEY, SQL Server will modify the Access Control List (ACL) on each resulting filesystem file it creates1 so that no-one other than the following Windows principals have access to the file:
- OWNER_RIGHTS has Full Control. OWNER_RIGHTS is a well-known security identifier,
S-1-3-4 that represents the current owner of the object. When an Access Control Entry that carries this SID is applied to an object, the system ignores the implicit READ_CONTROL and WRITE_DAC permissions for the object owner.
- Members of the local "Administrators" group have Full Control
- The Virtual Account or Managed Service Account used to run SQL Server has Full Control. Note this is not the SQL Server Service Account you configure in SQL Server Configuration Manager. For a default SQL Server instance, the account is typically
NT SERVICE\MSSQLSERVER. For a named instance, the account is named
- Inheritance is removed from the object's ACL to prevent access by any other principal.
This behavior is by design, and is an attempt to limit access to the resulting certificate and its private key. Allowing "everyone" to access the certificate and private key files allows everyone to restore a backup of the TDE encrypted database onto the server of their choice, and be able to view all the encrypted data as if it was not encrypted. What you're proposing to do seems like a very bad idea to me since it essentially circumvents the encryption.
See my blog post for more details, and example code.
1 - assuming the SQL Server Service has "full control" rights to the target folder in the backup statement.