Доступ до VPN для сервісного облікового запису: сертифікат чи спільний вхід
Порівняйте сертифікат машини зі збереженим паролем для доступу до VPN без обслуговування та вмістіть справжню межу дозволів у політику, що виконується після входу.
Майже кожну схему VPN без обслуговування покривають два рішення: спільний людський вхід, збережений у скрипті, або сертифікат машини, прив'язаний до хоста. Вони ламаються в різних місцях, і це важливіше за швидкість налаштування. Збережений пароль ламається, коли власник його змінює або звільняється; сертифікат ламається, коли спливає термін або коли хост перебудовують без ключа. Три умови вирішують, яку ціну ви можете нести, і жодне рішення нічого не обмежує, доки це не зробить політика авторизації.
Починайте із завдання, а не з облікового запису
Завдання задає межу: які призначення, які служби, у які години, як довго може тривати сеанс. Маршрут тунелю — лише половина цієї межі. Шлюз вирішує, чи дозволено сеанс; ресурс за ним вирішує, що сеанс може робити. Спершу напишіть список із названим власником, бо обидві схеми ідентичності мають його задовольняти.
Тримайте автентифікацію та авторизацію окремо, поки записуєте. Автентифікація відповідає, хто підключається; авторизація відповідає, куди сеанс може дістатися потім. RADIUS передає другу частину як атрибути на кшталт Filter-Id, Framed-IP-Address, Session-Timeout і Class, і шлюз додає їх після успішного входу. Схема, яка замінює вхід і залишає авторизацію як є, нічого не обмежила.
Спільний людський вхід: пароль стає межею
Повторне використання людського облікового запису — найшвидший шлях і той, що найгірше старіє. Облікові дані — це пароль, тому він потрапляє в скрипт, файл середовища й конфігурацію планувальника, і кожну копію треба змінювати. Коли власник змінює його в п'ятницю, завдання падає під час наступного запуску, і ніхто не дивиться.
MFA — місце, де ця схема зазвичай руйнується. Скрипт не може відповісти на push-запит, тому обліковий запис виключають із політики, а це саме той запис, який обрав би зловмисник. Винятки, обходи для довірених місць і послаблення для окремих записів множаться, і жодне з них не видно наступному, хто читає налаштування клієнта.
Атрибуція — друга ціна. Кожен сеанс у журналі шлюзу несе однакове ім'я користувача, тому нічну синхронізацію не відрізнити від роботи людини, яка її написала, і відкликання завдання означає відкликання цієї людини.
Сертифікат машини: ідентичність, прив'язана до хоста
Сертифікат змінює питання з того, що знає обліковий запис, на те, чим є хост. За EAP-TLS клієнт подає сертифікат і доводить володіння відповідним закритим ключем; сервер політики зіставляє суб'єкт або обліковий запис комп'ютера з групою та застосовує політику цієї групи. Жодного запиту, жодної спільної таємниці в текстовому файлі.
Створювана межа вужча, ніж очікують люди. Сертифікат автентифікує хост, а не завдання, і будь-хто з правами root або локального адміністратора може використати цей ключ на цьому хості. Тримайте ключ там, де платформа його захищає: неекспортованим у сховищі сертифікатів Windows, з підтримкою TPM там, де профіль це дозволяє, або файлом 0600 у власності root у Linux. Компрометація хоста — це компрометація облікових даних.
Закінчення терміну — повторюваний збій. Сертифікат, що спливає в неділю, зупиняє завдання в неділю, і шлюз зазвичай повідомляє загальну помилку автентифікації, а не називає дату. Перевіряйте дати з хоста завдання в межах інструкції з експлуатації:
openssl x509 -in client.pem -noout -subject -issuer -dates
ipsec listcertsВідкликання потребує шляху, який шлюз перевіряє. OpenVPN читає CRL через опцію crl-verify, а strongSwan залежить від CRL або OCSP залежно від того, як побудовано профіль з'єднання. Якщо не підключено жодного, видалення хоста означає чекати на закінчення терміну сертифіката.
Три умови, що вирішують між ними
Порівнюйте з тією платформою, яка у вас є, а не з еталонною схемою.
Перша умова: чи може шлюз авторизувати ідентичність машини? Якщо він лише зіставляє ім'я користувача RADIUS з користувачем каталогу, сертифікат автентифікує хост і потім застрягає на авторизації. Друга умова: чи потрібен завданню доступ до ресурсів, який несе лише обліковий запис користувача, наприклад підключений спільний ресурс або ліцензія на місце? Тоді ідентичність машини не замінить його, і чесна відповідь — виділений обліковий запис із обмеженою політикою. Третя умова: хто може змінити облікові дані без людини в циклі? Автоматична реєстрація робить сертифікати дешевими в утриманні; пароль, відомий одній людині, — ні.
| Constraint | Machine certificate | Dedicated user account with stored secret |
|---|---|---|
| Unattended login | Private key proof, no prompt | Only if the account is exempted from MFA |
| Resource expects a user identity | Works only when the resource accepts computer accounts | Matches the access a person would have |
| Rotation | Re-enrollment, often automated | Secret change plus redeploy of every copy |
| Revocation speed | Tied to CRL or OCSP refresh | Disable the account, immediate |
Читайте таблицю як список цін, а не як рейтинг. Стовпець збереженої таємниці виграє у швидкості відкликання та в сумісності з ресурсами, які розуміють лише облікові записи користувачів; стовпець сертифіката виграє в ротації та в тому, що не послаблює MFA заради роботи скрипта.
Вмістіть межу в політику, після автентифікації
Яку б ідентичність ви не обрали, межа дозволів належить політиці, що виконується після автентифікації. У NPS мережеві політики оцінюються по порядку, і перша політика, що збігається з усіма умовами, застосовує свої налаштування, тому широка політика, розміщена над вузькою, вирішує результат, хоч би що подав клієнт. Microsoft описує модель умов і налаштувань у своєму огляді політик NPS.
Дайте завданню власну групу або умову політики на основі того, що несе ідентичність машини: шаблон сертифіката, ідентифікатор станції, що викликає, або адреса з виділеного пулу. Потім обмежте сеанс атрибутами: Filter-Id для ролі, до якої його зіставляє шлюз, короткий Session-Timeout, щоб застрягле завдання автентифікувалося заново, а не тримало сеанс днями, і Framed-IP-Address з пулу, який ви фільтруєте міжмережевим екраном на іншому боці. Авторизація застосунку залишається окремою: тунель до сервера бази даних не є дозволом читати таблицю в ній.
Перевірте відмови, потім плануйте видалення
Працюючий доступ нічого не доводить про мінімальні права. Натомість перевіряйте відмови: підключіться з ідентичністю завдання і потягніться до призначення поза списком, відкрийте другий одночасний сеанс, якщо шлюз має дозволяти лише один, і повторіть вхід після відкликання облікових даних.
Потім підтвердьте той самий сеанс у двох місцях. Журнал шлюзу показує ідентичність, яка автентифікувалася; журнал сервера політики показує, яка політика збіглася і які атрибути вона повернула. У OpenVPN сервер записує спільне ім'я сертифіката, а ipsec statusall у strongSwan друкує встановлений тунель з ідентичністю, що використовується. Якщо два журнали розходяться щодо ідентичності, політика збігається не з тим, що ви припускаєте.
Видалення — частина схеми, а не прибиральний спринт. Запишіть усе, що треба видалити (сертифікат або обліковий запис, членство в групі, мережеву політику, запис у пулі, правило міжмережевого екрана на цілі), і прогоніть це один раз, поки завдання легко перебудувати.
Якщо ви починаєте сьогодні, працюйте в такому порядку: напишіть список ресурсів, виберіть ідентичність за трьома умовами, вмістіть межу в політику і відпрацюйте одну відмову до запуску завдання.