Kërkesa MFA e VPN refuzuar: çfarë duhet të bëjë klienti

Një kërkesë MFA e refuzuar duket si problem rrjeti dhe nuk është. Serveri kërkoi një faktor të dytë, faktori u kthye negativ ose nuk mbërriti kurrë, dhe sesioni u refuzua përpara se të ekzistonte ndonjë tunel. Ajo që ndodh më pas është çështje e sjelljes së klientit: të shfaqë dështimin dhe ta lërë përdoruesin të nisë një përpjekje të pastër, ose të ripërpiqet në mënyra që krijojnë më shumë kërkesa dhe përfundimisht aktivizojnë mbrojtjen e llogarisë. Rruga e dytë është ajo ku një kod i shtypur gabimisht bëhet një llogari e bllokuar.

Kontrolloni cila kërkesë dështoi

Filloni duke identifikuar cila kërkesë dështoi. Njoftimi push, kodi TOTP, deklarata FIDO dhe një rrjedhë SAML dështojnë secili ndryshe, dhe klienti zakonisht e di cilën kërkoi. Refuzimi, sfida e skaduar dhe dështimi i dorëzimit që nuk arriti kurrë në pajisje përfundojnë të gjitha në të njëjtin gabim gjenerik, prandaj dallimi shpesh mbijeton vetëm në gjendjen e vetë klientit.

Vlen ta regjistroni atë gjendje me saktësi. Regjistroni identifikuesin e sfidës ose referencën e transaksionit, llojin e faktorit, vulën kohore dhe rezultatin, por kurrë kodin ose deklaratën. Identifikuesi i sfidës është ajo që i lejon administratorit të gjejë ngjarjen në anën e ofruesit të identitetit; pa të, biseda me suportin nis me «diku gjatë orës së fundit» dhe zakonisht mbaron atje. Trajtojeni si metadata diagnostike, jo si sekret.

Riprovoni një herë, me qëllim, me një sfidë të re

Një ripërpjekje duhet të jetë një përpjekje e re me një sfidë të re, jo një riprodhim i asaj të vjetre. Kur klienti ripërdor sfidën e mëparshme, ofruesi i identitetit ose e refuzon si të vjetëruar ose, më keq, pranon një miratim që ishte menduar për përpjekjen e mëparshme. Kërkoni një sfidë të freskët, shfaqeni dhe lëreni përdoruesin të veprojë mbi atë që është tani në ekran.

Dy përpjekje me një pauzë të shkurtër midis tyre janë një parazgjedhje e arsyeshme; një cikël i pakufizuar nuk është. Nëse përpjekja e dytë dështon në të njëjtën mënyrë, ndaloni dhe raportoni në vend që të vazhdoni.

Çfarë nuk duhet të bëjë klienti

Klienti nuk duhet të bëjë disa gjëra që duken të dobishme dhe nuk janë. Nuk duhet të vazhdojë të dërgojë njoftime push derisa dikush të prekë «mirato», sepse kjo i mëson përdoruesit të miratojnë kërkesa që nuk i kanë nisur vetë, dhe është pikërisht sjellja në të cilën mbështeten kompletet e phishing. Nuk duhet të kalojë në një faktor më të dobët sepse ai i forti dështoi, dhe nuk duhet të çaktivizojë kontrollin e identitetit të serverit për të anashkaluar një ankesë certifikate që u shfaq në të njëjtën kohë. Secila nga këto tre shkurticë e kthen një dështim autentikimi në një incident sigurie.

Nuk duhet as ta gëlltisë dështimin në heshtje. Një klient që mbyll lidhjen dhe shfaq një rrotullues e lë përdoruesin pa asnjë ide nëse duhet të riprovojë, të presë ose të telefonojë suportin. Shfaqni dështimin me llojin e faktorit dhe një kod të shkurtër, mbajeni mesazhin pa sekrete dhe bëjeni veprimin e ripërpjekjes të qartë në vend të automatikut.

Nëse kërkesën nuk e nisi personi në tastierë, veprimi i saktë është ta lini të refuzuar dhe ta raportoni përmes rrugës së verifikuar të suportit. Miratimi i një kërkesë për të ndaluar zhurmën është modeli i dështimit, jo zgjidhja.

Çfarë të regjistrohet për suportin

Për suportin, regjistri i dobishëm është i vogël. Ora e përafërt me zonën kohore, llogaria, klienti dhe versioni, lloji i faktorit dhe statusi jo-sekret i çdo përpjekjeje: kërkuar, refuzuar, skaduar, miratuar por refuzuar nga politika.

Mbani në vëzhgim edhe orët e klientit dhe të serverit. TOTP është një kontroll i dritares kohore, prandaj një pajisje me orën e zhvendosur prodhon kode që duken të vlefshme dhe dështojnë çdo herë, dhe një klient që raporton një kod të pavlefshëm pa përmendur zhvendosjen i dërgon njerëzit të rivendosin kredenciale që nuk kanë qenë kurrë të gabuara. Një përdorues, hyrja e të cilit dështon vazhdimisht, duhet të kontrollojë versionin e mbështetur të klientit, gjendjen e regjistrimit dhe rrjedhën e dokumentuar të rikuperimit përpara se të krijojë më shumë kërkesa.

Rruga e rikuperimit meriton të njëjtin kujdes si rruga e hyrjes. Një rrjedhë pune për pajisje të humbur ekziston pikërisht që një refuzim të mos bëhet leje për të anashkaluar autentikimin, dhe klienti duhet të lidhë procesin e dokumentuar të organizatës në vend që të sajojë një të vetin.

Rregulli mbi të cilin duhet ndërtuar është se refuzimi është një rezultat, jo një pengesë. Raportojeni një herë, qartë, me kontekst të mjaftueshëm për të vepruar, dhe lëreni përpjekjen tjetër të jetë e re. Udhëzimet e CISA për MFA rezistente ndaj phishing-ut shpjegojnë pse modeli «pyet derisa të miratohet» është i rrezikshëm që në fillim, dhe është referenca që vlen të citohet kur dikush propozon një cikël ripërpjekjesh. Gjithçka që klienti shton pas një refuzimi duhet ta bëjë vendimin e ardhshëm më të lehtë për një njeri, jo t’ia heqë vendimin.