Чи може журнал 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 over HTTPS додає другий кордон: браузер або гостьовий застосунок із власним розв'язувачем ніколи нічого не питає в журналу організації. Точні транзакції надходять лише з власних подій застосунку або з проксі, журналювання якого ви явно підтримуєте. Звичайний тунель HTTPS CONNECT не дає проксі жодного огляду шляхів сторінок усередині. Володіння мережею не є дозволом тихо підміняти модель довіри застосунку.
Адреса належить сеансу, а не людині
Запис потоку з адресою з діапазону тунелю — це відправна точка, а не відповідь. З'єднайте цю адресу та позначку часу з призначенням сеансу, чинним у ту мить, бо через годину адресу може бути призначено іншому сеансу. Статична адресація — один зі способів зберегти цей зв'язок, але не єдиний.
Там, де крок трансляції зводить кілька пристроїв до однієї вихідної адреси вище за давач, зіставлення може назвати лише спільний сеанс шлюзу. Спільний обліковий запис або сертифікат, яким користуються кілька людей, обмежує атрибуцію, хоч би якими повними виглядали мережеві дані. І те, і те місце у звіті — обмеження, а не застереження на потім.
Записуйте часовий пояс, джерело годинника, точку спостереження та кожен кордон трансляції між ними. Відсутність заслуговує такої ж ретельності, як присутність, адже пропущений запис може означати, що запис потоку застарів, що давач не бачив пакет або що журнал застосунку було вимкнено.
Проєктуйте під заявлену мету, потім доведіть конвеєр
Коли питання зафіксовано, визначте, які поля потрібні, хто може їх читати і як довго вони зберігаються. Збирати більше, бо зберігання дешеве, створює зобов'язання, яке переживе розслідування. Модель приватності в RFC 6973 розглядає кореляцію, помилкову атрибуцію та зайвий збір як проблеми проєктування, а не як запізнілу думку.
Захищайте зіставлення та записи як один об'єкт, бо кожне окремо значно менш чутливе, ніж пара. Потім перевірте проєкт на активності, яку вам дозволено створювати і яку ви вже розумієте, використовуючи найменший запит, на який спиратиметься звіт. Конвеєр, не здатний відтворити відому подію, не відтворить і невідому. Повідомляйте про подію, яку підтверджують докази, тими словами, які докази дозволяють, і дозвольте читачеві самому дійти ширшого висновку.
Записуйте обмеження поруч із висновком: що було зіставлено, що трансльовано і який журнал промовчав. Висновок, який заявляє власні межі, витримує перевірку, якої не витримує впевнене резюме. У цьому різниця між доказом і розповіддю про доказ.