RDS CAL и VDI-лицензирование: чек-лист вопросов для ИТ

Зачем нужен чек-лист перед RDS и VDI

Лицензирование RDS CAL и VDI почти всегда связано с деньгами, доступом к данным и ответственностью. Без заранее согласованного чек-листа легко переплатить за лишние лицензии или, наоборот, недолицензироваться и получить остановку работ в самый неудобный момент, например на внутреннем аудите или при проверке.

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

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

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

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

Ниже - вопросы, которые стоит задать ИТ и ИБ до выбора модели, закупки и внедрения, чтобы решение было законным, управляемым и предсказуемым по затратам.

Базовые понятия простыми словами

RDS (Remote Desktop Services) - роль в Windows Server, которая позволяет людям работать с приложениями и рабочим столом на сервере удаленно.

RDP (Remote Desktop Protocol) - протокол, по которому выполняется подключение.

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

CAL (Client Access License) часто путают с «лицензией на Windows Server», но это разные вещи. Лицензия Windows Server дает право запускать сам сервер. А RDS CAL дает право пользователю или устройству подключаться к RDS и работать через терминальные сессии. Поэтому при планировании важно считать не только серверы, но и тех, кто к ним подключается.

VDI (Virtual Desktop Infrastructure) - подход, при котором каждому пользователю выдают отдельный виртуальный ПК (виртуальную машину) с собственным рабочим столом. В RDS пользователи, как правило, делят один сервер (разные сессии на одном «железе» и одной ОС). В VDI больше изоляции и гибкости (например, разные образы и настройки), но обычно выше требования к инфраструктуре и администрированию.

На практике встречаются несколько типовых вариантов доступа, и от них зависит, какие вопросы по лицензированию задавать дальше:

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

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

Как собрать исходные данные: пошаговый план

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

1. Начните с инвентаризации того, что реально будет доступно по удаленке. Это не «терминальный сервер вообще», а конкретные приложения (1С, МИС, CAD, браузерные системы), типы данных (персональные, финансовые, медданные) и операции (только просмотр или еще печать, выгрузка файлов, работа с USB).

2. Затем переходите к цифрам и ролям:

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

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

4. Согласуйте требования ИБ и внутренние правила: журналирование, хранение логов, запрет копирования, требования регуляторов и аудита.

Небольшой пример: в медорганизации 120 сотрудников работают в 2 смены, но одновременно подключаются максимум 45. Часть врачей заходит с ноутбуков в отделениях, а подрядчик подключается раз в неделю для обновлений. Если это не записать сразу, легко ошибиться и в выборе per user/per device, и в правилах доступа.

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

Per user или per device: вопросы для правильного выбора

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

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

Дальше посмотрите на «карту устройств». Один человек может работать с офисного ПК, с ноутбука и периодически подключаться из дома. В такой модели per user обычно проще объяснить и сопровождать. А если у вас много общих рабочих мест (сменные посты, регистратура, класс, call-центр), где за одним ПК работают разные люди по очереди, per device часто выглядит естественнее.

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

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

Небольшой пример: в поликлинике 40 сотрудников. 15 врачей подключаются и из кабинета, и из дома, а в регистратуре 10 рабочих мест работают в 2 смены (20 человек). Часто выходит смешанная картина: врачам удобнее per user, регистратуре - per device. Это повод заранее договориться, допускаете ли вы смешанный подход и как будете вести учет, чтобы потом не спорить на аудите.

Внешние подрядчики и временный доступ

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

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

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

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

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

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

Сценарии терминального доступа и где чаще выбирают VDI

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

Сценарий 1: общий терминальный сервер для офисных задач

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

Заранее решите, как будут подключаться: per user (человек) или per device (устройство). И сразу зафиксируйте, будет ли доступ с личных ноутбуков и тонких клиентов. Иначе расчеты по лицензиям разъедутся с реальностью.

Сценарий 2: выделенные рабочие столы (VDI) по ролям

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

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

Перед выбором модели полезно ответить на несколько вопросов:

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

Сценарий 3: доступ к одному приложению вместо полного рабочего стола

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

Если есть филиалы и нестабильные каналы, уточните, что будет при обрывах: как восстанавливается сессия, где остаются временные файлы, и не приведет ли рост числа точек подключения к пересмотру архитектуры. На практике это может потянуть отдельные серверы для филиалов или централизованный кластер в ЦОД, например на стоечном сервере уровня GSE S200 Series, с понятными правилами доступа и резервирования.

Вопросы к ИБ: контроль доступа, журналирование, данные

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

Доступ и аутентификация

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

Проверьте:

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

Сегментация, журналы и защита данных

Сегментация сети помогает ограничить последствия ошибок и инцидентов. Уточните, должны ли RDS/VDI жить в отдельном сегменте: отдельно от пользовательских ПК и отдельно от админских рабочих мест. Частый компромисс: пользователи видят только брокер или шлюз, а внутренние серверы недоступны напрямую.

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

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

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

Типовые ошибки, из-за которых потом приходится переделывать

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

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

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

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

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

Признаки, что вы движетесь к переделкам:

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

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

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

Перед тем как покупать лицензии и запускать пилот, договоритесь о простом правиле: у процесса должен быть один владелец. Это может быть ИТ, закупки или финконтроль, но ответственность за учет, подтверждение цифр и подготовку к аудиту должна быть закреплена по роли, а не «по привычке».

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

Проверьте перед закупкой шесть вещей:

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

Отдельно подумайте о проверке соответствия. Хороший план аудита отвечает на три вопроса: как часто проверяем, кто подписывает результат, из каких источников берем данные (например, списки из AD, отчеты RDS/VDI, заявки из Service Desk).

Небольшой пример: в колл-центре люди работают посменно за 40 общими ПК, а бухгалтерия подключается с личных ноутбуков. В первом случае часто выгоднее per device, во втором - per user. Но это работает только если сменность, реальное число устройств и правила для подрядчиков подтверждены документами и логами.

Пример реального сценария: смешанные пользователи и доступ из филиалов

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

В такой конфигурации два вопроса быстро показывают, где выгоднее per device, а где per user:

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

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

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

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

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

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

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

Удобная структура такой страницы:

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

Дальше проверьте, выдержит ли текущая инфраструктура выбранный сценарий. Бывает, что лицензии подобраны правильно, но «не тянет» CPU, RAM, дисковая подсистема, сеть или профильные хранилища.

Минимальный техчек перед внедрением:

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

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

Если внутри команды не хватает опыта или времени, имеет смысл подключить системного интегратора. GSE.kz, как производитель серверов и рабочих мест в Казахстане и системный интегратор, помогает с проектированием RDS/VDI, подбором серверов и рабочих станций, внедрением и поддержкой 24/7 с учетом требований ИБ и закупочных ограничений.