4

I want to give my database to the client to install on their server.

However, I want to deny the client rights to see the tables and stored procedures and also want to restrict that database to run from a single IP address.

How do I stop the user viewing the database tables even though database is present on their server?

We want to give the application to run on their own servers, but we don't want to show the tables and stored procedures. They are also not supposed to make any modifications to the database. Is this possible?

Perhaps can we encrypt database credentials in the web.config file?

  • 1
    Stored Procedures, Views and UDFs can be encrypted with WITH ENCRYPTION. It's not impossible to decrypt if you research examples, but it's not a straightforward task. – Mark Sinkinson Feb 12 '15 at 11:53
  • 3
    You are trying to solve a contractual problem with a technical solution. There are few easy ways to do this. I would recommend that you add provisions to your support contract that cover 1) them not sharing or re-distributing your intellectual property and 2) that any modification of the database or interactions except through the application void any support. – Jonathan Fite Apr 19 '16 at 12:42
3

Short Answer: you can't.

If the database is being run on the customer's infrastructure, then the customer must have control over their own infrastructure. Without it, they cannot operate.

If you really don't want them to have that control, then you cannot give them the database. This is the "Software-as-a-Service" Operating Model wherein you licence the application but don't get to play with the "back-end" of things.

I would suggest that this is not a Technical problem. It's a Licencing one.

I assume that the licence agreement for your software includes a provision that prevents any Customer from "Reverse Engineering" any part of your product. That clause should be extended to include your database.

Any "mucking about" with the database should invalidate [at least] your support agreement with that Customer. If they want to take that Risk, well, that's up to them.

0

Unless you control login privileges, you will not able to restrict them. So think like you have granted them only basic SELECT to see the table data. since you are not maintaining server, they can easily get admin privelages.maintenance stuff still should be taken by client and once backups are taken they can see schema, sp..

One way I can think of is enable auditing and log to with some drawbacks. whole point boils down to trust. We administer a 3rd party database around 600GB in size. Vendor made it clear, any changes should be done through us and support terms won't be applicable for things not done through us which causes app down. Since they have schema, they can easily compare it with changed ones.

-3

Every database user belongs to the public database role. When a user has not been granted or denied specific permissions on a securable object, the user inherits the permissions granted to public on that object.

Therefore unless until you can grant any permission to users for their login they wont be able to access tables, however can only see the databases listed on the server:

You just need to make sure, role assigned should be PUBLIC on the user mapping option of Login properties dialog box for the selected databases.

  • 6
    Useless unless the customer has no SA access to the server - because if he has, he just goes in and assigns the rights he needs. – TomTom Feb 12 '15 at 11:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.