Soukromé VPN a no-log tvrzení: ověřitelnost garancí a ochrana soukromí uživatelů

Co vlastně znamená „soukromá VPN“ a proč je důležitá

Soukromá VPN (virtuální privátní síť) je služba, která šifruje přenos mezi vaším zařízením a výstupním serverem provozovatele VPN. Cílem je chránit metadata a obsah před poskytovatelem internetového připojení, síťovou infrastrukturou a vybranými modely sledování. „Soukromá“ v praxi znamená, že operátor minimalizuje sběr dat, nevykonává komerční profilování a technicky omezuje možnost zpětné identifikace uživatele. Klíčovou součástí marketingu těchto služeb jsou no-log (bezlogové) tvrzení – příslib, že služba „neuchovává žádné záznamy“ o vaší aktivitě.

Logy nejsou jen „historie webu“: typologie údajů

Pojem „log“ je nadmnožinou mnoha dat. Při hodnocení tvrzení „no-log“ je důležité rozlišovat, jaké logy, na jak dlouho a za jakým účelem jsou evidovány:

  • Provozní metadata: čas připojení/odpojení, délka relace, IP adresa klienta, přidělená VPN IP, objem přenesených dat, chybové kódy. Často se používají k řešení incidentů a řízení kapacity.
  • Aplikační logy: zprávy klienta/daemonu (např. chybová hlášení WireGuard/OpenVPN), výsledky autentizace, stav tunelu. Mohou být dočasné nebo perzistentní.
  • Bezpečnostní události: detekce zneužití (DDoS, spam, port scanning), systémové události (SELinux/AppArmor), IDS/IPS záznamy.
  • Účetní údaje: fakturační údaje, e-mail konta, tokeny plateb, historie předplatného. Nejde o „síťové logy“, avšak spojitelnost s účtem je významná.
  • Síťový obsah: DNS požadavky, HTTP hlavičky, payloady. Soukromé VPN by je neměly ukládat ani inspektovat, s výjimkou explicitně aktivovaných filtrů (např. blok reklam) – pak je klíčové, jak jsou implementovány.

„No-log“ jako škála, nikoli binární stav

Absolutní „žádné logy“ je technicky a provozně nepravděpodobné. Reálná interpretace je škála od přísné minimalizace a krátkodobého, volatilního bufferování až po dlouhodobé perzistentní ukládání. Seriózní služby přesně definují, které údaje:

  • se nikdy nesbírají (např. zdrojová IP klienta na perzistentním úložišti),
  • se sbírají dočasně (v RAM, rotujících kruhových bufferech) a s jakým TTL,
  • se agregují/anonymizují (telemetrie výkonu bez identifikátorů),
  • se sbírají trvale z důvodů účetnictví a jsou právně odděleny od síťové vrstvy.

Technické architektury podporující minimální logování

Samo vyhlášení nestačí – rozhoduje implementace. Důležité prvky:

  • Diskless/RAM-only serverové image: systémové partitiony v RAM (tmpfs) a neměnitelný obraz (immutable), který se při restartu obnoví do čistého stavu.
  • Centrální syslog vypnutý nebo přesměrovaný do volatilních bufferů s velmi krátkou retencí a bez perzistentních rotačních logů.
  • Ephemeral klíče a Perfect Forward Secrecy: krátkodobě platné klíče (TLS-ECDHE, WireGuard s pravidelným rekey), aby kompromitace klíče neohrozila retrospektivní provoz.
  • Oddělení kontrolní a datové roviny: autentizace účtu probíhá mimo datové uzly (např. přes tokeny), aby servery neviděly identifikátory účtů.
  • Vlastní autoritativní DNS s nulovou retencí nebo DNS over TLS/HTTPS s lokální rekurzí a vypnutými debug logy.
  • Konfigurace WireGuard/OpenVPN tak, aby nevznikaly implicitní logy (např. vypnuté Log/Log-append v OpenVPN, vhodné LogLevel v systemd-journald, anonymizace peer ID ve WG managementu).
  • Automatické „wiping hooks“ při rotaci uzlů, crashích a aktualizacích – nulování swapu, RAM a ephemeral storage.

Jurisdikce a regulace: co může provozovatele donutit logovat

Právní prostředí má zásadní vliv. Je nutné sledovat:

  • Uchovávání provozních dat (data retention): pokud země vyžaduje plošné uchovávání metadat, „no-log“ může být v rozporu s právem.
  • Rozsah a tajnost příkazů: gag orders, nástroje typu „technical capability notices“ či national security letters mohou nařídit nasazení cíleného logování.
  • Extraterritorialita: nadnárodní působnost a dohody (MLAT) mohou rozšířit dosah orgánů mimo domovskou zemi provozovatele.
  • Struktura společnosti: holdingy v různých zemích, provoz serverů u třetích stran (colocation, cloud), smluvní podmínky poskytovatelů infrastruktury.

Audit, ověřitelnost a důkazní břemeno

Důvěryhodná „no-log“ tvrzení by měla být externě ověřitelná:

  • Nezávislé audity zdrojového kódu a procesů (např. posouzení konfigurace journald, OpenVPN/WireGuard, DNS, SIEM) – s veřejnou zprávou a popisem zjištění/výhrad.
  • Penetrační testy a red-team hodnocení, které pokrývají i snahy o extrakci logů z běžících uzlů a orchestrace.
  • Reprodukce buildu (reproducible builds) klientů a, pokud je to možné, i serverového image; hashované artefakty s ověřitelnými podpisy.
  • Případové důkazy (např. konfiskace serveru, kde nic nebylo nalezeno) jsou zajímavé, ale nikdy nejsou univerzálním důkazem – mohly se týkat jiného data či uzlu.
  • Průběžné transparentní reporty (počet žádostí orgánů, kolik splněných/odmítnutých, zda došlo k real-time logování a na jak dlouho).

DNS, IP pooly a riziko korelace

I bez logů lze provoz do určité míry korelovat:

  • Velikost a diverzita IP poolu: malé pooly usnadňují mapování uživatelů v čase; rotace a sdílené IP jsou vhodné proti profilování.
  • Vlastní vs. pronajaté AS: vlastní autonomní síť s kontrolou směrování a ROA/ROV politiky snižuje závislost na třetích stranách.
  • DNS otisky: používání společných resolverů s nulovou retencí a lokální rekurzí minimalizuje unikátnost dotazů.
  • Časování a vzory velikosti: proti korelaci pomáhá padding, multiplexing, v některých případech multihop nebo Decoy Routing (experimentálně).

WireGuard vs. OpenVPN: implikační rozdíly pro logování

WireGuard je štíhlejší, s menším prostorem pro chybovou konfiguraci. Udržuje mapování veřejných klíčů na interní IP (peer mapping). Pokud se spravuje neopatrně (např. zapisuje stav do perzistentního logu), může to oslabit „no-log“ přístup. OpenVPN má bohatší telemetrii a různé úrovně logování; správná politika vyžaduje vypnutí perzistentních logů, omezení detailů a striktní rotace. V obou případech je důležitá politika logování orchestrace (systemd, Docker/Containerd, Kubernetes), protože ta může tiše uchovávat události na pozadí.

Platby, identita a separace údajů

„No-log“ se často netýká účetnictví. Pro vyšší soukromí:

  • Oddělené identity: jiný e-mail jen pro VPN; nepoužívat firemní či školní účty.
  • Způsob platby: vliv na spojitelnost (platební karta vs. anonymizované platby). Operátor by měl oddělit fakturační systémy od provozní vrstvy.
  • Minimální telemetrie v klientech: vypínatelná diagnostika, žádné trvalé identifikátory, jasný seznam odesílaných polí.

Warrant canary, zákonné žádosti a reakční procesy

Warrant canary (pravidelně obnovované prohlášení, že poskytovatel nedostal tajný příkaz) může být užitečný signál, ale není právně závazný. Důležitější jsou:

  • Formální postup při právních žádostech: co poskytovatel předá, pokud je požádán o spolupráci, a jaké mechanismy má, pokud logy nemá.
  • Dokumentovaná nemožnost cíleného logování bez změny infrastruktury: např. pouze s fyzickým zásahem a redeployem signed image.
  • Interní princip minimálních privilegií: aby jednotlivci neměli přístup k infrastruktuře, kde by logy mohli zapnout bez detekce (four-eyes princip, M of N podpisy).

Limity VPN a falešná očekávání

VPN neřeší vše. Přehled hlavních limitů:

  • Fingerprinting prohlížeče a cookies: ochrana vyžaduje hardening prohlížeče, izolaci profilů a blokování trackerů.
  • Malware a kompromitované zařízení: pokud je endpoint napaden, VPN nepomůže.
  • Geolokační služby a mobilní identifikátory: aplikace mohou odesílat identifikátory, které VPN neodstraní.
  • Práce proti dobře financovaným aktérům: korelace na úrovni backbonu a vícenásobné sledování překračují možnosti běžné VPN.

Metodika hodnocení „no-log“ tvrzení pro organizace

Pokud organizace posuzuje VPN pro citlivé použití, doporučuje se formální metodika:

  1. Požadavky a hrozby: definujte hrozící subjekty (ISP, cloud provider, orgány činné v trestním řízení, konkurent, insider) a potřebu forenzní stopy vs. soukromí.
  2. Dokumentace a architektura: vyžádejte si detailní diagramy datových toků, konfigurace logování (journald, syslog, SIEM), politiky retence a mazání.
  3. Důkazy: audity třetích stran, výsledky red teamu, SBOM klientů, podpisové klíče, postupy reproducibilních buildů.
  4. Technické testy: vlastní měření DNS úniků, kontrola IPv6, WebRTC, behaviorální testy logování (např. generování chyb a sledování, zda se perzistentně ukládají).
  5. Právní due diligence: analýza jurisdikce, smlouvy s colocation/cloud partnery, procesy při příkazech na cílené logování.
  6. Operativa: rotační cykly serverů, patch management, detekce konfigurací mimo šablony (drift detection), přístupové politiky (JIT, PAM, audit trail).

Implementační doporučení pro provozovatele VPN

Pokud jste poskytovatel a chcete „no-log“ tvrzení podložit skutečností:

  • Navrhněte infra-as-code se stateless uzly a automatizovanou verifikací konfigurace (CIS benchmarky, vlastní OPA politiky).
  • Zaveďte kryptografické atestace serverů (např. TPM/SEV-SNP) a publikujte verifikační procedury pro uživatele.
  • Udržujte rozpočty logů nulové pro datovou rovinu; pro control-plane logy nastavte krátké TTL v RAM a formalizovaný důvod existence.
  • Oddělte telemetrii výkonu (agregovanou, bez identifikátorů) od jakýchkoli identifikovatelných metadat.
  • Zveřejňujte transparentní reporty, warrant canary a harmonogram nezávislých auditů.

Praktická kontrola pro jednotlivce: rychlý checklist

  • Má poskytovatel jasně specifikovány, které logy nevede, které vede dočasně a proč?
  • Existují aktuální audity a nejsou to jen marketingová tvrzení? Je dostupná plná zpráva?
  • Běží servery diskless/RAM-only? Jaké jsou důkazy (fotografie racků, atestační podpisy, technické whitepapery)?
  • Má vlastní autoritativní DNS s nulovou retencí a řešené úniky (IPv6, WebRTC)?
  • Umožňuje multihop nebo rotaci exitů a má široký IP pool?
  • Je klient open-source a podepsaný? Lze build reprodukovat?
  • Jaké jsou reakce na právní žádosti v minulosti? Existují zveřejněné precedentní případy?

Etické a regulační aspekty: „soukromí“ vs. zodpovědnost

Poskytovatelé balansují mezi soukromím uživatelů a prevencí zneužití. Zodpovědný přístup zahrnuje jasné Podmínky užívání, techniky vzdělávání uživatelů (např. o limitech VPN) a proporcionální síťové obrany proti zneužití, které nevyžadují plošné logování (např. rate limiting, reputa