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