Un registro VPN può mostrare la cronologia di navigazione? Cosa dimostrano le prove
Un registro di sessione, una query del resolver e un record di flusso dimostrano cose diverse. Scegliete la domanda, unite identità e tempo e affermate solo ciò che è stato mostrato.
Due domande di audit suonano simili e richiedono prove di tipo diverso. Quale sessione ha contattato questo indirizzo si risponde dai registri di connessione e di flusso. Quale persona ha aperto questa pagina di solito no, almeno non da quei registri. Scegliere un raccoglitore prima di scegliere la domanda è il modo in cui un team di rete finisce per presentare un nome host come cronologia di navigazione.
Iniziate dall'evento che l'audit deve stabilire
Scrivete la domanda come una frase con soggetto, verbo e tempo. Solo questa disciplina espone lo scarto tra un registro di sessione e una visualizzazione di pagina. Un registro di sessione stabilisce che un'identità è stata accettata per un intervallo, con un indirizzo assegnato secondo una politica registrata, e non può stabilire quale pagina qualcuno abbia letto perché non ha mai visto la richiesta.
Nominate l'osservazione prima di progettare la raccolta. Un campo intitolato a un sito visitato che in realtà memorizza un nome risolto è un errore futuro, non una comodità. I nomi dei campi sopravvivono alle persone che li hanno scelti, quindi scegliete quelli che descrivono la prova e non la conclusione.
Cosa può e cosa non può sostenere ciascun registro
Quattro tipi di registro compaiono in quasi ogni progetto di audit, e ciascuno risponde a una domanda diversa. Teneteli separati nel rapporto e nella pipeline, perché mescolarli è il modo in cui un risultato difendibile diventa imbarazzante.
| 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 |
Leggete l'ultima colonna con la stessa cura di quella centrale. Un record di flusso descrive indirizzi e porte, e una ricerca inversa di un indirizzo non ricostruisce il nome usato da un browser, perché un indirizzo può ospitare molti siti non correlati. Una query del resolver dimostra che è stata posta una domanda, non che è stata mostrata una pagina. Un nome host visibile durante una negoziazione TLS non è nemmeno il percorso cifrato della richiesta.
Ognuna di queste è un'osservazione reale, e nessuna è l'osservazione che le persone presumono. Un browser che insiste sul proprio resolver cifrato resta fuori dall'ambito monitorato, e l'analisi non può recuperare ciò che la registrazione non ha mai visto. Quello scarto appartiene al rapporto come limite dichiarato, non come nota a piè di pagina.
Ricerche anticipate e risposte in cache
I browser risolvono i nomi in anticipo, a volte senza caricare nulla. Rispondono anche dalla cache senza inviare una nuova query al resolver che state osservando, il che significa che l'assenza di una query non è l'assenza di una visita. Entrambi i comportamenti rompono l'equazione ingenua tra un registro DNS e una cronologia di navigazione.
DNS su HTTPS aggiunge una seconda frontiera: un browser o un'applicazione ospite con il proprio resolver non chiede mai nulla al registratore dell'organizzazione. Le transazioni esatte provengono solo dagli eventi dell'applicazione stessa o da un proxy di cui supportate esplicitamente la registrazione. Un semplice tunnel HTTPS CONNECT lascia il proxy senza alcuna vista dei percorsi di pagina al suo interno. Possedere la rete non è il permesso di sostituire in silenzio il modello di fiducia dell'applicazione.
L'indirizzo appartiene a una sessione, non a una persona
Un record di flusso con un indirizzo dell'intervallo del tunnel è un punto di partenza, non una risposta. Collegate quell'indirizzo e la marca temporale all'assegnazione di sessione attiva in quel momento, perché quell'indirizzo può essere riassegnato a un'altra sessione un'ora dopo. L'indirizzamento statico è un modo per conservare quell'associazione e non l'unico.
Quando un passo di traduzione comprime più dispositivi in un solo indirizzo di origine a monte del sensore, l'unione può nominare solo la sessione del gateway condiviso. Un account condiviso o un certificato usato da più persone limita l'attribuzione, per quanto completi appaiano i dati di rete. Entrambi appartengono al rapporto come limiti, non come avvertenze per dopo.
Registrate il fuso orario, la fonte dell'orologio, il punto di osservazione e ogni frontiera di traduzione nel mezzo. L'assenza merita la stessa cura della presenza, perché un registro mancante può significare che una voce di flusso è scaduta, che un sensore non ha mai visto il pacchetto o che un registro dell'applicazione era spento.
Progettate per lo scopo dichiarato, poi dimostrate la pipeline
Una volta fissata la domanda, definite quali campi servono, chi può leggerli e per quanto tempo vengono conservati. Raccogliere di più perché l'archiviazione costa poco crea una responsabilità che sopravvive all'indagine. Il modello di privacy del RFC 6973 inquadra la correlazione, l'attribuzione errata e la raccolta non necessaria come problemi di progettazione, non come riflessioni successive.
Proteggete la mappatura e i registri come un unico oggetto, perché ciascuno da solo è molto meno sensibile della coppia. Poi validate il progetto contro attività che vi è consentito generare e che già comprendete, usando la query più piccola su cui si baserà il rapporto. Una pipeline che non riesce a riprodurre un evento noto non riprodurrà nemmeno uno sconosciuto. Riportate l'evento che le prove sostengono, con le parole che le prove consentono, e lasciate che il lettore arrivi da solo alla conclusione più ampia.
Scrivete i limiti accanto al risultato: cosa è stato unito, cosa tradotto e quale registro è rimasto silenzioso. Un risultato che dichiara i propri confini supera una revisione che un riepilogo sicuro di sé non supera. È la differenza tra una prova e una storia su una prova.