Отдельные VPN-идентичности для небольшой команды, без каталога

Шесть человек пользуются одним входом в VPN, один из них уходит, и единственный способ забрать его доступ — сменить секрет, которым пользуются все остальные. Это и есть настоящая проблема, и для её решения не нужен Active Directory. Небольшой офис может держать отдельные идентичности в любом локальном хранилище, которое поддерживает его шлюз, и при этом считать уходы обычным делом. Работа в том, чтобы выбрать хранилище и записать шаги удаления до того, как они понадобятся.

Начните с учётных данных, которые есть у каждого

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

Два человека, которые делят один профиль, — это случай, который усложняет каждый следующий шаг. Исправьте это первым, потому что никакой каталог не решает общий секрет.

Выберите хранилище, которое шлюз действительно поддерживает

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

Расположение хранилища менее важно, чем его операции: регистрация, резервное копирование, продление и отзыв. Если ни на одну из них нет ответа, выбор не завершён.

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

Отделите человека от устройств

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

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

Сделайте удаление обычной операцией

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

sudo swanctl --terminate --ike alice-laptop

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