Дали на iPad му треба сопствен VPN клиентски сертификат?

Нов iPad се придружува на тимот, а најбрзиот пат е да се извезе постоечкиот клиентски сертификат и да се инсталира на таблетот. Тоа работи додека некој не замине, не изгуби уред или не побара ревизија што ќе каже кој уред и кога се поврзал. Одлуката не е за датотеката со сертификат туку за идентитетот: дали секој уред може самостојно да се овласти и отповика. Трошокот и напорот за управување ја одредуваат одговорот, и двете се помали отколку што изгледаат.

Заеднички издавач, одделни идентитети

Секој уред може да му верува на истото сертификациско тело и да се поврзе со истиот портал додека има друг клиентски идентитет. Издавачот е сидро на доверба, а идентитетот е пар клучеви чиј субјект серверот го мапира на политика. Токму мешањето на двете го прави споделениот сертификат да изгледа безопасен. Тој останува безопасен само додека некому не му треба да знае кој уред отворил сесија.

Споделувањето на издавачот заштедува конфигурациска работа и не менува ништо во одговорноста по уред. Споделувањето на идентитетот ги собира сите уреди во една отповиклива единица: отповикувањето на еден ги отповикува сите, а овластувањето замена го овластува секое кога и да е направено копие од клучот. Таа размена вреди да се направи експлицитно наместо со копирање датотека затоа што е побрзо во петок попладне.

Кога вториот сертификат чини премногу

Регистрацијата по уред чини еден чекор: управуван профил, барање SCEP или воден увоз со еднократна лозинка. Таа бара и место за следење на сериски броеви и датуми на истекување, делот што повеќето распоредувања го забораваат додека не истече првиот сертификат. Двата трошоци се еднократни и двата се намалуваат штом текот на регистрација ги автоматизира.

Трошокот е реален за домаќинство со два таблети и еден корисник, каде споделениот идентитет е разумна одлука документирана во една реченица. Тој не е разумен за услуга каде пристапот мора да се повлече по личност или по уред, бидејќи приказната за отповикување е целата причина да се користат сертификати наместо лозинка. Проценете го распоредувањето по тоа колку често уредите менуваат сопственик, а не по тоа колку уреди постојат денес.

Регистрирајте го уредот, не копирајте го клучот

Современите платформи ги чуваат приватните клучеви во заштитено складиште, а некои ги означуваат како неизвезни по дизајн. Токму тоа својство го прави копирањето невозможно од почеток, и тоа е причината зошто извезен пакет од преносен сметач не може едноставно да се увезе повторно на таблет на ниту еден поддржан начин. Обидот сепак создава профил што се инсталира чисто и потоа никогаш не автентицира.

Користете го методот на регистрација што распоредувањето веќе го поддржува: управуван профил за идентитет, услуга SCEP или тек заснован на сметка што издава нов клуч на уредот. Дистрибуирањето на приватниот клуч на сертификациското тело за решавање на идентитет што недостига е друга грешка со многу поголем радиус на влијание. Телото издава акредитиви и никогаш не треба да патува до крајната точка.

Проверете го отповикувањето пред да одговорите

Пред да ја изберете споделената опција, опишете како изгледа отповикувањето на најлошиот ден. Ако одговорот е една акција што влијае на неколку уреди, дизајнот веќе одлучил против вас.

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

Прегледајте го материјалот што навистина го имате: дали има приватен клуч, што вели субјектот и дали серискиот број може да се отповика одделно. Датотека со сертификат без својот клуч не може ништо да автентицира, и затоа некои копирани идентитети пропаѓаат при првото поврзување.

Бришењето апликација од таблетот не е отповикување, а серверот продолжува да го прифаќа идентитетот додека некој не го оневозможи. Запишете ја таа реченица во процедурата пред да се регистрира првиот уред.