Hoi,
Het lijkt erop dat de business een datadienst wil afnemen van een derde partij leverancier, die een ipsec-tunnel tussen ons en hen vereist voor de overdracht van gegevens tussen onze en hun databases.
Tot nu toe zijn we erin geslaagd om het nodig hebben van site-to-site tunnels met externe partijen te vermijden (en zo ons bedreigingslandschap te vergroten), maar misschien moeten we in dit geval toegeven, dus ik ben benieuwd naar de beste praktijken op het gebied van beveiliging / ontwerp die jullie gewoonlijk volgen?
Mijn vraag gaat vooral over topologie en blootstelling van ons netwerk / plaatsing van blootgestelde apparaten / segmentatie / dreigingsbeheer etc, in plaats van de configuratie van de ipsec-tunnel zelf.
Thanks voor elk advies dat je kunt geven.
Beschouw de tunnelinterface/verkeer net zoals je dat zou doen met een DMZ met openbare webservers. Sta slechts zeer specifiek verkeer toe, gebruik DPI en andere functies die je hebt om applicaties, antivirus en andere inspecties uit te voeren. Als je SaaS-toepassingen gebruikt waarvan de leverancier toegang nodig heeft, geef ze die toegang niet via de tunnel maar handhaaf goede toegangscontrole.
In het verleden hebben we ook bestandsdeling apart gemaakt voor leveranciers met slechts de data die ze nodig hebben om ze zo geïsoleerd mogelijk te houden.
Het klinkt alsof de IPSec-tunnel in de acceptabele risicobasket zal komen. Als het aan mij lag, zou ik de database-server in een DMZ-achtige zone plaatsen en alleen de specifieke poorten toestaan via een beveiligingsbeleid.
We doen dit de hele tijd met leveranciers. We beperken zo veel mogelijk welke subnets of apparaten met hun subnets kunnen praten, en vice versa om het risico te beperken.
Kijk eens naar OpenZiti/NetFoundry. Gecontroleerde toegangsregeling via centraal beleid, schaalbaar, en het heeft veel loggegevens, details, etc. Wij (ik werk bij NetFoundry) hebben veel klanten die het gebruiken voor interbedrijfconnectiviteit, vooral MSP/MSSP-verbindingen, maar een extranet zou hetzelfde model gebruiken.
Wat ik in een vorige functie deed, waar we aan deze eisen voldeden, was het creëren van een nieuwe DMZ speciaal voor deze tunnelendpoint. Een discreet apparaat dat alleen de taak heeft om de tunnel te beëindigen in de DMZ plaatsen. Vervolgens zou ik firewallregels opstellen om het benodigde verkeer toe te staan. Wat betreft de datatransfer, hangt het af van wat nodig is. Als er een gegevensdump van een database nodig was, haalden we de specificaties op, maakten we een datadump-script, plannen we het proces en verplaatsten we de data naar een server die toegankelijk was vanuit de DMZ. De DMZ zou verder geen andere toegang hebben en bestanden zouden tussen ons worden overgedragen.
In het geval dat een live-overdracht nodig was, zouden we weer een specifieke gebruiker voor de activiteit maken, en deze gebruiker alleen laten inloggen vanaf de DMZ-verbinding. Extreem beperkende toegangsregels instellen (beginnen met niets en zo weinig mogelijk geven versus alles geven en toegang verminderen).
Alles loggen, alles monitoren. Als het andere bedrijf meerdere personen nodig heeft om toegang tot onze systemen te krijgen, moeten ze allemaal individuele accounts hebben, moeten ze akkoord gaan met onze processen. We leggen dit vast in contracten en het wordt onderdeel van de SLA/contractbeëindigingsvoorwaarden.
Ik werk voor een van die SaaS-aanbieders en wij hebben meer dan 1000 tunnels naar klantnetwerken. We worden alleen betrokken en werken met klanten wanneer iemand moet afwijken van onze standaardimplementatie, maar uit ervaring is er geen standaard manier waarop klanten hun kant implementeren. Ik heb ze tunnels zien beëindigen voor, op en achter hun firewalls. Vaak in speciale DMZ-netwerken, maar ik heb er veel gezien die rechtstreeks routen/NAT’en naar hun LAN. Het hangt af van je eigen topologie, interne beleidslijnen en eventuele audit-/compliance-eisen.
Ik zou een aparte DMZ-zone maken voor leveranciers, die niet direct verbonden is met je interne netwerk. Je moet uitzoeken hoe precies de databases worden gesynchroniseerd. Er is geen reden om je database en die van de leverancier direct te laten praten. Er moet een tussenapparaat zijn dat dit werk doet.
De eerste (en enige?) stap is expliciet aangeven welk verkeer toegestaan is om de IPsec-tunnel binnen te komen en te verlaten. Idealiter wordt de tunnel op een van je firewalls beëindigd zodat deze stateful inspection kan uitvoeren. Firewallbeleidsregels zijn daarna een natuurlijk hulpmiddel om alleen gewenst verkeer over de tunnel toe te laten.
… we zijn erin geslaagd om het gebruik van site-to-site tunnels met externe partijen te voorkomen (en daarmee ons bedreigingslandschap te vergroten)
Ik begrijp niet waarom je je bedreigingslandschap wilt vergroten door IPsec-tunnels te vermijden. Dat lijkt me slecht.
Overschakel naar ZTP-model met een overlay-netwerk waarop de leverancier aansluit, en geef daarna alleen de benodigde rollen. Maak geen gebruik van IPSEC-site-to-site VPN-tunnels zoals in 1999. Er zijn veel ZTP-oplossingen die je kunt gebruiken, de meesten zijn open source en gratis, anderen vereisen een licentie. Gebruik snellere en betere VPN’s zoals Wireguard in plaats van IPSEC.
Heel eenvoudig, bouw de tunnelendpoint op je firewall en gebruik geschikte proxy-IDs en/of beleidsfilters om te zorgen dat ze alleen naar de systemen kunnen gaan waarvoor ze geautoriseerd zijn. Vraag ook een beëindigingsdatum van het contract wanneer het werk voltooid moet zijn, en verwijder de tunnel en configuraties zodra het klaar is, indien van toepassing.
Laat alleen de specifieke IP’s toe die verbinding maken.
Vervolgens hangt alles af van wat ze hoeven te verbinden, maar waarschijnlijk plaats je het in een firewall of in een aparte vrf en staat alleen toegang toe tot een heel klein aantal dingen met de juiste authenticatie, auditlogs, etc.
Niet het vermijden van ipsec-tunnels, maar het vermijden dat onbetrouwbare netwerken direct aan ons gekoppeld zijn, vermindert onze blootstelling - ik denk dat een hoog percentage van de compromissen afkomstig is van netwerken van derdenleveranciers die via verschillende middelen met anderen interfacen.
Het zal ongetwijfeld worden beëindigd op firewalls en stateful inspected,
Het is de bredere implicaties dat sommige gegevensbronnen aan onze zijde “intern” zijn - zou je het verkeer rechtstreeks naar het eindpunt (db) laten routeren of er een of andere proxy of fronting toepassen na de firewall, of de gegevensbron verplaatsen naar een gecontroleerd DMZ-achtig gebied om laterale beweging te voorkomen?
Maak geen site-to-site IPSEC VPN-tunnels zoals in 1999
Haha, precies mijn gedachte! Ik heb ze overal gezien als oplossing voor allerlei problemen en het is een nachtmerrie qua beveiliging. En dat probeer ik te vermijden.
Dus in jouw scenario ga ik ervan uit dat laterale beweging voor de blootgestelde interne host al sterk beperkt is door een zero trust-achtig beleid?
We zijn daar helaas nog niet.
Dat is gewoon een telefoon-naar-telefoonsysteem, maar een modernere implementatie. Dit was vroeger SSH-tunnels, wat voor mij prima is, omdat de toepassing van de firewall minder gedoe is dan het nemen van VPN-verantwoordelijkheid.
Soms moet je oude technologie uit 1999 gebruiken, net zoals we nu TCP/IP gebruiken uit de jaren 70. Endpoint-to-Endpoint-oplossingen zoals deze kunnen net zo problematisch zijn. Ondersteunen de server-OS’en de clientsoftware? Ondersteunt het serverteam het? Hoe verbinden de systemen zich? Vereist het portforwarding? Wordt er een cloud-connector gebruikt voor de setup? Als dat zo is, wie beheert/eigent dat en hoe wordt het beschermd?
Geen poging om je idee volledig af te wijzen, maar soms worden schijnbaar oude oplossingen gebruikt omdat ze nog steeds de juiste oplossing voor de klus zijn.