Парольден бас тартуға болатын болса, оны неге қорғау керек?

Біз қалыпты нәрсе деп үйреніп кеткен мәселе

Кез келген дерлік веб-қосымшаның әкімшілік панелі болады. Ал әкімшілік панельде, әдетте, кіру мекенжайы, авторизация пішіні, логин мен пароль бар.

Біз бұл құрылымға соншалықты үйреніп кеткенбіз, тіпті бәрі дәл осылай жұмыс істеуі міндетті ме деген сұрақты қоюды да қойдық.

Бір сайтың болғанда, мәселе елеулі көрінбейді. Күрделі пароль жасап, екі факторлы аутентификацияны қосып, кіру әрекеттерінің санын шектейсің де, жұмыс істей бересің.

Ал жобалар саны он, жиырма немесе отызға жеткенде не болады?

Менің жағдайымда сөз отыздан астам дербес бағдарламалық жобаны біріктіретін 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 тарихы мен үшін дәл осы ойдан басталды.