Цель статьи — рассказать про продукт и его архитектуру. По сути то, что постоянно рассказывают наши технические пресейл-инженеры нашим партнерам и заказчикам.
Немного покидаемся помидорами в «конкурентов», совсем чуть-чуть. Куда без этого :D
Спойлер: про вирус в статье ничего нет, кроме этого предложения.
Немного про команду
Так сложилось исторически, что внутри большого интегратора IBS завелся Департамент продуктового развития и производства. Раньше его еще неофициально называли Interlab.
Сотрудники этого департамента занимаются исследованием перспективных технологий, проверкой гипотез, тестированием различных решений и, как не сложно догадаться, созданием собственных продуктов. Собственно, так была создана линейка продуктов, в названии которых присутствует слово «Скала».
Сегодня речь будет идти о программном продукте — VDI-решении (virtual desktop infrastructure) Скала-Р Виртуальное Рабочее Место. Сокращенно — Скала-Р ВРМ.
Почему мы решили сделать VDI?
Все предельно просто. Мы верим в эту технологию. У нас есть опыт как внедрения VDI, так и участия в ее разработке. Проекты внедрения VDI не такие простые, так как затрагивают работу многих пользователей. Но нам кажется, что время VDI пришло. Мы видим спрос на такие решения на российском рынке. Многие заказчики стали учитывать санкционные риски, у некоторых даже есть KPI по импортозамещению. Ряд организаций уже давно активно используют подобные продукты западных производителей (самые популярные — Citrix и VMware). Другие ничем подобным не пользовались, но преимущества технологии осознают и готовы сделать ставку на отечественные решения.
Наша команда уже не первый раз разрабатывает VDI-решение. Вместе с коллегами из Virtuozzo (подразделение Parallels, которое занимается виртуализацией) мы разработали совместно за 4 года продукт для виртуализации рабочих мест — Parallels VDI. В этом сотрудничестве наша команда занималась формированием технических и бизнес-требований к продукту. Наш партнер превращал требования в код. Особенностью этого продукта было использование контейнерной виртуализации Windows, которую разработала Parallels. Microsoft в то время о собственных контейнерах даже не думала. Продукт имел свои плюсы, были и технические трудности (в том числе из-за контейнеров). В конечном итоге мы провели сертификацию ФСТЭК Parallels VDI и Virtuozzo Containers for Windows. Провели несколько внедрений. К сожалению, по ряду причин продукт прекратил существование. Права на код остались у партнера, из-за чего сами развивать продукт дальше мы не имели права. Однако интерес к отечественному VDI остался.
Кроме совместной разработки Parallels VDI, у нас есть богатый опыт реализации проектов по консолидации рабочих мест с использованием решений Citrix и VMware. В общем, наша команда видела, пожалуй, все, что творится «под капотом» VDI-решений. Мы хорошо знаем, как они должны быть устроены и чем отличаются от простой виртуализации.
Всем известно, как быстро в нашей стране разрабатываются отечественные решения из open source. Возможно, в этом ничего страшного нет, но наш опыт показал, что на рынке часто происходит подмена понятий. Системой VDI могут назвать продукт, в котором все делается за счет «ручного привода»: администратор создает виртуальную машину (ВМ), администратор передает IP-адрес пользователю, пользователь подключается по протоколу по инструкции к конкретной ВМ. Даже минимальная автоматизация жизненного цикла ВМ отсутствует.
Да, для малых организаций этого может быть достаточно. Но называть это промышленным VDI-решением категорически нельзя!
Наблюдая такое безобразие, мы попытались сформулировать гигиенический минимум функций промышленного VDI-решения. Который, кстати, в том числе помог нам в разработке Скала-Р ВРМ.
Надо признать, что не все собирают что-нибудь из open source на коленке. Видели товарищей, без стеснения совести предлагающих в государственных организациях использовать испанский VDI, который умеет интегрироваться с OpenNebula. Признаться честно, мы не знаем, насколько он хорош. Но то, что его нет в реестре отечественного ПО — это факт.
Интерес к отечественному VDI есть. Есть и предложение, хотя по опыту у многих отечественных разработчиков все работает только на слайдах в PowerPoint. Очевидный вывод — надо сделать свой хороший промышленный VDI, который будет максимально близок к мировым лидерам в этой области.
Кроме того, к моменту принятия решения мы уже разрабатывали собственную систему управления виртуализацией «Скала-Р Управление». Так что создать свой VDI с собственной системой управления виртуализацией — решение логичное и очевидное.
Итак, в конце 2016 года мы усилили нашу команду и начали собственную разработку с нуля. Вся кодовая база была под нашим контролем, писали код преимущественно на Python.
Наш прошлый опыт дал нам крутой буст. Так что побежали мы быстро.
Что такое Скала-Р ВРМ
VDI-решение IBS Скала-Р Виртуальное Рабочее Место (ВРМ) — это программный комплекс для виртуализации рабочих мест пользователей.
Назначение:
- повысить уровень информационной безопасности,
- снизить стоимость обслуживания рабочих мест сотрудников за счет централизации управления,
- снизить время подготовки новых рабочих мест,
- обеспечить плавный переход на использование отечественных ОС в рамках плана по импортозамещению.
Наше решение позволяет организовать виртуальные рабочие места, функционирующие на серверных мощностях в контролируемом периметре центра обработки данных. Подключаться к ним можно с защищенного устройства доступа на отечественной ОС.
Целевые потребители — средние и крупные промышленные предприятия, государственные и коммерческие организации, госкорпорации, региональные и федеральные ведомства и органы власти.
Архитектура
В прошлой статье, где мы рассказывали о нагрузочном тестировании на 16000 пользователей, мы уже затрагивали архитектуру решения. Тем кто ее не читал, рекомендую ознакомиться с разделом «Этапы подключения пользователя в виртуальный рабочий стол». Там достаточно подробно описано, как компоненты взаимодействуют в сценарии авторизации и подключения пользователя.
В этой статье подробнее рассмотрим основные функции компонентов Скала-Р ВРМ.
Схему можно увидеть в самом начале статьи. Компоненты будем рассматривать слева направо. Но сперва стоит сказать о функции, которая есть у всех компонентов нашего VDI-решения — контроль целостности. Как во время запуска компонента, так и систематически производится проверка его целостности (время проверки можно настраивать). Если целостность нарушена — компонент прекратит работу.
Клиент ВРМ — клиентское ПО, которое устанавливается на устройство доступа пользователя. Представляет графический интерфейс взаимодействия конечного пользователя с инфраструктурой VDI. На момент написания статьи Клиент ВРМ есть для следующих ОС (список пополняется в зависимости от потребностей партнеров и заказчиков):
- KasperskyOS for Thin Client;
- Альт 7 СПТ, Альт 8 СП, Альт 8;
- Astra Linux Smolensk, Astra Linux Orel;
- GM-Box;
- Windows 7 и выше.
- Формирование hardware ID (HWID) для авторизации устройства доступа. Во время запуска Клиент собирает информацию об устройстве, на котором запущен. На основе неизменяемых аппаратных параметров формируется HWID. При подключении к Диспетчеру подключений происходит авторизация устройства доступа: Клиент ВРМ передает HWID и информацию об устройстве, Брокер-менеджер производит авторизацию устройства согласно настроенной политике.
- Взаимодействие со смарт-картой при авторизации по сертификату. Если настроена авторизация по сертификату или двухфакторная авторизация, Клиент ВРМ «общается» со смарт-картой напрямую, используя библиотеку производителя смарт-карт. На текущий момент поддерживаются все широко распространенные в России устройства.
- Смена пароля пользователя. Если во время авторизации оказалось, что пароль пользователя просрочен, Клиент ВРМ отображает экран смены пароля. Важная функция для пользователей, у которых VDI — единственное окно в корпоративную сеть.
- Настройка и запуск протокола доставки рабочего стола. Клиент ВРМ позволяет пользователю настроить проброс принтеров, смарт-карт, локальных дисковых ресурсов, выбрать монитор и режим отображения удаленного рабочего стола и т.д. Некоторые из настроек будут работать, только если администратор разрешил их. Когда настает момент подключения в виртуальный рабочий стол, Клиент ВРМ формирует параметры запуска используемого протокола и запускает его.
- Опциональное шифрование трафика до Диспетчера подключений. Причем защищается как управляющий трафик, так и трафик протокола доставки рабочего стола (дополнительно к защите самого протокола). Данная функция не сертифицирована ФСБ. Поэтому если стоит задача аттестации, требуется дополнительно сертифицированное средство защиты канала от Клиента ВРМ до Диспетчера подключений. Встроенную защиту в таком случае можно отключить.
Протокол доставки виртуального рабочего стола — исполнительный механизм, доставляющий картинку на устройство доступа, а управляющие воздействия пользователя в виртуальный рабочий стол в ЦОДе. От возможностей данного протокола зависит набор сервисов, которые будут работать (проброс принтеров, общий буфер обмена, смарт-карты и т.д.). И как они будут работать.
Собственного протокола доставки рабочего стола у нас пока нет. Поэтому осуществляем поддержку существующих. Используем разные протоколы для подключения в виртуальные рабочие столы с разными ОС:
- ВРМ на Linux — RX@Etersoft,
- ВРМ на Windows — RDP.
Возможности протоколов представлены в таблице ниже:
Как видите, для рабочих столов на Linux доступны не все функции, имеющиеся в Microsoft RDP из коробки. Главный критерий, по которому в свое время мы выбрали RX@Etersoft — это возможность проброса смарт-карты как известного устройства. В таком случае смарт-карта видна и в устройстве доступа, и в виртуальном рабочем столе. А это важно, если используются защищенные тонкие клиенты, в ОС которых пользователь авторизуется также по сертификату со смарт-карты. Если смарт-карта не будет видна локально, устройство заблокируется.
- SPICE не позволяет реализовать сквозную авторизацию от VDI-клиента до виртуального рабочего стола.
- SPICE пробрасывает все устройства как сырые USB. Т.е. сетевой трафик с устройством, который передается по USB-каналу, начинает передаваться по сети в виртуальный рабочий стол и обратно. Это приводит к увеличению трафика и к отсутствию проброшенных устройств в ОС устройства доступа. Эта технология, кстати, не позволяет пробрасывать сетевые принтеры, настроенные на устройстве доступа.
- Смарт-карты также пробрасываются как сырые USB-устройства. Как следствие, локально на устройстве доступа их видно не будет. На защищенных устройствах с авторизацией по сертификату так работать не получится.
Если на данный момент в SPICE что-то улучшилось, просим поделиться в комментариях.
Настраивается протокол не только Клиентов ВРМ на устройстве доступа, но и в виртуальном рабочем столе при помощи нашего Агента ВРМ, до которого мы скоро дойдем.
Диспетчер подключений — компонент, терминирующий на себе подключения пользователей. Это прокси, который передает управляющий трафик брокер-менеджерам, а трафик протокола доставки рабочего стола в виртуальный рабочий стол. Размещать его стоит в ДМЗ как пограничный компонент.
На Диспетчерах подключений настраивается одна из четырех политик аутентификации:
- по паре логин-пароль;
- по сертификату;
- двухфакторная аутентификация;
- или логин-пароль, или сертификат.
Причем можно указать разные политики для разных диспетчеров. Так, указывая разные Диспетчеры подключений в конфигурационном файле Клиента ВРМ, можно настроить разные политики для разных пользователей. Обычно этого не требуется, и настраивается одна политика для всех.
Отказоустойчивость Диспетчеров подключений реализована очень просто. В Клиенте ВРМ указывается их список. Клиент ВРМ подключается к первому из списка, если не удается — ко второму и т.д.
Отсюда возникает законный вопрос: как происходит балансировка пользователей между Диспетчерами подключений, если пользователей десятки тысяч? Собственный балансировщик в планах развития, поэтому пока используем сторонний, который пулирует соединения пользователей на разные Диспетчеры подключений. А чтобы это можно было делать эффективнее, через API можно получать коэффициент текущей загруженности Диспетчера подключений по шкале от 0 до 1.
Опыт показал, что один Диспетчер подключений выдерживает около 2000 сессий пользователей. Если инсталляция на чуть большее количество пользователей, можно административно для части пользователей указать Диспетчеры подключений в конфиге Клиента ВРМ в одном порядке, для другой части пользователей — в другом порядке.
Большая часть функционала замкнута на этом компоненте. Боюсь, всего мы здесь не опишем. Попробуем выделить основное:
- авторизация устройств доступа. После получения от Клиента ВРМ через Диспетчер подключений HWID брокер-менеджер проверяет, разрешено ли этому устройству подключение. Для неизвестных устройств доступа есть выбор из двух политик — разрешать подключение или запрещать. Если настроен запрет, устройство доступа будет занесено в базу, после чего администратор должен вручную разрешить подключение с данного устройства. Также администратор может запретить подключаться с конкретного устройства. Или система может его временно заблокировать по неуспешным попыткам авторизации пользователей (если перебирают логин-пароль). Нужно заметить, что пока не пройдет успешная авторизация устройства доступа, пользователь не увидит окна ввода данных для аутентификации и авторизации.
- работа с внешним LDAP-каталогом. Чтение из LDAP при: назначении пользователей и их групп на рабочие столы; формировании списка доступных рабочих столов (проверяется членство в группах). Осуществляется авторизация пользователя и обработка результата авторизации. Смена пароля пользователя в LDAP (на самом деле AD или связка LDAP/Kerberos).
- соблюдение парольной политики пользователя. В системе есть собственная парольная политика, регламентирующая парольный алфавит, сложность, длину, число неуспешных попыток авторизации, срок действия пароля и т.д. Некоторые параметры дублируют такие же параметры LDAP-каталога. Например, число неуспешных попыток авторизации. В таком случае срабатывает политика, настроенная строже. Если это политика Скала-Р ВРМ, пользователь будет заблокирован по неуспешным попытка авторизации только в нашей системе, и администратор сможет его вручную разблокировать не обращаясь к LDAP-каталогу. Если сработала политика LDAP, придется разблокировать пользователя там.
- взаимодействие с системой управления виртуализацией Скала-Р Управление. Скала-Р ВРМ ничего не знает об оборудовании, на котором работают виртуальные рабочие столы. Система оперирует API Скала-Р Управление. Объединяющим объектом этих систем является пул ресурсов — логический сегмент ресурсов, в рамках которых выделены CPU, RAM и дисковая емкость. Пулы рабочих столов живут в рамках данных объектов — пулов ресурсов; Кстати, уже в летнем релизе мы сделаем в Скала-Р Управление интеграцию с VMware и OpenStack, что позволит использовать наш VDI совместно с этими системами виртуализации.
- автоматизация жизненного цикла виртуальных рабочих столов. Про эту часть отдельно будет ниже.
- исполнение управляющих воздействий администратора. Возможности администратора довольно широкие. Можно перевести рабочие столы в режим обслуживания, можно принудительно отключить пользователя от рабочего стола, подключиться в сессию пользователя для оказания технической поддержки (если пользователь разрешит), управлять питанием виртуальных рабочих столов, отправлять сообщения пользователям (отобразится и внутри виртуального рабочего стола, и в Клиенте ВРМ, чтобы точно никто не пропустил). И это не полный список возможностей.
Брокер-менеджер — это компонент, который взаимодействует со всеми остальными компонентами Скала-Р ВРМ и управляет ими.
LDAP комментариев не требует. В любой организации есть LDAP каталог в качестве централизованной системы управления учетными записями пользователей. Мы поддерживаем интеграцию с Microsoft Active Directory и линуксовыми реализациями LDAP/Kerberos.
PostgreSQL — конфигурационная база для хранения данных системы. Можно использовать российскую СУБД Postres Pro, даже сертифицированную. Однако обычно достаточно ванильного.
Агент ВРМ — ключевой компонент по управлению и подготовке виртуального рабочего стола. Устанавливается на этапе подготовки шаблона, после чего может обновляться из веб-панели администратора.
На наш взгляд, именно этот компонент критически необходим для автоматизации подготовки рабочего стола. Без него обеспечить адекватное управление рабочим столом (ввод в домен, настройку firewall, настройку разрешений на проброс устройств и т.д.) просто невозможно. А если управление осуществляется вручную, без агента, такое решение назвать VDI нельзя. Поэтому, наличие этого «засланного казачка», обычно отличает промышленное VDI-решение от собранного на коленке «ручного привода».
Функции, которые выполняет Агент ВРМ:
- Указание hostname. Виртуальные рабочие столы именуются автоматически, по заданной администратором маске. Кроме имени виртуальной машины, Агент настраивает таким же ее hostname.
- Добавление виртуального рабочего стола в домен (в том числе рабочих столов Linux) или настройка авторизации в LDAP/Kerberos. В случае использования Active Directory администратор может указать конкретный OrgUnit, куда будут добавляться учетные записи виртуальных рабочих столов.
- Подготовка к подключению пользователя. Перед каждым подключением, Агент ВРМ получает от брокер-менеджера команду на подготовку виртуального рабочего стола, которая включает:
- настройка серверной части протокола доставки виртуального рабочего стола по полученным от брокер-менеджера политикам (например, если запрещен администратором проброс локальных папок, как бы пользователь ни старался, работать он не будет т.к. отключен на серверной стороне протокола);
- добавление пользователя в локальную группу — для Windows может быть “remote desktop users” (локальный пользователь) или администратор, для Linux специальная группа для протокола RX;
- настройка firewall — Агент ВРМ открывает определенный порт в firewall для получения подключения с Диспетчера подключений.
- Исполнение команд от брокер-менеджера. Например, при инициализации подключения в сессию пользователя Агент ВРМ показывает пользователю окно с запросом разрешения на подключение и поднимает VNC-сервер, к которому администратор подключается из веб-консоли; по окончании сеанса VNC сервер выключается. Или отображение отправленного администратором сообщения.
- Обновление Агента ВРМ на новую версию. Если версия инсталляции повысилась, а Агент остался на старой, у администратора будет об этом индикация в веб-интерфейсе. Может быть инициировано обновление Агента из веб-консоли управления.
Скала-Р Управление. Наша система управления платформой виртуализации. На рисунке компонент изображен монолитно, т.к. основное внимание в данной статье уделяется системе VDI. На самом деле там также есть отказоустойчивость, возможность масштабирования и распределение нагрузки.
В рамках данной статьи не будем затрагивать детально возможности этого продукта. Если будет интересно, что он умеет, напишите в комментарии — подготовим отдельную статью.
Агент Скала-Р Управление. Компонент на хосте виртуализации, который транслирует команды Скалы-Р Управление гипервизору и собирает данные с хоста. Подробнее — отдельной статьей, если будет интерес.
Автоматизация жизненного цикла виртуальных рабочих столов
Виртуальные рабочие столы существуют только в рамках пулов рабочих столов. Пулы рабочих столов нужны, чтобы соотнести размещение ВМ в пуле ресурсов системы управления виртуализацией. Есть несколько типов пулов рабочих столов:
- персонализированный,
- полуавтоматический,
- сессионный.
Рассмотрим каждый по отдельности.
Персонализированный пул рабочих столов
Данный пул характеризует минимальная автоматизация и ручное создание под каждого пользователя виртуального рабочего стола из шаблона руками администратора.
Сценарий использования — рабочие столы для руководства или сотрудников с очень специфичным набором ПО.
Посмотрим настройки персонализированного пула:
Как видите, в настройках даже нельзя задать шаблон рабочего стола. Все потому, что каждый рабочий стол создается администратором по отдельности.
Из параметров, заслуживающих отдельного внимания:
- тайм-аут неактивности — время неактивности пользователя внутри виртуального рабочего стола, по истечении которого пользователь будет отключен от рабочего стола и разлогинен в Клиенте ВРМ;
- тайм-аут выключения — считается с момента отключения пользователя от виртуального рабочего стола (самостоятельно или по тайм-ауту неактивности). Когда тайм-аут выключения истекает, рабочий стол выключается. Если стоит нулевое значение, тайм-аут выключен;
- Сервисы — набор зависит от выбранного «протокола». То, как эти параметры используются мы описывали в рамках Агента ВРМ.
Меню создания персонализированного рабочего стола:
Тут уже присутствует выбор шаблона и учетной записи пользователя. Персонализированные рабочие столы назначаются на конкретные учетные записи пользователей.
Персонализированный (авто) пул рабочих столов
Однажды нас попросили сделать персонализированные рабочие столы, но так, чтобы не создавать каждый рабочий стол по отдельности. Чтобы раз создал на всех из одного шаблона, и все. Лень, знаете, — двигатель прогресса.
Сценарий использования: набор персонализированных рабочих столов с одинаковым ПО.
Настройки пула:
Тут настроек уже поприбавилось. Рассмотрим отличительные параметры:
- маска именования — при автоматическом создании именуем рабочие столы согласно маске;
- максимальное количество — верхний предел по количеству рабочих столов в пуле;
- минимальное количество — сколько система будет поддерживать созданных в пуле виртуальных рабочих столов. Если администратор удалит рабочие столы, система создаст автоматом новые до «минимального количества»;
- шаблон — собственно шаблон виртуального рабочего стола, который используется при автоматическом создании рабочих столов в этом пуле;
- группа пользователей — доступ к данному пулу уже определяется по членству в группе.
Сценарий работы данного пула следующий: администратор создает данный пул, система автоматически создает «минимальное количество» виртуальных рабочих столов, которые пока никем не заняты; когда пользователь подключается первый раз, за ним резервируется конкретный виртуальный рабочий стол. Все, рабочий стол, на который назначен пользователь, стал персонализированным. Учетная запись пользователя намертво ассоциируется с конкретным столом, пока администратор не разлучит их.
Если минимальное количество меньше максимального, возможен сценарий, когда все свободные рабочие столы из «минимального количества» уже разобраны. В таком случае для конкретного пользователя система автоматом создаст виртуальный рабочий стол. Так до тех пор, пока не упремся в «максимальное количество».
Сессионный пул рабочих столов
Самый интересный пул с максимальной автоматизацией.
Сценарии использования: типовые стандартизированные рабочие столы пользователей; географическое распределение пользователей по часовым поясам и сменный график пользователей.
Настройки пула:
Рассмотрим отличительные параметры:
- Режим создания — выбор из:
- полные клоны — соответственно, каждый рабочий стол — полноценная виртуальная машина;
- связанные клоны — Linked Clones в всем известной терминологии. Используемая платформа виртуализации позволяет задействовать данную технологию, но реализована он не так же как у VMware. Есть ограничения, которые мы обошли реализовав хороший кусок программной логики.
- горячий резерв — число свободных рабочих столов, которое система держит в готовом к подключению состоянии. Параметр нужен для минимизации времени ожидания пользователя. Важно заметить, что рабочие столы из «минимального количества», еще не занятые пользователями, считаются частью горячего резерва. Эти два параметра позволяют например, на отдел из 50 сотрудников сразу создать 50 рабочих столов и указать «горячий резерв», например, 10. Тогда после подключения 41 сотрудника система создаст 51 рабочий стол (чтобы в горячем резерве было 10 шт.). Так можно обезопасить себя от изменения числа одновременно работающих сотрудников данного отдела;
- действие при завершении сессии — если включен тайм-аут нективности, становится доступно:
- выключение — по сути оставляет рабочий стол зарезервированным за пользователей и только выключает его. Однако остаются инструменты присущие только сессионному пулу, как например, пересоздание всех рабочих столов из нового шаблона;
- удаление — после работы пользователя удаляем его рабочий стол; система по настроенному «минимальному количеству» и «горячему резерву» создает новые;
- перевод в горячий резерв — происходит дерегистрация пользователя от рабочего стола, который считается снова частью «горячего резерва». Следующий подключающийся пользователь может быть назначен на этот рабочий стол.
Параметры сессионного пула позволяют создавать виртуальные рабочие столы по количеству активных пользователей. Актуальная задача, которая позволит сэкономить аппаратные ресурсы для крупных распределенных организаций или сменного графика работы.
Как отделить пользователей от рабочих столов
Мы считаем, пользователь не должен подключаться напрямую в рабочий стол, т.к. любое подключение должно контролироваться системой. Нехорошо, если после первого подключения пользователь сможет запустить протокол доставки рабочего стола и подключиться по подсмотренному IP-адресу. Никаких логов в VDI-системе о его подключении не останется.
В общем, не стали бы мировые лидеры в области VDI делать различные Security Getway на сетевом периметре в ДМЗ. Мы опыт мировых лидеров уважаем, поэтому сделали таким же наш Диспетчер подключений.
Диспетчер подключений как часть серверной составляющей VDI-решения устанавливается в демилитаризованной зоне и обеспечивает подключение пользователей к VDI-инфраструктуре. Прямого сетевого доступа к виртуальным рабочим столам или брокер-менеджеру, или еще кому-либо у пользователя нет.
В качестве следующего шага необходимо исключить возможность подключения в соседний рабочий стол: пользователь легитимно подключается в свой рабочий стол, смотрит свой IP-адрес, и методом подбора пытается подключиться к соседнему рабочему столу в этой сети.
Тут на помощь приходит Агент ВРМ, который в закрытом firewall открывает нужный порт для подключения пользователя через Диспетчер подключений. Все остальное закрыто. По окончании сессии порт закрывается.
Как следствие, нелегитимным путем подключиться не получится, только после авторизации в системе. А если есть авторизация, значит, мы уже залогировали устройство, с которого подключались, пользователя и рабочий стол, в который подключались. В случае инцидента сотрудники ИБ скажут нам спасибо. Кстати, системные логи мы умеем отправлять сразу по syslog в системы типа SIEM.
Постскриптум
Получилось достаточно подробно рассказать про наше VDI-решение, хотя и объемно.
Далее просим всех в комментарии. Очень хочется увидеть обратную связь: ваши мнения, комментарии, вопросы.
