我正在开发一个 C# 项目,并且有两个程序员可以帮助我完成项目的某些部分。问题是我不信任这些程序员,因为他们最近加入并需要保护我公司的财产。
我需要向两个程序员隐藏部分代码,这样他们就看不到它,他们应该仍然能够处理他们的部分并运行完整的应用程序来测试它。
有这种事吗?:)
我正在开发一个 C# 项目,并且有两个程序员可以帮助我完成项目的某些部分。问题是我不信任这些程序员,因为他们最近加入并需要保护我公司的财产。
我需要向两个程序员隐藏部分代码,这样他们就看不到它,他们应该仍然能够处理他们的部分并运行完整的应用程序来测试它。
有这种事吗?:)
知道几点:
C# 可以非常容易地查看您正在编译的内容,但这实际上适用于所有编程语言:如果需要编译它,则针对 dll 进行编译,或者他们可以将其作为 DLL 或作为原始文件运行C#,他们可以访问它背后的逻辑。 没有办法解决这个问题。 如果计算机可以运行程序并且它都驻留在您的 PC 上,那么人类也可以查看它并学习如何操作。
然而!您可以设计您的程序,使他们不需要针对它进行编译。
制作其他员工必须编写的代码插件。让他们将他们的代码作为一个完全独立的项目编写到一个接口,您的 API 的核心部分在运行时动态加载。
查看托管可扩展性框架以获取执行此操作的工具。
可以抽象出特定保密的组件,因此可以隐藏其工作原理的细节,然后通过网络调用调用。这仅适用于您要保护的核心细节对时间不敏感的情况。这也不能保护该功能背后的想法:员工需要了解能够使用它的目的,仅此一项就足以从头开始重建它。
如果您目前不信任您的员工,则需要开发它。 您将无法知道每个人总是做的所有事情。 这不仅是编程的关键技能,也是生活中的关键技能。如果您觉得您永远无法信任他们,那么您要么需要雇用您可以信任的新员工,要么建立对他们的信任。
建立对其能力的信任的一种方法是通过代码审查。首先,确保您使用的是允许轻松分支的版本控制系统。如果不是,请立即切换到Mercurial *。拥有“整合”区和个别发展区,通常通过克隆分支或命名分支。在他们提交代码之前,与员工聚在一起并审查更改。如果你对他们满意,那就让他们承诺。这将在每次提交时消耗一点时间,但如果您对更改进行快速迭代,那么审查也会很快。
如果你不信任你的员工,他们很可能也不会信任你。相互不信任不会产生忠诚。没有忠诚,你就没有保护。如果他们可以访问您的存储库,而您不信任他们,那么他们很有可能只需稍加努力即可获得您想要的代码。
大多数人大部分时间都是诚实的。和他们一起工作。了解他们。如果一个人被证明是为一个敌对实体工作,那么他们可能已经获得了他们想要得到的东西,而你无论如何都被搞砸了。如果一个人被证明是一个病态的骗子或无能,立即更换他们。通过“保护”您的代码不被他们看到,这些问题都不会得到解决。
从安全的角度来看,提高对员工信任的另一种方法是背景调查。几百美元和几天,你可以找到关于他们的各种信息。如果您准备好向他们隐藏代码,并且您是雇主,那么您不妨在他们窃取宇宙的秘密之前进行尽职调查。
我不想把它告诉你,但你的代码几乎有 100% 的机会不是特别的。试图通过默默无闻来保护它是浪费时间,也是一种众所周知的、糟糕的保护方法。
祝你好运!
**为什么是 Mercurial?只是因为它是一种易于上手的选项。如果它适合您的喜好,请随意使用任何其他工具,例如 Git。您使用哪一个完全无关紧要,与整个讨论无关。 *
你做不到,
即使您只给他们一个包含您的代码的 DLL,他们也可以使用反射工具提取代码,例如reflector
.
保留单独的备份并将虚拟占位符提交给源代码控制。
复杂的方法:用VS2010和他们需要的所有文件建立一个应用服务器,锁定所有东西,这样他们就不能直接访问任何文件,只能运行VS2010和构建的应用程序,并且只为受保护的代码提供DLL。
从理论上讲,他们将能够处理他们需要的代码,但永远无法直接访问 DLL,也无法安装或使用诸如 .NET Reflector 之类的工具来反汇编文件……可能仍然是一些你需要寻找的漏洞。
正确的方法:聘请值得信赖的程序员。;)
将您的代码放入 DLL 并使用 Dotfuscator 来混淆内部工作。
我能看到的唯一方法是给他们编译和混淆的程序集以供参考。因为您只能混淆私有成员,您可能需要修改您的代码,以便公共方法根本不做太多事情。如果公共方法中有任何有趣的代码,您应该重新排列代码,如下所示:
public bool ProcessSomething()
{
return this.DoProcessSomething();
}
private bool DoProcessSomething()
{
// your code
}
即使是 VS 免费提供的混淆器也会做一些工作,使查看您的代码变得不简单。如果您需要更多保护,您当然需要更好的混淆器。
但从长远来看,这是不切实际的,并且会向那些告诉你不信任他们的开发人员发出不好的信号。不会有什么好结果。如果您不是老板(或代码的所有者),我不会那么担心 - 毕竟它不是您的财产。你可以和你的老板谈谈,表达你的担忧。如果你是老板,你一开始就不应该雇佣你不信任的人。