Puteți cripta oricând traficul dintre orice sisteme care aparțin unui grup definit. Mod de transport IPsec este creat special pentru asta. Nu este important ce roluri le asumă acele servere, backend, frontend etc., ele sunt doar noduri IP în acest caz. Luați în considerare aceasta ca o soluție generică care face ca „da, este posibil” un răspuns valid pentru toate întrebările precum „Este posibil să criptați traficul între A și B”. Cu toate acestea, uneori nu este convenabil și atât de des există și alte opțiuni.
Alte opțiuni depind de în care scop aveți nevoie de această criptare. Nu răspunde „doar pentru securitate”, nu există „doar securitate”. Există modele de amenințări și există modele de securitate care fac față acelor amenințări definite. De exemplu, în termeni simpli, modelul de amenințare pentru HTTP este omul din mijloc care poate să asculte și să-și injecteze propriile date, să se uite ca un server valid și/sau un client valid; HTTPS este conceput pentru a face acest lucru imposibil prin criptarea și semnarea tuturor comunicării. În cel mai bun caz, MitM poate fie să treacă întregul trafic fără a putea să asculte cu urechea, fie să întrerupă cu totul comunicarea. Şi ce dacă tu de care vă apărați, care sunt amenințările dvs.?
Rețeaua dvs. dintre backend și echilibratori nu este de încredere? De ce? Acele rețele ar trebui să includă doar echilibratori și backend și nimic altceva, ce actori neîncrezători aveți acolo? Cu toate acestea, IPsec în modul de transport este o soluție acceptabilă în acest caz, deoarece va cripta totul pe fir.
De asemenea, puteți utiliza HTTPS între echilibrator și backend-uri (și între backend-uri în sine). Este în regulă, echilibratorul dvs. va închide utilizatorul HTTPS, va vedea cererea și va răspunde în text simplu, va putea să le distrugă (adăugați/eliminați/modifica antetele) și va putea selecta backend-ul și procesarea analizând conținutul, de exemplu, selectați un backend pentru conținut static și altele pentru conținut dinamic. Apoi se va stabili o alta Conexiune HTTPS la backend. Singurii clienți HTTPS pentru backend-uri vor fi echilibratorii și alte backend-uri, așa că nu este important pentru ei să folosească certificate recunoscute la nivel global. (De exemplu, Google Frontends nu verifică certificatele backend-urilor HTTPS aflate în interiorul Google Cloud, așa că chiar și certificatele autosemnate vor funcționa.) Puteți să vă creați propriul CA intern, să eliberați certificate pentru toate backend-urile și echilibratorii și să le faceți de încredere instalând acel certificat CA în depozitul fiecărui sistem. Doar echilibratorii trebuie să aibă certificate configurate valabile la nivel global și numai pe partea cu client. Automatizarea Let's Encrypt va fi probabil și datoria acelor echilibratori, deoarece certificatele emise vor fi instalate pe ei.
Nu aveți încredere în echilibrul dvs. de încărcare? SSL passthrough ar putea ajuta, dar are și propriile sale dezavantaje. În această configurație, echilibrerul este unul dintre acei bărbați din mijloc împotriva cărora a fost creat HTTPS. Deci nu poate accesa detaliile HTTP pentru a echilibra cererile, nici măcar nu poate cunoaște valoarea antetului http Host pentru a diferenția vhost-urile; nu poate injecta anteturi proxy suplimentare, cum ar fi cele „proxiate pentru”, și așa mai departe; conexiunile sunt protejate de acesta conform așteptărilor.Tot ce ar putea face este să urmărească conexiunea și, în caz contrar, să trimită pachetele către un backend. În acest caz, nu configurați niciun certificat pe acesta și nici măcar nu configurați niciun nume de server. Doar specificați IP-urile backend-urilor. De asemenea, în acest caz trebuie instalate certificate valide pe toate backend-urile, deoarece nu se știe a priori care backend va primi ce cerere.
