Jak ocenić dostawcę VPN w audycie bezpieczeństwa: lista kryteriów dla CEO i IT

Po co firmie VPN i co tak naprawdę kupujesz

VPN jako produkt konsumencki vs. element architektury bezpieczeństwa

VPN w ujęciu konsumenckim to „apka do oglądania serwisów streamingowych za granicą” albo „tarcza prywatności w hotelowym Wi‑Fi”. W firmie taki sposób myślenia jest prostą drogą do wyboru rozwiązania, które dobrze wygląda w marketingu, ale nie wytrzymuje zderzenia z audytem bezpieczeństwa i wymogami compliance.

VPN jako element architektury bezpieczeństwa to komponent większej układanki: kontroli dostępu, segmentacji sieci, monitoringu, polityk haseł i zarządzania tożsamością. W takim podejściu dostawca VPN nie jest „aplikacją”, tylko krytycznym dostawcą infrastruktury, podobnie jak operator data center czy dostawca chmury. Tu każda awaria, wyciek lub błąd konfiguracji ma wpływ na całą organizację.

Jeśli w firmie VPN ma służyć jedynie kilku osobom do bezpiecznego połączenia z domowej sieci do biura, wymagania mogą być stosunkowo proste: stabilny tunel, szyfrowanie na przyzwoitym poziomie, podstawowe logowanie zdarzeń. Gdy jednak ten sam VPN ma spinać oddziały, partnerów, dostawy i zdalne zespoły, a dodatkowo bywa jedną z warstw ochrony przed atakami, lista kryteriów audytu rośnie wykładniczo.

Jeśli w rozmowie wewnętrznej VPN pojawia się głównie w kontekście „taniej aplikacji dla pracowników”, oznacza to, że obszar architektury bezpieczeństwa nie został jeszcze dostatecznie przepracowany. Jeśli natomiast rozważasz VPN jako usługę klasy „security backbone”, od samego początku należy traktować dostawcę jak partnera strategicznego, a nie jak kolejny abonament SaaS.

Scenariusze biznesowe: gdzie VPN jest krytyczny

Lista scenariuszy użycia powinna powstać przed wyborem dostawcy. Bez tego ocena bezpieczeństwa będzie oderwana od realiów biznesowych. Najczęstsze scenariusze:

• Zdalny dostęp pracowników – praca z domu, z podróży, z sieci publicznych. Tu VPN jest bramą do zasobów wewnętrznych (intranet, ERP, CRM, bazy danych).
• Łączenie oddziałów i lokalizacji – tunele site‑to‑site między biurami, magazynami, fabrykami, a czasem także między chmurą a on‑prem.
• Dostęp partnerów i dostawców – integratorzy, utrzymanie systemów, konsultanci, podwykonawcy z dostępem do środowisk produkcyjnych lub testowych.
• Ochrona pracowników mobilnych – sprzedaż w terenie, serwisanci, kadra zarządzająca podróżująca z laptopem i telefonem.

Każdy z tych scenariuszy ma inne wymagania co do kontroli dostępu, segmentacji, logowania i skalowalności. VPN do zdalnego dostępu 10 osób można skonfigurować niemal „z pudełka”. Inaczej wygląda sytuacja, gdy setki użytkowników łączą się równocześnie, a jeden błąd w politykach VPN otwiera nieautoryzowany dostęp do segmentu z danymi finansowymi.

Jeśli firma ma choć jeden scenariusz, w którym awaria VPN zatrzyma sprzedaż, produkcję albo obsługę klienta, to sygnał, że dostawca VPN powinien być oceniany przy użyciu tak samo rygorystycznych kryteriów jak dostawca chmury lub operator centrum danych.

Co faktycznie kupujesz: technologia, procesy, gwarancje

W materiałach marketingowych VPN jest zwykle opisany przez pryzmat funkcji: liczba serwerów, krajów, protokołów, aplikacji klienckich. W audycie bezpieczeństwa interesuje przede wszystkim to, jak wygląda ekosystem dookoła technologii:

• Procesy bezpieczeństwa – jak wygląda zarządzanie podatnościami, aktualizacje, reagowanie na incydenty, rotacja kluczy kryptograficznych.
• Gwarancje prawne i umowne – SLA, klauzule dot. bezpieczeństwa, odpowiedzialność za naruszenia, warunki współpracy z organami ścigania.
• Model wsparcia – czas reakcji, dostępność inżynierów, poziom wiedzy pierwszej linii supportu, ścieżka eskalacji.
• Transparentność techniczna – dokumentacja, API, dostępność logów, integracja z istniejącymi systemami SIEM / IAM.

VPN jako produkt to więc połączenie: oprogramowania, infrastruktury oraz dojrzałości organizacyjnej dostawcy. Bez rzetelnych procesów i sensownej umowy nawet bardzo dobry technologicznie VPN staje się krytycznym ryzykiem.

Jeśli dostawca sprzedaje głównie „funkcje” i unikając szczegółów procesowych odsyła do marketingu, to sygnał ostrzegawczy, że w tle może brakować dojrzałości operacyjnej. Jeśli jest gotów pokazać procedury, schematy odpowiedzialności i wzory raportów bezpieczeństwa – poziom zaufania rośnie.

Oczekiwania CEO vs. oczekiwania IT

Z perspektywy CEO czy CFO VPN jest narzędziem do zrealizowania celu biznesowego: umożliwienia pracy zdalnej, obniżenia kosztów łączności między lokalizacjami, spełnienia wymogów bezpieczeństwa stawianych przez kluczowego klienta. Oczekiwania to zwykle:

• bezawaryjność i przewidywalny koszt,
• brak barier dla wzrostu (skalowalność),
• zgodność z wymaganiami regulacyjnymi i audytami klientów,
• czytelne warunki odpowiedzialności dostawcy.

Dla działu IT i bezpieczeństwa istotne są inne elementy: jakość szyfrowania, sposób zarządzania tożsamościami, integracja z istniejącą infrastrukturą, dostęp do logów, łatwość automatyzacji i monitoringu. IT chce też mieć realny wpływ na konfigurację i polityki, a nie być zmuszone do pracy „na sztywno” w ramach marketingowo opakowanego produktu.

Kluczowe jest skonstruowanie listy kryteriów, w której minimum biznesowe (np. SLA, cena, warunki rezygnacji) jest równoważone z minimum technicznym (protokoły, standardy szyfrowania, logowanie, integracja). W przeciwnym razie jedna ze stron – zarząd albo IT – będzie miała poczucie, że kompromisy są zbyt daleko idące.

Jeśli w procesie wyboru dostawcy VPN dominuje wyłącznie perspektywa finansowa, to ryzyko niezaakceptowalnych kompromisów bezpieczeństwa skacze do góry. Jeśli ustalenia prowadzi tylko IT, nietrudno przeoczyć istotne koszty ukryte czy ryzyka kontraktowe.

Ramy oceny: kto powinien brać udział w audycie dostawcy VPN

Kluczowe role i odpowiedzialności

Audyt dostawcy VPN to proces wielowymiarowy: dotyka bezpieczeństwa, finansów, prawa, operacji i strategii. Dlatego jednoosobowe decyzje (np. „administrator znalazł fajny VPN, bierzemy”) są jednym z najczęstszych błędów. Zaangażowane powinny być co najmniej:

• CEO / CFO – określają dopuszczalne ryzyko, horyzont czasowy współpracy, budżet, ocenę wpływu na działalność operacyjną.
• CISO / IT Security – ocena technicznego poziomu bezpieczeństwa, standardów kryptografii, architektury, procesów reagowania na incydenty.
• Administratorzy systemów / sieci – weryfikują integrację z obecną infrastrukturą, narzędzia zarządzania, wpływ na utrzymanie i monitoring.
• Dział prawny i compliance – analiza jurysdykcji, umowy, klauzul dotyczących odpowiedzialności, ochrony danych osobowych, tajemnicy przedsiębiorstwa.

W małych organizacjach te role mogą łączyć się w jednej osobie, ale perspektywy nie mogą zniknąć. Nawet jeśli CEO pełni funkcję CFO, ktoś musi zadać pytania o TCO, a ktoś o konsekwencje prawne przechowywania logów za granicą.

Jeśli ocena dostawcy VPN jest prowadzona tylko przez IT, ryzyko przeoczenia aspektów prawnych, finansowych i reputacyjnych jest bardzo wysokie. Jeżeli decyzję podejmuje wyłącznie zarząd na podstawie oferty handlowej, bez dogłębnej oceny technicznej, ryzyko nieświadomych luk bezpieczeństwa dramatycznie wzrasta.

Jak zbudować wspólny arkusz kryteriów

Arkusz kryteriów – prosta tabela w arkuszu kalkulacyjnym – jest najlepszym narzędziem, by ucywilizować dyskusję między biznesem a IT. Powinny znaleźć się w nim kategorie, w ramach których każdy dział dopisze własne wymagania:

• Bezpieczeństwo techniczne – protokoły, szyfrowanie, logowanie, integracje, zarządzanie kluczami, mechanizmy dodatkowe (kill switch, PFS, ochrona przed wyciekiem DNS).
• Aspekty prawne i compliance – jurysdykcja, podmioty przetwarzające, zgodność z RODO/innymi regulacjami, klauzule powierzenia przetwarzania danych, polityka logów.
• Finanse i TCO – cena licencji, koszty wdrożenia, koszty utrzymania, wymagane integracje, koszt ewentualnej migracji w przyszłości.
• Operacje i wsparcie – SLA, czas reakcji, model wsparcia, szkolenia, dostępność dokumentacji, doświadczenia referencyjne w zbliżonej branży.

Każde kryterium otrzymuje trzy podstawowe parametry: „must‑have”, „nice‑to‑have”, „nieistotne”. W ten sposób już na starcie da się wyeliminować oferty, które nie spełniają absolutnego minimum – bez wchodzenia w dyskusję cenową.

Jeśli arkusz kryteriów jest przygotowany wspólnie, konflikty na etapie wyboru dostawcy są mniej emocjonalne i bardziej merytoryczne. Jeśli kryteria są zdefiniowane dopiero po obejrzeniu kilku prezentacji handlowych, rośnie ryzyko, że zostaną dopasowane do „ulubionego” dostawcy zamiast do realnych potrzeb.

Spotkanie kick‑off i ustalenie „minimum bezpieczeństwa”

Krótka sesja kick‑off z udziałem kluczowych osób to punkt kontrolny, którego pominięcie zwykle mści się po kilku miesiącach. Podczas takiego spotkania należy:

• zdefiniować główne scenariusze użycia VPN (kto, skąd, do czego się łączy),
• ustalić poziom akceptowalnego ryzyka (np. brak logów vs. logowanie minimalne),
• określić, które regulacje i standardy muszą być spełnione (RODO, ISO 27001, branżowe regulacje sektorowe),
• przyjąć ramowy budżet i horyzont czasowy współpracy z dostawcą (2, 3, 5+ lat).

Na tej podstawie powstaje lista „minimum bezpieczeństwa” – zbiór warunków, poniżej których żadna oferta nie jest nawet analizowana. Przykłady takich minimów to: brak autorskich, zamkniętych protokołów szyfrowania, dostępność minimum jednego standardowego protokołu (np. WireGuard lub OpenVPN), możliwość integracji z firmowym systemem zarządzania tożsamością.

Jeśli „minimum bezpieczeństwa” zostanie spisane na początku, presja czasu lub ceny nie zepchnie go na dalszy plan. Jeśli nie zostanie ustalone, w praktyce tym minimum staje się oferta konkretnego sprzedawcy, który pierwszy złoży atrakcyjną propozycję cenową.

Jurysdykcja, własność i struktura firmy – fundament zaufania

Jurysdykcja dostawcy i sojusze wywiadowcze

Miejsce rejestracji dostawcy VPN oraz kraj, z którego faktycznie prowadzi działalność, ma bezpośredni wpływ na to, jakie służby i organy mogą żądać dostępu do danych. Dotyczy to nie tylko logów VPN, ale i danych billingowych, informacji o płatnościach czy korespondencji z supportem.

Szczególną uwagę wymagają kraje zaangażowane w porozumienia wywiadowcze, takie jak Five Eyes, Nine Eyes, Fourteen Eyes. W tych jurysdykcjach istnieją mechanizmy prawne ułatwiające wymianę informacji pomiędzy różnymi służbami, nie zawsze przejrzyście opisane i w pełni kontrolowane przez sądy cywilne.

Nie oznacza to automatycznie, że każdy dostawca VPN z siedzibą w kraju „Five Eyes” jest niewiarygodny. Oznacza jednak, że w audycie bezpieczeństwa należy uwzględnić scenariusz, w którym dostawca jest prawnie zobowiązany do współpracy z organami ścigania i służbami w sposób, o którym klient może nie zostać poinformowany.

Jeśli dostawca VPN nie podaje wprost kraju rejestracji, albo używa ogólnikowych sformułowań („działamy globalnie”, „siedziba w Unii Europejskiej”), to silny sygnał ostrzegawczy. Jeśli przedstawia konkretne informacje o jurysdykcji, mechanizmach prawnych i sposobie, w jaki reaguje na wnioski organów, ryzyko jest łatwiejsze do oszacowania.

Struktura własnościowa i przejęcia

Dostawca VPN to nie tylko nazwa marki. To także struktura właścicielska: spółka matka, powiązania kapitałowe, fundusze inwestycyjne, potencjalne przejęcia. W kontekście bezpieczeństwa istotne są pytania:

• Kto faktycznie kontroluje spółkę (osoby fizyczne, fundusz private equity, inna korporacja technologiczna)?
• Czy dostawca VPN nie jest jednym z wielu produktów dużego holdingu, którego głównym celem jest agresywny wzrost przychodów?
• Czy w ostatnich latach dochodziło do przejęć lub fuzji, które mogły zmienić kulturę bezpieczeństwa i priorytety biznesowe?

Transparentność, audyty zewnętrzne i historia incydentów

Warstwa prawna i właścicielska to dopiero początek oceny zaufania. Drugi wymiar to transparentność techniczna i operacyjna. Dostawca VPN, który faktycznie stawia na bezpieczeństwo, zwykle:

• publikuje niezależne audyty bezpieczeństwa (kodu, infrastruktury, polityki logów) wraz z nazwą audytora i zakresem prac,
• udostępnia raporty z testów penetracyjnych przynajmniej w formie streszczenia (executive summary) dla klientów biznesowych,
• prowadzi program bug bounty lub formalny kanał zgłaszania podatności,
• komunikuje otwarcie historię incydentów bezpieczeństwa – co się stało, jak zareagowano, jakie korekty wdrożono.

Brak jakichkolwiek informacji o audytach zewnętrznych, przy jednoczesnym agresywnym marketingu „najbezpieczniejszy VPN na świecie”, to silny sygnał ostrzegawczy. Z drugiej strony, dostawca, który przyznaje się do incydentu sprzed kilku lat i pokazuje konkretne działania naprawcze, zwykle ma dojrzałą kulturę bezpieczeństwa.

Jeśli w dokumentacji i rozmowach handlowych widzisz konkrety: nazwy firm audytorskich, daty, zakres, wnioski – poziom zaufania rośnie. Jeśli odpowiedzi ograniczają się do ogólników („regularnie się audytujemy”), ryzyko, że audyt pełni funkcję marketingową, a nie kontrolną, jest wyższe.

Segmentacja biznesu i konflikty interesów

Coraz częściej VPN jest elementem większego ekosystemu: pakietów „security suite”, usług proxy, platform reklamowych. Z punktu widzenia bezpieczeństwa kluczowe są pytania:

• czy dostawca VPN nie prowadzi równolegle działalności, która zarabia na monetyzacji danych użytkowników (np. usługi reklamowe, analityka ruchu),
• czy istnieje jasna separacja danych pomiędzy poszczególnymi liniami biznesowymi w obrębie tej samej grupy kapitałowej,
• czy w umowie wprost zapisano zakaz wykorzystywania danych o ruchu VPN do celów innych niż realizacja usługi (np. research marketingowy, statystyki publiczne).

Jeśli ten sam holding jest właścicielem popularnych wtyczek do przeglądarki zbierających dane o ruchu oraz „bezlogowego” VPN, poziom sceptycyzmu powinien automatycznie wzrosnąć. Jeśli VPN jest jedyną lub kluczową linią biznesową, konflikt interesów jest mniejszy, ale nadal wymagane są jasne zapisy umowne.

Jeżeli po analizie struktury grupy kapitałowej nie jesteś w stanie jednoznacznie odpowiedzieć, kto ma dostęp do danych twojej firmy, kryterium zaufania nie jest spełnione. Jeżeli dostawca pokazuje strukturę, mapę przepływu danych i formalne bariery (chińskie mury) – masz punkt kontrolny zaliczony.

Wpływ jurysdykcji klientów i podwykonawców

Oprócz kraju rejestracji liczy się również to, gdzie znajdują się kluczowi podwykonawcy i z jakich krajów pochodzą inni klienci dostawcy. W praktyce oznacza to konieczność zadania kilku niewygodnych pytań:

• czy dostawca korzysta z zewnętrznych centrów danych lub chmury publicznej (AWS, GCP, Azure) w krajach o podwyższonym ryzyku prawnym,
• czy dane administracyjne (billing, CRM, helpdesk) są przetwarzane w krajach spoza UE/EOG i na jakiej podstawie prawnej,
• czy dostawca obsługuje klientów z sektorów wysokiego zainteresowania wywiadowczego (np. organizacje polityczne, branża obronna) i jak to wpływa na częstotliwość wniosków ze strony służb.

Dostawca, który potrafi przedstawić mapę swoich podwykonawców oraz lokalizację przetwarzania danych w ustrukturyzowany sposób, ułatwia realną ocenę ryzyka. Brak przejrzystości oznacza, że audytujący musi „domyślać się” łańcucha przetwarzania, co dla świadomej organizacji powinno być nieakceptowalne.

Jeśli po rozmowach z dostawcą wiesz, w jakich krajach fizycznie i prawnie „dotykane” są dane twojej firmy, możesz wpisać to w matrycę ryzyka. Jeśli lista krajów i podmiotów zmienia się dynamicznie i bez powiadomień, kontrola nad ryzykiem staje się iluzoryczna.

Polityka logowania i dane przetwarzane przez dostawcę VPN

Marketing „no‑logs” vs. faktyczne dane operacyjne

Sformułowanie „no‑logs” stało się hasłem marketingowym, za którym często nie stoi precyzyjna definicja. Z perspektywy audytu należy precyzyjnie dopytać, jakie dokładnie kategorie danych są lub nie są przechowywane. Kluczowe pytania to:

• czy przechowywane są adresy IP użytkowników (wejściowe, wyjściowe) i przez jaki czas,
• czy logowany jest czas rozpoczęcia i zakończenia sesji, ilość przesłanych danych, identyfikator urządzenia,
• czy jakiekolwiek logi aplikacyjne mogą zostać powiązane z konkretnym użytkownikiem lub firmą (np. identyfikatory subskrypcji).

Z praktyki: w projekcie dla średniej firmy technologicznej okazało się, że dostawca „no‑logs” gromadził szczegółowe logi po stronie serwera RADIUS, które pozwalały odtworzyć historię połączeń konkretnych pracowników. Nie było to wymienione w publicznej polityce prywatności, lecz wynikało z użytej architektury uwierzytelniania.

Jeżeli polityka logów zawiera tabelaryczne zestawienie: „dane – cel – czas retencji – podstawa prawna – miejsce przechowywania”, masz bazę do realnej oceny. Jeżeli polityka ogranicza się do zdania „nie przechowujemy logów”, bez rozbicia na kategorie, ryzyko błędnej interpretacji jest wysokie.

Minimalizacja danych i czas retencji

Kolejny punkt kontrolny to stopień minimalizacji danych. Dostawca VPN potrzebuje pewnych informacji do działania usługi (np. metadane sesji dla bilingu czy wykrywania nadużyć), ale ich zakres i czas przechowywania musi być ograniczony do minimum. Warto zweryfikować:

• jak długo przechowywane są metadane połączeń (godziny, wolumen ruchu, błędy),
• czy czas retencji jest konfigurowalny dla klienta biznesowego,
• czy istnieją automatyczne mechanizmy anonimizacji lub agregacji danych po określonym czasie,
• czy dane techniczne wykorzystywane do monitoringu i SLA są przechowywane w sposób zdepersonalizowany względem konkretnych użytkowników.

Jeżeli dostawca deklaruje, że „dla bezpieczeństwa” przechowuje pełne logi sesji przez nieograniczony czas, jest to jaskrawy sygnał ostrzegawczy. Jeżeli retencja jest ograniczona, opisano ją w umowie i można ją modyfikować – oznacza to, że projektowano usługę z myślą o prywatności i compliance.

Jeśli potrafisz na etapie audytu wskazać konkretne parametry retencji i anonimizacji w umowie, możesz świadomie zdecydować, czy poziom ryzyka jest akceptowalny. Jeśli parametry retencji pozostają „kwestią operacyjną dostawcy”, oddajesz mu zbyt dużo kontroli.

Dane identyfikacyjne, płatnicze i obsługa kont firmowych

Nawet jeśli ruch VPN nie jest logowany, dostawca przetwarza inne dane: dane kontaktowe administratorów, informacje o strukturze firmy, szczegóły płatności. W audycie należy sprawdzić:

• jakie dane identyfikacyjne wymagane są dla konta firmowego (imię, nazwisko, numer telefonu, stanowisko, dane rozliczeniowe),
• czy dane płatnicze są przechowywane u dostawcy VPN czy wyłącznie u zewnętrznego procesora płatności,
• jak zabezpieczone są panele administracyjne, listy użytkowników, tokeny dostępowe,
• czy dostawca dopuszcza modele płatności ograniczające ekspozycję danych (np. rozliczenia zbiorcze, faktury pro forma).

Z perspektywy RODO i ochrony tajemnicy przedsiębiorstwa istotne jest również, czy dostawca używa danych kontaktowych administratorów i użytkowników do własnego marketingu. Zapisy „możemy wykorzystywać dane kontaktowe do komunikacji handlowej partnerów” powinny od razu zapalić lampkę ostrzegawczą.

Jeżeli wiesz, jakie dane identyfikacyjne i płatnicze znajdą się w systemach dostawcy i jak są odseparowane od danych o ruchu, możesz je objąć własną matrycą ryzyka. Jeżeli całość jest zaszyta w jednym nieprzejrzystym systemie CRM dostawcy, identyfikacja luk jest praktycznie niemożliwa.

Udostępnianie danych stronom trzecim i odpowiedzi na wnioski organów

Ostatni filar polityki logów to zasady udostępniania danych. Warto domagać się nie tylko ogólnych deklaracji, ale również konkretnych procedur i przykładów. Pytania kontrolne:

• czy dostawca publikuje raport przejrzystości (transparency report) z informacją o liczbie wniosków organów i sposobie ich obsługi,
• czy istnieje formalna procedura kwestionowania zbyt szerokich wniosków oraz czy klient jest informowany, o ile prawo na to pozwala,
• czy dane mogą być udostępniane partnerom technologicznym (np. dostawcom usług anty‑DDoS, CDN, SIEM) i w jakim zakresie,
• czy dane mogą być wykorzystywane do tworzenia raportów zbiorczych (np. statystyki ruchu), nawet jeśli mają być „anonimowe”.

Praktyka pokazuje, że wiele „anonimowych” zbiorów danych można w pewnych warunkach zrekonstruować lub powiązać z konkretnymi organizacjami. Dlatego zapisy o wykorzystywaniu danych do celów statystycznych wymagają szczególnie krytycznego spojrzenia.

Jeżeli dostawca prezentuje jasne procedury, raporty przejrzystości i konkretne przykłady ograniczania zakresu udostępnianych danych, podnosi to poziom zaufania. Jeżeli jedyną odpowiedzią jest „działamy zgodnie z prawem kraju X”, nie masz realnej kontroli nad tym, co stanie się z logami i metadanymi twojej organizacji.

Architektura bezpieczeństwa i szyfrowania – co jest minimum

Wybór protokołów i unikanie „własnej kryptografii”

Fundamentem technicznego bezpieczeństwa VPN jest dobór protokołów i algorytmów szyfrowania. Z perspektywy audytu ryzykowne są wszelkie autorskie, słabo udokumentowane rozwiązania, które nie przeszły lat testów w społeczności specjalistów. Kryteria bazowe:

• obsługa nowoczesnych, szeroko audytowanych protokołów (np. WireGuard, IKEv2/IPsec, OpenVPN),
• brak wymuszenia autorskich protokołów, działających jako „czarna skrzynka” bez publicznej specyfikacji,
• wymuszenie minimalnych wersji TLS (np. TLS 1.2/1.3) oraz zakaz używania przestarzałych protokołów (PPTP, L2TP bez IPsec),
• stosowanie silnych, aktualnych zestawów szyfrów (np. AES‑GCM, ChaCha20‑Poly1305) z odpowiednią długością klucza.

Dostawca, który promuje własny protokół jako „szybszy i bezpieczniejszy”, ale nie potrafi wskazać publicznej dokumentacji i audytów, stwarza istotne ryzyko. Bez przejrzystości nie ma możliwości niezależnej oceny bezpieczeństwa.

Jeżeli w ofercie znajdują się co najmniej dwa standardowe protokoły i możesz zrezygnować z autorskiego, masz elastyczność architektoniczną. Jeżeli jesteś „zamykany” na jedyną słuszną implementację, uzależniasz bezpieczeństwo od wiary w kompetencje jednego dostawcy.

Zarządzanie kluczami i Perfect Forward Secrecy

Następny punkt kontrolny to zarządzanie kluczami kryptograficznymi. Nawet najlepszy algorytm nie pomoże, jeśli klucze są przechowywane w sposób niebezpieczny lub współdzielone między wieloma klientami. Kryteria do weryfikacji:

• czy stosowana jest Perfect Forward Secrecy (PFS), czyli mechanizmy uniemożliwiające odszyfrowanie historycznego ruchu po kompromitacji klucza długoterminowego,
• jak często dochodzi do rotacji kluczy sesyjnych i certyfikatów serwerów,
• czy klucze prywatne serwerów VPN są przechowywane w hardware security modules (HSM) lub innej formie izolacji sprzętowej,
• czy klient ma możliwość korzystania z własnej infrastruktury kluczy (BYOK, własne CA) w scenariuszach korporacyjnych.

W praktyce niewiele firm dokładnie dopytuje o PFS, a tymczasem jest to jeden z głównych buforów bezpieczeństwa przy założeniu, że prędzej czy później ktoś klucze wykradnie lub wymusi ich wydanie. Brak PFS oznacza, że kompromitacja jednego klucza może otworzyć przeszłe miesiące ruchu.

Mechanizmy ochrony przed wyciekami i kontrola ścieżki ruchu

Sam tunel VPN nie wystarczy, jeśli część ruchu „ucieka” poza niego lub przechodzi przez infrastrukturę, nad którą nie masz żadnej kontroli. Dlatego jednym z punktów kontrolnych w audycie jest sposób, w jaki dostawca projektuje i wymusza ścieżkę ruchu.

• Ochrona przed wyciekami DNS (DNS leak protection) – zapytania DNS powinny być kierowane przez tunel do zaufanych resolverów (dostawcy lub własnych, korporacyjnych), a nie do domyślnych serwerów operatora internetowego.
• Kontrola trasy dla IPv6 – wiele usług „rozwiązuje problem” wyłączając IPv6. To obejście, nie rozwiązanie. Lepszym scenariuszem jest pełne wsparcie IPv6 w tunelu, aby uniknąć ruchu poza VPN.
• Split‑tunneling z zasadami – jeśli dostawca oferuje split‑tunneling, sprawdź, czy można go definiować centralnie (po stronie administratora), a nie w gestii użytkownika. Brak centralnej polityki to ryzyko wycieku krytycznych aplikacji poza tunel.
• Filtrowanie ruchu na brzegu – możliwość stosowania reguł firewall/SWG na poziomie serwera VPN (np. blokada ruchu do nieautoryzowanych krajów, portów, kategorii stron).

Jeżeli dostawca pokazuje przejrzystą konfigurację DNS, IPv6 i split‑tunnelingu oraz umożliwia centralne wymuszenie polityk, controllujesz faktyczną ścieżkę ruchu. Jeżeli odpowiedź brzmi „aplikacja klienta to załatwia automatycznie”, licz się z tym, że w praktyce część pakietów popłynie poza tunel.

Bezpieczeństwo klienta VPN: aplikacje, aktualizacje, integracje

Klient VPN instalowany na stacjach roboczych i urządzeniach mobilnych jest równie krytyczny jak sama infrastruktura serwerowa. To tam dochodzi do uwierzytelnienia, zestawienia tunelu i lokalnego egzekwowania polityk.

• Model dystrybucji i aktualizacji – czy aplikacje są dystrybuowane z zaufanych repozytoriów (App Store, Google Play, MDM) i czy proces aktualizacji jest podpisany kryptograficznie, z weryfikacją integralności.
• Obsługa systemów MDM/EMM – w środowisku firmowym minimum to możliwość cichej instalacji, aktualizacji i wymuszania konfiguracji przez MDM, bez potrzeby interakcji użytkownika.
• Izolacja konfiguracji – czy użytkownik może samodzielnie modyfikować krytyczne parametry (serwer, protokół, split‑tunneling), czy są one blokowane i zarządzane centralnie.
• Uprawnienia aplikacji mobilnych – warto sprawdzić, czy aplikacja nie żąda nadmiernych uprawnień (dostęp do kontaktów, lokalizacji, pamięci), które nie są niezbędne do działania VPN.
• Otwarty kod klienta lub niezależne audyty – klient open‑source lub przynajmniej regularnie audytowany przez zewnętrzne podmioty daje wyższy poziom przejrzystości.

Jeśli klient VPN jest projektowany pod zarządzanie korporacyjne (MDM, centralne profile, ograniczenia uprawnień), da się go włączyć w istniejący łańcuch bezpieczeństwa. Jeśli cała kontrola sprowadza się do „kliknięć” użytkownika, powstaje luka między polityką na papierze a rzeczywistą konfiguracją urządzeń.

Funkcje odporności na błędy: kill switch i scenariusze awaryjne

Nawet najlepiej zaprojektowana infrastruktura miewa awarie, a kluczowe jest zachowanie klienta i serwera w takich momentach. W audycie trzeba zwrócić uwagę, co dzieje się z ruchem w przypadku utraty połączenia VPN.

• Systemowy kill switch – rozwiązania, które zatrzymują cały ruch sieciowy, jeśli tunel VPN przestaje działać, powinny funkcjonować na poziomie systemowego firewalla, a nie wyłącznie w logice aplikacji.
• Tryby awaryjne – czy administrator może zdefiniować reguły: co ma się stać, jeśli nie uda się zestawić tunelu (np. blokada całego ruchu vs. ograniczony dostęp do wybranych zasobów).
• Automatyczne przełączanie między serwerami – mechanizmy failover (np. lista priorytetowa serwerów, zdrowie endpointów) powinny działać bez udziału użytkownika.
• Raportowanie zdarzeń awaryjnych – sposób, w jaki informacja o zerwaniach tunelu, failoverach i zadziałaniu kill switcha trafia do centralnych systemów logowania (SIEM, SOC).

Jeśli w testach awaryjnych ruch jest natychmiast blokowany, a zdarzenie dobrze widoczne w logach, masz realny bufor bezpieczeństwa. Jeśli po utracie połączenia VPN system płynnie przechodzi „na internet lokalny”, masz tylko iluzję ochrony.

Segmentacja ruchu i integracja z istniejącą architekturą sieci

VPN biznesowy nie może być „czarnym tunelem” w oderwaniu od reszty architektury. Ruch wchodzący i wychodzący z tunelu musi dać się sensownie wpiąć w istniejące segmenty sieci, WAF, IDS/IPS czy proxy.

• Możliwość definiowania wielu bram VPN – odrębne klastry dla różnych środowisk (produkcyjne, testowe, partnerskie) ograniczają skutki ewentualnego kompromisu.
• Integracja z korporacyjnym firewallem – czy serwery VPN mogą działać jako strefa DMZ z pełną inspekcją ruchu, zamiast być „wyspą” poza głównym firewallem.
• Obsługa trasowania opartą o polityki (policy‑based routing) – możliwość kierowania różnych grup użytkowników do innych segmentów sieci wewnętrznej na podstawie ról lub grup w katalogu.
• Rejestrowanie ruchu na styku tunelu – logowanie zdarzeń na poziomie sieci wewnętrznej (np. NetFlow, IDS), przy jednoczesnym poszanowaniu polityki „no‑logs” po stronie dostawcy.

Jeśli dostawca dopuszcza granularną segmentację i integrację z Twoją architekturą (firewalle, IDS, NAC), VPN staje się przewidywalnym elementem całości. Jeśli jedyne, co oferuje, to „jeden globalny tunel dla wszystkich”, każdy incydent będzie trudny do opanowania i analizy.

Infrastruktura serwerowa, lokalizacje i zarządzanie sprzętem

Model własności infrastruktury: serwery własne vs. kolokacja vs. chmura

To, gdzie fizycznie działają serwery VPN i kto je kontroluje, ma bezpośredni wpływ na ryzyko dla danych. Transparentny model infrastruktury to jeden z pierwszych elementów, które warto rozpisać w audycie.

• Serwery własne (bare metal) – pełna kontrola nad sprzętem, oprogramowaniem, łańcuchem dostaw komponentów. Wyższy koszt, ale niższe ryzyko współdzielonych środowisk.
• Kolokacja w zewnętrznych centrach danych – istotne są umowy z operatorem DC (SLA, fizyczne bezpieczeństwo, zakres uprawnień personelu DC do sprzętu klienta).
• Infrastruktura chmurowa (IaaS) – elastyczność i szybkość skalowania kosztem dodatkowej warstwy zaufania do dostawcy chmury. Wymaga weryfikacji, jak zapobiega się dostępowi hypervisora do pamięci maszyny i jak obsługiwane są snapshoty.
• Modele mieszane – częsty scenariusz: kluczowe lokalizacje na sprzęcie własnym, peryferyjne regiony (egzotyczne kraje) w chmurze. W takim przypadku trzeba rozróżnić profile ryzyka między regionami.

Jeżeli dostawca jest w stanie pokazać jasny podział: które lokalizacje działają na serwerach własnych, a które w chmurze, oraz jakie różnice w politykach z tego wynikają, możesz świadomie zarządzać trasami ruchu. Jeśli odpowiedź brzmi „to konfiguracja operacyjna, której nie ujawniamy”, akceptujesz nieznane ryzyko.

Bezpieczeństwo centrów danych i fizyczna kontrola dostępu

Fizyczne bezpieczeństwo serwerów VPN często jest traktowane po macoszemu, choć kompromitacja w tym obszarze może unieważnić resztę środków technicznych. Punkt kontrolny to zarówno standardy, jak i praktyka operacyjna.

• Certyfikacje DC – poziomy Tier, ISO 27001, SOC 1/2/3. Sam certyfikat nie jest gwarancją, ale informacją o minimum procesowym.
• Kontrola dostępu – czy dostęp do szaf z serwerami VPN jest ograniczony do personelu dostawcy VPN, czy także personel DC może wchodzić do szaf bez nadzoru.
• Monitoring i rejestr zdarzeń fizycznych – zapisy wejść/wyjść, monitoring wideo, procedury reagowania na nieautoryzowane próby dostępu.
• Procedury ingerencji serwisowej – kto i na jakich zasadach może fizycznie dotknąć serwera (wymiana dysku, karty sieciowej), oraz jak dokumentowane są takie działania.

Jeśli dostawca potrafi pokazać, że serwery VPN są fizycznie odseparowane, a działania personelu DC są ściśle kontrolowane i logowane, masz mocniejszy fundament zaufania. Jeśli natomiast „lokalne wsparcie techniczne” ma swobodę pracy na serwerach, rośnie ryzyko nieautoryzowanej ingerencji.

Zarządzanie dyskami, szyfrowanie i operacje serwisowe

Wielu dostawców deklaruje „brak danych na dysku”, ale w praktyce działają logi systemowe, swap, cache i różne pliki tymczasowe. Trzeba sprawdzić, jak to wygląda operacyjnie.

• Szyfrowanie dysków – czy wszystkie dyski (w tym hot‑spare, dyski w RAID) są szyfrowane na poziomie sprzętowym lub programowym, oraz jak zarządzane są klucze.
• Serwery bezdyskowe lub RAM‑only – część dostawców stosuje systemy działające wyłącznie w pamięci (ramdisk, boot z sieci). To znacząco ogranicza ślad danych na nośnikach trwałych.
• Procedury wycofywania i utylizacji dysków – czy istnieje formalna procedura niszczenia lub bezpiecznego zerowania dysków oraz czy dostawca może to audytowo udokumentować.
• Snapshoty i backupy – jeśli infrastruktura korzysta z wirtualizacji lub chmury, trzeba zweryfikować, czy snapshoty nie przechowują wrażliwych danych (kluczy, logów) poza kontrolą dostawcy VPN.

Jeśli konfiguracja serwerów ogranicza zapis danych na dysk, a utylizacja nośników jest udokumentowana i powiązana z szyfrowaniem, ryzyko wyniesienia danych fizycznie spada. Jeśli natomiast na serwerze działa pełny system z wieloma usługami, logami i snapshotami, zapewnienie „no‑logs” ma niewielkie przełożenie na rzeczywistość.

Topologia sieci i redundancja: SLA, przepustowość, scenariusze awarii

VPN musi wytrzymać nie tylko ataki, ale też zwykłe obciążenie biznesowe i awarie łączy. Z perspektywy CEO ważne są SLA i ciągłość działania, z perspektywy IT – topologia i mechanizmy redundancji.

• Geograficzna redundancja – czy kluczowe regiony mają wiele punktów obecności (PoP) i czy ruch może być automatycznie przekierowany w przypadku awarii jednego z nich.
• Łącza do operatorów – bezpośrednie peeringi z głównymi operatorami i węzłami wymiany ruchu (IX) zmniejszają opóźnienia i ryzyko przeciążeń.
• Monitoring wydajności – publiczne lub udostępniane klientom wskaźniki obciążenia, opóźnień i dostępności, najlepiej w formie panelu statusowego.
• SLA obejmujące bezpieczeństwo – nie tylko „uptime”, ale też czasy reakcji na incydenty bezpieczeństwa, ataki DDoS, nieautoryzowany dostęp do infrastruktury.

Jeśli dostawca realnie pokazuje topologię, redundancję i parametry wydajności, da się ocenić, czy infrastruktura utrzyma Twoje obciążenie i profil ryzyka. Jeśli oferta ogranicza się do ogólnego „wysoka dostępność, niskie ping”, przygotuj się na niespodzianki przy wdrożeniu.

Modele „wirtualnych lokalizacji” i zgodność z wymaganiami prawnymi

Coraz częściej pojawiają się tzw. wirtualne lokalizacje – serwer logicznie przypisany do danego kraju, ale fizycznie działający w innym. Z punktu widzenia zgodności z prawem i kontraktów z klientami taki model wymaga szczególnej uwagi.

• Jasne oznaczenie wirtualnych lokalizacji – klient powinien móc łatwo sprawdzić, które lokalizacje są „wirtualne”, a które odpowiadają faktycznemu położeniu serwera.
• Jurysdykcja a routing – nawet jeśli adres IP wskazuje na kraj A, realna jurysdykcja może być krajem B, gdzie stoi sprzęt. To ma znaczenie przy regulacjach dotyczących miejsca przetwarzania danych.
• Polityki dla danych wrażliwych – w wielu branżach (finanse, sektor publiczny) istnieją wymogi co do fizycznej lokalizacji danych. Model wirtualnych lokalizacji może je naruszać, jeśli nie jest właściwie zarządzany.
• Konfiguracja tras dla klientów biznesowych – istotne jest, czy możesz wymusić użycie wyłącznie „fizycznych” lokalizacji lub konkretnych krajów, zgodnie z Twoją polityką i wymogami kontraktowymi.

Jeśli dostawca potrafi precyzyjnie wskazać, gdzie fizycznie znajduje się sprzęt powiązany z daną lokalizacją logiczną i daje narzędzia do kontroli tras, da się to spiąć z regulacjami i polityką DLP. Jeśli wirtualne lokalizacje są ukryte lub opisane zdawkowo, ryzyko naruszeń zgodności rośnie wykładniczo.

Najczęściej zadawane pytania (FAQ)

Jak ocenić, czy dostawca VPN jest wystarczająco bezpieczny dla mojej firmy?

Podstawowy punkt kontrolny to spojrzenie poza listę funkcji z ulotki marketingowej. Sprawdź, jakie protokoły i standardy szyfrowania są stosowane, jak rozwiązany jest podział na role i uprawnienia administratorów oraz czy VPN integruje się z Twoim systemem tożsamości (AD, Azure AD, Okta, itp.). Minimum to nowoczesne protokoły (np. IKEv2/IPsec, WireGuard, TLS 1.2+), silne szyfrowanie oraz możliwość centralnego zarządzania dostępem.

Kolejny obszar to procesy: zarządzanie podatnościami, cykl aktualizacji, procedury reagowania na incydenty i rotacji kluczy kryptograficznych. Jeżeli dostawca jest w stanie pokazać udokumentowane procedury, raporty z testów penetracyjnych i opisać proces obsługi incydentu krok po kroku, zaufanie rośnie. Jeśli na pytania o procesy odpowiada ogólnikami i odsyła do strony marketingowej – to silny sygnał ostrzegawczy.

Jeśli po rozmowie z dostawcą rozumiesz, jak wygląda jego „fabryka bezpieczeństwa” (technologia + proces + ludzie), to jesteś na dobrej drodze. Jeśli widzisz tylko kolorową listę funkcji i brak konkretów – ryzyko jest zbyt wysokie.

Na co powinien zwrócić uwagę CEO przy wyborze dostawcy VPN, a na co dział IT?

CEO patrzy przede wszystkim na wpływ na biznes. Kluczowe kryteria to: stabilność usługi (SLA, historia awarii), przewidywalny koszt całkowity (licencje, wdrożenie, utrzymanie), możliwość skalowania wraz ze wzrostem firmy oraz zgodność z wymaganiami klientów i regulatorów. Minimum dla zarządu to jasne zapisy w umowie: parametry SLA, odpowiedzialność za incydenty, czas wypowiedzenia i dostępność wsparcia 24/7, jeśli VPN jest krytyczny dla działalności.

Dla IT punktem kontrolnym jest poziom techniczny: protokoły i szyfrowanie, integracja z istniejącą infrastrukturą (firewalle, SIEM, IAM), dostęp do logów i API, mechanizmy segmentacji dostępu (dostęp tylko do konkretnych systemów, nie całej sieci). IT weryfikuje też, czy narzędzie da się automatyzować (IaC, skrypty) i czy produkt nie zamyka drogi do własnej konfiguracji polityk bezpieczeństwa.

Jeśli wybór VPN uwzględnia zarówno „minimum biznesowe” (SLA, koszty, warunki umowy), jak i „minimum techniczne” (szyfrowanie, logi, integracje), szansa na bezpieczną i trwałą współpracę jest wysoka. Jeśli dominuje tylko jedna perspektywa, kompromisy szybko wrócą w postaci incydentów lub nieprzewidzianych kosztów.

Jakie kryteria uwzględnić w arkuszu oceny dostawcy VPN?

Dobry arkusz oceny to lista kategorii, pod które każdy dział dopisuje swoje wymagania. W praktyce pojawiają się zwykle: bezpieczeństwo techniczne (protokoły, szyfrowanie, logowanie, zarządzanie kluczami, dodatkowe mechanizmy typu kill switch, ochrona przed wyciekiem DNS), aspekty prawne (jurysdykcja dostawcy, zgodność z RODO, klauzule dot. odpowiedzialności i współpracy z organami ścigania) oraz biznes/finanse (cena, model licencjonowania, TCO, warunki rezygnacji).

Do tego dochodzą operacje i utrzymanie: jakość i dostępność wsparcia technicznego, czas reakcji, poziomy eskalacji, dostępność dokumentacji i szkoleń. Dobrym zwyczajem jest przypisanie wagi do każdej kategorii oraz wyraźne oznaczenie punktów „must have”, które dyskwalifikują dostawcę, jeśli nie są spełnione.

Jeśli arkusz kryteriów jesteś w stanie wypełnić wspólnie (CEO/CFO, IT, bezpieczeństwo, prawo), decyzja będzie oparta na faktach, a nie „przeczuciu” po prezentacji handlowej. Jeśli brakuje choć jednej z tych perspektyw, pojawią się ślepe plamy – najczęściej w obszarze prawa lub bezpieczeństwa.

Czym różni się VPN konsumencki od rozwiązania VPN dla firmy?

VPN konsumencki jest projektowany głównie pod prywatność i omijanie geoblokad: nacisk jest na łatwą aplikację, dużą liczbę serwerów i atrakcyjny marketing. Takie usługi rzadko oferują granularną kontrolę dostępu, zaawansowane logowanie, integrację z systemami firmowymi czy gwarancje SLA na poziomie, który akceptuje biznes.

VPN dla firmy to element architektury bezpieczeństwa. Ma działać jako kontrolowana brama do zasobów wewnętrznych, spinać lokalizacje, partnerów i pracowników mobilnych, a równocześnie wpisywać się w polityki bezpieczeństwa, compliance i audyty klientów. Oczekuje się od niego segmentacji sieci, ścisłego powiązania z tożsamością użytkownika, raportowania do SIEM oraz jasno opisanych procesów reagowania na incydenty.

Jeśli Twoja firma używa „VPN-a z internetu” tylko dlatego, że jest tani i wygodny, to sygnał ostrzegawczy. Jeśli traktujesz VPN jak krytyczną infrastrukturę na równi z chmurą czy data center, kierunek jest właściwy.

Kto powinien brać udział w audycie i wyborze dostawcy VPN?

Minimum to reprezentanci czterech obszarów: zarząd (CEO/CFO), bezpieczeństwo (CISO lub osoba odpowiedzialna za security), IT/administratorzy oraz prawo/compliance. Zarząd określa akceptowalny poziom ryzyka i horyzont współpracy, bezpieczeństwo ocenia architekturę i procesy, IT sprawdza integrację i utrzymanie, a prawo analizuje umowę, jurysdykcję i ochronę danych.

W mniejszych firmach te role mogą łączyć się w jednej osobie, ale perspektywy nie mogą „zniknąć”. Ktoś musi zadać pytania o TCO, ktoś o konsekwencje prawne przechowywania logów, ktoś o integrację z obecnym firewallem. Brak choć jednej z tych perspektyw to klasyczny punkt, w którym później ujawniają się problemy – np. brak możliwości przejścia audytu klienta lub niekorzystne zapisy o odpowiedzialności za incydent.

Jeśli o wyborze VPN decyduje tylko administrator, ryzyko pominięcia aspektów prawnych i biznesowych jest bardzo wysokie. Jeśli decyzję podejmuje tylko zarząd na podstawie oferty handlowej, łatwo przepuścić poważne luki techniczne.

Jakie scenariusze użycia VPN trzeba zmapować przed wyborem dostawcy?

Kluczowe są cztery grupy scenariuszy: zdalny dostęp pracowników (home office, podróże, sieci publiczne), łączenie oddziałów i lokalizacji (site‑to‑site, połączenia z chmurą), dostęp partnerów i dostawców (serwis systemów, konsultanci, integratorzy) oraz ochrona pracowników mobilnych (sprzedaż w terenie, serwisanci, zarząd). Każdy z tych scenariuszy ma inne wymagania co do segmentacji, logowania i skalowalności.

Przykład z praktyki: VPN ustawiony „jednym tunelem dla wszystkich” może być wystarczający dla małego zespołu łączącego się z domów do jednego systemu. Gdy jednak kilkuset użytkowników i kilku dostawców ma przez ten sam VPN dostęp do wielu segmentów sieci, każdy błąd w politykach może otworzyć drogę do wrażliwych danych finansowych czy produkcyjnych.

Bibliografia

• NIST Special Publication 800-77: Guide to IPsec VPNs. National Institute of Standards and Technology (2024) – Wytyczne dot. projektowania i bezpieczeństwa IPsec VPN w organizacjach
• NIST Special Publication 800-113: Guide to SSL VPNs. National Institute of Standards and Technology (2008) – Charakterystyka SSL/TLS VPN, modele wdrożeń i ryzyka
• ISO/IEC 27001 Information security, cybersecurity and privacy protection — ISMS Requirements. International Organization for Standardization (2022) – Wymagania systemu zarządzania bezpieczeństwem, istotne przy ocenie dostawcy VPN
• ENISA Report: Cloud Security Guide for SMEs. European Union Agency for Cybersecurity (2021) – Praktyczne wskazówki oceny dostawców usług krytycznych i zarządzania ryzykiem
• CIS Controls v8. Center for Internet Security (2021) – Zestaw praktyk bezpieczeństwa, w tym zdalny dostęp i zarządzanie dostawcami
• OWASP Secure Configuration Guide. OWASP Foundation – Dobre praktyki bezpiecznej konfiguracji usług, w tym komponentów sieciowych
• SANS Whitepaper: Best Practices for Secure Remote Access. SANS Institute – Rekomendacje dla bezpiecznego zdalnego dostępu z użyciem VPN
• ACM Computing Surveys: A Survey on Virtual Private Network Technologies. Association for Computing Machinery (2019) – Przegląd technologii VPN, protokołów i modeli wdrożeniowych
• IT Governance and Information Security: Guides for CEOs and Boards. World Economic Forum (2015) – Perspektywa zarządu na ryzyko IT i kryteria oceny dostawców technologii
• Vendor Risk Management Maturity Model. Shared Assessments Program (2019) – Model dojrzałości zarządzania ryzykiem dostawców, przydatny przy audycie VPN