Ge VPN-användare åtkomst till en tjänst, inte till subnätet

En underleverantör behöver en intern webbapplikation och inget annat, och det enkla svaret är att ge dem en tunnel in i serversubnätet. Det fungerar till den dag de skannar det. Den smalare designen kräver mer eftertanke, eftersom nåbarhet, routning och applikationstillstånd är tre separata kontroller som måste stämma överens.

Skriv kravet som en tjänst, inte som ett subnät

Börja med målvärden, protokollet och porten och lägg sedan till användar- eller enhetsgruppen som ska nå den. Ta bara med den privata DNS-zonen om applikationen slår upp ett namn, och en identitetsleverantör bara om inloggningsflödet behöver en. Allt annat är ett beroende du ännu inte har motiverat.

Ett subnät är en implementeringsdetalj för nätverksteamet, medan en tjänst är det verksamheten bad om och den enhet som kan granskas och avvecklas.

Om beroendelistan växer förbi tre poster behöver applikationen förmodligen ett eget designsamtal.

Routa smalt, men upprätthåll på annat håll

En smal rutt eller väljare talar om för tunneln vilka paket den ska bära; det är inte en auktoriseringspolicy. Gateway-filtret, brandväggen på målvärden och applikationens egen behörighetsmodell är där åtkomst avgörs. En rutt som täcker en adress är en bra början, och det är inte den kontroll som stoppar en beslutsam användare. Just den separationen gör det möjligt att ändra filtret utan att rita om tunneln.

Omvänt kan en bred rutt med ett strikt filter vara legitim, men bara om alla inblandade vet vilken av dem som utför upprätthållandet.

Dokumentera upprätthållandepunkten uttryckligen, annars flyttar nästa ändring den av misstag.

Kontrollera den källa som tjänsten faktiskt ser

Målet ser antingen klientens pooladress eller gatewayens adress, beroende på om du översätter. Brandväggsregler och loggar på värden måste matcha den verkliga källan. Om flera användare delar en översatt källa kan ingen regel per användare på den värden skilja dem åt, och det är en designbegränsning, inte en bugg.

Välj översättning medvetet: det förenklar routning och förstör källidentiteten, vilket spelar roll för revision och för regler per användare.

Skriv ned vilken av de två du valde, bredvid regeln som beror på det.

Applikationsauktorisering är inte valfritt

Att nå en port ger ingen roll. Applikationen behöver fortfarande sin egen inloggning och sina egna behörigheter, eftersom nätverkslagret inte kan uttrycka vilka poster en användare får redigera. En tjänst som litar på varje begäran från det interna subnätet förvandlar en smal tunnel till full åtkomst för en komprometterad inloggningsuppgift. Tunneln avgör vem som får öppna socketen, och applikationen avgör vad de får göra med den.

Det är här den smala designen lönar sig dubbelt, eftersom färre nåbara värdar innebär färre ställen där ett fel på applikationsnivå kan utnyttjas.

Håll nätverksregeln och applikationsrollen i separata system och avveckla dem separat.

Bevisa både den tillåtna och den nekade vägen

Anslut som den auktoriserade användaren och utför en ofarlig representativ operation, försök sedan med en destination som ska vara onåbar. En design som bara testar första halvan är inte testad, och det är det nekade testet som bevisar designen. Testa en ny session efter varje regeländring, och titta på returvägen om begäranden kommer men inte svar.

Inaktivera inte vidarebefordringsfilter för att få acceptanstestet att gå igenom, eftersom det ändrar det som testas.

När användaren inte längre behöver tjänsten, avveckla den externa identiteten och applikationsrollen i deras respektive system, och registrera båda. strongSwan-vägledningen för vidarebefordran täcker gateway-sidan av vägen.