Quão preocupado devo estar com o HTTP desprotegido em uma rede “privada”?

Question

Então eu me juntei a uma nova equipe, que desenvolve e opera um serviço disponível na Internet. Ele é voltado para o uso B2B em vez do consumidor, embora qualquer um possa se inscrever em uma conta de nível baixo para verificar (você não chega a lugar nenhum se os desenvolvedores de seus clientes em potencial não puderem jogar antes que os processos assinem uma oferta! ).

Recentemente, fiquei sabendo, para minha surpresa, que algumas coisas que eu esperaria que fossem veiculadas via HTTPS para um conjunto de certificados de clientes rigidamente controlados seriam repassadas para HTTP aberto, sem autenticação de qualquer tipo. Coisas como um armazenamento de chave / valor Consul, em que alguns dos valores são senhas, ou um registro particular do Docker no qual algumas das imagens contêm chaves privadas (há um projeto em andamento para remover chaves das imagens e injetá-las em tempo de execução, mas as imagens antigas ainda estão no registro e eu não gostaria de apostar que as chaves foram alteradas). Provavelmente existem outros serviços em uma posição semelhante que ainda não encontrei.

O colega que eu perguntei sobre isso concordou que não era ideal, mas estava bastante despreocupado porque esses serviços só são expostos na rede privada dentro do datacenter (hospedado por terceiros). Eles não são (se tudo estiver funcionando corretamente) roteáveis da Internet, graças a Deus. No entanto, isso parece ser uma grande confiança para colocar na configuração de roteamento da rede, para não mencionar que se um dos servidores ficar comprometido, seu acesso à rede interna significa que o resto é um patinho sentado.

Este é o meu primeiro show executando um serviço público, até agora eu trabalhei no mundo "shrinkwrap" onde vendemos software, mas nossos clientes o instalam e executam. Então eu não tenho a menor idéia do quão ruim isso é. Eu vou aumentá-lo e tentar consertá-lo, mas eu queria executá-lo por uma comunidade com mais experiência na execução de serviços de produção, a fim de calibrar o quão alto eu deveria estar gritando. Isso é realmente terrível e devemos largar tudo até que seja consertado, ou não bom, mas na verdade não tão incomum na realidade?

Como convidado, pois não quero dar pistas sobre quem é o serviço:)

    

Answer 1

Eu não acho que isso seja um grande problema, com uma ressalva : fornecida a rede que conecta os servidores privados (seja virtual ou física) está comutado , isso não é um grande problema.

Meu mantra usual é que não existe algo como segurança no resumo , apenas ameaças e respostas, apropriadas e de outra forma. Então, qual é o seu modelo de ameaça? Um invasor compromete o servidor da Internet; o que ele (a) pode fazer agora?

O SSL (incluindo HTTPS) na conexão fornece dois serviços, criptografia e autenticação. A criptografia não oferece proteção contra esse modelo de ameaça: desde que a rede de back-end seja comutada, o invasor só poderá ver o tráfego de e para o servidor comprometido. Como esse é um terminal SSL, ele poderá ler todo o tráfego mesmo assim . A autenticação fornece um pequeno benefício, mas é apenas um rastreamento: mesmo que eles não usem os certificados auto-assinados usuais (que tendem a autenticar o Gut), você pode ter certeza de que está realmente falando com os servidores de back-end, porque você controla a rede interna e o modelo de ameaça não especifica a penetração da infra-estrutura de rede.

Resumindo: você escreve que " se um dos servidores ficar comprometido, seu acesso à rede interna significa que o resto é um patinho" ". Isso é verdade, mas não é menos verdade apenas porque o crosstalk interno é criptografado .

Quando você faz um comentário para Ryan sobre o acesso ao escritório para a LAN privada hospedada é através de uma VPN, e as operações no serviço de produção são feitas a partir de laptops Linux dedicados ao invés de máquinas principais dos devs. "Eu vejo uma empresa que está realmente pensando em modelos de ameaças e respostas, em vez de acenar em forma de criptografia, como se fosse uma espécie de cobertor de segurança brilhante, e presumindo que agora eles estão seguros, por causa da criptografia. Parece que eles trabalham duro para proteger os bits que se beneficiam da segurança, e não se preocupe com os bits que não o fazem.

    

Answer 2

Eu tive uma longa conversa sobre isso com um amigo meu. Tudo se resume ao que você está fazendo e à sua rede.

Geralmente: é ruim.

A criptografia tornou-se muito mais simples de implementar ao longo dos anos, portanto, não deveria haver muita desculpa para não implementá-la.

Isso realmente depende do que está acontecendo com o seu fio. Essas informações precisam ser confidenciais / autenticadas? Lembre-se que, embora o destino possa não ser capaz de encaminhar para a Internet - a sua máquina pode. Tecnicamente, se alguém tocar em sua máquina ou em qualquer dispositivo de roteamento / comutação entre você e seu destino, seus dados estarão comprometidos. Você deve sempre presumir que, se sua máquina puder acessar a Internet, alguém pode ter todo o poder que você tem. Só porque a Internet não pode acessar diretamente a sua LAN privada, não significa que não possa alcançá-la comprometendo sua máquina.

Este é um tópico facilmente discutível, mas geralmente não ter criptografia reduzirá sua postura de segurança. Se você puder fazer isso, então faça. Eu concordo que a sua situação é um risco mínimo, mas ainda assim - basta fazer isso!