如何对数据库进行签名？
有没有办法在 SQL 数据库上签名，以便只有特定版本的特定应用程序才能访问该数据库？
我正在使用 sql server 2008。我有一个数据库，我希望通过多种方式对其进行保护。重要的列被加密，应用程序本身被签名和混淆（持有密钥）。
我正在寻找一种方法来阻止应用程序，即使是早期版本，即使持有密钥也无法访问数据库。我想防止有人破解 exe 的情况，破解 exe 会破坏应用程序签名并阻止他访问数据库。
谢谢 阿维
Is there a way to have a signature on a SQL DB so only a specific application with a specific version could access that DB?
I'm using sql server 2008. I have a DB that I wish to protect in several ways. The important columns are encrypted and the application itself is signed and obfuscated (holding the key).
I'm looking for a way to block an application, even an earlier version from accessing the DB even if holding the key. I would like to prevent a case where someone hacked the exe, hacking the exe will break the app signature and will prevent him from accessing the DB.
thanks
Avi
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
要回答您的问题，您必须将签名存储在数据库中，可能存储在它自己的表中。
签名将是经过加盐和加密的软件版本号。
To answer your question, you'd have to store the signature on the database, probably in it's own table.
The signature would be the version number of the software, salted, and encrypted.
这是一款什么样的应用程序？
在 .NET 上，强命名就是为此目的而发明的。还可以在 google 上搜索 SignTool.exe (MSDN)，
否则您需要进行自我验证，
这样的事情是不可逆转的（例如，使用 IDA-Pro 等工具通常可以逆转自打包和自修改代码）。所以如果可以的话，尝试依靠操作系统功能来验证exe
What kind of app is this?
On .NET strong naming was invented for this purpose. Also google for SignTool.exe (MSDN)
Otherwise you'd need to self-verify
Nothing like that is unreversible (e.g. self-packing and self-modifying code is routinely reversed using tools like IDA-Pro). So if you can, try to rely on OS functions to verify the exe
听起来您想签署应用程序，而不是数据库。 SQL Server 无法真正知道它正在对话的应用程序的版本，因为应用程序本身负责告诉 SQL Server 它是什么版本。您实际上将您的应用程序置于“信任边界”之外，但您希望它以可信的方式运行。
对于这样的事情，我建议改用三层解决方案。创建一个可信的中间层，用于与应用程序对话 WCF 或 Web 服务。希望这个中间层是您可以控制和信任的。然后，中间层可以对客户端使用基于证书的身份验证（或任意数量的其他类型）来验证其身份，然后根据用户的授权传回适当的数据。
It sounds like you want to sign the application, not the database. There's no way for SQL Server to really know what version of the app it's talking to, since the application itself is responsible for telling SQL Server what version it is. You effectively are placing your app outside the "trust boundary", yet you want it to behave in a trusted fashion.
For stuff like this, I recommend going with a three-tier solution instead. Create a trusted middle tier which talks WCF or Web Services to the application. This middle tier is hopefully something you can control and trust. The middle tier could then use certificate-based authentication (or any number of other types of) to clients in order to authenticate their identities, and then pass back the appropriate data based on the user's authorization to it.