VPN for et lite kontor: hold den borte fra domenekontrolleren

Tre forhold avgjør om kontorets eneste Windows-server også skal avslutte VPN-en: hvor mye internettvendt programvare du vil kjøre på katalogen, om du kan autentisere fjernbrukere uten den rollen, og hva som skjer med administrasjonstilgangen din når verten starter på nytt. Hvis ett av de tre har et dårlig svar, skill rollene. At kontoret er lite endrer budsjettet, ikke risikoen.

Hver maskin i domenet stoler på en domenekontroller; en VPN-gateway kan nås av hvem som helst på internett. Den asymmetrien er hele argumentet.

To jobber med to ulike eksponeringsprofiler

Gatewayen godtar tilkoblinger utenfra, så lytteren, TLS-stakken og autentiseringsoverflaten er alle tilgjengelige fra ikke-klarerte nettverk. Katalogen har en autoritet som andre maskiner stoler på, derfor behandler Microsofts herdingsveiledning domenekontrollerrollen og hostingmiljøet som særlig sensitivt. Hver tjeneste som legges til den verten, arver katalogens tillitsposisjon og legger til sin egen angrepsflate. Installasjonskomfort er ikke en tillitsgrense.

Å skille rollene fjerner ikke avhengighetene. Fjernbrukere trenger fortsatt autentisering, ruter, DNS og tilgangsregler, og en gateway som hopper over dem er ikke sikrere, bare mindre nyttig.

Autentisering uten katalogrollen

En gateway kan validere legitimasjon gjennom en støttet ekstern integrasjon uten å hoste katalogen selv. Uansett hva den integrasjonen er, gi den en konto der rettighetene passer til formålet: lese attributtene som trengs for autentisering, ikke mer. Å ta inn VPN-brukere krever aldri at de vanlige kontoene deres blir domeneadministratorer, og det krever aldri at gatewayen har en kopi av katalogen.

Begrens deretter nettverksbanene fjernklienten faktisk trenger. Tilgang til én intern filttjeneste, pluss navneoppløsnings- og identitetstjenestene den arbeidsflyten er avhengig av, er et definert sett med baner. Det er ikke grunn til å tillate hver domenekontrollerport eller hvert administrativt grensesnitt fra VPN-poolen.

Én vert er fortsatt ett feildomene

To gjester på én hypervisor skiller operativsystemkonfigurasjonen sin og skiller ikke skjebnen sin. Hypervisorens administratorer, virtuell svitsjing, lagring og sikkerhetskopier er fortsatt en del av designet, og en omstart av verten fjerner begge tjenestene samtidig. Å kalle det høy tilgjengelighet fordi diagrammet viser to VM-er er en vanlig og dyr feil. Hvis den eneste veien tilbake går gjennom VPN-en på den verten, tar en feil bort forbindelsen som trengs for å reparere den.

Planlegg derfor en uavhengig administrasjonsbane som ikke avhenger av tunnelen, og skriv ned hva som forblir tilgjengelig under vedlikehold. Planlegg gatewayoppdateringer og katalogvedlikehold hver for seg, og noter hvilke brukere eller applikasjoner hver avbrudd berører.

Et vedlikeholdsvindu som krever at VPN-en er oppe for å reparere VPN-en, er ikke et vedlikeholdsvindu.

Flytt det uten å låse deg ute

Hvis rollene allerede deler én installasjon, unngå en forhastet fjernmigrering. Inventer hva gatewayen eier i dag: adresser, videresendingsregler, NAT, DNS-innstillinger, autentiseringskonfigurasjon og eventuelle publiserte tjenester. Forbered både erstatningen og en vei tilbake før du flytter lytteren eller endrer en standardrute. Test deretter en vanlig fjernbrukers faktiske arbeid gjennom den nye grensen, og bekreft at unødvendig administrativ tilgang fortsatt feiler.

Målet er ikke et penere diagram. Det er evnen til å reparere eller gjenoppbygge VPN-en uten å røre boksen som forankrer katalogtilliten for hele kontoret. Det er forskjellige mål, og bare ett av dem trenger en ekstra server.

Noter beslutningen uansett, inkludert betingelsene som ville gjenåpne den. Et lite kontor vokser, og svaret som passet én server passer kanskje ikke den neste.