MFA servis pao: odlučite o VPN pristupu prije kvara

VPN pristup staje, a alarm kaže da je usluga drugog faktora nedostupna. Može li se još neko povezati pitanje je politike na koje se trebalo odgovoriti prije prekida, a ne tijekom njega. Nedostupan verifikator nije dokaz da je faktor prošao, a odbijeni izazov nije isti događaj kao nedostupan. Procedura ispod pretvara tu razliku u pisano pravilo koje možete testirati.

Korak 1: imenujte tri ishoda odvojeno

Zapišite tri stanja i odbijte ih spojiti: primarna autentifikacija nije uspjela, izazov drugog faktora je odbijen ili je istekao, a MFA servis nikada nije odgovorio. Svako ima drugog vlasnika, drugu liniju u dnevniku i drugi ispravan odgovor. Jedna generička poruka o isteku roka skriva u kojem se stanju nalazite, a ta dvosmislenost pretvara prekid u raspravu. Imenujte stanja u proceduri prije nego što vam zatrebaju.

Odbijanje znači da je verifikator odgovorio i rekao ne, što je ishod politike, a ne problem dostupnosti. Istekao pokušaj znači da je izazov postojao i da ga nitko nije dovršio na vrijeme. Nedostupna usluga znači da pitanje uopće nije dobilo odgovor. Samo je treće prekid.

Korak 2: pročitajte način rada pri kvaru koji proxy stvarno koristi

Pronađite postavku koja upravlja ponašanjem kada se usluga ne može kontaktirati i pročitajte je iz pokrenute konfiguracije, a ne iz predloška. U Duo RADIUS proxyju dokumentirane vrijednosti failmode su safe i secure, pri čemu safe dopušta pokušaj samo kada primarna autentifikacija uspije, a secure odbija pokušaj u tom uvjetu.

radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager

Naziv safe opisuje izbor dostupnosti, a ne jamstvo da je svaka propuštena sesija imala svježi drugi faktor. Ta rečenica pripada u registar rizika jer je to točna razmjena koju postavka čini. Ne generalizirajte vrijednost na drugog pružatelja, drugu integraciju ili drugi način rada proxyja; pročitajte dokumentaciju tog proizvoda za njegov vlastiti ekvivalent. Konfiguracija kopirana iz primjera dobavljača bez tog razumijevanja iznenađenje je koje čeka sljedeći prekid.

Zaustavite se ako nitko ne može reći koji je način rada aktivan. Ostatak procedure ovisi o tom odgovoru.

Korak 3: uskladite ponovne pokušaje s tijekom

Uskladite gatewayev rok i ponašanje pri ponovnom pokušaju s tijekom autentifikacije koji vodi. Neusklađeni ponovni pokušaji stvaraju više upita, zbunjuju uparivanje pokušaja i ostavljaju dnevnik bez mogućnosti da kaže koji rezultat pripada kojoj prijavi. Vrlo dug rok nije dizajn dostupnosti; to je dulje čekanje na isti odgovor.

ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log

Vlastiti rok zahtjeva proxyja zasebna je granica: zahtjev za autentifikaciju koji je izdan i nikada dovršen biva odbijen, a to odbijanje nije prekid s kojeg se vraćate natrag. Tretirajte odbijanje, nedovršeni izazov i nedostupnu uslugu kao tri različita ulaza u svoju tablicu odluka. Zatim učinite tablicu izričitom: koje stanje propušta, koje stanje zadržava i koje stanje eskalira prema čovjeku.

Ako dva komponenta oba ponavljaju pokušaj, prvo popravite vlasništvo ponovnih pokušaja. Duplicirani upiti simptom su dva vlasnika, a ne sporog servisa.

Korak 4: upravljajte hitnim pristupom odvojeno

Ako je hitan pristup potreban, dajte mu vlastiti opseg, identitet, ovlaštenje i revizijski trag. Tiho onemogućavanje MFA za sve korisnike nije hitna procedura; to je trajno slabljenje s incidentom u prilogu. Sigurnosni vlasnik unaprijed odobrava pravilo pristupa, vidljivost i put eskalacije.

grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy

Testirajte cijelu matricu u neprodukcijskom okruženju: neuspjeh primarne autentifikacije, namjerno odbijanje, istek izazova i nedostupnost usluge. Za svaki zapišite rezultat pristupa i razlog koji je zabilježen. Ne stvarajte produkcijski prekid da biste otkrili konfigurirano ponašanje i ne testirajte hitni put prvi put tijekom incidenta za koji je napisan. Procedura oporavka koja nikada nije pokrenuta jest dokument, a ne kontrola.

Procedura završava kada su tri stanja imenovana, način rada pri kvaru pročitan iz pokrenutog sustava, ponovni pokušaji imaju jednog vlasnika, a hitni pristup ima vlastito odobrenje i pregled. Predvidljivo provođenje plus poznat put oporavka ishod je koji vrijedi dokumentirati.