Реєстрація користувача VPN: спершу знайдіть власника ідентичності

Хтось просить доступ до 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 і який пристрій або профіль представляє з'єднання. Це можуть бути три різні системи, і план відкликання, який називає лише одну з них, залишає шлях відкритим. Коли людина йде, зніміть право в його власника і відкличте кожен виданий обліковий документ у його власника. Видалення завантаженого файлу — не відкликання, і видалення локального запису теж, якщо зовнішня ідентичність усе ще проходить автентифікацію.

Потім перевірте реєстрацію так, як це зробив би зловмисник: підключіться один раз з новою ідентичністю, підтвердьте доступ до передбаченого ресурсу і підтвердьте, що не пов'язаний ресурс усе ще відмовляє. Перше робоче підключення плюс негативний тест — це завершена реєстрація.

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