Мультитенантный VPN: общий шлюз, на арендатора или на хост
Туннель — это не изоляция арендаторов. Сравните общий шлюз, шлюзы на каждого арендатора и подключения на каждый хост по сопоставлению идентичностей, маршрутизации и выводу из эксплуатации.
Решите, кто допускает клиента и что не даёт этому клиенту добраться до ресурсов другого арендатора. Это два решения, и выбор IPsec, WireGuard или mesh-продукта не отвечает ни на одно. Туннель, который поднимается безупречно, всё равно может оставить каждому арендатору доступ ко всем остальным, а обзор, который считает эти две вещи одним и тем же, одобряет неверный проект. Сначала напишите карту «клиент — ресурс»: администраторы, доступ поддержки, общие сервисы и пути, которые должны оставаться запрещёнными.
Начните с карты, а не с продукта
Эта карта — первый артефакт, и каждый выбор ниже — лишь решение о том, где живёт граница, которая его обеспечивает. Держите её пригодной для обзора: одна строка на клиента, одна строка на общий сервис и выписанные запрещённые пути.
Карта, которую никто не может прочитать, — это карта, которую никто не станет обеспечивать.
Одна точка допуска и её проблема сопоставления
Каждое размещение решается одним операционным вопросом, и таблица — всё сравнение.
| Placement | The question it lives or dies on |
|---|---|
| One shared gateway | How does an admitted identity end up limited to its own resources and its own routing context? |
| A gateway per tenant | Who owns each gateway, its credentials, its policy, its updates and its eventual retirement? |
| A connection per hosted machine | How do enrollment, per-machine policy and replacement work at fleet scale? |
Общий шлюз централизует допуск и концентрирует риск в одном месте: связь между идентичностью арендатора и его политикой. Группы или адреса туннелей должны сводиться к правильным правам на ресурсы, а отдельная метка на каждого клиента сама по себе ничего не предотвращает. Раздельные контексты маршрутизации могут хранить перекрывающиеся префиксы, когда платформа это поддерживает и проект полон. Обычная общая таблица маршрутизации не различает два одинаковых префикса назначения только потому, что у людей за ними разные учётные записи.
Это проверка для большинства проектов. Двум арендаторам, которые внутри нумеруются через 10.0.0.0/8, нужно раздельное состояние маршрутизации, а не соглашение об именах.
Шлюз на арендатора покупает границы и системы
Один шлюз на клиента делает часть административных границ легко объяснимыми, потому что допуск и политика этого клиента находятся вместе. Зато он размножает системы, которым нужны учётные данные, патчи, мониторинг и владелец. И он не навязывает единственную предписанную схему публичных адресов: совместное использование конечных точек, трансляция и демультиплексирование протоколов зависят от того, что реализация действительно поддерживает.
Сосчитайте системы и людей, прежде чем считать выигрыш в безопасности. Проект, в котором шлюзов на четыре больше, чем команда успевает патчить, на практике не изолированнее.
Если число арендаторов меняется каждый месяц, такой модели нужна история автоматизации, а не шаблон.
Подключения на каждый хост переносят работу
Подключение на каждой размещённой машине не убирает эксплуатационную работу, а переносит её в жизненный цикл машины. Регистрация, политика на машину, ротация ключей и замена становятся частью провижининга, и они отказывают в том же окне, что и сама машина. Для горстки долгоживущих хостов в разных сетях это часто правильно, а для парка, который уже потерял счёт тому, какой образ где работает, — редко.
Назовите роль для выдачи идентичностей, обновлений, отзыва доступа, мониторинга и восстановления при каждом варианте. Затем спросите, что происходит в день, когда один клиент уходит.
Вывод из эксплуатации входит в сравнение
Большинство сравнений пропускает вывод из эксплуатации. Удаление арендатора должно аннулировать его учётные данные, снять его политику, освободить его адреса и состояние маршрутизации и оставить всех остальных нетронутыми. Руководство NIST по архитектуре нулевого доверия здесь правильная ссылка, потому что оно ставит аутентификацию и авторизацию на ресурс, а не на доверие к сетевой позиции, и это действует и внутри собственного сегмента клиента.
Взвесьте разрешённые и запрещённые потоки, обработку перекрывающихся адресов и процедуру вывода из эксплуатации, прежде чем взвешивать эталонные показатели протоколов. Затем выберите транспорт и метод аутентификации, подходящие к выбранной границе. Более старое имя продукта или утверждение, что каждый бизнес должен стандартизироваться на одном протоколе, ничего из этого не решает. Карта, написанная первой, решает.