Лицензирование антивируса для изолированных контуров: что учесть

Почему в изолированном контуре с антивирусом возникают проблемы

Изолированный контур (air-gap) - это сеть или сегмент без прямого доступа в интернет, где часто ограничены и внешние носители. Такой режим повышает безопасность, но меняет привычную эксплуатацию антивируса: то, что в открытой сети делается автоматически, здесь превращается в отдельный процесс с людьми, регламентом и контрольными точками.

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

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

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

• как вы будете получать, проверять и завозить обновления (кто, откуда, как часто, с какой валидацией);
• где будет храниться офлайн-репозиторий обновлений и кто отвечает за его целостность;
• как считается лицензия: по устройствам, серверам, виртуальным машинам или ядрам;
• какие отчеты нужны ИБ (покрытие, актуальность, инциденты, исключения) и в каком виде;
• что считается нарушением: «нет обновлений 7 дней», «нет связи с консолью 24 часа» и т.д.

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

Модели лицензирования: что реально работает без интернета

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

По устройствам, серверам или пользователям: что проще в офлайне

Для закрытого контура обычно удобнее лицензирование по устройствам (endpoint) и по серверам: их проще посчитать по инвентаризации и привязать к конкретным узлам. Модель «по пользователям» в офлайне часто приводит к спорным ситуациям: люди меняются, учетные записи дублируются, а доказать, кто реально пользовался ПК, сложно.

Практичный подход - заранее зафиксировать правила, по которым объект считается лицензируемым (физический ПК, ВМ, терминальный сервер, выделенный сервер обновлений), и вести единый список активов.

Перед закупкой проверьте у вендора детали подсчета:

• физический ПК и виртуальная машина считаются отдельно или нет;
• сервер управления и офлайн-репозиторий требуют отдельной лицензии или входят в пакет;
• терминальные серверы считаются «по серверу» или «по сессиям/пользователям»;
• допускается ли перенос лицензии при замене железа и как это подтверждается.

Подписка и бессрочная лицензия: где скрыт риск

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

Бессрочная лицензия выглядит спокойнее, но право на обновления часто покупают отдельно (техподдержка/maintenance). Если maintenance закончился, продукт может продолжить работать, но без свежих баз и без отчетов об «актуальности защиты». Для ИБ это обычно неприемлемо.

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

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

Обновления без интернета: как спланировать процесс и частоту

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

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

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

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

Если обновления разрешены только через «санитарный шлюз», планируйте процесс как цепочку с проверками:

1. выгрузка пакетов обновлений во внешней зоне;
2. антивирусная проверка и контроль целостности на шлюзе;
3. перенос носителем или через выделенный канал в буферную зону;
4. тест на эталонной группе (несколько ПК и один сервер);
5. раскатка в контур и фиксация факта обновления для ИБ.

Офлайн-репозиторий обновлений: варианты архитектуры

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

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

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

Зона загрузки (staging)

На практике удобно разделить процесс на две части: внешняя среда, где обновления скачиваются, и внутренняя, где они распространяются. Между ними ставят «зону загрузки» - отдельную машину или сегмент, куда обновления попадают первым шагом и где их дополнительно проверяют. Затем пакеты импортируются на внутренний сервер обновлений (часто это выделенный серверный узел в стойке).

Хранение и откат

Держите несколько версий обновлений, чтобы можно было быстро откатиться, если после импорта начались ложные срабатывания или упала производительность. Обычно хватает 2-4 «срезов»: последний рабочий, предыдущий и еще 1-2 запасных.

В регламенте лучше сразу указать, сколько версий хранить и как долго, где хранить (на сервере обновлений и в резервной копии), кто имеет право на откат, и как фиксируется причина и итог (для аудита).

Инфраструктура управления и журналирования в закрытой сети

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

Консоль управления: где и как разместить

Консоль нужна не «для галочки». Через нее задают единые политики, видят покрытие по узлам, контролируют актуальность баз и получают отчетность для ИБ. В закрытой сети чаще всего консоль ставят на выделенный сервер внутри контура или на отдельную виртуальную машину в том сегменте, где больше всего клиентов.

Логи и события лучше хранить централизованно, иначе вы потеряете историю при переустановке узла или переполнении локального диска. Практичный вариант - база событий и журналов на отдельном сервере в контуре, со сроком хранения (например, 90-180 дней) и резервным копированием. Если контур небольшой, допустимо хранение на сервере консоли, но только при контроле места и регулярных бэкапах.

Сегментация часто ломает «идеальную схему». Если есть несколько подсетей, филиалы или отдельные домены, продумайте, как клиенты будут находить сервер управления (DNS, статические адреса, правила межсетевого экрана), нужны ли дополнительные точки распространения обновлений внутри сегментов, будет ли один общий сервер управления или несколько - с раздельными политиками и отчетами.

Роли и доступ: минимум, без которого начинается хаос

Сразу разделите доступы, чтобы не смешивать администрирование, контроль и аудит. Обычно хватает четырех ролей:

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

Так вы заранее закрываете вопросы по ответственности, журналированию действий в консоли и готовности к проверкам.

Учет активов и расчет количества лицензий

Точный расчет лицензий в закрытом контуре начинается не с прайса, а с понятного списка активов. Если пропустить хотя бы один класс устройств (например, тестовые серверы или VDI), очень быстро начинается «докупить срочно».

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

В расчет обычно попадают рабочие ПК и моноблоки (включая «дежурные» и запасные), физические серверы и критичные роли (AD, файловые, почтовые), виртуальные машины (если лицензия считается по VM, а не по хосту), VDI и терминальные фермы (часто считают по одновременным пользователям или по хостам), тестовые стенды и песочницы, если на них есть боевые данные или доступ в контур.

Заложите резерв на рост и замены. Часто это 10-20% к текущему количеству, но лучше опираться на план: закупка новых рабочих мест, обновление серверов, пилот нового сервиса. Например, если в контуре 50 рабочих станций и 10 серверов, а раз в квартал меняете 2-3 ПК, резерв в 8-12 лицензий обычно выглядит разумно.

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

Инвентаризация должна быть простой, но полной. Минимальный набор полей: имя хоста, роль (ПК, сервер, VDI, тест), местоположение (площадка, стойка, кабинет), владелец (подразделение, ответственный), статус (в эксплуатации, резерв, временно, списан).

Отчетность для ИБ и аудита: что собирать заранее

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

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

• покрытие: сколько узлов под управлением, сколько без агента, сколько с ошибками;
• актуальность баз и модулей: версии, даты, процент устройств с просрочкой;
• инциденты: детекты, карантин, действия оператора, время реакции;
• исключения: список, кто согласовал, срок действия, причина;
• состояние политик: что включено и что запрещено менять локально.

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

Также согласуйте, кто подписывает отчеты: администратор (готовит), владелец системы или руководитель ИБ (утверждает), ответственное лицо за контур (подтверждает перенос и хранение носителей). Хранить материалы лучше там, где есть контроль изменений. Сроки хранения задайте в регламенте.

Пошагово: как внедрить антивирус в изолированном контуре

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

Рабочая последовательность выглядит так:

• зафиксируйте границы контура и ограничения: сегменты, число узлов, критичные серверы, правила для USB/носителей, расписание переносов, требования к журналам;
• выберите модель лицензии и метрику учета: по устройствам, по пользователям, по серверам, отдельно ли считаются виртуальные машины и тестовые стенды;
• разверните управление и обновления: консоль администрирования в контуре, офлайн-репозиторий, маршрут переноса баз (например, через отдельный компьютер в буферной зоне с проверкой носителей);
• настройте политики: уровни защиты, расписания сканирования, обновления из локального репозитория, исключения только по заявкам, права доступа администраторов и операторов;
• включите контроль: регулярные отчеты, алерты по устаревшим базам, контроль отключенной защиты, периодические сверки «факт vs учет».

Полезно начать с пилота на небольшой группе (например, 20-30 рабочих мест и 2-3 сервера), а затем расширять. В больнице или на производстве это снижает риск, что сканирование попадет на часы пик и помешает работе.

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

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

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

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

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

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

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

Перед закупкой и в первые месяцы эксплуатации помогает короткая проверка:

• заложите резерв лицензий и отдельный тестовый стенд;
• назначьте владельца обновлений и контрольные точки по срокам;
• опишите правила для носителей: проверка, журнал, ответственные;
• введите срок жизни исключений и регулярный пересмотр;
• по возможности автоматизируйте отчеты и сверку с реестром активов.

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

Короткий чек-лист перед закупкой или продлением

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

Проверьте пять вещей:

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

Простой тест: представьте, что ИБ просит за 15 минут показать список всех узлов с устаревшими базами и объяснить причину. Если непонятно, из какого отчета это берется и кто его подписывает, условия закупки стоит уточнить до продления.

Следующие шаги: как оформить требования и организовать внедрение

Начните с короткого, но точного описания контура. В ТЗ зафиксируйте, какие сегменты изолированы, как данные могут переноситься внутрь (носители, шлюз, выделенное окно), и какие ограничения есть по установке ПО и доступу администраторов.

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

Чтобы избежать сюрпризов после закупки, заранее запросите у вендора детали по офлайн-режиму: как подтверждается факт обновления без интернета (журналы, версии баз, подписи пакетов), как считается лицензия в изоляции (по узлам, серверам, ядрам, сроку, резерву), что будет при временной недоступности репозитория, какие требования к ОС, БД и ресурсам консоли управления, как выгружаются отчеты и логи для аудита.

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

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