Серверные логи и приватностьВаш хостер перестал вести логи. Ваш сервер — нет.

Теперь вы — сторона, которой пишут

Тот, кто хочет узнать, кто посещал ваш сайт, начинает не с вашего хостера. Он начинает с вас — потому что именно вы единственная сторона в цепочке, у которой есть прямой интерес хранить эту запись, юридический адрес, по которому можно написать, и никакого отчёта о прозрачности, который можно было бы потом опубликовать.

Хостинг-компании неловко это писать, и вот арифметика, которая за этим стоит. Перечень, опубликованный здесь, гласит, что HTTP-логи доступа уничтожаются по суточному таймеру и что никакой истории адресов после этого нигде не остаётся. Обычный веб-сервер на арендованной у нас машине по умолчанию хранит собственный лог доступа около двух недель, в ночной резервной копии — год, и оба этих числа никто не выбирал осознанно. Тщательный выбор хостера сводится на нет настройкой по умолчанию, которую никто не прочитал.

Что на самом деле содержит одна строка лога доступа

Формат по умолчанию у обоих распространённых веб-серверов не менялся двадцать пять лет, и почти никто не читает его как запись о человеке. Стоит хотя бы раз прочитать его именно так, потому что каждое поле ниже — это отдельное раскрытие данных, и они складываются друг с другом.

Семь полей, одна строка — записывается на каждый запрос, который делает браузер — а это обычно от двадцати до восьмидесяти строк на один просмотр страницы. Ничего из этого не было решением. Всё это — запись.

Девять мест, где ваш собственный стек записывает посетителя

Почти весь спор о логировании крутится вокруг первой строки таблицы. Это единственное, о существовании чего люди знают, и оно далеко не самое откровенное из того, что есть на машине.

Именно последняя строка сводит на нет большинство благих намерений. Сокращение ротации логов с четырнадцати дней до одного меняет то, что лежит на диске, и совершенно не меняет копию, снятую в три часа ночи и хранимую год. Удаление записи, которая уже реплицирована, — это смена местоположения, а не удаление.

Два поля, которые выдают больше, чем адрес

Адрес — это поле, о котором спорят все, и у него самый короткий срок полезной жизни: он меняется, он общий для многих, а в мобильной сети принадлежит оператору связи, а не человеку. Два соседних поля незаметно хуже.

Реферер описывает читателя, а не запрос

Он отвечает на вопрос, который вы никогда не задавали: где этот человек был секунду назад. Это и пересланная ему ссылка на приватный документ, и внутренняя система тикетов, и превью почтового клиента, и страница сайта, который он не хотел бы связывать с вашим. Браузеры теперь обрезают путь, если переход ведёт на другой домен, и это помогает — но никак не помогает со ссылками внутри вашего собственного сайта, где полный путь по-прежнему отправляется и по-прежнему записывается.

User-agent — основа отпечатка

Сам по себе он — толпа. В сочетании с адресом, языковым заголовком, порядком запросов и набором принимаемых форматов он неделями остаётся одним и тем же посетителем — без cookie, без согласия и без того, чтобы кто-то решил кого-то отслеживать. Именно этот механизм делает фразу «мы храним только серверные логи» более слабой, чем думает тот, кто её произносит.

Секреты попадают в лог, потому что были в URL

Ради этой ошибки стоит дочитать страницу до конца: она распространена, она незаметна и полностью в вашей власти. Всё, что после знака вопроса, — часть строки запроса, а строка запроса — это то, что записывается.

• Ссылки для сброса пароля. Одноразовый токен в query-строке записывается открытым текстом в лог доступа, в резервную копию лога доступа и на каждом прокси между читателем и вами.
• Ссылки-приглашения и ссылки для отписки. Устроены так же, живут дольше и обычно вообще не истекают.
• Идентификаторы сессии, переданные в URL. Редкость в новом коде, но всё ещё встречается в старом, и для любого, у кого есть этот файл, — полный захват учётной записи.
• API-ключи, переданные браузеру. Ключ в query-строке — это ключ в логе, ключ в реферере, отправленном третьей стороне, и ключ в истории читателя.
• Поле поиска. Поиск по сайту, отправляемый методом GET, записывает каждый запрос, который кто-либо вводил на вашем сайте, рядом с адресом того, кто его ввёл.

Исправление — это не настройка логирования. Перенесите значение в заголовок или в тело запроса, где ни один формат по умолчанию его не запишет, и ротируйте всё, что уже успело записаться. Фильтр логов, вырезающий токены, — это ещё одна вещь, которую нужно поддерживать, и он ошибётся в первый же раз, когда кто-то добавит новый параметр.

Что у вас могут потребовать и кто

Другие материалы на этом сайте — об инструментах, поступающих в хостинг-компанию в юрисдикции, выбранной специально для этого. Инструмент, который добирается до ваших собственных логов, проще: его вручают вам, там, где находитесь вы, и местоположение машины тут вообще ни при чём.

• Гражданское требование в вашей собственной стране. Тот, кто судится из-за комментария, утечки или покупки, запрашивает у оператора сайта то, что у оператора есть. Оператор — это вы, а две недели логов доступа — это то, что легко обязать предоставить.
• Запрос от читателя. Согласно европейскому законодательству о защите данных человек вправе спросить, что вы о нём храните, а адрес способен быть персональными данными: в 2016 году Суд ЕС постановил именно это по делу C-582/14, где динамический адрес, которым владел оператор сайта, был признан персональными данными, потому что существовал законный способ установить абонента. Срок хранения тоже должен быть обоснован — статья 5(1)(e) требует хранить не дольше, чем необходимо, а «так уж вышло по умолчанию» — не цель.
• Тот, кто скомпрометирует машину. Самый вероятный читатель вашего лога доступа — вовсе не суд. Логи редко шифруются, редко мониторятся и почти никогда не входят в модель угроз, а лежат по предсказуемому пути на любом сервере, собранном обычным способом.
• Все, до кого дотягиваются ваши резервные копии. Копия, хранимая за пределами площадки, — это копия в другой компании, под другой юрисдикцией, подотчётная инструментам, которых вы не читали.

Ничто из этого не является юридической консультацией, и это хозяйство — не ваш юрист. Это та же логика перечня, применённая к вашей стороне провода: то, чего вы не можете предоставить, не может быть с вас потребовано, а всё остальное — вопрос того, чей суд спрашивает. Как это работает на стороне хостинга, описано в материале что на самом деле происходит, когда полиция обращается к хостеру.

Хранить меньше, не ослепнув

Прочитав до этого места, хочется просто отключить логирование, и это неверный шаг: сервер без логов нельзя отладить, для него нельзя разумно настроить ограничение частоты запросов, и он не сможет сообщить, что его прямо сейчас взламывают. Цель — не ноль. Цель — оставить ту часть, которая отвечает на эксплуатационный вопрос, и отбросить ту, что отвечает только на вопрос о конкретном человеке.

Два из этих шести пунктов не стоят вообще ничего и снимают большую часть рисков, описанных на этой странице. О последнем не думает никто, и именно поэтому остальные пять недорабатывают.

Третьи стороны, которые логируют ваших читателей за вас

Всё сказанное выше — про файлы на машине, которую контролируете вы. Но браузер, загружающий вашу страницу, ещё и открывает соединение с каждым другим доменом, упомянутым на странице, и каждый из них получает адрес, user-agent и реферер, сообщающий, какая именно ваша страница читалась — ещё до того, как посетитель ответил на баннер согласия, потому что запрос уже ушёл.

• Шрифт, отдаваемый чужим сервером. Одна строка в таблице стилей — и каждый читатель каждой страницы раскрывается третьей стороне ради файла, который вы вполне могли бы разместить в той же папке, что и весь остальной сайт.
• Встроенное видео или карта. Загружается сразу, на каждой странице, где присутствует, — независимо от того, нажал ли кто-нибудь «play».
• Виджет чата или тег-менеджер. По замыслу присутствует на каждой странице и способен подгружать дополнительный код, который вы не проверяли.
• Трекер ошибок. Самый полезный из них и самый откровенный: он существует именно для того, чтобы передавать вам состояние чужой сессии.
• CDN перед всем сайтом. Это не аргумент против CDN — это разумный компромисс — но это компания, которая видит каждый запрос раньше вас, ведёт собственные логи и отвечает перед собственной юрисдикцией.

Разместить первые три у себя обычно можно за полдня работы, и это убирает больше стороннего наблюдения, чем любая настройка на вашем собственном сервере. Это также та часть страницы, которая улучшает то, что получают ваши читатели, а не только то, что у вас могут обязать предоставить, — и именно поэтому с неё стоит начать. Аналогичный список, направленный на риски для вас самих, а не для ваших читателей, — в материале девять вещей, которые выдают сайт.

Что это хозяйство может с этим сделать, а что нет

Честно провести границу дороже, чем любое заверение, поэтому вот она — с этой стороны.

• Наши собственные HTTP-логи доступа уничтожаются по суточному таймеру, и никакой истории адресов, записи о местоположении при входе или переживающего это отпечатка не остаётся. Полный список того, что всё же сохраняется, опубликован в виде перечня, и в нём семь записей.
• То, что поступает через юридическую процедуру, учитывается в отчёте о прозрачности, а что именно выдаётся по законному постановлению, записано заранее, а не решается на месте.
• На VPS или выделенном сервере логи, описанные на этой странице, находятся внутри вашей операционной системы. Мы их не читаем, никуда их не отправляем и точно так же не можем настроить их за вас — единоличная аренда режет в обе стороны, в этом и весь смысл.
• Что мы можем обеспечить — это слой ниже: никакой записи личности при регистрации, расчёты только ончейн, и машина в юрисдикции, которую выбрали вы, а не в той, где живёт эмитент вашей карты.

И вот ради чего существует эта страница: выбрать хостера по тому, что он отказывается хранить, а затем самому хранить две недели того же самого — это решение о приватности, отменённое одним конфигурационным файлом. Эти две половины несравнимы по трудозатратам. Одна заняла неделю чтения, другая занимает полдня, и завершена только одна из них.

Часовой аудит собственных логов

Ничего из перечисленного ниже не требует покупки какого-либо инструмента, и каждый шаг сообщает то, чего не сообщал предыдущий.

1. Распечатайте одну строку своего лога доступа и прочитайте её вслух, поле за полем, так, как это сделал бы посторонний.
2. Перечислите все файлы в своей директории логов, затем отметьте те, что открывали за последний год. Неотмеченные — это чистый риск.
3. Прочитайте конфигурацию ротации и запишите, сколько дней она хранит на самом деле, а не то число, которое, как вам помнится, вы когда-то согласовали.
4. Восстановите резервную копию за прошлый месяц во временную директорию и поищите там лог, который, как вам кажется, был удалён две недели назад.
5. Поищите в логе доступа слова token, reset, key, session и password. Всё, что найдёте, — это секрет, который уже записан на диск и который нужно не просто исправить, а сменить.
6. Откройте свою главную страницу с включённой панелью сети браузера и выпишите все домены, к которым идут обращения и которые вам не принадлежат. Каждый из них — компания, хранящая данные о ваших читателях по собственному сроку хранения.
7. Проверьте, какой заголовок несёт реальный адрес за вашим прокси или CDN, и убедитесь, записывает ли его исходный сервер. CDN не останавливает логирование на исходном сервере — он просто переносит поле.
8. Откройте самое недавнее событие в своём трекере ошибок и посчитайте, сколько деталей о реальном читателе есть в его содержимом.
9. Осознанно определите три срока хранения — для безопасности, для аналитики, для резервных копий — и запишите их там, где их найдёт следующий, кто будет настраивать этот сервер.
10. Составьте перечень: что существует, где, как долго и что вы бы предоставили, если бы завтра утром поступило законное постановление. Если этот документ неприятно писать — это самый полезный час из всего списка.

Вопросы, которые задают на самом деле

Каждая цена в этом хозяйстве опубликована полностью и в одном месте. Смотреть весь каталог