VPN multi-chiriaș: gateway partajat, pe chiriaș sau pe gazdă
Un tunel nu este izolare între chiriași. Comparați un gateway partajat, gateway-uri pe chiriaș și conexiuni pe gazdă în privința mapării identităților, rutării și scoaterii din uz.
Decideți cine admite un client și ce împiedică acel client să ajungă la resursele altui chiriaș. Sunt două decizii, iar alegerea IPsec, WireGuard sau a unui produs mesh nu răspunde la niciuna. Un tunel care se ridică perfect poate lăsa totuși fiecare chiriaș capabil să ajungă la toți ceilalți, iar o analiză care tratează cele două ca același lucru aprobă proiectul greșit. Scrieți mai întâi harta client-la-resursă: administratori, acces de suport, servicii partajate și căile care trebuie să rămână interzise.
Începeți cu harta, nu cu produsul
Acea hartă este primul artefact, iar fiecare alegere de mai jos este doar o decizie despre unde se află granița care o impune. Țineți-o revizuibilă: un rând pe client, un rând pe serviciu partajat și căile interzise scrise.
O hartă pe care nimeni nu o poate citi este o hartă pe care nimeni nu o va impune.
Un singur punct de admitere și problema lui de mapare
Fiecare plasare este decisă de o singură întrebare operațională, iar tabelul este întreaga comparație.
| 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? |
Un gateway partajat centralizează admiterea și concentrează riscul într-un singur loc: asocierea dintre identitatea unui chiriaș și politica sa. Grupurile sau adresele tunelului trebuie să se rezolve în permisiunile de resursă corecte, iar o etichetă diferită pe client nu împiedică nimic de la sine. Contextele de rutare separate pot ține prefixe suprapuse când platforma o susține și proiectul este complet. O tabelă de rutare partajată simplă nu poate distinge două prefixe de destinație identice doar pentru că oamenii din spate au conturi diferite.
Acesta este testul pentru majoritatea proiectelor. Doi chiriași care numerotează intern cu 10.0.0.0/8 au nevoie de stare de rutare separată, nu de o convenție de denumire.
Un gateway pe chiriaș cumpără granițe și sisteme
Un gateway pe client face unele granițe administrative ușor de explicat, pentru că admiterea și politica acelui client stau împreună. Multiplică însă sistemele care au nevoie de acreditări, patch-uri, monitorizare și un proprietar. Și nu impune o singură aranjare prescrisă a adreselor publice: partajarea punctelor finale, traducerea și demultiplexarea protocoalelor depind de ce susține implementarea cu adevărat.
Numărați sistemele și oamenii înainte de a număra câștigul de securitate. Un proiect cu patru gateway-uri mai multe decât poate echipa să patch-uiască nu este mai izolat în practică.
Dacă numărul de chiriași se schimbă lunar, acel model are nevoie de o poveste de automatizare, nu de un șablon.
Conexiunile pe gazdă mută munca
O conexiune pe fiecare mașină găzduită nu elimină munca operațională, o mută în ciclul de viață al mașinii. Înregistrarea, politica pe mașină, rotația cheilor și înlocuirea devin parte din provizionare și eșuează în aceeași fereastră ca mașina însăși. Pentru câteva gazde longevive în rețele distincte este adesea corect, iar pentru o flotă care a pierdut deja evidența imaginii care rulează unde, rareori.
Numiți un rol pentru emiterea identității, actualizări, retragerea accesului, monitorizare și recuperare la fiecare opțiune. Apoi întrebați ce se întâmplă în ziua în care un client pleacă.
Scoaterea din uz face parte din comparație
Majoritatea comparațiilor sar peste scoaterea din uz. Eliminarea unui chiriaș ar trebui să îi invalideze acreditările, să îi elimine politica, să îi elibereze adresele și starea de rutare și să lase pe toți ceilalți neatinși. Îndrumările NIST privind arhitectura zero trust sunt referința corectă aici, pentru că pun autentificarea și autorizarea pe resursă în loc să se bazeze pe o poziție în rețea, iar asta se aplică și în interiorul segmentului propriu al unui client.
Cântăriți fluxurile permise și interzise, tratarea adreselor suprapuse și procedura de scoatere din uz înainte de a cântări indicatorii de protocol. Apoi alegeți un transport și o metodă de autentificare care se potrivesc graniței alese. Un nume de produs mai vechi, sau afirmația că fiecare afacere trebuie să se standardizeze pe un singur protocol, nu rezolvă nimic din toate acestea. Harta pe care ați scris-o prima o face.