logo标签列表

为什么像PostgreSQL和MySQL这样的开源数据库没有加密存储过程？

mysqlpostgresqlstored-proceduresencryption
3
为什么像Postgresql和Mysql这样的开源数据库没有加密存储过程？
是因为它们固有的开源哲学吗？
加密存储过程的强有力理由是什么？
1
没有必要对存储过程进行加密，这是一个典型的 "PHB" 要求。 - bortzmeyer
9个回答
6

我相信在PostgreSQL中，加密存储过程至少是编程方面的一个简单问题（MySQL和存储过程之间没有很长的历史），由于PgSQL的自定义语言支持，我不认为这会有什么用。它们需要在某个时刻被解密以执行它们，因此任何管理数据库/数据库服务器的人都能够（如果具备足够的技能）获取未加密的存储过程。DBA已经可以看到所有数据、所有关系，似乎使存储过程代码混淆无意义。

在PostgreSQL中支持自定义语言是一个优点。如果需要隐藏存储过程，可以很容易地创建它们在C库或Java文件中并将其包含。 - Jimmy Stenke
4
对于PostgreSQL，已经进行了多次辩论（并被拒绝，原因由james2vegas解释）。 - bortzmeyer
4

可能是因为没有人有这方面的需求。

4

加密存储过程是一个明显不好的想法。

商业编程不应该围绕着只有DBA可以访问完整SQL代码并以加密形式存储在数据库中的情况进行。这样会导致疯狂的结果。

2
说实话，我认为你在攻击一个稻草人。没有理由假设所有系统都涉及具有唯一访问权限的DBA。而且很容易想象出加密可能有用的部署场景（例如，某人开发了一组SQL存储过程库并希望出售它）。 - j_random_hacker
如果您分发加密软件，那么您也必须分发密钥以便进行解密和执行。否则，加密就只是混淆而已。这就是数字版权管理（DRM）的核心问题。 - Schwern
1
@Schwern：是的，在某种程度上，这只是“混淆”。但是，为了颠覆它所需的努力水平可以足够高，以至于在实践中它可以是有效的：很多商业软件以等效的方式工作（例如，通过要求访问执行某些检查然后解锁应用程序的一些核心部分的密钥服务器）。 - j_random_hacker
2
我想最重要的原因是开源数据库是由非常聪明的人编写的。他们知道，加密过程并不能保护您免受某些流氓管理员访问未加密源代码的侵害。
在专有软件世界中，人们往往认为“加密将解决问题”。但是当您考虑到您的数据库源代码是公开的这一事实时，这意味着必须以非常聪明的方式进行加密，并且并不适用于所有情况。
基本上 - 如果您想保护数据免受“硬盘被盗”- 您可以使用硬盘加密。如果您想保护备份 - 加密备份。但是，如果您想保护数据库免受“过于好奇”的管理员 - 请雇用律师，而不是试图考虑（或多或少）隐藏数据的不可能方法。
如果您想保护您的知识产权，那么不加密使任何具有数据库访问权限的人都可以查看您的代码是不负责任的。查看加密代码可能需要正确的技能集，但这并不像每个人所说的那样容易，特别是当加密被正确执行时。我敢猜测，在知识产权被盗之前，一家公司尽了一切努力来保护它们的知识产权，陪审团会更加同情他们。 - James L.
1

（关于加粗文本）我认为这不太对。如果您曾经使用过ACT！联系人管理系统，他们会将MSSQL Express作为单独的实例安装，并使用私有用户名和密码来访问SQL和数据库。因此，有方法可以不与客户共享数据库。

不想引发宗教战争，但像MSSQL这样的数据库服务器具有存储过程加密功能。其想法是，如果您是ISV，则可以部署带有加密存储过程的解决方案以保护您的知识产权。作为DBA，您无法解密这些存储过程。

以上仅供参考。

1
回答“加密存储过程的强制性原因是什么？”这个问题，我见过在应用程序使用相当复杂的专有逻辑在存储过程中，并且应用程序托管在客户数据库系统上时使用此方法。
我知道这不是一个完美的解决方案，但它可以防止轻易地窃取代码或防止客户DBA更改他们不应该触及的东西。
同意。你不会因为有人知道如何撬锁而把门留开。锁是对那些轻易放弃的小偷们的有效威慑。 - James L.
1

我曾经为InterBase提供支持，这个问题会不时出现。客户需要这个功能的原因是保护他们的“知识产权”——即源代码——在开发商业软件应用程序时的投资。

当然，您可以限制对C++、Java或Delphi等已编译语言的源代码的访问。一个客户可以反向工程已编译的代码并了解一些算法，但这与访问源代码不同。通过反编译，他们得不到很多信息。

但是，如果在触发器和存储过程体中实现应用程序的某些部分，则任何购买该软件产品的客户都可以读取这些内容。可能有办法模糊或加密此代码，但它不能是不可逆加密，否则数据库引擎将无法运行代码。

InterBase在BLOB字段中存储触发器/proc源代码的副本以及相同例程的已编译版本。因此，您可以将包含源代码的BLOB字段置为空，留下已编译的代码。但这仅与发布编译的应用程序代码一样有效；它仍然可以被具备足够技能和动力的盗版者进行反向工程。

我不知道在MySQL或PostgreSQL中是否可能使用NULL-out-the-source-BLOB技巧。

底线是：

将数据或元数据完全限制在客户手中后，没有绝对的访问限制方式。

值得注意的是，这是一个人为的要求。我从未听说过由于触发器和存储过程中有可读代码而导致软件IP被盗的人。无论如何，这也不是必要的。盗版者可以使用其他手段复制您的软件。

您为加密和混淆提出了非常好的论点，但在最后两段中暗示这并不是必要的。 我认为，如果可能的话，加密和混淆更好，以使其他人难以复制商业软件。 当您在非常狭窄的市场中工作时，只需要一次侵犯就可以夺走您的竞争优势。 让别人轻松查看、复制和更改您的源代码是不负责任的。 - James L.
@JamesL. 嗯，祝你好运。我认为编写开源代码比依赖代码作为你的价值主张更好。相反，创造一些无法被盗版的价值，例如提供不断更新的内容的访问权限。 - Bill Karwin
1

以下是我个人认为的一种加密存储过程/视图的好方案。我所在的公司编写了一个数据库驱动的应用程序。我们将数据库放置在客户网络上的SQL服务器或运行SQL Express的工作站上（适用于用户较少的小型客户）。存储过程和视图用于审计客户提供给我们的数据。为了防止客户的DBA或IT人员简单地窃取我们的专有算法，我们对存储过程和视图进行加密。我们在版本控制软件（如Visual Source Safe）中维护原始的明文脚本，以便我们端的支持团队可以访问并查看过程或视图的编码方式。我希望一些开源引擎也能够支持它，这样我们就可以摆脱SQL Express的限制。

这是一个非常糟糕的情况。如果你担心客户会欺骗你，那么这绝对不是你应该做生意的类型的客户。如果必须这样做 - 只需雇佣一位好律师。如果某人在数据库和操作系统中具有超级用户权限，并且还可以物理访问服务器 - 那么就没有办法保护数据库免受他的攻击。请查看Bill Karwin的回答。 - user80168
有技术反向工程程序的能力的人，无论加密和混淆如何，都可以做到。然而，将商业应用程序的源代码交给任何有权限查看、复制和更改的人是不负责任的。仅仅因为某个人可以反向工程您的程序并不意味着加密和混淆是一个坏主意。 - James L.
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接