Шматкліенцкі 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 па архітэктуры нулявога даверу — тут правільнае спасыланне, бо яно ставіць аўтэнтыфікацыю і аўтарызацыю на рэсурс замест даверу да сеткавай пазіцыі, і гэта датычыцца таксама ўнутры ўласнага сегмента кліента.
Узважце дазволеныя і забароненыя патокі, апрацоўку перасякальных адрасоў і працэдуру вываду з эксплуатацыі, перш чым узважваць бенчмаркі пратаколаў. Затым выберыце транспарт і метад аўтэнтыфікацыі, якія адпавядаюць абранай мяжы. Старэйшая назва прадукту або сцвярджэнне, што кожны бізнес мусіць стандартызавацца на адным пратаколе, не вырашае нічога з гэтага. Карта, якую вы напісалі першай, вырашае.