Todos os servidores precisam usar o protocolo HTTPS ou apenas servidores públicos?

Eu tenho um servidor Web front-end executando sobre HTTPS - isso é voltado para o público - ou seja, a porta está aberta.

Também tenho um servidor de API back-end no qual meu servidor da Web faz solicitações de API - isso é voltado para o público e requer autenticação - a porta está aberta.

Esses 2 servidores rodam sobre HTTPS.

Por trás do servidor da API, existem muitos outros servidores. O servidor da API reverte proxies para esses servidores. As portas para esses outros servidores não estão abertas ao tráfego de entrada. Eles só podem ser consultados através do servidor da API.

Minha pergunta ... Os "muitos outros servidores" precisam executar sobre HTTPS ou, como não podem ser acessados ​​externamente, eles podem executar sobre HTTP com segurança?

Eu pensei que isso seria uma pergunta comum, mas não consegui encontrar uma resposta para ela. Obrigado. Se isso é uma bobagem, por favor, aponte-me para a resposta certa.

Isso é uma questão de opinião e também tem a ver com questões regulatórias (se você enfrentar alguma).

Mesmo que atualmente não seja necessário, sou um grande defensor de manter o HTTPS ativado entre os firewalls / balanceadores de carga / servidores de front-end no nível do aplicativo e os servidores de back-end. É uma superfície a menos de ataque. Contratei lugares que precisavam ser convertidos à medida que informações mais sensíveis começaram a ser transmitidas - é melhor começar por aí.

O que eu geralmente sugeriria é o uso de uma autoridade de certificação interna (se disponível) ou de autoassinatura (se não houver autoridade de certificação interna) nos servidores back-end. Definimos a data de validade agradável e 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 na sua rede. Malwares em sua própria rede podem interceptar / modificar solicitações http.

Não são ataques teóricos, mas exemplo da vida real:

• Roteadores (provavelmente hackeados) dentro da rede de alguns sites que injetam anúncios: https://www.blackhat.com/docs/us-16/materials/us-16-Nakibly-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

Os "muitos outros servidores" precisam executar o HTTPS ou, como não podem ser acessados ​​externamente, eles podem executar o HTTP com segurança?

Isso realmente depende do que você está tentando realizar. Entender o objetivo do uso do HTTPS é proteger os dados em trânsito entre dois pontos. Se você está preocupado com a detecção de dados dentro da sua rede, talvez seja melhor cuidar primeiro deles. Se você precisar proteger os dados em trânsito dentro da sua rede, o que você está dizendo é que você tem uma preocupação com a segurança dos dados que atravessam seus sistemas na rede ou há algum motivo relacionado à conformidade para criptografar os dados em trânsito.

Esta é realmente mais uma pergunta de opinião, mas a resposta é que depende. O que você está tentando fazer? Que tipo de dados você está criptografando? De que 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, ele poderá ser mal utilizado quando estiver sendo transmitido dentro da sua rede, então eu sugiro que você se junte à gerência para corrigir o problema. Então, no final, o que você está tentando proteger e por que está tentando protegê-lo?

Naquela época, as pessoas supunham que as redes internas eram seguras como casas. Certa vez, entrei em uma disputa com um supervisor que estava horrorizado que meus servidores internos estavam executando seus firewalls internos. "Se você não pode confiar na sua rede interna, em quem pode confiar?" Eu indiquei que tínhamos laptops estudantis em nossa rede interna e que não havia firewall entre os laptops estudantis e meus servidores. Ele, sendo novo na academia, parecia ter seu universo em frangalhos diante dessa informação.

As redes internas não são mais consideradas tão seguras, mesmo se você não tiver laptops de estudantes em sua rede. Veja a resposta de Tom para alguns exemplos.

Dito isto, sim, depende de quais informações estão sendo transmitidas, de quaisquer questões de conformidade legal, etc. Você pode decidir que não se importa se alguém cheira, por exemplo, dados meteorológicos. Dito isso, é possível que, mesmo que os dados enviados não sejam confidenciais agora , alguém possa decidir adicionar recursos ao seu aplicativo posteriormente que sejam confidenciais, por isso recomendo maior paranóia (incluindo HTTPS).

Hoje, com instruções especializadas da CPU para acelerar a criptografia e novos protocolos de transporte que não operam nem operam com desempenho degradado em um link não criptografado (HTTP / 2, gRPC, etc ...), talvez a melhor pergunta seja: existe alguma motivo pelo 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.

O único motivo para desativar a criptografia em que consigo pensar é no desempenho. No entanto, no seu caso, os servidores internos têm interface via HTTP, o que significa que eles já suportam o custo de desempenho da execução de um servidor da Web, suportando o protocolo HTTP e codificando dados em HTTP / JSON / qualquer que seja. A desativação da criptografia liberará talvez 100 KB de RAM e você ganhará alguns microssegundos por KB de dados transmitidos, o que não terá impacto visível no desempenho geral. Por outro lado, você precisará prestar muito mais atenção à segurança, já que agora executa o HTTP na sua intranet. De fato, é possível que uma configuração mais rigorosa do firewall atrase as coisas mais do que a desativação da criptografia as tenha acelerado, resultando em pior desempenho percebido pelos usuários finais.

Será como colocar um spoiler em um trator: você ganha quase nada teoricamente e muitos inconvenientes na prática.