Mi sembra che la domanda sia "ti fidi del tuo datacenter". In altre parole, sembra che tu stia cercando di tracciare con precisione la linea in cui si trovano le reti non affidabili e la fiducia inizia.

A mio parere, il trust SSL / TLS dovrebbe terminare al dispositivo di offload SSL poiché il reparto che gestisce quel dispositivo spesso gestisce anche la rete e l'infrastruttura. C'è una certa dose di fiducia contrattuale lì. Non ha senso crittografare i dati su un server a valle poiché le stesse persone che supportano la rete di solito hanno accesso anche a questo. (con la possibile eccezione in ambienti multi-tenant o requisiti aziendali unici che richiedono una segmentazione più profonda).

Un secondo motivo per cui SSL dovrebbe terminare al bilanciamento del carico è perché offre un luogo centralizzato per correggere gli attacchi SSL come CRIME o BEAST. Se SSL viene terminato su una varietà di server web, in esecuzione su diversi sistemi operativi è più probabile che si verifichino problemi a causa della ulteriore complessità. Mantienilo semplice e avrai meno problemi a lungo termine.

Detto questo

1. Sì, termina al bilanciamento del carico e offload SSL lì. Mantenerlo semplice.
2. Il bilanciatore del carico Citrix Netscaler (ad esempio) può negare l'accesso non sicuro a un URL. Questa logica dei criteri, combinata con le funzionalità di TLS, dovrebbe garantire che i tuoi dati rimangano riservati e privi di manomissioni (dato che comprendo adeguatamente il tuo requisito di integrità)

Modifica:

È possibile (e comune)

• Esternalizzare il bilanciamento del carico (Amazon, Microsoft, ecc.)
• Utilizzare una CDN di terze parti (Akamai , Amazon, Microsoft, ecc.)
• Oppure utilizza un proxy di terze parti per prevenire attacchi DoS

... dove il traffico da quella terza parte verrebbe inviato ai tuoi server tramite collegamenti di rete che non gestisci. Pertanto potrebbe non fidarsi di quei collegamenti non crittografati. In tal caso, è necessario crittografare nuovamente i dati, o almeno far viaggiare tutti i dati attraverso una VPN point-point.

Microsoft offre un prodotto VPN di questo tipo e consente l'outsourcing sicuro del perimetro.

Sì, direi che TLS dovrebbe essere scaricato. Ho fatto tutto ciò che menziono di seguito specificamente con Citrix Netscaler, ma credo che F5 dovrebbe essere in grado di fare le stesse cose.

Per prima cosa, devi sempre assicurarti di ricrittografare sull'altro lato del bilanciamento del carico, ma il dispositivo che decrittografa TLS dovrebbe essere in grado di ispezionare cosa sta succedendo dal punto di vista della sicurezza. L'integrità dei dati non dovrebbe essere compromessa da questo approccio.

Molte persone mi hanno detto che la ricrittografia sul back-end lo rende altrettanto costoso dal punto di vista computazionale, ma non è vero. La spesa con TLS è la costruzione e la chiusura della connessione, che gestisce l'offloader TLS. Sul back-end hai una connessione più persistente ai server, e quindi le risorse richieste sono molto inferiori.

Inoltre, se non disponi dell'offload TLS, anche un piccolo attacco DDoS tramite TLS annullerebbe completamente i tuoi server. Conosco molto bene questa situazione e l'offload TLS è un aiuto incredibile dal punto di vista computazionale e consente anche di bloccare gli attacchi più in alto nella catena. Per attacchi DDoS estremamente grandi, potresti persino suddividere la tua strategia di mitigazione tra il tuo offloader TLS ei tuoi server.

Per ispezionare i dati che vanno all'interno di una connessione SSL, allora uno di questi deve essere vero:

• Il tunnel termina sulla macchina che esegue l'ispezione, ad es. il tuo "load balancer".
• Il sistema di ispezione conosce una copia della chiave privata del server e la connessione SSL non utilizza Diffie-Hellman effimero (ovvero il server non consente le suite di cifratura che contengono "DHE "nel loro nome).

Se segui la prima opzione, i dati viaggeranno non crittografati tra il sistema di ispezione (il bilanciatore del carico) e i cluster, a meno che tu non li crittografi di nuovo con qualche altro SSL tunnel: la connessione SSL principale è tra il browser del client e il bilanciamento del carico e il bilanciamento del carico mantiene un collegamento SSL (o qualche altra tecnologia di crittografia, ad esempio una VPN con IPsec) tra se stesso e ciascuno dei nodi del cluster .

La seconda opzione è un po 'più leggera, poiché l'ispettore di pacchetti decrittografa solo i dati ma non deve ricrittografarli. Tuttavia, ciò implica che tutti i nodi del cluster siano in grado di eseguire l'SSL completo con il client, ovvero conoscere una copia della chiave privata del server. Inoltre, non supportare DHE significa che non otterrai la funzionalità elegante di Perfect Forward Secrecy (questo non è fatale, ma PFS sembra davvero buono negli audit di sicurezza, quindi è una cosa buona da avere). / p>

In ogni caso, il nodo che esegue l'ispezione approfondita dei pacchetti deve avere un accesso privilegiato al tunnel SSL, il che lo rende piuttosto critico per la sicurezza.

Suggerirei di terminare SSL sul sistema di bilanciamento del carico (che sia sulla tua rete, o presso un provider CDN o altro). Significa che il LB può ispezionare il traffico e può svolgere un lavoro migliore di bilanciamento del carico. Significa anche che il tuo sistema di bilanciamento del carico è responsabile della gestione di client lenti, implementazioni SSL non funzionanti e instabilità generale di Internet. È probabile che il tuo sistema di bilanciamento del carico disponga di risorse migliori per farlo rispetto ai tuoi server back-end. Significa anche che i certificati SSL che il mondo vede sono tutti sul bilanciatore del carico (che si spera li renda più facili da gestire).

L'alternativa qui è semplicemente bilanciare il carico delle connessioni TCP dai client alle spalle server finali. Poiché LB non è in grado di ispezionare cosa sta succedendo in questo modo, non può distribuire il carico in modo uniforme sui server back-end e i server back-end devono affrontare tutta la debolezza di Internet. Utilizzerei questo metodo solo se non ti fidi del tuo sistema di bilanciamento del carico, provider CDN o altro.

Che tu decifri di nuovo o meno dal bilanciatore del carico ai tuoi server back-end è una questione personale scelta e circostanza. Se hai a che fare con carte di credito o transazioni finanziarie, probabilmente sei regolamentato dal governo e quindi dovrai crittografare nuovamente. Probabilmente dovresti anche crittografare nuovamente se il traffico tra il bilanciamento del carico e i server back-end viaggia su reti non attendibili. Se stai solo ospitando il sito web della tua azienda, potresti essere in grado di evitare l'overhead aggiuntivo della ricrittografia, se non ti interessano davvero gli aspetti di sicurezza di esso.

La ricrittografia non lo fa Tuttavia, non aggiungere tutto il carico che potresti pensare. Di solito, il bilanciatore del carico sarà in grado di mantenere connessioni persistenti ai server, quindi il costo SSL sarà piuttosto basso per quel "salto" sulla rete.

L'ultima cosa a cui pensare è l'applicazione sui server back-end. Se tutto il traffico che arriva lì è HTTP, non può prendere decisioni in base al protocollo utilizzato dal client. Non può quindi dire "stai tentando di accedere alla pagina di accesso tramite HTTP, quindi ti reindirizzerò alla versione HTTPS della pagina", ad esempio. Puoi fare in modo che il bilanciatore del carico aggiunga un'intestazione HTTP per dire "questo proviene da HTTPS", ma tale intestazione richiede una gestione speciale nell'applicazione. A seconda della situazione, potrebbe essere più semplice crittografare nuovamente e lasciare che l'applicazione funzioni nel modo "predefinito" piuttosto che richiedere una modifica specifica del sito.

In sintesi, direi: terminare nel sistema di bilanciamento del carico e crittografate nuovamente sui server back-end. Se lo fai e noti qualche problema, puoi apportare modifiche se necessario.

Puoi scegliere di crittografare il traffico interno con un certificato con chiave inferiore. Inoltre, si consiglia di posizionare il bilanciatore del carico il più vicino possibile ai server per prevenire attacchi di sniffing o man-in-middle. La terminazione SSL può essere eseguita sul Load Balancer per scaricare i lavori ad alta intensità di CPU dai server web. Se il marchio LB che hai scelto può svolgere determinate funzioni come l'ispezione di connessioni di protocollo malformate, rilevare il comportamento DDoS, ecc.