Ці можа журнал VPN паказаць гісторыю прагляду? Што даказваюць доказы
Журнал сеансу, запыт рэзалвера і запіс патоку даказваюць рознае. Спачатку выберыце пытанне, звяжыце ідэнтычнасць і час, і гаварыце толькі пра тое, што было паказана.
Два пытанні аўдыту гучаць падобна і патрабуюць доказаў рознага роду. На пытанне, які сеанс звярнуўся да гэтага адрасу, можна адказаць па запісах злучэнняў і патокаў. На пытанне, якая асоба адкрыла гэтую старонку, звычайна нельга, прынамсі не па гэтых запісах. Выбар зборшчыка раней за выбар пытання — менавіта так сеткавая каманда пачынае падаваць імя хоста як гісторыю прагляду.
Пачніце з падзеі, якую павінен устанавіць аўдыт
Запішыце пытанне як сказ з дзейнікам, дзеясловам і часам. Адна толькі гэтая дысцыпліна выкрывае разрыў паміж запісам сеансу і праглядам старонкі. Журнал сеансу фіксуе, што ідэнтычнасць была прынятая на пэўны інтэрвал з прызначаным адрасам паводле зафіксаванай палітыкі, і ён не можа ўстанавіць, якую старонку хто чытаў, бо ніколі не бачыў запыту.
Назвіце назіранне да таго, як праектаваць збор. Поле, названае ў гонар наведанага сайта, якое насамрэч захоўвае развязанае імя, — гэта будучая памылка, а не зручнасць. Назвы палёў жывуць даўжэй за людзей, якія іх выбралі, таму выбірайце тыя, што апісваюць доказ, а не выснову.
Што кожны запіс можа і не можа пацвердзіць
Чатыры тыпы запісаў сустракаюцца амаль у кожным праекце аўдыту, і кожны адказвае на іншае пытанне. Трымайце іх асобна і ў справаздачы, і ў канвееры апрацоўкі, бо іх змешванне — гэта шлях ад абароненай высновы да сорамнай.
| 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 |
Чытайце апошні слупок так жа ўважліва, як сярэдні. Запіс патоку апісвае адрасы і парты, а зваротны пошук адрасу не аднаўляе імя, якое выкарыстаў браўзер, бо адзін адрас можа абслугоўваць мноства незвязаных сайтаў. Запыт рэзалвера даказвае, што пытанне было зададзена, а не што старонка была паказана. Імя хоста, бачнае падчас перамоў TLS, таксама не з'яўляецца шляхам зашыфраванага запыту.
Кожнае з гэтага — рэальнае назіранне, і ні адно з іх не з'яўляецца тым назіраннем, якое людзі мяркуюць. Браўзер, які настойвае на ўласным зашыфраваным рэзалверы, знаходзіцца па-за межамі кантраляванай зоны, і аналіз не можа аднавіць тое, чаго журнал ніколі не бачыў. Гэтая прага павінна быць у справаздачы як заяўленае абмежаванне, а не як зноска.
Папераджальныя запыты і кэшаваныя адказы
Браўзеры развязваюць імёны загадзя, часам зусім нічога не загружаючы. Яны таксама адказваюць з кэша, не адпраўляючы новага запыту да рэзалвера, за якім вы назіраеце, а значыць адсутнасць запыту не азначае адсутнасці наведвання. Абодва паводзіны ламаюць наіўнае раўнанне паміж журналам DNS і гісторыяй прагляду.
DNS праз HTTPS дадае другую мяжу: браўзер або гасцявая праграма з уласным рэзалверам ніколі нічога не пытае ў рэгістратара арганізацыі. Дакладныя транзакцыі прыходзяць толькі з уласных падзей праграмы або з проксі, журнал якога вы яўна падтрымліваеце. Звычайны тунель HTTPS CONNECT не пакідае проксі ніякага выгляду на шляхі старонак унутры яго. Валоданне сеткай не дае дазволу ціха падмяніць мадэль даверу праграмы.
Адрас належыць сеансу, а не чалавеку
Запіс патоку з адрасам з дыяпазону тунелю — гэта адпраўны пункт, а не адказ. Звяжыце гэты адрас і адзнаку часу з прызначэннем сеансу, актыўным у той момант, бо праз гадзіну гэты адрас можа быць прызначаны іншаму сеансу. Статычная адрасацыя — адзін са спосабаў захаваць гэтую сувязь, але не адзіны.
Калі крок трансляцыі згортвае некалькі прылад у адзін адрас крыніцы вышэй за сэнсар, злучэнне можа назваць толькі агульны сеанс шлюза. Агульны ўліковы запіс або сертыфікат, якім карыстаюцца некалькі чалавек, абмяжоўваюць атрыбуцыю, якой бы поўнай ні выглядалі сеткавыя даныя. Абодва належаць у справаздачу як абмежаванні, а не як заўвагі на будучыню.
Запішыце часавы пояс, крыніцу часу, пункт назірання і кожную мяжу трансляцыі паміж імі. Адсутнасць заслугоўвае такой жа ўвагі, як прысутнасць, бо адсутны запіс можа азначаць, што запіс патоку састарэў, сэнсар ніколі не бачыў пакета або журнал праграмы быў выключаны.
Праектуйце пад заяўленую мэту, затым дакажыце канвеер
Калі пытанне зафіксавана, вызначце, якія палі патрэбны, хто можа іх чытаць і колькі яны захоўваюцца. Збор большага таму, што захоўванне таннае, стварае адказнасць, якая перажывае расследаванне. Мадэль прыватнасці ў RFC 6973 разглядае карэляцыю, памылковую атрыбуцыю і непатрэбны збор як праблемы праектавання, а не як думкі пасля.
Ахоўвайце адпаведнасць і запісы як адзін аб'ект, бо кожнае паасобку куды менш адчувальнае, чым пара. Затым праверце праект на актыўнасці, якую вам дазволена генерыраць і якую вы ўжо разумееце, з самым малым запытам, на які будзе абапірацца справаздача. Канвеер, які не можа ўзнавіць вядомую падзею, не ўзнавіць і невядомую. Паведамляйце пра падзею, якую падтрымліваюць доказы, словамі, якія дапускаюць доказы, і дайце чытачу самому прыйсці да большай высновы.
Напішыце абмежаванні побач з высновай: што было злучана, што было перакладзена і які журнал маўчаў. Выснова, якая заяўляе ўласныя межы, вытрымлівае разгляд, якога ўпэўненае рэзюмэ не вытрымлівае. Гэта і ёсць розніца паміж доказам і гісторыяй пра доказ.