v1.3_4.15 Настройка проверки соответствия требованиям ИБ (Posture)

Описание

Услуга «Соответствия ИБ» (Posture, posturing) предназначена для контроля соответствия эндпоинтов требованиям информационной безопасности (ИБ) до предоставления им полного доступа к сети. Реализована по принципу Zero Trust: эндпоинт не получает доступ к корпоративной сети, пока не подтвердит соответствие требованиям. Проверку выполняет агент, установленный на эндпоинте, — он собирает данные о системе по требованиям политик и передаёт результат проверки соответствия (posture-отчёт) в NAICE. По результату для эндпоинта определяется статус соответствия ИБ, на основании которого политики доступа к сети выдают соответствующий уровень доступа.

Общий алгоритм работы

1. При каждом триггерном событии (если период доверия к результату выключен или истёк) эндпоинт получает статус «Не определен» («Unknown») и помещается в карантин; такое поведение задаётся в политиках доступа к сети.

2. Находясь в карантине, агент получает из NAICE политики, подходящие под тип и версию ОС эндпоинта, собирает пробы и отправляет результат обратно.

3. По результату проверки NAICE определяет статус соответствия: если активные требования выполнены, эндпоинт получает доступ к сети, иначе остаётся в карантине. Итоговые доступы для каждого статуса настраивает администратор в политиках доступа к сети.

4. При смене статуса для активной сессии NAICE автоматически отправляет CoA Re-Auth, чтобы применить доступы, соответствующие новому статусу.

Проверка соответствия выполняется агентом:

• при подключении эндпоинта к сети;

• при перезапуске агента или смене сетевого интерфейса;

• периодически в фоне, если включена периодическая фоновая проверка (PRA).

При провале проверки эндпоинт переводится в статус «Не соответствует», а его доступ пересматривается через CoA Re-Auth.

Условия работы услуги и ограничения

Требования к NAICE

• Наличие активированной лицензии уровня PRIME или демо-режим (есть ограничение по количеству проверок).

• Включён учёт RADIUS-сессий (accounting), отвечающий за старт и завершение активных сессий. При отключённом учёте услуга недоступна.

• В профиле сетевого устройства настроен тип CoA Re-Auth.
• Загружен сертификат сервера соответствия для безопасного взаимодействия с агентами соответствия по HTTPS.
• Если на эндпоинте включена рандомизация MAC-адреса, то требуется его ручное добавление в NAICE (случайные MAC-адреса не изучаются как эндпоинты автоматически).

Требования к сетевому устройству (аутентификатору)

• Сетевое устройство, через которое авторизован эндпоинт, поддерживает RADIUS CoA. При смене статуса соответствия NAICE автоматически отправляет CoA Re-Auth, чтобы применить к активной сессии доступы, соответствующие новому статусу. Если устройство не поддерживает CoA Re-Auth или соответствующий тип не настроен, услуга не предоставляется.

• На сетевом устройстве должна быть включена передача запросов RADIUS-accounting: в начале сессии после успешной авторизации должен отправляться запрос Accounting-Start, а при ее завершении - Accounting-Stop.

• Сетевое устройство должно в запросе передавать атрибут RADIUS·Calling-Station-Id, по которому в NAICE определяется уникальный эндпоинт.

Требования к клиентскому устройству (эндпоинту)

• Клиентское устройство использует одну из поддерживаемых операционных систем (64-разрядные версии с архитектурой AMD64):
  • Windows 10/11 Home/Pro/Enterprise;
  • RedOS 8;
  • Ubuntu 24/26;
  • Astra Linux 1.7/1.8.
• Должны быть корректно указаны системное время и часовой пояс.

• На эндпоинте должен быть установлен агент политики соответствия. Агент является скрытым (не имеет GUI) и проводит проверки в фоновом режиме без навязчивых всплывающих окон.

• Агент требует прав администратора для установки и последующей работы для успешного сбора проб.
• Агент должен доверять сертификату сервера соответствия при установке HTTPS соединения.

• Агент должен иметь сетевую связность с NAICE как из карантинной, так и корпоративной сети (по умолчанию для приема сообщений со стороны NAICE используется TCP порт 8102).

• При использовании в качестве адреса NAICE доменного имени агент должен его успешно разрешать через DNS запрос.

Настройка NAICE

Включение учета RADIUS-сессий (accounting)

Учёт RADIUS-сессий (accounting) используется в работе с активными сессиями. Он включен в NAICE по умолчанию, однако если в ходе более ранних работ настройка была выключена, то следует включить ее обратно на странице Настройки системы → Сервисы → RADIUS. При отключённом учёте настройка услуги проверки соответствия ИБ недоступна.

Также должен быть верно указан порт аккаунтинга RADIUS как со стороны NAICE, так и со стороны сетевого оборудования (значение должно совпадать).

Настройка профиля устройства

Профили устройств расположены на странице Пользователи и устройства → Сетевые ресурсы → Профили устройств. Требуется создать новый или отредактировать существующий профиль, указав в нем Настройки RADIUS CoA:

Наиболее важные настройки:

• Общие настройки RADIUS CoA:
  • Устройство поддерживает RADIUS CoA - включить;
  • Порт RADIUS CoA - указать используемый на сетевом устройстве порт RADIUS CoA. Значение может отличаться в зависимости от производителя и типа оборудования;
• Типы CoA:
  • Re-authentication - включить;
  • Атрибут и Значение атрибута - сочетание атрибут+значение, которое на используемом сетевом оборудовании приводит к повторной аутентификации клиента. Данные настройки могут отличаться в зависимости от производителя и типа оборудования. 

Для того, чтобы поместить клиента сначала в карантинную, а затем и в целевую корпоративную сеть, предполагается использование механизма Client VLAN (CVLAN) - выдачи значения VLAN-ID в результирующем RADIUS-ответе авторизации. Альтернативный вариант - использование для тех же целей ACL (named, dynamic). В дальнейшем для демонстрации работы услуги будет использовано ограничение доступа через VLAN.

Необходимо на вкладке Разрешения настроить возможность выдачи CVLAN / named ACL в профиле авторизации:

Наиболее важные настройки:

• Настроить VLAN - включить;
• Атрибуты по умолчанию - выключить, если для механизма CVLAN оборудование использует RADIUS-атрибуты, отличные от стандартных RADIUS:Tunnel-Private-Group-Id. При выключении требуется выбор вендор-специфичных атрибутов.
• Настроить ACL - включить;
• Имя - RADIUS-атрибут, в котором оборудование принимает от RADIUS-сервера имя ACL, который требуется применить для клиента. Сам ACL должен быть настроен на оборудовании. 

После завершения настройки нажать Сохранить.

Добавление устройства

На странице Пользователи и устройства → Сетевые ресурсы → Устройства добавить сетевое устройство с ранее настроенным профилем устройства.

Добавление профилей авторизации 

Профили авторизации содержат результат авторизации, который необходимо назначить клиенту в зависимости от правил политик доступа. Именно здесь необходимо указать конкретные значения CVLAN / named ACL, разрешение и атрибуты для которых настраивались в профиле устройства.

Перейти на страницу Доступ к сети → Элементы политик → Профили авторизации и создать профиль авторизации для помещения эндпоинта в карантинную сеть:

Наиболее важные настройки:

• Профиль устройства - настроенный ранее профиль устройства;
• Тип доступа - ACCESS_ACCEPT;
• Общие задачи:
  • VLAN - включить;
  • VLAN ID/Name - указать VLAN ID или имя карантинного VLAN.

При использовании ограничения доступа через механизм named ACL включить и указать имя настроенного на оборудовании ACL.

При использовании ограничения доступа через механизм dynamic ACL указать Расширенные настройки атрибутов согласно v1.3_4.2.3 Настройка выдачи dynamic ACL. 

Аналогичным образом создать профиль авторизации для доступа эндпоинта к целевой корпоративной сети.

Загрузка и назначение сертификата сервера соответствия

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

Необходимые для этого действия, а также требования к сертификату, описаны в v1.3_3.6 Использование сертификатов безопасности.

Настройка политик соответствия ИБ

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

Из-за значительных различий в работе операционных систем требования к Windows- и Linux-клиентам настраиваются отдельно. От семейства ОС зависят доступные типы требований и их атрибуты.

После установки или обновления системы до версии 1.3 в списке автоматически появляются преднастроенные шаблоны политик Default posture policy for Windows  и  Default posture policy for Linux. Они созданы в выключенном состоянии: их можно адаптировать под свои требования и включить. По умолчанию обе политики содержат требования к работе антивредоносного ПО (одна из указанных программ должна быть включена и возвращать положительный статус здоровья устройства) и межсетевого экрана (один из указанных в списке межсетевых экранов должен быть включен).

Для понимания общего процесса настройки политики соответствия далее будет рассмотрено создание собственной простой политики.

Создание политики соответствия ИБ

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

Шаг 1 - Назначение политики:

Настроить:

• Включено - участвует ли на данный момент политика в проверке подходящего эндпоинта на соответствие требованиям;
• Тип агента - в текущей версии доступен только скрытый агент (без GUI);
• Имя политики - произвольное название;
• Семейство ОС - Windows или Linux;
• Версия ОС - выбрать конкретную редакцию и версию операционной системы. Поддерживаются только 64-разрядные версии ОС с архитектурой AMD64: Windows 10/11 (Home/Pro/Enterprise), а также Linux — РЕД ОС 8, Astra Linux 1.7/1.8, Ubuntu 24/26. 

  Поле "Версия ОС"  является необязательным. Если значение не выбрано, политика будет применяться при проверке эндпоинтов всех версий данного семейства ОС.

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

При нажатии Далее происходит переход к шагу 2 - Набор требований:

Для добавления нового типа проверки нажать Добавить тип проверки.

Для требования №1 из примера требуется использование типа проверки "Установленное ПО" – обобщенный тип проверки программного обеспечения, предназначенный для контроля наличия программ в системе, соответствия их версий заданному порогу и некоторых других атрибутов, свойственных любому ПО. В отличие от типов проверок "Антивредоносное ПО" или "Межсетевой экран", не содержит специальных проверок, свойственных только конкретному типу ПО.

Карточка типа проверки содержит следующие элементы:

• -  общий выключатель данного типа проверки, который исключает из процесса posture ВСЕ вложенные проверки;
• Глобальное условие между проверками  - логический оператор между проверками в рамках данного типа проверок - И / ИЛИ;
• - удалить тип проверки или атрибут поиска/проверки;
• - свернуть/развернуть карточку;
• Имя  - название проверки, которое будет отображаться в отчете с результатами проверки соответствия требованиям;
• - переключатель статуса проверки. Общий статус влияет на все указанные условия этой проверки, также статус есть у каждого конкретного условия. Возможные статусы проверки:
  • - проверка выполняется и влияет на результат соответствия эндпоинта по политике;
  • - проверка выполняется, результат помещается в отчет, но он не влияет на результат соответствия эндпоинта политике; полезно при отладке новой политики;
  • - проверка не выполняется.
• - дополнительные действия с проверкой (Дублировать / Удалить);
• Параметры поиска  - атрибуты, по которым на эндпоинте находится проверяемый объект (доступно не для всех типов). Для некоторых типов проверок заданы обязательные параметры поиска, которые нельзя удалить. Новый атрибут можно добавить либо в текущую ветку условий, либо в новую. Это необходимо для построения сложной логики с операторами И/ИЛИ между параметрами.
• Параметры проверки - условие, по которым определяется статус соответствия проверяемого объекта.
• - добавить еще одну проверку в данного типа. Суммирование результатов нескольких проверок определяется исходя из Глобальное условие между проверками.

 Для удовлетворения требования №1 из примера настроено следующее: 

В рамках одной политики можно добавить несколько типов требований. Глобально между различными типами проверок действует логика "И" - для получения статуса "Соответствует" требуется успешное прохождение всех типов проверок. Это поведение нельзя переопределить.

Для удовлетворения требования №2 из примера добавлена проверка типа "Антивредоносное ПО" – контроль установленных антивирусных решений и их работоспособности. В отличие от "Установленного ПО", содержит специальные параметры проверки, характерные только для антивирусов. 

После завершения всех настроек нажать Добавить.

Перечень доступных требований ИБ

(опционально) Настройка интервалов проверок соответствия

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

Доступные настройки:

• Период доверия к результату проверки (Posture Lease), дней – количество дней, в течение которых NAICE доверяет последнему полученному статусу ""Соответствует" без повторной проверки. Настройка позволяет ускорить получение доступа в сеть, сократив количество проверок. Рекомендуется использовать совместно с PRA, чтобы не снижать безопасность системы.

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

  При использовании коммутаторов Eltex MES включение данной настройки является обязательным. Повторная аутентификация на этих коммутаторах реализуется через CoA port bounce, которая завершает активную RADIUS-сессию. Это приводит к постоянному сбросу статуса соответствия эндпоинта в «Unknown».

• Периодическая фоновая проверка (PRA), минут – механизм регулярной проверки соответствия эндпоинта требованиям безопасности без необходимости наступления одного из триггерных событий. Задача PRA: в фоновом режиме убеждаться, что устройство всё еще "здорово" и соблюдает политики ИБ, поэтому PRA запускается только после того, как устройство успешно прошло первичную/триггерную проверку и получило статус "Соответствует" (Compliant). Механизм автоматически прекращает работу, как только устройство переходит в статус "Не соответствует" (Non-Compliant) или теряет связь с NAICE. Сбор данных и отправка отчета происходят незаметно для пользователя во время активной сессии. Каждая успешная фоновая проверка сбрасывает и обновляет таймеры периода доверия (Posture Lease) и следующего запуска PRA.

Настройка политик доступа к сети

Алгоритм работы услуги проверки соответствия ИБ предполагает различный доступ к сети в зависимости от статуса соответствия эндпоинта - неизвестные или провалившие проверку устройства помещаются в карантин, а полностью соответствующие требованиям безопасности устройства получают доступ в корпоративную сеть. Такое поведение настраивается в разделе Доступ к сети → Политики RADIUS.

Требуется создать новый набор политик. В качестве входного условия может быть настроено любое подходящее условие - адрес конкретного сетевого устройства, к какой группе оно принадлежит, тип подключения клиентского устройства и многое другое. Для примера настроено условие по RADIUS-атрибуту  NAS-IP-Address. Список разрешенных протоколов также может быть настроен произвольно. Далее необходимо сохранить набор и перейти к его детальной настройке через кнопку .

Политика аутентификации настраивается в зависимости от источника идентификационных данных пользователей. Для примера оставлена цепочка источников идентификации по умолчанию - Default sequence, которая изначально содержит только локальных пользователей сети. При необходимости использования внешних источников пользователей произвести настройки согласно v1.3_4.1 Настройка интеграции с внешними источниками.

Политика авторизации требует настройки двух правил с условием по статусу соответствия (Endpoint identity·Posture status) - для эндпоинтов, успешно прошедших проверку (статус «Compliant») разрешить доступ к корпоративной сети, для эндпоинтов, не прошедших или проваливших проверку - разрешить доступ только к карантинной сети. Один из вариантов этой настройки выглядит следующим образом:

В качестве профилей авторизации должны быть указаны соответствующие ранее созданные профили.

Настройка может быть разделена на 3 правила отдельно для каждого возможного статуса - «Compliant», «Non-compliant» и «Unknown». Это может быть полезно для более четкого разделения в мониторинге неизвестных и проваливших проверку устройств.

(опционально) Настройка срока хранения результатов проверок

Отчеты с результатами проверок удаляются по истечении заданного срока хранения (по умолчанию - 7 дней). Изменить данный срок можно на странице Настройки системы → Система → Ротация данных.

Настройка сетевого устройства

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

Все настройки выполняются в режиме конфигурации (configure). Приведена минимально необходимая  настройка.

Настройка адреса RADIUS-сервера (NAICE)

radius-server host <адрес NAICE> key <секретный ключ RADIUS>

Включение учета RADIUS-сессий (accounting)

aaa accounting dot1x start-stop group radius

Включение RADIUS CoA

aaa authorization dynamic radius

Включение режима аутентификации 802.1X

dot1x system-auth-control

Конфигурация интерфейса

Перейти в режим редактирования конфигурации конкретного интерфейса:

interface <название, например GigabitEthernet 1/0/3>

Использовать 802.1X для изменения состояния клиента между авторизованным и неавторизованным:

dot1x port-control auto

Разрешить применение через получаемые RADIUS-атрибуты ограничения доступа на порту одним или несколькими способами:

dot1x radius-attributes filter-id                      # named ACL (требует настройки ACL на коммутаторе)
dot1x radius-attributes vlan static                    # client VLAN (требует наличия VLAN в VLAN database)
dot1x radius-attributes vendor-specific data-filter    # dynamic ACL

Настройка клиентского устройства

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

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

Проверка подключения

После выполнения попытки подключения результаты подключения можно увидеть в NAICE.

Мониторинг активности на сети

Перейти на страницу Мониторинг → RADIUS → Активность на сети. Колонка "Статус соответствия ИБ"  по умолчанию скрыта в таблице со списком событий на сети. Для ее включения требуется нажать над таблицей и включить соответствующий чекбокс:

После сохранения статус соответствия эндпоинта станет отображаться сразу в таблице.

Посмотреть последние события. Для устройства, которое ПРОВАЛИЛО проверку требований ИБ и получило статус "Не соответствует", переподключение после CoA-запроса завершится попаданием в карантинную сеть, аналогично первому запросу.

В детальной информации о сессии (открывается в новом окне при нажатии кнопки в колонке "Подробнее") при этом также будет отображаться Статус соответствия ИБ "Non-compliant" (т.е. "Не соответствует"). Для того чтобы понять, почему именно проверка не была пройдена, необходимо открыть детальную информацию об эндпоинте (кнопка напротив MAC-адреса клиента).

В случае, если проверка пройдена успешно, эндпоинт получит статус "Соответствует" ("Compliant") и после переподключения ему будет назначен профиль авторизации, соответствующий доступу в корпоративную сеть.

Просмотр отчета с результатами проверки соответствия

На страницу отчета с результатами проверки соответствия ИБ можно попасть через подробности сессии указанным выше образом. Альтернативный способ – перейти на страницу Пользователи и устройства → Управление идентификацией → Эндпоинты и для соответствующего эндпоинта открыть детальную карточку (нажать в колонке "Подробнее"). Последний полученный отчет располагается во вкладке Результат соответствия ИБ.

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

В данном случае проверка была провалена потому что на устройстве было найдено приложение, содержащее в названии telegram ("Telegram Desktop"). При этом приложение Elph Nova было найдено, из-за чего правило "Elph Nova установлен" считается соответствующим. Аналогично была успешно пройдена проверка "Антивирус", но так как между разными типами проверок считается логический оператор "И", то на конечный результат это не повлияло.

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

Решение проблем

См. v1.3_9.12 Диагностика проверки соответствия требованиям ИБ (Posture).