Сэрвіс 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
Праверце ўсю матрыцу ў невытворчым асяроддзі: збой асноўнай аўтэнтыфікацыі, наўмысная адмова, сканчэнне часу запытання і недаступнасць сэрвісу. Для кожнага запішыце вынік допуску і прычыну, якая была запісана ў журнал. Не стварайце вытворчы збой, каб выявіць наладжаныя паводзіны, і не правярайце аварыйны шлях упершыню падчас інцыдэнту, для якога ён напісаны. Працэдура аднаўлення, якая ніколі не запускалася, — гэта дакумент, а не кантроль.
Парадак дзеянняў заканчваецца, калі тры станы названыя, рэжым адмовы прачытаны з працоўнай сістэмы, паўторныя спробы маюць аднаго ўладальніка, а аварыйны доступ мае ўласнае ўхваленне і разгляд. Прадказальнае прымяненне плюс вядомы шлях аднаўлення — гэта вынік, варты дакументавання.