O SSL precisa ser configurado no balanceador de carga externo se você estiver usando um?

2

Usando o Elastic Load Balancer, é fácil configurar o SSL no balanceador de carga externo e atender solicitações como http no aplicativo.

Ao executar um único servidor, também é possível configurar o SSL no servidor da web (Tomcat) ou no aplicativo (Spring).

Ao executar com o balanceador de carga, é necessário colocar o SSL no nível do balanceador de carga? Existe um elemento de estado na conexão SSL que será perdido ao encaminhar o tráfego ainda criptografado?

    
por LizH 27.01.2015 / 19:28

3 respostas

5

Eu tenho medo que a resposta seja "depende". Eu tive a oportunidade de cavar um pouco quando eu estava trabalhando com segurança de internet banking. Isto foi há alguns anos atrás, por isso é totalmente possível que alguém venha com algo que eu tenha esquecido ou que tenha mudado durante esses anos.

Desvantagens com o encerramento do SSL no balanceador de carga

  • Primeiro, é possível perder o estado fazendo isso - se você tiver um aplicativo em execução que exija alguns cabeçalhos SSL para manter o estado. Nesse caso, é provável que você perca essa informação (embora você possa configurar seus balanceadores de carga para encaminhá-la de alguma maneira). Um exemplo poderia ser se você estiver usando certificados de cliente para autenticação.

  • Em segundo lugar, como diz Bazze, isso torna o tráfego vulnerável a escutas na rede local. Quanto perigo isso é, naturalmente, dependerá de como sua rede se parece, e também de que tipo de tráfego é.

Vantagens

  • Você está reduzindo a carga em seus servidores da Web, pois eles não precisam mais gastar seus recursos em descriptografia e criptografia.

  • Quando você altera a configuração do servidor da web, pode fazer um simples recarregamento do apache sem precisar digitar sua senha da chave SSL. Isso significa que você pode automatizá-lo, permitindo implantação contínua e devops e todos os chavões. (O outro lado disso é que alterar a configuração do LB pode exigir que você insira a senha, mas como regra isso é algo que você não faz tão frequentemente quanto mexer na configuração do apache ...)

  • A resolução de problemas do seu servidor da Web e da aplicação ficou muito mais fácil, já que agora você pode espiar / tcpdump o tráfego de entrada diretamente.

  • Você tem menos lugares para lidar com falhas de segurança / bugs SSL. Geralmente, é muito mais fácil alterar as configurações de SSL em um LB do que em um grande número de servidores da Web - especialmente se esses servidores forem gerenciados por muitas pessoas diferentes de departamentos diferentes.

  • A auditoria do SSL também é muito mais fácil quando há apenas um lugar para auditar.

  • É muito mais fácil controlar quais certificados estão em uso e quando eles precisam ser renovados quando estão todos em um só lugar. Você não tem mais a questão de Bob ter pedido um certificado e colocar seu endereço de e-mail pessoal no sistema para lembretes e depois desistir ou ser demitido para que o lembrete seja devolvido e o certificado expire e, de repente, você terá muitas pessoas preocupadas exigindo isso. Fica consertado agora! (Não que isso tenha acontecido em qualquer lugar onde trabalhei! tosse )

Conclusão

Se é uma boa ideia terminar ou não no LB depende de como você valoriza as várias vantagens e desvantagens. Como regra, eu diria que, a menos que haja uma boa razão para fazer o contrário, você precisará remover a complexidade o mais cedo possível - na fronteira da rede, se isso for razoável do ponto de vista da segurança e usabilidade ou tão cedo quanto possível.

    
por 27.01.2015 / 20:36
0

Eu diria que encerrar o tráfego SSL no nível do balanceador de carga ou do servidor depende se você estiver satisfeito com o tráfego não criptografado entre os dois ou não. Na maioria dos casos, o tráfego proveniente do balanceador de carga para o (s) servidor (es) está viajando dentro de uma rede privada, onde você não precisa se preocupar com ataques de espionagem e man-in-the-middle (em comparação com o tráfego internet pública).

Deixar a terminação para o ELB também economiza o trabalho extra de encerrar o tráfego por conta própria.

Aqui você pode ler mais sobre isso: link

    
por 27.01.2015 / 20:08
0

Algumas ideias adicionais: 1. Se você estiver procurando por conformidade com o PCI, precisará criptografar "dados em trânsito" para ter que transferir o tráfego criptografado para seu aplicativo ou criptografar novamente entre o LB e seu servidor de aplicativos.

  1. Descriptografar no LB retira uma carga de processamento do seu servidor de aplicativos e esse é um dos principais motivos para encerrar o SSL no LB.
por 27.01.2015 / 22:10