FortiGate VPN MFA. տեղական token, RADIUS, թե SAML

Յուրաքանչյուր FortiGate VPN MFA նախագիծ սկզբում պատասխանում է մեկ հարցի՝ ո՞վ է ստուգում երկրորդ գործոնը Դարպասն ինքը կարող է դա անել տեղական token-ով կամ էլփոստով ուղարկված կոդով, RADIUS-ի backend-ը կարող է պարտադրել այն և վերադարձնել մարտահրավեր, կամ SAML-ի ինքնության մատակարարը կարող է ամբողջ արարողությունը վերցնել բրաուզերում։ Նրանցից յուրաքանչյուրը տալիս է մուտքի այլ հաջորդականություն, ձախողման այլ ստորագրություն և վերականգնման այլ ընթացակարգ, իսկ նրանց միջև հրամանների բլոկ պատճենելը ստեղծում է կոնֆիգուրացիա, որը հավաստի է թվում և ոչ մեկին չի նույնականացնում։ Սա մեխանիզմի մասին հոդված է՝ ինչ է իրականում անում յուրաքանչյուր նախագիծ մուտքի ընթացքում և որտեղ է կոտրվում։

Մուտքի արարողությունը որոշում է, թե ով է տիրապետում գործոնին

Առաջին երկու նախագծերում FortiGate-ը վստահող կողմն է։ Այն հավաքում է հավատարմագրերը, որոշում է՝ արդյոք անհրաժեշտ է երկրորդ գործոն, և ստուգում է այն տեղում կամ մարտահրավերի միջոցով։ Երրորդ նախագծում դարպասը դադարում է ստուգող լինելուց և դառնում է փոխանցող՝ այն վերահասցեավորում է հաճախորդին ինքնության մատակարարի մոտ, ստանում է պնդում և քարտեզագրում է հաստատված ինքնությունը օգտվողի և խմբի հետ։ RADIUS-ի նախագծում այն գտնվում է նրանց միջև և վարում է հարցում-պատասխան փոխանակում քաղաքականությունը պահող backend-ի հետ։

Այդ տարբերությունը որոշում է, թե ինչ ապացույցներ կարող եք հավաքել։ Երբ դարպասը ստուգում է, նրա սեփական վրիպազերծման ելքը ձեզ ասում է, թե ինչ է տեղի ունեցել։ Երբ ստուգում է ինքնության մատակարարը, դարպասը միայն գիտի, որ պնդում է ժամանել, և «արդյոք MFA-ն իսկապես պահանջվում էր» հարցի պատասխանը գտնվում է մատակարարի մատյաններում, ոչ թե firewall-ի։ Սխալ մատյան կարդալը նախագծին ճիշտ համապատասխան աշխատող տեղադրումը սխալ ախտորոշելու ամենատարածված ձևն է։ Ծառայությունն ինքն էլ սահմանափակում է արարողությունը՝ FortiOS 7.6.3-ը հեռացնում է SSL VPN թունելի ռեժիմը հօգուտ IPsec-ի, մինչդեռ վեբ ռեժիմը շարունակվում է որպես Agentless VPN աջակցվող մոդելներում, ուստի մեկ ծառայության վրա ապացուցված արարողությունը ինքնաբերաբար հասանելի չէ մյուսում։

Տեղական ստուգում՝ token-ներ և էլփոստի կոդեր

FortiGate-ի կողմից կառավարվող գործոնները կցվում են օգտվողի օբյեկտին։ FortiToken-ը կամ փաստաթղթավորված token-ի ինտեգրումը պահանջում է գրանցում, աջակցվող ստուգման արարողություն, լիցենզավորում՝ որտեղ կիրառելի է, և փոխարինման ընթացակարգ։ Էլփոստով ուղարկված կոդը պահանջում է աշխատող SMTP ուղի և փոստարկղ, որին օգտվողը կարող է հասնել մինչև թունելի գոյությունը, կախվածություն, որը կապ չունի գաղտնագրության հետ և ամբողջովին կապված է այն հարցի հետ, թե արդյոք ինչ-որ մեկը կարող է մուտք գործել։

config user local
    edit "jdoe"
        set type password
        set two-factor fortitoken
        set fortitoken FTKMOB1234567890
    next
end

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

Հավաստիացման պահանջները նույնպես այստեղ են՝ մինչև ապրանքի ընտրությունը։ NIST SP 800-63B-ը էլփոստը համարում է անընդունելի արտաքին նույնականացման համար, ուստի համապատասխանություն պնդող տեղադրումը չի կարող էլփոստի կոդը որպես երկրորդ գործոն օգտագործել, որքան էլ այն հարմար լինի։ Սարքի վրա ֆունկցիայի առկայությունը չի հայտարարում, որ ֆունկցիան բավարարում է տվյալ ստանդարտին։

RADIUS՝ դարպասը հարցնում է, backend-ը որոշում

RADIUS-ի դեպքում FortiGate-ը հավատարմագրերը ուղարկում է backend-ին, որը տիրապետում է գործոնի քաղաքականությանը։ Փոխանակումը կարող է լինել պարզ ընդունում կամ մերժում, կամ այն կարող է ներառել մարտահրավեր, որին հաճախորդը պետք է պատասխանի, ինչը նշանակում է, որ և՛ VPN ծառայությունը, և՛ հաճախորդը պետք է աջակցեն մարտահրավերի այդ ձևին։ Push հաստատում պարտադրող backend-ը և հաճախորդը, որը միայն գիտի գաղտնաբառին վեցանիշ կոդ ավելացնել, մեջտեղում չեն հանդիպի։

config user radius
    edit "corp-radius"
        set server "10.10.20.15"
        set secret ENCXXXXXXXX
        set secondary-server "10.10.20.16"
    next
end
diagnose test authserver radius corp-radius pap jdoe <password>

Փորձարկեք backend-ը ինքնուրույն, նախքան թունելին մեղադրելը։ Եթե authserver-ի թեստը հաջողվի, իսկ VPN մուտքը՝ ոչ, տարբերությունը մարտահրավերի մշակման մեջ է, ոչ թե հավատարմագրերի, և դարպասի նույնականացման դեմոնի վրիպազերծումը այն տեղն է, որտեղ դա երևում է:

diagnose debug application fnbamd -1
diagnose debug enable

SAML՝ բրաուզերը լքում է դարպասը

SAML-ի նախագծում հաճախորդը վերահասցեավորվում է ինքնության մատակարարի մոտ, այնտեղ նույնականացվում է և վերադառնում է պնդումով, որը դարպասը վավերացնում է վստահության հարաբերության և խմբի քարտեզագրման դեմ։ Դարպասը երբեք չի տեսնում գաղտնաբառը կամ երկրորդ գործոնը, ինչը միաժամանակ անվտանգության բարելավում և գործառնական բարդություն է՝ ձախողումն այժմ տեղի է ունենում բրաուզերի սեսիայում, որը firewall-ը չի կարող ստուգել։

Պնդում ընդունելը չի ապացուցում, որ մատակարարը MFA պահանջել է այդ մուտքի համար։ Մատակարարի քաղաքականությունը, որը MFA է կիրառում որոշ հավելվածների վրա և ոչ մյուսների, կտա ճիշտ այն մուտքը, որը դուք խնդրել եք, և ոչինչ այն հավաստիացումից, որը դուք ենթադրել եք։ Ստուգեք մատակարարի քաղաքականությունը հենց այս հավելվածի համար և ստուգեք, որ խմբային պնդումների քարտեզագրումը FortiGate-ի խմբերին դեռ համընկնում է ցանկացած կողմի ցանկացած վերանվանումից հետո։

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

Վերականգնումը մեխանիզմի մասն է

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

Այնուհետև փորձարկեք երեք մուտք նախքան տեղադրումը՝ սովորականը, մերժված կամ ժամկետանց գործոնը, և կորսված նույնականացուցիչի հաստատված վերականգնումը։ Գրանցեք, թե յուրաքանչյուրը որ մատյանում է երևում։ Հենց այդ գրառումն է «MFA-ն միացված է» արտահայտությունը վերածում նախագծի, որը կարող է շահագործել մեկ ուրիշը։