Dați utilizatorilor VPN acces la un singur serviciu, nu la subrețea

Un contractant are nevoie de o singură aplicație web internă și de nimic altceva, iar răspunsul ușor este să îi dăm un tunel în subrețeaua serverului. Asta funcționează până în ziua în care o scanează. Designul mai îngust cere mai multă gândire, pentru că accesibilitatea, rutarea și permisiunea aplicației sunt trei controale separate care trebuie să fie de acord.

Scrieți cerința ca serviciu, nu ca subrețea

Începeți cu gazda de destinație, protocolul și portul, apoi adăugați grupul de utilizatori sau de dispozitive care trebuie să ajungă la ea. Includeți zona DNS privată doar dacă aplicația rezolvă un nume, și includeți un furnizor de identitate doar dacă fluxul de autentificare are nevoie de unul. Tot restul este o dependență pe care încă nu ați justificat-o.

O subrețea este un detaliu de implementare al echipei de rețea, în timp ce un serviciu este ceea ce a cerut afacerea și unitatea care poate fi revizuită și retrasă.

Dacă lista de dependențe depășește trei elemente, aplicația are probabil nevoie de propria discuție de design.

Rutați îngust, dar aplicați în altă parte

O rută sau un selector îngust îi spune tunelului ce pachete să transporte; nu este o politică de autorizare. Filtrul gateway-ului, firewall-ul gazdei de destinație și modelul propriu de permisiuni al aplicației sunt locurile unde se decide accesul. O rută care acoperă o singură adresă este un început bun și nu este controlul care oprește un utilizator hotărât. Exact această separare vă permite să schimbați filtrul fără a reproiecta tunelul.

Invers, o rută largă cu un filtru strict poate fi legitimă, dar numai dacă toți cei implicați știu care dintre ele face aplicarea regulii.

Documentați explicit punctul de aplicare, altfel următoarea modificare îl va muta din greșeală.

Verificați sursa pe care serviciul o vede de fapt

Destinația vede fie adresa pool-ului clientului, fie adresa gateway-ului, în funcție de dacă traduceți. Regulile de firewall ale gazdei și jurnalele trebuie să corespundă sursei reale. Dacă mai mulți utilizatori partajează o sursă tradusă, nicio regulă pe utilizator de pe acea gazdă nu îi poate distinge, și aceasta este o constrângere de design, nu un defect.

Alegeți traducerea în mod deliberat: simplifică rutarea și distruge identitatea sursei, ceea ce contează pentru audit și pentru regulile pe utilizator.

Notați care dintre cele două ați ales-o, lângă regula care depinde de ea.

Autorizarea aplicației nu este opțională

A ajunge la un port nu acordă un rol. Aplicația are în continuare nevoie de autentificarea și permisiunile ei, pentru că stratul de rețea nu poate exprima ce înregistrări poate edita un utilizator. Un serviciu care se încrede în orice cerere din subrețeaua internă transformă un tunel îngust în acces complet pentru o singură acreditare compromisă. Tunelul decide cine poate deschide socket-ul, iar aplicația decide ce se poate face cu el.

Aici designul îngust se plătește de două ori, pentru că mai puține gazde accesibile înseamnă mai puține locuri unde o greșeală la nivel de aplicație poate fi exploatată.

Țineți regula de rețea și rolul aplicației în sisteme separate și retrageți-le separat.

Dovediți atât calea permisă, cât și cea refuzată

Conectați-vă ca utilizatorul autorizat și executați o operațiune reprezentativă inofensivă, apoi încercați o destinație care ar trebui să fie inaccesibilă. Un design care testează doar prima jumătate nu este testat, iar testul refuzat este cel care dovedește designul. Testați o sesiune nouă după fiecare modificare de regulă și uitați-vă la calea de întoarcere dacă cererile ajung, dar răspunsurile nu.

Nu dezactivați filtrele de redirecționare pentru ca testul de acceptare să treacă, pentru că asta schimbă lucrul care este testat.

Când utilizatorul nu mai are nevoie de serviciu, retrageți identitatea la distanță și rolul aplicației în sistemele lor respective și înregistrați-le pe amândouă. Ghidul strongSwan de redirecționare acoperă partea de gateway a căii.