Dlaczego reguła VPN nie powstrzyma wysłania jednego pliku
Osiągalność usługi i kontrola nad tym, które pliki z niej wychodzą, to dwa wymagania. Umieść regułę tam, gdzie plik jest widoczny: poczta, aplikacja lub agent punktu końcowego.
Mały zespół prosi o zdalny dostęp do swoich systemów pracy i w tym samym oddechu prosi, aby pewne załączniki przestały opuszczać firmę. Oba życzenia brzmią jak jedna zmiana VPN. To dwa wymagania z różnymi punktami egzekwowania, a reguła spełniająca pierwsze nie robi nic dla drugiego. Zacznij od nazwania działania i danych, a potem wybierz komponent, który naprawdę może je zobaczyć.
Jedno żądanie, dwa wymagania
Pierwsze wymaganie dotyczy osiągalności: którzy użytkownicy i urządzenia mogą otworzyć połączenie z którą usługą. Drugie dotyczy zachowania po powstaniu tego połączenia: które dokumenty można załączyć, wkleić lub wysłać. Tunel działa na pierwsze i z założenia jest ślepy na drugie.
Kontrola na poziomie IP przekazuje pakiety. Nie analizuje wysyłki wieloczęściowej, nie sprawdza PDF i nie decyduje, czy arkusz zawiera numery kont. Oczekiwanie tego od niej nie jest błędem konfiguracji; to błąd kategorii.
Powiedz wymaganie na głos w tej postaci, zanim zaczniesz szukać produktu. „Użytkownicy mogą dotrzeć do portalu plików” i „użytkownicy nie mogą wysyłać list klientów do portalu plików” to różne zdania, i tylko drugie opisuje politykę treści.
Wybierz komponent, który widzi plik
Egzekwowanie musi następować tam, gdzie plik jest czytelny. W przypadku poczty jest to zwykle platforma lub brama pocztowa, która już obsługuje załączniki i może je ocenić przed dostarczeniem. Przy wysyłce z przeglądarki do zatwierdzonej usługi sama aplikacja może być jedyną stroną, która widzi treść. Gdy zarządzany laptop kopiuje pliki na nośniki wymienne, operację widzi agent punktu końcowego.
| 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 |
Niektóre komercyjne pakiety dostępu zdalnego łączą agenta punktu końcowego, kontrolę sieciową i moduł zapobiegania utracie danych. Te komponenty mogą egzekwować politykę treści, ale zdolność należy do modułu, a nie do tunelowania. Przeczytaj, co pakiet naprawdę zawiera, zanim obiecasz wynik.
Przydatnym modelem porównawczym jest przegląd zapobiegania utracie danych w Purview firmy Microsoft: opisuje zasady w kategoriach typów informacji poufnych, lokalizacji i działań. To słownictwo dotyczy treści i działań, a nie prefiksów IP.
TLS przeżywa tunel, więc zaplanuj to
Szyfrowanie aplikacji jest negocjowane między klientem a usługą, a tunel VPN przenosi te bajty bez ich otwierania. Brama na ścieżce nie zyskuje więc automatycznie zdolności klasyfikowania załącznika, niezależnie od tego, jak dużą część trasy posiada.
Aby sprawdzać treść w tranzycie, potrzebujesz komponentu, który kończy TLS zaufanym certyfikatem, a to poważna decyzja architektoniczna z własnymi skutkami dla prywatności i eksploatacji. To nie jest pole wyboru w profilu VPN. Klienci muszą ufać certyfikatowi inspekcji, aplikacje przypinające certyfikaty się zepsują, a operator zyskuje możliwość czytania ruchu, którego wcześniej nie mógł czytać. To są powody, dla których ta decyzja należy do właściciela bezpieczeństwa, a nie do osoby obsługującej tunel.
Dlatego uczciwa odpowiedź na „czy VPN może zablokować tę wysyłkę” brzmi zwykle nie, po czym następuje konkretna alternatywa. Alternatywą mogą być ograniczenia na poziomie aplikacji, reguła pocztowa lub polityka punktu końcowego, a każda z nich ma właściciela, który może ją zmienić.
Napisz test akceptacyjny przed regułą
Reguła treści potrzebuje dwóch przykładów, nie jednego: dozwolonego działania, które musi nadal działać, i zabronionego, które musi zostać zatrzymane. Przetestuj oba z aplikacji i urządzeń w zakresie, ponieważ polityka działająca tylko w jednej przeglądarce nie jest polityką, o którą ktoś prosił.
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/uploadPierwsze żądanie powinien odrzucić komponent, który posiada regułę, a drugie powinno się powieść. Jeśli powiodą się oba, kontrola nie leży na ścieżce. Jeśli zawiodą oba, zepsułeś usługę zamiast ją chronić, co jest częstszym wynikiem reguły napisanej bez dozwolonego przykładu.
Zdecyduj z góry, co widzi użytkownik, kto może udzielić wyjątku i gdzie administrator potwierdza decyzję później. Zablokowana wysyłka bez komunikatu generuje zgłoszenie do pomocy technicznej, a reguła, której nikt nie może zaudytować, generuje spór. Obu można uniknąć dzięki jednemu zdaniu dokumentacji napisanemu przed wejściem polityki w życie.
Na koniec trzymaj oba wymagania w osobnych zgłoszeniach z osobnymi właścicielami. Połączenie ich pod „VPN” gwarantuje, że zespół sieciowy zostanie poproszony o rozwiązanie problemu treści i że problem treści zostanie ogłoszony rozwiązany, gdy tunel wstanie.