Запыт MFA да VPN адхілены: што павінен зрабіць кліент

Адхілены запыт MFA выглядае як праблема сеткі, але ёй не з'яўляецца. Сервер запытаў другі фактар, фактар вярнуўся адмоўным або не прыйшоў зусім, і сеанс быў адхілены яшчэ да ўзнікнення якога-небудзь тунеля. Тое, што адбываецца далей, — пытанне паводзінаў кліента: паказаць збой і даць карыстальніку пачаць чыстую спробу або паўтараць яе так, што гэта спараджае больш запытаў і ўрэшце ўключае абарону ўліковага запісу. Другі шлях — гэта тое, як адзін няправільна ўведзены код ператвараецца ў заблакаваны запіс.

Праверце, які запыт не ўдаўся

Пачніце з вызначэння таго, які запыт не ўдаўся. Push-апавяшчэнне, код TOTP, сцвярджэнне FIDO і паток SAML кожны правальваюцца па-свойму, і кліент звычайна ведае, які з іх запытаў. Адмова, скончаны тэрмін выкліку і збой дастаўкі, які так і не дайшоў да прылады, усе сканчаюцца адной агульнай памылкай, таму стан самога кліента часта застаецца адзіным месцам, дзе розніца захоўваецца.

Гэты стан варта запісваць дакладна. Запішыце ідэнтыфікатар выкліку або спасылку на транзакцыю, тып фактара, адзнаку часу і вынік, але ніколі — код або сцвярджэнне. Ідэнтыфікатар выкліку — гэта тое, што дазваляе адміністратару знайсці падзею на баку пастаўшчыка ідэнтычнасці; без яго размова з падтрымкай пачынаецца з «недзе за апошнюю гадзіну» і звычайна там жа і сканчаецца. Стаўцеся да яго як да дыягнастычных метаданых, а не як да сакрэту.

Паўтарыце адзін раз, свядома, з новым выклікам

Паўторная спроба павінна быць новай спробай з новым выклікам, а не прайграваннем старога. Калі кліент паўторна выкарыстоўвае папярэдні выклік, пастаўшчык ідэнтычнасці або адхіляе яго як састарэлы, або, што горш, прымае адабрэнне, прызначанае для папярэдняй спробы. Запытайце свежы выклік, пакажыце яго і дайце карыстальніку дзейнічаць з тым, што зараз на экране.

Дзве спробы з кароткай паўзай паміж імі — разумная папярэдняя налада; бясконцы цыкл — не. Калі другая спроба правальваецца гэтак жа, спыніцеся і паведаміце, а не працягвайце.

Чаго кліент не павінен рабіць

Кліент не павінен рабіць некалькі рэчаў, якія выглядаюць карыснымі, але не з'яўляюцца такімі. Ён не павінен працягваць дасылаць push-апавяшчэнні, пакуль хтосьці не націсне «адабрыць», бо гэта прывучае карыстальнікаў адабраць запыты, якія яны не ініцыявалі, і гэта менавіта тыя паводзіны, на якія разлічаны фішынгавыя наборы. Ён не павінен пераходзіць на слабейшы фактар праз тое, што моцны не спрацаваў, і не павінен адключаць праверку ідэнтычнасці сервера, каб абысці скаргу на сертыфікат, якая з'явілася адначасова. Кожны з гэтых трох кароткіх шляхоў ператварае збой аўтэнтыфікацыі ў інцыдэнт бяспекі.

Ён таксама не павінен моўчкі праглынаць збой. Кліент, які зачыняе злучэнне і паказвае круцёлку, пакідае карыстальніка без разумення, ці паўтараць, ці чакаць, ці званіць у падтрымку. Пакажыце збой з тыпам фактара і кароткім кодам, трымайце паведамленне без сакрэтаў і зрабіце дзеянне паўтору відавочным, а не аўтаматычным.

Калі запыт ініцыяваў не чалавек за клавіятурай, правільнае дзеянне — пакінуць яго адхіленым і паведаміць пра яго праз правераны шлях падтрымкі. Адабрэнне запыту, каб спыніць шум, — гэта мадэль збою, а не рашэнне.

Што запісаць для падтрымкі

Для падтрымкі карысны запіс невялікі. Прыкладны час з часовым поясам, уліковы запіс, кліент і версія, тып фактара і не сакрэтны статус кожнай спробы: запытана, адхілена, скончыўся тэрмін, адабрэна, але адхілена палітыкай.

Трымайце ў полі зроку і гадзіннікі кліента і сервера. TOTP — гэта праверка часовага акна, таму прылада, чый гадзіннік з'ехаў, спараджае коды, якія выглядаюць сапраўднымі і кожны раз правальваюцца, а кліент, які паведамляе пра несапраўдны код, не адзначаючы зруху, накіроўвае людзей скідаць уліковыя даныя, якія ніколі не былі няправільнымі. Карыстальнік, чый уваход пастаянна не ўдаецца, павінен праверыць падтрымліваную версію кліента, стан рэгістрацыі і дакументаваны шлях аднаўлення, перш чым ствараць новыя запыты.

Шлях аднаўлення заслугоўвае такой жа ўвагі, як шлях уваходу. Працэс для страчанай прылады існуе менавіта для таго, каб адмова не стала дазволам абыйсці аўтэнтыфікацыю, і кліент павінен спасылацца на дакументаваны працэс арганізацыі, а не выдумляць свой.

Правіла, на якое трэба арыентавацца: адмова — гэта вынік, а не перашкода. Паведаміце пра яе адзін раз, ясна, з дастатковым кантэкстам для дзеяння, і дайце наступнай спробе быць новай. Кіраўніцтва CISA па MFA, устойлівай да фішынгу тлумачыць, чаму схема «запытваць да адабрэння» небяспечная з самага пачатку, і гэта той даведнік, на які варта спасылацца, калі хтосьці прапануе цыкл паўторных спробаў. Усё, што кліент дадае пасля адмовы, павінна рабіць наступнае рашэнне прасцейшым для чалавека, а не забіраць рашэнне ў яго.