Giv VPN-brugere adgang til én tjeneste, ikke til undernettet

En underleverandør har brug for én intern webapplikation og intet andet, og det nemme svar er at give dem en tunnel ind i serverundernettet. Det virker indtil den dag, de scanner det. Det smallere design kræver mere eftertanke, fordi tilgængelighed, routing og applikationstilladelse er tre separate kontroller, der skal stemme overens.

Skriv kravet som en tjeneste, ikke som et undernet

Start med destinationsværten, protokollen og porten, og tilføj derefter den bruger- eller enhedsgruppe, der skal nå den. Medtag kun den private DNS-zone, hvis applikationen opløser et navn, og medtag kun en identitetsudbyder, hvis loginflowet har brug for en. Alt andet er en afhængighed, du endnu ikke har begrundet.

Et undernet er en implementeringsdetalje for netværksteamet, mens en tjeneste er det, forretningen bad om, og den enhed, der kan gennemgås og nedlægges.

Hvis afhængighedslisten vokser ud over tre elementer, har applikationen sandsynligvis brug for sin egen designdrøftelse.

Rut smalt, men håndhæv andre steder

En smal rute eller selector fortæller tunnelen, hvilke pakker den skal bære; det er ikke en autorisationspolitik. Gateway-filteret, destinationsværtens firewall og applikationens egen tilladelsesmodel er der, hvor adgangen afgøres. En rute, der dækker én adresse, er en god begyndelse, og det er ikke den kontrol, der stopper en beslutsom bruger. Netop den adskillelse gør det muligt at ændre filteret uden at redesigne tunnelen.

Omvendt kan en bred rute med et strengt filter være legitim, men kun hvis alle involverede ved, hvilken af dem der håndhæver.

Dokumentér håndhævelsespunktet eksplicit, ellers flytter den næste ændring det ved et uheld.

Kontrollér den kilde, tjenesten faktisk ser

Målet ser enten klientens pooladresse eller gatewayens adresse, afhængigt af om du oversætter. Værtens firewallregler og logfiler skal matche den rigtige kilde. Hvis flere brugere deler en oversat kilde, kan ingen regel per bruger på den vært skelne dem, og det er en designbegrænsning, ikke en fejl.

Vælg oversættelse bevidst: det forenkler routing og ødelægger kildeidentiteten, hvilket betyder noget for revision og for regler per bruger.

Skriv ned, hvilken af de to du valgte, ved siden af den regel, der afhænger af det.

Applikationsautorisation er ikke valgfri

At nå en port giver ikke en rolle. Applikationen har stadig brug for sit eget login og sine egne tilladelser, fordi netværkslaget ikke kan udtrykke, hvilke poster en bruger må redigere. En tjeneste, der stoler på enhver anmodning fra det interne undernet, forvandler en smal tunnel til fuld adgang for én kompromitteret legitimationsoplysning. Tunnelen afgør, hvem der må åbne socketten, og applikationen afgør, hvad de må gøre med den.

Det er her, det smalle design betaler sig to gange, fordi færre tilgængelige værter betyder færre steder, hvor en fejl på applikationsniveau kan udnyttes.

Hold netværksreglen og applikationsrollen i separate systemer, og nedlæg dem separat.

Bevis både den tilladte og den afviste vej

Forbind som den autoriserede bruger og udfør én uskadelig repræsentativ handling, og prøv derefter en destination, der bør være uopnåelig. Et design, der kun tester den første halvdel, er ikke testet, og den afviste test er den, der beviser designet. Test en frisk session efter hver regelændring, og se på returvejen, hvis anmodninger ankommer, men svar ikke gør.

Deaktiver ikke videresendelsesfiltre for at få accepttesten til at bestå, fordi det ændrer det, der testes.

Når brugeren ikke længere har brug for tjenesten, nedlæg den eksterne identitet og applikationsrollen i deres respektive systemer, og registrér begge. strongSwan-videresendelsesvejledningen dækker gateway-siden af vejen.