mjhjmtu

I have a SQL Server 2016 SP1 with data that I am ready to share with a partner (developer), except for a few columns, example:

email varchar(64) MASKED WITH (FUNCTION = 'email()') NULL

I give the partner the credentials for logging in to the test copy of the database as a certain user, without unmask permission. I understand this is reasonably safe.
Now, we are considering sharing the database backup with our partners, so they can reload in their own server and environment.

I would probably need to have contained users, so that partner cannot create new users or connect them to existing logins (not sure about this).

CREATE USER user_name WITH PASSWORD = 'strong_password';

Is there a way that I can share a database backup, and still trust that the masked columns are safe, or do I have to physically delete the data?

I would probably need to have contained users, so that partner cannot create new users or connect them to existing logins (not sure about this).

If you're sharing the backup, contained database or not, they can do whatever they want with the data. Sysadmins (of which I'm sure they have access to on their servers) can see all of the data.

Is there a way that I can share a database backup, and still trust that the masked columns are safe, or do I have to physically delete the data?

Delete the data, then cycle through the transaction log multiple times taking backups and re-using VLFs by inserting dummy data (that way they can't mine the log) or better yet, create a schema only copy of the database and insert only the data needed. Note that you can still mine information from statistics, I wouldn't script those if I were making a copy to send and wanted it to be secure.

Another option would be to restore the backup to a staging area and encrypt the data in sensitive columns using some form of encryption (column, AE, etc.). Drop the requisite keys before sending the database. This way they won't have the keys to decrypt the data, but it's still there. This may be acceptable if you didn't want to do any of the other above options.

No, I'm sorry. Your partner has a sysadmin login for their SQL Server, and a sysadmin can do everything with everything inside a SQL Server instance - including the databases.

I suggest that you develop a routine to clear out the sensitive data. I.e., perform the backup. Restore it to a different database name, clean it. And now produce a new backup.