Treba li iPad vlastiti klijentski certifikat za VPN?

Novi iPad pridružuje se timu, a najbrži put je izvesti postojeći klijentski certifikat i instalirati ga na tablet. To radi dok neko ne ode, ne izgubi uređaj ili ne zatraži reviziju koja kaže koji se uređaj i kada povezao. Odluka nije o datoteci certifikata nego o identitetu: može li se svaki uređaj samostalno ovlastiti i opozvati. Trošak i upravljački napor određuju odgovor, a oboje je manje nego što izgleda.

Zajednički izdavatelj, odvojeni identiteti

Svaki uređaj može vjerovati istom certifikacijskom tijelu i povezati se s istim pristupnikom dok nosi drugi klijentski identitet. Izdavatelj je sidro povjerenja, a identitet je par ključeva čiji subjekt poslužitelj preslikava u pravilo. Upravo stapanje to dvoje čini zajednički certifikat naizgled bezopasnim. On ostaje bezopasan samo dok nekome ne zatreba znati koji je uređaj otvorio sesiju.

Dijeljenje izdavatelja štedi konfiguracijski rad i ne mijenja ništa u odgovornosti po uređaju. Dijeljenje identiteta sažima svaki uređaj u jednu jedinicu koja se može opozvati: opoziv jednoga opoziva sve, a ovlaštenje zamjene ovlašćuje svaku kopiju ključa ikad izrađenu. Tu zamjenu vrijedi napraviti izričito, a ne kopiranjem datoteke jer je brže u petak poslijepodne.

Kada drugi certifikat košta previše

Upis po uređaju košta jedan korak: upravljani sadržaj, SCEP zahtjev ili vođeni uvoz s jednokratnom zaporkom. Košta i mjesto za praćenje serijskih brojeva i datuma isteka, dijela koji većina implementacija zaboravi dok prvi certifikat ne istekne. Oba su troška jednokratna i oba se smanjuju kad tok upisa ih automatizira.

Trošak je stvaran za kućanstvo s dva tableta i jednim korisnikom, gdje je zajednički identitet razumna odluka dokumentirana u jednoj rečenici. Nije razuman za uslugu u kojoj se pristup mora povući po osobi ili po uređaju, jer je priča o opozivu cijeli razlog za korištenje certifikata umjesto zaporke. Procijenite implementaciju po tome koliko često uređaji mijenjaju vlasnika, a ne po tome koliko uređaja danas postoji.

Upišite uređaj, ne kopirajte ključ

Suvremene platforme drže privatne ključeve u zaštićenom spremištu, a neke ih po dizajnu označavaju kao neizvozive. To svojstvo kopiranje čini nemogućim od početka, a i razlog je zašto se izvezeni paket s prijenosnika ne može jednostavno ponovno uvesti na tablet ni na jedan podržan način. Pokušaj to ipak čini profil koji se čisto instalira i zatim nikada ne autentificira.

Koristite metodu upisa koju implementacija već podržava: upravljani sadržaj identiteta, SCEP uslugu ili tok zasnovan na računu koji izdaje novi ključ na uređaju. Dijeljenje privatnog ključa certifikacijskog tijela radi rješavanja nedostajućeg identiteta druga je pogreška s mnogo većim dosegom. Tijelo izdaje vjerodajnice i nikada ne smije putovati do krajnje točke.

Provjerite opoziv prije nego što odgovorite

Prije nego odaberete zajedničku opciju, opišite kako opoziv izgleda na najgori dan. Ako je odgovor jedna radnja koja pogađa nekoliko uređaja, dizajn je već odlučio protiv vas.

openssl pkcs12 -in client.p12 -info -noout
openssl x509 -in client.pem -noout -subject -issuer -serial -dates
openssl verify -CAfile ca.pem client.pem

Pregledajte materijal koji stvarno držite: postoji li privatni ključ, što kaže subjekt i može li se serijski broj opozvati pojedinačno. Datoteka certifikata bez svog ključa ne može ništa autentificirati, i zato neki kopirani identiteti padaju na prvoj vezi.

Brisanje aplikacije s tableta nije opoziv, a poslužitelj nastavlja prihvaćati identitet dok ga netko ne onemogući. Zapišite tu rečenicu u runbook prije nego što se prvi uređaj upiše.