Segurança de rede e IoT em um modelo de segurança de confiança zero

Views: 45
0 0
Read Time:5 Minute, 30 Second

Você nunca pode ter muito cuidado quando se trata de segurança de rede e IoT. Com um número crescente de dispositivos díspares sendo conectados a infraestruturas corporativas e industriais, é melhor prevenir do que remediar.

Para administradores de rede, não se trata mais apenas de proteger laptops e PCs, mas sim de gerenciar uma rede composta por uma paleta colorida de hardware conectado, incluindo dispositivos móveis e IoT de baixo custo. Mas como você pode manter sua rede segura quando cada dispositivo é reproduzido por suas próprias regras? A resposta é (relativamente) simples: NÃO CONFIE EM NINGUÉM!

É aqui que entra o conceito de “arquitetura de confiança zero”, que é um conceito de segurança baseado em não confiar em um dispositivo por padrão simplesmente porque faz parte da sua rede. Em vez disso, cada dispositivo precisa se autenticar para cada conexão que deseja estabelecer. Dado que qualquer conexão possível envolve pelo menos duas partes, a autenticação necessária aqui é chamada de autenticação mútua.

Existem diferentes protocolos de comunicação que fazem uso da autenticação mútua, como SSH TLS. Mas o que esses protocolos têm em comum é que a autenticação é baseada em certificados de dispositivo exclusivos. Sem esse certificado, um dispositivo não pode se autenticar.

Como um dispositivo obtém um certificado?

Tudo começa com o dispositivo tendo seu próprio par de chaves público-privado exclusivo. Para gerar um certificado, o primeiro passo é compartilhar a chave pública desse par com uma Autoridade de Certificação (AC). A autoridade de certificação verificará se a chave pública pertence a este dispositivo, enviando-lhe um desafio. Somente o dispositivo que possui a chave privada correspondente poderá responder com sucesso a esse desafio. Agora a autoridade de certificação sabe que a chave pública pertence ao dispositivo e criará um certificado para ela.

Uma vez criado, o certificado pode ser enviado para o dispositivo, que agora pode usá-lo em protocolos de autenticação futuros em redes que consideram a autoridade de certificação específica que criou o certificado uma fonte confiável. Isso é algo que torna o termo “confiança zero” um pouco enganoso. Mesmo quando você não confia nos dispositivos, há algo em que você precisa confiar. Neste caso, a relação de confiança é baseada nos certificados e na autoridade que os fornece.

Mas há outro aspecto que é importante considerar: a chave privada. A chave privada é a base sobre a qual toda a segurança é construída. É o que vincula o certificado ao dispositivo, porque qualquer pessoa que queira verificar a autenticidade do certificado pode fazer isso desafiando a chave privada. E como essa chave privada é tão importante, ela deve sempre ser armazenada com segurança dentro do dispositivo.

Um invasor nunca deve ser capaz de ler, alterar ou copiar essa chave privada, pois isso compromete a segurança de toda a rede à qual o dispositivo está conectado. Manter a chave privada privada deve ser a maior prioridade de qualquer dispositivo. E a rede precisa confiar (há essa palavra novamente…) no dispositivo para poder fazê-lo.

Como a chave privada é armazenada com segurança no dispositivo?

Existem algumas maneiras de fazer isso, começando com o uso tradicional de hardware seguro, como um Secure Element ou um Trusted Platform Module. Ambos são chips seguros que precisam ser adicionados ao dispositivo e que cuidam da criação e armazenamento seguro de chaves. Esta é uma solução aceitável para dispositivos caros, como telefones e laptops, mas geralmente não resolve todos os problemas de segurança, já que partes limitadas têm acesso a ele. No entanto, para dispositivos IoT de baixo custo, adicionar um chip seguro à lista de materiais adiciona muito custo.

Uma solução mais acessível é armazenar o par de chaves na memória de um dos chips que o dispositivo já precisa de qualquer maneira, como um microcontrolador. Neste caso, o par de chaves pode ser provisionado externamente durante a fabricação, ou pode ser gerado internamente (se o chip tiver um gerador de números aleatórios interno). A principal desvantagem dessa opção é que os chips para dispositivos IoT não são projetados para armazenar chaves com segurança. Isso significa que existe um sério risco de a chave privada ser comprometida por um determinado invasor com acesso ao dispositivo. Além disso, quando as chaves são injetadas de fora, a parte que injeta essas chaves é outra entidade confiável para manter os segredos em segredo.

Há ainda outra alternativa a esses métodos tradicionais para gerar e armazenar chaves secretas, e é baseada em funções físicas não clonáveis (PUFs).

PUFs usam variações submícrons profundas no processo de fabricação de chips para criar identificadores exclusivos do dispositivo. Isso significa que os PUFs podem gerar chaves criptográficas (como o par de chaves que precisamos) a partir do silício dos chips. Essas chaves são únicas para cada chip e nunca precisam ser armazenadas na memória – elas são simplesmente (re)geradas toda vez que são necessárias. Isso elimina a necessidade de provisionamento externo de chaves, bem como de usar hardware dedicado para proteger chaves armazenadas.

É por isso que a implantação de PUFs está ganhando força rapidamente, especialmente para dispositivos IoT de baixo custo. Usar PUFs para criar e proteger as chaves necessárias para gerar certificados de dispositivo fornece o tipo de confiança que uma arquitetura de confiança zero requer.

Conclusão

Agora que vimos todos os diferentes blocos de construção necessários para conectar dispositivos com segurança em uma rede, podemos dar um passo atrás e ver o que aprendemos.

Tudo começa no nível do dispositivo, onde a base de uma arquitetura de confiança zero é estabelecida selecionando a maneira correta de provisionar o dispositivo com as chaves que são a base para seu certificado exclusivo. O método de escolha variará dependendo do hardware de dispositivos individuais.

Diferentes abordagens fornecem diferentes níveis de segurança, mas uma coisa que todas elas têm em comum é que precisam incutir o nível apropriado de confiança de que manterão a chave privada privada. Quando um dispositivo está equipado com um par de chaves público-privadas, uma autoridade de certificação pode fornecer a próxima peça do quebra-cabeça gerando um certificado para o dispositivo. Uma vez que um dispositivo tenha esse certificado exclusivo, ele estará pronto para a autenticação mútua que deve ter permissão para entrar de maneira segura em uma rede construída sobre uma arquitetura de confiança zero.

Combinando a garantia fornecida pela maneira como as chaves criptográficas são armazenadas com a confiança que precisa ser colocada na autoridade de certificação, é seguro afirmar que, pelo menos neste caso, não há “confiança zero” sem confiança.

FONTE: HELPNET SECURITY

Previous post Como implementar configurações seguras mais rapidamente
Next post Hackers da SolarWinds estão perseguindo provedores de serviços de nuvem, gerenciados e de TI

Deixe um comentário