Описание системы и архитектуры

On-premises · иерархия «мастер — подчинённые узлы»

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

О документе

Настоящий документ даёт целостное функциональное и архитектурное описание ITENTA DNS Filter в варианте размещения в инфраструктуре заказчика. Он предназначен для ИТ-архитекторов, специалистов сетевой инфраструктуры, информационной безопасности и администраторов решения.

Краткое резюме

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

• Контентная фильтрация — ограничение категорий ресурсов и отдельных доменов для выбранных адресов и сетей.
• Защита от доменных угроз — запрет разрешения имён, связанных с фишингом, вредоносным ПО, управляющей инфраструктурой, ботнетами и иными индикаторами угроз.
• Иерархическое управление — глобальная политика задаётся на мастере и версионированно доставляется подчинённым узлам.
• Локальная автономность — каждый узел хранит собственную рабочую копию конфигурации, выполняет фильтрацию, разрешение имён и журналирование без обращения к мастеру на каждый запрос.
• Наблюдаемость — локальный и общекластерный журнал, аналитика, состояние узлов и передача событий во внешние системы мониторинга.

1. Назначение и возможности системы

1.1. Решаемая задача

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

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

1.2. Основные функции

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

2. Модель развёртывания

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

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

2.1. Мастер-узел

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

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

2.2. Подчинённый узел

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

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

2.3. Два узла и доступность

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

3. Логическая архитектура

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

3.1. Состав логических компонентов

3.2. Размещение данных

4. Обработка DNS-запроса

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

4.1. Последовательность решения

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

4.2. Приоритет правил

Разрешение локальной категории снимает только категорийный запрет для указанной области клиентов; отдельное запрещающее доменное правило продолжает действовать. Это позволяет делать точечные исключения без неявного отключения других механизмов контроля.

4.3. Формирование ответа

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

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

5. Политики, категории и защита от угроз

5.1. Политика фильтрации

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

5.2. Категоризация доменов

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

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

5.3. Защита от компьютерных угроз

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

5.4. Обновление рабочего снимка

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

6. Управление и синхронизация

6.1. Регистрация подчинённого узла

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

6.2. Получение глобальной конфигурации

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

6.3. Обновление базы категорий

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

6.4. Обратный поток на мастер

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

7. Механизм управления DNS-зонами

Правила зон в ITENTA DNS Filter задают не авторитетные DNS-записи, а маршрут разрешения: для одного или нескольких доменных суффиксов выбирается набор DNS-серверов, которым следует передавать разрешённый запрос.

7.1. Состав правила

7.2. Правила мастера

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

7.3. Локальные правила подчинённого узла

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

При совпадении одного суффикса локальное правило узла имеет приоритет над правилом мастера: площадка лучше знает собственный путь к внутренней зоне.

7.4. Выбор маршрута

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

7.5. Безопасное применение

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

8. События, журнал и аналитика

8.1. Состав события

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

8.2. Локальный и общий журнал

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

Кроме сырых событий узел формирует компактные агрегаты по времени, вердиктам, категориям и клиентам. Мастер использует их для сводных карточек, сравнения узлов и площадок, а сырые события — для общекластерного журнала с детальными фильтрами.

8.3. Независимость DNS от аналитики

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

8.4. Внешний экспорт

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

9. Управление и пользовательские роли

9.1. Веб-консоль

9.2. Модель полномочий

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

9.3. Локальные исключения

Подчинённому узлу разрешено добавлять локальные блокировки и исключения, не изменяя глобальную политику мастера. Блокирующее правило действует сразу, поскольку только ужесточает контроль. Разрешающее правило на подчинённом узле вступает в силу после одобрения администратора мастера; изменение одобренного правила требует нового одобрения.

9.4. Резервное копирование

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

10. Надёжность и деградированные режимы

11. Архитектура безопасности

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

12. Внешние взаимодействия

13. Типовые сценарии

13.1. Блокирование угрозы

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

13.2. Изменение глобальной политики

Администратор меняет распространяемую политику на мастере. Мастер фиксирует новую версию. Подчинённые узлы при очередном опросе получают согласованный набор, транзакционно применяют его, подготавливают новый снимок и атомарно активируют. В heartbeat мастер видит фактически применённую версию каждого узла.

13.3. Локальная внутренняя зона

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

13.4. Временная потеря мастера

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

14. Ключевые архитектурные свойства

15. Глоссарий