Parole VPN versus certificate de client: ce se recuperează mai repede

O implementare cere nume de utilizator și parolă, alta un certificat de client, iar a treia ambele. Alegerea schimbă mult mai mult decât fereastra de autentificare: decide cum sunt emise credențialele, cum expiră, cum arată recuperarea la 2 dimineața și cine poate revoca accesul pentru exact un dispozitiv. Comparați ciclul de viață operațional, nu caseta de dialog.

O parolă este un secret al contului validat de un proces de autentificare, în timp ce un certificat este o identitate plus dovada deținerii cheii sale private. Sunt obiecte diferite cu moduri de eșec diferite.

Două dovezi diferite, două casete diferite

O parolă dovedește cunoașterea unui secret partajat, așa că serverul compară un hash și sistemul de conturi deține ciclul de viață. Un certificat dovedește deținerea unei chei private, iar serverul verifică un lanț de semnături până la o CA în care are încredere. Al doilea poate identifica un dispozitiv în locul unei persoane, motiv pentru care implementările emit adesea unul pe laptop. O frază de acces care protejează un fișier de cheie este din nou un al treilea lucru: păzește fișierul în repaus și nu este parola contului VPN.

Verificarea serverului rămâne necesară în orice combinație. Credențialele valide trimise către un punct final a cărui identitate ați încetat să o verificați rămân credențiale înmânate celui care a răspuns, motiv pentru care verificarea certificatului serverului aparține profilului de bază și nu unui pas de depanare.

Emiterea, expirarea și revocarea sunt costul real

Parolele sunt ieftine de emis și scumpe de susținut: resetări, politică, reutilizare și coada helpdesk-ului. Certificatele mută acest cost în față, unde aveți nevoie de o CA, un proces de semnare și un canal de distribuție, apoi adaugă un calendar de expirare pe care nimeni nu-l ține minte. Ambele au nevoie de revocare planificată. Un certificat revocat are nevoie de o CRL pe care fiecare server o citește cu adevărat, iar un cont dezactivat are nevoie ca backend-ul de autentificare să îl refuze la următoarea conexiune, nu la următoarea sincronizare.

Niciun mecanism nu devine sigur doar pentru că există. Întrebarea este ce ciclu de viață poate echipa să opereze consecvent.

Ce se strică atunci când un dispozitiv se pierde

Pentru un laptop pierdut, eliminați autorizarea pe care acel dispozitiv a folosit-o efectiv. Resetarea parolei nu revocă certificatul acestuia, iar emiterea unui certificat nou nu schimbă parola unui cont nelegat. Identitățile separate pe dispozitiv fac posibilă o eliminare țintită, în timp ce credențialele partajate înseamnă că scoaterea unui dispozitiv afectează mai multe. Scrieți procedura de recuperare pentru fiecare mecanism înainte de a avea nevoie, inclusiv cine poate semna un certificat de înlocuire în afara orelor de program.

Exersați calea de revocare în loc să o presupuneți: revocați o identitate de test, confirmați că serverul o refuză la o conexiune nouă, apoi restabiliți-o. Un proces de revocare care nu a fost niciodată exersat tinde să eșueze exact când este necesar.

Operarea ambelor fără a dubla munca

Multe implementări combină intenționat ambele: un certificat pentru dispozitiv și o credențială de cont pentru persoană, astfel încât un laptop furat nu este suficient și o parolă scursă nu este suficientă. Această combinație merită doar când cele două cicluri de viață rămân separate și ambele sunt automatizate. Altfel helpdesk-ul gestionează două cozi, iar câștigul de securitate rămâne teoretic.

Alegeți metoda pe care clienții serviciului și instrumentele de administrare o susțin efectiv. Slăbirea verificării pentru ca un profil nepotrivit să se conecteze inversează întregul sens, iar un profil editat până se conectează este adesea unul care nu mai verifică ceea ce a fost construit să verifice.

Notați ce dovadă cere fiecare implementare și cum este revocată fiecare. Următorul incident va cere exact asta.