在私有云上反向deviseDocker部署

我正在开发一个必须部署在客户端私有云上的软件。客户端具有root权限以及硬件。我不希望客户对我们的软件进行逆向工程。

我们可以在这里控制两件事：

我们可以访问服务器的一个安全端口，我们可以使用这个端口来发送令牌来解密代码，并在必要时将其closures;
我们可以手动安装（在安装时input密码），或者使用防拆装置。

Docker部署能否阻止我们的客户端逆向工程我们的代码？我们打算打开单个端口并使用SSL来保护传入和传出的数据。

如果用户拥有root权限，或者他能够使用自定义的内核（甚至内核模块），他可以做任何事情 – 转储内存，停止进程，附加debugging器 – 开始反向工程。如果用户可以访问硬件，他也可以得到root或者定制的内核。保护软件的唯一方法是使用良好的DRM，例如在TPM（可信平台模块）或ARM TrustZone的帮助下。 SecureBoot不会完全保护您的软件（在x86上通常可能会closures）。其他变体是使用防篡改硬件（ http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/what-is-tamper-resistant-hardware.htm ），就像用来存储掌握在银行（ http://en.wikipedia.org/wiki/Hardware_security_module ）中的encryption密钥（用于处理pin码），但是这种硬件具有很高的成本。

据了解，Docker不保护用户的代码： https : //stackoverflow.com/a/26108342/196561 –

主机上的root用户（运行docker守护程序的用户）可以完全访问主机上运行的所有进程。这意味着控制主机的人可以随时访问应用程序的RAM以及文件系统。这使得无法隐藏解密文件系统的密钥或保护RAM免于debugging。

任何能够部署docker容器的用户（来自docker组的用户）都可以完全访问容器fs，拥有对容器进程的root权限，并且可以debugging它们并转储它们的内存。 https://www.andreas-jung.com/contents/on-docker-security-docker-group-considered-harmful

只有受信任的用户才能被允许控制你的Docker守护进程

http://docs.docker.com/articles/security/#docker-daemon-attack-surface

Docker允许您在Docker主机和访客容器之间共享一个目录; 它允许你这样做而不限制容器的访问权限。

所以， Docker对用户的代码没有额外的保护 ，我们可以认为它就像其他包装系统一样，如rpm和deb。 Rpm和deb允许你把代码打包成单个文件和列表依赖，docker将你的代码和依赖关系打包成单个文件。

我们的解决scheme托pipe在我们客户的云服务器上，因此他们可以访问根和硬件。然而，我们在这里有两个好处：1）我们可以访问一个安全的端口，我们可以使用这个端口发送令牌来解密代码，并审计可疑的活动; 2）我们可以手动安装（在安装时键入令牌）

只有在您拥有的硬件上运行代码时，才能保护您所拥有的代码（closures所有NSA / IntelME / IPMI / UEFI后门以拥有自己的硬件）。如果用户在自己的硬件上运行你的代码，他将拥有所有的二进制代码，并且能够在收到你的令牌之后进行内存转储。

他硬件上的虚拟化不会给你的代码提供额外的保护。

“安全端口”是指SSL / TLS / SSH？在networking上发送时保护数据是安全的; 两个端点都将拥有明文，未encryption的数据。

离开用户的数据中心后，手动安装将无助于保护代码。

我认为你可以购买一些通常的软件保护解决scheme，如flexlm，可能需要一些硬件令牌来运行该软件。但是任何保护措施都可能被破解，早期（更便宜）的破解将更容易，而现代（更昂贵的）保护则更难以破解。

你也可以在你自己的服务器上运行一部分软件。这部分不会被破解。

或者如果我们必须使用防篡改硬件。

如果用户的服务器中没有这样的硬件，则不能使用防篡改硬件。而且非常昂贵。