Две проверки входа — не два фактора: VPN и RADIUS

Добавление второго бэкенда аутентификации к VPN-шлюзу выглядит как добавление второго фактора. Обычно оно добавляет вторую проверку, другой объект с другими режимами отказа. Должны ли обе успешно завершиться, что доказывает каждая и что происходит, когда одна недоступна, это три отдельных решения. Ошибётесь, и шлюз окажется строже на демонстрации и слабее во время сбоя.

Что на самом деле доказывает второй бэкенд

Поиск в локальной учётной записи доказывает, что имя существует в базе данных и что пароль к нему подошёл. Обмен RADIUS доказывает, что сервер RADIUS вернул Access-Accept для полученных атрибутов. Ни одно из утверждений не упоминает тип фактора, потому что оба проверяют знание. А руководство NIST по цифровой идентичности считает разные типы факторов и их аутентификаторы, а не серверы или запросы.

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

RADIUS может нести настоящий второй фактор, когда стоит перед чем-то, что проверяет один, например push-подтверждением или аппаратным токеном. Конверт не сообщает, какие аутентификаторы предъявил пользователь, поэтому читайте политику бэкенда, а не ярлык шлюза.

AND, OR и резервная — разные продукты

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

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

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

Двойная проверка OpenVPN конкретный случай

Общий OpenVPN 2.6 требует и клиентский сертификат, и настроенный скрипт auth-user-pass-verify, когда включено и то и другое. Это документированный AND между проверкой сертификата и скриптом учётных данных, и это действительно две проверки. Это всё ещё не автоматически два типа факторов, поскольку скрипт может проверять только пароль.

Комбинация также оставляет открытым вопрос сопоставления. Сертификат обычно идентифицирует устройство, а учётные данные человека, и ничто в стандартном потоке не требует, чтобы оба относились к одному и тому же субъекту. Решите, какие пары разрешены, затем реализуйте это сопоставление внутри скрипта проверки или на более позднем этапе авторизации.

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

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

Проверьте комбинацию на своём шлюзе

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

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

grep показывает, требуется ли сертификат и какой скрипт выполняется после него, и порядок важнее, чем подсказывают имена. Дамп сертификата даёт идентичность, которую увидит шлюз, включая CN и серийный номер, нужные для карты сопоставления. Тест RADIUS негативный случай: неверный пароль должен давать Access-Reject, а верный Access-Accept. Если отклонённые учётные данные всё же дают сеанс, скрипт вообще не на пути аутентификации.

Затем прогоните случай сбоя на лабораторном экземпляре: остановите обязательный бэкенд и подключитесь с действительными учётными данными. Ожидаемый результат отказ, а всё остальное это резервная политика, которую никто не документировал.

Запишите требование как негативные случаи

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

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

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