VPN-wachtwoorden versus clientcertificaten: wat sneller herstelt
Een wachtwoord en een certificaat bewijzen verschillende dingen en falen op verschillende plekken. Vergelijk uitgifte, verloop en intrekking voordat je ze combineert.
De ene implementatie vraagt om een gebruikersnaam en wachtwoord, de andere om een clientcertificaat en een derde om beide. De keuze verandert veel meer dan het inlogvenster: ze bepaalt hoe inloggegevens worden uitgegeven, hoe ze verlopen, hoe herstel er om 2 uur ’s nachts uitziet en wie de toegang voor precies één apparaat kan intrekken. Vergelijk de operationele levenscyclus in plaats van het dialoogvenster.
Een wachtwoord is een accountgeheim dat door een authenticatieproces wordt gevalideerd, terwijl een certificaat een identiteit plus bewijs van bezit van de bijbehorende privésleutel is. Dat zijn verschillende objecten met verschillende faalwijzen.
Twee verschillende bewijzen, twee verschillende vensters
Een wachtwoord bewijst kennis van een gedeeld geheim, dus vergelijkt de server een hash en bezit het accountsysteem de levenscyclus. Een certificaat bewijst bezit van een privésleutel, en de server verifieert een handtekeningsketen tot een CA die hij vertrouwt. Het tweede kan een apparaat identificeren in plaats van een persoon, daarom geven implementaties er vaak één per laptop uit. Een wachtwoordzin die een sleutelbestand beschermt is weer iets anders: die bewaakt het bestand in rust en is niet het wachtwoord van het VPN-account.
Serververificatie blijft in elke combinatie nodig. Geldige inloggegevens die naar een eindpunt worden gestuurd waarvan je de identiteit niet meer controleert, zijn nog steeds inloggegevens die aan degene die antwoordde worden gegeven, daarom hoort de servercertificaatcontrole in het basisprofiel en niet in een probleemoplossingsstap.
Uitgifte, verloop en intrekking zijn de echte kosten
Wachtwoorden zijn goedkoop uit te geven en duur te ondersteunen: resets, beleid, hergebruik en de helpdeskwachtrij. Certificaten verschuiven die kosten naar voren, waar je een CA, een ondertekeningsproces en een distributiekanaal nodig hebt, en voegen dan een verloopkalender toe die niemand onthoudt. Beide hebben geplande intrekking nodig. Een ingetrokken certificaat heeft een CRL nodig die elke server daadwerkelijk leest, en een uitgeschakeld account heeft nodig dat de authenticatiebackend het bij de volgende verbinding weigert en niet bij de volgende synchronisatie.
Geen van beide mechanismen wordt veilig omdat het bestaat. De vraag is welke levenscyclus het team consistent kan uitvoeren.
Wat breekt als een apparaat verloren gaat
Verwijder voor een verloren laptop de autorisatie die dat apparaat daadwerkelijk gebruikte. Een wachtwoordreset trekt het certificaat niet in, en het uitgeven van een nieuw certificaat verandert geen wachtwoord van een niet-gerelateerd account. Aparte identiteiten per apparaat maken gericht verwijderen mogelijk, terwijl gedeelde inloggegevens betekenen dat het uitfaseren van één apparaat er meerdere raakt. Schrijf de herstelprocedure voor elk mechanisme voordat je die nodig hebt, inclusief wie buiten kantooruren een vervangend certificaat kan ondertekenen.
Oefen het intrekkingspad in plaats van het aan te nemen: trek een testidentiteit in, bevestig dat de server die op een nieuwe verbinding weigert en herstel die daarna. Een intrekkingsproces dat nooit is geoefend, faalt meestal precies wanneer het nodig is.
Beide draaien zonder het werk te verdubbelen
Veel implementaties combineren beide bewust: een certificaat voor het apparaat en een accountgegeven voor de persoon, zodat een gestolen laptop niet genoeg is en een gelekt wachtwoord niet genoeg is. Die combinatie loont alleen als de twee levenscycli gescheiden blijven en beide geautomatiseerd zijn. Anders draait de helpdesk twee wachtrijen en blijft de veiligheidswinst theoretisch.
Kies de methode die de clients van de dienst en de beheertools echt ondersteunen. Verificatie verzwakken zodat een niet-passend profiel verbinding maakt, keert het hele punt om, en een profiel dat is bewerkt tot het verbinding maakt is vaak een dat niet meer controleert waarvoor het is gebouwd.
Noteer welk bewijs elke implementatie vereist en hoe elk wordt ingetrokken. Het volgende incident vraagt precies dat.