AWS Client VPN-regler hör till resursen, inte till subnätet

Personalen måste nå en applikation i VPC:n och får inte nå databaslyssnaren på samma instans, så någon lägger till ett andra offentligt subnät för VPN-slutpunkten och förklarar kravet uppfyllt. Subnätets placering ändrar routning och tillgänglighet. Det ger eller fråntar inte en enda port. Tillståndet som uttrycker kravet bor vid målet, i resursens säkerhetsgrupp, och VPN-gränsen levererar handtaget som regeln hänvisar till.

Subnätets placering är routning, inte auktorisering

Var slutpunktens nätverkskoppling ligger avgör vilken ruttabell som bär klienttrafiken och vilka tillgänglighetszoner som överlever ett fel. Det säger ingenting om vilken port på vilken instans trafiken kan nå. Två klienter kopplade till samma subnät anländer fortfarande med samma källidentitet, och resursen kan inte skilja dem åt på subnätets namn.

Börja i stället från kravet: vem anropar, vilken resurs, vilken tjänsteport och vilken riktning. Välj sedan den regelmodell som kan uttrycka de fyra sakerna vid målet. Det greppet tar oftast bort det extra subnätet helt från designen.

Client VPN-kopplingsgruppen är handtaget

För en subnätskopplad AWS Client VPN-slutpunkt är den dokumenterade ordningen konkret. Tillämpa den avsedda säkerhetsgruppen på slutpunktens mål-nätverkskopplingar och tillåt sedan den nödvändiga trafiken i resursens säkerhetsgrupp med den Client VPN-gruppen som källa.

Konkret tillåter applikationsinstansens grupp applikationsporten från kopplingsgruppen, och inget annat. AWS procedur för resursåtkomst beskriver detta förhållande, och det är värt att hålla samma gruppolicy på varje subnät som slutpunkten kopplas till, eftersom en föråldrad koppling med en annan grupp tyst vidgar gränsen.

Den regeln autentiserar ingen. Inloggning är en separat kontroll, och vägen till resursen är en tredje. Alla tre måste gälla innan en begäran anländer. Vilken som fallerar avgör vilken rättelse som är rätt, och en regeländring är bara rätt svar för den första.

Vad en kopplingsgrupp inte kan skilja på

Varje klient bakom samma kopplingsgrupp når resursen som samma säkerhetsgruppskälla. Två användare med olika roller går inte att skilja åt på det lagret, oavsett hur gruppen namnges eller taggas. Client VPN:s auktorisering av externa grupper begränsar åtkomst per målprefix för en katalog- eller SAML-grupp, vilket är grövre än en resursroll och bör behandlas som en nätverksgräns, inte ett identitetssystem.

Finare skillnader hör till applikationen. En databaslyssnare som måste hållas stängd för de flesta anställda skyddas bättre av att inte vara nåbar alls på det tillåtna prefixet än av att hoppas att gruppmedlemskapet hålls städat.

Att byta namn på gruppen skapar ingen identitet, och att duplicera den per team multiplicerar bara kopplingarna som måste granskas.

Kopiera inte den regeln till varje VPN-design

En självförvaltad EC2 VPN-gateway, en routad inspektionsapparat och hanterad Client VPN är tre olika paketvägar. Fastställ vilken källadress som faktiskt når resursen, om översättning sker på vägen och vilka referensmekanismer tjänsten stöder på den vägen.

Att skicka trafik genom en mellanliggande enhet bevarar inte en käll-säkerhetsgruppreferens som direkt instans-till-instans-trafik gör. AWS dokumenterar att sådana designer kan behöva lämpliga privata källadresser eller CIDR:er i stället för en gruppreferens. Proceduren för hanterad Client VPN är inte bevis för att varje gateways anslutna grupp fungerar som en universell identitetstoken för vidarebefordrade paket.

Ett NAT-hopp på vägen räcker för att bryta antagandet, och felet ser ut som en regel som finns men aldrig matchar.

Granska den effektiva gränsen

Läs varje säkerhetsgrupp som är kopplad till resursen, eftersom tillåtelseregler kombineras och en snäv regel inte upphäver en bredare på en annan grupp. Kontrollera sedan nätverks-ACL:n, värdens brandvägg och applikationens egen auktorisering, som är separata lager med separata fel.

Avsluta med en tillåten och en medvetet utesluten begäran mot samma resurs. Paret bevisar gränsen, medan en enda lyckad anslutning bara bevisar att något är öppet. Bekräfta vägen, den effektiva källan och den avsedda tjänsteporten i stället för subnätet som innehåller slutpunkten.

Arbetsordning: skriv det fyrdelade kravet, koppla gruppen till kopplingarna, begränsa resursregeln till porten, verifiera en tillåtelse och en avvisning, och överväg först därefter att dela subnät av routningsskäl.