Accés de VPN a VLAN: construïu la matriu abans que les regles
Rols a una banda, serveis a l'altra. Cinc comprovacions converteixen un disseny vague d'accés de VPN a VLAN en una taula que el propietari del tallafoc pot implementar.
Comenceu per la matriu, no per la sintaxi del tallafoc. Una taula amb rols a una banda i serveis a l'altra la pot revisar el propietari d'una aplicació, discutir-la el propietari de seguretat i implementar-la qui tingui la passarel·la. Aquesta revisió surt més barata que depurar regles sobre les quals ningú no s'ha posat d'acord.
Una hora d'escriure-la estalvia una setmana d'arqueologia de regles després. El disseny parla de qui arriba a quin servei, i aquesta és la part que sobreviu a la renumeració.
Pas 1: anomeneu els rols abans que les xarxes
Comenceu per les persones, no pel commutador. Anoteu cada grup que es connecta remotament i la frase única que descriu què fa aquest grup, com ara personal de magatzem que llegeix nivells d'estoc o un contractista que manté una integració. Si dos grups rebrien el mateix accés, per a aquest propòsit són un sol rol.
Atureu-vos aquí si un rol només existeix per un organigrama. Un rol sense una necessitat de servei pròpia es converteix en una fila de cel·les idèntiques, i les files idèntiques conviden algú a concedir més endavant una subxarxa sencera per comoditat. Dividiu pel que fa la gent, no per qui signa les seves despeses. Sis rols solen ser massa per a una oficina petita i tres sovint és el correcte.
Pas 2: convertiu cada cel·la en una declaració de servei
Una cel·la que diu «Aplicacions» no és verificable. Una cel·la que diu «HTTPS a l'amfitrió ERP al 443, des del pool de personal» sí que ho és. Substituïu cada nom de xarxa per una destinació, un protocol i un port, i després afegiu la dependència sense la qual el servei no funciona, com el resolutor intern o el proveïdor d'identitat.
| 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 |
La columna de direcció atrapa els errors més cars. El permís perquè el personal obri una aplicació no implica permís perquè els servidors d'aplicacions obrin connexions de tornada als portàtils del personal, i una regla amb estat que permet la primera direcció sovint es llegeix com si permetés la segona.
Pas 3: decidiu on la identitat es converteix en política
Algú ha de convertir una sessió autenticada en un rol que la passarel·la pugui aplicar. Les opcions admeses inclouen política de grup lliurada pel backend d'autenticació, atributs de sessió de confiança o pools d'adreces separats per rol. Les tres funcionen; una etiqueta enviada pel client no. Trieu el mecanisme que documenta la vostra passarel·la, no el que descriu una publicació d'un fòrum.
Assignar una adreça que només sembla que pertany a una VLAN és la mateixa no-resposta amb un altre vestit. La guia de Netgate sobre les regles de tallafoc d'OpenVPN fa clara la separació: permetre que el túnel s'aixequi és una decisió diferent de permetre que el trànsit hi passi.
Anoteu quin mecanisme heu triat i on està configurat. Quan un rol canvia, aquesta nota és la diferència entre una edició i una cacera per tres interfícies. També diu a un auditor on mirar primer.
Pas 4: vigileu l'adreça d'origen que veu la destinació
La política de reenviament ha de coincidir amb l'origen real a la frontera. Si la passarel·la tradueix els clients VPN a la seva pròpia adreça, cada tallafoc posterior veu un sol origen i perd la capacitat de decidir per rol. Si conserva l'adreça del client, el camí de tornada ha d'existir per a aquest pool.
Proveu les dues direccions abans d'escriure les regles finals, i després anoteu l'origen observat al costat de cada cel·la. Executeu la mateixa comprovació des de dos rols diferents i compareu el resultat. Si tots dos mostren l'adreça de la passarel·la, la distinció de rols ja s'ha perdut. Una matriu que assumeix adreces conservades mentre la passarel·la fa traducció d'origen falla a la primera ACL posterior.
Pas 5: proveu cada cel·la abans de publicar
Convertiu cada cel·la permesa en una operació representativa i cada cel·la denegada en un cas negatiu. Executeu tots dos des d'un client amb el rol real, no des de la consola de la passarel·la, perquè la consola salta el camí que esteu provant.
# 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 cas negatiu que connecta és una troballa, no una casualitat, i pertany a la matriu com a cel·la fallida fins que la regla es corregeixi. Manteniu les ordres de prova al costat de la taula perquè el proper revisor les torni a executar en lloc de reconstruir el raonament.
La taula acabada sobreviu a la passarel·la per a la qual es va escriure. Les regles canvien amb el firmware i el proveïdor, mentre que la fila que diu que un contractista arriba a un servei de projecte continua sent certa fins que aquesta feina canvia.