Как настроить двухфакторную аутентификацию без облака

Двухфакторная аутентификация без облака вполне работает, если организация готова сама владеть проверяющим сервером, ключевым материалом, временем и процедурой восстановления. Для администраторов я бы не строил ее вокруг кодов из телефона: основной способ должен применять аппаратный криптографический ключ или смарт-карту, а TOTP стоит оставить для совместимости и заранее оговоренного резерва.

Главная ошибка начинается с покупки коробки ключей до описания точек входа. Интерактивный вход в домен, VPN, SSH, RDP, консоль гипервизора и панель сетевого оборудования используют разные протоколы. Один брелок может хранить несколько типов учетных данных, но это еще не делает их единой системой. Сначала нужно решить, где именно второй фактор проверяется, что произойдет при потере связи с доменом и кто сможет вернуть доступ, не превращая резервный пароль в постоянный обход.

Как выглядит локальный контур аутентификации

Локальный контур не требует интернета, но требует собственного доверенного центра проверки. В минимальной схеме учетная запись остается в каталоге, а отдельный компонент проверяет доказательство владения ключом или общий секрет TOTP. VPN-шлюз и другие точки удаленного входа обращаются к нему по RADIUS, LDAP, Kerberos или через локальный модуль PAM. Журналы, резервные копии конфигурации и время тоже остаются внутри организации.

Полезно разделить систему на четыре роли. Каталог отвечает за личность и группы. Проверяющий узел принимает второй фактор. Точка доступа применяет решение и не разрешает запасной путь. Процесс регистрации связывает конкретный аутентификатор с конкретным администратором. Если один сервер одновременно выполняет все четыре роли, его отказ блокирует вход, а его компрометация отдает атакующему и учетные записи, и секреты.

Для критичного контура нужны как минимум два проверяющих узла в разных зонах отказа. Они должны получать одинаковые политики и актуальные записи об отозванных устройствах, но не обязаны иметь доступ в интернет. Резервное копирование базы TOTP или центра сертификации имеет смысл только вместе с защищенными ключами шифрования и проверенной процедурой восстановления. Копия базы без ключа бесполезна, а база вместе с ключом в одном архиве слишком удобна для похитителя.

Перед выбором продукта нарисуйте таблицу точек входа. Для каждой строки укажите протокол, текущий источник учетных записей, способ MFA, поведение без сети, место журнала и владельца аварийного доступа. В такой таблице быстро видно, что веб-панель поддерживает TOTP, SSH умеет FIDO-ключи, а старая консоль принимает только пароль. Последняя строка и определяет фактическую защищенность административного контура.

Аппаратный ключ может означать три разные вещи

Для локальной инфраструктуры аппаратный ключ следует выбирать по протоколу, а не по разъему или форме корпуса. Под одним названием продавцы часто смешивают FIDO2/U2F, PIV-совместимую смарт-карту и аппаратный генератор OATH-TOTP. Эти режимы решают разные задачи и оставляют разный след на сервере.

Различия удобно держать в короткой памятке:

• FIDO2/U2F хранит закрытый ключ для конкретного сервиса, а сервис проверяет подпись и вызов. Этот режим подходит для веб-входа, SSH и PAM.
• PIV или смарт-карта хранит закрытый ключ и сертификат, которые проверяет PKI, Kerberos или TLS. Этот режим подходит для доменного входа, RDP и VPN.
• OATH-TOTP хранит общий секрет и счетчик времени, а код сверяет локальный TOTP-сервер. Этот режим нужен старым VPN и приложениям.

FIDO2 дает сильную защиту от фишинга, когда протокол привязывает ответ к имени проверяющего сервиса. NIST SP 800-63B прямо отличает такую криптографическую привязку от ручного ввода одноразового кода. Злоумышленник может выманить действующий TOTP и тут же переслать его настоящему VPN, а подпись FIDO для поддельного адреса не подойдет настоящему адресу.

PIV работает через сертификаты и хорошо ложится на Active Directory, RDP и клиентскую аутентификацию TLS. Цена этой совместимости состоит в полноценной PKI: шаблоны сертификатов, доверенные корни, публикация списков отзыва, продление, учет носителей и защита ключа центра сертификации. Если никто не отвечает за срок действия CRL и сертификатов контроллеров домена, смарт-карта однажды перестанет пускать администраторов в самый неудобный момент.

Аппаратный TOTP-токен лучше приложения на личном телефоне с точки зрения владения и учета, но его протокол остается общим секретом. Сервер, который проверяет код, должен располагать тем же seed. Утечка этой базы позволяет клонировать генераторы без кражи физических устройств. Поэтому аппаратный корпус сам по себе не превращает TOTP в схему с открытым ключом.

При закупке проверьте поддержку нужных режимов на реальной версии ОС и клиента, возможность задать PIN, ограничение попыток, процедуру очистки, уникальный серийный номер для учета и способ обновления прошивки в изолированной сети. Не покупайте смешанный парк без причины. Два внешне одинаковых ключа с разными апплетами создают больше ошибок службы поддержки, чем экономят на закупке.

TOTP работает без облака, но переносит риск на сервер

TOTP легко развернуть локально, потому что алгоритму нужны только общий секрет и согласованное время. RFC 6238 определяет значение как HOTP от временного счетчика и рекомендует 30-секундный шаг. Стандарт требует уникальный секрет для каждого генератора и советует принимать не более одного соседнего шага для задержки. Расширять окно на несколько минут ради удобства не стоит: каждый дополнительный шаг увеличивает время, в которое украденный код пригоден.

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

Seed нельзя хранить в открытом виде в каталоге, конфигурационном репозитории или заявке службы поддержки. Проверяющему серверу секрет нужен в обратимой форме, поэтому обычного хеширования недостаточно. Шифруйте базу отдельным мастер-ключом, ограничивайте доступ служебной учетной записи и разделяйте резервную копию данных от резервной копии мастер-ключа. Администратор каталога не должен автоматически получать возможность выгрузить все TOTP-секреты.

Регистрация через QR-код тоже передает сам секрет, а не безобидную картинку. Проводите ее на управляемом рабочем месте после очной или эквивалентно строгой проверки личности. Не отправляйте QR-код по почте и не оставляйте его в системе заявок. После регистрации попросите администратора ввести два последовательных кода, затем уничтожьте временный носитель секрета и запишите идентификатор токена, но не seed.

У TOTP есть разумное место: оборудование, которое не умеет сертификаты или FIDO, аварийный VPN-клиент и переходный период. Не объявляйте его эквивалентом аппаратной подписи. NIST считает OTP устойчивым к повторному воспроизведению уже использованного значения, но не устойчивым к фишингу, потому что пользователь вручную передает код проверяющему. Это различие влияет на защиту, а не на терминологию.

Доменный вход требует PKI, а не только ключа

В Active Directory надежный локальный путь для интерактивного входа строится на смарт-карте или PIV-режиме с сертификатом. Контроллер домена сопоставляет сертификат с учетной записью и проверяет цепочку доверия. Обычный FIDO2-ключ нельзя считать прямой заменой смарт-карты для классического доменного входа: без поддерживаемого поставщика учетных данных и отдельной архитектуры Windows не начнет принимать его только потому, что ключ вставлен в USB.

Документация Microsoft по входу со смарт-картой требует, чтобы выдающий центр сертификации находился в хранилище NTAuth, а контроллеры домена имели подходящие сертификаты. Клиент и контроллер должны доверять корню. Для сертификата пользователя важны корректное сопоставление с учетной записью, назначение ключа и доступность сведений об отзыве. Ошибка в UPN, цепочке или CRL часто выглядит для дежурного как безликое сообщение о невозможности проверить учетные данные.

Проверка отзыва заслуживает отдельного теста. Если точка публикации CRL недоступна или срок списка истек, вход может быть отклонен даже при исправном ключе и верном PIN. Размещайте CRL внутри каждой необходимой сетевой зоны, задавайте срок действия с запасом на восстановление центра сертификации и оповещайте дежурных задолго до Next Update. Отключать проверку отзыва ради доступности нельзя: тогда потерянный сертификат продолжит работать до истечения срока.

На тестовой рабочей станции сведения о карте и цепочке можно проверить штатной командой:

certutil.exe -scinfo

В выводе ищите найденный считыватель, контейнер ключа, сертификат входа, цепочку до доверенного корня и результат проверки отзыва. Сам факт, что утилита видит устройство, не доказывает готовность доменного входа. Запускайте проверку из каждой зоны и под учетной записью, которая повторяет реальный административный профиль.

Политика «для интерактивного входа нужна смарт-карта» должна включаться поэтапно. Сначала выдайте каждому администратору два зарегистрированных носителя, проверьте вход на рабочую станцию и RDP, затем включите требование для пилотной группы. Не начинайте с встроенных или сервисных учетных записей. Их назначение и технические ограничения требуют отдельного разбора.

Отключенный от домена ноутбук создает отдельный случай. Microsoft описывает автономный вход как проверку кэшированных учетных данных, а не новую онлайн-проверку сертификата контроллером. Политика кэша, срок сертификата, доступ к CRL до отключения и поведение после отзыва должны быть проверены на вашей сборке Windows. Нельзя обещать мгновенный отзыв ключа на машине, которая не получает новых данных.

На Linux второй фактор должен пережить зашифрованный home

На Linux аппаратный FIDO/U2F-ключ можно проверять локально через PAM, но файл сопоставления нельзя прятать там, куда система получает доступ только после входа пользователя. Руководство pam_u2f отдельно предупреждает: если mapping-файл лежит в зашифрованном домашнем каталоге, а каталог открывается после аутентификации, вход становится невозможным. Для системного входа храните сопоставления в защищенном файле, который root читает до монтирования home.

Минимальная строка PAM может выглядеть так:

auth required pam_u2f.so authfile=/etc/security/u2f_mappings cue

Слово required важно: ошибка второго фактора должна провалить весь стек, даже если следующий модуль принял пароль. Но порядок модулей зависит от дистрибутива и способа входа. Сначала оставьте открытую root-консоль, проверьте синтаксис pam_u2f, права файла и два ключа тестового пользователя, а уже потом переносите изменение на SSH, sudo или экранный менеджер.

Для SSH удобнее использовать собственную поддержку security key в OpenSSH. Ключ создается на рабочей станции администратора, а сервер получает только открытую часть:

ssh-keygen -t ed25519-sk -O verify-required -C "admin@infrastructure"

Ожидаемый диалог просит вставить устройство, коснуться его и при поддержке выполнить проверку пользователя по PIN. Опция verify-required заставляет сервер требовать отметку о локальной проверке пользователя, а не только физическое касание. Перед массовым выпуском убедитесь, что клиентская и серверная версии OpenSSH поддерживают выбранный тип ключа, и сохраните обычный аварийный путь через отдельную консоль.

Не добавляйте один открытый ключ в учетные записи нескольких людей. Журнал SSH тогда докажет только применение общего ключа, но не личность оператора. У каждого администратора должны быть своя учетная запись и два собственных носителя. Повышение привилегий через sudo следует журналировать отдельно, чтобы вход и административное действие не сливались в одну размытую запись.

Удаленный доступ нужно закрывать на первой точке входа

Второй фактор должен проверяться на VPN-шлюзе, бастионе или RD Gateway до появления административного трафика во внутренней сети. Если VPN принимает пароль, а MFA спрашивает только веб-панель одного сервера, украденная учетная запись уже может сканировать внутренние адреса и атаковать протоколы, где второй фактор не настроен.

Для VPN без облака типовая связка состоит из двух локальных RADIUS-узлов, каталога и выбранного модуля MFA. Шлюз отправляет запрос RADIUS, проверяющий узел сверяет членство в административной группе и второй фактор, затем возвращает разрешение с минимально нужным профилем доступа. Настройте отдельные RADIUS-секреты на каждый клиент, ограничьте источники запросов межсетевым экраном и защищайте административный протокол шлюза независимо от пользовательского VPN.

Не все VPN-протоколы удобно передают два поля. Некоторые клиенты склеивают пароль и TOTP в одну строку, другие поддерживают отдельный запрос, а аппаратная подпись требует совсем другого обмена. Проверьте точный клиент, включая мобильный резерв, до выбора проверяющего сервера. Формальная отметка «RADIUS поддерживается» не говорит, как пользователь введет второй фактор и сможет ли шлюз отличить неверный пароль от неверного кода.

Для RDP смарт-карта может оставаться у администратора: Remote Desktop Services перенаправляет обращения удаленной сессии к локальному считывателю. Документация Microsoft отдельно указывает требования к сертификатам KDC, доверенным корням и UPN при входе между доменами. Тестируйте прямой RDP, вход через шлюз и переподключение к существующей сессии как разные сценарии. Запрет буфера обмена не заменяет контроль перенаправления учетных устройств.

Для SSH используйте аппаратный ключ уже на бастионе и запрещайте парольный вход для административной группы после пилота. Agent forwarding я бы не делал основным способом: удаленный узел получает возможность просить локальный агент подписывать запросы, пока соединение живо. Лучше выполнять следующий переход с короткоживущим сертификатом SSH или с отдельным ключом, политика которого ограничивает назначение.

Журнал должен связывать запрос на внешнем шлюзе, решение MFA, доменную учетную запись и целевой сеанс. Синхронизируйте время всех четырех источников. Запись «код принят» без имени токена и идентификатора запроса мало помогает при расследовании, а запись общего аварийного аккаунта скрывает человека именно в тот момент, когда риск выше всего.

Резервный вход не должен стать тихим обходом

Рабочий резерв начинается со второго персонального аппаратного ключа, зарегистрированного одновременно с первым и хранящегося отдельно. Это проще и безопаснее, чем срочно отключать MFA ночью. Для дежурной команды резервный ключ можно хранить в контролируемом помещении с журналом выдачи, но он все равно должен быть привязан к конкретному человеку, а не к общей учетной записи.

Второй уровень резерва нужен на случай отказа всей системы MFA. Создайте одну или несколько аварийных учетных записей, которые не используются в обычной работе, имеют длинные случайные пароли и не зависят от того же проверяющего узла. Разделите получение пароля между двумя ответственными лицами или используйте защищенное хранилище с правилом двойного контроля. Любое извлечение должно немедленно создавать оповещение по независимому каналу.

Одноразовые recovery-коды пригодны только там, где система умеет хранить их в виде стойких хешей, принимать каждый код один раз и регистрировать его применение. Распечатанный список рядом с сервером превращает владение бумагой в полный административный доступ. Для инфраструктуры я предпочитаю второй ключ и формальную аварийную учетную запись: их легче учитывать, отзывать и проверять на учениях.

Резерв не должен повторять ту же причину отказа. Два TOTP-приложения не помогут, если проверяющая база повреждена. Два смарт-карточных сертификата не помогут при истекшем CRL. Аварийный пароль в облачном хранилище не поможет изолированной площадке. Для каждого способа запишите зависимости от каталога, PKI, DNS, времени, сети, хранилища и конкретных людей.

Проверяйте аварийный вход по расписанию, но не превращайте проверку в обычное администрирование. После каждого использования меняйте пароль, закрывайте временные правила межсетевого экрана, отзывайте выданные сессии и разбирайте причину. Если аварийной учетной записью пользуются раз в неделю, это не резерв, а плохо наблюдаемый основной путь.

При утере устройства важна скорость отзыва, а не паника

Потерянный ключ не равен мгновенной компрометации учетной записи, если устройство защищено PIN, а пароль неизвестен постороннему. Но служба поддержки не должна оценивать намерения нашедшего. Она должна быстро удалить связь ключа с пользователем, отозвать сертификат при наличии PKI и проверить, не применялось ли устройство после заявленного времени потери.

Рабочий порядок укладывается в пять действий:

1. Проверить личность заявителя по заранее установленной процедуре, не используя потерянное устройство.
2. Зафиксировать время, серийный номер или credential ID, учетные записи и предполагаемое место потери.
3. Отключить конкретный аутентификатор во всех проверяющих системах, отозвать сертификат и опубликовать новый CRL.
4. Завершить активные VPN, веб, SSH и RDP-сеансы владельца, затем просмотреть события с момента последнего надежного использования.
5. Выдать новый основной ключ через обычную регистрацию, а резервный вернуть в резерв после проверки.

Не блокируйте всю учетную запись автоматически, если это оставит площадку без единственного дежурного администратора. Такое решение должно зависеть от признаков кражи пароля, подозрительных сессий и наличия другого оператора. При подтвержденном использовании потерянного ключа блокировка учетной записи, смена связанных секретов и расследование уже обязательны.

Для FIDO удаляют зарегистрированный credential ID или открытый ключ. Для PIV отзывают сертификат по серийному номеру и обеспечивают доставку свежего CRL всем проверяющим узлам. Для TOTP удаляют seed и меняют пароль, если код мог быть выманен вместе с ним. Просто вычеркнуть номер устройства из инвентарной таблицы недостаточно.

Учение должно начинаться с фразы «дежурный потерял основной ключ и находится вне офиса», а заканчиваться подтвержденным входом через резерв и полным отзывом утерянного устройства. Замерьте время не ради красивой метрики, а чтобы найти ожидание одного согласующего, недоступный сейф или CRL, который публикуется только вручную с выключенного сервера.

Пилот должен ломать схему до промышленного запуска

Хороший пилот проверяет отказы, а не только успешный вход. Возьмите несколько администраторов с разными рабочими станциями и все типы доступа: локальную консоль, VPN, SSH, RDP, повышение привилегий, управление гипервизором и сетевым оборудованием. Для каждой точки пройдите основной ключ, резервный ключ, неверный PIN, заблокированный токен, истекший сертификат и недоступный проверяющий узел.

Обязательно остановите один RADIUS-узел, нарушьте синхронизацию времени на тестовом сервере, сделайте CRL недоступным и отключите связь рабочей станции с доменом. Ожидаемое поведение должно быть записано заранее. Если команда решает на ходу, разрешать ли пароль при отказе MFA, архитектура еще не готова.

Проверьте наблюдаемость. Дежурный должен по одной попытке найти имя пользователя, идентификатор устройства, точку доступа, результат каждого фактора и причину отказа. При этом журнал не должен содержать TOTP-seed, PIN, recovery-код или полный RADIUS-пароль. Доступ к журналам дайте тем, кто расследует инциденты, а изменение политики MFA отделите от просмотра событий.

После пилота зафиксируйте процедуру выпуска, замены, отзыва, продления сертификатов и вывода сотрудника. Укажите, кто может регистрировать новый фактор и какое подтверждение личности требуется. Возможность добавить ключ после одного парольного входа уничтожает смысл всей схемы, особенно для администратора с широкими правами.

Развертывание выполняйте группами и оставляйте проверенную консоль восстановления, которая не доступна из пользовательской сети. GSE может подобрать локальную серверную платформу и интеграционную схему для такого контура с учетом существующей инфраструктуры и требований к поддержке. Но решение о допустимом резервном входе все равно должен принять владелец риска внутри организации.

Выбор начинается с протоколов и модели отказа

Если инфраструктура в основном состоит из современного SSH и веб-интерфейсов, я бы выбрал FIDO2-ключи с PIN и персональными учетными записями. Для классического доменного входа Windows и RDP логичнее PIV или смарт-карта с правильно обслуживаемой PKI. TOTP подходит как слой совместимости для систем, которые не понимают криптографические ключи, но его seed-база требует защиты уровня хранилища административных паролей.

Не требуйте один метод буквально везде. Требуйте одинаковый результат: два независимых фактора на первой точке административного доступа, личную привязку действия, быстрый отзыв и проверяемый резерв. Протоколы под этим правилом могут различаться, иначе старое устройство заставит ослабить весь контур.

При сравнении решений запросите автономную документацию, перечень поддерживаемых протоколов и версий, формат экспорта резервной копии, способ защиты мастер-ключей, журнал административных изменений и процедуру работы при отказе лицензирующего или обновляющего сервера. Фраза «on-premises» ничего не обещает сама по себе: продукт может проверять лицензию через интернет, загружать зависимости при восстановлении или хранить часть конфигурации у поставщика.

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

Самое неприятное решение стоит принять до закупки: что организация предпочтет при отказе MFA, закрытый доступ или парольный обход. Для административного контура безопаснее заранее построить независимый, строго контролируемый резерв, чем разрешить каждому шлюзу переходить на пароль. Иначе первый же сбой научит команду обходить защиту, которую она только что внедрила.