Geef VPN-gebruikers toegang tot één dienst, niet tot het subnet

Een aannemer heeft één interne webapplicatie nodig en niets anders, en het gemakkelijke antwoord is hem een tunnel naar het serversubnet te geven. Dat werkt tot de dag dat hij het scant. Het smallere ontwerp vraagt meer nadenken, omdat bereikbaarheid, routering en applicatietoestemming drie afzonderlijke controles zijn die moeten kloppen.

Schrijf de eis als een dienst, niet als een subnet

Begin met de doelserver, het protocol en de poort, en voeg dan de gebruiker- of apparaatgroep toe die hem moet bereiken. Neem de privé-DNS-zone alleen op als de applicatie een naam oplost, en een identiteitsprovider alleen als de inlogstroom er een nodig heeft. Al het andere is een afhankelijkheid die u nog niet hebt gerechtvaardigd.

Een subnet is een implementatiedetail van het netwerkteam, terwijl een dienst is wat het bedrijf vroeg en de eenheid die kan worden beoordeeld en uitgefaseerd.

Als de afhankelijkhedenlijst boven de drie items groeit, heeft de applicatie waarschijnlijk een eigen ontwerpgesprek nodig.

Routeer smal, maar handhaaf elders

Een smalle route of selector vertelt de tunnel welke pakketten hij moet dragen; het is geen autorisatiebeleid. Het gateway-filter, de firewall van de doelserver en het eigen toestemmingsmodel van de applicatie zijn de plekken waar toegang wordt besloten. Een route die één adres dekt is een goed begin, en het is niet de controle die een vastberaden gebruiker tegenhoudt. Juist die scheiding maakt het mogelijk het filter te wijzigen zonder de tunnel opnieuw te ontwerpen.

Omgekeerd kan een brede route met een streng filter legitiem zijn, maar alleen als iedereen die erbij betrokken is weet welke van de twee de handhaving doet.

Documenteer het handhavingspunt expliciet, anders verplaatst de volgende wijziging het per ongeluk.

Controleer de bron die de dienst werkelijk ziet

Het doel ziet ofwel het pooladres van de client ofwel het adres van de gateway, afhankelijk van of u vertaalt. Firewallregels en logboeken van de server moeten overeenkomen met de echte bron. Als meerdere gebruikers een vertaalde bron delen, kan geen regel per gebruiker op die server hen onderscheiden, en dat is een ontwerpbeperking, geen fout.

Kies vertaling bewust: het vereenvoudigt routering en vernietigt de bronidentiteit, wat van belang is voor audits en voor regels per gebruiker.

Noteer welke van de twee u hebt gekozen, naast de regel die ervan afhangt.

Applicatie-autorisatie is niet optioneel

Een poort bereiken geeft geen rol. De applicatie heeft nog steeds haar eigen login en haar eigen toestemmingen nodig, omdat de netwerklaag niet kan uitdrukken welke records een gebruiker mag bewerken. Een dienst die elk verzoek uit het interne subnet vertrouwt, verandert een smalle tunnel in volledige toegang voor één gecompromitteerde inloggegevens. De tunnel bepaalt wie de socket mag openen, en de applicatie bepaalt wat daarmee mag gebeuren.

Hier betaalt het smalle ontwerp zich dubbel uit, want minder bereikbare servers betekent minder plekken waar een fout op applicatieniveau kan worden misbruikt.

Houd de netwerkregel en de applicatierol in gescheiden systemen, en faseer ze apart uit.

Bewijs zowel het toegestane als het geweigerde pad

Verbind als de geautoriseerde gebruiker en voer één onschadelijke representatieve handeling uit, en probeer daarna een bestemming die onbereikbaar zou moeten zijn. Een ontwerp dat alleen de eerste helft test, is niet getest, en de geweigerde test is degene die het ontwerp bewijst. Test een nieuwe sessie na elke regelwijziging, en kijk naar het retourpad als verzoeken aankomen maar antwoorden niet.

Schakel geen doorstuurfilters uit om de acceptatietest te laten slagen, want dat verandert het ding dat wordt getest.

Als de gebruiker de dienst niet meer nodig heeft, faseer dan de externe identiteit en de applicatierol in hun eigen systemen uit, en leg beide vast. De strongSwan-handleiding voor doorsturen behandelt de gateway-kant van het pad.