Бұлтсыз екі факторлы аутентификацияны қалай баптайды

Ұйым тексеру серверлерін, кілт материалын, уақыт көздерін және қалпына келтіру тәртібін өзі басқаруға дайын болса, бұлтсыз екі факторлы аутентификация толық жұмыс істейді. Әкімшілер үшін жүйені телефондағы кодтарға сүйеніп құрмас едім. Негізгі тәсіл аппараттық криптографиялық кілтті немесе смарт-картаны қолдануы керек, ал TOTP үйлесімділік пен алдын ала жоспарланған резерв үшін қалғаны дұрыс.

Негізгі қателік компания кіру нүктелерін сипаттамай тұрып, бір қорап кілт сатып алған кезде басталады. Доменге интерактивті кіру, VPN, SSH, RDP, гипервизор консолі және желілік жабдық панельдері әртүрлі хаттамаларды қолданады. Бір токен тіркелгі деректерінің бірнеше түрін сақтай алады, бірақ олар осыдан біртұтас жүйеге айналмайды. Алдымен екінші фактордың қай жерде тексерілетінін, доменмен байланыс үзілгенде не болатынын және резервтік құпиясөзді тұрақты айналып өту жолына айналдырмай, қолжетімділікті кім қайтаратынын шешу керек.

Жергілікті аутентификация контуры қалай құрылады

Жергілікті контурға интернет қажет емес, бірақ оның өз сенімді тексеру торабы болуы керек. Ең қарапайым сұлбада тіркелгі каталогта қалады, ал бөлек компонент аппараттық кілтке иелік етуді дәлелдейтін жауапты немесе ортақ TOTP құпиясын тексереді. VPN шлюздері мен басқа қашықтан кіру нүктелері оған RADIUS, LDAP, Kerberos немесе жергілікті PAM модулі арқылы сұрау жібереді. Журналдар, конфигурацияның резервтік көшірмелері және уақыт көздері де ұйымның ішінде қалады.

Жүйені төрт рөлге бөлген дұрыс. Каталог тұлғалар мен топтарға жауап береді. Тексеру торабы екінші факторды қабылдайды. Қолжетімділік нүктесі шешімді орындайды және қосалқы жолға рұқсат бермейді. Тіркеу процесі нақты аутентификаторды нақты әкімшімен байланыстырады. Егер бір сервер төрт рөлді де атқарса, оның істен шығуы кіруді тоқтатады, ал бұзылуы шабуылдаушыға тіркелгілерді де, құпияларды да береді.

Маңызды контурға әртүрлі ақау аймағында орналасқан кемінде екі тексеру торабы қажет. Олар бірдей саясаттар мен құрылғыларды кері қайтару туралы өзекті жазбаларды алуы керек, бірақ интернетке шығуы міндетті емес. TOTP дерекқорының немесе сертификаттау орталығының резервтік көшірмесі қорғалған шифрлау кілттерімен және тексерілген қалпына келтіру тәртібімен бірге болғанда ғана пайдалы. Кілтсіз дерекқор көшірмесі жарамсыз, ал дерекқор мен кілтті бір мұрағатта сақтау ұрлаушының жұмысын тым жеңілдетеді.

Өнімді таңдамас бұрын кіру нүктелерінің кестесін жасаңыз. Әр жолға хаттаманы, қазіргі тұлға дерегінің көзін, MFA тәсілін, желісіз кездегі әрекетті, журналдың орнын және төтенше қолжетімділік иесін жазыңыз. Мұндай кесте веб-панельдің TOTP қолдайтынын, SSH FIDO кілттерін түсінетінін, ал ескі консоль тек құпиясөз қабылдайтынын бірден көрсетеді. Сол соңғы жол әкімшілік контурдың шын мәніндегі қорғанысын анықтайды.

Аппараттық кілт үш түрлі мағына беруі мүмкін

Жергілікті инфрақұрылымға аппараттық кілтті жалғағышы немесе қорабының пішіні бойынша емес, хаттамасы бойынша таңдаңыз. Өндірушілер FIDO2/U2F, PIV үйлесімді смарт-карта және аппараттық OATH-TOTP генераторын бір атауға жиі біріктіреді. Бұл режимдер әртүрлі міндетті шешеді және серверде әртүрлі із қалдырады.

Айырмасын қысқа жадынамада ұстауға болады:

• FIDO2/U2F нақты сервиске арналған жабық кілтті сақтайды, ал сервис қолтаңба мен сұрауды тексереді. Бұл режим веб арқылы кіруге, SSH және PAM үшін жарайды.
• PIV немесе смарт-карта PKI, Kerberos не TLS тексеретін жабық кілт пен сертификатты сақтайды. Бұл режим доменге кіруге, RDP және VPN үшін жарайды.
• OATH-TOTP ортақ құпия мен уақыт санауышын сақтайды, ал кодты жергілікті TOTP сервері салыстырады. Бұл режим ескі VPN мен қолданбаларға керек.

Хаттама жауапты тексеруші сервистің атауымен байланыстырса, FIDO2 фишингтен жақсы қорғайды. NIST SP 800-63B мұндай криптографиялық байланысты бір реттік кодты қолмен енгізуден нақты ажыратады. Шабуылдаушы жарамды TOTP кодын алдап сұрап, оны бірден шынайы VPN-ге жібере алады, ал жалған мекенжай үшін жасалған FIDO қолтаңбасы шынайы мекенжайда өтпейді.

PIV сертификаттарды қолданады және Active Directory, RDP мен TLS клиенттік аутентификациясына жақсы үйлеседі. Бұл үйлесімділік толыққанды PKI қажет етеді: сертификат үлгілері, сенімді түбірлер, кері қайтару тізімдерін жариялау, жаңарту, тасымалдағыштарды есепке алу және сертификаттау орталығының кілтін қорғау. CRL мен домен контроллері сертификаттарының мерзіміне ешкім жауап бермесе, смарт-карталар ең қолайсыз сәтте әкімшілерді кіргізбей қояды.

Аппараттық TOTP токені иелік ету мен есеп тұрғысынан жеке телефондағы қолданбадан жақсырақ, бірақ оның хаттамасы әлі де ортақ құпияны қолданады. Кодты тексеретін серверде дәл сол seed болуы керек. Осы дерекқор сыртқа шықса, шабуылдаушы физикалық құрылғыларды ұрламай-ақ генераторларды көшіре алады. Аппараттық қорап TOTP-ті ашық кілтке негізделген сұлбаға айналдырмайды.

Сатып алу кезінде қажетті режимдердің дәл қолданылатын операциялық жүйе мен клиент нұсқаларында қолдауын, PIN орнату мүмкіндігін, әрекет санының шегін, тазарту тәртібін, есепке алуға арналған бірегей сериялық нөмірді және оқшауланған желіде микробағдарламаны жаңарту тәсілін тексеріңіз. Себепсіз аралас парк сатып алмаңыз. Сырты бірдей, бірақ апплеттері бөлек екі кілт сатып алуда үнемдегеннен көп қолдау қатесін туғызады.

TOTP бұлтсыз жұмыс істейді, бірақ тәуекелді серверге көшіреді

TOTP-ті жергілікті ортада жаю оңай, өйткені алгоритмге ортақ құпия мен синхрондалған уақыт қана керек. RFC 6238 мәнді уақыт санауышынан алынған HOTP ретінде анықтайды және 30 секундтық қадамды ұсынады. Стандарт әр генераторға бірегей құпия талап етеді және жеткізу кідірісіне ең көбі бір көршілес қадамды қабылдауды ұсынады. Ыңғайлы болсын деп терезені бірнеше минутқа кеңейтпеңіз. Әр қосымша қадам ұрланған код жарамды болатын уақытты ұзартады.

Тексеру тораптары уақытты кемінде екі ішкі көзден алуы, ал бұл көздер бақыланатын жоғары деңгейлі тірекке сүйенуі керек. Ағымдағы ауытқумен бірге синхрондау ақауларын да бақылаңыз. Виртуалды машина суреттен қалпына келгеннен кейін оның сағаты артқа жылжып, кәдімгі инфрақұрылым ақауын бүкіл кезекші ауысым үшін кіру тоқтауына айналдыруы мүмкін.

Seed мәндерін каталогта, конфигурация репозиторийінде немесе қолдау өтінімінде ашық сақтауға болмайды. Тексеру серверіне құпияның кері ашылатын түрі керек, сондықтан қарапайым хештеу жеткіліксіз. Дерекқорды бөлек мастер-кілтпен шифрлаңыз, қызметтік тіркелгінің құқықтарын шектеңіз және деректердің көшірмесін мастер-кілт көшірмесінен бөлек сақтаңыз. Каталог әкімшісі барлық TOTP құпиясын экспорттау мүмкіндігін автоматты түрде алмауы керек.

QR-код арқылы тіркеу де зиянсыз суретті емес, құпияның өзін береді. Тіркеуді тұлғаны бетпе-бет немесе соған тең қатаң тәсілмен тексергеннен кейін басқарылатын жұмыс орнында өткізіңіз. QR-кодты электрондық поштамен жібермеңіз және өтінім жүйесінде қалдырмаңыз. Тіркеуден кейін әкімшіден қатарынан екі код енгізуді сұраңыз, құпияның уақытша тасымалдағышын жойыңыз және seed орнына токен идентификаторын жазыңыз.

TOTP-тің орынды қолданылатын жері бар: сертификаттарды немесе FIDO-ны түсінбейтін жабдық, төтенше VPN клиенті және көшу кезеңі. Оны аппараттық қолтаңбамен тең деп жарияламаңыз. NIST OTP-ті бұрын қолданылған мәнді қайталауға төзімді деп санайды, бірақ фишингке төзімді санамайды, өйткені пайдаланушы кодты тексерушіге қолмен береді. Бұл айырма атауға емес, қорғанысқа әсер етеді.

Доменге кіруге кілт қана емес, PKI қажет

Active Directory ішінде интерактивті кірудің сенімді жергілікті жолы сертификаты бар смарт-картаға немесе PIV режиміне сүйенеді. Домен контроллері сертификатты тіркелгімен сәйкестендіріп, сенім тізбегін тексереді. Қарапайым FIDO2 кілтін классикалық домендік кіруге арналған смарт-картаның тікелей баламасы деп санамаңыз. Қолдау көрсетілетін тіркелгі деректері провайдері мен бөлек архитектура болмаса, Windows кілт USB портына салынғаны үшін ғана оны қабылдамайды.

Microsoft-тың смарт-картамен кіру құжаттамасы сертификатты шығарған орталықтың NTAuth қоймасында болуын және домен контроллерлерінде жарамды сертификаттардың болуын талап етеді. Клиент пен контроллер түбірге сенуі керек. Пайдаланушы сертификаты тіркелгімен дұрыс сәйкестенуі, кілт мақсаты дұрыс берілуі және кері қайтару деректері қолжетімді болуы қажет. UPN, тізбек немесе CRL қатесі кезекшіге тіркелгі деректерін тексеру мүмкін болмады деген көмескі хабар болып жиі көрінеді.

Кері қайтаруды тексеруге бөлек сынақ арнаңыз. CRL жариялау нүктесі қолжетімсіз болса немесе тізім мерзімі өтсе, жұмыс істейтін кілт пен дұрыс PIN болғанның өзінде кіруге тыйым салынуы мүмкін. CRL-ді қажет әр желілік аймаққа орналастырыңыз, жарамдылық мерзімін сертификаттау орталығын қалпына келтіруге жететін қорымен белгілеңіз және кезекшілерге Next Update уақытына дейін ертерек хабарлаңыз. Қолжетімділік үшін кері қайтару тексерісін өшіруге болмайды. Онда жоғалған сертификат мерзімі біткенше жұмыс істей береді.

Сынақ жұмыс станциясында карта мен тізбек туралы деректі жүйелік пәрменмен тексеруге болады:

certutil.exe -scinfo

Нәтижеден табылған оқу құрылғысын, кілт контейнерін, кіру сертификатын, сенімді түбірге дейінгі тізбекті және кері қайтару тексерісінің нәтижесін іздеңіз. Утилитаның құрылғыны көруі доменге кірудің дайын екенін дәлелдемейді. Тексерісті әр аймақтан және нақты әкімшілік профильді қайталайтын тіркелгімен іске қосыңыз.

«Интерактивті кіруге смарт-карта қажет» саясатын кезеңмен қосу керек. Алдымен әр әкімшіге тіркелген екі тасымалдағыш беріңіз, жұмыс станциясы мен RDP арқылы кіруді тексеріңіз, содан кейін талапты пилоттық топқа қосыңыз. Кіріктірілген немесе қызметтік тіркелгілерден бастамаңыз. Олардың міндеті мен техникалық шектеулерін бөлек талдау қажет.

Доменнен ажыратылған ноутбук бөлек жағдай туғызады. Microsoft автономды кіруді контроллердің сертификатты жаңадан онлайн тексеруі емес, кэштелген тіркелгі деректерін тексеру деп сипаттайды. Кэш саясатын, сертификат мерзімін, ажыратылғанға дейінгі CRL қолжетімділігін және кері қайтарудан кейінгі әрекетті өз Windows жинағыңызда тексеріңіз. Жаңа дерек алмайтын машинада кілттің бірден кері қайтарылуына уәде беруге болмайды.

Linux жүйесінде екінші фактор шифрланған home бөлімінен тәуелсіз болуы керек

Linux аппараттық FIDO/U2F кілтін PAM арқылы жергілікті тексере алады, бірақ сәйкестендіру файлын жүйе пайдаланушы кіргеннен кейін ғана жететін жерге жасыруға болмайды. pam_u2f нұсқаулығы mapping файлы шифрланған үй каталогында тұрып, каталог аутентификациядан кейін ашылса, кіру мүмкін болмайтынын арнайы ескертеді. Жүйеге кіру үшін сәйкестендірулерді root пайдаланушысы home каталогын тіркемей тұрып оқи алатын қорғалған файлда сақтаңыз.

PAM жолының ең қарапайым түрі мынадай:

auth required pam_u2f.so authfile=/etc/security/u2f_mappings cue

required сөзі маңызды. Келесі модуль құпиясөзді қабылдаса да, екінші фактор қатесі бүкіл стектің сәтсіз аяқталуына әкелуі керек. Бірақ модульдердің реті дистрибутив пен кіру тәсіліне байланысты. Алдымен root консолін ашық қалдырып, pam_u2f синтаксисін, файл құқықтарын және сынақ пайдаланушысының екі кілтін тексеріңіз, содан кейін ғана өзгерісті SSH, sudo немесе экран менеджеріне көшіріңіз.

SSH үшін OpenSSH ішіндегі security key қолдауы ыңғайлырақ. Кілт әкімшінің жұмыс станциясында жасалады, ал серверге тек ашық бөлігі жіберіледі:

ssh-keygen -t ed25519-sk -O verify-required -C "admin@infrastructure"

Күтілетін диалог құрылғыны салуды, оған қол тигізуді және қолдау болса, PIN арқылы пайдаланушыны тексеруді сұрайды. verify-required параметрі серверге жай ғана физикалық жанасуды емес, пайдаланушының жергілікті тексерілгені туралы белгіні талап еткізеді. Жаппай шығарудың алдында клиент пен сервердегі OpenSSH нұсқалары таңдалған кілт түрін қолдайтынына көз жеткізіп, тек бөлек консоль арқылы ашылатын төтенше жолды сақтаңыз.

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

Қашықтан қолжетімділікті алғашқы кіру нүктесінде жабыңыз

Екінші факторды әкімшілік трафик ішкі желіге жетпей тұрып VPN шлюзінде, бастионда немесе RD Gateway торабында тексеріңіз. Егер VPN құпиясөзді қабылдап, тек бір сервердің веб-панелі MFA сұраса, ұрланған тіркелгі ішкі мекенжайларды сканерлеп, екінші фактор орнатылмаған хаттамаларға шабуыл жасай алады.

Бұлтсыз VPN үшін қалыпты сұлба екі жергілікті RADIUS торабынан, каталогтан және таңдалған MFA модулінен тұрады. Шлюз RADIUS сұрауын жібереді, тексеру торабы әкімшілік топқа мүшелікті және екінші факторды тексеріп, ең аз қажетті қолжетімділік профилімен рұқсат қайтарады. Әр клиентке бөлек RADIUS құпиясын орнатыңыз, сұрау көздерін желіаралық экранмен шектеңіз және шлюздің әкімшілік хаттамасын пайдаланушы VPN-інен бөлек қорғаңыз.

VPN хаттамаларының бәрі екі өрісті ыңғайлы жеткізе бермейді. Кей клиенттер құпиясөз бен TOTP-ті бір жолға біріктіреді, басқалары бөлек сұрауды қолдайды, ал аппараттық қолтаңбаға мүлде басқа алмасу керек. Тексеру серверін таңдамас бұрын нақты клиентті, соның ішінде мобильді резервті сынаңыз. «RADIUS қолдайды» деген белгі пайдаланушы екінші факторды қалай енгізетінін немесе шлюз қате құпиясөзді қате кодтан ажырата алатынын түсіндірмейді.

RDP кезінде смарт-карта әкімшінің жанында қала береді. Remote Desktop Services қашықтағы сессияның сұрауларын жергілікті оқу құрылғысына бағыттайды. Microsoft құжаттамасы домендер арасында кіргенде KDC сертификаттарына, сенімді түбірлерге және UPN мәніне бөлек талаптар қояды. Тікелей RDP, шлюз арқылы кіру және бар сессияға қайта қосылуды бөлек сценарий ретінде тексеріңіз. Алмасу буферіне тыйым салу тіркелгі құрылғыларын қайта бағыттауды бақылаудың орнына жүрмейді.

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

Журнал сыртқы шлюздегі сұрауды, MFA шешімін, домендік тіркелгіні және мақсатты сессияны байланыстыруы керек. Төрт дереккөздің де уақытын синхрондаңыз. Токен атауы мен сұрау идентификаторы жоқ «код қабылданды» жазбасы тергеуге аз көмектеседі, ал ортақ төтенше тіркелгі тәуекел ең жоғары кезде нақты адамды жасырады.

Резервтік кіру жасырын айналып өту жолына айналмауы керек

Жұмыс істейтін резерв негізгі кілтпен бірге тіркеліп, бөлек сақталатын екінші жеке аппараттық кілттен басталады. Бұл түнде MFA-ны асығыс өшіруден оңай әрі қауіпсіз. Кезекші топтың резервтік кілті берілу журналы бар бақыланатын бөлмеде сақталуы мүмкін, бірақ ол ортақ тіркелгіге емес, бәрібір нақты адамға байлануы керек.

Екінші резерв деңгейі бүкіл MFA жүйесі істен шыққан жағдайға керек. Күнделікті жұмыста қолданылмайтын, ұзын кездейсоқ құпиясөзі бар және сол тексеру торабына тәуелді емес бір немесе бірнеше төтенше тіркелгі жасаңыз. Құпиясөзді алуды екі жауапты тұлғаға бөліңіз немесе қос бақылау ережесі бар қорғалған қойманы қолданыңыз. Әрбір алу тәуелсіз арна арқылы бірден хабарлама жасауы керек.

Бір реттік recovery-кодтар жүйе оларды мықты хеш түрінде сақтап, әр кодты бір рет қабылдап және қолдануын журналға жазғанда ғана жарайды. Сервер жанында жатқан басылған тізім қағаз иесіне толық әкімшілік қолжетімділік береді. Инфрақұрылым үшін екінші кілт пен ресми төтенше тіркелгіні дұрыс көремін. Оларды есепке алу, кері қайтару және жаттығуда тексеру оңайырақ.

Резерв сол ақау себебін қайталамауы керек. Тексеру дерекқоры зақымданса, екі TOTP қолданбасы көмектеспейді. CRL мерзімі өтсе, екі смарт-карта сертификаты көмектеспейді. Бұлт қоймасындағы төтенше құпиясөз оқшауланған алаңға көмектеспейді. Әр тәсіл үшін каталогқа, PKI, DNS, уақытқа, желіге, қоймаға және нақты адамдарға тәуелділікті жазыңыз.

Төтенше кіруді кесте бойынша тексеріңіз, бірақ тексерісті күнделікті әкімшілік жұмысқа айналдырмаңыз. Әр қолданудан кейін құпиясөзді өзгертіңіз, уақытша желіаралық экран ережелерін жабыңыз, берілген сессияларды кері қайтарыңыз және себебін талдаңыз. Төтенше тіркелгі апта сайын қолданылса, ол резерв емес, нашар бақыланатын негізгі жол.

Құрылғы жоғалғанда кері қайтару жылдамдығы маңызды

Құрылғы PIN арқылы қорғалып, бөгде адам құпиясөзді білмесе, жоғалған кілт тіркелгінің бірден бұзылғанын білдірмейді. Бірақ қолдау қызметі кілтті тапқан адамның ниетін болжауға тиіс емес. Ол кілт пен пайдаланушының байланысын жылдам жойып, PKI болса сертификатты кері қайтарып, құрылғының жоғалғаны хабарланған уақыттан кейін қолданылғанын тексеруі керек.

Жұмыс тәртібі бес әрекеттен тұрады:

1. Өтініш берушінің тұлғасын жоғалған құрылғыны қолданбай, алдын ала бекітілген рәсіммен тексеріңіз.
2. Уақытты, сериялық нөмірді немесе credential ID мәнін, тіркелгілерді және жоғалған ықтимал орынды тіркеңіз.
3. Нақты аутентификаторды барлық тексеру жүйесінде өшіріп, сертификатты кері қайтарыңыз және жаңа CRL жариялаңыз.
4. Иесінің белсенді VPN, веб, SSH және RDP сессияларын аяқтап, соңғы сенімді қолданудан кейінгі оқиғаларды қараңыз.
5. Қалыпты тіркеу арқылы жаңа негізгі кілт беріп, тексергеннен кейін резервтік кілтті қайтадан резервке қойыңыз.

Егер бүкіл тіркелгіні бұғаттау алаңды жалғыз кезекші әкімшісіз қалдырса, оны автоматты түрде жасамаңыз. Шешім құпиясөз ұрланғанының белгілеріне, күмәнді сессияларға және басқа оператордың бар-жоғына байланысты болуы керек. Жоғалған кілттің қолданылғаны расталса, тіркелгіні бұғаттау, байланысты құпияларды ауыстыру және оқиғаны тергеу міндетті.

FIDO үшін тіркелген credential ID немесе ашық кілт жойылады. PIV үшін сертификат сериялық нөмірі бойынша кері қайтарылып, жаңа CRL барлық тексеру торабына жеткізіледі. TOTP үшін seed жойылады, ал код құпиясөзбен бірге алдап алынуы мүмкін болса, құпиясөз ауыстырылады. Құрылғы нөмірін түгендеу кестесінен сызып тастау жеткіліксіз.

Жаттығу «кезекші инженер негізгі кілтін жоғалтып, кеңседен тыс жерде қалды» деген жағдайдан басталып, резерв арқылы расталған кірумен және жоғалған құрылғыны толық кері қайтарумен аяқталуы керек. Уақытты әдемі көрсеткіш үшін емес, бір келісушіні күту, ашылмайтын сейф немесе тек өшірулі серверден қолмен жарияланатын CRL сияқты бөгеттерді табу үшін өлшеңіз.

Пилот өндірістік іске қосуға дейін сұлбаны бұзуы керек

Жақсы пилот сәтті кірумен бірге ақауларды да тексереді. Жұмыс станциялары әртүрлі бірнеше әкімшіні таңдап, барлық қолжетімділік түрін қосыңыз: жергілікті консоль, VPN, SSH, RDP, құқық көтеру, гипервизор мен желілік жабдықты басқару. Әр нүктеде негізгі кілтті, резервтік кілтті, қате PIN-ді, бұғатталған токенді, мерзімі өткен сертификатты және қолжетімсіз тексеру торабын сынаңыз.

Бір RADIUS торабын тоқтатып, сынақ серверіндегі уақыт синхрондауын бұзыңыз, CRL-ді қолжетімсіз етіңіз және жұмыс станциясын доменнен ажыратыңыз. Күтілетін әрекет сынаққа дейін жазылуы керек. Егер команда MFA істен шыққанда құпиясөзге рұқсат беруді ақау үстінде шешсе, архитектура дайын емес.

Бақылау мүмкіндігін тексеріңіз. Кезекші бір әрекет бойынша пайдаланушы атын, құрылғы идентификаторын, қолжетімділік нүктесін, әр фактордың нәтижесін және сәтсіздік себебін таба алуы керек. Журналда TOTP seed, PIN, recovery-код немесе толық RADIUS құпиясөзі болмауы тиіс. Журналды оқуға оқиғаларды тергейтін адамдарға рұқсат беріп, MFA саясатын өзгерту құқығын оқиғаларды көру құқығынан бөліңіз.

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

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

Таңдау хаттамалар мен ақау моделінен басталады

Инфрақұрылым негізінен қазіргі SSH пен веб-интерфейстерден тұрса, PIN коды бар FIDO2 кілттерін және жеке тіркелгілерді таңдар едім. Классикалық Windows доменіне кіру мен RDP үшін дұрыс қызмет көрсетілетін PKI бар PIV немесе смарт-карта қисындырақ. TOTP криптографиялық кілттерді түсінбейтін жүйелерге үйлесімділік қабаты ретінде жарайды, бірақ оның seed дерекқорын әкімшілік құпиясөз қоймасындай қорғау қажет.

Барлық жерде бір тәсілді сөзбе-сөз талап етпеңіз. Бірдей нәтиже талап етіңіз: әкімшілік кірудің алғашқы нүктесінде екі тәуелсіз фактор, әр әрекетті нақты адаммен байланыстыру, жылдам кері қайтару және тексерілген резерв. Осы ереже астындағы хаттамалар әртүрлі болуы мүмкін, әйтпесе бір ескі құрылғы бүкіл контурдың қорғанысын әлсіретеді.

Шешімдерді салыстырғанда автономды құжаттаманы, қолдау көрсетілетін хаттамалар мен нұсқалар тізімін, резервтік көшірме экспортының пішімін, мастер-кілттерді қорғау тәсілін, әкімшілік өзгерістер журналын және лицензиялау не жаңарту сервері істемегендегі тәртіпті сұраңыз. «On-premises» сөзі өздігінен ештеңеге кепіл болмайды. Өнім лицензияны интернет арқылы тексеруі, қалпына келтіру кезінде тәуелділіктерді жүктеуі немесе конфигурацияның бір бөлігін жеткізушіде сақтауы мүмкін.

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

Ең қолайсыз шешімді сатып алуға дейін қабылдаңыз: MFA істен шыққанда ұйым жабық қолжетімділікті ме, әлде құпиясөзбен айналып өтуді ме таңдайды. Әкімшілік контурда әр шлюзге құпиясөзге көшуге рұқсат бергеннен гөрі, тәуелсіз әрі қатаң бақыланатын резерв құрған қауіпсіз. Әйтпесе алғашқы ақау командаға жаңа енгізілген қорғанысты айналып өтуді үйретеді.