Rozhodněte, kdo přijímá zákazníka a co tomuto zákazníkovi brání dosáhnout na prostředky jiného tenanta. To jsou dvě rozhodnutí a volba IPsec, WireGuard nebo mesh produktu neodpovídá ani na jedno. Tunel, který se naváže bezchybně, může přesto nechat každého tenanta dosáhnout na všechny ostatní, a recenze, která obě věci považuje za totéž, schvaluje špatný návrh. Nejprve napište mapu zákazník–prostředek: správci, přístup podpory, sdílené služby a cesty, které musí zůstat zakázané.

Začněte mapou, ne produktem

Ta mapa je první artefakt a každá volba níže je jen rozhodnutím o tom, kde žije hranice, která ji vynucuje. Udržte ji kontrolovatelnou: jeden řádek na zákazníka, jeden řádek na sdílenou službu a vypsané zakázané cesty.

Mapa, kterou nikdo nepřečte, je mapa, kterou nikdo nevynutí.

Jeden vstupní bod a jeho problém mapování

O každém umístění rozhoduje jediná provozní otázka a tabulka je celé srovnání.

PlacementThe question it lives or dies on
One shared gatewayHow does an admitted identity end up limited to its own resources and its own routing context?
A gateway per tenantWho owns each gateway, its credentials, its policy, its updates and its eventual retirement?
A connection per hosted machineHow do enrollment, per-machine policy and replacement work at fleet scale?

Sdílená brána centralizuje přijetí a soustřeďuje riziko na jedno místo: vazbu mezi identitou tenanta a jeho politikou. Skupiny nebo adresy tunelů se musí přeložit na správná oprávnění k prostředkům, a jiný štítek pro každého zákazníka sám o sobě nic nebrání. Oddělené kontexty směrování mohou držet překrývající se prefixy, když to platforma podporuje a návrh je úplný. Obyčejná sdílená směrovací tabulka nerozliší dva shodné cílové prefixy jen proto, že lidé za nimi mají různé účty.

To je test pro většinu návrhů. Dva tenanti, kteří interně číslují s 10.0.0.0/8, potřebují oddělený směrovací stav, ne konvenci pojmenování.

Brána pro každého tenanta kupuje hranice a systémy

Jedna brána na zákazníka usnadňuje vysvětlení některých administrativních hranic, protože přijetí a politika tohoto zákazníka jsou pohromadě. Také znásobuje systémy, které potřebují přihlašovací údaje, záplaty, monitorování a vlastníka. A nevnucuje jedno předepsané uspořádání veřejných adres: sdílení koncových bodů, překlad a demultiplexing protokolů závisí na tom, co implementace skutečně podporuje.

Spočítejte systémy a lidi, než spočítáte bezpečnostní zisk. Návrh se čtyřmi bránami navíc, než tým stačí záplatovat, není v praxi izolovanější.

Pokud se počet tenantů každý měsíc mění, tento model potřebuje příběh automatizace, ne šablonu.

Připojení pro každý host přesouvají práci

Připojení na každém hostovaném stroji neodstraňuje provozní práci, přesouvá ji do životního cyklu stroje. Zapsání, politika pro stroj, rotace klíčů a výměna se stávají součástí zřizování a selhávají ve stejném okně jako stroj sám. Pro hrst dlouhověkých hostů v odlišných sítích je to často správně, a pro flotilu, která už ztratila přehled o tom, který obraz kde běží, zřídka.

Pojmenujte roli pro vydávání identit, aktualizace, odebrání přístupu, monitorování a obnovu u každé možnosti. Pak se zeptejte, co se stane v den, kdy jeden zákazník odejde.

Vyřazení patří do srovnání

Většina srovnání vyřazení vynechává. Odebrání tenanta má zneplatnit jeho přihlašovací údaje, zahodit jeho politiku, uvolnit jeho adresy a směrovací stav a nechat všechny ostatní nedotčené. Pokyny NIST k architektuře nulové důvěry jsou zde správným odkazem, protože stavějí ověřování a autorizaci na prostředek místo důvěry v síťovou pozici, a to platí i uvnitř zákazníkova vlastního segmentu.

Zvažte povolené a zakázané toky, zacházení s překrývajícími se adresami a postup vyřazení, než zvážíte protokolové benchmarky. Pak zvolte přenos a metodu ověřování, které odpovídají hranici, kterou jste zvolili. Starší název produktu nebo tvrzení, že každá firma musí standardizovat na jediném protokolu, nic z toho neřeší. Mapa, kterou jste napsali první, to řeší.

Související články