VPN-til-VLAN-tilgang: bygg matrisen før reglene
Roller på den ene siden, tjenester på den andre. Fem kontroller gjør et vagt VPN-til-VLAN-design om til en tabell som en brannmur-eier kan implementere.
Begynn med matrisen, ikke med brannmur-syntaksen. En tabell med roller på den ene siden og tjenester på den andre kan gjennomgås av en applikasjonseier, diskuteres av en sikkerhetseier og implementeres av den som har gatewayen. Den gjennomgangen er billigere enn å feilsøke regler ingen har blitt enige om.
En time med skriving sparer senere en uke med reglarkologi. Designet handler om hvem som når hvilken tjeneste, og det er den delen som overlever omnummerering.
Trinn 1: navngi rollene før nettene
Begynn med menneskene, ikke med svitsjen. Skriv ned hver gruppe som kobler til eksternt, og den ene setningen som beskriver hva gruppen gjør, for eksempel lagerpersonale som leser lagernivåer, eller en entreprenør som vedlikeholder én integrasjon. Hvis to grupper ville fått samme tilgang, er de én rolle for dette formålet.
Stopp her hvis en rolle bare finnes på grunn av et organisasjonskart. En rolle uten eget tjenestebehov blir en rad med identiske celler, og identiske rader frister noen til senere å gi et helt subnett for enkelhets skyld. Del etter hva folk gjør, ikke etter hvem som signerer utgiftene deres. Seks roller er vanligvis for mange for et lite kontor, og tre er ofte riktig.
Trinn 2: gjør hver celle til en tjenesteerklæring
En celle som sier «Applikasjoner», kan ikke testes. En celle som sier «HTTPS til ERP-verten på 443, fra personalpoolen», kan. Erstatt hvert nettverksnavn med en destinasjon, en protokoll og en port, og legg deretter til avhengigheten tjenesten ikke kan fungere uten, som den interne resolveren eller identitetsleverandøren.
| 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 |
Retningskolonnen fanger de dyreste feilene. Tillatelse for personalet til å åpne en applikasjon betyr ikke tillatelse for applikasjonsservere til å åpne forbindelser tilbake til personalets bærbare maskiner, og en tilstandsbasert regel som tillater den første retningen, leses ofte som tillatelse til den andre.
Trinn 3: bestem hvor identitet blir policy
Noen må gjøre en autentisert økt om til en rolle gatewayen kan håndheve. Støttede alternativer er gruppepolicy levert av autentiseringsbackend, betrodde øktattributter eller separate adressepooler per rolle. Alle tre virker; en etikett klienten sender, virker ikke. Velg mekanismen gatewayen din dokumenterer, ikke den et foruminnlegg beskriver.
Å tildele en adresse som bare ser ut som den hører til et VLAN, er det samme ikke-svaret i en annen drakt. Netgates veiledning til OpenVPN-brannmurregler gjør skillet tydelig: å la tunnelen komme opp er en annen beslutning enn å la trafikk gå gjennom den.
Skriv ned hvilken mekanisme du valgte, og hvor den er konfigurert. Når en rolle endres, er det notatet forskjellen mellom én endring og en jakt gjennom tre grensesnitt. Det forteller også en revisor hvor de skal se først.
Trinn 4: følg med på kildeadressen destinasjonen ser
Videresendingspolicyen må samsvare med den virkelige kilden ved grensen. Hvis gatewayen oversetter VPN-klienter til sin egen adresse, ser hver nedstrøms brannmur én kilde og mister evnen til å avgjøre per rolle. Hvis den bevarer klientadressen, må returveien finnes for den poolen.
Test begge retninger før du skriver de endelige reglene, og noter deretter den observerte kilden ved hver celle. Kjør samme kontroll fra to ulike roller og sammenlign resultatet. Hvis begge viser gatewayens adresse, er rolledelingen allerede tapt. En matrise som forutsetter bevarede adresser mens gatewayen oversetter kilden, feiler ved den første nedstrøms ACL-en.
Trinn 5: test hver celle før du sender den ut
Gjør hver tillatt celle til én representativ operasjon og hver avvist celle til et negativt tilfelle. Kjør begge fra en klient i den faktiske rollen, ikke fra gateway-konsollen, fordi konsollen omgår veien du tester.
# 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'Et negativt tilfelle som kobler til, er et funn, ikke et tilfelle, og det hører i matrisen som en feilet celle til regelen er rettet. Ha testkommandoene ved siden av tabellen, slik at neste anmelder kjører dem på nytt i stedet for å bygge resonnementet opp igjen.
Den ferdige tabellen lever lenger enn gatewayen den ble skrevet for. Regler endres med fastvare og leverandør, mens raden som sier at en entreprenør når én prosjekttjeneste, forblir sann til den jobben endres.