Varför en VPN-regel inte kan stoppa uppladdningen av en fil
Att nå en tjänst och att styra vilka filer som lämnar den är två krav. Placera regeln där filen är synlig: e-post, applikation eller slutpunktsagent.
Ett litet team ber om fjärråtkomst till sina arbetssystem och ber i samma andetag att vissa bilagor slutar lämna företaget. Båda önskemålen låter som en enda VPN-ändring. De är två krav med olika tillämpningspunkter, och en regel som uppfyller det första gör ingenting för det andra. Börja med att namnge åtgärden och uppgifterna och välj sedan den komponent som faktiskt kan se dem.
En förfrågan, två krav
Det första kravet handlar om nåbarhet: vilka användare och enheter som får öppna en anslutning till vilken tjänst. Det andra handlar om beteende när anslutningen finns: vilka dokument som får bifogas, klistras in eller laddas upp. En tunnel verkar på det första och är enligt konstruktionen blind för det andra.
En kontroll på IP-nivå vidarebefordrar paket. Den tolkar inte en uppladdning i flera delar, granskar inte en PDF och avgör inte om ett kalkylark innehåller kontonummer. Att förvänta sig det är inte ett konfigurationsfel; det är ett kategorifel.
Säg kravet högt i den formen innan du letar efter en produkt. ”Användare får nå filportalen” och ”användare får inte ladda upp kundlistor till filportalen” är olika meningar, och bara den andra beskriver en innehållspolicy.
Välj den komponent som kan se filen
Tillämpningen måste ske där filen är läsbar. För e-post är det vanligtvis e-postplattformen eller gatewayen, som redan hanterar bilagor och kan bedöma dem före leverans. För webbläsaruppladdningar till en godkänd tjänst kan applikationen själv vara den enda parten som ser innehållet. För en hanterad bärbar dator som kopierar filer till flyttbara medier ser en slutpunktsagent åtgärden.
| 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 |
Vissa kommersiella fjärråtkomstpaket samlar en slutpunktsagent, en webbkontroll och en modul för dataläckageförebyggande. Dessa komponenter kan mycket väl tillämpa innehållspolicy, men förmågan tillhör modulen och inte tunnling. Läs vad paketet faktiskt innehåller innan du lovar resultatet.
Microsofts översikt över dataläckageförebyggande i Purview är en användbar modell att jämföra med: den beskriver policyer i termer av typer av känslig information, platser och aktiviteter. Den vokabulären handlar om innehåll och åtgärder, inte om IP-prefix.
TLS överlever tunneln, så planera för det
Applikationens kryptering förhandlas mellan klienten och tjänsten, och en VPN-tunnel bär dessa byte utan att öppna dem. En gateway på vägen får därför inte automatiskt förmågan att klassificera en bilaga, hur stor del av rutten den än äger.
För att granska innehåll under överföring behöver du en komponent som avslutar TLS med ett betrott certifikat, och det är ett betydande arkitekturbeslut med egna konsekvenser för integritet och drift. Det är inte en kryssruta i VPN-profilen. Klienterna måste lita på granskningscertifikatet, applikationer som pinnar certifikat kommer att gå sönder, och operatören får möjlighet att läsa trafik som den tidigare inte kunde läsa. Det är skälen till att beslutet hör till en säkerhetsägare och inte till den som driver tunneln.
Därför är det ärliga svaret på ”kan VPN:en blockera den här uppladdningen” oftast nej, följt av ett konkret alternativ. Alternativet kan vara begränsningar på applikationsnivå, en e-postregel eller en slutpunktspolicy, och var och en har en ägare som kan ändra den.
Skriv acceptanstestet före regeln
En innehållsregel behöver två exempel, inte ett: en tillåten åtgärd som måste fortsätta fungera och en förbjuden åtgärd som måste stoppas. Testa båda från applikationerna och enheterna i omfattningen, eftersom en policy som bara fungerar i en webbläsare inte är den policy någon bad om.
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/uploadDen första förfrågan bör avvisas av den komponent som äger regeln, och den andra bör lyckas. Lyckas båda finns kontrollen inte på vägen. Misslyckas båda har du förstört tjänsten i stället för att skydda den, vilket är det vanligare resultatet av en regel som skrivits utan ett tillåtet exempel.
Bestäm i förväg vad användaren ser, vem som kan bevilja ett undantag och var en administratör bekräftar beslutet efteråt. En blockerad uppladdning utan meddelande ger en supportbiljett, och en regel som ingen kan granska ger en diskussion. Båda kan undvikas med en mening dokumentation skriven innan policyn träder i kraft.
Slutligen, håll de två kraven i separata ärenden med separata ägare. Att bunta dem under ”VPN” garanterar att nätverksteamet blir ombedda att lösa ett innehållsproblem och att innehållsproblemet förklaras löst när tunneln kommer upp.