MFA paslauga neveikia: nuspręskite dėl VPN prieigos iš anksto

VPN prieiga sustoja, o perspėjimas sako, kad antrojo veiksnio paslauga nepasiekiama. Ar kas nors dar gali prisijungti, yra politikos klausimas, į kurį turėjo būti atsakyta prieš sutrikimą, o ne jo metu. Neprieinamas tikrintojas nėra įrodymas, kad veiksnys praėjo, o atmestas iššūkis nėra tas pats įvykis kaip nepasiekiamas. Toliau pateikta instrukcija paverčia šį skirtumą rašytine taisykle, kurią galite išbandyti.

1 žingsnis: įvardykite tris rezultatus atskirai

Užrašykite tris būsenas ir atsisakykite jas sujungti: pirminė autentifikacija nepavyko, antrojo veiksnio iššūkis buvo atmestas arba pasibaigė, o MFA paslauga niekada neatsakė. Kiekviena turi skirtingą savininką, skirtingą žurnalo eilutę ir skirtingą teisingą atsaką. Vienas bendras laiko limito pranešimas paslepia, kurioje esate, ir būtent šis neapibrėžtumas paverčia sutrikimą ginču. Įvardykite būsenas instrukcijoje prieš joms prireikiant.

Atmetimas reiškia, kad tikrintojas atsakė ir pasakė ne, o tai yra politikos rezultatas, ne prieinamumo problema. Pasibaigęs bandymas reiškia, kad iššūkis egzistavo ir niekas jo laiku neužbaigė. Nepasiekiama paslauga reiškia, kad į klausimą apskritai nebuvo atsakyta. Tik trečiasis yra sutrikimas.

2 žingsnis: perskaitykite gedimo režimą, kurį tarpinė tikrai naudoja

Raskite nustatymą, kuris valdo elgseną, kai paslaugos pasiekti negalima, ir perskaitykite jį iš veikiančios konfigūracijos, o ne iš šablono. Duo RADIUS tarpinėje dokumentuotos failmode reikšmės yra safe ir secure, kur safe leidžia bandymą tik tada, kai pirminė autentifikacija pavyksta, o secure atmeta bandymą esant šiai sąlygai.

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

Pavadinimas safe apibūdina prieinamumo pasirinkimą, o ne garantiją, kad kiekviena priimta sesija turėjo naują antrąjį veiksnį. Tas sakinys priklauso rizikų registrui, nes tai yra būtent ta mainai, kuriuos atlieka nustatymas. Nekelkite reikšmės į kitą tiekėją, kitą integraciją ar kitą tarpinės režimą; skaitykite to produkto dokumentaciją apie jo paties atitikmenį. Be šio supratimo iš tiekėjo pavyzdžio nukopijuota konfigūracija yra staigmena, laukianti kito sutrikimo.

Sustokite, jei niekas negali pasakyti, kuris režimas aktyvus. Likusi instrukcijos dalis priklauso nuo to atsakymo.

3 žingsnis: suderinkite pakartojimus su srautu

Suderinkite tinklų sietuvos laiko limitą ir pakartojimų elgseną su autentifikacijos srautu, kurį ji valdo. Nesuderinti pakartojimai sukuria kelis raginimus, supainioja bandymų poravimą ir palieka žurnalą be galimybės pasakyti, kuris rezultatas priklauso kuriam prisijungimui. Labai ilgas laiko limitas nėra prieinamumo dizainas; tai ilgesnis laukimas to paties atsakymo.

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

Tarpinės pačios užklausos laiko limitas yra atskira riba: autentifikacijos užklausa, kuri išduodama ir niekada neužbaigiama, atmetama, ir tas atmetimas nėra sutrikimas, nuo kurio atsitraukiama. Traktuokite atmetimą, neužbaigtą iššūkį ir nepasiekiamą paslaugą kaip tris skirtingas įvestis į savo sprendimų lentelę. Tada padarykite lentelę aiškią: kuri būsena įleidžia, kuri būsena sulaiko ir kuri būsena eskaluojama žmogui.

Jei du komponentai abu kartoja, pirmiausia ištaisykite pakartojimų nuosavybę. Pasikartojantys raginimai yra dviejų savininkų simptomas, o ne lėtos paslaugos.

4 žingsnis: avarinę prieigą valdykite atskirai

Jei reikia avarinės prieigos, suteikite jai atskirą apimtį, tapatybę, įgaliojimą ir audito pėdsaką. Tylus MFA išjungimas visiems naudotojams nėra avarinė procedūra; tai nuolatinis susilpninimas su incidentu. Saugumo savininkas iš anksto patvirtina priėmimo taisyklę, matomumą ir eskalavimo kelią.

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

Išbandykite visą matricą ne produkcinėje aplinkoje: pirminį gedimą, tyčinį atmetimą, iššūkio pasibaigimą ir paslaugos nepasiekiamumą. Kiekvienam užrašykite priėmimo rezultatą ir žurnale įrašytą priežastį. Nekurkite produkcinio sutrikimo, kad atrastumėte sukonfigūruotą elgseną, ir nebandykite avarinio kelio pirmą kartą per incidentą, kuriam jis buvo parašytas. Niekada nevykdyta atkūrimo procedūra yra dokumentas, o ne kontrolė.

Instrukcija baigiasi, kai trys būsenos įvardytos, gedimo režimas perskaitytas iš veikiančios sistemos, pakartojimai turi vieną savininką, o avarinė prieiga turi savo patvirtinimą ir peržiūrą. Nuspėjamas vykdymas ir žinomas atkūrimo kelias yra rezultatas, kurį verta dokumentuoti.