Waarom een VPN-regel één bestand niet tegenhoudt bij het uploaden
Een dienst bereiken en bepalen welke bestanden hem verlaten zijn twee vereisten. Zet de regel waar het bestand zichtbaar is: mail, applicatie of endpoint-agent.
Een klein team vraagt om externe toegang tot zijn werksystemen en vraagt in dezelfde adem dat bepaalde bijlagen het bedrijf niet meer verlaten. Beide verzoeken klinken als één VPN-wijziging. Het zijn twee vereisten met verschillende handhavingspunten, en een regel die aan de eerste voldoet, doet niets voor de tweede. Benoem eerst de actie en de gegevens en kies dan het onderdeel dat ze echt kan zien.
Eén verzoek, twee vereisten
De eerste vereiste gaat over bereikbaarheid: welke gebruikers en apparaten een verbinding naar welke dienst mogen openen. De tweede gaat over gedrag nadat die verbinding bestaat: welke documenten mogen worden bijgevoegd, geplakt of geüpload. Een tunnel werkt op de eerste en is per ontwerp blind voor de tweede.
Een controle op IP-niveau stuurt pakketten door. Hij parseert geen upload met meerdere delen, inspecteert geen PDF en beslist niet of een spreadsheet rekeningnummers bevat. Dat van hem verwachten is geen configuratiefout; het is een categoriefout.
Spreek de vereiste hardop in die vorm uit voordat je een product zoekt. „Gebruikers mogen het bestandsportaal bereiken” en „gebruikers mogen geen klantenlijsten naar het bestandsportaal uploaden” zijn verschillende zinnen, en alleen de tweede beschrijft een inhoudsbeleid.
Kies het onderdeel dat het bestand kan zien
Handhaving moet gebeuren waar het bestand leesbaar is. Voor e-mail is dat meestal het mailplatform of de gateway, die bijlagen al verwerkt en ze vóór aflevering kan beoordelen. Voor browseruploads naar een goedgekeurde dienst kan de applicatie zelf de enige partij zijn die de inhoud ziet. Voor een beheerde laptop die bestanden naar verwisselbare media kopieert, ziet een endpoint-agent de handeling.
| Where the file moves | Component that can see it |
|---|---|
| Email attachment | Mail gateway or mail platform policy |
| Upload to a web application | The application, or an inspection proxy that terminates TLS |
| Copy to USB or local folder | Endpoint agent on the device |
| Anything inside the tunnel | Nothing, unless one of the above is present |
Sommige commerciële suites voor externe toegang bundelen een endpoint-agent, een webcontrole en een module voor gegevensverliespreventie. Die onderdelen kunnen best inhoudsbeleid handhaven, maar de mogelijkheid hoort bij de module en niet bij het tunnelen. Lees wat de suite werkelijk bevat voordat je het resultaat belooft.
Het overzicht van gegevensverliespreventie van Purview van Microsoft is een bruikbaar vergelijkingsmodel: het beschrijft beleid in termen van soorten gevoelige informatie, locaties en activiteiten. Dat vocabulaire gaat over inhoud en acties, niet over IP-prefixen.
TLS overleeft de tunnel, dus plan dat in
De versleuteling van de applicatie wordt tussen de client en de dienst onderhandeld, en een VPN-tunnel draagt die bytes zonder ze te openen. Een gateway op het pad krijgt daardoor niet automatisch de mogelijkheid om een bijlage te classificeren, hoe groot het deel van de route ook is.
Om inhoud onderweg te inspecteren heb je een onderdeel nodig dat TLS beëindigt met een vertrouwd certificaat, en dat is een aanzienlijke architectuurkeuze met eigen gevolgen voor privacy en beheer. Het is geen vinkje in het VPN-profiel. Clients moeten het inspectiecertificaat vertrouwen, applicaties die certificaten vastpinnen breken, en de operator krijgt de mogelijkheid verkeer te lezen dat hij voorheen niet kon lezen. Dat zijn de redenen waarom deze beslissing bij een beveiligingseigenaar hoort en niet bij wie de tunnel draait.
Daarom is het eerlijke antwoord op „kan de VPN deze upload blokkeren” meestal nee, gevolgd door een concreet alternatief. Het alternatief kan een beperking op applicatieniveau zijn, een mailregel of een endpointbeleid, en elk daarvan heeft een eigenaar die het kan wijzigen.
Schrijf de acceptatietest vóór de regel
Een inhoudsregel heeft twee voorbeelden nodig, niet één: een toegestane actie die moet blijven werken en een verboden actie die moet worden gestopt. Test beide vanuit de applicaties en apparaten binnen het bereik, want een beleid dat alleen in één browser werkt is niet het beleid waar iemand om heeft gevraagd.
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/upload
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/uploadHet eerste verzoek hoort te worden geweigerd door het onderdeel dat de regel bezit, en het tweede hoort te slagen. Als beide slagen, zit de controle niet in het pad. Als beide mislukken, heb je de dienst kapotgemaakt in plaats van beschermd, wat de vaker voorkomende uitkomst is van een regel die zonder toegestaan voorbeeld is geschreven.
Bepaal vooraf wat de gebruiker ziet, wie een uitzondering kan geven en waar een beheerder de beslissing achteraf bevestigt. Een geblokkeerde upload zonder melding levert een supportticket op, en een regel die niemand kan auditen levert een discussie op. Beide zijn te voorkomen met één zin documentatie die is geschreven voordat het beleid ingaat.
Ten slotte, houd de twee vereisten in aparte tickets met aparte eigenaren. Ze onder „VPN” bundelen garandeert dat het netwerkteam wordt gevraagd een inhoudsprobleem op te lossen, en dat het inhoudsprobleem als opgelost wordt verklaard zodra de tunnel staat.