Primeiro, a maioria dos balanceadores de carga funciona como proxies reversos wikipedia f5 devcentral . No entanto, existem diferenças na proteção inerente à maneira como os balanceadores de carga (ou proxies reversos) são arquitetados. Nota: eu vou usar o termo "balanceadores de carga" (LB) e "proxy reverso" (RP) intercambiáveis daqui para frente.
Um LB fornece segurança adicional servindo como intermediário para toda a comunicação. A maioria dos LBs de nível empresarial atua como proxies de camada 7. Para o tráfego da Web, a sessão HTTP do lado do cliente termina completamente no LB e o LB restabelece a conexão HTTP do lado do servidor de volta ao servidor. Ao forçar uma terminação da camada 7 (l7), toda a carga útil pode ser revisada, depurada e enviada de volta ao servidor limpa e otimizada. Em muitos casos, um LB também implementa um firewall de aplicativo da Web como um módulo complementar para inspecionar ainda mais o tráfego em busca de padrões anômalos antes de enviar o tráfego de volta ao servidor da web.
A força relativa de proteção fornecida por um LB no modelo acima depende se o tráfego está sendo finalizado em l7 ou em um nível inferior. Alguns balanceadores de carga podem funcionar apenas na camada de rede, o que basicamente significa que o LB pode apenas reescrever as informações de IP / porta à medida que o tráfego flui do lado do cliente para o lado do servidor. Além disso, é totalmente possível configurar um LB com capacidade de l7 full proxy para trabalhar apenas nas camadas de rede / transporte para melhorar o desempenho (l7 terminal é um recurso intensivo). Nesse caso, o balanceador de carga pode não esfregar o tráfego o mais completamente possível.
Voltando ao seu modelo, se RP = LB, a partir da perspectiva da arquitetura, a arquitetura proposta adiciona complexidade adicional ao modelo atual. No entanto, a chave aqui é com o modelo proposto, o S1 / S2 inicia a conexão de saída para o DMZ. Um invasor pode comprometer o RP, mas não pode estabelecer uma nova sessão de volta ao S1 / S2 ou à rede interna. No entanto, se houver pontos fracos do aplicativo em S1 / S2 ou DB, MQ, um invasor poderá entrar de novo na rede para acessar S1 / S2. Além disso, uma vez que "RP" está usando a mesma pilha de tecnologia que S1 / S2, qualquer fraqueza em S1 / S2 provavelmente existiria em "RP" também. No entanto, se "RP" não for quebrável, o modelo proposto aumentará a postura de segurança, pois as pilhas de rede de S1 / S2 estarão protegidas e o ataque terá que ser o alvo da pilha de aplicativos primeiro.
Embora seja discutível o valor de segurança que esse modelo adiciona (se um atacante quebra o dmz / int fw, ele tem acesso livre à intranet & esse modelo não protege contra o ataque comum de pesca submarina), modelo pode ser mais aceitável para um sujeito de conformidade do que não. Esse é especialmente o caso da conformidade com PCI, onde qualquer sistema que tenha acesso a um ambiente CHD também está no escopo. No caso acima, a DMZ inteira pode estar dentro do escopo, mas se você estabelecer uma conexão de saída do ambiente CHD, somente a "RP" será adicionada ao escopo. Embora eu não esteja insinuando que este é o caso, eu vi arquitetos abordarem a redução do escopo do PCI dessa maneira.