Gi VPN-brukere tilgang til én tjeneste, ikke til subnettet

En underleverandør trenger én intern webapplikasjon og ingenting annet, og det enkle svaret er å gi dem en tunnel inn i serversubnettet. Det fungerer til den dagen de skanner det. Det smalere designet krever mer ettertanke, fordi tilgjengelighet, ruting og applikasjonstillatelse er tre separate kontroller som må stemme overens.

Skriv kravet som en tjeneste, ikke som et subnett

Start med destinasjonsverten, protokollen og porten, og legg deretter til bruker- eller enhetsgruppen som skal nå den. Ta med den private DNS-sonen bare hvis applikasjonen slår opp et navn, og ta med en identitetsleverandør bare hvis påloggingsflyten trenger en. Alt annet er en avhengighet du ennå ikke har begrunnet.

Et subnett er en implementasjonsdetalj for nettverksteamet, mens en tjeneste er det forretningen ba om, og enheten som kan gjennomgås og avvikles.

Hvis avhengighetslisten vokser forbi tre elementer, trenger applikasjonen sannsynligvis sin egen designsamtale.

Rut smalt, men håndhev andre steder

En smal rute eller velger forteller tunnelen hvilke pakker den skal bære; det er ikke en autorisasjonspolicy. Gateway-filteret, brannmuren på destinasjonsverten og applikasjonens egen tillatelsesmodell er der tilgangen avgjøres. En rute som dekker én adresse er en god start, og det er ikke kontrollen som stopper en bestemt bruker. Nettopp denne separasjonen gjør det mulig å endre filteret uten å redesigne tunnelen.

Omvendt kan en bred rute med et strengt filter være legitim, men bare hvis alle involverte vet hvilken av dem som utfører håndhevelsen.

Dokumenter håndhevelsespunktet eksplisitt, ellers flytter den neste endringen det ved et uhell.

Kontroller kilden tjenesten faktisk ser

Målet ser enten klientens pooladresse eller gatewayens adresse, avhengig av om du oversetter. Brannmurregler og logger på verten må samsvare med den virkelige kilden. Hvis flere brukere deler en oversatt kilde, kan ingen regel per bruker på den verten skille dem, og det er en designbegrensning, ikke en feil.

Velg oversettelse bevisst: det forenkler ruting og ødelegger kildeidentiteten, noe som betyr noe for revisjon og for regler per bruker.

Skriv ned hvilken av de to du valgte, ved siden av regelen som avhenger av det.

Applikasjonsautorisasjon er ikke valgfritt

Å nå en port gir ikke en rolle. Applikasjonen trenger fortsatt sin egen pålogging og sine egne tillatelser, fordi nettverkslaget ikke kan uttrykke hvilke poster en bruker kan redigere. En tjeneste som stoler på enhver forespørsel fra det interne subnettet, gjør en smal tunnel om til full tilgang for én kompromittert legitimasjon. Tunnelen avgjør hvem som kan åpne sokkelen, og applikasjonen avgjør hva de kan gjøre med den.

Det er her det smale designet lønner seg dobbelt, fordi færre tilgjengelige verter betyr færre steder hvor en feil på applikasjonsnivå kan utnyttes.

Hold nettverksregelen og applikasjonsrollen i separate systemer, og avvikle dem separat.

Bevis både den tillatte og den avviste veien

Koble til som den autoriserte brukeren og utfør én ufarlig representativ operasjon, og prøv deretter en destinasjon som skal være utilgjengelig. Et design som bare tester den første halvdelen, er ikke testet, og det er den avviste testen som beviser designet. Test en fersk økt etter hver regelendring, og se på returveien hvis forespørsler kommer, men ikke svar.

Ikke deaktiver videresendingsfiltre for å få akseptansetesten til å bestå, fordi det endrer det som testes.

Når brukeren ikke lenger trenger tjenesten, avvikle den eksterne identiteten og applikasjonsrollen i deres respektive systemer, og registrer begge. strongSwan-veiledningen for videresending dekker gateway-siden av veien.