April 30, 2020 at 12:21 pm
Dear All
In my company using sqlserver Standard edition.As of now we are only maintain all the client database server client premises.but now company will change the business model.they bring partner base sales model.Here after we are not directly contact with clients. We will sell use base licence to Partner. then partner sell to client.
All the clients they need data their on premises.my manager said our database structure not reveal anybody.how to protect database backup and Database structure protection Security.We need to host my application and database client server. Application side no problem we can obfuscation.But database side please share me suggestion? How to protect data model of my database.
April 30, 2020 at 3:25 pm
I'm sorry, but the English here doesn't quite make sense.
I assume you are saying you host all the servers now in your company (on premises). Now you want to have clients host the servers in their data center. How can you protect your database schema?
First, there's no reason do to this. A data schema of tables isn't IP. There just isn't any IP here, no matter what is done. For stored procs/views/functions, you can set them as encrypted (check BOL for the WITH ENCRYPTION) command, but this is trivial to decompile and get the code. You could also move to CLR functions, but these can be decompiled as well.
My view, there isn't any value in trying to protect this from people reading it. You have copyright, but you if you don't have control of the server, you can't protect this.
April 30, 2020 at 7:33 pm
One option that would allow you to continue to control the databases while not presenting it to the client would be to still own the databases. Host them yourselves or in a reliable cloud solution (I recommend a reliable cloud solution over self-hosting as your customers will be much happier knowing that their data is stored in a reliable location). Something like Azure (doesn't need to be Azure).
If the database NEEDS to reside on the client side, then, as Steve Jones said, there is no good way to protect it apart from your copyright and EULA's. Even On-Premise Microsoft tools that use a SQL backend (GP, NAV, AX) don't encrypt all of their stuff. They encrypt the stored procedures, but like Steve Jones said, decrypting those is trivial. And protecting the table structure is impossible.
On the opposite side of the spectrum, we have a service desk system at our work that ONLY creates tables and indexes in the database and all of the logic exists in the code side. This was their way of "hiding" the SQL, but tools like Extended Events or Profiler can pull that data out pretty easily.
They also used no PK's or FK's so if you want to match tables up for getting good joins, you need to do the work yourself. But again, this is not impossible or even that difficult to do by watching how the tool uses the database from XE or Profiler.
As for protecting database backups, you can put passwords on it, but as soon as someone gets appropriate permissions to the SQL Instance, they can make their own unencrypted backup. On top of that, I would let end users do their own backups. When they need to do disaster recovery, you don't want to be getting the 2:00 AM phone call to help them restore the database from backup.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply