Регистрација VPN корисника: прво пронађите власника идентитета

Неко тражи приступ VPN-у, а први инстинкт је покренути adduser на серверу. Тај инстинкт је исправан само у уском скупу поставки. Пре него што било шта направите, отворите конфигурацију сервера и откријте који производ тамо ради и где проверава акредитиве, јер налог може живети у бази производа, код добављача идентитета или у сопственом слоју провере аутентичности домаћина. Прављење погрешне врсте налога оставља особу са радном пријавом и без тунела.

Профил клијента у којем пише OpenVPN описује протокол, а не систем идентитета иза њега.

Почните од сервера, а не од adduser

Прво идентификујте производ. Community OpenVPN је демон плус било која аутентификација коју сте на њега прикључили, док је Access Server производ са сопственим слојем корисника. Затражите конфигурацију, назив јединице и списак пакета и проверите да ли постоји веб интерфејс за управљање корисницима. Затим погледајте како распоређени профил очекује да клијенти докажу ко су: сертификатом, корисничким именом и лозинком или обојим. Тај одговор именује систем који поседује налог.

Тек након тога фраза прављење корисника има смисла. У поставци само са сертификатима то значи издавање идентитета уређаја кроз одобрени процес, а Unix пријава ништа не мења. У поставци са лозинком то значи backend који стварно проверава лозинку.

Четири backend-а, четири места за прављење налога

Локална аутентификација Access Server-а држи налоге у сопственој бази, па интерфејс за њихово прављење припада производу, а не домаћину. PAM делегира проверу слоју оперативног система, и зато локални Unix налог може бити део регистрације када је услуга изабрала управо тај слој. LDAP, RADIUS и SAML премештају проверу у спољну услугу, где живе припрема налога, политика лозинки и MFA. Access Server и у сва четири случаја може да држи сертификате и дозволе по кориснику, и то је оно што поделу чини збуњујућом.

Проверите ефективну методу за овог конкретног корисника, а не глобални подразумевани избор. Access Server 2.10 и новији може применити различите методе аутентификације по групи или кориснику, па подразумевана локална вредност не доказује да се налог пред вама проверава локално.

Право је засебна одлука

Аутентификација одговара ко је особа; право одговара до чега сме да дође. Држите то као два корака, јер успешна пријава није одобрење. Намерно доделите предвиђене руте, дозволе за ресурсе и административна права и потврдите да неповезани приступ остаје одбијен. Где поставка подржава појединачне идентитете, издајте по један по особи уместо прослеђивања туђег профила, јер се заједнички профил не може укинути за једну особу.

Клијентски материјал је такође важан. Профил са аутоматском пријавом и интерактивна корисничка пријава представљају различите односе аутентификације, а замена једног другим мења оно што сервер стварно проверава.

Укидање приступа део је регистрације

Запишите три власника док се корисник ствара: ко проверава налог, ко одобрава приступ VPN-у и који уређај или профил представља везу. То могу бити три различита система, а план укидања који именује само један од њих оставља пут отвореним. Када особа оде, уклоните право од његовог власника и укините сваку издату акредитиву код његовог власника. Брисање преузете датотеке није укидање, а није ни брисање локалног уноса ако се спољни идентитет још увек аутентификује.

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

Чувајте запис уз профил коме припада. Следећи ревизор питаће ко је могао да се повеже током датог месеца, а одговор живи у та три власника.