Acces de la VPN la VLAN: întâi matricea, apoi regulile
Roluri pe o parte, servicii pe cealaltă. Cinci verificări transformă un proiect vag de acces de la VPN la VLAN într-un tabel pe care proprietarul firewall-ului îl poate implementa.
Începeți cu matricea, nu cu sintaxa firewall-ului. Un tabel cu roluri pe o parte și servicii pe cealaltă poate fi revizuit de un proprietar de aplicație, dezbătut de un proprietar de securitate și implementat de cel care ține gateway-ul. Acea revizuire costă mai puțin decât depanarea unor reguli asupra cărora nimeni nu s-a înțeles.
O oră de scriere economisește mai târziu o săptămână de arheologie a regulilor. Proiectul vorbește despre cine ajunge la ce serviciu, iar aceasta este partea care supraviețuiește renumerotării.
Pasul 1: numiți rolurile înaintea rețelelor
Începeți cu oamenii, nu cu switch-ul. Notați fiecare grup care se conectează de la distanță și propoziția unică ce descrie ce face acel grup, de exemplu personalul de depozit care citește nivelurile de stoc sau un contractor care întreține o singură integrare. Dacă două grupuri ar primi același acces, pentru acest scop sunt un singur rol.
Opriți-vă aici dacă un rol există doar din cauza unei organigrame. Un rol fără o nevoie proprie de serviciu devine un rând de celule identice, iar rândurile identice îndeamnă pe cineva să acorde mai târziu un întreg subnet pentru comoditate. Împărțiți după ce fac oamenii, nu după cine le semnează cheltuielile. Șase roluri sunt de obicei prea multe pentru un birou mic, iar trei este adesea corect.
Pasul 2: transformați fiecare celulă într-o afirmație de serviciu
O celulă în care scrie „Aplicații” nu este verificabilă. O celulă în care scrie „HTTPS către gazda ERP pe 443, din grupul personalului” este. Înlocuiți fiecare nume de rețea cu o destinație, un protocol și un port, apoi adăugați dependența fără de care serviciul nu funcționează, cum ar fi resolverul intern sau furnizorul de identitate.
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
Coloana de direcție prinde cele mai scumpe greșeli. Permisiunea ca personalul să deschidă o aplicație nu implică permisiunea ca serverele de aplicații să deschidă conexiuni înapoi către laptopurile personalului, iar o regulă cu stare care permite prima direcție este adesea citită ca și cum ar permite a doua.
Pasul 3: decideți unde identitatea devine politică
Cineva trebuie să transforme o sesiune autentificată într-un rol pe care gateway-ul îl poate impune. Opțiunile acceptate includ politica de grup livrată de backend-ul de autentificare, atribute de sesiune de încredere sau grupuri separate de adrese pentru fiecare rol. Toate trei funcționează; o etichetă trimisă de client nu. Alegeți mecanismul documentat de gateway-ul vostru, nu pe cel descris de o postare pe forum.
Atribuirea unei adrese care doar pare că aparține unui VLAN este același non-răspuns într-un alt costum. Ghidul Netgate privind regulile de firewall OpenVPN face separarea clară: a permite tunelului să urce este o decizie diferită de a permite traficului să treacă prin el.
Notați ce mecanism ați ales și unde este configurat. Când un rol se schimbă, acea notă este diferența dintre o singură modificare și o vânătoare prin trei interfețe. De asemenea, îi spune unui auditor unde să se uite mai întâi.
Pasul 4: urmăriți adresa sursă pe care o vede destinația
Politica de forwardare trebuie să corespundă sursei reale la graniță. Dacă gateway-ul traduce clienții VPN în propria adresă, fiecare firewall din aval vede o singură sursă și pierde capacitatea de a decide pe roluri. Dacă păstrează adresa clientului, calea de întoarcere trebuie să existe pentru acel grup.
Testați ambele direcții înainte de a scrie regulile finale, apoi notați sursa observată lângă fiecare celulă. Rulați aceeași verificare din două roluri diferite și comparați rezultatul. Dacă ambele arată adresa gateway-ului, distincția pe roluri s-a pierdut deja. O matrice care presupune adrese păstrate în timp ce gateway-ul face traducere de sursă eșuează la primul ACL din aval.
Pasul 5: testați fiecare celulă înainte de a o livra
Transformați fiecare celulă permisă într-o operație reprezentativă și fiecare celulă refuzată într-un caz negativ. Rulați ambele de pe un client din rolul real, nu din consola gateway-ului, pentru că consola ocolește calea pe care o testați.
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'Un caz negativ care se conectează este o descoperire, nu o întâmplare, și locul lui este în matrice ca celulă eșuată până când regula este corectată. Țineți comenzile de test lângă tabel, ca următorul recenzent să le ruleze din nou în loc să reconstruiască raționamentul.
Tabelul terminat supraviețuiește gateway-ului pentru care a fost scris. Regulile se schimbă cu firmware-ul și furnizorul, în timp ce rândul care spune că un contractor ajunge la un serviciu de proiect rămâne adevărat până când acea activitate se schimbă.