Todos os servidores precisam usar o protocolo HTTPS ou apenas servidores voltados ao público?

Question

Eu tenho um servidor Web front end executado 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 da Web faz solicitações de API - isso é voltado para o público e requer autenticação - a porta está aberta.

Esses dois servidores são executados em HTTPS.

Atrás do servidor da API, há muitos outros servidores. O servidor da API inverte os proxies para esses servidores. Portas para esses outros servidores não estão abertas para tráfego de entrada. Eles só podem ser conversados por meio do servidor da API.

Minha pergunta ... Os "vários outros servidores" precisam ser executados via HTTPS ou, como não podem ser acessados externamente, podem ser executados via HTTP com segurança?

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

    

Answer 1

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

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

O que eu geralmente sugeriria é usar uma CA interna (se disponível) ou assinar automaticamente (se não houver uma CA interna) os servidores de back-end. Nós definimos a data de validade para o futuro para evitar mudanças desnecessárias.

    

Answer 2

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 que injetam anúncios: link

• Rede indiana farejando entre cloudfare e back-end: link

• O agora famoso "SSL adicionado e removido aqui :-)" da NSA

Answer 3

Do the "lots of other servers" need to run over HTTPS or, given that they cannot be accessed externally, can they run over HTTP safely instead?

Isso realmente depende do que você está tentando realizar. Entenda o propósito de usar HTTPS é proteger os dados em trânsito entre dois pontos. Se você está preocupado com os dados que estão sendo detectados dentro de sua rede, então talvez isso deva ser resolvido primeiro. Se você precisar proteger os dados em trânsito dentro de sua rede, o que está dizendo é que você tem uma preocupação com a segurança dos dados que atravessam 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 é que depende. O que você está tentando fazer? Que tipo de dados você está criptografando? Quais ameaças você está tentando defender? Você tem uma exigência 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, isso pode ser mal utilizado quando estiver sendo transmitido dentro de 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 você está tentando protegê-lo?

    

Answer 4

De volta ao dia, as pessoas assumiram que as redes internas eram seguras como casas. Uma vez entrei em disputa com um supervisor que ficou chocado com o fato de meus servidores internos estarem executando seus firewalls internos. "Se você não pode confiar em sua rede interna, em quem você pode confiar?" Eu indiquei que tínhamos laptops para estudantes em nossa rede interna e que não havia firewall entre os laptops dos alunos e meus servidores. Ele, sendo novo na academia, parecia ter seu universo em farrapos com essa informação.

Redes internas não são mais consideradas seguras, mesmo que você não tenha laptops de alunos na sua rede. Veja a resposta de Tom para alguns exemplos.

Dito isso, sim, depende de quais informações estão sendo transmitidas, de 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 sensíveis agora , alguém possa decidir adicionar recursos ao seu aplicativo mais tarde que são confidenciais, por isso recomendamos paranóia (incluindo HTTPS).

    

Answer 5

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 alguma razão pela qual você precisa fazer downgrade de um link de rede para HTTP? Se não houver um motivo específico, a resposta é ficar com HTTPS.

    

Answer 6

O único motivo para desabilitar a criptografia é o desempenho. No entanto, no seu caso, os servidores internos são conectados 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 / whatever. A desativação da criptografia libera talvez 100 KB de RAM e gera 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 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 rígida atrapalhe mais a ativação do que a desativação da criptografia, o que resulta em um pior desempenho percebido pelos usuários finais.

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