Warum eine VPN-Regel das Hochladen einer Datei nicht verhindern kann
Einen Dienst zu erreichen und zu steuern, welche Dateien ihn verlassen, sind zwei Anforderungen. Setzen Sie die Regel dort, wo die Datei sichtbar ist: Mail, Anwendung oder Endpunkt-Agent.
Ein kleines Team bittet um Fernzugriff auf seine Arbeitssysteme und im selben Atemzug darum, dass bestimmte Anhänge die Firma nicht mehr verlassen. Beide Wünsche klingen nach einer einzigen VPN-Änderung. Es sind zwei Anforderungen mit unterschiedlichen Durchsetzungspunkten, und eine Regel, die die erste erfüllt, bewirkt für die zweite nichts. Benennen Sie zuerst die Aktion und die Daten und wählen Sie dann die Komponente, die sie tatsächlich sehen kann.
Eine Anfrage, zwei Anforderungen
Die erste Anforderung betrifft die Erreichbarkeit: welche Benutzer und Geräte eine Verbindung zu welchem Dienst öffnen dürfen. Die zweite betrifft das Verhalten, nachdem diese Verbindung besteht: welche Dokumente angehängt, eingefügt oder hochgeladen werden dürfen. Ein Tunnel wirkt auf die erste und ist für die zweite konstruktionsbedingt blind.
Eine Kontrolle auf IP-Ebene leitet Pakete weiter. Sie parst keinen mehrteiligen Upload, prüft kein PDF und entscheidet nicht, ob eine Tabelle Kontonummern enthält. Das von ihr zu erwarten ist kein Konfigurationsfehler; es ist ein Kategorienfehler.
Sprechen Sie die Anforderung in dieser Form laut aus, bevor Sie ein Produkt suchen. „Benutzer dürfen das Dateiportal erreichen“ und „Benutzer dürfen keine Kundenlisten in das Dateiportal hochladen“ sind verschiedene Sätze, und nur der zweite beschreibt eine Inhaltsrichtlinie.
Wählen Sie die Komponente, die die Datei sehen kann
Die Durchsetzung muss dort geschehen, wo die Datei lesbar ist. Bei E-Mail ist das meist die Mailplattform oder das Gateway, das Anhänge bereits verarbeitet und sie vor der Zustellung bewerten kann. Bei Browser-Uploads zu einem genehmigten Dienst kann die Anwendung selbst die einzige Partei sein, die den Inhalt sieht. Bei einem verwalteten Laptop, der Dateien auf Wechselmedien kopiert, sieht ein Endpunkt-Agent den Vorgang.
| 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 |
Manche kommerziellen Fernzugriffs-Suiten bündeln einen Endpunkt-Agent, eine Webkontrolle und ein Modul zur Verhinderung von Datenverlust. Diese Komponenten können durchaus Inhaltsrichtlinien durchsetzen, doch die Fähigkeit gehört zum Modul und nicht zum Tunneln. Lesen Sie, was die Suite tatsächlich enthält, bevor Sie das Ergebnis versprechen.
Die Übersicht zur Verhinderung von Datenverlust in Purview von Microsoft ist ein nützliches Vergleichsmodell: Sie beschreibt Richtlinien anhand von Typen vertraulicher Informationen, Orten und Aktivitäten. Dieses Vokabular handelt von Inhalten und Aktionen, nicht von IP-Präfixen.
TLS überlebt den Tunnel, also planen Sie das ein
Die Verschlüsselung der Anwendung wird zwischen Client und Dienst ausgehandelt, und ein VPN-Tunnel überträgt diese Bytes, ohne sie zu öffnen. Ein Gateway auf dem Pfad erhält dadurch nicht automatisch die Fähigkeit, einen Anhang zu klassifizieren, so viel von der Route es auch besitzt.
Um Inhalte im Transit zu prüfen, brauchen Sie eine Komponente, die TLS mit einem vertrauenswürdigen Zertifikat terminiert, und das ist eine erhebliche Architekturentscheidung mit eigenen Folgen für Datenschutz und Betrieb. Es ist kein Häkchen im VPN-Profil. Clients müssen dem Prüfzertifikat vertrauen, Anwendungen, die Zertifikate pinnen, brechen, und der Betreiber gewinnt die Möglichkeit, Verkehr zu lesen, den er zuvor nicht lesen konnte. Das sind die Gründe, warum diese Entscheidung zu einem Sicherheitsverantwortlichen gehört und nicht zu dem, der den Tunnel betreibt.
Deshalb lautet die ehrliche Antwort auf „kann das VPN diesen Upload blockieren“ meist nein, gefolgt von einer konkreten Alternative. Die Alternative können Einschränkungen auf Anwendungsebene, eine Mailregel oder eine Endpunkt-Richtlinie sein, und jede davon hat einen Verantwortlichen, der sie ändern kann.
Schreiben Sie den Abnahmetest vor der Regel
Eine Inhaltsregel braucht zwei Beispiele, nicht eines: eine erlaubte Aktion, die weiter funktionieren muss, und eine verbotene Aktion, die gestoppt werden muss. Testen Sie beides aus den Anwendungen und Geräten im Geltungsbereich, denn eine Richtlinie, die nur in einem Browser funktioniert, ist nicht die Richtlinie, um die jemand gebeten hat.
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/uploadDie erste Anfrage sollte von der Komponente abgelehnt werden, die die Regel besitzt, und die zweite sollte gelingen. Gelingen beide, liegt die Kontrolle nicht im Pfad. Scheitern beide, haben Sie den Dienst kaputtgemacht statt ihn zu schützen, was das häufigere Ergebnis einer Regel ist, die ohne ein erlaubtes Beispiel geschrieben wurde.
Legen Sie vorab fest, was der Benutzer sieht, wer eine Ausnahme erteilen kann und wo ein Administrator die Entscheidung später bestätigt. Ein blockierter Upload ohne Meldung erzeugt ein Support-Ticket, und eine Regel, die niemand prüfen kann, erzeugt einen Streit. Beides lässt sich mit einem Satz Dokumentation vermeiden, der vor dem Inkrafttreten der Richtlinie geschrieben wird.
Schließlich gehören die beiden Anforderungen in getrennte Tickets mit getrennten Verantwortlichen. Sie unter „VPN“ zu bündeln garantiert, dass das Netzwerkteam ein Inhaltsproblem lösen soll und dass das Inhaltsproblem als gelöst erklärt wird, sobald der Tunnel steht.