Toegang van VPN naar VLAN: bouw eerst de matrix, dan de regels
Rollen aan de ene kant, diensten aan de andere. Vijf controles maken van een vaag VPN-naar-VLAN-ontwerp een tabel die een firewallbeheerder kan implementeren.
Begin met de matrix, niet met de firewallsyntaxis. Een tabel met rollen aan de ene kant en diensten aan de andere kan door een applicatiebeheerder worden nagelezen, door een securitybeheerder worden bediscussieerd en door degene die de gateway heeft worden geïmplementeerd. Die doorloop is goedkoper dan het debuggen van regels waar niemand het over eens is geworden.
Een uur schrijven bespaart later een week regels-archeologie. Het ontwerp gaat over wie welke dienst bereikt, en dat is het deel dat een hernummering overleeft.
Stap 1: benoem de rollen vóór de netwerken
Begin bij de mensen, niet bij de switch. Noteer elke groep die op afstand verbindt en de enige zin die beschrijft wat die groep doet, bijvoorbeeld magazijnpersoneel dat voorraadniveaus leest of een aannemer die één integratie onderhoudt. Als twee groepen dezelfde toegang zouden krijgen, zijn ze voor dit doel één rol.
Stop hier als een rol alleen bestaat vanwege een organogram. Een rol zonder eigen dienstbehoefte wordt een rij identieke cellen, en identieke rijen nodigen iemand uit om later voor het gemak een heel subnet toe te kennen. Deel naar wat mensen doen, niet naar wie hun uitgaven ondertekent. Zes rollen zijn meestal te veel voor een klein kantoor en drie is vaak goed.
Stap 2: maak van elke cel een dienstverklaring
Een cel met de tekst „Applicaties” is niet testbaar. Een cel met de tekst „HTTPS naar de ERP-host op 443, uit de personeelspool” is dat wel. Vervang elke netwerknaam door een bestemming, een protocol en een poort, en voeg dan de afhankelijkheid toe zonder welke de dienst niet werkt, zoals de interne resolver of de identiteitsprovider.
| 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 |
De richtingkolom vangt de duurste fouten. Toestemming voor personeel om een applicatie te openen betekent niet dat applicatieservers verbindingen terug naar de laptops van het personeel mogen openen, en een stateful regel die de eerste richting toestaat, wordt vaak gelezen als toestemming voor de tweede.
Stap 3: bepaal waar identiteit beleid wordt
Iemand moet een geauthenticeerde sessie omzetten in een rol die de gateway kan afdwingen. Ondersteunde opties zijn groepsbeleid van de authenticatiebackend, vertrouwde sessieattributen of aparte adrespools per rol. Alle drie werken; een label dat de client stuurt niet. Kies het mechanisme dat je gateway documenteert, niet dat wat een forumbericht beschrijft.
Een adres toekennen dat er alleen uitziet alsof het bij een VLAN hoort, is hetzelfde niet-antwoord in een ander kostuum. De Netgate-gids voor OpenVPN-firewallregels maakt de scheiding duidelijk: de tunnel laten opkomen is een andere beslissing dan verkeer erdoor laten gaan.
Noteer welk mechanisme je hebt gekozen en waar het is geconfigureerd. Wanneer een rol verandert, is die notitie het verschil tussen één aanpassing en een zoektocht door drie interfaces. Ze vertelt een auditor ook waar die het eerst moet kijken.
Stap 4: let op het bronadres dat de bestemming ziet
Het doorstuurbeleid moet bij de grens overeenkomen met de werkelijke bron. Als de gateway VPN-clients naar zijn eigen adres vertaalt, ziet elke firewall stroomafwaarts één bron en verliest het vermogen om per rol te beslissen. Als hij het cliëntadres bewaart, moet de retourroute voor die pool bestaan.
Test beide richtingen voordat je de definitieve regels schrijft, en noteer dan de waargenomen bron naast elke cel. Voer dezelfde controle uit vanuit twee verschillende rollen en vergelijk het resultaat. Als beide het gateway-adres tonen, is het onderscheid tussen rollen al verloren. Een matrix die bewaarde adressen veronderstelt terwijl de gateway bronvertaling doet, faalt op de eerste stroomafwaartse ACL.
Stap 5: test elke cel voordat je oplevert
Maak van elke toegestane cel één representatieve handeling en van elke geweigerde cel een negatief geval. Voer beide uit vanaf een client in de werkelijke rol, niet vanaf de gateway-console, omdat de console het pad omzeilt dat je test.
# 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'Een negatief geval dat verbinding maakt, is een bevinding, geen toeval, en het hoort in de matrix als een mislukte cel tot de regel is gecorrigeerd. Houd de testcommando's naast de tabel, zodat de volgende beoordelaar ze opnieuw uitvoert in plaats van de redenering opnieuw op te bouwen.
De voltooide tabel overleeft de gateway waarvoor hij is geschreven. Regels veranderen mee met firmware en leverancier, terwijl de rij die zegt dat een aannemer één projectdienst bereikt, waar blijft tot dat werk verandert.