Může VPN log ukázat historii prohlížení? Co důkazy dokazují
Log relace, dotaz na resolver a záznam toku dokazují různé věci. Zvolte otázku, spojte identitu a čas a řekněte jen to, co bylo prokázáno.
Dvě auditní otázky znějí podobně a vyžadují různé druhy důkazů. Která relace kontaktovala tuto adresu, lze odpovědět ze záznamů spojení a toků. Která osoba otevřela tuto stránku, obvykle ne, alespoň ne z těchto záznamů. Volba sběrače před volbou otázky je způsob, jak síťový tým skončí tím, že jméno hostitele vydává za historii prohlížení.
Začněte událostí, kterou má audit prokázat
Napište otázku jako větu s podmětem, přísudkem a časem. Už tato disciplína odhalí mezeru mezi záznamem relace a zobrazením stránky. Log relace stanoví, že identita byla přijata na určitý interval s přidělenou adresou podle zaznamenané politiky, a nemůže stanovit, kterou stránku kdo četl, protože nikdy neviděl požadavek.
Pojmenujte pozorování dřív, než navrhnete sběr. Pole pojmenované po navštíveném webu, které ve skutečnosti ukládá přeložené jméno, je budoucí chyba, ne pohodlí. Názvy polí žijí déle než lidé, kteří je zvolili, proto vybírejte takové, které popisují důkaz, a ne závěr.
Co který záznam může a nemůže podpořit
V téměř každém auditním návrhu se objevují čtyři typy záznamů a každý odpovídá na jinou otázku. Držte je oddělené ve zprávě i v pipeline, protože jejich smícháním se obhajitelný nález stane trapným.
| The question being asked | Record that can answer it | What that record proves | What still needs a join |
|---|---|---|---|
| Was this address contacted? | Flow record | The connection five-tuple and when it was seen | Which session held the address at that moment |
| Which account held that address? | Session log | Which identity authenticated and the tunnel address it received | Which device or person used that account |
| Was this name looked up? | Resolver query | That this resolver was asked for this name | Whether a page was fetched, and by whom |
| Was this page viewed? | Proxy or application transaction | The request and identity recorded inside that application's scope | Traffic outside that application's visibility |
| Who was the person? | None of the four on its own | An account in use, at best | A named human, whenever accounts are shared |
Čtěte poslední sloupec stejně pečlivě jako prostřední. Záznam toku popisuje adresy a porty a reverzní dotaz na adresu nerekonstruuje jméno, které prohlížeč použil, protože jedna adresa může hostovat mnoho nesouvisejících webů. Dotaz na resolver dokazuje, že byla položena otázka, ne že byla zobrazena stránka. Ani jméno hostitele viditelné během vyjednávání TLS není cestou šifrovaného požadavku.
Každé z toho je skutečné pozorování a žádné není pozorováním, které lidé předpokládají. Prohlížeč, který trvá na vlastním šifrovaném resolveru, stojí mimo sledovaný rozsah a analýza nemůže obnovit to, co log nikdy neviděl. Tato mezera patří do zprávy jako deklarované omezení, ne jako poznámka pod čarou.
Předběžné dotazy a odpovědi z mezipaměti
Prohlížeče překládají jména předem, někdy vůbec nic nenačítají. Odpovídají také z mezipaměti, aniž by poslaly nový dotaz resolveru, který sledujete, což znamená, že absence dotazu není absence návštěvy. Obě chování boří naivní rovnici mezi DNS logem a historií prohlížení.
DNS přes HTTPS přidává druhou hranici: prohlížeč nebo hostující aplikace s vlastním resolverem se organizačního loggeru nikdy na nic neptá. Přesné transakce přicházejí jen z vlastních událostí aplikace nebo z proxy, jejíž logování výslovně podporujete. Obyčejný tunel HTTPS CONNECT nenechá proxy žádný pohled na cesty stránek uvnitř. Vlastnit síť není oprávnění tiše vyměnit model důvěry aplikace.
Adresa patří relaci, ne osobě
Záznam toku s adresou z tunelového rozsahu je výchozí bod, ne odpověď. Spojte tuto adresu a časové razítko s přiřazením relace aktivním v tu chvíli, protože tato adresa může být o hodinu později přiřazena jiné relaci. Statické adresování je jeden způsob, jak toto spojení udržet, a ne jediný.
Když krok překladu sloučí několik zařízení do jedné zdrojové adresy nad senzorem, spojení může pojmenovat jen sdílenou relaci brány. Sdílený účet nebo certifikát používaný více lidmi omezuje atribuci, ať síťová data vypadají jakkoli úplně. Obojí patří do zprávy jako omezení, ne jako upozornění na později.
Zaznamenejte časové pásmo, zdroj hodin, pozorovací bod a každou hranici překladu mezi nimi. Nepřítomnost si zaslouží stejnou péči jako přítomnost, protože chybějící záznam může znamenat, že záznam toku vypršel, že senzor paket nikdy neviděl nebo že log aplikace byl vypnutý.
Navrhněte pro deklarovaný účel, pak dokažte pipeline
Jakmile je otázka pevná, definujte, která pole jsou potřeba, kdo je smí číst a jak dlouho se uchovávají. Sbírat více, protože úložiště je levné, vytváří odpovědnost, která přežije vyšetřování. Model soukromí v RFC 6973 rámuje korelaci, chybnou atribuci a zbytečný sběr jako problémy návrhu, ne jako dodatečné myšlenky.
Chraňte mapování a záznamy jako jeden objekt, protože každé samo o sobě je mnohem méně citlivé než pár. Pak ověřte návrh proti aktivitě, kterou smíte generovat a už jí rozumíte, s nejmenším dotazem, na který se zpráva bude spoléhat. Pipeline, která nedokáže reprodukovat známou událost, nereprodukuje ani neznámou. Reportujte událost, kterou důkazy podporují, slovy, která důkazy dovolují, a nechte čtenáře, ať k většímu závěru dojde sám.
Napište omezení vedle nálezu: co bylo spojeno, co přeloženo a který log zůstal němý. Nález, který uvádí vlastní hranice, přežije revizi, kterou sebevědomé shrnutí nepřežije. To je rozdíl mezi důkazem a příběhem o důkazu.