Virtualização Segura Precisa de KMS e HSM

Por: Igor Jardim

No início dos anos 2000, o conceito de virtualização começou a surgir como uma saída para os grandes datacenters que enfrentavam tanto a falta de espaço físico para crescimento quanto o desperdício de poder de processamento de servidores, que acabavam ficando mais ociosos do que realmente em uso.

No decorrer dos anos, esses pools de servidores físicos dedicados começaram a cair em desuso drasticamente e a virtualização passou a ser peça fundamental de uma infraestrutura de T.I., seja na arquitetura ou nos projetos, visto a agilidade que permite à gestão e à operacionalização das empresas.

Ao mesmo tempo que melhorou-se significativamente o tempo de resposta de um departamento de T.I. e de provedores em nuvem, exacerbou-se um problema que, até então, tinha sido deixado de lado: a segurança dos dados, principalmente aqueles em disco.

Hoje, com inúmeros vazamentos de dados, e a LGPD batendo à porta de todos, é fundamental para as empresas resolverem este passivo que só aumenta, colocando em risco não somente os usuários dos sistemas mas também em cheque a própria continuidade dos proprietários da infraestrutura de T.I.

Por que a segurança de dados é deixada de lado?

Muitos administradores deixam de utilizar a cifração do disco em servidores, por exemplo, pois para ter o HD decifrado após a reinicialização do equipamento, é necessário digitar uma senha em cada um, operação intrinsecamente enfadonha e que aumenta o tempo de indisponibilidade da infra, mesmo que por alguns minutos.

Hoje, com a facilidade de criação de servidores virtuais, isso torna-se uma tarefa quase impraticável, o que acaba fazendo que administradores de sistemas optem, erroneamente, pela não criptografia do disco.

O que complica é que justamente nos servidores virtuais o problema é muito pior: toda vez que uma máquina virtual é pausada ou um snapshoot é criado, não somente o conteúdo dos seus discos vai parar no HD físico do servidor, mas também os dados de memória! Ou seja, todos aqueles dados que estão na memória dos aplicativos e serviços rodando na máquina virtual, o que incluem, normalmente, chaves criptográficas, dados pessoais, senhas, tokens de autenticação, etc, vão parar em aberto no disco do servidor físico, expondo dados que precisam estar seguros.

Uma solução para a segurança

Se você pensou: mas e o Hypervisor, ele não resolve isso? A resposta curta é: não sozinho.

Para entender, vamos relembrar: o Hypervisor é uma camada de software entre o hardware e o sistema operacional que permite que máquinas virtuais possam ter acesso aos recursos de hardware. Ele opera em uma camada no sistema onde têm a possibilidade de utilizar chaves para cifrar e decifrar volumes de dados de forma automática e transparente para as máquinas virtuais, sempre que necessário, eliminando a necessidade da digitação de senhas.

No entanto utilizar apenas chaves para cifrar/decifrar um servidor leva a outro problema: encontrar uma forma de armazenamento seguro para essas chaves, visto que, com o seu vazamento, não apenas um único servidor, mas um cluster, ou seja, vários equipamentos conectados que trabalham juntos e paralelamente, acabam ficando vulneráveis.

Utilizando KMS para guardar as chaves criptográficas

 

 

Para solucionar esse problema e manter as chaves de maneira segura, a saída é a utilização de um KMS (Key Management Service). KMSs são um tipo de sistema capaz de gerenciar de forma segura o ciclo de vida de chaves criptográficas na forma de um serviço. Neste serviço, podem-se conectar diversos outros sistemas com suporte à criptografia de dados, como um Hypervisor, um Banco de Dados e, até mesmo, SIEMs.

Obviamente, o KMS não pode ser uma máquina virtual, por isso os Key Management Systems/Services efetivos são baseados ou usam equipamentos de proteção criptográfica da classe HSM (Hardware Security Module), dispositivo blindado, no sentido lógico e físico, contra roubo e uso inadequado de chaves criptográficas.

Se você procura uma solução para este problema, temos duas boas notícias!

A primeira  é que com o lançamento do vSphere 6.5, a VMware introduziu a possibilidade de se encriptar de forma transparente a própria máquina virtual (VM), independentemente do Sistema Operacional que ela estiver rodando, o que resolve os problemas de segurança já citados, além de ajudar na regulamentação de proteção de dados como a LGPD! Para essa funcionalidade, o vSphere utiliza um KMS para proteger suas chaves de criptografia!

A segunda notícia é que o HSM kNET opera como KMS e é totalmente compatível com o Vmware vSphere.

Comunicação entre o vSphere e o kNET

A figura abaixo explica, de forma geral, como a comunicação entre o vSphere da Vmware e o kNET da Kryptus é realizada:

 

 

1- Primeiramente deve-se ter uma relação de confiança entre o kNET (KMS) e o vCenter;

2- O vCenter solicita uma chave ao KMS;

3- O KMS envia uma chave Key Encryption Key (KEK) para o vCenter;

4- O vCenter armazena apenas o ID da chave e envia o conjunto KEK+ID para o ESXi (Hypervisor);

5- O ESXi recebe e armazena a KEK exclusivamente na memória;

6- Com a KEK recebida, o ESXi gera a chave Data Encryption Key (DEK), para cifrar os arquivos da VM;

7- O ESXi, agora, cifra os discos rígidos da VM com a DEK e, em seguida cifra a DEK com a KEK;

Nota: Quando o ESXi é reinicializado, o vCenter solicita novamente a chave para o KMS e todo o processo é repetido.

A relação de confiança entre o VMware vCenter e o Kryptus kNET é realizada de forma fácil e prática: utilizando para isso o protocolo de manipulação de chaves KMIP. Para tal, adiciona-se no vCenter o cluster de KMS que serão utilizados informando o IP, porta, usuário e senha do kNET. Em seguida, gera-se uma solicitação de assinatura de certificado (CSR), que deve ser assinada pelo KMS e devolvida ao vCenter que, a partir desse ponto, estabelece a relação de confiança com o KMS.

Benefícios da integração VMware e kNET

Com a integração, o cluster de servidores possui duas camadas de proteção! Isso ocorre por conta de cada VM ser cifrado com uma chave DEK única e cada chave DEK ser cifrada, por sua vez, com uma chave KEK única. Assim, mesmo se o atacante descobrir a chave DEK, sem a chave KEK – que fica armazenada de maneira segura dentro do kNET HSM – ele não tem acesso aos arquivos.

“Antes da utilização de um KMS integrado ao VMware para gerenciar e armazenar as chaves, precisávamos digitar as senhas manualmente em cada servidor. Agora, esse processo ficou muito mais prático, além de melhorar significativamente a segurança do ambiente como um todo”, diz Igor, Gerente de TI da Kryptus.

Igor também dá a dica que deve-se considerar a configuração de mais de um kNET, criando-se um cluster de KMS, a fim de aumentar a disponibilidade do sistema, pois o ESXi, ao ser reiniciado, e/ou instanciar uma nova VM, solicita chaves que devem ser providas sob risco de indisponibilidade.