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