A cosa serve il certificato su Load Balancer e Keystore on Service?

2

Considerare uno scenario in cui il mio servizio utilizza un keystore costituito da certificati autofirmati e il bilanciamento del carico che bilancia il traffico per il servizio è associato a un certificato approvato dalla CA. Vorrei sapere quando inizia la comunicazione tra il Cliente, che risponde al cliente con il certificato? Il Servizio risponderà con certificato autofirmato o Bilanciamento del carico con certificato CA?

Mi piacerebbe sapere come funzionerà la comunicazione tra client-loadBalancer e loadBalancer-server? Quale di questi è protetto?

    
posta user1879956 12.03.2014 - 12:31
fonte

1 risposta

1

Terminare HTTPS (presumibilmente, non hai specificato quale protocollo) sul bilanciamento del carico ha molti vantaggi, un sottoinsieme rilevante qui:

  • richiesta di ispezione, eliminazione / applicazione del protocollo, limitazioni URL e WAF capacità
  • verifica delle risposte, DLP capacità
  • ispezione di cookie / URL per assegnazione del server e stickiness di sessione
  • (probabilmente) cache di sessione TLS comune, supporto RSA hardware assistito e crittografia simmetrica

Se non termina TLS sul bilanciatore del carico, non avrai alcuna capacità di ispezione e avrai opzioni di assegnazione sessione limitate.

Anche l'utilizzo di un certificato sui server back-end (content / application) presenta alcuni vantaggi:

  • il server back-end di contenuto / applicazione utilizza lo stesso protocollo del client, questo può avere un effetto sulla generazione di URL assoluti e modificare il comportamento di alcuni sistemi sensibili al protocollo (ad es. OWA, ma ci sono soluzioni alternative per questo)
  • lo sviluppo e il test sono solitamente più facili se tutto usa un protocollo
  • puoi tenere tutto in DMZ front-end crittografato, cosa che potrebbe essere richiesta dalla politica di sicurezza
  • se non ci sono DMZ front-end (cioè il tuo load-balancer è fuori dal tuo firewall perimetrale) allora questa configurazione è quasi certamente richiesta

e almeno uno svantaggio:

  • Overhead TLS (principalmente generazione di chiavi RSA). Su una rete fidata può essere accettabile per usare chiavi RSA più corte o cifrature simmetriche più veloci (meno robuste). Anche le connessioni persistenti o i tempi di sessione più lunghi si attenuano.

Nel caso generale, il bilanciamento del carico o il reverse-proxy è più semplice quando sia il server front-end che il server back-end utilizzano lo stesso protocollo (schema URI), nome host, porta e percorso URI. Questo semplifica o elimina la necessità di riscrivere le intestazioni, i contenuti, i percorsi dei cookie, i messaggi di errore ecc.

I client visualizzeranno (dovrebbero) solo il certificato CA pubblico sul front-end (bilanciamento del carico). È possibile utilizzare un certificato autofirmato a costo zero sui server Web di back-end. Di solito non c'è motivo per cui non sia possibile utilizzare anche qui gli stessi certificati commerciali della CA, sebbene alcune CA richiedessero una "licenza" per utilizzare un certificato su più di un dispositivo.

Tutte le connessioni verranno crittografate dal client al servizio di bilanciamento del carico e nuovamente dal server di bilanciamento del carico al server back-end. Vedi anche: Il protocollo SSL deve essere terminato con un bilanciamento del carico?

    
risposta data 13.03.2014 - 14:40
fonte

Leggi altre domande sui tag