VPN til et lille kontor: hold den væk fra domænecontrolleren

Tre forhold afgør, om kontorets eneste Windows-server også skal afslutte VPN'en: hvor meget internetvendt software du vil køre på biblioteket, om du kan godkende fjernbrugere uden den rolle, og hvad der sker med din administrationsadgang, når værten genstarter. Hvis bare ét af de tre har et dårligt svar, skal du adskille rollerne. At kontoret er lille ændrer budgettet, ikke risikoen.

En domænecontroller er betroet af hver maskine i domænet; en VPN-gateway kan nås af enhver på internettet. Den asymmetri er hele argumentet.

To job med to forskellige eksponeringsprofiler

Gatewayen accepterer forbindelser udefra, så dens lytter, dens TLS-stak og dens godkendelsesflade kan alle nås fra utroede netværk. Biblioteket har en autoritet, som andre maskiner stoler på, og derfor behandler Microsofts hardening-vejledning domænecontrollerrollen og dens hostingmiljø som særligt følsomt. Hver tjeneste, der føjes til den vært, arver bibliotekets tillidsplacering og tilføjer sin egen angrebsflade. Nem installation er ikke en tillidsgrænse.

At adskille rollerne fjerner ikke afhængighederne. Fjernbrugere har stadig brug for godkendelse, ruter, DNS og adgangsregler, og en gateway, der springer dem over, er ikke mere sikker, bare mindre nyttig.

Godkendelse uden biblioteksrollen

En gateway kan validere legitimationsoplysninger gennem en understøttet ekstern integration uden at hoste biblioteket selv. Hvad den integration end er, skal du give den en konto, hvis rettigheder passer til formålet: læse de attributter, der er nødvendige for godkendelse, ikke mere. At optage VPN-brugere kræver aldrig, at deres almindelige konti bliver domæneadministratorer, og det kræver aldrig, at gatewayen har en kopi af biblioteket.

Afgræns derefter de netværksstier, som fjernklienten faktisk har brug for. Adgang til én intern filservice plus de navneopløsnings- og identitetstjenester, som den arbejdsgang afhænger af, er et defineret sæt stier. Det er ikke grund til at tillade hver domænecontrollerport eller hver administrativ grænseflade fra VPN-puljen.

Én vært er stadig ét fejldomæne

To gæster på én hypervisor adskiller deres operativsystemkonfiguration og adskiller ikke deres skæbne. Hypervisorens administratorer, virtuel switching, lager og backups forbliver en del af designet, og en genstart af værten fjerner begge tjenester på én gang. At kalde det høj tilgængelighed, fordi diagrammet viser to VM'er, er en almindelig og dyr fejl. Hvis den eneste vej tilbage går gennem VPN'en på den vært, tager en fejl den forbindelse væk, der er nødvendig for at reparere den.

Planlæg derfor en uafhængig administrationsvej, der ikke afhænger af tunnelen, og skriv ned, hvad der forbliver tilgængeligt under vedligeholdelse. Planlæg gatewayopdateringer og biblioteksvedligeholdelse særskilt, og noter, hvilke brugere eller applikationer hver afbrydelse berører.

Et vedligeholdelsesvindue, der kræver, at VPN'en er oppe for at reparere VPN'en, er ikke et vedligeholdelsesvindue.

Flyt det uden at låse dig selv ude

Hvis rollerne allerede deler én installation, undgå en forhastet fjernmigrering. Lav en fortegnelse over, hvad gatewayen ejer i dag: adresser, videresendelsesregler, NAT, DNS-indstillinger, godkendelseskonfiguration og eventuelle publicerede tjenester. Forbered både erstatningen og en vej tilbage, før du flytter lytteren eller ændrer en standardrute. Test derefter en almindelig fjernbrugers faktiske arbejde gennem den nye grænse, og bekræft, at unødvendig administrativ adgang stadig fejler.

Målet er ikke et pænere diagram. Det er evnen til at reparere eller genopbygge VPN'en uden at røre den boks, der forankrer bibliotekets tillid for hele kontoret. Det er forskellige mål, og kun ét af dem kræver en ekstra server.

Noter beslutningen uanset hvad, inklusive de betingelser, der ville genåbne den. Et lille kontor vokser, og det svar, der passede til én server, passer måske ikke til den næste.