Пункт 7.19 приложения 3 к ПТКЗИ: централизованный сбор и хранение DNS-запросов

Краткое описание требования

DNS сопоставляет доменные имена с данными, необходимыми для обращения к ресурсам. Когда рабочая станция запрашивает адрес корпоративного сервиса, а сервер — адрес внешнего API, соответствующий запрос может быть зарегистрирован на обслуживающем DNS-сервере. Такой журнал помогает установить, какой актив запрашивал какое имя и когда.

DNS-журнал не подтверждает, что соединение с запрошенным адресом действительно установилось. Например, несуществующее имя тоже создаёт DNS-запрос. Для подтверждения последующего соединения потребуются другие источники: журнал межсетевого экрана, прокси-сервера или средства защиты узла.

В пункте 7.19 ключевое слово — «централизованного». Недостаточно включить запись событий на одном сервере. Нужно определить охват активов ИС и СЗИ, организовать доставку сведений из необходимых источников в центральное хранилище и обеспечить их доступность в течение нормативного срока.

Оригинальная формулировка требования

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

В пункте определены предмет сбора (DNS-запросы активов ИС и СЗИ), централизованный характер сбора и хранения, а также срок — не менее одного месяца. Конкретные поля записи, сервер журналирования, SIEM, DoH и DoT в формулировке не указаны и рассматриваются ниже как вопросы технической реализации.

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

В таблице приложения 3 требование отмечено знаком «+» для классов 3-ин, 3-спец, 3-бг, 3-юл и 3-дсп и знаком «+/–» для классов 4-ин, 4-спец, 4-бг, 4-юл и 4-дсп. Соответственно, для классов третьего уровня оно обязательное, для четвёртого — рекомендуемое.

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

Что именно проверяет проверяющий

Проверка строится вокруг трёх результатов: охват источников, централизованное поступление сведений и фактический срок хранения.

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

Фактическое поступление. На выбранном тестовом активе выполняют запрос уникального имени через предусмотренный DNS-сервер. Например, в контролируемой среде:

nslookup gc-audit-20260927-001.invalid 10.10.10.10 

Здесь 10.10.10.10 — условный адрес корпоративного DNS; его заменяют адресом реального сервера. Домен .invalid специально зарезервирован для недействительных имён. Ответ NXDOMAIN допустим: проверяется регистрация запроса, а не существование адреса.

Затем в центральном хранилище находят запись с именем, временем и источником. Условный нормализованный результат:

Время:       27.09.2026 16:20:43 DNS-сервер:  dns01 Источник:    10.10.10.25 Запрос:      gc-audit-20260927-001.invalid Тип:         A Ответ:       NXDOMAIN 

Если запись содержит только IP промежуточного резолвера, демонстрируют предусмотренный механизм сопоставления с первоначальным активом. При наличии нескольких DNS-маршрутов испытание повторяют для каждого существенного варианта.

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

Дополнительно полезно проверить обнаружение прекращения передачи событий. Это эксплуатационная мера, поддерживающая полноту сбора, а не отдельная буквальная формулировка пункта 7.19.

Где регистрировать запросы

До выбора программного продукта следует восстановить путь DNS-запроса для разных типов активов. Например:

Рабочая станция → DNS на контроллере домена → внешний резолвер Сервер приложения → локальный DNS → корпоративный DNS СЗИ → DNS, указанный в настройках самого средства 

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

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

Учитывают и удалённые устройства: при подключении через VPN они могут использовать корпоративный DNS, а вне VPN — иной. Для включённых в границы ИС режимов работы нужно отдельно установить, откуда получать соответствующие сведения.

Какие сведения сохранять

В качестве практического состава записи целесообразно предусмотреть:

• дату и время запроса;
• идентификатор источника — как минимум его адрес в точке регистрации;
• запрашиваемое доменное имя;
• тип запроса, например A или AAAA;
• DNS-сервер либо иной источник события.

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

Для сопоставления адреса с активом могут потребоваться сведения DHCP, VPN и реестра активов за соответствующий момент времени. Адрес, который сегодня принадлежит одной рабочей станции, завтра может быть выдан другой. Не следует утверждать, что единственный IP в журнале всегда однозначно определяет устройство или пользователя.

Нельзя автоматически приравнивать запрос к успешному разрешению имени. Например, ответ NXDOMAIN означает, что запрошенное имя не найдено, однако сам запрос всё равно представляет интерес для регистрации.

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

Вариант 1 — журналирование на корпоративных DNS-серверах. DNS-серверы фиксируют клиентские запросы, агент или поддерживаемый механизм экспорта передаёт записи на центральный сервер журналов. Это удобно, если маршруты DNS известны и основные активы используют централизованную службу.

На Windows Server важно различать аудит изменений DNS и аналитическое журналирование обработки запросов. Один только журнал изменения DNS-зон не подтверждает регистрацию клиентских обращений. Для проверки включают соответствующий аналитический канал либо другой поддерживаемый механизм журналирования запросов и убеждаются, что в нём действительно появляются события. <a href=»https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-logging-and-diagnostics»>Документация Microsoft</a> отдельно описывает назначение каналов и ограничения по производительности.

На BIND 9 журналирование входящих запросов может осуществляться через категорию queries. Параметры её включения и формат записей приведены в <a href=»https://bind9.readthedocs.io/en/latest/reference.html»>руководстве BIND 9</a>. Настройку и объём журналирования выбирают с учётом нагрузки DNS-сервера.

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

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

Независимо от варианта, центральное хранилище должно принимать события из установленных источников, обеспечивать поиск по периоду и идентификатору актива и сохранять записи в течение заданного срока. SIEM может выполнять эту задачу, но пункт 7.19 сам по себе не устанавливает обязательность именно SIEM.

Особый случай: DoH, DoT и кэширование

Не все программы обязательно используют штатный корпоративный DNS. Приложение может обращаться к иному резолверу, в том числе через DNS over HTTPS (DoH) или DNS over TLS (DoT). В таком случае традиционный журнал корпоративного DNS-сервера не увидит запрос, который через него не проходил.

Запрет DoH/DoT не сформулирован в пункте 7.19 как отдельная обязанность. Но при проверке полноты сбора необходимо понять, не позволяют ли фактические настройки активов обходить выбранные точки регистрации. Возможные технические решения — управляемые настройки DNS, ограничения на использование сторонних резолверов и регистрация на поддерживаемых конечных узлах. Конкретный вариант зависит от архитектуры.

Ещё одно ограничение — кэш. Если ответ получен из кэша клиента, новый запрос на сетевой DNS-сервер может не отправляться. Отсутствие сетевого запроса в таком случае не равно сбою журналирования. Для контрольного испытания используют уникальное имя, которое ранее не запрашивалось.

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

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

В ЛПА и ОРД закрепляют ответственных за сопровождение, разграничение доступа к журналам, контроль достаточности хранилища и действия при прекращении поступления событий. Организационные документы не заменяют фактическую работу технических средств: проверяющему необходимо предъявить и утверждённое решение, и результат его функционирования.

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

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

• Записываются изменения DNS-зон вместо клиентских запросов. Журнал службы существует, но предмет требования не охвачен.
• Сбор организован только на вышестоящем сервере. Сохраняется адрес промежуточного резолвера, а исходный актив установить нельзя.
• Часть активов обходит точки регистрации. Например, отдельные серверы или СЗИ используют другие DNS-серверы.
• Журналы остаются локально. Регистрация на DNS-сервере есть, централизованное хранение не подтверждено.
• Указан срок, но нет исторических записей. Настройка ротации не соответствует фактическому сохранению сведений.
• Проверяется только основной DNS-сервер. Резервный сервер обслуживает запросы, но его журнал не поступает в центр.

Обнаруженное отклонение следует формулировать по существу: какие активы или DNS-маршруты не охвачены, какие сведения отсутствуют и чем это подтверждается.

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

• Пункт 1.3 — централизованный сбор событий ИБ.
• Пункт 7.12 — межсетевое экранирование.
• Пункт 7.18 — обнаружение и реагирование на угрозы конечных узлов.

Вывод

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

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

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

• Приказ ОАЦ от 20.02.2020 № 66, актуализированная редакция — приложение 3, пункт 7.19, таблица обязательности.
• Microsoft: DNS Logging and Diagnostics — технические возможности DNS в Windows Server.
• BIND 9 Administrator Reference Manual — настройка регистрации запросов BIND.

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