Proteger uma imagem VMWare sem entrada manual de senha

1

Estou diante da seguinte tarefa: Um "modelo" VMWare (baseado no SLES11) com software personalizado, que deve ser distribuído para alguns clientes. Eles receberão uma cópia específica do cliente do modelo e deverão importá-lo para o servidor ESX local. MAS! eles não devem ter acesso local!

Existem duas partes a considerar:

1) Se a imagem em si não estiver criptografada, ela poderá ser aberta mesmo sem executar e os dados poderão ser extraídos ou pior: alterados. Ou alguém poderia apenas alterar o processo de inicialização e iniciar uma imagem de resgate do SLES e, em seguida, montar as partições de imagem

2) A solução óbvia seria criptografar o disco virtual, e pedir uma senha no gerenciador de inicialização (por exemplo, truecrypt) - mas o cliente não deve saber a senha e eu não entrarei em cada inicialização; / p>

Então a pergunta é: Como criptografar / proteger esta imagem VMWare?

    
por Kaffee 08.04.2013 / 15:27

2 respostas

3

Com acordos contratuais e a retirada do suporte, se você descobrir que eles já se conectaram ao sistema e mudaram alguma coisa. Há muito pouco que você pode fazer quando o atacante em potencial (seus clientes) tem acesso "físico" ao sistema. Não é como se você pudesse bloqueá-los de seu próprio sistema VMware.

Para ajudar a fornecer uma resposta melhor e mais segmentada: o que especificamente você não quer que eles sejam capazes de fazer? Que ações eles podem tomar que estão lhe dando agita? Faça alterações dentro do sistema operacional? Use algo como o Tripwire para auditar quaisquer alterações (e, em seguida, negue o suporte se encontrar alterações). Leia os arquivos de configuração que contêm suas senhas secretas, que são as mesmas para todos os dispositivos em cada cliente? Isso pode ser um pouco mais difícil.

Para o primeiro ponto - dados do paciente. Se você estiver nos EUA com o HIPAA, precisará de uma resposta específica para sua empresa de uma fonte qualificada, não de um site de perguntas e respostas da Internet. Honestamente. Dito isto, os dados do paciente estão sendo gerados / armazenados por você / sua empresa? Provavelmente não - eu imagino que está sendo gerado / armazenado por seus clientes, só acontece de estar no seu dispositivo. É sua bunda, então eles precisam proteger este dispositivo.

Para o segundo ponto - Jeebus. Quanto a "não alterar a configuração", algo como o Tripwire ajudaria a determinar se isso acontece. Impedindo os usuários finais de fazer isso? Fabricantes de equipamentos perigosos não podem impedir que os clientes usem um cortador e remover barras de segurança, mas contanto que a documentação diga: "Nunca faça isso; risco de morte", então a responsabilidade é normalmente do cliente por fazer o estúpido coisa. IANAL claro.

    
por 08.04.2013 / 15:36
1

Essencialmente você não faz. Não pense que a virtualização contém uma solução mágica para esse problema - você deve tratar sua segurança exatamente como se estivesse entregando uma máquina física ao cliente.

Em outras palavras, se você passar a eles um VMDK / OVF, você deve pressupor que eles tenham acesso total ao console e ao disco rígido.

Como você lida com isso depende de você, mas a solução certamente não é técnica. Dado que organizações muito maiores do que você está enviando dispositivos virtuais agora, e geralmente com uma senha de root, eu sugiro que você está simplesmente abordando isso do ângulo errado. O que exatamente você está tentando proteger?

    
por 08.04.2013 / 15:37