Dikush humbet telefonin dhe tiketa mbërrin si VPN i prishur. Ky kornizim është i gabuar dy herë: llogaria ekziston ende dhe porta ende i beson ofruesit të identitetit, kështu që e vetmja pjesë e prishur është një faktor që personi nuk e ka më. Trajtojeni si rikuperim dhe jo si ndërprerje: verifikoni kërkuesin, regjistroni një zëvendësues, tërhiqni metodën e humbur dhe më pas provoni se llogaria funksionon. E gjithë kjo supozon se plani është shkruar para humbjes, sepse shpikja e tij gjatë telefonatës është rruga ku MFA përfundon e çaktivizuar për të gjithë.

Hapi 1: lexoni faktorët e regjistruar nga një regjistër, jo nga kujtesa

Pyetja e parë nuk është cili pajisje humbi, por çfarë tjetër mund të përdorë ende llogaria. Një llogari mund të mbajë një fjalëkalim plus push, një kod të bazuar në kohë, një çelës harduerik dhe kode rikuperimi të shtypura, dhe humbja e njërit prej tyre është një ngjarje krejt e ndryshme nga humbja e të vetmit. Lexoni listën e metodave nga sistemi i identitetit në vend që t'i kërkoni përdoruesit ta mbajë mend, dhe në një qiradhënës Microsoft Entra pyetja është një rresht:

Get-MgUserAuthenticationMethod -UserId [email protected]

Më pas shkruani regjistrin e rikuperimit ndërsa llogaria ende funksionon: identifikuesi i llogarisë, faktorët e regjistruar, ku jetojnë kodet e rikuperimit, kush mund ta verifikojë në mënyrë të pavarur kërkuesin dhe cilat sisteme arrin llogaria. Mbani atë në inventarin e mbrojtur që ekipi përdor tashmë, kurrë në një shënim që përmban edhe kode aktive. Këto pesë fusha e kthejnë një telefonatë paniku në një listë kontrolli, dhe udhëzimi i NIST për ciklin e jetës së autentikuesit e trajton rikuperimin si pjesë të kredencialeve dhe jo si përjashtim.

Regjistroni kanalin e verifikimit si fushë më vete, sepse pikërisht atë pjesë njerëzit e kapërcejnë. Një numër telefoni i lidhur me llogarinë nuk është kanal i pavarur kur personi që kërkon kontrollon edhe telefonin.

Hapi 2: verifikoni kërkuesin jashtë rrugës që dështon

Kryeni kontrollin e identitetit përmes një kanali që nuk varet nga VPN-ja, kutia postare ose pajisja e humbur. Një telefonatë kthimi në një numër nga regjistri i burimeve njerëzore, ose një kontroll ballë për ballë me një menaxher që është tashmë në drejtori, funksionojnë të dyja; një mesazh chat i dërguar nga llogaria në rikuperim nuk funksionon. Kontrolli ka të bëjë me personin, jo me aftësinë e tij për t'u përgjigjur pyetjeve për llogarinë, sepse detajet e llogarisë rrjedhin. Regjistroni kush e verifikoi kërkesën dhe kur, pasi shqyrtuesi tjetër do të dojë të dyja.

Kur kërkesa vjen me urgjencë dhe presion për të kapërcyer kontrollin, ai është momenti për të ngadalësuar. Mashtrimi i rikuperimit duket saktësisht si një koleg ndihmës që nxiton.

Hapi 3: regjistroni zëvendësuesin, më pas tërhiqni faktorin e vjetër

Regjistroni autentikuesin e ri përmes rrjedhës normale të regjistrimit, kurrë përmes një anashkalimi administrativ. Më pas hiqni metodën e humbur në mënyrë eksplicite, sepse regjistrimi i një zëvendësuesi e lë autentikuesin e mëparshëm të autorizuar derisa dikush ta tërheqë. Nëse pajisja e vjetër mund të jetë në duart e dikujt tjetër, trajtojeni heqjen si urgjente dhe ndiqni procesin e incidentit, jo atë të rikuperimit. Revokoni sesionet ekzistuese në të njëjtin kalim, pasi një sesion i krijuar para ndryshimit mund ta mbijetojë atë:

Revoke-MgUserSignInSession -UserId [email protected]

Heqja e faktorit për të gjithë të tjerët, ose lehtësimi i kontrolleve të certifikatës së portës, shkëmben rikuperimin e një personi me një ndërprerje që prek të gjithë vendosjen. Mbajeni ndryshimin të kufizuar në llogarinë e vetme dhe eskaloni nëse provat tregojnë një kompromis më të gjerë. Shënoni në tiketë cili faktor u tërhoq dhe cili e zëvendësoi.

Hapi 4: provoni se llogaria funksionon në të dy drejtimet

Hyni një herë me faktorin e ri përmes një klienti të mbështetur, më pas konfirmoni se llogaria arrin ende burimet që arrinte para humbjes. Testoni një burim që kërkon tunelin dhe një që nuk e kërkon, që dështimi të tregojë shtresën e duhur. Provoni një hyrje me faktorin e tërhequr dhe prisni një refuzim, jo një kërkesë, që provon se heqja hyri në fuqi. Një sfidë që dështon nga një pajisje ekzistuese e regjistruar është problem kërkese, jo arsye për të regjistruar gjithçka përsëri.

Më pas kërkoni nga përdoruesi të përfundojë të njëjtën hyrje pa udhëzim. Testi juaj i suksesshëm provon konfigurimin; përpjekja e tij provon dorëzimin.

Mbyllni tiketën me vulën kohore të hyrjes së suksesshme dhe emrin e faktorit që përdoret tani. Përditësoni regjistrin e rikuperimit në të njëjtin kalim, që humbja tjetër të nisë nga një inventar i saktë dhe jo i vjetruar.

Hapi 5: hiqni kushtin që e bëri këtë të dhimbshëm

Çdo telefonatë rikuperimi është provë për dizajnin e regjistrimit. Nëse llogaria kishte saktësisht një faktor, kërkoni një të dytë për të gjithë në atë grup. Nëse kodet e rikuperimit ishin në laptopin e humbur, ndryshoni ku jetojnë. Nëse verifikimi kërkonte një menaxher me pushim, caktoni një zëvendës. Çdo rregullim merr një pasdite dhe heq orën më të keqe të incidentit të ardhshëm.

Më pas rilexoni regjistrin e hapit një kundrejt realitetit. A liston faktorët që ekzistojnë vërtet, dhe a arrin kanali i verifikimit ende një njeri? Një manual që askush nuk e përditëson degjeneron në një dokument që njerëzit e injorojnë gjatë telefonatës për të cilën u shkrua.

Artikuj të ngjashëm