MFA услуга је пала: одлучите о VPN приступу унапред

VPN приступ се зауставља, а упозорење каже да услуга другог фактора није доступна. Да ли неко још може да се повеже је питање политике на које је требало одговорити пре прекида, не током њега. Недоступан верификатор није доказ да је фактор прошао, а одбијен изазов није исти догађај као недоступан. Упутство испод претвара ту разлику у писано правило које можете тестирати.

Корак 1: именујте три исхода одвојено

Запишите три стања и одбијте да их спојите: примарна аутентификација није успела, изазов другог фактора је одбијен или је истекао, а MFA услуга никада није одговорила. Свако има другог власника, други ред у дневнику и други исправан одговор. Једна општа порука о истеку времена скрива у ком стању сте, а управо та нејасност претвара прекид у расправу. Именујте стања у упутству пре него што вам буду потребна.

Одбијање значи да је верификатор одговорио и рекао не, што је исход политике, а не проблем доступности. Истекао покушај значи да је изазов постојао и да га нико није завршио на време. Недоступна услуга значи да на питање уопште није одговорено. Само је треће прекид.

Корак 2: прочитајте режим отказа који прокси заиста користи

Пронађите подешавање које управља понашањем када услуга не може да се контактира и прочитајте га из конфигурације која ради, а не из шаблона. У RADIUS проксију компаније Duo, документоване вредности failmode су safe и secure, при чему safe дозвољава покушај само када примарна аутентификација успе, а secure одбија покушај у том услову.

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

Назив safe описује избор доступности, а не гаранцију да је свака примљена сесија имала свеж други фактор. Та реченица припада регистру ризика, јер је то тачно та размена коју подешавање чини. Не генерализујте вредност на другог добављача, другу интеграцију или други режим проксија; прочитајте документацију тог производа за његов сопствени еквивалент. Конфигурација копирана из примера добављача без овог разумевања је изненађење које чека следећи прекид.

Зауставите се ако нико не може да каже који је режим активан. Остатак упутства зависи од тог одговора.

Корак 3: ускладите поновне покушаје са током

Ускладите временско ограничење и понашање при поновном покушају мрежног пролаза са током аутентификације који води. Неусклађени поновни покушаји стварају више захтева, збуњују упаривање покушаја и остављају дневник без могућности да каже који резултат припада ком пријављивању. Веома дуго временско ограничење није пројекат доступности; то је дуже чекање на исти одговор.

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

Сопствено временско ограничење захтева код проксија је одвојена граница: захтев за аутентификацију који се изда и никада не заврши се одбија, и то одбијање није прекид са којег се повлачи. Третирајте одбијање, незавршени изазов и недоступну услугу као три различита улаза у вашу табелу одлука. Затим учините табелу експлицитном: које стање пушта, које стање задржава и које стање се ескалира до човека.

Ако две компоненте обе понављају покушај, прво поправите власништво поновних покушаја. Двоструки захтеви су симптом два власника, а не спорог сервиса.

Корак 4: управљајте хитним приступом одвојено

Ако је хитан приступ потребан, дајте му сопствени обим, идентитет, овлашћење и ревизорски траг. Тихо онемогућавање MFA за све кориснике није хитна процедура; то је трајно слабљење са инцидентом прикаченим уз њега. Власник безбедности унапред одобрава правило приступа, видљивост и пут ескалације.

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

Тестирајте целу матрицу у непродукционом окружењу: примарни неуспех, намерно одбијање, истек изазова и недоступност услуге. За сваки, запишите резултат приступа и разлог који је записан у дневнику. Не стварајте продукциони прекид да бисте открили конфигурисано понашање и не тестирајте хитни пут први пут током инцидента за који је написан. Процедура опоравка која никада није покренута је документ, а не контрола.

Упутство се завршава када су три стања именована, режим отказа прочитан из система који ради, поновни покушаји имају једног власника и хитан приступ има сопствено одобрење и преглед. Предвидиво спровођење плус познат пут опоравка је исход који вреди документовати.