|
sql
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Storing T-SQL code so it can't be read
If you want to create a new database and some T-SQL (stored procedures) on an
external partners SQL Server machine that will be used by Reporting Services RDL files but don't what the external partner to see or change the code what are the options you have for creating this database to meet the privacy considerations I described? add "WITH ENCRYPTION" to your CREATE PROCEDURE statement..
r Show quoteHide quote "Greg Larsen" <gregalar***@removeit.msn.com> wrote in message news:7D4DA201-E843-4BD2-973F-9D5F5CE3284E@microsoft.com... > If you want to create a new database and some T-SQL (stored procedures) on > an > external partners SQL Server machine that will be used by Reporting > Services > RDL files but don't what the external partner to see or change the code > what > are the options you have for creating this database to meet the privacy > considerations I described? Hi Greg
"Greg Larsen" wrote: As you have no control over the actual server then there is a limit to what > If you want to create a new database and some T-SQL (stored procedures) on an > external partners SQL Server machine that will be used by Reporting Services > RDL files but don't what the external partner to see or change the code what > are the options you have for creating this database to meet the privacy > considerations I described? you can do, you may want to read http://blogs.msdn.com/lcris/archive/2006/11/30/who-needs-encryption.aspx John Thanks for your thoughts here.
I suppose if you really want to secure your T-SQL code then you need to place it into a compiled exe. Show quoteHide quote "John Bell" wrote: > Hi Greg > > "Greg Larsen" wrote: > > > If you want to create a new database and some T-SQL (stored procedures) on an > > external partners SQL Server machine that will be used by Reporting Services > > RDL files but don't what the external partner to see or change the code what > > are the options you have for creating this database to meet the privacy > > considerations I described? > > As you have no control over the actual server then there is a limit to what > you can do, you may want to read > http://blogs.msdn.com/lcris/archive/2006/11/30/who-needs-encryption.aspx > > John > I suppose if you really want to secure your T-SQL code then you need to But anyone can use Profiler to catch your code, so you would have the downside of not using stored > place it into a compiled exe. procedures, and it is questionable whether it is better than encrypting your procedures. -- Show quoteHide quoteTibor Karaszi, SQL Server MVP http://www.karaszi.com/sqlserver/default.asp http://sqlblog.com/blogs/tibor_karaszi "Greg Larsen" <gregalar***@removeit.msn.com> wrote in message news:21C5D57E-8F14-42AE-805C-4CDCD1D3D855@microsoft.com... > > Thanks for your thoughts here. > > I suppose if you really want to secure your T-SQL code then you need to > place it into a compiled exe. > > "John Bell" wrote: > >> Hi Greg >> >> "Greg Larsen" wrote: >> >> > If you want to create a new database and some T-SQL (stored procedures) on an >> > external partners SQL Server machine that will be used by Reporting Services >> > RDL files but don't what the external partner to see or change the code what >> > are the options you have for creating this database to meet the privacy >> > considerations I described? >> >> As you have no control over the actual server then there is a limit to what >> you can do, you may want to read >> http://blogs.msdn.com/lcris/archive/2006/11/30/who-needs-encryption.aspx >> >> John >> I suppose if you really want to secure your T-SQL code then you need to I totally agree. But if you can't encrypt, can you still protect your calls >> place it into a compiled exe. > > But anyone can use Profiler to catch your code, so you would have the > downside of not using stored procedures, and it is questionable whether it > is better than encrypting your procedures. from Profiler by embedding sp_password in a comment as part of each batch? > But if you can't encrypt, can you still protect your calls from Profiler by embedding sp_password Nah, no more. As of SQL 2005 (I believe it is, just tested on 2005), Profiler doesn't suppress > in a comment as part of each batch? batches with (commented) sp_password... -- Show quoteHide quoteTibor Karaszi, SQL Server MVP http://www.karaszi.com/sqlserver/default.asp http://sqlblog.com/blogs/tibor_karaszi "Aaron Bertrand [SQL Server MVP]" <ten.xoc@dnartreb.noraa> wrote in message news:ebLHw5SgHHA.4704@TK2MSFTNGP06.phx.gbl... >>> I suppose if you really want to secure your T-SQL code then you need to >>> place it into a compiled exe. >> >> But anyone can use Profiler to catch your code, so you would have the downside of not using >> stored procedures, and it is questionable whether it is better than encrypting your procedures. > > I totally agree. But if you can't encrypt, can you still protect your calls from Profiler by > embedding sp_password in a comment as part of each batch? > Ah, something I hadn't tried in a long time. Thanks Tibor.
Show quoteHide quote > Nah, no more. As of SQL 2005 (I believe it is, just tested on 2005), > Profiler doesn't suppress batches with (commented) sp_password... Yep, another trick we can purge from memory... :-)
-- Show quoteHide quoteTibor Karaszi, SQL Server MVP http://www.karaszi.com/sqlserver/default.asp http://sqlblog.com/blogs/tibor_karaszi "Aaron Bertrand [SQL Server MVP]" <ten.xoc@dnartreb.noraa> wrote in message news:%23KkkwNTgHHA.208@TK2MSFTNGP05.phx.gbl... > Ah, something I hadn't tried in a long time. Thanks Tibor. > > -- > Aaron Bertrand > SQL Server MVP > http://www.sqlblog.com/ > http://www.aspfaq.com/5006 > > > > > >> Nah, no more. As of SQL 2005 (I believe it is, just tested on 2005), Profiler doesn't suppress >> batches with (commented) sp_password... > > "Tibor Karaszi" wrote: Age seems to have set up a sheduled task to do that on mine :(> Yep, another trick we can purge from memory... :-) > John > Age seems to have set up a sheduled task to do that on mine :( I think it is more like FT indexing, crawling constantly and purging stuff. Problem is that I'd like to talk to whoever wrote this routine, as I don't agree with the algorithms used... -- Show quoteHide quoteTibor Karaszi, SQL Server MVP http://www.karaszi.com/sqlserver/default.asp http://www.solidqualitylearning.com/ "John Bell" <jbellnewspo***@hotmail.com> wrote in message news:10E0A0E1-A2B7-4913-849E-02BBAF4ED29B@microsoft.com... > > > "Tibor Karaszi" wrote: > >> Yep, another trick we can purge from memory... :-) >> > > Age seems to have set up a sheduled task to do that on mine :( > > John  
Other interesting topics
Rolling Back from build 3159 to build 3152
can't access server from another PC SQL 2005 Performance One table returns ODBC timeout error Major SQL Server 2k5 x64 configuration problem Change only USER tables to a new user ssrs Can you spot a security problem here with XQuery!?... Problem with TCP connections to SQL 2000 application Best practise on Database security |
|||||||||||||||||||||||
