Gje VPN-brukarar tilgang til éin teneste, ikkje til subnettet

Ein underleverandør treng éin intern webapplikasjon og ingenting anna, og det enkle svaret er å gje dei ein tunnel inn i serversubnettet. Det fungerer til den dagen dei skannar det. Det smalare designet krev meir ettertanke, fordi tilgjenge, ruting og applikasjonstilgang er tre separate kontrollar som må stemme overeins.

Skriv kravet som ei teneste, ikkje som eit subnett

Start med målverten, protokollen og porten, og legg deretter til brukar- eller eininggruppe som skal nå han. Ta med den private DNS-sona berre viss applikasjonen slår opp eit namn, og ta med ein identitetsleverandør berre viss innloggingsflyten treng ein. Alt anna er ein avhengigheit du enno ikkje har grunngjeve.

Eit subnett er ein implementasjonsdetalj for nettverksteamet, medan ei teneste er det verksemda bad om, og eininga som kan gjennomgåast og leggjast ned.

Viss avhengigheitslista veks forbi tre element, treng applikasjonen truleg sin eigen designsamtale.

Rut smalt, men handhev andre stader

Ei smal rute eller veljar fortel tunnelen kva pakkar han skal bera; det er ikkje ein autorisasjonspolitikk. Gateway-filteret, brannmuren på målverten og applikasjonen sin eigen tilgangsmodell er der tilgangen blir avgjord. Ei rute som dekkjer éin adresse er ein god start, og det er ikkje kontrollen som stoppar ein bestemt brukar. Nettopp denne skilnaden gjer det mogleg å endre filteret utan å redesigne tunnelen.

Omvendt kan ei brei rute med eit strengt filter vere legitim, men berre viss alle involverte veit kven av dei som utfører handhevinga.

Dokumenter handhevingspunktet eksplisitt, elles flyttar den neste endringa det ved eit uhell.

Kontroller kjelda tenesta faktisk ser

Målet ser anten klienten si puljeadresse eller adressa til gatewayen, avhengig av om du omset. Brannmurreglar og loggar på verten må samsvare med den verkelege kjelda. Viss fleire brukarar deler ei omsett kjelde, kan ingen regel per brukar på den verten skilje dei, og det er ei designavgrensing, ikkje ein feil.

Vel omsetjing medvite: det gjer rutinga enklare og øydelegg kjeldeidentiteten, noko som betyr noko for revisjon og for reglar per brukar.

Skriv ned kva av dei to du valde, ved sida av regelen som avheng av det.

Applikasjonsautorisasjon er ikkje valfritt

Å nå ein port gjev ikkje ei rolle. Applikasjonen treng framleis si eiga innlogging og sine eigne løyve, fordi nettverkslaget ikkje kan uttrykke kva postar ein brukar kan redigere. Ei teneste som stolar på kvar førespurnad frå det interne subnettet, gjer ein smal tunnel om til full tilgang for éin kompromittert legitimasjon. Tunnelen avgjer kven som kan opne sokkelen, og applikasjonen avgjer kva dei kan gjere med han.

Det er her det smale designet løner seg dobbelt, fordi færre tilgjengelege vertar betyr færre stader der ein feil på applikasjonsnivå kan utnyttast.

Hald nettverksregelen og applikasjonsrolla i separate system, og legg dei ned kvar for seg.

Prov både den tillatne og den avviste vegen

Kopla til som den autoriserte brukaren og utfør éin ufarleg representativ operasjon, og prøv deretter ein destinasjon som skal vere utilgjengeleg. Eit design som berre testar den første halvdelen, er ikkje testa, og det er den avviste testen som provar designet. Test ei fersk økt etter kvar regelendring, og sjå på returvegen viss førespurnader kjem, men ikkje svar.

Ikkje deaktiver videresendingsfilter for å få akseptansetesten til å gå gjennom, fordi det endrar det som blir testa.

Når brukaren ikkje lenger treng tenesta, legg ned den eksterne identiteten og applikasjonsrolla i dei respektive systema deira, og registrer båe. strongSwan-veiledninga for videresending dekkjer gateway-sida av vegen.