Мультитенантний 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 щодо архітектури нульової довіри тут правильне посилання, бо вони ставлять автентифікацію та авторизацію на ресурс, а не на довіру до мережевої позиції, і це діє також усередині власного сегмента клієнта.
Зважте дозволені та заборонені потоки, поводження з перекриваними адресами і процедуру виведення з експлуатації, перш ніж зважувати еталонні показники протоколів. Потім виберіть транспорт і метод автентифікації, що відповідають обраній межі. Старіша назва продукту або твердження, що кожен бізнес має стандартизуватися на одному протоколі, нічого з цього не вирішує. Карта, написана першою, вирішує.