Услугата 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

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

Процедурата приключва, когато трите състояния са названи, режимът при отказ е прочетен от работещата система, повторните опити имат един собственик, а аварийният достъп има своето одобрение и преглед. Предвидимото прилагане плюс известен път за възстановяване е резултатът, който си струва да се документира.