February 28, 2012 at 11:12 am
Members,
We have a web application that is starting to grab hold in our niche market. Currently, we use stored procedures exclusively for all of our CURD operations. We also use stored procedures for picking out records based on tolerances and other criterium that are then displayed to the user for further processing. It's this part of our application that is very sensitive and is the key to our application.
We are starting to become a little concerned as these stored procedures, as well as the others, can be copied by a malicious DBA and reverse engineered. Since there is no way to really encrypt or protect the stored procedures, we can only really see two options to protect our intellectual property: 1) Rewrite the processing procedures to CLR stored procedures, or, 2) Move the processing to the application layer. Both of these have their drawbacks, the latter being that we would be looping through a boatload of records multiple times.
We are looking at upwards to maybe 1 million records on the high end to search through and process. I'm sure I'm not the only one who has run across this dilemma, and I was hoping that someone could give me an idea as to what any other options are, what your recommendations would be, and what others have done.
Thank you in advance,
Jim
February 28, 2012 at 11:32 am
Moving logic in CLR or application won't protect the code, that can always be disassembled and reverse-engineered.
Personally, I would try to avoid the "security by obscurity" approach and I would focus on the few things that make sense.
The first one is protecting the database from unauthorized access. When you know exactly the people that have administrative rights on the database, you know who to blame when there's a leak. This prevents people from disclosing things they shouldn't disclose.
-- Gianluca Sartori
February 28, 2012 at 11:52 am
Well if it's a web application then you are hosting the database, so you can lock the security down to only your internal staff who, I assume, you trust (if you don't trust your internal staff, why are they still staff?)
CLR can be trivially decompiled, so that's no protection. Application code can be stolen easier than database code if you have secured the database
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
February 28, 2012 at 12:21 pm
At some level there has to be at the very least one or two people that have access to the code. It sounds like ultra paranoia to me that you want to prevent your own dba's from the code they have to support. I agree with Gail that if you can't trust your own employees, you should find one you can trust. There is also nothing wrong with having your own employees sign an NDA to protect the company's IP. Lock down access, audit stuff, keep your i's crossed and your t's dotted.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
February 28, 2012 at 12:38 pm
Would you please clarify the scenario you're dealing with:
If it's a web app, you should be the one hosting the database. In that case, the question is: who don't you trust.
Id this app is sold as a stand-alone software and is programmend using any .NET technology, you shouldn't worry about protecting the database stuff alone since the whol app can be reverse-engineered.
Usually, instead of reverse-engineering any source code, the trend is more to copy the process/functionality and writing new code.
Other than that, I completely agree what's been posted before.
February 28, 2012 at 2:57 pm
Yeah, I think I need to clarify a little more, sorry.
We distribute a web application that is installed on a Web server via a MSI. The MSI, creates the SQL logins, database, tables, stored procedures, objects etc. Therefore, we have no control over the employees, and end-user agreements are violated all the time.
Some of these database servers are very poorly managed and instead of locking down databases using the proper access restrictions, some first and second tier database users are just given complete sa permissions where they can go in and do just about anything to any database.
Basically, my concern is someone copying the data structure, logic and writing a front end for it, changing it just enough not to violate copyrights and such. Sure, almost anything can be reverse engineered and the like. I'm just curious as to what others do to protect themselves from this kind of thing such as using CLR stored procedures, moving all processing logic to the business layer, a combination of the two or something else entirely.
Hope this helps.
February 28, 2012 at 3:08 pm
If you distribute the app to some other company, there is nothing you can do to keep them out of the code. You can make it harder, but that's all, and that will just deter the less interested people. Someone wants your code and has admin access to the servers, they can get it.
This problem is solved either by hosting or by legal agreements and lawyers.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
February 28, 2012 at 3:29 pm
That was pretty much my understanding. They are set as administrators, after all. I was just hoping that there is a way to obfuscate those stored procedures. Luckily, the market is pretty small. The more we innovate and improve the product we can better balance the stored procedures logic between the two layers.
Thanks again...
February 28, 2012 at 4:02 pm
Obfuscate yes, but that's all and it won't stop someone who wants your code, and don't think for a second that your app layer is safe if it's also running on their servers
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply