Нехта просіць доступ да VPN, і першы інстынкт — запусціць adduser на серверы. Гэты інстынкт правільны толькі ў вузкім наборы разгортванняў. Перш чым нешта ствараць, адкрыйце канфігурацыю сервера і высветліце, які прадукт там працуе і дзе ён правярае ўліковыя даныя, бо ўліковы запіс можа жыць у базе даных прадукту, у пастаўшчыку ідэнтычнасці або ва ўласным стэку аўтэнтыфікацыі хоста. Стварэнне ўліковага запісу не таго тыпу пакідае чалавека з працоўным лагінам і без тунэля.

Профіль кліента, у якім напісана OpenVPN, апісвае пратакол, а не сістэму ідэнтычнасці за ім.

Пачніце з сервера, а не з adduser

Спачатку вызначце прадукт. Community OpenVPN — гэта дэман плюс любая аўтэнтыфікацыя, якую вы да яго падключылі, а Access Server — гэта прадукт з уласным узроўнем карыстальнікаў. Запытайце канфігурацыю, назву юніта і спіс пакетаў, а таксама праверце, ці існуе вэб-інтэрфейс для кіравання карыстальнікамі. Затым паглядзіце, як разгорнуты профіль чакае, што кліенты дакажуць, хто яны: сертыфікат, імя карыстальніка і пароль або і тое і другое. Гэты адказ называе сістэму, якая валодае ўліковым запісам.

Толькі пасля гэтага фраза стварэння карыстальніка набывае сэнс. У разгортванні толькі з сертыфікатамі гэта азначае выдачу ідэнтычнасці прылады праз зацверджаны працэс, і лагін Unix нічога не змяняе. У разгортванні з паролем гэта азначае бэкенд, які фактычна правярае пароль.

Чатыры бэкенды, чатыры месцы для стварэння ўліковага запісу

Лакальная аўтэнтыфікацыя Access Server трымае ўліковыя запісы ў сваёй базе даных, таму інтэрфейс для іх стварэння належыць прадукту, а не хосту. PAM перадае праверку стэку аперацыйнай сістэмы, і менавіта таму лакальны ўліковы запіс Unix можа быць часткай рэгістрацыі, калі сэрвіс выбраў менавіта гэты стэк. LDAP, RADIUS і SAML пераносяць праверку ў знешні сэрвіс, дзе жывуць падрыхтоўка, палітыка пароляў і MFA. Access Server можа ўсё яшчэ трымаць сертыфікаты і дазволы для кожнага карыстальніка ва ўсіх чатырох выпадках, і менавіта гэта робіць падзел заблытаным.

Праверце эфектыўны метад для гэтага канкрэтнага карыстальніка, а не глабальнае значэнне па змаўчанні. Access Server 2.10 і пазней можа ўжываць розныя метады аўтэнтыфікацыі для групы або карыстальніка, таму значэнне па змаўчанні лакальна не даказвае, што ўліковы запіс перад вамі правяраецца лакальна.

Правы — асобнае рашэнне

Аўтэнтыфікацыя адказвае, хто гэты чалавек; правы адказваюць, чаго ён можа дасягнуць. Трымайце гэта як два крокі, бо паспяховы лагін — гэта не дазвол. Прызначце меркаваныя маршруты, правы на рэсурсы і адміністрацыйныя правы свядома і пацвердзіце, што незвязаны доступ застаецца забароненым. Там, дзе разгортванне падтрымлівае індывідуальныя ідэнтычнасці, выдавайце па адной на чалавека замест перадачы чужога профілю, бо агульны профіль нельга адклікаць для аднаго чалавека.

Кліенцкі матэрыял таксама мае значэнне. Профіль аўтаматычнага лагіну і інтэрактыўны лагін карыстальніка ўяўляюць розныя адносіны аўтэнтыфікацыі, і замена аднаго на другое змяняе тое, што сервер фактычна правярае.

Адкліканне доступу — частка рэгістрацыі

Запішыце трох уладальнікаў, пакуль ствараецца карыстальнік: хто правярае ўліковы запіс, хто дазваляе доступ да VPN і якая прылада або профіль уяўляе злучэнне. Гэта могуць быць тры розныя сістэмы, і план адклікання, які называе толькі адну з іх, пакідае шлях адкрытым. Калі чалавек сыходзіць, выдаліце правы ў іх уладальніка і адклічце кожныя выдадзеныя ўліковыя даныя ў іх уладальніка. Выдаленне спампаванага файла — не адкліканне, і выдаленне лакальнага запісу таксама, калі знешняя ідэнтычнасць яшчэ аўтэнтыфікуецца.

Затым праверце рэгістрацыю так, як гэта зрабіў бы зламыснік: падключыцеся адзін раз з новай ідэнтычнасцю, пацвердзіце доступ да меркаванага рэсурсу і пацвердзіце, што незвязаны рэсурс усё яшчэ адмаўляе. Першае працоўнае злучэнне плюс негатыўны тэст — гэта завершаная рэгістрацыя.

Трымайце запіс разам з профілем, якому ён належыць. Наступны аўдытар спытае, хто мог падключыцца на працягу пэўнага месяца, і адказ жыве ў гэтых трох уладальніках.

Падобныя артыкулы