Centralizează accesul VPN al partenerilor fără a-i uni pe parteneri

Propunerea este rezonabilă: cinci tuneluri de partener răspândite pe o duzină de laptopuri, cinci seturi de versiuni de client, cinci scripturi de help desk și un inginer care știe cum se potrivesc. Mutarea lor într-un nivel de acces controlat rezolvă împrăștierea endpoint-urilor. În același timp creează un obiect nou în arhitectură — un serviciu de acces comun care are acum nevoie de propriul model de autorizare; iar eșecul pe care toți îl subestimează este un echipament central cu toate tunelurile activate care devine încet o rețea de tranzit între organizații care nu au fost niciodată de acord să fie vecine. Acel risc este o decizie de proiectare, nu ceva ce face hardware-ul de la sine. Lucrarea de mai jos este felul în care păstrez confortul fără să accept efectul secundar accidental.

Începe cu contractul pe care fiecare partener l-a semnat deja

Înainte de orice configurare, confirmă că partenerul permite măcar un gateway sau o conexiune de site comună. Un cont personal de acces la distanță, o cerință de postură a dispozitivului sau un flux MFA interactiv pot să nu fie transferabile către un tunel comun nesupravegheat, iar gruparea angajaților în spatele unei identități de client copiate este genul de scurtătură care rezistă până când partenerul își auditează jurnalele. Pentru fiecare conexiune permisă, notează intervalele de destinație, domeniile DNS private, sursele interne autorizate, responsabilul autentificării și ce trebuie să se întâmple când tunelul eșuează. Roagă partenerul să confirme în scris conexiunea comună, inclusiv intervalele de sursă pe care le va accepta. Aprobarea verbală tinde să își schimbe sensul în săptămâna în care echipa lor de securitate se schimbă.

Acel registru este rezultatul. Dacă nu îl poți scrie pentru un partener, acel partener nu este pregătit pentru centralizare.

Rutează după context, nu doar după destinație

Doi parteneri vor folosi în cele din urmă același interval privat, pentru că fiecare organizație alege din același spațiu RFC 1918. Un singur tabel de rutare obișnuit nu poate alege partenerul corect doar după adresa de destinație, așa că intervalele care se suprapun au nevoie de contexte de rutare separate sau de altă soluție convenită. Modelul de domeniu de forwarding din RFC 4364 descrie de ce contează această separare, iar o implementare nu trebuie să ruleze MPLS pentru a cere aceeași proprietate platformei sale de gateway.

Pune platformei o întrebare directă: pot doi parteneri să partajeze același prefix de destinație și totuși să fie distinși după contextul angajatului din care a venit sesiunea? Dacă răspunsul este nu, acea constrângere modelează proiectarea mai mult decât orice listă de funcții a unui furnizor.

Acolo unde răspunsul este da, contextul de rutare devine ceea ce documentezi și testezi, pentru că este invizibil într-un traceroute.

Decide ce tastează angajatul și ce jurnalizează partenerul

O parte din munca partenerului se potrivește unui proxy de aplicație sau unui spațiu de lucru la distanță deschis în contextul acelui partener. Altă muncă necesită acces de rețea rutat dintr-un segment de angajați aprobat, iar cele două produc adrese de sursă diferite și urme de audit diferite la celălalt capăt. O adresă de sursă tradusă comună poate satisface o listă de permisiuni ascunzând în același timp ce dispozitiv a făcut ce, așa că păstrează o legătură fiabilă între angajat și sesiune și menține autentificarea aplicației, în loc să tratezi adresa gateway-ului ca identitate — ceea ce e comod exact până când partenerul întreabă cine a făcut-o.

Apoi parcurge o sarcină reală din partea angajatului: pe ce dau click, ce li se cere și ce ar vedea partenerul dacă ar cere o intrare de jurnal. Dacă parcurgerea nu este reproductibilă, proiectarea nu este terminată.

Interzice explicit tranzitul între parteneri

Hardware-ul comun nu trebuie să implice niciodată încredere comună. Adaugă interdicția ca regulă deliberată cu un responsabil numit, nu ca accident al unei configurații lipsă, și testeaz-o din ambele direcții cu o cerere care altfel ar reuși. Testul contează pentru că o permisiune care doar lipsește poate fi restaurată de următorul inginer care adaugă o rută pentru a repara o reclamație nelegată.

Scrie interdicția în registrul partenerului lângă permisiuni, ca intenția să supraviețuiască schimbărilor de personal.

Rulează-l ca serviciu comun, nu ca laptop mai mare

Reînnoirea tunelurilor, rotația acreditărilor, capacitatea și înlocuirea gateway-ului devin acum toate modificări ale unui serviciu comun, ceea ce înseamnă că au nevoie de un calendar și de o cale de comunicare pe care laptopurile individuale nu le-au cerut niciodată. Un certificat de partener care expiră într-o sâmbătă nu mai este întreruperea unui singur utilizator; este întreruperea tuturor sesiunilor acelui partener deodată.

Acceptă nivelul doar când o cerere refuzată între parteneri eșuează exact cum a fost proiectată și o cerere permisă a unui angajat ajunge la destinația corectă cu sursa corectă. Eliminarea conflictului dintre laptopuri păstrând intactă granița fiecărui partener este tot rostul; un design în care fiecare prefix la distanță este accesibil din fiecare birou a mutat doar problema.

Ține un tabel mic cu partener, context, intervale permise și responsabil. Va fi primul lucru pe care cineva îl cere în timpul unui incident.