Hvorfor en VPN-regel ikke stopper at én fil lastes opp
Å nå en tjeneste og å kontrollere hvilke filer som forlater den er to krav. Plasser regelen der filen er synlig: e-post, applikasjon eller endepunktagent.
Et lite team ber om tilgang utenfra til arbeidssystemene sine og ber samtidig om at bestemte vedlegg ikke lenger skal forlate selskapet. Begge ønskene høres ut som én endring i VPN-oppsettet. De er to krav med forskjellige håndhevelsespunkter, og en regel som oppfyller det første, gjør ingenting for det andre. Start med å navngi handlingen og dataene, og velg så komponenten som faktisk kan se dem.
Én forespørsel, to krav
Det første kravet gjelder rekkevidde: hvilke brukere og enheter som kan åpne forbindelse til hvilken tjeneste. Det andre gjelder oppførsel når forbindelsen først finnes: hvilke dokumenter som kan vedlegges, limes inn eller lastes opp. En tunnel virker på det første og er konstruert for å være blind for det andre.
Kontroll på IP-nivå videresender pakker. Den tolker ikke en opplasting i flere deler, ser ikke inn i en PDF og avgjør ikke om et regneark inneholder kontonumre. Å forvente det er ikke en feil i konfigurasjonen, men en feil i kategorien.
Formuler kravet høyt på den måten før du ser deg om etter et produkt. «Brukere skal kunne nå filportalen» og «brukere skal ikke kunne laste opp kundelister til filportalen» er to forskjellige setninger, og bare den siste beskriver en innholdspolicy.
Velg komponenten som ser filen
Håndhevelsen må skje der filen kan leses. For e-post betyr det vanligvis e-postplattformen eller gatewayen, som allerede behandler vedlegg og kan vurdere dem før levering. For opplasting fra nettleser til en godkjent tjeneste kan applikasjonen selv være den eneste som ser innholdet. For en administrert bærbar PC som kopierer filer til flyttbare medier, ser en endepunktagent operasjonen.
| 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 |
Enkelte kommersielle pakker for fjernaksess kombinerer en endepunktagent, nettkontroll og en modul mot datatap. Disse komponentene kan godt håndheve innholdspolicy, men evnen ligger i modulen og ikke i tunnelleringen. Les hva pakken faktisk inneholder før du lover resultatet.
Microsofts gjennomgang av datatapsforebygging i Purview er en nyttig modell å sammenligne med: den beskriver policyer gjennom typer sensitive opplysninger, steder og aktiviteter. Det ordforrådet handler om innhold og handlinger, ikke om IP-prefikser.
TLS overlever tunnelen, så planlegg for det
Krypteringen av applikasjonen forhandles mellom klienten og tjenesten, og en VPN-tunnel frakter bytene uten å åpne dem. En gateway underveis får derfor ikke automatisk evnen til å klassifisere et vedlegg, uansett hvor stor del av ruten den kontrollerer.
Vil du inspisere innhold underveis, trenger du en komponent som avslutter TLS med et sertifikat klientene stoler på, og det er en betydelig arkitekturbeslutning med egne personvern- og driftskonsekvenser. Det er ikke et avkrysningsfelt i VPN-profilen. Klientene må stole på inspeksjonssertifikatet, applikasjoner som låser sertifikater vil knekke, og operatøren får mulighet til å lese trafikk den ikke kunne lese før. Derfor hører beslutningen til en sikkerhetsansvarlig, ikke til den som driver tunnelen.
Det er grunnen til at det ærlige svaret på «kan VPN blokkere denne opplastingen» som regel er nei, etterfulgt av et konkret alternativ. Alternativet kan være begrensninger på applikasjonsnivå, en e-postregel eller en endepunktpolicy, og hver av dem har en eier som kan endre den.
Skriv akseptansetesten før regelen
En innholdsregel trenger to eksempler, ikke ett: en tillatt handling som må fortsette å virke, og en forbudt handling som må stanses. Prøv begge fra applikasjonene og enhetene som er omfattet, for en policy som bare virker i én nettleser er ikke policyen noen ba 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ørste forespørselen bør avvises av komponenten som eier regelen, og den andre bør lykkes. Lykkes begge, står kontrollen ikke i veien. Feiler begge, har du ødelagt tjenesten i stedet for å beskytte den, og det er det vanligste utfallet av en regel skrevet uten et tillatt eksempel.
Bestem på forhånd hva brukeren ser, hvem som kan gi unntak, og hvor en administrator bekrefter beslutningen i etterkant. En blokkert opplasting uten melding gir en supportsak, og en regel ingen kan revidere gir en diskusjon. Begge kan unngås med én setning dokumentasjon skrevet før policyen trer i kraft.
Til slutt: hold de to kravene i hver sin sak med hver sin eier. Å slå dem sammen under «VPN» garanterer at nettverksteamet blir bedt om å løse et innholdsproblem, og at innholdsproblemet erklæres løst i det tunnelen kommer opp.