MFA-peto al VPN malakceptita: kion la kliento devus fari

Malakceptita MFA-peto aspektas kiel reta problemo kaj ne estas. La servilo petis duan faktoron, la faktoro revenis negativa aŭ neniam alvenis, kaj la seanco estis rifuzita antaŭ ol ekzistis ajna tunelo. Kio okazas poste estas demando pri konduto de la kliento: montri la fiaskon kaj lasi la uzanton komenci puran provon, aŭ ripeti laŭ manieroj, kiuj generas pliajn petojn kaj fine ekigas kontan protekton. La dua vojo estas kiel unu mistajpita kodo fariĝas ŝlosita konto.

Kontrolu, kiu peto malsukcesis

Komencu per identigo de tio, kiu peto malsukcesis. Puŝa sciigo, TOTP-kodo, FIDO-aserto kaj SAML-fluo ĉiu malsukcesas alimaniere, kaj la kliento kutime scias, kiun ĝi petis. Rifuzo, eksvalidiĝinta defio kaj livera fiasko, kiu neniam atingis la aparaton, ĉiuj finiĝas per la sama ĝenerala eraro, do la propra stato de la kliento ofte estas la sola loko, kie la diferenco pluvivas.

Tiu stato indas esti precize registrita. Registru la identigilon de la defio aŭ la transakcian referencon, la faktoran tipon, la tempostampon kaj la rezulton, sed neniam la kodon aŭ la aserton. La identigilo de la defio estas tio, kio ebligas al administranto trovi la eventon ĉe la flanko de la identecprovizanto; sen ĝi la subtena konversacio komenciĝas per «ie dum la lasta horo» kaj kutime finiĝas tie. Traktu ĝin kiel diagnozan metadatenon, ne kiel sekreton.

Ripetu unufoje, konscie, kun nova defio

Ripeto devus esti nova provo kun nova defio, ne reludado de la malnova. Kiam la kliento reuzas la antaŭan defion, la identecprovizanto aŭ malakceptas ĝin kiel eksvalidiĝintan aŭ, pli malbone, akceptas aprobon destinatan al la pli frua provo. Petu freŝan defion, montru ĝin, kaj lasu la uzanton agi pri tiu, kiu estas nun sur la ekrano.

Du provoj kun mallonga paŭzo inter ili estas racia defaŭlto; senlima buklo ne estas. Se la dua provo malsukcesas same, haltu kaj raportu anstataŭ daŭrigi.

Kion la kliento ne devas fari

La kliento ne devas fari plurajn aferojn, kiuj aspektas helpemaj kaj ne estas. Ĝi ne devas daŭre resendi puŝajn sciigojn ĝis iu frapetas «aprobo», ĉar tio trejnas uzantojn aprobi petojn, kiujn ili ne iniciatis, kaj ĝi estas ĝuste la konduto, sur kiu fiŝkaptaj ilojstaroj fidas. Ĝi ne devas fali reen al pli malforta faktoro ĉar la forta malsukcesis, kaj ĝi ne devas malŝalti la servilan identeckontrolon por preterpasi atestilan plendon, kiu aperis samtempe. Ĉiu el tiuj tri fuŝsolvoj igas aŭtentigan malsukceson sekureca incidento.

Ĝi ankaŭ ne devas silente engluti la fiaskon. Kliento, kiu fermas la konekton kaj montras ŝpinilon, lasas la uzanton sen ajna ideo, ĉu ripeti, atendi aŭ telefoni la subtenon. Montru la fiaskon kun la faktora tipo kaj mallonga kodo, tenu la mesaĝon sen sekretoj, kaj faru la ripetan agon eksplicita anstataŭ aŭtomata.

Se la peton ne iniciatis la persono ĉe la klavaro, la ĝusta ago estas lasi ĝin malakceptita kaj raporti ĝin tra la kontrolita subtena vojo. Aprobi peton por ĉesigi la bruon estas la fiaskomodelo, ne la solvo.

Kion registri por la subteno

Por la subteno, la utila registro estas malgranda. La proksimuma tempo kun la tempzono, la konto, la kliento kaj versio, la faktora tipo kaj la ne-sekreta stato de ĉiu provo: petita, rifuzita, eksvalidiĝinta, aprobita sed rifuzita de politiko.

Tenu ankaŭ la horloĝojn de kliento kaj servilo en la vido. TOTP estas kontrolo de tempa fenestro, do aparato, kies horloĝo driviĝis, produktas ŝajne validajn kodojn, kiuj malsukcesas ĉiufoje, kaj kliento, kiu raportas nevalidan kodon sen mencii la drivon, sendas homojn restarigi akreditaĵojn, kiuj neniam estis malĝustaj. Uzanto, kies ensaluto malsukcesas ree, devus kontroli la subtenatan klientversion, la aliĝan staton kaj la dokumentitan reakiran fluon antaŭ ol generi pliajn petojn.

La reakirado meritas la saman zorgon kiel la ensaluto. Laborfluo por perdita aparato ekzistas ĝuste por ke malakcepto ne fariĝu permeso preterpasi aŭtentigon, kaj kliento devus ligi al la dokumentita procezo de la organizo anstataŭ elpensi sian propran.

La regulo, laŭ kiu oni konstruu, estas ke malakcepto estas rezulto, ne obstaklo. Raportu ĝin unufoje, klare, kun sufiĉa kunteksto por agi, kaj lasu la sekvan provon esti nova. La gvidilo de CISA pri fiŝada-rezista MFA klarigas, kial la ŝablono «demandi ĝis aprobo» estas danĝera ekde la komenco, kaj ĝi estas la referenco inda citi, kiam iu proponas ripetan buklon. Ĉio, kion la kliento aldonas post malakcepto, devus igi la sekvan decidon pli facila por homo, ne forpreni la decidon de li.