Регистрация пользователя VPN: сначала найдите владельца идентичности
Добавление пользователя VPN начинается с системы идентичности, а не с оболочки. Выясните, какой backend проверяет учётную запись, выдайте право и спланируйте отзыв.
Кто-то просит доступ к VPN, и первый порыв — запустить adduser на сервере. Этот порыв верен лишь в узком наборе развёртываний. Прежде чем что-либо создавать, откройте конфигурацию сервера и выясните, какой продукт там работает и где он проверяет учётные данные, потому что учётная запись может жить в базе продукта, у поставщика идентичности или в собственном стеке аутентификации хоста. Создание учётной записи не того типа оставляет человека с работающим входом и без туннеля.
Клиентский профиль, в котором указан OpenVPN, описывает протокол, а не систему идентичности за ним.
Начните с сервера, а не с adduser
Сначала определите продукт. Community OpenVPN — это демон плюс любая аутентификация, которую вы к нему подключили, а Access Server — продукт с собственным уровнем пользователей. Запросите конфигурацию, имя юнита и список пакетов и проверьте, есть ли веб-интерфейс для управления пользователями. Затем посмотрите, как развёрнутый профиль ожидает, что клиенты докажут, кто они: сертификатом, именем пользователя и паролем или и тем и другим. Этот ответ называет систему, которой принадлежит учётная запись.
Только после этого фраза создание пользователя обретает смысл. При развёртывании только с сертификатами это означает выдачу идентичности устройства через утверждённый процесс, и вход в Unix ничего не меняет. При развёртывании с паролем это означает backend, который действительно проверяет пароль.
Четыре backend, четыре места для создания учётной записи
Локальная аутентификация Access Server хранит учётные записи в собственной базе, поэтому интерфейс для их создания принадлежит продукту, а не хосту. PAM передаёт проверку стеку операционной системы, и поэтому локальная учётная запись Unix может быть частью регистрации, когда служба выбрала именно этот стек. LDAP, RADIUS и SAML переносят проверку во внешнюю службу, где живут подготовка, политика паролей и MFA. Access Server во всех четырёх случаях по-прежнему может хранить сертификаты и разрешения для каждого пользователя, и именно это делает разделение запутанным.
Проверьте действующий метод для этого конкретного пользователя, а не глобальное значение по умолчанию. Access Server 2.10 и более новые версии могут применять разные методы аутентификации для группы или пользователя, поэтому локальное значение по умолчанию не доказывает, что учётная запись перед вами проверяется локально.
Право — отдельное решение
Аутентификация отвечает, кто этот человек; право отвечает, куда он может попасть. Держите их как два шага, потому что успешный вход не является предоставлением. Намеренно назначьте предполагаемые маршруты, разрешения на ресурсы и административные права и подтвердите, что несвязанный доступ остаётся запрещённым. Там, где развёртывание поддерживает индивидуальные идентичности, выдавайте по одной на человека вместо пересылки чужого профиля, потому что общий профиль нельзя отозвать для одного человека.
Клиентский материал тоже важен. Профиль с автоматическим входом и интерактивный пользовательский вход представляют разные отношения аутентификации, и замена одного другим меняет то, что сервер действительно проверяет.
Отзыв доступа — часть регистрации
Запишите трёх владельцев, пока создаётся пользователь: кто проверяет учётную запись, кто разрешает доступ к VPN и какое устройство или профиль представляет соединение. Это могут быть три разные системы, и план отзыва, называющий только одну из них, оставляет путь открытым. Когда человек уходит, снимите право у его владельца и отзовите каждый выданный учётный документ у его владельца. Удаление скачанного файла — не отзыв, и удаление локальной записи тоже, если внешняя идентичность всё ещё проходит аутентификацию.
Затем проверьте регистрацию так, как это сделал бы злоумышленник: подключитесь один раз с новой идентичностью, подтвердите доступ к предполагаемому ресурсу и подтвердите, что несвязанный ресурс по-прежнему отказывает. Первое работающее подключение плюс негативный тест — это завершённая регистрация.
Храните запись вместе с профилем, которому она принадлежит. Следующий аудитор спросит, кто мог подключаться в течение определённого месяца, и ответ живёт у этих трёх владельцев.