Пункт 4.4 приложения 3 к ПТКЗИ: синхронизация системного времени активов и СЗИ

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

Пункт 4.4 приложения 3 к ПТКЗИ – практический разбор требования «синхронизация времени». Пункт 4.4 устанавливает требование к единству системного времени в информационной системе и системе защиты информации. Его смысл состоит в том, что серверы, рабочие станции, сетевое оборудование, средства защиты, журнальные системы, системы резервного копирования, гипервизоры, СУБД и иные значимые компоненты должны использовать согласованное время, получаемое от единого общего источника.

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

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

Приложение 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, предназначенных для обработки информации, распространение и (или) предоставление которой ограничено, утверждённому приказом Оперативно-аналитического центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66, в редакции приказа от 10 декабря 2024 г. № 259, с учётом изменений, внесённых приказом от 27 мая 2026 г. № 98 (далее – Приложение 3 к ПТКЗИ), раздел «Требования по защите системы защиты информации информационной системы», пункт 4.4: «синхронизация системного времени активов информационной системы, средств защиты информации от единого (общего) источника».

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

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

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

Что означает единый общий источник времени

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

В доменной Windows-инфраструктуре типовой вариант – синхронизация клиентов и серверов от доменной иерархии времени, где ключевую роль играет контроллер домена с ролью PDC Emulator. В Linux-среде часто применяются chrony или ntpd. Для сетевого оборудования и средств защиты обычно настраиваются внутренние NTP-серверы. Важно, чтобы все эти механизмы в итоге приводили к единой согласованной временной шкале, а не к набору независимых источников.

• Внутренний источник времени. Сервер или группа серверов, которым доверяют активы ИС и СЗИ.
• Внешний эталонный источник. Государственный, операторский, корпоративный или иной утверждённый источник, от которого получает время внутренний источник.
• Иерархия синхронизации. Правило, по которому одни узлы получают время от утверждённых внутренних серверов, а не от произвольных внешних NTP-серверов.
• Контроль расхождения времени. Проверка того, что фактическое время на узлах не уходит за допустимые пределы.
• Документированная схема. Описание того, какие активы и СЗИ откуда получают системное время.

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

Какие компоненты должны быть охвачены

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

• Контроллеры домена, серверы и рабочие станции. Для них синхронизация времени критична для аутентификации, журналирования и корректной работы доменной инфраструктуры.
• Сетевое оборудование. Коммутаторы, маршрутизаторы, межсетевые экраны, VPN-шлюзы и иные устройства должны иметь согласованное время для анализа соединений, изменений конфигурации и административных действий.
• Средства защиты информации. СЗИ от НСД, межсетевые экраны, IDS/IPS, антивирусные консоли, SIEM, средства журналирования, DLP, EDR и иные защитные компоненты должны формировать события с корректными временными метками.
• СУБД и прикладные системы. Временные метки операций пользователей, транзакций, ошибок, изменений данных и административных действий должны быть сопоставимы с системными и сетевыми журналами.
• Гипервизоры и виртуальная инфраструктура. Виртуальные машины, хосты виртуализации и управляющие компоненты должны использовать согласованное время, иначе журналы на уровне гипервизора и гостевых систем расходятся.
• Системы резервного копирования и хранения журналов. Время заданий, ошибок, восстановления, ротации и архивирования должно совпадать с временными метками других компонентов ИС.
• Облачные и внешние компоненты. При использовании IaaS, SaaS или внешних сервисов необходимо понимать, как формируются временные метки и в какой временной зоне они представлены.

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

Что следует подтвердить при проверке

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

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

Слабая реализация – когда контроллер домена синхронизируется с одним внешним сервером, сетевое оборудование – с другим, СЗИ – с третьим, а часть Linux-серверов вообще использует локальные настройки. В такой ситуации формально синхронизация где-то есть, но единого общего источника времени для ИС фактически нет.

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

Организационный вариант.

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

Технический вариант.

Синхронизация реализуется средствами Windows Time Service, NTP, chrony, ntpd, настройками гипервизоров, сетевого оборудования, СЗИ и прикладных платформ. На техническом уровне задаются внутренние серверы времени, источники для них, правила доступа, параметры синхронизации и контроль состояния. Такой вариант даёт фактический результат, но без документированного порядка проверяющему будет трудно понять, какая схема считается утверждённой владельцем ИС.

Комбинированный вариант.

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

Что целесообразно закрепить в ТЗ, ЛПА и ОРД

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

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

• единый общий источник системного времени или внутренняя иерархия источников времени;
• перечень активов ИС и СЗИ, подлежащих синхронизации;
• порядок синхронизации серверов, рабочих станций, сетевого оборудования, гипервизоров, СЗИ, СУБД и приложений;
• правила использования внешних источников времени и запрет произвольных внешних NTP-серверов;
• порядок контроля расхождения времени между ключевыми компонентами;
• допустимые пределы отклонения времени, если они определяются владельцем ИС;
• порядок действий при отказе источника времени или обнаружении значимого расхождения;
• порядок документирования результатов проверки синхронизации;
• ответственных лиц за настройку, сопровождение и контроль системного времени;
• используемый часовой пояс и правила интерпретации времени в журналах событий.

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

Возможность технической реализации и инструменты

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

• Внутренние серверы времени. Получают время от утверждённого источника и обслуживают активы ИС и СЗИ.
• Доменная иерархия. В Windows-среде клиенты и серверы могут использовать штатную иерархию домена с контролируемым внешним источником для корневой роли времени.
• NTP-клиенты сетевого оборудования и СЗИ. Направляются на утверждённые внутренние источники, а не на произвольные публичные серверы.
• Мониторинг расхождения. Контролируются состояние синхронизации, доступность источников и величина отклонения времени.
• Резервирование. Допускается несколько согласованных источников в одной доверенной иерархии, если их использование документировано.

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

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

• синхронизация времени настроена только на доменных компьютерах, но не на сетевом оборудовании и СЗИ;
• разные компоненты ИС используют разные внешние NTP-серверы без единой утверждённой схемы;
• контроллер домена, серверы Linux, гипервизоры и межсетевые экраны имеют разные источники времени;
• в журналах разных систем используются разные часовые пояса без описания порядка интерпретации;
• на сетевом оборудовании время настроено вручную и постепенно уходит от фактического;
• СЗИ формируют журналы с некорректным временем, из-за чего их невозможно корректно сопоставить с событиями ОС и приложений;
• нет контроля расхождения времени и никто не замечает рассинхронизацию до расследования инцидента;
• после миграции в виртуальную среду или облако схема синхронизации времени не пересматривается;
• в ЛПА указана одна схема синхронизации, а фактические настройки используют другие источники;
• отсутствуют подтверждения: выгрузки настроек, команды проверки, скриншоты, отчёты мониторинга или результаты сверки времени.

Вывод

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

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

Связанные материалы

• Определение состава регистрируемых событий ИБ
• Централизованный сбор событий ИБ
• Контроль работоспособности и настроек активов

Нормативная основа

• Приказ ОАЦ № 66 в редакции приказа № 259 от 10.12.2024 с учётом изменений, внесённых приказом № 98 от 27.05.2026 с учётом изменений, внесённых приказом № 98 от 27.05.2026 с учётом изменений, внесённых приказом № 98 от 27.05.2026 – приложение 3, пункт 4.4; пункт 11 о составе активов и схемах; пункт 13 о регламентации применения СЗИ. Официальный текст