Može li VPN dnevnik pokazati povijest pregledavanja? Što dokazi dokazuju
Dnevnik sesije, upit razrješivača i zapis toka dokazuju različite stvari. Odaberite pitanje, spojite identitet i vrijeme, pa navedite samo ono što je pokazano.
Dva revizijska pitanja zvuče slično i traže različite vrste dokaza. Na pitanje koja je sesija kontaktirala ovu adresu može se odgovoriti iz zapisa veza i tokova. Na pitanje koja je osoba otvorila ovu stranicu obično ne, barem ne iz tih zapisa. Odabir sakupljača prije odabira pitanja je način na koji mrežni tim završi tako što ime hosta predstavi kao historiju pregledanja.
Počnite od događaja koji revizija mora utvrditi
Napišite pitanje kao rečenicu sa subjektom, glagolom i vremenom. Sama ta disciplina otkriva jaz između zapisa sesije i pregleda stranice. Dnevnik sesije utvrđuje da je identitet prihvaćen na neki interval, s dodijeljenom adresom po zabilježenoj politici, i ne može utvrditi koju je stranicu iko čitao jer nikada nije vidio zahtjev.
Imenujte opažanje prije nego što dizajnirate prikupljanje. Polje nazvano po posjećenom sajtu koje zapravo čuva razriješeno ime je buduća greška, a ne pogodnost. Imena polja žive duže od ljudi koji su ih odabrali, zato birajte ona koja opisuju dokaz, a ne zaključak.
Šta svaki zapis može i ne može podržati
Četiri tipa zapisa pojavljuju se u gotovo svakom revizijskom dizajnu i svaki odgovara na drugo pitanje. Držite ih odvojeno u izvještaju kao i u obradi, jer njihovo miješanje pretvara odbranjiv nalaz u neugodan.
| 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 |
Pročitajte posljednju kolonu jednako pažljivo kao srednju. Zapis toka opisuje adrese i portove, a obrnuta pretraga adrese ne rekonstruiše ime koje je preglednik koristio, jer jedna adresa može hostovati mnogo nepovezanih sajtova. Upit razrješivača dokazuje da je pitanje postavljeno, a ne da je stranica prikazana. I ime hosta vidljivo tokom TLS pregovora nije putanja šifrovanog zahtjeva.
Svako od toga je stvarno opažanje i nijedno nije opažanje koje ljudi pretpostavljaju. Preglednik koji insistira na vlastitom šifrovanom razrješivaču nalazi se izvan nadziranog obuhvata, a analiza ne može povratiti ono što evidencija nikada nije vidjela. Taj jaz pripada izvještaju kao navedeno ograničenje, a ne kao fusnota.
Unaprijedni upiti i keširani odgovori
Preglednici razrješavaju imena unaprijed, ponekad bez ičega što bi uopšte učitali. Odgovaraju i iz keša bez slanja novog upita razrješivaču koji nadzirete, što znači da odsustvo upita nije odsustvo posjete. Oba ponašanja ruše naivnu jednačinu između DNS evidencije i historije pregledanja.
DNS preko HTTPS dodaje drugu granicu: preglednik ili gostujuća aplikacija s vlastitim razrješivačem nikada ništa ne pita evidenciju organizacije. Tačne transakcije dolaze samo iz događaja same aplikacije ili iz proxyja čiju evidenciju izričito podržavate. Običan tunel HTTPS CONNECT ostavlja proxy bez ikakvog uvida u putanje stranica unutar njega. Posjedovanje mreže nije dozvola da se tiho zamijeni model povjerenja aplikacije.
Adresa pripada sesiji, ne osobi
Zapis toka s adresom iz tunelskog opsega je početna tačka, a ne odgovor. Spojite tu adresu i vremensku oznaku s dodjelom sesije aktivnom u tom trenutku, jer ta adresa može sat kasnije biti dodijeljena drugoj sesiji. Statičko adresiranje je jedan način da se ta veza sačuva, ali ne jedini.
Kada korak prevođenja sabije nekoliko uređaja u jednu izvorišnu adresu uzvodno od senzora, spajanje može navesti samo zajedničku sesiju pristupnika. Dijeljeni račun ili certifikat koji koristi više ljudi ograničava pripisivanje koliko god mrežni podaci izgledali potpuni. Oboje pripada izvještaju kao ograničenja, a ne kao napomene za kasnije.
Zabilježite vremensku zonu, izvor sata, tačku posmatranja i svaku granicu prevođenja između njih. Odsustvo zaslužuje istu pažnju kao prisustvo, jer zapis koji nedostaje može značiti da je unos toka istekao, da senzor nikada nije vidio paket ili da je evidencija aplikacije bila isključena.
Dizajnirajte za navedenu svrhu, zatim dokažite tok obrade
Kada je pitanje fiksirano, definišite koja su polja potrebna, ko ih smije čitati i koliko se dugo čuvaju. Prikupljanje više zato što je pohrana jeftina stvara obavezu koja nadživljava istragu. Model privatnosti u RFC 6973 tretira korelaciju, pogrešno pripisivanje i nepotrebno prikupljanje kao dizajnerske probleme, a ne kao naknadne misli.
Čuvajte mapiranje i zapise kao jedan objekt, jer je svako samo za sebe daleko manje osjetljivo od para. Zatim provjerite dizajn na aktivnosti koju vam je dozvoljeno generisati i koju već razumijete, koristeći najmanji upit na koji će se izvještaj osloniti. Tok obrade koji ne može reproducirati poznati događaj neće reproducirati ni nepoznati. Izvijestite o događaju koji dokazi podržavaju, riječima koje dokazi dopuštaju, i pustite čitaoca da sam dođe do većeg zaključka.
Napišite ograničenja uz nalaz: šta je spojeno, šta prevedeno i koja je evidencija ostala nijema. Nalaz koji navodi vlastite granice preživljava pregled koji samouvjereni sažetak ne preživljava. To je razlika između dokaza i priče o dokazu.