Пункт 1.2 Приказа ОАЦ №66: как обеспечить сбор и хранение событий ИБ не менее одного года

Смысл требования

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

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

Формулировка требования

Приложение 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, раздел «Аудит безопасности», пункт 1.2: «обеспечение сбора и хранения сведений о событиях информационной безопасности в течение установленного срока хранения, но не менее одного года».

Обязательность применения

По таблице приложения 3 требование пункта 1.2 установлено как обязательное для всех классов типовых ИС: 4-ин, 4-спец, 4-бг, 4-юл, 4-дсп, 3-ин, 3-спец, 3-бг, 3-юл, 3-дсп. В отличие от ряда соседних мер, здесь отсутствует режим рекомендательного применения. Следовательно, владелец ИС не вправе ограничиться декларацией о включённом журналировании без доказательства фактического срока хранения.

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

Предмет проверки

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

• установлен ли в ТЗ, ЛПА, регламенте эксплуатации или ином ОРД срок хранения событий ИБ не менее одного года;
• определены ли источники событий, для которых этот срок должен обеспечиваться: операционные системы, СУБД, прикладное ПО, телекоммуникационное оборудование, средства защиты, VPN и иные каналы удалённого доступа;
• существует ли фактический механизм накопления и сохранения записей, а не только включённая регистрация на локальном узле;
• можно ли поднять архивные записи за предшествующие периоды и подтвердить, что события не были утрачены вследствие ротации, переполнения или сбоя;
• согласована ли модель хранения с перечнем событий, определённым по пункту 1.1;
• учтена ли типология событий, рекомендованная ОАЦ со ссылкой на приказ № 130, для операционных систем, СУБД, телекоммуникационного оборудования, прикладного программного обеспечения и средств защиты информации.

Последний пункт принципиален. В методических рекомендациях ОАЦ прямо указано, что перечень типов и записей событий ИБ определён в приложении к положению, утверждённому приказом ОАЦ № 130 от 25 июля 2023 г. Соответственно, для практической реализации пункта 1.2 логично исходить не из произвольного набора источников, а как минимум из этой нормативно предложенной структуры событий.

Варианты реализации

Организационная модель.

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

Техническая модель без централизованного сбора.

Здесь события ИБ сохраняются на самих источниках регистрации, но для каждого источника настраиваются объём журналов, архивирование, ротация, резервное копирование и контроль доступности архивов. Формально такой вариант может соответствовать пункту 1.2, поскольку сам пункт не требует обязательной централизации. Однако эксплуатационно это слабое решение: чем больше источников, тем выше вероятность утраты части записей и тем труднее доказать соблюдение годового срока хранения по всей ИС.

Комбинированная модель.

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

Техническая реализация и инструменты

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

• Windows Event Forwarding / Windows Event Collector. Рационален для преимущественно Windows-среды. Позволяет централизованно собирать события с рабочих станций и серверов в единый коллектор. Преимущество — штатная реализация без отдельного тяжёлого стека. Ограничение — менее удобно для смешанной инфраструктуры и глубокой аналитики.
• rsyslog / syslog-ng / классический syslog-сервер. Подходит для Linux-систем, сетевого оборудования, межсетевых экранов, части СЗИ и Unix-подобных компонентов. Преимущество — надёжность и простота развёртывания. Ограничение — минимальные встроенные средства корреляции и аналитики.
• Graylog. Практичный вариант для небольших и средних ИС, когда кроме хранения требуется удобный поиск, фильтрация и базовая обработка событий. Преимущество — хорошее соотношение трудоёмкости внедрения и полезности в эксплуатации.
• Wazuh. Подходит для случаев, когда помимо накопления событий нужен агентский сбор, контроль целостности и более выраженная security-логика. Это уже не просто хранилище логов, а платформа с расширенным набором функций безопасности.
• ELK / OpenSearch Stack. Целесообразен для больших объёмов событий, смешанной инфраструктуры и необходимости масштабируемого поиска и аналитики. Ограничение — значительно более высокая сложность сопровождения по сравнению с базовыми средствами.
• SIEM-платформы. Оправданы в крупных и зрелых ИС, где задача хранения тесно связана с корреляцией, расследованием и реагированием. Для изолированного закрытия одного пункта 1.2 это может быть избыточно, но для развитой системы мониторинга такой вариант часто наиболее устойчив.

При выборе инструмента следует оценивать не маркетинговую известность продукта, а структуру источников событий, объём журналов, квалификацию персонала, требования к поиску и анализу, а также эксплуатационные ресурсы. Для простой ИС иногда достаточно WEC или syslog-сервера с корректно настроенным архивированием. Для распределённой или смешанной среды без выделенного централизованного механизма хранение годового массива событий обычно быстро становится неуправляемым.

Типичные ошибки при реализации

• срок хранения событий ИБ нигде не закреплён документально;
• журналы формально ведутся, но фактически перезаписываются значительно раньше одного года;
• архивирование реализовано, однако поиск и извлечение исторических записей затруднены либо фактически невозможны;
• учтены только события операционных систем, а события из СУБД, телекоммуникационного оборудования, межсетевых экранов, прикладного ПО и СЗИ не включены в модель хранения;
• объёмы хранения не рассчитаны, вследствие чего происходит обрезка журналов, потеря части архивов или аварийное заполнение хранилища;
• техническое решение внедрено, но не отражено в ТЗ, регламентах и иных документах, поэтому на проверке его приходится обосновывать устно;
• перечень событий по пункту 1.1 и источники хранения по пункту 1.2 не согласованы между собой.

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

Для смешанной, распределённой или критичной для расследований ИС предпочтительна комбинированная модель с централизованным накоплением и контролируемым сроком хранения. С точки зрения правоприменительной практики пункт 1.2 выполнен не тогда, когда журналирование «включено», а тогда, когда владелец ИС способен документально и технически доказать сохранность событий ИБ в течение установленного срока, но не менее одного года. Отсылка рекомендаций ОАЦ к приказу № 130 дополнительно показывает, что состав источников и типов событий должен строиться на нормативно признанной модели, а не на произвольном наборе журналов.