VPN för ett litet kontor: håll den borta från domänkontrollanten

Tre villkor avgör om kontorets enda Windows-server också ska avsluta VPN:en: hur mycket internetvänd programvara du är villig att köra på katalogen, om du kan autentisera fjärranvändare utan den rollen, och vad som händer med din administrationsåtkomst när värden startar om. Om något av de tre har ett dåligt svar, separera rollerna. Att kontoret är litet ändrar budgeten, inte risken.

Varje maskin i domänen litar på en domänkontrollant; en VPN-gateway kan nås av vem som helst på internet. Den asymmetrin är hela argumentet.

Två jobb med två olika exponeringsprofiler

Gatewayen tar emot anslutningar utifrån, så dess lyssnare, TLS-stack och autentiseringyta är alla nåbara från icke betrodda nätverk. Katalogen har en auktoritet som andra maskiner litar på, därför behandlar Microsofts härdningsvägledning domänkontrollantrollen och dess hostingmiljö som särskilt känsliga. Varje tjänst som läggs till den värden ärver katalogens förtroendeposition och lägger till sin egen attackyta. Installationsbekvämlighet är inte en förtroendegräns.

Att separera rollerna tar inte bort beroendena. Fjärranvändare behöver fortfarande autentisering, rutter, DNS och åtkomstregler, och en gateway som hoppar över dem är inte säkrare, bara mindre användbar.

Autentisering utan katalogrollen

En gateway kan validera autentiseringsuppgifter genom en stödd extern integration utan att hosta själva katalogen. Vad den integrationen än är, ge den ett konto vars rättigheter passar syftet: läsa attributen som behövs för autentisering, inget mer. Att släppa in VPN-användare kräver aldrig att deras vanliga konton blir domänadministratörer, och det kräver aldrig att gatewayen har en kopia av katalogen.

Begränsa sedan de nätverksvägar som fjärrklienten faktiskt behöver. Åtkomst till en intern filttjänst, plus de namnupplösnings- och identitetstjänster som arbetsflödet är beroende av, är en definierad uppsättning vägar. Det är inte skäl att tillåta varje domänkontrollantport eller varje administrativt gränssnitt från VPN-poolen.

En värd är fortfarande en felddomän

Två gäster på en hypervisor separerar sin operativsystemskonfiguration och separerar inte sitt öde. Hypervisorns administratörer, virtuell växling, lagring och säkerhetskopior är fortfarande en del av designen, och en omstart av värden tar bort båda tjänsterna samtidigt. Att kalla det hög tillgänglighet eftersom diagrammet visar två VM:ar är ett vanligt och dyrt misstag. Om den enda vägen tillbaka går genom VPN:en på den värden tar ett fel bort anslutningen som behövs för att reparera den.

Planera därför en oberoende administrationsväg som inte beror på tunneln, och skriv ned vad som förblir tillgängligt under underhåll. Schemalägg gatewayuppdateringar och katalogunderhåll separat, och notera vilka användare eller applikationer varje avbrott berör.

Ett underhållsfönster som kräver att VPN:en är uppe för att reparera VPN:en är inte ett underhållsfönster.

Flytta det utan att låsa in dig själv

Om rollerna redan delar en installation, undvik en förhastad fjärrmigrering. Inventera vad gatewayen äger i dag: adresser, vidarebefordringsregler, NAT, DNS-inställningar, autentiseringskonfiguration och eventuella publicerade tjänster. Förbered både ersättningen och en väg tillbaka innan du flyttar lyssnaren eller ändrar en standardrutt. Testa sedan en vanlig fjärranvändares faktiska arbete genom den nya gränsen, och bekräfta att onödig administrativ åtkomst fortfarande misslyckas.

Målet är inte ett vackrare diagram. Det är förmågan att reparera eller bygga om VPN:en utan att röra lådan som förankrar katalogförtroendet för hela kontoret. Det är olika mål, och bara ett av dem behöver en extra server.

Anteckna beslutet oavsett, inklusive villkoren som skulle öppna det igen. Ett litet kontor växer, och svaret som passade en server passar kanske inte nästa.