Может ли журнал 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 рассматривает корреляцию, ошибочную атрибуцию и избыточный сбор как проблемы проектирования, а не как запоздалую мысль.
Защищайте сопоставление и записи как один объект, потому что каждое по отдельности гораздо менее чувствительно, чем пара. Затем проверьте проект на активности, которую вам разрешено создавать и которую вы уже понимаете, используя минимальный запрос, на который будет опираться отчёт. Конвейер, не способный воспроизвести известное событие, не воспроизведёт и неизвестное. Сообщайте о событии, которое подтверждают доказательства, теми словами, которые доказательства позволяют, и позвольте читателю самому прийти к более широкому выводу.
Записывайте ограничения рядом с находкой: что было сопоставлено, что транслировано и какой журнал промолчал. Находка, заявляющая собственные границы, выдерживает проверку, которую не выдерживает уверенное резюме. В этом разница между доказательством и рассказом о доказательстве.