Az MFA-szolgáltatás kiesett: döntse el a VPN-belépést előre

A VPN-belépés megáll, és a riasztás azt mondja, hogy a második tényező szolgáltatása elérhetetlen. Hogy valaki még csatlakozhat-e, olyan házirend-kérdés, amelyet a kiesés előtt kellett volna megválaszolni, nem közben. Egy el nem érhető ellenőrző nem bizonyíték arra, hogy egy tényező átment, és az elutasított kihívás nem ugyanaz az esemény, mint az elérhetetlen. Az alábbi folyamatleírás ezt a különbséget írott szabállyá teszi, amelyet tesztelhet.

1. lépés: nevezze meg a három kimenetet külön

Írjon le három állapotot, és utasítsa el ezek összevonását: az elsődleges hitelesítés meghiúsult, a második tényező kihívása elutasításra került vagy lejárt, és az MFA-szolgáltatás soha nem válaszolt. Mindegyiknek más a tulajdonosa, más a naplósora és más a helyes válasza. Egyetlen általános időtúllépési üzenet elrejti, melyikben van, és épp ez a bizonytalanság teszi a kiesést vitává. Nevezze meg az állapotokat a folyamatleírásban, mielőtt szüksége lenne rájuk.

Az elutasítás azt jelenti, hogy az ellenőrző válaszolt és nemet mondott, ami házirend-eredmény, nem elérhetőségi probléma. A lejárt kísérlet azt jelenti, hogy a kihívás létezett, és senki nem fejezte be időben. Az elérhetetlen szolgáltatás azt jelenti, hogy a kérdésre egyáltalán nem érkezett válasz. Csak a harmadik kiesés.

2. lépés: olvassa ki a proxyszerver tényleges hibaüzemmódját

Keresse meg azt a beállítást, amely a viselkedést vezérli, amikor a szolgáltatás nem érhető el, és a futó konfigurációból olvassa ki, ne sablonból. A Duo RADIUS-proxyjában a dokumentált failmode-értékek safe és secure, ahol a safe csak akkor enged kísérletet, ha az elsődleges hitelesítés sikeres, a secure pedig ebben az esetben elutasítja a kísérletet.

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

A safe név elérhetőségi választást ír le, nem garanciát arra, hogy minden beengedett munkamenet friss második tényezővel rendelkezett. Ez a mondat a kockázati nyilvántartásba tartozik, mert pontosan ez a csere, amit a beállítás tesz. Ne általánosítsa az értéket más szolgáltatóra, más integrációra vagy más proxyüzemmódra; olvassa el annak a terméknek a dokumentációját a saját megfelelőjéhez. E megértés nélkül szállítói példából másolt konfiguráció a következő kiesésre váró meglepetés.

Álljon meg, ha senki nem tudja megmondani, melyik üzemmód aktív. A folyamatleírás többi része ettől a választól függ.

3. lépés: igazítsa az újrapróbálkozásokat a folyamathoz

Igazítsa az átjáró időtúllépését és újrapróbálkozási viselkedését ahhoz a hitelesítési folyamathoz, amelyet vezet. A nem hangolt újrapróbálkozások több kérést hoznak létre, összezavarják a kísérletek párosítását, és a naplót képtelenné teszik annak megmondására, melyik eredmény melyik bejelentkezéshez tartozik. A nagyon hosszú időtúllépés nem elérhetőségi tervezés; hosszabb várakozás ugyanarra a válaszra.

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

A proxy saját kérési időtúllépése külön korlát: a kiadott és soha be nem fejezett hitelesítési kérés elutasításra kerül, és ez az elutasítás nem kiesés, amelyből vissza lehet lépni. Kezelje az elutasítást, a befejezetlen kihívást és az elérhetetlen szolgáltatást három különböző bemenetként a döntési táblázatában. Ezután tegye egyértelművé a táblázatot: melyik állapot enged be, melyik tart vissza, és melyik eszkalálódik emberhez.

Ha két komponens egyaránt újrapróbálkozik, először az újrapróbálkozások tulajdonjogát javítsa. Az ismétlődő kérések két tulajdonos tünetei, nem a lassú szolgáltatásé.

4. lépés: a vészhelyzeti hozzáférést külön kezelje

Ha vészhelyzeti hozzáférésre van szükség, adjon neki saját hatókört, identitást, felhatalmazást és auditnyomot. Az MFA csendes kikapcsolása minden felhasználónál nem vészhelyzeti eljárás; ez tartós gyengítés, amelyhez incidens kapcsolódik. A biztonsági tulajdonos előre jóváhagyja a belépési szabályt, a láthatóságot és az eszkalációs utat.

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

Tesztelje a teljes mátrixot nem termelési környezetben: elsődleges hiba, szándékos elutasítás, kihívás lejárta és a szolgáltatás elérhetetlensége. Mindegyiknél rögzítse a belépés eredményét és a naplózott indokot. Ne hozzon létre termelési kiesést a beállított viselkedés felfedezéséhez, és ne a vészhelyzeti utat tesztelje először abban az incidensben, amelyre írták. A soha le nem futtatott helyreállítási eljárás dokumentum, nem kontroll.

A folyamatleírás akkor ér véget, amikor a három állapot nevet kapott, a hibaüzemmódot a futó rendszerből olvasták ki, az újrapróbálkozásoknak egy tulajdonosa van, és a vészhelyzeti hozzáférésnek saját jóváhagyása és felülvizsgálata van. A kiszámítható érvényesítés plusz egy ismert helyreállítási út az az eredmény, amelyet érdemes dokumentálni.