我以前见过 ACT 的制作者这样做过。他们的产品安装了一个新的 SQL Server Express 实例，并且作为该过程的一部分，他们对该实例的 sa 密码进行了加密。这使得其他人“不可能”使用除了他们的产品和附加工具之外的任何东西连接到数据库。 我不知道他们到底是如何做到这一点的，但也许您可以搜索“加密 sa 密码”或类似的内容并了解如何做到这一点。 由于不敢安装自己的 SQL Server 实例，我不确定您将如何进行此操作。 请记住，您的应用程序将需要提供备份、调整、修改数据库等功能，因为 DBA 无法访问 SQL Server 实例。
I've seen this done before by the makers of ACT. Their product installs a new instance of SQL Server Express and as part of that process they encrypt the sa password for the instance. This makes it 'impossible' for others to connect to the database using anything other than their product and add-on tools. I don't know exactly how they do it, but perhaps you could search for encrypting sa password or something similar and find out how to do it. Shy of installing your own instance of SQL Server I am not sure how you would go about this. Bear in mind that your application will need to then provide the ability to backup, tune, modify, etc the database as the DBA would not have access to the instance of SQL Server.
Incidentally, we threw ACT out once we saw this - I didn't, and still don't, like the idea of a black box running on one of our servers.
In the end, you'll probably find that this added layer of protection (for you, not the client) just isn't worth the aggravation. While you may have proprietary information in the form of the database schema the odds of the client reverse engineering your application and then making their own are slim. Even if they did, it is hard to make good software - they likely wouldn't get it 'right' anyway.
My advice, don't worry about this, focus on making your software great so there is no reason for them to roll their own or look elsewhere.
You cannot limit the rights of an administrator on a server.
The administrator also has access to pretty much all tables that store your encryption keys, so TDE won't work.
If he is a security admin or one of the other roles, that might solve the issue as by default such roles has no permissions on your data.
SQL Administrators normally have these roles to protect your data. They need it. If the data is very sensitive, you need to use alternative means to secure it, such as applying your own encryption before saving the sensitive values. (AES etc.)
发布评论
评论（3）
我以前见过 ACT 的制作者这样做过。他们的产品安装了一个新的 SQL Server Express 实例，并且作为该过程的一部分，他们对该实例的 sa 密码进行了加密。这使得其他人“不可能”使用除了他们的产品和附加工具之外的任何东西连接到数据库。
我不知道他们到底是如何做到这一点的，但也许您可以搜索“加密 sa 密码”或类似的内容并了解如何做到这一点。
由于不敢安装自己的 SQL Server 实例，我不确定您将如何进行此操作。
请记住，您的应用程序将需要提供备份、调整、修改数据库等功能，因为 DBA 无法访问 SQL Server 实例。
顺便说一句，我们一看到这个就抛弃了 ACT - 我不喜欢，现在仍然不喜欢在我们的一台服务器上运行黑匣子的想法。
最后，您可能会发现这种额外的保护层（对您而言，而不是对客户来说）根本不值得烦恼。虽然您可能拥有数据库模式形式的专有信息，但客户对您的应用程序进行逆向工程然后制作自己的应用程序的可能性很小。即使他们这样做了，也很难开发出好的软件——无论如何，他们很可能都不会“正确”地做到这一点。
我的建议是，不要担心这一点，专注于让你的软件变得更好，这样他们就没有理由推出自己的软件或寻找其他地方。
I've seen this done before by the makers of ACT. Their product installs a new instance of SQL Server Express and as part of that process they encrypt the sa password for the instance. This makes it 'impossible' for others to connect to the database using anything other than their product and add-on tools.
I don't know exactly how they do it, but perhaps you could search for encrypting sa password or something similar and find out how to do it.
Shy of installing your own instance of SQL Server I am not sure how you would go about this.
Bear in mind that your application will need to then provide the ability to backup, tune, modify, etc the database as the DBA would not have access to the instance of SQL Server.
Incidentally, we threw ACT out once we saw this - I didn't, and still don't, like the idea of a black box running on one of our servers.
In the end, you'll probably find that this added layer of protection (for you, not the client) just isn't worth the aggravation. While you may have proprietary information in the form of the database schema the odds of the client reverse engineering your application and then making their own are slim. Even if they did, it is hard to make good software - they likely wouldn't get it 'right' anyway.
My advice, don't worry about this, focus on making your software great so there is no reason for them to roll their own or look elsewhere.
简单：不，他是DBA。如果没有使用数据库的能力，他就无法完成他的工作。克服你的反对意见。
Simple: No, he is DBA. He can not do his job without the ability to work with the database. Get over your objections.
您无法限制服务器上管理员的权限。
管理员还可以访问几乎所有存储加密密钥的表，因此 TDE 将不起作用。
如果他是安全管理员或其他角色之一，则可能会解决问题，因为默认情况下此类角色对您的数据没有权限。
SQL 管理员通常具有这些角色来保护您的数据。他们需要它。
如果数据非常敏感，您需要使用替代方法来保护数据，例如在保存敏感值之前应用您自己的加密。 （AES 等）
You cannot limit the rights of an administrator on a server.
The administrator also has access to pretty much all tables that store your encryption keys, so TDE won't work.
If he is a security admin or one of the other roles, that might solve the issue as by default such roles has no permissions on your data.
SQL Administrators normally have these roles to protect your data. They need it.
If the data is very sensitive, you need to use alternative means to secure it, such as applying your own encryption before saving the sensitive values. (AES etc.)