EAP մեթոդը նախ՝ ինչ գաղտնաբառի հեշ կարող է օգտագործել VPN-ը
VPN-ը ստուգում է գաղտնիքը, ոչ թե վեբ հեշը։ Կարդացեք մեթոդը, ապա ստուգեք, թե ինչ է պահում պահոցը, նախքան խոստանալ, որ նույն գաղտնաբառերը կշարունակեն աշխատել։
Շատ թիմեր ունեն աշխատող վեբ մուտք և VPN, որը մերժում է նույն աղյուսակից եկած ամեն գաղտնաբառ։ Վեբ հավելվածը համեմատում է իր իսկ հաշվարկած հեշը, մինչդեռ թունելը հաճախորդից պահանջում է ապացուցել գաղտնիքի տիրապետումն այնպես, որ սերվերը պետք է կարողանա ստուգել։ Դրանք տարբեր պահանջներ են պահված նյութի նկատմամբ։ Հենց այդ երկուսի միջև ընկած բացվածքում են կանգ առնում այս նախագծերի մեծ մասը։
Նախ կարդացեք մեթոդը, հետո՝ սխեման
Գրի առեք, թե ընտրված մեթոդը ինչ ապացույց է պահանջում, նախքան որևէ սխեմայի նայելը։ Մարտահրավեր-պատասխան մեթոդին անհրաժեշտ է նյութ, որից սերվերը կարող է հաշվարկել սպասվող պատասխանը, ինչը գործնականում նշանակում է գաղտնաբառը կամ համատեղելի ածանցյալ ձև։ Այն մեթոդը, որը գաղտնաբառը կրում է պաշտպանված թունելի ներսում, պահանջում է հենց գաղտնաբառը ստուգողի մոտ։ Կարդացեք մեթոդի փաստաթղթերը ստուգողի պահանջի համար, ոչ թե հաճախորդի կարգավորման, որովհետև հաճախորդի պահանջները սովորաբար հեշտ մասն են։
Ժամանակակից վեբ շրջանակի արտադրած աղած հեշը ոչ մեկը չի տալիս։ Այն ստուգում է մեկ կոնկրետ համեմատություն և հնարավոր չէ վերադարձնել այն գաղտնիքին, որից առաջացել է։
Մարտահրավեր-պատասխանը չի կարող օգտագործել աղած հեշ
MSCHAPv2-ը մարտահրավեր-պատասխան փոխանակում է, ուստի սերվերը երբեք չի ստանում գաղտնաբառը և չի կարող համեմատել պահված տող։ Նա պետք է սպասվող պատասխանը բխեցնի արդեն իսկ ունեցած նյութից, և դրա համար են համատեղելի պահված ձևերն այդքան նեղ։ Մեկ օգտագործողի համար աղով bcrypt կամ Argon2 արժեքը միակողմանի է այնպես, որ ամբողջությամբ բացառում է փոխանակումը։ Ստորև բերված աղյուսակը սկսվում է պահման ձևից, ոչ թե մեթոդի անունից, որովհետև հենց պահման ձևն է որոշում պատասխանը։
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
SQL փլագինի փաստաթղթերը strongSwan-ի համար սահմանում են սեփական սխեմա կարգավորման և հավատարմագրերի համար, և նախագիծը դեռ նշում է այդ փլագինը որպես փորձարարական։ Դրանցում ոչինչ չի հարմարվում հավելվածի օգտագործողների աղյուսակին և չի գուշակում, թե որ հեշավորման սխեման է ստեղծել պահված արժեքը։ Այսպիսով, իրատեսական տարբերակներն են՝ տեղափոխվել պահոց, որը դարպասը կարող է օգտագործել, կամ աութենտիֆիկացիայի ծառայություն գոյություն ունեցող պահոցի առջևում, որը կարող է կատարել փոխանակումը։ Մնացած ամեն ինչ միակցիչ է՝ ներսում թաքնված ենթադրությամբ։
RADIUS-ը տեղափոխում է աշխատանքը, ոչ թե պահանջը
EAP-ը RADIUS սերվերին պատվիրակելը փոխում է, թե որտեղ է կատարվում ստուգումը, և սովորաբար լավացնում է աուդիտի հետքը։ Այն չի վերականգնում գաղտնաբառը միակողմանի հեշից, ուստի աութենտիֆիկացիայի ծառայությունը դեռ պետք է ունենա իր ավարտած մեթոդին համատեղելի նյութ։ Թիմերը դա իմանում են RADIUS ուղին կառուցելուց և մյուս ծայրում նույն պատին հանդիպելուց հետո։
Այնտեղ, որտեղ RADIUS սերվերը կարող է կարդալ համատեղելի հավատարմագրով գրացուցակ, լուծումն աշխատում է, և VPN դարպասը մնում է պարզ։ Այնտեղ, որտեղ չի կարող, ազնիվ պատասխանը գրանցման փոփոխությունն է, ոչ թե ևս մեկ միակցիչ։ Տրամադրումը և չեղարկումը պատկանում են նրան, ով տիրապետում է ինքնությանը, ուստի աջակցվող համաժամացման գործընթաց չունեցող պատճենված աղյուսակը հավատարմագրերի երկրորդ կենսացիկլն է, ոչ թե միասնական մուտք։ Այն սկսում է տարբերվել առաջին անգամ, երբ ինչ-որ մեկը գաղտնաբառը վերականգնում է միայն մեկ տեղում, և այդ տարբերությունը լուռ է, մինչև երկու համակարգերում էլ գոյություն ունեցող հաշիվը յուրաքանչյուրում այլ կերպ չվարվի։
Սահմանափակեք գրացուցակը կարդացող հաշիվը հենց այդ ընթերցմամբ և պահեք այն առանձին այն հաշվից, որն օգտագործում է դարպասը սեփական կարգավորման համար։ Ընդհանուր ադմինիստրատիվ հաշիվը միայն կարդալու ձևավորումը վերածում է շատ ավելի լայն ազդեցության շառավիղի։
Որտեղ պետք է ապրի հաշիվը
Երբ նյութի հարցը լուծված է, մնում են երկու ճարտարապետություն։ Դարպասը կարող է ունենալ հավատարմագրերի փոքր պահոց, որը կարդում է միայն ինքը, կամ պատվիրակել աութենտիֆիկացիայի ծառայությանը, որը կանգնած է կորպորատիվ գրացուցակի առջևում։
Առաջինն ավելի հեշտ է մտովի կառավարել և ավելի վատ է օգտագործողի համար, ով վերջում երկրորդ գաղտնաբառ ունի պահելու։ Երկրորդը պահպանում է մեկ ինքնություն և ավելացնում կախվածություն ծառայությունից, որը հիմա պետք է աշխատի նախքան որևէ մեկը կմիանա։ Ոչ մեկը սխալ չէ, բայց ընտրությունը պետք է գրանցվի դարպասի կարգավորման կողքին, այլապես հաջորդ ինժեները կենթադրի, որ ընտրվել է մյուսը։ Ինչ էլ ընտրեք, ստորև բերված երկու հրամաններն են, որ ցույց են տալիս ընթացիկ վիճակը նախքան այն փոխելը։
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsՀաշվի աութենտիֆիկացիան չի լուծում նաև լիազորումը։ Խմբային անդամակցությունը, սարքի վիճակը և ցանցի թույլտվությունը դեռ պահանջում են բացահայտ քարտեզագրում այն բանից հետո, երբ օգտագործողն ապացուցել է պահանջվող ինքնությունը։ Միացումը, որը կատարելապես աութենտիֆիկացվում է և ոչինչ չի լիազորում, քաղաքականության արդյունք է, ոչ թե մեթոդի խնդիր։