Пункт 1.3 Приказа ОАЦ №66: как обеспечить централизованный сбор и хранение событий ИБ

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

Пункт 1.3 развивает требования пунктов 1.1 и 1.2 и переводит аудит безопасности из режима разрозненного журналирования в режим управляемого накопления событий. Если пункт 1.1 требует определить состав событий ИБ, подлежащих регистрации, а пункт 1.2 — обеспечить их сбор и хранение не менее одного года, то пункт 1.3 требует организовать этот процесс централизованно. Иными словами, владелец ИС должен обеспечить не просто наличие журналов на отдельных узлах, а единую модель накопления событий информационной безопасности, позволяющую получать, хранить и использовать их как целостный массив данных. :contentReference[oaicite:0]{index=0}

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

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

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

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

По таблице приложения 3 требование пункта 1.3 имеет смешанный режим применения. Для классов 4-ин, 4-бг и 4-юл оно обозначено как рекомендуемое («+/–»), а для классов 4-спец, 4-дсп, 3-ин, 3-спец, 3-бг, 3-юл, 3-дсп — как обязательное («+»). Это означает, что для части менее жёстких классов законодатель допускает выполнение пункта 1.2 без обязательной централизации, однако для большей части систем, обрабатывающих более чувствительные категории информации или работающих в условиях подключения к открытым каналам передачи данных, централизованный сбор и хранение уже становятся обязательной мерой.

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

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

При проверке пункта 1.3 оценивается не формальное наличие сервера логов, а наличие работающей централизованной модели. Проверяющий, как правило, анализирует, какие источники событий подключены к централизованному сбору, в каком объёме они передают события, как обеспечивается их накопление в течение требуемого срока и можно ли по данным из одного централизованного контура восстановить события за прошлые периоды. Поскольку методические рекомендации ОАЦ связывают практику аудита безопасности с типологией событий из приказа ОАЦ № 130, в поле проверки обычно попадают события от операционных систем, СУБД, телекоммуникационного оборудования, прикладного ПО и средств защиты информации. :contentReference[oaicite:5]{index=5}

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

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

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

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

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

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

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

Комбинированная модель с централизованным сбором и базовой аналитикой.

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

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

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

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

В правоприменительной логике важно, что средство выбирается не “по названию”, а по способности обеспечить именно централизованный сбор и централизованное хранение. Если платформа принята, но часть событий продолжает оставаться только на источниках, это уже не полноценная централизованная модель.

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

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

Вывод

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

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