Какие конкретные меры и настройки нужно внедрить, чтобы минимизировать риски информационной безопасности при переходе на VDI на базе ESXi и использовании тонких клиентов?

Всем здравствуйте! Я младший сисадмин (в основном эникей). <br/> С прошлого года наша компания (~100 сотрудников) перешла на тонкие клиенты и VDI: у нас есть сервер виртуализации VMware vSphere, на котором крутятся виртуальные рабочие места сотрудников. <br/> Раньше все офисные ПК были в домене AD, и при добавлении новой машины админ вручную добавлял её в Active Directory. Летом по поручению старшего админа я через PXE перебил и установил на каждый ПК тонкий клиент с VMware Horizon Client. Важно: на физическом компьютере стоит обычная Windows 11, но эти машины не состоят в корпоративном домене — они работают в WORKGROUP. На компьютерах настроены локальные учётные записи (в том числе локальная учётка без пароля, которой пользуются сотрудники, с автозапуском Omnissa Horizon), а сами пользователи заходят в локальную сессию и затем через Horizon Client подключаются к своим виртуальным рабочим столам. Меня беспокоит вопрос по безопасности: насколько рискованна такая схема (физические ПК вне домена, локальные аккаунты без пароля, автозапуск клиента)? Какие возможные угрозы и какие лучшие практики по организации аутентификации, учётных записей и управления тонкими клиентами/VDI в нашей инфраструктуре вы бы порекомендовали?
  • 20 марта 2026 г. 19:01
Ответы на вопрос 5
Коротко — да, текущая схема с «рабочими станциями в WORKGROUP + локальная учётка без пароля + автозапуск Horizon» рискованна. Физический клиент остаётся потенциальной точкой входа в сеть (кража/подмена образа, локальный malware, перехват сессии, кража/подмена учётных данных) и ослабляет контроль, который даёт домен/MDM. Ниже — конкретные угрозы и практические рекомендации (с приоритетами, конкретными настройками и примерами), которые можно внедрить быстро и в среднесрок/долгосрочной перспективе.

Главные угрозы
- Физический доступ/кража устройства: доступ к локальным учёткам, загрузке с USB, изменение настроек BIOS/UEFI.
- Нулевые/слабые пароли локальных учётных записей: легкая эскалация и сохранение бэкдора.
- Автологин/автозапуск клиента: сессия можно перехватить, подменить клиент, выполнить локальный код.
- Лёгкая компрометация клиента → перехват учётных данных (keylogger, скриншоты), MITM, перенаправление USB/дисков в VDI.
- Отсутствие централизованного управления/патчинга: уязвимости Windows/клиента не закрываются.
- Неправильная конфигурация vCenter/ESXi/Horizon → атакующий получает доступ к инфраструктуре VDI.

Немедленные (высокий приоритет) меры — что сделать в первую очередь
1. Запретить локальные учётки без пароля
   - Удалить/запретить локальные учётки без пароля. Отдельно разрешить только управляемые учётки с уникальными сложными паролями.
   - Политика паролей: минимум 12 символов, сочетание букв/цифр/символов, минимальный срок жизни по ситуации (ротация для сервисных/киоск-учёток).
2. Отключить автологин локального пользователя
   - Убрать автозапуск обычного Windows-пользователя. Если нужен автозапуск Horizon, делать это в сильно заизолированной «киоск»-учётке с ограниченными правами и регулярно менять её пароль централизованно.
3. Запрет USB/внешних носителей в BIOS/ОС
   - Включить Secure Boot, выставить пароль BIOS/UEFI, отключить загрузку с USB/CD. Если нельзя отключить физически — сделать политикой.
4. Сегментация сети
   - Перенести тонкие клиенты в отдельный VLAN с минимальным доступом: разрешить трафик только к Horizon Connection Server / Unified Access Gateway и DNS/ DHCP. Запретить доступ в management VLAN, к vCenter, к серверам AD и прочим сервисам.
5. Настроить firewall/ACL на уровне сети
   - Разрешать только нужные порты и адреса (Horizon: HTTPS 443, Blast 8443/UDP/TCP, PCoIP 4172 и т.д. — открыть только необходимые, через Gateway/Proxy).
6. Включить шифрование и проверку сертификатов
   - Horizon/Connection Servers, vCenter, ESXi — все с корректными выписанными/утверждёнными сертификатами (не самоподписные в проде). Включить TLS 1.2/1.3, отключить устаревшие алгоритмы.

Короткий план на среднесрочную перспективу (1–3 месяца)
1. Централизованное управление тонкими клиентами
   - Перенести устройства под управление MDM/Endpoint management (Microsoft Intune / VMware Workspace ONE / фирменный менеджер тонких клиентов). Это позволит централизованно менять пароли, обновлять софт, разворачивать политики.
2. Присоединить устройства к домену или Enroll в MDM
   - Лучшее — вернуть физические машины в AD или, если политика не позволяет, зарегистрировать в MDM/Azure AD. Это даёт централизованные GPO/политики и LAPS.
3. Управление локальными паролями
   - Внедрить LAPS для доменных машин. Если устройства не в домене — использовать альтернативы: Workspace ONE, MDM-скрипты или коммерческие решения для ротации паролей киоск-учётки.
4. MFA для доступа к VDI
   - Обязательно включить многофакторную аутентификацию на уровне Horizon (SAML/Radius/Okta/DUO) особенно для внешнего доступа и для админов vCenter/Horizon.
5. Ограничение функциональности клинета
   - Через политики Horizon отключить client drive redirection, clipboard redirection, USB redirection (или разрешать только для нужных групп), принтеры по необходимости.
6. Патчинг и EDR
   - Поставить EDR/AV на образах гостевых машин (VDI) и на управляющих серверах (vCenter, Connection servers). Обновлять ESXi и vCenter по плану.

Рекомендации по настройкам Horizon / VDI
- Включить True SSO и/или интеграцию с AD и MFA (уменьшает риск передачи паролей).
- Отключить или сильно ограничить перенаправления:
  - Client drive redirection = Disabled
  - Clipboard redirection = Disabled (или разрешать только копию текста, если нужно)
  - USB redirection = Disabled (или allow list конкретных устройств на группу)
  - Printer redirection = Разрешать через vPrint/NLA, а не прямой access
- Session timeout & disconnect:
  - Idle disconnect = 15–30 минут (в зависимости от политики)
  - Forced logoff after X time (по безопасности)
- Политики доступа:
  - Запрет многократных одновременных сессий по учетке, если нужно.
  - Ограничивать доступ по политике Horizon Apps/Desktops per AD group.
- Шифрование трафика Blast/PCoIP, принудительно TLS1.2+, отключить SSL3/TLS1.0/1.1.
- Установить Access Point/Unified Access Gateway для доступа извне и не открывать internal Connection Servers наружу.

vSphere / ESXi / vCenter — конкретные жесткие меры
- Изолировать management сеть: ESXi hosts и vCenter management на отдельной сети, доступ только с jump server и через ограниченные IP.
- Lockdown Mode на ESXi где применимо.
- Использовать vCenter role-based access и ограничить привилегии админу. Включить MFA для vCenter.
- Обновлять ESXi и vCenter по расписанию, применять VMware Security Advisories.
- Замена самоподписанных сертификатов в vCenter/ESXi на CA-подписанные.
- Включить аудит и централизованный сбор логов (syslog на SIEM).
- Рассмотреть VM Encryption для особо чувствительных рабочих столов/данных (требует KMS).

Холодная жёсткая защита на клиентской стороне (физические ПК)
- Если возможно — использовать специализированные thin/zero client OS (Linux-based/firmware) вместо полноценных Windows 11. Они легче в фиксированном режиме и сложнее скомпрометировать.
- Если Windows 11 остаётся — создать очень ограничённый «киоск» профиль (Assigned Access / Shell Launcher), убрать все лишние приложения/сервисы.
- BitLocker + TPM для местных дисков (если локально хранится что-то важное).
- BIOS/UEFI пароль, Secure Boot, отключение Boot from USB.
- Физическая защита: закрепление устройств, замки на корпусе.

Управление образами VDI и гостевых ОС
- Golden image: настроенный шаблон с EDR, обновлениями, минимальным набором ПО. После патча — пересоздать образ и развернуть.
- Удалять локальные админ-права у пользователей в гостевых VDI. Управлять обновлениями централизованно.
- Настроить snapshot / revert policy: при завершении сессии восстанавливать чистый десктоп (persistent vs non-persistent решения).
- Настроить профили пользователей (FSLogix / UEM) для управления данными.

Мониторинг, логирование и реагирование
- Собирать логи Horizon, vCenter, ESXi, Connection Server, Unified Access Gateway в SIEM (например, Splunk, Elastic, QRadar).
- Пороговые оповещения: множественные неудачные логины, аномальная активность сессий, подключение новых MAC/IP.
- EDR на endpoints/servers + сетевые IDS/IPS.
- План реагирования: как отключать скомпрометированные пользователи/устройства, как быстро деприватизировать VDI-пулы.

Политики и операционные практики (рекомендуемые значения)
- Пароли: длина >=12, сложность, истечение 90 дней (или использовать MFA + длинные пароли/семантические правила).
- Блокировка учётной записи: блокировать после 5 неудач в 15 минут.
- Idle timeout: 15–30 минут + авто-логoff после заданного времени.
- Ротация паролей киоск-учёток: автоматическая/через MDM, минимум раз в неделю/при смене персонала.
- Привилегированные учетные записи: отдельное управление, 2FA обязательна.

Пошаговый план внедрения (практичный)
1. Немедленно (1–2 недели)
   - Убрать учётки без пароля; отключить автологин.
   - Разделить сеть: выделить VLAN для тонких клиентов, закрыть доступ к management.
   - Отключить USB/drive/clipboard redirection в Horizon по дефолту.
2. Короткий срок (1–3 месяца)
   - Внедрить MDM/менеджер тонких клиентов; централизованно управлять паролями киоск-учёток.
   - Включить MFA для Horizon и админ-панелей.
   - Включить мониторинг логов, настроить оповещения.
3. Средний срок (3–6 месяцев)
   - Присоединить устройства к AD / перевести на управление Workspace ONE / Intune.
   - Перейти на специализированные thin/zero- clients либо построить безопасный kiosk-mode на Windows.
   - Обновить политики VDI, включить True SSO, шифрование VM (если нужно).
4. Долгосрочно
   - Внедрить zero-trust подход, NSX микросегментация, периодические pentest/аудит, автоматизацию развертывания пачтей и образов.

Дополнительные практические замечания
- LAPS работает для доменных машин. Если не хотите доменить — используйте MDM/Workspace ONE для автоматической ротации паролей киоск-учёток.
- Не используйте обычные рабочие аккаунты в качестве автологин-учёток.
- Контролируйте физический доступ: камеры, замки, политка пропуска.
- Тестируйте изменения в тестовом пуле VDI, прежде чем массово выкатывать.

Если нужно — могу:
- Составить конкретный чеклист настроек для Horizon (как включить/отключить нужные политики и где они в консоли).
- Подготовить пример GPO / Intune-политик для перехода Windows в kiosk-mode и отключения USB/drive.
- Помочь с планом по миграции машин в AD/MDM и внедрению LAPS/2FA.

Хочешь, начнём с оперативного чеклиста на ближайшие 7 дней (что сделать прямо сейчас)?
*анекдот про хакера и солонку в столовой* <br/> <br/> Аппаратные бекдоры программными методами не решаются, или решаются с понижением удобства. Например, злоумышленник может подменить клавиатуру/кабель (в зависимости от денежных затрат), в котором будет скрыт кейлогер плюс при должном старании, с удаленным управлением (способным набить программу для удаленной загрузки основного тела трояна). <br/> <br/> Такие проблемы решаются другими методами, типа регламентом, видеонаблюденем, обысками... <br/> <br/> p.s. 'нормальные' материнские платы позволяют загрузить свой ключ, которым можно подписывать загрузчик, т.е. в этом случае сменить жесткий диск не получится (нужно будет менять всю железку), сами данные на диске зашифрованы, ключ шифрования загружает сервер после проверки железа (не гарантия но очень много мест где злоумышленник споткнется и будет дороже атака), системы авторизации по личному карте-ключу (с железом не очень, а так системы есть по до все) или паролю
Сам по себе WORKGROUP не проблема, авторизация же на уровне Horizon/AD. Но локальная учётка без пароля при физическом доступе это дыра: любой может сесть и делать что хочет в самой винде. Минимум — настрой kiosk mode (Assigned Access) или shell replacement, чтобы кроме Horizon Client ничего не запускалось, плюс закрой BIOS паролем и отруби загрузку с USB. Ну и 802.1X на свитчах не помешает, чтобы левый ноут в сетку не воткнули.
Secure Boot (Безопасная загрузка): Самый важный механизм. Он разрешает запуск только тех загрузчиков и драйверов, которые подписаны доверенными ключами (обычно Microsoft или производителя устройства). Если злоумышленник подменит диск на другой с вредоносной ОС или другим загрузчиком, UEFI просто откажется его запускать. <br/> <br/> Связка с TPM и BitLocker: Это наиболее эффективный способ защиты именно от физической подмены. <br/> TPM (Trusted Platform Module) хранит ключи шифрования в аппаратном чипе. <br/> <br/> Если диск будет переставлен в другой компьютер или данные на нем будут изменены «снаружи», TPM заметит изменение конфигурации системы (хеша прошивки и настроек) и заблокирует доступ к ключам. Система потребует 48-значный ключ восстановления. <br/> <br/> Пароль на BIOS/UEFI: Защищает сами настройки прошивки от изменений. Без него злоумышленник может просто отключить Secure Boot и загрузиться с любого устройства. <br/> <br/> Пароль на HDD/SSD (ATA Password): Многие UEFI поддерживают установку пароля непосредственно на контроллер накопителя. Если такой диск переставить в другой компьютер, он останется заблокированным на аппаратном уровне и не даст прочитать данные без ввода пароля. <br/> <br/> Что произойдет при подмене диска? <br/> <br/> Если включен Secure Boot: Система выдаст ошибку «Security Violation» или «No Bootable Device», так как новый диск не содержит подписанного загрузчика, которому доверяет данная материнская плата. <br/> <br/> Если включен BitLocker + TPM: Даже если вы поставите старый диск обратно после манипуляций, Windows может потребовать ключ восстановления, так как «доверенная цепочка» была нарушена. <br/> <br/> Ps да и vdi у вас же не напрямую в инет торчит, нет же, ну нет...
Добавлю свои 5 копеек ко всему выше сказанному. В таких случаях у компов открыт доступ только к VDI серверу( или к белому списку внутреней инфраструктуре). Доступ можно закрыть на местной сетевой инфраструктуре (свич,роутер,фаервол). Так что никакого удаленного доступа у него быть не может. Чтобы провернуть ваш сценарий, ему еще потребуется 4g modem там поставить, если плохо ловит то еще и антену приставить к окну )) так что заменой ssd ничего не будет. Ну а могут ли вирусы с компа переходить в софт тонкого клиента этого мы уже не знаем, это уже другая история... <br/> <br/> P.S. Нету одного решения этой проблемы, если вы сделаете то, что вам посоветовали ( я насчитал до 10 советов), то будете защищены от многих проблем, хотя я думаю, что вы и парочку отсюда не сделаете :). Как показывает практика, чем больше надо делать, чтобы защитить сеть/компы, тем меньше это делают.
Похожие вопросы