Ինչո՞ւ պաշտպանել գաղտնաբառը, եթե կարելի է հրաժարվել դրանից

Խնդիր, որը մենք սովոր ենք նորմալ համարել

Գրեթե յուրաքանչյուր վեբ հավելված ունի վարչական վահանակ։ Իսկ վարչական վահանակը, որպես կանոն, ունի մուտքի հասցե, նույնականացման ձև, օգտանուն և գաղտնաբառ։

Մենք այնքան ենք սովորել այս կառուցվածքին, որ գրեթե դադարել ենք հարցնել՝ արդյո՞ք ամեն ինչ պարտադիր պետք է հենց այսպես աշխատի։

Երբ մեկ կայք ունես, խնդիրը էական չի թվում։ Ստեղծում ես բարդ գաղտնաբառ, միացնում երկգործոն նույնականացումը, կարգավորում մուտքի փորձերի սահմանափակումը և աշխատում։

Բայց ի՞նչ է տեղի ունենում, երբ նախագծերը դառնում են տասը, քսան կամ երեսուն։

Իմ դեպքում խոսքը DigiMeld էկոհամակարգի մասին է, որը միավորում է ավելի քան երեսուն ինքնուրույն ծրագրային նախագիծ։ Յուրաքանչյուրն ունի սեփական ճարտարապետությունը, սերվերային տրամաբանությունն ու վարչական միջերեսը։

Հետևաբար, յուրաքանչյուրին անհրաժեշտ է վարչական հասանելիության մեխանիզմ։

Երկար ժամանակ ես կիրառում էի միանգամայն սովորական մոտեցում․ առանձին վարչական հաշվի տվյալներ, բարդ գաղտնաբառեր և դրանց պահպանումը բրաուզերում։

Դա աշխատում էր։

Բայց ինչ-որ պահի մտածեցի՝ ինչո՞ւ ընդհանրապես պետք է այդքան վարչական գաղտնաբառ պահեմ։ Ինչո՞ւ եմ ստիպված պաշտպանել ոչ միայն սերվերները, այլև դրանց հասանելիություն ստանալու միջոցները։

Եվ հնարավո՞ր է արդյոք հրաժարվել այդ անհրաժեշտությունից։

Ես հանգեցի մի մտքի, որն ավելի ուշ դարձավ իմ լուծման հիմքը․

Գուցե պետք է պաշտպանել ոչ թե մշտական մուտքը, այլ ժամանակավորապես հասանելիություն ստանալու իրավունքը։

Իսկ ի՞նչ, եթե ընդունված մուտքի էջ ընդհանրապես չլինի

Ես որոշեցի իմ նախագծերում հրաժարվել վարչական նույնականացման ավանդական մոդելից։

Ոչ թե պարզապես թաքցնել մուտքի ձևը։

Ոչ թե փոխել հասցեն։

Ոչ թե գաղտնաբառը փոխարինել ավելի բարդ գաղտնաբառով։

Այլ վերացնել մշտապես գոյություն ունեցող՝ գաղտնաբառով մուտքի անհրաժեշտությունը։

Իհարկե, վարչական միջերեսները ոչ մի տեղ չեն անհետացել։ Դրանք դեռ անհրաժեշտ են հավելվածները կառավարելու համար։

Փոխվել է դրանց հասանելիություն ստանալու եղանակը։

Այժմ միացված նախագծերի վարչական վահանակներ մուտք գործելու համար պահպանված օգտանուն ու գաղտնաբառ մուտքագրելու կարիք չկա։

Դրա փոխարեն ես օգտագործում եմ MeldID նույնականացման և հասանելիության կառավարման սեփական համակարգը։

Գաղափարը բավականին պարզ է․ վարչական հասանելիություն տրվում է միայն այն ժամանակ, երբ այն իսկապես անհրաժեշտ է՝ կոնկրետ օգտվողին և կոնկրետ նախագծին։

Ընդ որում, միայն հաշվի գոյությունը դեռ չի նշանակում, որ օգտվողն իրավունք ունի բացելու վարչական վահանակը։

Այդ իրավունքը պետք է տրամադրվի առանձին։

Հասանելիություն, որը մեկ րոպե առաջ գոյություն չուներ

Սա, թերևս, ամբողջ հայեցակարգի ամենահետաքրքիր մասն է։

Ավանդական մոդելում ադմինիստրատորը մշտապես ունի մուտքի միջոցներ։ Նա կարող է դրանք օգտագործել այսօր, վաղը կամ մեկ ամիս անց՝ քանի դեռ դրանք վավեր են։

Ես որոշեցի փոխել այս սկզբունքը։

Մշտական վարչական հաշվի տվյալների փոխարեն կիրառվում է մուտքի գործընթացը նախաձեռնելու ժամանակավոր հնարավորություն։

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

Բայց նույնիսկ այդպիսի ժամանակավոր հղման առկայությունն ինքնին դեռ հասանելիություն չի տալիս։

Սա սկզբունքային պահ է։

Ենթադրենք՝ ինչ-որ մեկը ինչ-որ կերպ ստացել է հղումը։ Միայն հասցեի գաղտնիության վրա հիմնված սովորական համակարգում նման արտահոսքը կարող էր լուրջ խնդիր դառնալ։

Իմ մոդելում հղումը միայն թույլ է տալիս սկսել հաստատման գործընթացը։

Շարունակելու համար անհրաժեշտ է առանձին թույլտվություն՝ MeldID վստահելի շարժական սարքի միջոցով։

Առանց համապատասխան հաստատման վարչական սեսիա չի ստեղծվում։

Հենց այդ պատճառով էլ ժամանակավոր հղումը համարում եմ ոչ թե գաղտնաբառի փոխարինող, այլ հասանելիություն տրամադրելու ընթացակարգի տարրերից մեկը։

Իմանալը, թե ուր դիմել, և մուտք գործելու իրավունք ունենալը բոլորովին տարբեր բաներ են։

Հեռախոսը դառնում է հասանելիությունը կառավարելու գործիք

Այս մոդելում շարժական սարքը շատ ավելի կարևոր դեր ունի, քան մեկանգամյա կոդերի սովորական գեներատորը։

Այն օգտագործվում է վարչական հասանելիության հետ կապված գործողությունները հաստատելու համար։

Երբ ուզում եմ բացել վարչական վահանակը, համակարգը MeldID-ի միջոցով հաստատում է պահանջում։

Ես համապատասխան հարցումը տեսնում եմ վստահելի սարքում և հաստատում գործողությունը։

Եվ միայն ստուգումը հաջող անցնելուց հետո է համակարգը թույլ տալիս շարունակել մուտքի գործընթացը։

Ընդ որում, հաստատումը կապված է կոնկրետ գործողության հետ, այլ ոչ թե պարզապես հեռախոսն ապակողպելու փաստի։

Շարժական սարքի կենսաչափական տվյալներն ապահովում են օգտվողի տեղային ստուգումը, իսկ սերվերային կողմը ստուգում է գրանցված սարքի գաղտնագրային հաստատումը։

Այս մոտեցումը թույլ է տալիս հույսը չդնել բացառապես գաղտնաբառի կամ այն հաղորդագրության վրա, թե օգտվողն իբր հաստատել է մուտքը։

Եվ այստեղ ի հայտ է գալիս ևս մեկ առավելություն․ վստահելի սարքերը կարելի է կառավարել։

Եթե սարքն այլևս չպետք է օգտագործվի հասանելիությունը հաստատելու համար, կարելի է չեղարկել դրա վստահելի կարգավիճակը։

Դրանից հետո այն դադարում է լինել համապատասխան գործողությունների նույնականացման գործող միջոց։

Մեկ համակարգ՝ բազմաթիվ անկախ նախագծեր

Երբ սկսեցի մշակել այս մեխանիզմը, գլխավոր խնդիրներից մեկն այն էր, որ յուրաքանչյուր նախագիծ պահպանի իր ինքնուրույնությունը։

Ես չէի ուզում բոլոր վարչական վահանակները միավորել մեկ հսկայական հավելվածի մեջ։

DigiMeld-ի յուրաքանչյուր ծառայություն պետք է շարունակի կառավարել սեփական տրամաբանությունը, կարգավորումները, օգտվողներին և տվյալները։

Ուստի ես տարանջատեցի երկու խնդիր։

MeldID-ը պատասխանատու է նույնականացման և վարչական հասանելիություն տրամադրելու համար։

Իսկ նախագիծն ինքն է պատասխանատու սեփական վարչական գործառույթների և գործող լիազորությունների ստուգման համար։

Արդյունքում ստացվեց հասանելիության կառավարման կենտրոնացված մոդել՝ առանց հենց հավելվածները կենտրոնացնելու անհրաժեշտության։

Բացի այդ, իրավունքները տրամադրվում են առանձին։

Մի նախագծի ադմինիստրատորը մյուսների հասանելիությունն ինքնաբերաբար չի ստանում միայն այն պատճառով, որ ունի MeldID հաշիվ։

Յուրաքանչյուր վարչական ուղղության համար կարելի է սահմանել թույլտվություն ունեցող օգտվողների առանձին շրջանակ։

Միևնույն ժամանակ, սովորական օգտվողների իրավունքներն ու վարչական լիազորությունները տարանջատված են։

Տասնյակ ծառայություններից բաղկացած էկոհամակարգի համար սա հատկապես հարմար եղավ։

Ինչո՞ւ եմ նախընտրում ժամանակավոր հասանելիությունը մշտականից

Կա ևս մեկ սկզբունք, որը ես գիտակցաբար ներդրել եմ համակարգում։

Վարչական հասանելիությունը չպետք է պահպանվի անվերջ։

Թույլտվությունը գործում է սահմանափակ ժամանակ և դադարում է գործել՝ անկախ նրանից, թե օգտվողը շարունակում է աշխատել բրաուզերում, թե ոչ։

Ժամկետի ավարտից հետո աշխատանքը շարունակելու համար անհրաժեշտ է նոր հաստատման ընթացակարգ։

Սա թույլ չի տալիս, որ մեկ անգամ կատարված նույնականացումը վերածվի մշտապես գործող իրավունքի։

Բայց միայն ժամանակի սահմանափակումը բավարար չէ։

Կարևոր է արդեն տրամադրված հասանելիությունը ժամկետից շուտ դադարեցնելու հնարավորությունը։

Այդ պատճառով MeldID-ում նախատեսված է վարչական թույլտվությունների կենտրոնացված չեղարկում։

Երբ թույլտվությունը չեղարկվում է, միացված նախագծերը ստանում են համապատասխան իրադարձությունը և անվավեր են դարձնում դրա հետ կապված վարչական սեսիաները։

Այսպիսով, հասանելիության կառավարումը չի ավարտվում այն պահին, երբ օգտվողը հաջողությամբ մուտք է գործում։

Ինձ համար լիազորությունները չեղարկելու հնարավորությունը նույնքան կարևոր է, որքան դրանք տրամադրելու հնարավորությունը։

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

Իսկ ի՞նչ է փոխվել առօրյա աշխատանքում

Նախևառաջ, այլևս կարիք չկա մշտապես դիմելու պահպանված վարչական գաղտնաբառերին։

Այլևս կարիք չունեմ բրաուզերում պահելու հաշվի տվյալների հավաքածու՝ յուրաքանչյուր միացված վարչական վահանակ մուտք գործելու համար։

Դրա փոխարեն թույլտվությունները կառավարում եմ միասնական մեխանիզմի միջոցով։

Ընտրում եմ անհրաժեշտ նախագիծը, հաստատում հասանելիությունը և աշխատում։

Երբ վարչական հասանելիությունն այլևս պետք չէ, այն կարելի է չեղարկել։

Հատկապես հարմար է այն, որ նոր նախագծի ի հայտ գալու դեպքում վարչական նույնականացման ամբողջ համակարգը նորից նախագծելու կարիք չկա։

Բավական է այն միացնել արդեն գոյություն ունեցող մոդելին և սահմանել անհրաժեշտ թույլտվությունները։

Իհարկե, սա չի նշանակում, որ անվտանգության բոլոր ռիսկերը վերացել են։

Ժամանակավոր թույլտվությունները, վստահելի սարքերը, սերվերային սեսիաներն ու կենտրոնական ենթակառուցվածքը նույնպես պաշտպանության կարիք ունեն։

Բայց այլևս պետք չէ յուրաքանչյուր հավելվածի համար առանձին լուծել վարչական գաղտնաբառերի կառավարման նույն խնդիրը։

Եվ հենց դա էր իմ սկզբնական նպատակներից մեկը։

Մի՞թե նման տեխնոլոգիաներ արդեն գոյություն չունեն

Իհարկե, գոյություն ունեն։

Անգաղտնաբառ նույնականացումը, արտոնյալ հասանելիության կառավարումը, ժամանակավոր թույլտվություններն ու վստահելի սարքերի միջոցով հաստատումը վաղուց հայտնի են տեղեկատվական անվտանգության ոլորտում։

Նման մոտեցումներ կիրառվում են Identity and Access Management, Privileged Access Management համակարգերում և Zero Trust հայեցակարգերում։

Ես չեմ հավակնում, թե այս սկզբունքներն իմ հայտնագործությունն են։

Իմ խնդիրն այլ էր։

Ինձ անհրաժեշտ էր ստեղծել սեփական, ինտեգրված համակարգ, որը լուծում է DigiMeld ենթակառուցվածքի կոնկրետ խնդիրները և թույլ է տալիս կառավարել բազմաթիվ ինքնուրույն նախագծերի վարչական հասանելիությունը։

Արդյունքում ես միավորեցի մի քանի հայտնի մոտեցումներ՝ իմ պահանջներին համապատասխանող մեկ ճարտարապետության մեջ։

Եվ կարծում եմ, որ ինժեներական աշխատանքի արժեքը պարտադիր չէ, որ նոր տեխնոլոգիա հորինելու մեջ լինի։

Երբեմն այն կայանում է խնդիրը ճիշտ ձևակերպելու և դրա համար հարմար լուծում գտնելու մեջ։

MeldID-ը միայն վարչական վահանակների համար չէ

Այստեղ պետք է առանձին մի ճշգրտում անել։

MeldID-ը ստեղծվել է ոչ միայն որպես իմ սեփական վարչական հասանելիության գործիք։

Այն նաև ծրագրավորողներին տրամադրում է SDK՝ սեփական հավելվածներում նույնականացման և մուտքի հաստատման մեխանիզմները ինտեգրելու համար։

Ավելին, այդ SDK-ն հասանելի է անվճար։

Օրինակ՝ կողմնակի ծրագրավորողը կարող է MeldID-ն օգտագործել որպես օգտվողի նույնականացման լրացուցիչ հաստատման շերտ։

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

Օգտվողը հարցում է ստանում վստահելի շարժական սարքում, որտեղ կարող է հաստատել կամ մերժել մուտքի փորձը։

Սա թույլ է տալիս նվազեցնել չարտոնված հասանելիության վտանգը, եթե հաշվի տվյալները վտանգվել են։

Կարևոր է տարբերել MeldID-ի այս՝ բոլորին հասանելի հնարավորությունը DigiMeld նախագծերի համար իմ մշակած վարչական հասանելիության մոդելից։

Դրանք կիրառում են վստահության և գործողությունների հաստատման ընդհանուր սկզբունքներ, բայց լուծում են տարբեր խնդիրներ։

Անվտանգությունը միայն գոյություն ունեցողը պաշտպանելը չէ

Այս համակարգի վրա աշխատանքն ինձ ստիպեց այլ կերպ նայել նույնականացման ընդունված մեխանիզմներին։

Մենք հաճախ փորձում ենք պաշտպանել այն, ինչ գոյություն ունի պատմական պատճառներով։

Ավելացնում ենք նոր ստուգումներ, սահմանափակումներ, լրացուցիչ գաղտնաբառեր և պաշտպանության շերտեր։

Երբեմն դա իսկապես անհրաժեշտ է։

Բայց երբեմն ավելի օգտակար է մեկ այլ հարց տալ․

Պարտադի՞ր է, որ հենց պաշտպանվող մեխանիզմը նախկին տեսքով գոյություն ունենա։

Իմ դեպքում պատասխանը բացասական էր։

Ինձ մշտապես հասանելի վարչական մուտքի ձև պետք չէր։

Ինձ անհրաժեշտ էր վարչական լիազորություններ անվտանգ ստանալու հնարավորություն՝ հենց այն ժամանակ, երբ դրանք պետք են։

Սրանք երկու տարբեր խնդիրներ են։

Եվ առաջինից երկրորդին անցնելը փոխեց ոչ միայն տեխնիկական ճարտարապետությունը, այլև նախագծերի հետ ամենօրյա աշխատանքը։

Ոչ թե վերջնական կետ, այլ ընտրված ուղղություն

Այսօր այս ճարտարապետությունն արդեն աշխատում է DigiMeld էկոհամակարգի զգալի մասում։

Մնացած նախագծերն աստիճանաբար տեղափոխվում են վարչական հասանելիության նոր մոդելին։

Միգրացիան իրականացնում եմ հաջորդաբար՝ ստուգելով յուրաքանչյուր հավելվածի աշխատանքը, իսկ անցումն ավարտելուց հետո նախատեսում եմ լրացուցիչ աուդիտ անցկացնել ամբողջ համակարգում։

Միջերեսի առանձին տարրերն ու սեսիաների կառավարման կանոնները դեռ կարող են փոխվել։

Բայց հիմնական գաղափարն արդեն հստակ է։

Չեմ ուզում վերադառնալ այն մոդելին, որտեղ սեփական տասնյակ նախագծերը կառավարելու համար պետք է մշտապես պահեմ ու օգտագործեմ տասնյակ վարչական գաղտնաբառեր։

Միևնույն ժամանակ, սեփական իրականացումը չեմ համարում բոլորի համար ունիվերսալ լուծում։

Տարբեր կազմակերպություններ ունեն տարբեր պահանջներ, ենթակառուցվածքներ, սպառնալիքների մոդելներ և կառավարման եղանակներ։

Այն, ինչը հարմար ու հիմնավորված է DigiMeld էկոհամակարգի համար, պարտադիր չէ, որ օպտիմալ լինի մեկ այլ ծրագրավորողի համար։

Այնուամենայնիվ, լիազորությունները ժամանակավորապես տրամադրելու սկզբունքն արժանի է ուշադրության։

Ամփոփելու փոխարեն

Ես որոշեցի կիսվել այս փորձով ոչ թե այն պատճառով, որ ինձ նոր նույնականացման եղանակի հայտնագործող եմ համարում։

Եվ ոչ էլ այն պատճառով, որ ուզում եմ հերթական համակարգը ներկայացնել որպես բացարձակապես պաշտպանված։

Բացարձակ անվտանգություն գոյություն չունի։

Ինձ պարզապես հետաքրքիր է հենց հարցի ձևակերպումը։

Մշտական վարչական մուտքն անվերջ պաշտպանելու փոխարեն կարելի է վերանայել դրա գոյության անհրաժեշտությունը։

Բազմաթիվ գաղտնաբառեր պահելու փոխարեն՝ օգտագործել ժամանակավոր թույլտվություններ։

Առաջին նույնականացումից հետո ինքնաբերաբար վստահելու փոխարեն՝ հաստատել կոնկրետ լիազորությունների տրամադրումը։

Սեսիայի ավարտին սպասելու փոխարեն՝ նախատեսել հասանելիությունը կենտրոնացված կարգով չեղարկելու հնարավորություն։

Եվ վերջապես, յուրաքանչյուր նախագծում առանձին մուտքի մեխանիզմ ունենալու փոխարեն՝ ստեղծել վարչական հասանելիության կառավարման միասնական համակարգ՝ պահպանելով հավելվածների ինքնուրույնությունը։

Ես չեմ պնդում, թե այս մոտեցումը բացառում է վտանգման հնարավորությունը։

Այն պարզապես շեշտը մշտապես գոյություն ունեցող հաշվի տվյալների պաշտպանությունից տեղափոխում է լիազորությունների վերահսկվող տրամադրման ու դադարեցման վրա։

Գուցե երբեմն հարձակման մակերեսը նվազեցնելու ամենաարդյունավետ միջոցը պաշտպանության հերթական մեխանիզմ ավելացնելը չէ, այլ հրաժարվելն այն բանից, առանց որի համակարգը կարող է լիովին աշխատել։

Հենց այս մտքից էլ ինձ համար սկսվեց MeldID Admin Gateway-ի պատմությունը։