Лекция «Журналы: что писать, сколько хранить, как читать»

Около 65 минут на 18 тем. Прогресс сохраняется, поэтому лекцию можно проходить частями и возвращаться к ней позже.

Начало — да: первые 1 тема открыты сразу, без регистрации. После бесплатной регистрации откроются темы до 2-й — вместе с частью из 54 тестов и монетами за верные ответы. Полная лекция — 99 ₽ навсегда, либо подписка на все лекции платформы от 499 ₽ в месяц.

Восемнадцать тем про плановую дисциплину журналирования: что пишется постоянно, куда, сколько живёт и как потом читается. Первая часть — состав. Электронный журнал по п. 3.4 ГОСТ Р 59548-2022 — объект, предназначенный для хранения записей о событиях безопасности, а событием считается и возможность нарушения, а не только состоявшееся нарушение: неуспешный вход и штатная загрузка операционной системы — события. Содержательный минимум перечня даёт мера РСБ.1 методического документа ФСТЭК: входы и выходы плюс загрузка и останов ОС, подключение носителей и вывод на носители, запуск и завершение программ, попытки доступа к защищаемым объектам, попытки удалённого доступа — с оговоркой о статусе документа, писавшегося к приказу № 17, отменённому приказом № 117 с 1 марта 2026 года. Требования к усилению добавляют ежегодный пересмотр перечня, регистрацию действий привилегированных записей и изменений привилегий, причём привилегированные действия обязательны с класса защищённости 2 и выше, а остальные усиления — всегда. Обязательный состав записи — шесть полей таблицы 2: дата и время, идентификатор, наименование, субъект доступа, тип, уровень важности, причём при невозможности определить субъект поле следует оставить пустым. Уровней важности ровно семь, состав регистрируемой информации расписан для 81 типа событий, а время указывается в формате ГОСТ Р 7.0.64 со смещением от Всемирного координированного времени, обязательным наравне с самой минутой; мера МАС.9 ГОСТ Р 57580.1-2017 требует синхронизации на всех трёх уровнях защиты. Вторая часть — срок. Универсального ответа нет: не менее трёх месяцев по усилению 4 меры РСБ.1, три года по мере МАС.15 и пять лет по МАС.16 для финансовых организаций, двенадцать месяцев с тремя немедленно доступными по требованию 10.5.1 PCI DSS 4.0.1, а для персональных данных в журнале — критерий цели из ч. 7 ст. 5 152-ФЗ без числа. Отдельно разведён Перечень типовых управленческих архивных документов Росархива с пятилетними сроками по ст. 567, 577 и 578: он про управленческие документы, а не про электронные журналы событий. Усиление 4 называет и пять вариантов состава хранимого — от записей о выявленных событиях до всех записей журналов приложений, и разница между вариантами «а» и «б» принципиальна: вывод против вывода вместе с исходными строками. Сопутствующие меры МАС.8, МАС.11, МАС.12, МАС.13 и МАС.14 закрывают способы остаться без журнала, формально его храня. Инженерное дно темы даёт journald: SystemMaxUse по умолчанию 10 процентов файловой системы, SystemKeepFree 15 процентов, оба не больше 4 ГБ, MaxRetentionSec равен нулю — удаление по времени выключено. Значит журнал ограничен объёмом и не ограничен временем, а фактическая глубина проверяется не конфигурацией, а запросом записи за дату минус три месяца. Третья часть — чего в журнале быть не должно: перечень OWASP от паролей и токенов до данных держателей карт, правило о недопустимости исключать события «известных» систем, требование не помещать в журнал данные более высокого класса защиты, чем разрешено самому хранилищу, и кейс Facebook 2019 года, где журнал оказался одновременно причиной утечки и единственным инструментом расследования. Здесь же п. 48 приказа ФСТЭК № 117 о персонификации привилегированных учётных записей: общая учётная запись формально заполняет поле субъекта и обнуляет журнал по существу, а страдает от этого в первую очередь работник. Четвёртая часть — доказательственная: кейс Equifax с девятнадцатью месяцами отсутствия видимости, 76 днями атаки, 9 000 запросов к 48 базам и 265 находками; ч. 1 ст. 71 ГПК РФ, допускающая цифровую запись при условии способа, позволяющего установить достоверность; арифметика сроков ст. 193 ТК РФ, где месяц считается со дня обнаружения, шесть месяцев со дня совершения, а по результатам ревизии два года — против трёх месяцев глубины журнала; п. 53 постановления Пленума ВС РФ от 17.03.2004 № 2 о том, что доказывать тяжесть и обстоятельства проступка обязан работодатель; и ч. 1 и 2 ст. 10 98-ФЗ, по которым режим коммерческой тайны считается установленным только после принятия всех мер, включая учёт лиц, получивших доступ. Пятая часть — метод чтения от вопроса к полю записи и явный перечень того, чего лекция не обещает: ни универсального срока, ни безусловной персональности сетевого адреса, ни победы в трудовом споре одним журналом.

Одного числа нет, и это не уклончивость, а содержание вопроса. Ответ зависит от режима, в котором работает организация, а режимов в лекции разобрано пять. Общий ориентир — усиление 4 меры РСБ.1 методического документа ФСТЭК: не менее трёх месяцев, если иное не установлено законодательством. Для финансовых организаций ГОСТ Р 57580.1-2017 даёт мерой МАС.15 возможность доступа к данным регистрации в течение трёх лет на уровнях защиты 3 и 2 и мерой МАС.16 — в течение пяти лет на первом, усиленном уровне. При обработке карточных данных требование 10.5.1 PCI DSS 4.0.1 устанавливает не менее 12 месяцев, из которых последние три месяца должны быть немедленно доступны для анализа. А для персональных данных, которые попадают в журнал побочно — учётная запись, сетевой адрес, время работы, — ч. 7 ст. 5 152-ФЗ числа не называет вовсе: хранение в форме, позволяющей определить субъекта, допускается не дольше, чем этого требуют цели обработки, и цель формулирует сама организация. Поэтому единственный корректный ответ руководителю начинается со встречного вопроса о режиме. И отдельно: пятилетние сроки из Перечня типовых управленческих архивных документов Росархива сюда не относятся — они про журналы учёта носителей и документы об обеспечении защиты информации, то есть про управленческие документы организации, а не про электронные журналы событий операционных систем.

Не значит, и это самый практичный вывод лекции. Документация journald описывает поведение прямо: SystemMaxUse и RuntimeMaxUse задают предельный объём, SystemKeepFree и RuntimeKeepFree — сколько оставить свободным, служба соблюдает оба ограничения и применяет меньшее; первая пара по умолчанию равна 10 процентам размера файловой системы, вторая — 15 процентам, причём каждое вычисленное значение ограничено сверху 4 ГБ. А MaxRetentionSec — максимальное время хранения записей — по умолчанию равен нулю, что эту возможность выключает; в документации прямо сказано, что обычно удаления по размеру достаточно, однако для соблюдения политик хранения данных значение имеет смысл изменить. Отсюда следует буквальное: на типовой машине журнал ограничен объёмом и не ограничен временем. Фактическая глубина — частное от деления выделенного места на скорость записи, и на тихом сервере она составит год, а на нагруженном несколько суток при одинаковой конфигурации. Три месяца из усиления 4 меры РСБ.1 при этом нигде не нарушены явно — их просто не существует как настройки. Проверяется глубина одним вопросом, который нельзя пройти на бумаге: «покажи запись за дату минус три месяца». Если запись находится — глубина есть; если нет — есть только настройка, которая её обещала.

Проблема в том, что журнал в этом случае перечисляет действия без авторов. Поле «субъект доступа» из таблицы 2 ГОСТ Р 59548-2022 заполняется именем учётной записи: формально состав записи соблюдён, проверку это пройдёт, а ответа на вопрос «кто» нет. П. 48 приказа ФСТЭК России от 11.04.2025 № 117 требует, чтобы привилегированные учётные записи, имеющие права по созданию других привилегированных записей, были персонифицированными, запрещает объединять в одной записи или их группе роли по системному администрированию, по разработке и тестированию и роли администраторов безопасности, требует отключить или переименовать встроенные привилегированные записи и прямо указывает, что все действия по доступу пользователей с использованием привилегированных учётных записей подлежат регистрации. Но важнее формального требования вторая сторона. Журнал защищает обе стороны: работодателя — потому что действия зафиксированы и обработка не выглядит бесконтрольной, работника — потому что персонифицированная запись показывает, что именно сделал он, а чего не делал. Без персонификации назначение виновного превращается в выбор из списка имеющих доступ, и выбирают обычно того, кто был на смене. Так что общая учётная запись — это риск в первую очередь для самих администраторов, а не для организации.