我面临以下任务：一个包含自定义软件的 VMWare“模板”（基于 SLES11），将分发给一些客户。他们将收到一份客户专用的模板副本，并将其导入到本地 ESX 服务器。但是！他们不应该获得任何本地访问权限！
有两个部分需要考虑：
1) 如果映像本身未加密，则即使没有运行，也可能会被打开，数据可能会被提取或更糟：被更改。或者有人可能只是修改启动过程并启动 SLES 救援映像，然后挂载映像分区
2）显而易见的解决方案是加密虚拟磁盘，并在引导加载程序中要求输入密码（例如 truecrypt） - 但客户端不应该知道密码，而且我不会在每次启动时输入密码;）
所以问题是：如何加密/保护这个 VMWare 映像？
答案1
如果您发现他们曾经登录系统并更改任何内容，则根据合同协议和撤销支持。当潜在攻击者（您的客户）对系统有“物理”访问权限时，您几乎无能为力。您无法将他们锁定在自己的 VMware 系统之外。
为了帮助你得到更好、更有针对性的答案：具体来说你不希望他们能够做到什么？他们采取了哪些行动让你感到不安？在操作系统内部进行更改？使用 Tripwire 之类的工具来审核任何更改（如果发现更改，则拒绝支持。）阅读包含你的秘密密码的配置文件，这些密码对于每个客户的每个设备都相同？这可能有点困难。
第一点是患者数据。如果您在美国，受 HIPAA 保护，您需要从合格来源（而不是某些互联网问答网站）获得针对您公司的特定答案。说实话。话虽如此，患者数据是由您/您的公司生成/存储的吗？可能不是 - 我猜想它是由您的客户生成/存储的，只是恰好在您的设备上。这是他们的设备，所以他们需要保护这个设备。
对于第二点 - Jeebus。至于“不更改配置”，像 Tripwire 这样的工具可以帮助确定是否会发生这种情况。阻止最终用户这样做？危险设备制造商无法阻止客户使用切割器并拆除安全杆，但只要文档中写着“永远不要这样做；有死亡风险”，那么做这种愚蠢事情的责任通常由客户承担。当然，我不是律师。
答案2
从本质上讲，您不需要。不要认为虚拟化可以神奇地解决此问题 - 您应该像将物理机器交给客户一样对待您的安全性。
换句话说，如果你向他们传递一个 VMDK/OVF，你必须假定他们有控制台和硬盘的完全访问权限。
如何处理这个问题取决于你，但解决方案几乎肯定不是技术性的。考虑到现在比你大得多的组织正在发送虚拟设备，而且通常使用 root 密码，我认为你只是从错误的角度来处理这个问题。确切地你想保护吗？