Soukromé VPN a tvrzení o neuchovávání záznamů

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 odchozím serverem provozovatele VPN. Cílem je chránit metadata a obsah před poskytovatelem 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 (bezzáznamová) tvrzení – příslib, že služba „neuchovává žádné záznamy“ o vaší aktivitě.

Záznamy nejsou jen „historie webu“: typologie dat

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 se evidují:

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/servisu (např. chybová hlášení WireGuard/OpenVPN), výsledky autentizace, stav tunelu. Mohou být dočasné nebo trvalé.
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 účtu, platební tokeny, historie předplatného. Nejsou „síťové logy“, ale spojitelnost s účtem je důležitá.
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 reklamy) – pak je klíčové, jak jsou implementovány.

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

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

se nikdy nesbírají (např. zdrojová IP klienta na trvalé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ělené od síťové vrstvy.

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

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

Diskless/RAM-only serverové image: systémové partition v RAM (tmpfs) a neměnný 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 trvalých rotačních logů.
Efemérní klíče a Perfect Forward Secrecy: krátkodobé klíče (TLS-ECDHE, WireGuard s pravidelnou rekonekcí), aby zkompromitování klíče neodhalilo historickou komunikaci.
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á úroveň LogLevel v systemd-journald, anonymizace peer ID ve WireGuard managementu).
Automatické „wiping hooks“ při rotaci uzlů, pádech a aktualizacích – vymazání swapu, RAM a efemérního úložiště.

Jurisdikce a regulace: co může provozovatele přinutit vést záznamy

Právní prostředí má zásadní vliv. Je potřeba sledovat:

Uchovávání provozních dat (data retention): pokud země požaduje plošné uchovávání metadat, „no-log“ může být v konfliktu s právem.
Rozsah a tajnost příkazů: gag orders, nástroje typu „technical capability notices“ či national security letters mohou nařídit zavedení 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 kódu a procesů (např. posouzení konfigurace journald, OpenVPN/WireGuard, DNS, SIEM) – s veřejným reportem a popisem zjištění/výhrad.
Penetrační testy a red-team hodnocení, která zahrnují i snahy extrahovat logy z běžících uzlů a orchestrace.
Reprodukce buildu (reproducible builds) klientů a pokud možno i serverového image; hashované artefakty s ověřitelnými podpisy.
Případové důkazy (např. zajištění serveru, kde nebyly nalezeny žádné záznamy) jsou zajímavé, ale nikdy ne univerzální důkaz – mohly se týkat jiného data či uzlu.
Průběžné transparentní reporty (počet žádostí orgánů, kolik bylo vyhověno/odmítnuto, jestli došlo k reálnému 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 politik 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é a objemové vzory: 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 chybnou konfiguraci. Udržuje mapování veřejných klíčů na interní IP (peer mapping). Pokud se nesprávně spravuje (např. zapisuje stav do trvalého logu), může to oslabit „no-log“ přístup. OpenVPN má rozsáhlejší telemetrii a různé úrovně logování; správná politika vyžaduje vypnutí trvalých logů, omezení detailů a přísné rotace. V obou případech je důležitá politika logování orchestrace (systemd, Docker/Containerd, Kubernetes), protože právě ona může potichu uchovávat události na pozadí.

Platby, identita a oddělení dat

„No-log“ se často nevztahuje na účetnictví. Pro vyšší soukromí:

Oddělené identity: samostatný e-mail pouze pro VPN; nepoužívat firemní či školní účty.
Způsob platby: vliv na spojitelnost (platební karta vs. anonymní platby). Provozovatel 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 pro právní žádosti: co poskytovatel předá, když je žádán o spolupráci, a jaké má mechanismy, pokud logy nemá.
Dokumentovaná nemožnost cíleného logování bez změny infrastruktury: například jen s fyzickým zásahem a re-deployem podepsaného image.
Interní princip minimálních privilegií: aby jednotlivci neměli přístup k infrastruktuře, kde by mohli logy zapnout bez detekce (four-eyes princip, M of N podpisy).

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

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

Fingerprinting prohlížeče a cookies: ochrana vyžaduje zpevnění 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ícebodové sledování přesahují možnosti běžné VPN.

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

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

Požadavky a hrozby: definujte ohrožující subjekty (ISP, cloud provider, orgány činné v trestním řízení, konkurent, insider) a potřebu forenzní stopy vs. soukromí.
Dokumentace a architektura: vyžádejte detailní diagramy datových toků, konfigurace logování (journald, syslog, SIEM), politiky retence a mazání.
Důkazy: audity třetích stran, výsledky red teamů, SBOM klientů, podpisové klíče, postupy reprodukovatelných buildů.
Technické testy: vlastní měření DNS úniků, kontrola IPv6, WebRTC, behaviorální testy logování (např. generování chyb a sledování, zda se trvale ukládají).
Právní due diligence: analýza jurisdikce, smlouvy s colocation/cloud partnery, procesy při povinnostech cíleného logování.
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 realitou:

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í postupy pro uživatele.
Udržujte rozpočty logů rovné nule 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áno, které logy nevede, které vede dočasně a proč?
Existují aktuální audity a nejsou to jen marketingová tvrzení? Je dostupný kompletní report?
Běží servery diskless/RAM-only? Jaké jsou důkazy (fotografie racků, atestační podpisy, technické whitepapery)?
Má vlastní autoritatní DNS s nulovou retencí a řešené úniky (IPv6, WebRTC)?
Umožňuje multihop nebo rotaci exitů a má rozsáhlý IP pool?
Je klient open-source a podepsaný? Lze build reprodukovat?
Jaké jsou reakce na právní žádosti v minulosti? Existují zveřejněné precedenty?

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

Poskytovatelé balancují mezi soukromím uživatelů a prevencí zneužití. Odpovědný přístup zahrnuje jasné Podmínky použití, 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é log