Arbejdslaptop på en personlig VPN: hvad der faktisk passerer

Når en firmalaptop kobles til en hjemme-VPN, står den to steder på én gang, og det interessante spørgsmål er mindre og mere nyttigt end det alarmerende. Ingen har lagt et Ethernet-kabel mellem kontoret og hjemmet, og ingen rute gør hjemmenetværket til en forlængelse af det korporative subnet. Det, der findes, er ét endepunkt med adgang til begge miljøer, og tre separate mekanismer afgør, hvad der faktisk kan bevæge sig mellem dem. At gå de tre igennem fra endepunktet og udad giver et svar, en administrator kan handle på, i stedet for en debat om etiketter.

Begynd ved endepunktet, ikke ved netværksdiagrammet

Endepunktet er der, hvor begge forbindelser mødes, så det er der, gennemgangen begynder: hvilke processer kører, hvad kan de nå, og hvem styrer dem. Et diagram, der viser to skyer forbundet til en laptop, er præcist og ubrugeligt, fordi det antyder et led, der måske ikke findes. Erstat det med en liste over de programmer, der kan tale med hvert miljø, og noter, hvilken konto hver af dem kører under. Den ramme holder også gennemgangen proportional, da en laptop med to tunneler ikke er det samme objekt som to netværk, der er forbundet.

Den liste er det inventar, resten af gennemgangen arbejder ud fra. Hvis den indeholder en synkroniseringsklient, en browserprofil logget ind i begge miljøer og en build-agent med legitimationsoplysninger, har gennemgangen allerede sine emner.

Tre overgangspunkter, gennemgået hver for sig

Programadgang er det første overgangspunkt, og det kræver ingen videresendelse. En browservane, en synkroniseringsklient eller en build-agent på endepunktet kan læse fra en ressource i det ene miljø og indsende data til en ressource i det andet. Den evne findes, uanset om styresystemet videresender pakker mellem grænseflader, og det er den mekanisme, folk overser, når de konkluderer, at ingen bro betyder ingen risiko. At læse listen over programmer er derfor mere oplysende end at læse listen over grænseflader.

Identitet og data udgør det andet overgangspunkt. Korporative legitimationsoplysninger, sessionscookies, downloadede dokumenter og administrationsrettigheder ligger på endepunktet, og det at tilslutte et andet netværk afslører dem ikke i sig selv. Det, der ændrer sig, er det sæt af parter, der kan påvirke endepunktet, mens det holder disse oplysninger, og det er et spørgsmål om det personlige netværks troværdighed snarere end om routing. Det er en vurdering, endepunktets ejer ikke kan foretage alene, og den besvares ikke af fraværet af en videresendelsesregel.

Netværksvideresendelse er den tredje og den eneste, der kan gøre laptoppen til en transit-enhed. IP-videresendelse, deling af internetforbindelse, en proxy eller en brofunktion kan hver især gøre det, og hver af dem er en konfiguration, der enten er aktiveret eller ikke. Undersøg den tilstand direkte i stedet for at udlede den af tilstedeværelsen af en VPN-klient. På en administreret maskine er svaret normalt nej, og at verificere det gør en antagelse til en kendsgerning, der er værd at notere.

Bed om én ressource, ikke to netværk

De fleste reelle krav er snævrere, end de først ser ud: én konsol, én filshare, én intern webapplikation. Formulér kravet sådan, og lad ressourcens ejer afgøre, om det overhovedet hører til på dette endepunkt. En anmodning formuleret som to netværk, der forbindes, er svær at godkende og let at afvise; en anmodning om én navngivet tjeneste har et svar.

Hvis svaret er ja, foretræk den snævreste understøttede vej, og hold den inden for organisationens eksisterende kontroller. En administreret anden profil eller en afgrænset programpost bevarer overvågning og politik; en konkurrerende personlig konfiguration erstatter dem stille, og ingen ved, hvilken der vinder efter den næste opdatering.

Medtag DNS- og ruteeffekter

Navneopløsning ændrer sig i det øjeblik, en anden profil er aktiv. En personlig klient kan skubbe sin egen resolver ind, en browser kan bruge sin egen krypterede DNS, og en policytabel kan rute interne navne til en anden server, end den korporative konfiguration forventer. Intet af det kræver videresendelse, og ethvert af det kan sende et internt værtsnavn det forkerte sted hen.

Resolve-DnsName intranet.corp.example -Type A
Get-DnsClientNrptPolicy -Effective
route print 0.0.0.0

Fang de tre output før og efter, at den anden profil opretter forbindelse. Forskellen mellem dem er den effekt, der faktisk når brugeren, og den er ofte større end den routingændring, sagen beskriver. Gem begge optagelser, så en senere gennemgang kan se, hvad der ændrede sig, i stedet for hvad der var hensigten.

Verificér og behold en vej ud

Test det godkendte program fra den virkelige proces og brugerkontekst, ikke fra en administratorskal på samme maskine. Bekræft derefter, at urelaterede destinationer forbliver uopnåelige, hvor designet kræver det: en grænse, ingen har testet, er en grænse, ingen kan påberåbe sig. Afbrydelse af den personlige tunnel bør genskabe den tidligere tilstand, og den genskabelse er værd at kontrollere, mens nogen stadig ser på.

Test-NetConnection -ComputerName files.corp.example -Port 443
Get-NetConnectionProfile

NISTs vejledning om zero-trust-arkitektur er nyttig her, fordi den fjerner netværksplacering som automatisk tillidskilde, hvilket netop er den antagelse, der er på spil. Spørgsmålet er ikke, om hjemmenetværket er troværdigt af natur; det er, hvem der kan nå hvilken ressource, fra hvilket endepunkt, gennem hvilket håndhævelsespunkt. Besvar de tre, og opbevar evidensen sammen med beslutningen.