Երկու մուտքի ստուգումը երկու գործոն չէ՝ VPN և RADIUS

VPN դարպասին երկրորդ նույնականացման backend ավելացնելը թվում է երկրորդ գործոն ավելացնել։ Սովորաբար այն ավելացնում է երկրորդ ստուգում, որը տարբեր օբյեկտ է՝ տարբեր ձախողման եղանակներով։ Արդյոք երկուսն էլ պետք է հաջողվեն, ինչ է ապացուցում յուրաքանչյուրը և ինչ է լինում, երբ մեկը հասանելի չէ, երեք առանձին որոշումներ են։ Սխալվեք, և դարպասը ցուցադրության մեջ ավելի խիստ կլինի, իսկ ընդհատման ժամանակ՝ ավելի թույլ։

Ինչ է իրականում ապացուցում երկրորդ backend-ը

Տեղական հաշվի որոնումը ապացուցում է, որ անունը գոյություն ունի տվյալների բազայում և որ գաղտնաբառը համապատասխանել է դրան։ RADIUS փոխանակումը ապացուցում է, որ RADIUS սերվերը ստացված ատրիբուտների համար վերադարձրել է Access-Accept։ Հայտարարություններից ոչ մեկը չի նշում գործոնի տեսակ, քանի որ երկուսն էլ ստուգում են գիտելիք։ Իսկ NIST-ի թվային ինքնության ուղեցույցը հաշվում է գործոնի տարբեր տեսակներ և դրանց նույնականացուցիչները, ոչ թե սերվերներ կամ հուշումներ։

Կա օրինական ձևավորում, որտեղ մասնակցում են երկու համակարգերը։ Կենտրոնական ծառայությունը կարող է նույնականացնել մարդուն, մինչ դարպասը ինքնուրույն ստուգում է, թե արդյոք այդ հաշիվն իրավունք ունի այս թունելին։ Դա լիազորում է նույնականացման կողքին, և այն երկգործոն անվանելը շփոթում է քաղաքականության ստուգումը տիրապետման ապացույցի հետ։

RADIUS-ը կարող է կրել իրական երկրորդ գործոն, երբ կանգնած է մի բանի առջև, որ ստուգում է մեկին, օրինակ push հաստատում կամ ապարատային նշան։ Ծրարը չի ասում, թե որ նույնականացուցիչներն է ներկայացրել օգտատերը, ուստի կարդացեք backend-ի քաղաքականությունը, ոչ թե դարպասի պիտակը։

AND, OR և պահեստայինը տարբեր արտադրանքներ են

Նախքան իրականացումները համեմատելը, որոշեք, թե ինչ է նշանակում երկուսն էլ ձեր պահանջի մեջ։ AND քաղաքականությունը պահանջում է, որ անցնի յուրաքանչյուր նշված ստուգում, OR քաղաքականությունն ընդունում է այն, ինչը հաջողվում է, իսկ պահեստայինը փորձում է երկրորդը միայն նշված ձախողման պայմաններում։ Այս երեքը ընդհատման ժամանակ հակառակ են վարվում, և սովորաբար դրանցից միայն մեկն է այն, ինչ նկատի ուներ վերանայումը։

Կազմաձևման էկրանին երկու backend գրառում ավելացնելը չի բացահայտում, թե որ քաղաքականությունն է կիրառում արտադրանքը։ Որոշ դարպասներ plugin-ները հաջորդաբար շղթայում են և կանգնում առաջին մերժման վրա, ինչը AND է միայն այն դեպքում, երբ յուրաքանչյուր plugin պարտադիր է։ Մյուսները տեղական հաշիվը համարում են վերագրանցում, ինչը կենտրոնական ընդհատումը դարձնում է շրջանցում։ Հուսալի պատասխանը յուրաքանչյուր ուղու համար փաստաթղթավորված բացասական թեստն է, որն անցկացվում է ձեր տեղակայվող build-ի վրա։

Պահեստայինը ամենաշատ կասկածի է արժանի, որովհետև այն գոյություն ունի, որպեսզի շարունակի աշխատել, երբ ինչ-որ բան կոտրված է։ Պահեստայինը, որն ընդունում է տեղական գաղտնաբառ, երբ RADIUS-ը հասանելի չէ, կենտրոնական քաղաքականությունը վերածել է երկրորդ, ավելի թույլ դռան։

OpenVPN-ի կրկնակի ստուգումը կոնկրետ դեպք է

Համայնքային OpenVPN 2.6-ը պահանջում է և՛ հաճախորդի վկայական, և՛ կազմաձևված auth-user-pass-verify սկրիպտ, երբ երկուսն էլ միացված են։ Դա փաստաթղթավորված AND է վկայականի ստուգման և հավատարմագրերի սկրիպտի միջև, և դա իսկապես երկու ստուգում է։ Այն դեռ ավտոմատ երկու գործոնի տեսակ չէ, քանի որ սկրիպտը կարող է ստուգել միայն գաղտնաբառ։

Համադրությունը բաց է թողնում նաև կապի հարցը։ Վկայականը սովորաբար նույնականացնում է սարք, մինչդեռ հավատարմագրերը նույնականացնում են մարդ, և լռելյայն հոսքում ոչինչ չի պահանջում, որ երկուսն էլ վերաբերեն նույն սուբյեկտին։ Որոշեք, թե որ զույգերն են թույլատրված, ապա կիրառեք այդ քարտեզը ստուգման սկրիպտի ներսում կամ ավելի ուշ լիազորման քայլում։

Միայն վկայականի ռեժիմը մեկ ստուգում է՝ հենված բանալու վրա, որը կարող է PIN-ով պաշտպանված լինել կամ չլինել։ PIN-ը նույն հավատարմագիրը դարձնում է գիտելիք գումարած տիրապետում միայն այն դեպքում, երբ բանալին առանց դրա չի կարող օգտագործվել։ Այդ բանալին սկավառակի վրա չգաղտնագրված թողնելը երկրորդ մասը հասցնում է ֆայլի թույլտվության։

Սարքերի արտադրողները կառուցում են իրենց սեփական խողովակաշարը, հաճախ PAM մոդուլ կամ RADIUS plugin՝ վեբ կոնսոլի հետևում։ Համայնքի վարքը հղում է, թե ինչպիսին են կրկնակի ստուգումները, ոչ թե նկարագրություն, թե ինչպես է սարքը դրանք համադրում։

Ստուգեք համադրությունը ձեր դարպասի վրա

Կարդացեք կազմաձևը նախքան կոնսոլի ամփոփմանը վստահելը։ Քաղաքականությունը որոշող տողերն են վկայականի ռեժիմը, հավատարմագրերի սկրիպտը և plugin-ների հերթականությունը։

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

grep-ը ցույց է տալիս՝ արդյոք վկայական է պահանջվում և ինչ սկրիպտ է գործարկվում դրանից հետո, և հերթականությունը ավելի կարևոր է, քան անունները հուշում են։ Վկայականի արտաբերումը տալիս է ինքնությունը, որը կտեսնի դարպասը, ներառյալ CN-ը և սերիական համարը, որ անհրաժեշտ են կապի քարտեզի համար։ RADIUS թեստը բացասական դեպքն է. սխալ գաղտնաբառը պետք է տա Access-Reject, իսկ ճիշտը՝ Access-Accept։ Եթե մերժված հավատարմագիրը դեռ սեսիա է տալիս, ապա սկրիպտը բոլորովին նույնականացման ուղու վրա չէ։

Այնուհետև գործարկեք ընդհատման դեպքը լաբորատոր օրինակի վրա. դադարեցրեք պարտադիր backend-ը և միացեք վավեր հավատարմագրերով։ Սպասվող արդյունքը մերժումն է, և ամեն ինչ այլ՝ այն պահեստային քաղաքականությունն է, որը ոչ ոք չի փաստաթղթավորել։

Պահանջը գրեք որպես բացասական դեպքեր

Օգտագործելի պահանջը անվանում է ապացույցները, դրանք ներկայացնելու թույլատրված հաշիվները և արդյունքը, երբ ստուգողը բացակայում է։ Այն նաև նշում է սարքի ինքնության և մարդու ինքնության միջև թույլատրված զուգավորումը։ Դա ավելի ճշգրիտ է, քան գնման պատվերի ապրանքանունները, և կարելի է ստուգել։

Ընդունումը պետք է ներառի չորս մերժում՝ ոչ պիտանի տեղական հաշիվ, բացակայող պարտադիր ապացույց, անվավեր երկրորդ գործոն և անհասանելի պարտադիր backend։ Յուրաքանչյուր մերժում պահանջում է մատյանի տող, որը տարբերում է այն մյուսներից, այլապես հաջորդ միջադեպը սկսվում է ենթադրություններով։ Գրանցեք, թե որ բաղադրիչն է կայացրել յուրաքանչյուր որոշում, քանի որ դարպասը, RADIUS սերվերը և գրացուցակը կմեղադրեն միմյանց։

Կրկնեք չորս մերժումները plugin-ի կամ firmware-ի ցանկացած փոփոխությունից հետո։ Դրանք էժան են, և այն քաղաքականությունը, որը նրանք պաշտպանում են, հարձակվողի առաջին ստուգվող մասն է։