Eu tenho um servidor web front-end rodando em HTTPS - isso é voltado para o público - ou seja, a porta está aberta.
Eu também tenho um servidor de API de back-end para o qual meu servidor web faz solicitações de API - isso é voltado para o público e requer autenticação - a porta está aberta.
Esses 2 servidores são executados em HTTPS.
Atrás do servidor API, existem muitos outros servidores. Os proxies reversos do servidor API para esses servidores. As portas para esses outros servidores não estão abertas ao tráfego de entrada. Eles só podem ser falados por meio do servidor da API.
Minha pergunta ... Os "muitos outros servidores" precisam ser executados em HTTPS ou, como não podem ser acessados externamente, podem ser executados em HTTP com segurança?
Eu pensei que esta seria uma pergunta comum, mas não consegui encontrar uma resposta para ela. Obrigado. Se isso for um engano, por favor, me aponte para a resposta certa.
Isso é uma questão de opinião e também tem a ver com questões regulatórias (se houver).
Mesmo que não seja necessário no momento, sou um grande defensor de manter o HTTPS ativado entre todos os firewalls / balanceadores de carga / servidores front-end e servidores back-end no nível do aplicativo. É uma superfície de ataque a menos. Contratei lugares que precisavam ser convertidos à medida que informações mais confidenciais começaram a ser passadas - é melhor começar por aí.
O que eu geralmente sugeriria é usar uma CA interna (se disponível) ou autoassinar (se não houver CA interna) os servidores de back-end. Definimos a data de validade bem distante no futuro para evitar alterações desnecessárias.
TL;DR você deve criptografar o tráfego , a menos que esteja no mesmo host.
Você não pode confiar em sua rede. Malwares em sua própria rede podem interceptar/modificar solicitações http.
Não são ataques teóricos, mas exemplos da vida real:
Roteadores (provavelmente hackeados) dentro da rede de alguns sites injetando anúncios: https://www.blackhat.com/docs/us-16/materials/us-16-Nakably-TCP-Injection-Attacks-in-the-Wild- A-Large-Scale-Study-wp.pdf
Rede indiana farejando entre cloudfare e back-end: https://medium.com/@karthikb351/airtel-is-sniffing-and-censoring-cloudflares-traffic-in-india-and-they-don-t-even-know -it-90935f7f6d98#.hymc3785e
O agora famoso "SSL adicionado e removido aqui :-)" da NSA
Isso realmente depende do que você está tentando realizar. Entenda que o objetivo do uso do HTTPS é proteger os dados em trânsito entre dois pontos. Se você está preocupado com os dados que estão sendo rastreados dentro de sua rede, talvez isso deva ser resolvido primeiro. Se você precisa proteger os dados em trânsito dentro de sua rede, o que você está dizendo é que você tem uma preocupação com a segurança dos dados que trafegam em seus sistemas dentro de sua rede ou há algum motivo relacionado à conformidade para criptografar os dados em trânsito.
Esta é realmente mais uma questão de opinião, mas a resposta é depende. O que você está tentando fazer? Que tipo de dados você está criptografando? De quais ameaças você está tentando se defender? Você tem um requisito legal (por exemplo, PCI-DSS, HIPAA, etc.) que diz que você precisa criptografar os dados em trânsito? Se os dados forem confidenciais e você estiver preocupado com o uso indevido quando estiverem sendo transmitidos dentro de sua rede, sugiro que se reúna com o gerenciamento para corrigir o problema. Então, no final, o que você está tentando proteger e por que está tentando protegê-lo?
Antigamente, as pessoas presumiam que as redes internas eram seguras como casas. Certa vez, tive uma disputa com um supervisor que ficou chocado com o fato de meus servidores internos estarem executando seus firewalls integrados. "Se você não pode confiar em sua rede interna, em quem você pode confiar?" Ressaltei que tínhamos laptops de alunos em nossa rede interna e que não havia firewall entre os laptops de alunos e meus servidores. Ele, sendo novo na academia, parecia ter seu universo em frangalhos com essa informação.
As redes internas não são mais consideradas tão seguras, mesmo que você não tenha laptops de alunos em sua rede. Veja a resposta de Tom para alguns exemplos.
Dito isso, sim, depende de quais informações estão sendo transmitidas, quaisquer problemas de conformidade legal, etc. Você pode decidir que não se importa se alguém fareja, digamos, dados meteorológicos. Dito isso, é possível que, mesmo que os dados enviados não sejam confidenciais agora , alguém decida adicionar recursos confidenciais ao seu aplicativo posteriormente , portanto, eu recomendaria maior paranóia (incluindo HTTPS).
Hoje, com instruções de CPU especializadas para acelerar a criptografia e novos protocolos de transporte que não funcionam ou operam com desempenho degradado em um link não criptografado (HTTP/2, gRPC etc.), talvez a melhor pergunta seja: existe algum razão pela qual você precisa fazer o downgrade de um link de rede para HTTP? Se não houver um motivo específico, a resposta é permanecer com HTTPS.
A única razão para desabilitar a criptografia que consigo pensar é o desempenho. No entanto, no seu caso, os servidores internos têm interface via HTTP, o que significa que eles já arcam com o custo de desempenho de executar um servidor da Web, suportando o protocolo HTTP e codificando dados em HTTP/JSON/qualquer coisa. Desativar a criptografia liberará talvez 100 KB de RAM e ganhará alguns microssegundos por KB de dados transmitidos, o que não terá impacto visível no desempenho geral. Por outro lado, você terá que prestar muito mais atenção à segurança, já que agora você executa o HTTP em sua intranet. Na verdade, é possível que uma configuração de firewall mais rigorosa torne as coisas mais lentas do que desabilitar a criptografia as acelerou, resultando em um desempenho pior percebido pelos usuários finais.
Será como colocar um spoiler em um trator: você ganha quase nada teoricamente e muitos transtornos na prática.