Дайте пользователям VPN доступ к одной службе, а не к подсети

Подрядчику нужна одна внутренняя веб-служба и больше ничего, и простой ответ — дать ему туннель в подсеть сервера. Это работает до дня, когда он просканирует её. Более узкий дизайн требует больше размышлений, потому что доступность, маршрутизация и разрешение приложения — три отдельных контроля, которые должны согласовываться.

Запишите требование как службу, а не как подсеть

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

Подсеть — деталь реализации сетевой команды, а служба — то, что попросил бизнес, и единица, которую можно проверить и вывести из эксплуатации.

Если список зависимостей превышает три пункта, приложению, вероятно, нужен собственный разговор о дизайне.

Маршрутизируйте узко, но применяйте контроль в другом месте

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

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

Явно задокументируйте точку контроля, иначе следующее изменение случайно её переместит.

Проверьте источник, который служба действительно видит

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

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

Запишите, какой из двух вариантов вы выбрали, рядом с правилом, которое от него зависит.

Авторизация приложения не является необязательной

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

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

Держите сетевое правило и роль приложения в разных системах и выводите их из эксплуатации по отдельности.

Докажите и разрешённый, и запрещённый путь

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

Не отключайте фильтры пересылки, чтобы приёмочный тест прошёл, потому что это меняет то, что тестируется.

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