Патч-менеджмент стороннего ПО без SCCM: офлайн и контроль

Зачем нужен патч-менеджмент для стороннего ПО

Самые частые уязвимости на рабочих ПК находят не в Windows, а в массовых программах: браузерах, Java и PDF-ридерах. Они постоянно обрабатывают "чужой" контент - сайты, файлы, вложения из почты. Поэтому пропущенный патч быстро превращается в реальный риск: иногда достаточно открыть ссылку или документ.

Ручные обновления "когда будет время" почти всегда дают разнобой. На одном ПК ставят другую редакцию (x86 вместо x64), на другом остаются старые плагины или расширения, на третьем не хватает прав, и установка молча откатывается. Отдельная боль - перезагрузки и занятые файлы: пользователь не закрыл браузер, установщик не смог заменить компоненты, и версия осталась прежней.

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

Практический патч-менеджмент стороннего ПО без SCCM - это не про то, как "запустить инсталлятор". Это про четыре результата, которые можно подтвердить:

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

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

Определяем периметр и критерии успеха

Чтобы работа не превратилась в бесконечное "подкрутим еще вот это", сначала зафиксируйте периметр: что обновляем и на каких ПК. Это экономит время и упрощает разговор с аудитором или службой ИБ.

Начните с перечня приложений, которые чаще всего дают критичные уязвимости и при этом стоят почти везде. Обычно это браузеры (и их компоненты), Java (если она действительно нужна бизнесу), PDF-ридеры, а также плагины и вспомогательные модули. Сразу договоритесь, что считается "приложением": отдельный плагин в браузере - тоже объект обновления, если он может быть точкой входа.

Дальше определите классы ПК. Офисные компьютеры и ноутбуки обычно переживают перезагрузку и могут обновляться по расписанию. Киоски, терминалы, рабочие станции с 24/7 нагрузкой требуют окон обслуживания, плана отката и иногда отдельного набора настроек (например, отключить автообновление, но разрешить установку только вашего пакета).

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

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

Мини-сценарий: в закрытом контуре вы обновляете PDF-ридер на 200 офисных ПК и 20 киосках. Для офисных успех - установка плюс перезагрузка ночью. Для киосков - установка без смены киоск-режима и без простоя днем. Это разные критерии, и их лучше согласовать заранее.

Базовая подготовка перед обновлениями

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

Инвентаризация: что реально стоит на ПК

Соберите точный список: какие браузеры, какая Java (JRE/JDK, 32 или 64-bit), какие PDF-ридеры и плагины, и на каких группах ПК они встречаются. Важно фиксировать не только название, но и версию, разрядность и способ установки (MSI/EXE, per-user/per-machine). В одной организации часто живут две ветки одного продукта, и это напрямую влияет на пакет обновления.

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

Целевые версии и окно обслуживания

Целевые версии выбирайте как поддерживаемые и проверенные на совместимость. Это не всегда "самое новое". Сразу определите окно обслуживания и правило перезагрузки: когда можно закрывать приложения, сколько времени даете пользователю, что делаете с компьютерами, которые были выключены.

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

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

Варианты доставки обновлений в изолированных сетях

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

Три практичных схемы

Если сеть закрытая, но единая, самый быстрый старт - централизованная папка с пакетами на внутреннем файловом ресурсе (SMB). Администратор публикует установщики и скрипты, а ПК забирают их по расписанию через GPO, планировщик задач или ваш агент.

При полном air-gap чаще работает перенос на носителе. Пакеты привозят на согласованной защищенной флешке или диске, затем выкладывают в локальный репозиторий внутри сегмента (на отдельном ПК или сервере). Важно, чтобы этот репозиторий был единственным источником правды, иначе версии быстро разъедутся.

Если обновления регулярные, удобнее поднять отдельный сервер обновлений в изолированном контуре и сделать внутренний кэш. По сути это "внутренний магазин": вы один раз загружаете, проверяете и публикуете пакеты, а клиенты берут их по LAN. В крупных организациях под такой узел логично выделять надежное железо с поддержкой и запасом ресурсов, например сервер из класса GSE S200 Series.

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

Доступ к пакетам и журналирование

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

Как готовить пакеты обновлений безопасно и повторяемо

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

Откуда брать установщики и как фиксировать источник

Если у вендора есть корпоративный канал (офлайн MSI, LTS/ESR ветка, админ-дистрибутивы), используйте его. Для браузеров это часто проще и надежнее, чем обычный онлайн-установщик, который в закрытом контуре не скачает нужные файлы. Для Java и PDF-ридеров тоже ищите офлайн-дистрибутивы, а не веб-загрузчики.

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

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

Ошибки между x86 и x64, а также между языковыми сборками - самые частые. Разделяйте такие пакеты физически: отдельные папки или отдельные "пакеты" в вашей системе доставки, с понятным именованием.

Минимальная структура и пример

Удобно держать структуру вроде "Vendor - Product - Version - Arch - Lang". Например, для обновления PDF-ридера в закрытом контуре: отдельный каталог для x64 ru-RU, отдельный - для x64 en-US, и отдельная папка для документации.

Если вы поставляете ПК и серверы в организации (как это часто делают системные интеграторы уровня GSE.kz), такой порядок заметно упрощает поддержку: инженеру проще увидеть, что именно установлено, чем проверено, и как повторить установку без импровизации.

Пошагово: как развернуть обновления без SCCM

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

Способ A: PowerShell или bat с тихой установкой

Для точечных обновлений или пилота начните со скрипта. Для MSI обычно достаточно msiexec, для EXE нужны ключи тихой установки.

MSI лучше ставить без окон и с логом. Полезные коды возврата: 0 (успех), 3010 (успех, нужна перезагрузка). Для EXE ключи зависят от вендора, часто встречаются /S, /quiet, /qn, /norestart. Если документации нет, проверьте "setup.exe /?" или параметры, которые вы фиксируете в карточке пакета.

Чтобы установка была повторяемой, скрипт обычно делает пять шагов: проверяет текущую версию, запускает установку с ожиданием, пишет код возврата и лог в локальную папку, затем повторно проверяет версию и отдельно отмечает случаи 3010 (перезагрузка по плану).

Способ B и C: через GPO или Планировщик заданий

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

MSI ставьте через msiexec: он предсказуем по логам и кодам. С EXE нужна аккуратность: одинаковый ключ /S у разных производителей может вести себя по-разному.

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

Контроль успешности установки: что проверять и как

Ключевая часть процесса - доказуемо понять, что именно обновилось, где не обновилось и почему. Фразы вроде "установилось" недостаточно, особенно когда повторная доставка пакета занимает время.

1) Версия: до и после

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

Для браузеров и PDF-ридеров удобно заранее фиксировать ожидаемую версию и сравнивать с фактом на ПК. Для Java отдельно проверяйте, не остались ли старые ветки рядом - это частая причина "вечных" уязвимостей.

2) Статус установки: коды возврата и логи

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

Для MSI включайте подробный лог (например, через ключи /L*v). Для EXE используйте штатные ключи логирования, если они есть. Практика, которая хорошо работает в закрытом контуре: складывать логи на каждом ПК в одну папку (например, C:\ProgramData\PatchLogs), а потом собирать их на сервер при следующем подключении.

Не забывайте про удаление уязвимых хвостов. Пример: после обновления Java убедитесь, что старые JRE/JDK действительно удалены, а не остались параллельными установками.

Финальный шаг - простая сводка. Обычно хватает CSV: имя ПК, продукт, версия до, версия после, код возврата, статус (OK/Reboot/Fail), время. На практике это быстро показывает несколько "проблемных" машин, которым нужен перезапуск или ручная чистка.

Частые ошибки и ловушки

Ошибки в обновлениях часто выглядят как "все прошло", а по факту на части ПК остаются старые уязвимые компоненты.

Путают каналы и ломают совместимость

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

Обновляют поверх, оставляя уязвимые хвосты

Типичный пример - Java или PDF-ридер обновился, но старая версия осталась рядом (плагин, runtime, отдельный компонент). Сканер уязвимостей продолжает ругаться, и это не ложное срабатывание. Заранее решите, входит ли в правила установки удаление предыдущей версии, чистка устаревших компонентов и запрет параллельных веток пользователями.

Игнорируют права и UAC

Тихий режим не отменяет контекст запуска. Если пакет требует повышенных прав, а его запускают от пользователя, вы получите ошибку или, хуже, "успех" без фактической установки. Проверьте заранее: запуск от имени SYSTEM или админа, права записи в Program Files и реестр, корректные ключи тихой установки.

Не учитывают запущенные приложения

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

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

Если пакет попадает в закрытый контур через перенос, его легко перепутать, повредить или подменить. Минимальная дисциплина: проверка подписи и контрольной суммы, тест на пилотной группе, фиксация ожидаемой версии до и после, журналирование кодов возврата.

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

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

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

Перед запуском

Зафиксируйте состав цикла: какое ПО обновляете и до каких версий, включая редакцию (например, ESR или обычная ветка) и поддерживаемые ОС. Затем проверьте сами пакеты: нужная разрядность, тип установщика (MSI/EXE), параметры silent, а также подпись и хэш до передачи в закрытый контур. Если есть шлюз или карантинная зона, убедитесь, что файл не был пересобран или переупакован по пути.

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

Минимум, который должен быть готов:

• список ПО и целевых версий на цикл;
• пакеты проверены (подпись/хэш, разрядность, параметры silent);
• согласовано окно обслуживания и оповещение.

После запуска

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

Для критичных рабочих мест держите план восстановления. Идеально - откат до предыдущей версии или снапшот. Минимум - понятная инструкция, как быстро вернуть работоспособность (удалить проблемное обновление, поставить проверенную версию, временно отключить автозапуск обновлений).

Пример сценария: обновляем браузер, Java и PDF-ридер в закрытом контуре

Условия: 200 рабочих ПК в домене, интернет отсутствует, обновления раз в месяц. Цель простая: закрыть известные уязвимости в браузере, Java и PDF-ридере и подтвердить это цифрами.

Сначала собираете фактические версии. Один раз готовите скрипт инвентаризации (PowerShell или WMIC), который снимает версию браузера, Java Runtime и PDF-ридера, плюс имя ПК, подразделение, дату. Отчет складываете в CSV на внутреннем файловом ресурсе.

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

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

Запуск делаете волнами, чтобы не получить массовый простой. Обычно хватает пилота на 10-15 ПК с наблюдением 1-2 дня, затем первой волны на 30-40% типовых машин, затем второй волны на оставшиеся ПК, плюс отдельное окно для критичных рабочих мест. Исключения (несовместимости) уходят в отдельный план.

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

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

Если парк типовой (одинаковые модели ПК и стандартизированные образы), волны проще привязывать к этим стандартам. Тогда пилот быстрее выявляет реальные различия, а не случайные "особенности" отдельных машин.

Следующие шаги: как превратить разовые обновления в процесс

Разовые кампании быстро превращаются в "пожарные" работы. Чтобы процесс стал предсказуемым, закрепите короткий регламент и повторяйте его по циклу.

Закрепите правила один раз

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

Автоматизируйте минимум, который дает эффект

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

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