Dispozitiv de teren, TLS și VPN: care graniță protejează ce

Un dispozitiv de teren deschide o conexiune către un serviciu, iar întrebarea de proiectare apare ca o alegere între VPN și TLS. Această încadrare este greșită, pentru că cele două fac treburi diferite. TLS autentifică punctul final al aplicației și protejează conversația; în timp ce un VPN controlează accesibilitatea și protejează pachetele între parteneri. Urmați conexiunea de la dispozitiv spre exterior și fiecare strat are propriul răspuns.

Dacă nu puteți spune unde se termină TLS, nu puteți spune în ce se încrede de fapt aplicația.

Găsiți unde se termină de fapt TLS

Începeți de la aplicația dispozitivului și urmați conexiunea până la procesul care finalizează strângerea de mână. Dacă un proxy termină TLS înainte de mainframe, calea protejată se termină la proxy. Saltul rămas are nevoie de propria protecție documentată.

Să numești asta cap-coadă pe baza unei presupuneri este felul în care o revizuire de proiectare aprobă o lacună. Desenați punctul de terminare și ancora de încredere pe aceeași diagramă.

TLS transportă cereri și răspunsuri în ambele direcții, așa că o aplicație bidirecțională nu are nevoie în mod inerent de un VPN în loc de TLS. Și invers este adevărat: o implementare poate avea în continuare nevoie de un VPN pentru alte protocoale pe același dispozitiv.

Decideți ce trebuie să autentifice dispozitivul

Configurați validarea identității serverului și rădăcinile de încredere dorite. Dacă fiecare dispozitiv trebuie să își dovedească propria identitate, alegeți un model de autentificare a clientului acceptat și înregistrați acreditări separate pentru fiecare dispozitiv. Acreditările partajate transformă un singur dispozitiv furat într-o problemă pentru întreaga flotă.

Planificați protecția cheilor, reînnoirea, revocarea și recuperarea înainte de expediere. Un dispozitiv din teren care nu poate fi reînregistrat după o reînnoire eșuată devine o deplasare la fața locului, iar acel cost modelează proiectarea mai mult decât strângerea de mână.

Folosiți o bibliotecă acceptată și recomandările actuale. Recomandări moderne de implementare TLS interzic negocierea TLS 1.0 și 1.1, iar o referință la TLSv1 într-o notă de proiectare veche nu este o cerință.

Închideți când strângerea de mână eșuează

O strângere de mână eșuată sau o verificare a identității eșuată nu trebuie să revină în tăcere la protocolul original cu text clar. Acea revenire este vulnerabilitatea pe care lucrul la TLS trebuia să o închidă. Faceți eșecul vizibil pentru operatorul dispozitivului și pentru serviciu și cereți canalul protejat pentru operațiunile sensibile. Apoi lăsați autorizarea aplicației să decidă ce poate face un dispozitiv autentificat.

Definiți durata de viață a conexiunii, încadrarea în cadre, expirările și comportamentul la reîncercare ca parte a contractului. Criptarea nu face o comandă repetată sigură, iar o reîncercare după o operațiune anterioară incertă are nevoie de un răspuns la nivel de aplicație.

Scrieți regula de revenire. „Se reconectează fără TLS dacă strângerea de mână eșuează” este o decizie de proiectare și ar trebui să fie explicită.

Dați VPN-ului doar munca pe care o poate face

Un VPN poate restricționa accesibilitatea și poate proteja pachetele până la propriul partener. TLS protejează relația aplicației cu punctul final ales. Punctele lor de terminare pot diferi și niciunul nu securizează datele stocate ale punctului final sau accesul administrativ.

Măsurați costul strângerii de mână, mesageria stabilă și reconectarea pe dispozitivul real în loc să presupuneți că un mecanism este mai rapid. Apoi testați cele patru cazuri care contează: schimbul dorit, o identitate de server greșită, un dispozitiv neautorizat și o reconectare după o operațiune incertă. Notați rezultatul pentru fiecare caz, inclusiv eroarea pe care o afișează dispozitivul.