Então juntei-me a uma nova equipa, que desenvolve e opera um serviço disponível na Internet. Ele é voltado para uso B2B e não para o consumidor, embora qualquer pessoa possa se inscrever em uma conta de nível inferior para conferir (você não chegará a lugar nenhum se os desenvolvedores de seus clientes em potencial não puderem jogar antes que os ternos assinem um acordo! ).
Aprendi recentemente, para minha surpresa, que algumas coisas que eu esperaria que fossem servidas por HTTPS para um conjunto rigidamente controlado de certificados de clientes, em vez disso, são transmitidas por HTTP aberto, sem qualquer tipo de autenticação. Coisas como um armazenamento de chave/valor Consul, no qual alguns dos valores são senhas, ou um registro privado 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 não gostaria de apostar que as chaves foram alteradas). Provavelmente existem outros serviços em posição semelhante que ainda não encontrei.
O colega a quem perguntei sobre isso concordou que não era o ideal, mas não se preocupou 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 bem) roteáveis pela Internet, graças a Deus. No entanto, parece muita confiança para colocar na configuração de roteamento da rede, sem mencionar que se um dos servidores for comprometido, seu acesso à rede interna significa que o resto será alvo fácil.
Este é meu primeiro trabalho administrando um serviço público, até agora trabalhei no mundo "shrinkwrap", onde vendemos software, mas nossos clientes o instalam e executam. Portanto, não tenho noção do quão ruim isso é. Vou aumentá-lo e tentar consertá-lo, mas queria administrá-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 devo gritar. Isso é realmente terrível e deveríamos largar tudo até que esteja consertado, ou não é bom, mas na verdade não é tão incomum na realidade?
Postando como convidado, pois não quero dar nenhuma pista sobre de quem é esse serviço :)
Responder1
Eu não acho que isso seja um grande problema, com umembargo:forneceu a rede que conecta os servidores privados(seja virtual ou físico)está trocado, isso não é um grande problema.
Meu mantra habitual é que não existe segurançano abstrato, apenas ameaças e respostas a elas, apropriadas ou não. Então, qual é o seu modelo de ameaça? Um invasor compromete o servidor voltado para a Internet; o que ele(a) pode fazer agora?
SSL (incluindo HTTPS) na rede 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 back-end seja comutada, o invasor só poderá ver o tráfego de e para o servidor comprometido. Como esse é um endpoint SSL, ele seria capaz de ler todo esse tráfegode qualquer forma. A autenticação oferece um pequeno benefício, mas é apenas um rastreamento: mesmo que eles não usem os certificados autoassinados usuais (que tendem a impedir a autenticação), você pode ter certeza de que está realmente se comunicando com os servidores back-end, porque você controla a rede interna e o modelo de ameaça não especifica a penetração da infraestrutura de rede.
Resumindo: você escreve isso "se um dos servidores for comprometido, seu acesso à rede interna significa que os demais serão alvos fáceis". Isto é verdade,mas não é menos verdade só porque o crosstalk interno é criptografado.
Quando você comenta com Ryan acima disso "o acesso do escritório à LAN privada hospedada é feito por VPN, e as operações no serviço de produção são feitas a partir de laptops Linux dedicados, em vez das máquinas principais dos desenvolvedores", vejo uma empresa que na verdade estápensamentosobre modelos e respostas a ameaças, em vez de agitar a criptografia como uma espécie de cobertor de segurança brilhante e presumir que agora eles estão seguros, por causa da criptografia. Parece que eles trabalham duro para proteger as partes que se beneficiam da segurança e não se preocupam com as que não o fazem.
Responder2
Tive uma longa conversa sobre isso com um amigo meu. Tudo se resume ao que você está fazendo e à aparência da sua rede.
Geralmente: é ruim.
A criptografia tornou-se muito mais simples de implementar ao longo dos anos, portanto não deveria haver muitas desculpas para não implementá-la.
Realmente depende do que está acontecendo na sua rede. Essas informações precisam ser confidenciais/autenticadas? Lembre-se de que, embora o destino possa não conseguir rotear para a Internet, sua máquina pode. Tecnicamente, se alguém grampeou sua máquina ou qualquer dispositivo de roteamento/comutação entre você e seu destino, seus dados serão comprometidos. Você deve sempre presumir que, se sua máquina puder acessar a Internet, alguém poderá ter todo o poder que você possui. Só porque a Internet não consegue alcançar sua LAN privada diretamente, não significa que ela não possa alcançá-la comprometendo sua máquina.
Isto é umfacilmentetópico discutível, mas geralmente não ter criptografia diminuirá sua postura de segurança. Se você pode fazer isso, então faça. Eu concordaria que sua situação apresenta um risco mínimo, mas ainda assim - basta fazê-lo!