VPN-salasanat ja asiakasvarmenteet: mikä palautuu nopeammin

Yksi käyttöönotto pyytää käyttäjätunnusta ja salasanaa, toinen asiakasvarmennetta ja kolmas molempia. Valinta muuttaa paljon muutakin kuin kirjautumisikkunaa: se päättää, miten tunnistetiedot myönnetään, miten ne vanhenevat, miltä palautus näyttää kello 2 yöllä ja kuka voi mitätöidä pääsyn täsmälleen yhdelle laitteelle. Vertaile käytön elinkaarta, älä valintaikkunaa.

Salasana on tilin salaisuus, jonka todennusprosessi vahvistaa, kun taas varmenne on identiteetti sekä todiste sen yksityisen avaimen hallinnasta. Ne ovat eri objekteja, joilla on erilaiset vikatilat.

Kaksi eri todistetta, kaksi eri ikkunaa

Salasana todistaa jaetun salaisuuden tuntemisen, joten palvelin vertaa tiivistettä ja tilijärjestelmä omistaa elinkaaren. Varmenne todistaa yksityisen avaimen hallinnan, ja palvelin vahvistaa allekirjoitusketjun luottamaansa CA:han asti. Jälkimmäinen voi tunnistaa laitteen henkilön sijaan, minkä vuoksi käyttöönotot myöntävät usein yhden kannettavaa kohti. Avaintiedostoa suojaava salalause on taas kolmas asia: se vartioi tiedostoa levossa eikä ole VPN-tilin salasana.

Palvelimen vahvistaminen on välttämätöntä kaikissa yhdistelmissä. Pätevät tunnistetiedot, jotka lähetetään päätepisteelle, jonka identiteettiä et enää tarkista, ovat edelleen tunnistetietoja, jotka luovutetaan sille, joka vastasi, minkä vuoksi palvelinvarmenteen tarkistus kuuluu perusprofiiliin eikä vianmääritysvaiheeseen.

Myöntäminen, vanhentuminen ja mitätöinti ovat todellinen kustannus

Salasanat ovat halpoja myöntää ja kalliita tukea: nollaukset, käytäntö, uudelleenkäyttö ja tukipalvelun jono. Varmenteet siirtävät tämän kustannuksen etupainotteiseksi, jolloin tarvitaan CA, allekirjoitusprosessi ja jakelukanava, ja lisäävät sitten vanhenemiskalenterin, jota kukaan ei muista. Molemmat tarvitsevat suunnitellun mitätöinnin. Mitätöity varmenne tarvitsee CRL:n, jonka jokainen palvelin todella lukee, ja poistettu käytöstä oleva tili tarvitsee todennuksen taustajärjestelmän hylkäämään sen seuraavalla yhteydellä eikä seuraavassa synkronoinnissa.

Kumpikaan mekanismi ei tule turvalliseksi siksi, että se on olemassa. Kysymys on siitä, mitä elinkaarta tiimi pystyy hoitamaan johdonmukaisesti.

Mikä hajoaa, kun laite katoaa

Kadonneen kannettavan kohdalla poista valtuutus, jota kyseinen laite todella käytti. Salasanan nollaus ei mitätöi sen varmennetta, eikä uuden varmenteen myöntäminen muuta toisen tilin salasanaa. Laitekohtaiset erilliset identiteetit mahdollistavat kohdennetun poistamisen, kun taas jaetut tunnistetiedot tarkoittavat, että yhden laitteen poisto vaikuttaa useisiin. Kirjoita palautusmenettely jokaiselle mekanismille ennen kuin tarvitset sitä, mukaan lukien kuka voi allekirjoittaa korvaavan varmenteen työajan ulkopuolella.

Harjoittele mitätöintipolkua sen olettamisen sijaan: mitätöi testi-identiteetti, vahvista, että palvelin hylkää sen uudella yhteydellä, ja palauta se sitten. Mitätöintiprosessi, jota ei ole koskaan harjoiteltu, tapaa epäonnistua juuri silloin, kun sitä tarvitaan.

Molempien käyttö työtä kaksinkertaistamatta

Monet käyttöönotot yhdistävät molemmat tarkoituksella: varmenne laitteelle ja tilin tunnistetieto henkilölle, jotta varastettu kannettava ei riitä eikä vuotanut salasana riitä. Yhdistelmä kannattaa vain, kun kaksi elinkaarta pysyvät erillisinä ja molemmat on automatisoitu. Muuten tukipalvelu hoitaa kahta jonoa ja turvallisuushyöty jää teoreettiseksi.

Valitse menetelmä, jota palvelun asiakkaat ja hallintatyökalut todella tukevat. Vahvistuksen heikentäminen, jotta yhteensopimaton profiili yhdistää, kääntää koko idean nurin, ja profiili, jota on muokattu kunnes se yhdistää, on usein sellainen, joka ei enää tarkista sitä, mitä varten se rakennettiin.

Kirjaa, minkä todisteen kukin käyttöönotto vaatii ja miten kukin mitätöidään. Seuraava tapaus kysyy täsmälleen sitä.