Логирование и аудит

Практика ведения системных журналов выросла в реализациях операционных систем семейства Unix: подсистема syslog, разработанная в Калифорнийском университете в составе дистрибутива BSD, позволяла программам отправлять сообщения о событиях центральному демону, который складывал их в единые файлы^[8]. Ценность протокола для эксплуатации привела к тому, что сообщения о событиях стали пересылаться по сети между машинами, и в 2001 году документ RFC 3164 описал наблюдаемое поведение сложившейся практики^[8].

Стандартизация продолжилась рабочей группой IETF: документ RFC 5424 2009 года определил формат сообщения syslog с приоритетом, объединяющим источник событий и уровень критичности, со структурными данными и полем TIMESTAMP, принимающим NILVALUE («-»), когда системное время получить невозможно^[9]. Системный интерфейс журналирования закрепили и в стандарте POSIX: функции openlog, syslog и closelog дают программе универсальный способ записи сообщений с указанием источника и приоритета^[10]. По мере роста парков машин журналы перестали умещаться на отдельных серверах: администраторы стали собирать сообщения со всех узлов в централизованные хранилища, где записи сопоставляются и просматриваются единообразно^[6][5]. Инженерные руководства крупных интернет-сервисов закрепили этот подход: журналирование рассматривается как служба всей системы, а не личная привычка разработчика отдельного компонента^[11]

Собственные механизмы регистрации событий независимо развивали и производители других платформ: документация Майкрософт описывает инфраструктуру регистрации событий Windows, переработанную начиная с Windows Vista^[12].

Поворотной точкой в управлении журналами стал документ NIST SP 800-92 2006 года: руководство Национального института стандартов и технологий США сформулировало лог-менеджмент как сквозную практику организации — от выработки политики записи событий до хранения, защиты и уничтожения журналов^[5]. Потребность в таком руководстве была связана с федеральным законодательством о защите информации, однако рекомендации института распространились далеко за пределы государственных систем США^[5][6].

В эксплуатационной практике сложились отдельные инструменты журналирования безопасности: подсистема auditd в Linux регистрирует события аудита на уровне ядра — от запуска программ до изменений файлов системной конфигурации, — и предоставляет утилиты поиска по журналу^[13]. Для распределённых приложений манифест двенадцати факторов сформулировал журнал как поток агрегированных событий, упорядоченных по времени, — такой поток можно направлять в файл, на экран или в системы обработки без изменения самого приложения^[14].

Журналирование устроено как непрерывная запись событий в хранилище: каждая запись содержит отметку времени, имя источника — узла или приложения, — и текст сообщения о событии^[9]. Формат RFC 5424 добавляет к этому заголовок с приоритетом, в котором закодированы источник событий (facility) и уровень критичности (severity), а также раздел структурных данных, позволяющий передавать сведения в машиночитаемой форме^[9].

Большинство систем записывает сообщения в виде строк текста, однако растёт доля структурированных форматов: запись сопровождается полями в машиночитаемой разметке вроде JSON, что упрощает автоматический разбор^[4][14]. Выбор формата влияет на весь дальнейший путь записи: текстовый журнал остаётся простым для человека, структурный — удобным для систем анализа^[6][15].

Набор событий, которые стоит записывать, руководства по безопасности определяют перечнем: отказы проверки входных данных, входы и выходы пользователей, обращения к чувствительным данным, операции с ключами шифрования, создание и удаление системных объектов, импорт и экспорт данных^[3]. Для приложений клиентской стороны справочник языка JavaScript описывает консоль отладки — объект console с методами вывода сообщений разной важности; такие сообщения служат журналом во время разработки и в работающем браузере^[16].

Протокол syslog закрепил восемь уровней критичности сообщений: от «чрезвычайной ситуации» (система неработоспособна) и «тревоги» (требуется немедленное действие) через «критическое состояние», «ошибку», «предупреждение» и «уведомление» до «информационного сообщения» и «отладочного сообщения»^[9]. Уровень помогает отделить события, требующие немедленной реакции, от рутинных, и задаёт правила фильтрации: администратор вправе направлять в отдельные журналы только события выше заданной критичности^[10][6].

Библиотеки журналирования переносят ту же шкалу в прикладной код. Справочник языка Python описывает методы debug, info, warning, error и critical и даёт рекомендации, какой метод выбирать для какой задачи — от детальной диагностики до сообщения о сбое^[17]. Выбор уровня при записи — обязанность разработчика: заниженный уровень прячет проблему в общем потоке, завышенный создаёт ложные тревоги^[6][3].

Журналы разделяются на системные и прикладные. Системные ведут операционная система и её службы: они фиксируют загрузку, входы пользователей, работу драйверов и сетевых служб; прикладные ведут программы — от сообщений веб-сервера о каждом запросе до ошибок самого приложения^[6][2]. Оба вида записываются в файлы журналов на файловой системе либо пересылаются центральному сборщику по сети^[8][5].

Особое место занимают журналы систем управления базами данных: документация PostgreSQL посвящает журналу упреждающей записи отдельную главу о надёжности — WAL-записи об изменениях сбрасываются на постоянный носитель до записи соответствующих изменений в файлы данных, что позволяет восстановить согласованное состояние после сбоя^[18]. Такой журнал служит не диагностике, а восстановлению данных, и потому отделён от журналов событий^[18][19].

Жизненный цикл журнала начинается с генерации записи: компоненты системы пишут события локально либо сразу отправляют их сборщику. Классический транспорт syslog работает по протоколу UDP на порту 514; доставка не гарантируется, зато накладные расходы минимальны^[8]. Для случаев, когда целостность сообщений в пути существенна, стандарты определили защищённые транспорты: RFC 5425 описывает пересылку сообщений syslog поверх защищённого канала TLS^[20].

Для критичных журналов хранение проектируют с защитой от подмены и утраты: копии выводятся на отдельные системы, записи подписываются, доступ к архивам ограничивается^[6][21]. Архивы сжимаются: сжатие текстовых журналов уменьшает занятое пространство в разы и потому считается стандартной частью хранения^[6]. Долгосрочное хранение даёт и исследовательский выигрыш: по старым журналам администраторы отслеживают корни проблем, восстанавливают систему и воспроизводят сценарии сбоев^[4].

Журналирование в эксплуатации связывается с Мониторингом: инженерные руководства отделяют пассивную запись событий от активных проверок и оповещений, но строят обе практики на одних и тех же записях^[11]. Анализ в реальном времени превращает журнал в источник тревог: правила срабатывают на события выше заданного уровня или на серии повторяющихся отказов^[2][11].

Аудит в информационных системах — это проверка состояния системы и действий людей по объективным записям, прежде всего по журналам^[2]. Аудит информационной безопасности проводится внутренними силами организации или приглашёнными специалистами и отвечает на вопрос, соответствует ли система требованиям стандартов, регламентов и законодательства; журналы при этом служат фактическим материалом проверки^[2]. Аудиторский след — восстановленная по журналам цепочка событий — позволяет ответить, кто, когда и что делал с данными^[3][2].

Для задач аудита журналы ведутся с повышенными требованиями к достоверности. Режим auditctl -e 2 блокирует изменение конфигурации аудита до перезагрузки, но сам по себе не обеспечивает неизменяемость файлов журнала. Их защиту организуют отдельно^[22]. Утилиты поиска и отчётов позволяют восстановить все попытки доступа к системе за выбранный период^[13].

Стандарты дополняют защиту журналов криптографическими средствами: документ RFC 5848 описывает подписанные сообщения syslog, дающие подтверждение подлинности отправителя, целостность сообщения, устойчивость к повтору и обнаружение пропавших записей^[21]. Такие меры помогают при расследовании инцидентов: след, который нельзя незаметно подделать, остаётся доказательством и после взлома системы^[21][23].

Первое применение журналирования — поиск неисправностей. Журналы фиксируют последовательность событий, предшествовавших сбою, что позволяет отделить причину от следствия и воспроизвести ошибку^[6]. В разработке программ журналирование дополняет отладку и трассировку: отладчик останавливает программу и требует участия человека, а журнал собирает сведения о работе системы в производственной среде, где отладчик недоступен^[17][15].

Второе применение — контроль безопасности. Журналы регистрируют входы, отказы аутентификации, смену привилегий и обращения к защищённым данным; системы обнаружения вторжений сопоставляют эти события с признаками атак и поднимают тревогу^[3][2]. Аудиторский след используется и после инцидента: по записям расследуют происшествие, оценивают ущерб и находят уязвимое место^[4][7].

Запись событий стоит производительности: вызовы журналирования выполняются в общем потоке приложения, и обильная запись замедляет работу программ и увеличивает объёмы передаваемых данных^[15]. Справочники по фронтенд-разработке отмечают и обратную сторону: слишком скудный журнал лишает разработчика сведений о реальных сбоях у пользователей^[15][16]. Руководства поэтому требуют балансировать полноту журналирования с быстродействием и выбирать события осознанно, а не записывать всё подряд^[5][3].

Журнал, собранный для защиты данных, сам становится их хранилищем. OWASP рекомендует обычно не записывать напрямую следующие сведения, а при необходимости удалять, маскировать, обезличивать, хешировать или шифровать их: маркеры доступа, чувствительные персональные данные, пароли аутентификации, строки подключения к базам данных, ключи шифрования, банковские реквизиты^[3]. Записанное вопреки запрету попадает в архивы и резервные копии, утечка которых угрожает конфиденциальности всей системы^[3][7].

Атакующий, получивший доступ к системе, заинтересован стереть свой след, поэтому журналы защищают от изменения: выводят копии на отдельные узлы, подписывают сообщения, ограничивают права на файлы журналов^[21][6]. Против этого работает и архитектура: блокировка конфигурации аудита защищает правила регистрации от изменения до перезагрузки; защита сохранённых записей требует ограничения доступа и отдельных мер хранения^[22].

Отдельный класс рисков — внедрение ложных записей: если журнал принимает сообщения из сети без проверки, нарушитель может заполнить его поддельными событиями или длинными строками, переполняющими хранилище^[3][8]. Защита строится на проверке источников, ограничении размера записей и подписывании сообщений^[21][3].