Аудит образа ОС от поставщика: проверка телеметрии и служб

Почему образ ОС надо проверять до приемки партии

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

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

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

Обычно в риск превращаются:

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

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

Что заранее уточнить у поставщика и что зафиксировать письменно

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

Зафиксируйте базовые параметры ОС: версию и редакцию (например, Windows 10/11 Enterprise), язык, разрядность, схему лицензирования и дату сборки образа. Дата критична: она влияет на обновления, компоненты и набор запланированных заданий.

Попросите перечень предустановленного ПО и драйверов с версиями. Формулировка «драйверы установлены» не подходит: в протоколе должны быть названия, версии и источник (пакет производителя, корпоративный репозиторий, OEM-набор). Это помогает быстро отсеять «лишние» утилиты и понять, откуда взялись дополнительные службы.

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

Удобно закрепить все в одном документе:

• состав ОС (версия, редакция, язык, разрядность, дата сборки);
• список ПО и драйверов с версиями;
• политики и средства защиты (включая шифрование);
• ответственность за обновления, активацию и первичную настройку после поставки;
• допустимые сетевые обращения (обновления, активация, синхронизация времени), включая временные окна.

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

Подготовка стенда для аудита и фиксация исходного состояния

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

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

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

Для отчета заранее снимите базовые «отпечатки» установки:

• хэши полученного образа (если он передан отдельно) и контрольные суммы ключевых файлов;
• номер сборки ОС, редакцию, язык, дату установки;
• список установленных обновлений;
• версии BIOS/UEFI и драйвер-пака.

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

Быстрый осмотр: процессы, автозапуск и установленные компоненты

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

Начните с автозагрузки. В Windows проверьте не только вкладку «Автозагрузка» в Диспетчере задач, но и папки Startup, а также записи Run и RunOnce (для пользователя и для системы). Часто «помощники» прячутся под нейтральными названиями вроде Updater, Helper, Service Host, но ведут в странные папки.

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

Чтобы не распыляться, держите короткий порядок:

• автозапуск (Startup, Run, RunOnce);
• процессы (издатель, путь к файлу, нагрузка CPU и сеть);
• установленные приложения и компоненты (сверка со списком поставщика);
• браузеры (расширения, фоновые «помощники», автозапуск);
• фиксация (скриншоты и выгрузки списков).

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

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

Службы и драйверы: что проверять и что должно насторожить

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

Соберите базовые сведения по службам: имя, состояние, тип запуска и учетную запись (LocalSystem, NetworkService, отдельный пользователь). Большое число системных служб - нормально. Подозрительны элементы с непонятными названиями, без описания, а также с путями в Temp, ProgramData или пользовательских профилях.

Частые красные флаги:

• служба запускается автоматически и работает от LocalSystem, но никто не может объяснить зачем;
• файл службы без цифровой подписи или подпись не совпадает с ожидаемым издателем;
• нестандартный путь к исполняемому файлу (не Windows и не Program Files);
• служба создает сетевые соединения сразу после запуска;
• рядом появляются задания планировщика или записи автозапуска.

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

Быстрая фиксация в Windows (минимум для протокола):

sc query type= service state= all
driverquery /v
pnputil /enum-drivers

Отдельно оцените, нет ли агентов удаленного администрирования. Если они нужны (например, для поддержки), договоритесь, кто ими управляет, как отключается доступ и как фиксируются подключения. Если ответа нет - приемку лучше остановить до прояснения.

Запланированные задания и политики: скрытые точки запуска

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

В Планировщике заданий откройте Библиотеку и пройдитесь по папкам Microsoft и сторонним. Смотрите не только имя, но и триггеры, действия и учетную запись запуска. Особое внимание - заданиям, которые запускаются от SYSTEM или с повышенными правами.

Настораживают такие признаки:

• действие запускает PowerShell, cmd, wscript, mshta или неизвестный exe;
• путь указывает на Temp, AppData, Downloads или папку профиля пользователя;
• в аргументах есть скачивание, выполнение из сети, base64, скрытый режим;
• триггер срабатывает при входе, простое, разблокировке, подключении к сети;
• задание скрыто, без описания, или недавно создано без понятной причины.

Для выгрузки списка заданий в файл (удобно прикладывать к протоколу):

schtasks /query /fo LIST /v > tasks.txt

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

gpresult /r > gpresult.txt

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

Телеметрия и сетевые обращения: как поймать лишний трафик

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

Соберите список внешних адресов и доменов, к которым идут запросы в первые 10-20 минут. Параллельно смотрите активные подключения (например, через монитор ресурсов и netstat) и журнал DNS-запросов на вашем DNS-сервере.

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

Проверьте три места, где телеметрия часто «прячется»:

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

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

«Лишние» агенты и удаленное управление: как не пропустить

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

Проверьте, нет ли RMM-агентов, «инвентаризации», удаленной помощи и лишних VPN-клиентов. Часто они маскируются нейтральными названиями (Support, Monitor, Update Service) и имеют собственные службы и автообновление.

Быстрые признаки, что стоит копать глубже:

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

Дальше уточните, кто реально может получить доступ. Проверьте локальных пользователей и группы, политики удаленного входа, разрешения служб, а также настройки RDP. Если в образе есть SSH или серверные компоненты на рабочих ПК, это должно быть отдельно обосновано.

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

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

Частые ошибки при аудите образа и как их избежать

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

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

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

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

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

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

Как оформить результаты: протокол, уровни риска и решение о приемке

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

Хорошо работает единый формат записи для каждой находки.

Шаблон записи находки

• Идентификатор и краткое имя: например, "TelemetryService-X".
• Место: путь к файлу, имя службы/драйвера/задачи, ветка реестра.
• Точка старта: автозапуск, служба, запланированное задание, политика, драйвер.
• Наблюдение: что делает (процесс, аргументы запуска, сетевые обращения, частота).
• Доказательства: выгрузка списка, фрагмент журнала, скриншот, pcap (если снимали трафик).

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

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

Решение о приемке

Привяжите приемку к понятным критериям:

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

Пример: при приемке партии ПК для школы вы фиксируете одну лишнюю задачу, которая стартует скрытый апдейтер, и два неизвестных исходящих домена. Это «критично» до объяснения. В протоколе прикладываете журналы и pcap, запрашиваете новый образ и повторяете проверку перед подписанием актов.

Пример: приемка партии ПК и проверка образа на 1-2 дня

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

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

План на 1 день (если образ один и изменения типовые):

• 1-2 ПК оставьте без сети: снимите базовое состояние (процессы, службы, автозапуск, задания), зафиксируйте версии ОС и список установленных компонентов.
• 2-3 ПК подключите в тестовый сегмент: проверьте, какие домены/адреса вызываются после входа в систему и через 10-20 минут простоя.
• На одном ПК сделайте перезагрузку 2-3 раза: часть лишнего появляется только после второго старта или после обновления.

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

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

После правок сделайте повторную проверку на 1-2 устройствах из выборки и зафиксируйте финальное состояние: список разрешенных служб/задач, контрольные значения образа (например, хэши файлов или снимок списка ПО) и дату сборки. Это сильно упрощает спорные случаи, если в середине поставки образ внезапно меняется.

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

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

Отметьте в протоколе:

• соответствие заявленному (редакция и версия ОС, номер сборки, статус активации, обновления, язык и часовой пояс, ключевые параметры из ТЗ);
• списки «точек запуска» (процессы, автозагрузка, службы, драйверы, задания планировщика) с пометкой всего неизвестного;
• сетевое поведение в первые 30-60 минут после первого входа (домены/адреса и порты, какие процессы инициируют соединения, есть ли регулярные «звонки наружу» без обоснования);
• учетные записи и удаленный доступ (лишние локальные администраторы, включенный RDP без согласования, сохраненные пароли, сторонние средства удаленного управления и мониторинга);
• итоговую оценку риска (что допустимо, что убрать до ввода, что стоп-фактор).

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

Что делать дальше: закрепить стандарт образа и контроль поставок

Разовую проверку стоит превратить в стандарт. Иначе через пару поставок снова появится «особенный» образ, где что-то добавили «для удобства».

Начните с простого: назначьте владельца золотого образа (обычно ИТ совместно с ИБ) и зафиксируйте правила изменений. Определите, как образ обновляется: кто инициирует патчи и драйверы, где хранится эталон, как ведется журнал изменений, и что считается критичным отклонением. Полезное правило - никаких добавлений без заявки: агенты удаленного управления, «оптимизаторы», неучтенные VPN/прокси и любые сервисы с сетевой активностью.

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

Чтобы контроль не превращался в большой проект, достаточно периодических выборочных проверок:

• при каждой поставке проверять 1-2 устройства по вашему чеклисту;
• раз в квартал повторять сетевой контроль на типовой рабочей станции;
• сравнивать состав служб, задач и автозапуска с эталоном по отчету, а не «на глаз»;
• фиксировать отклонения и требовать корректировки образа у поставщика.

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

Ориентир простой: если изменения в образе нельзя объяснить и повторить в виде контролируемого пакета, это не обновление, а риск. "