December 21, 2010 at 1:01 am
The question is quite simple.
We got a report with code behind, we deploy this to a server of one of our customers.
The server admin of our customer recovers the rdl file,
How can we prevent the admin of our customer to make changes to the report.
December 21, 2010 at 8:08 am
There's no easy solution to this currently, other than to make certain the Admin doesn't have the ability to do this, but that could be a large undertaking in itself...
Here's a connect item that you can vote for if you see this as an issue. I would have the same question however as the MS representative that replied to the connect item...
"What are you trying to protect?" Is it custom code? Then use a .DLL, if it's the SQL Query use an encrypted stored procedure (which I'd also advise against). If it's the layout... The layout is right there in front of them when they run the report and should be easily re-creatable.
-Luke.
December 21, 2010 at 8:22 am
From what I've been told we want to protect the code behind, parameters and if possible the layout.
But the latter will probably be impossible.
Txn for the answer.
December 21, 2010 at 8:39 am
Resender (12/21/2010)
From what I've been told we want to protect the code behind, parameters and if possible the layout.But the latter will probably be impossible.
Txn for the answer.
And by Code behind you mean what exactly? the contents of the .RDL file? There's really not a lot there that I could see as a IP issue. The only thing might be SQL code int he queries. Use stored procedures and then you don't have to worry about that either.
The parameters? Really? With the exception of hidden parameters which are typically used as a means of modifying the layout at run time, the parameters are again visible when you execute the report. What is a parameter really? A Datatype (which can be gleaned from the prompt), the Prompt (a simple text string that the users need to be able to see to answer the question) and perhaps a list of values to choose from, either typed in by hand or queried from the database.
Again, the layout is visible when the report is run and to a competent developer should be relatively easy to recreate.
If it's because you don't want to support the changes they may make to your report, that's an argument that could be made, but SSRS timestamps the username and date for anytime that changes are made to a report. If you don't support modifications, you'll know when it was changed, who changed it etc. if it wasn't you, provide them with a copy of the original to upload again and be done with it. Your lawyers and SLA are your defense here, not encrypting the .RDL.
-Luke.
December 21, 2010 at 8:47 am
Luke L (12/21/2010)
There's no easy solution to this currently, other than to make certain the Admin doesn't have the ability to do this, but that could be a large undertaking in itself...Here's a connect item that you can vote for if you see this as an issue. I would have the same question however as the MS representative that replied to the connect item...
"What are you trying to protect?" Is it custom code? Then use a .DLL, if it's the SQL Query use an encrypted stored procedure (which I'd also advise against). If it's the layout... The layout is right there in front of them when they run the report and should be easily re-creatable.
-Luke.
I added my vote to it.
I have the same challenge. We are thinking about building a BI suite for an ERP.
Since we are talking about years of dev and testing, we want to make sure someone cannot just go up a copy the work and give it away.
There's also an option to possibly having a license with Dev rights rather than just use. So complete control is really an asset protection on this one.
December 21, 2010 at 9:10 am
Ninja's_RGR'us (12/21/2010)
Luke L (12/21/2010)
There's no easy solution to this currently, other than to make certain the Admin doesn't have the ability to do this, but that could be a large undertaking in itself...Here's a connect item that you can vote for if you see this as an issue. I would have the same question however as the MS representative that replied to the connect item...
"What are you trying to protect?" Is it custom code? Then use a .DLL, if it's the SQL Query use an encrypted stored procedure (which I'd also advise against). If it's the layout... The layout is right there in front of them when they run the report and should be easily re-creatable.
-Luke.
I added my vote to it.
I have the same challenge. We are thinking about building a BI suite for an ERP.
Since we are talking about years of dev and testing, we want to make sure someone cannot just go up a copy the work and give it away.
There's also an option to possibly having a license with Dev rights rather than just use. So complete control is really an asset protection on this one.
Right, but for that instance, you'd have the stored procedures encrypted right(even though it's a huge PITA for those of us that have had to fix vendor supplied encrypted procedures due to poor performance etc.)? you'd have your custom front end compiled ('cause let's face it you wont be doing this with the standard SSRS interface). You could keep your .rdl files with the rest of your application, not deployed on an SSRS server. while I'm not sure how this might scale, they'd be compiled with the rest of your code making them more difficult to alter.
Your upsell becomes the report definitions perhaps in a separate project in the same solution that they'd need to recompile and deploy with your application. but then again I might be completely off base here. Thoughts?
-Luke.
December 21, 2010 at 9:15 am
No, that's the solution I had to come up with.
Make an asp .net report project, compile to dll and only deploy the dll.
As for performance I think I get that one covered.
But then again we were looking at cubes, any way to protect those?
December 21, 2010 at 10:27 am
Ninja's_RGR'us (12/21/2010)
No, that's the solution I had to come up with.Make an asp .net report project, compile to dll and only deploy the dll.
As for performance I think I get that one covered.
But then again we were looking at cubes, any way to protect those?
No idea about cubes, other than to protect them the way you would any other datasource/database, security, principle of least permissions etc... Again it gets kinda tricky because you want the local admin to be able to do normal administrative tasks without shooting you in the foot by changing stuff.
December 21, 2010 at 10:29 am
Luke L (12/21/2010)
Ninja's_RGR'us (12/21/2010)
No, that's the solution I had to come up with.Make an asp .net report project, compile to dll and only deploy the dll.
As for performance I think I get that one covered.
But then again we were looking at cubes, any way to protect those?
No idea about cubes, other than to protect them the way you would any other datasource/database, security, principle of least permissions etc... Again it gets kinda tricky because you want the local admin to be able to do normal administrative tasks without shooting you in the foot by changing stuff.
Exactly my thaughts... I never really ever saw a way to protect from the admins who have access to everything on the server.
Is there any way to encrypt an SSIS package and rebuild the cubes from there?
December 21, 2010 at 10:35 am
Not sure about the package itself, but here's something from MS on Encrypting the data inside the package... Again it talks about giving users the ability to run/open the package, which may impact some of the ways you might want/need to encrypt it.
December 21, 2010 at 10:42 am
Thanks for the link.
But the more I think about it, it's the same as the report. Any half decent dba will be able to reverse engineer the cubes from the dw tables.
So now that's something else to protect too.
It seems like we'll just have to trust the users not to give the system away. And then implement some sort of key validation on our servers to track hacking.
Then there's the issue of another coder just copying our work and claiming it as his own and reselling it. Another issue with not obvious answer...
December 21, 2010 at 10:48 am
Ninja's_RGR'us (12/21/2010)
Thanks for the link.But the more I think about it, it's the same as the report. Any half decent dba will be able to reverse engineer the cubes from the dw tables.
So now that's something else to protect too.
It seems like we'll just have to trust the users not to give the system away. And then implement some sort of key validation on our servers to track hacking.
Then there's the issue of another coder just copying our work and claiming it as his own and reselling it. Another issue with not obvious answer...
do what MS and others are doing. Have a unique instance ID or customer ID or something built into the product that communicates back to your servers. IF all of a sudden you're seeing traffic coming from IPs where it wasn't registered you build some method by notifying the appropriate personnel to take action. Perhaps make it part of the Check for updates process like MS does with windows update. You can run a hacked copy of their software just as long as you never want to apply a hotfix, service pack etc.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply