VPN для малого офісу: тримайте його окремо від контролера домену

Три умови визначають, чи має єдиний сервер Windows в офісі також завершувати VPN: скільки зверненого в інтернет програмного забезпечення ви готові запускати на каталозі, чи можете ви автентифікувати віддалених користувачів без цієї ролі і що станеться з вашим адміністративним доступом під час перезавантаження хоста. Якщо хоча б одна з трьох має погану відповідь, розділіть ролі. Те, що офіс малий, змінює бюджет, а не ризик.

Кожна машина домену довіряє контролеру домену; шлюз VPN доступний будь-кому в інтернеті. Ця асиметрія — весь аргумент.

Два завдання з двома різними профілями впливу

Шлюз приймає з'єднання ззовні, тому його слухач, стек TLS і поверхня автентифікації доступні з недовірених мереж. Каталог зберігає повноваження, якому довіряють інші машини, тому рекомендації Microsoft щодо посилення захисту розглядають роль контролера домену та середовище його розміщення як особливо чутливі. Кожна служба, додана на цей хост, успадковує становище довіри каталогу і додає власну поверхню атаки. Зручність встановлення — не межа довіри.

Розділення ролей не усуває залежностей. Віддаленим користувачам усе ще потрібні автентифікація, маршрути, DNS і правила доступу, а шлюз, який їх пропускає, не безпечніший, просто менш корисний.

Автентифікація без ролі каталогу

Шлюз може перевіряти облікові дані через підтримувану зовнішню інтеграцію, не розміщуючи сам каталог. Якою б не була ця інтеграція, дайте їй обліковий запис, права якого відповідають меті: читання атрибутів, потрібних для автентифікації, і нічого більше. Допуск користувачів VPN ніколи не вимагає робити їхні звичайні облікові записи адміністраторами домену і ніколи не вимагає, щоб шлюз зберігав копію каталогу.

Потім обмежте мережеві шляхи, які віддаленому клієнту справді потрібні. Доступ до однієї внутрішньої файлової служби плюс служби розв'язання імен та ідентичності, від яких залежить цей робочий процес, — це визначений набір шляхів. Це не причина дозволяти кожен порт контролера домену чи кожен адміністративний інтерфейс із пулу VPN.

Один хост залишається одним доменом відмови

Два гості на одному гіпервізорі розділяють конфігурацію операційних систем і не розділяють свою долю. Адміністратори гіпервізора, віртуальна комутація, сховище та резервні копії залишаються частиною проєкту, а перезавантаження хоста прибирає обидві служби одразу. Називати це високою доступністю тому, що на схемі дві VM, — поширена й дорога помилка. Якщо єдиний шлях назад іде через VPN на цьому хості, збій забирає з'єднання, потрібне для його лагодження.

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

Вікно обслуговування, яке вимагає працюючого VPN, щоб полагодити VPN, — не вікно обслуговування.

Перемістіть його, не замкнувши себе ззовні

Якщо ролі вже ділять одне встановлення, уникайте квапливої віддаленої міграції. Складіть опис того, чим шлюз володіє сьогодні: адреси, правила пересилання, NAT, налаштування DNS, конфігурація автентифікації та будь-які опубліковані служби. Підготуйте і заміну, і шлях назад, перш ніж переміщати слухач або змінювати маршрут за замовчуванням. Потім перевірте реальну роботу звичайного віддаленого користувача через нову межу й переконайтеся, що непотрібний адміністративний доступ досі не проходить.

Мета — не красивіша схема. Це здатність полагодити або перебудувати VPN, не торкаючись коробки, яка закріплює довіру каталогу для всього офісу. Це різні цілі, і лише одна з них потребує другого сервера.

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