VPN для маленького офиса: держите его отдельно от контроллера домена

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

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

Две задачи с двумя разными профилями воздействия

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

Разделение ролей не устраняет зависимости. Удалённым пользователям по-прежнему нужны аутентификация, маршруты, DNS и правила доступа, а шлюз, который их пропускает, не безопаснее, просто менее полезен.

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

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

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

Один хост остаётся одним доменом отказа

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

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

Окно обслуживания, которое требует работающего VPN, чтобы починить VPN, — не окно обслуживания.

Переместите его, не заперев себя снаружи

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

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

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