Virtualização Segura Precisa de KMS e HSM

por | ago 7, 2019 | Análises Técnicas | 0 Comentários

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

 

HSM kNET Kryptus operando como KMS.

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:

Fluxograma comunicação vsphere e knet

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.



				
Igor Jardim

Igor Jardim

Gerente de T.I.

Especialista em Redes de Computadores pela UNICAMP. Administrador de Sistemas e Auditor Interno ISO 9001:2008

0 comentários

Enviar um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

CONTACT US

CONTACT US


Rua Maria Tereza Dias da Silva, 270
Cidade Universitária, Campinas-SP - Brasil
CEP 13083-820

fale.conosco@kryptus.com
Tel/Fax +55 (19) 3112 5000

© 2019 - Kryptus | Shaping Trusted Bonds - All rights reserved. - Developed by DDID