É possível criptografar o tráfego entre servidores da Web internos usando o Load Balancer [fechado]

Você sempre pode criptografar o tráfego entre quaisquer sistemas que pertençam a um grupo definido. O modo de transporte IPsec é criado especificamente para isso. Não é importante quais funções esses servidores assumem, back-end, front-end, etc., eles são apenas nós IP neste caso. Considere isso como uma solução genérica que torna "sim, é possível" uma resposta válida para todas as perguntas como "é possível criptografar o tráfego entre A e B". No entanto, às vezes não é conveniente e muitas vezes existem outras opções.

Outras opções dependem para qual finalidade você precisa dessa criptografia. Não responda "apenas por segurança", não existe "apenas por segurança". Existem modelos de ameaças e modelos de segurança que lidam com essas ameaças definidas. Por exemplo, em termos simples, o modelo de ameaça para o HTTP é o homem no meio que pode espionar e injetar seus próprios dados, se passar por um servidor válido e/ou um cliente válido; o HTTPS é projetado para tornar isso impossível criptografando e assinando todas as comunicações. Na melhor das hipóteses, o MitM pode passar todo o tráfego sem poder escutar ou simplesmente interromper a comunicação por completo. Então, contra o que você está se defendendo, quais são suas ameaças?

Sua rede entre os back-ends e os balanceadores não é confiável? Por quê? Essas redes devem incluir apenas balanceadores e back-ends e nada mais, quais atores não confiáveis ​​você tem lá? No entanto, o IPsec no modo de transporte é uma solução aceitável nesse caso, porque ele criptografará tudo que estiver no fio.

Você também pode usar HTTPS entre o balanceador e os back-ends (e entre os próprios back-ends). Tudo bem, seu balanceador encerrará o HTTPS do usuário, verá a solicitação e a resposta em texto simples, poderá desmontá-los (adicionar/remover/alterar cabeçalhos) e selecionará o back-end e o processamento analisando o conteúdo, por exemplo, selecione um back-end para conteúdo estático e outro para conteúdo dinâmico. Em seguida, estabelecerá outroConexão HTTPS para back-end. Os únicos clientes HTTPS para back-ends serão balanceadores e outros back-ends, portanto, não é importante que eles usem certificados globalmente recong. (Por exemplo, o Google Front-ends não verifica certificados de back-ends HTTPS localizados no Google Cloud, portanto, mesmo certificados autoassinados funcionarão.) Você pode criar sua própria CA interna, emitir certificados para todos os back-ends e balanceadores e torná-los confiáveis ​​instalando esse certificado CA no armazenamento de cada sistema. Somente os balanceadores precisam configurar certificados válidos globalmente e apenas no lado do cliente. A automação do Let's Encrypt provavelmente também será o dever desses balanceadores, porque os certificados emitidos devem ser instalados neles.

Você não confia no seu balanceador de carga? A passagem SSL pode ajudar, mas também tem suas próprias desvantagens. Nesta configuração, o balanceador é um daqueles homens no meio contra quem o HTTPS foi criado. Portanto, ele não pode acessar os detalhes de HTTP para equilibrar as solicitações, nem mesmo saber o valor do cabeçalho do host http para diferenciar os vhosts; ele não pode injetar cabeçalhos de proxy adicionais como aqueles "proxies para" e assim por diante; as conexões são protegidas dele conforme o esperado. Tudo o que ele pode fazer é rastrear a conexão e, de outra forma, encaminhar pacotes cegamente para algum back-end. Nesse caso, você não configura nenhum certificado nele e nem configura nenhum nome de servidor. Basta especificar os IPs dos back-ends. Além disso, neste caso, certificados válidos devem ser instalados em todos os back-ends, porque não se sabe a priori qual back-end receberá qual solicitação.