1. Проблема: почему неверный выбор модели лицензирования Indeed PAM может создать проблемы после внедрения
На этапе пресейла модель лицензирования Indeed PAM кажется простой: есть пользователи, есть ресурсы или есть одновременные сессии. На этапе эксплуатации выясняется, что одно разрешение на доступ в PAM при пользовательско‑ресурсной схеме фактически «ест» сразу две лицензии: пользовательскую и ресурсную.
В результате заказчик может неожиданно упереться в лимит ещё до того, как реально нагрузит систему параллельными сессиями, просто на этапе выдачи разрешений. Это особенно болезненно, когда бизнесу нужно много людей с потенциальным доступом и много ресурсов, но реальные одновременные подключения сравнительно скромные.
Эта статья нужна тем, кто выбирает или уже внедряет Indeed PAM и хочет заранее понимать, хватает ли текущего набора лицензий под реальные сценарии, а не только под красивую цифру «количество пользователей/ресурсов/сессий» в коммерческом предложении.
Также важно учесть, что совместить 2 разных модели лицензирования на одном сервере (инстансе) Индид РАМ сейчас нельзя - придется выбирать какую-то одну, или ставить параллельно 2 инсталляции под разные лицензии со всеми вытекающими сложностями двойной выделения ресурсов, настройки, администрирования...
В результате заказчик может неожиданно упереться в лимит ещё до того, как реально нагрузит систему параллельными сессиями, просто на этапе выдачи разрешений. Это особенно болезненно, когда бизнесу нужно много людей с потенциальным доступом и много ресурсов, но реальные одновременные подключения сравнительно скромные.
Эта статья нужна тем, кто выбирает или уже внедряет Indeed PAM и хочет заранее понимать, хватает ли текущего набора лицензий под реальные сценарии, а не только под красивую цифру «количество пользователей/ресурсов/сессий» в коммерческом предложении.
Также важно учесть, что совместить 2 разных модели лицензирования на одном сервере (инстансе) Индид РАМ сейчас нельзя - придется выбирать какую-то одну, или ставить параллельно 2 инсталляции под разные лицензии со всеми вытекающими сложностями двойной выделения ресурсов, настройки, администрирования...
2. На что обратить внимание при расчёте
В Indeed PAM есть две базовые схемы лицензирования:
2.1. Пользовательские и ресурсные лицензии
При схеме «по пользователям и ресурсам» вам нужно сразу посчитать:
Дальше начинается важный нюанс:
– чтобы выдать доступ одному пользователю к одному ресурсу через PAM, вы:
2.2. Параллельные сессии против числа настроенных политик
Важно разделить три плоскости:
- по пользователям и ресурсам;
- по сессиям (одновременным подключениям).
2.1. Пользовательские и ресурсные лицензии
При схеме «по пользователям и ресурсам» вам нужно сразу посчитать:
- сколько людей реально будут иметь разрешения на доступ через PAM;
- сколько ресурсов (серверов, рабочих станций, сетевого оборудования и т.п.) нужно добавить в PAM.
Дальше начинается важный нюанс:
– чтобы выдать доступ одному пользователю к одному ресурсу через PAM, вы:
- добавляете ресурс — расходуется одна ресурсная лицензия;
- создаёте разрешение для пользователя — расходуется одна пользовательская лицензия.
2.2. Параллельные сессии против числа настроенных политик
Важно разделить три плоскости:
- количество ресурсов;
- количество пользователей, для которых созданы разрешения (политики доступа);
- количество одновременных сессий.
Возможны разные сценарии:
– Много ресурсов, но мало параллельных сессий.
Пример: банк с сотнями серверов, но одновременно работают не более 50–100 администраторов. В такой конфигурации ресурсные лицензии становятся основной статьёй затрат, а пользовательских может быть немного.
– Немного ресурсов, но много параллельных сессий.
Пример: ограниченный набор критичных серверов, к которым ходит большое количество подрядчиков и админов. Здесь ресурсных лицензий нужно немного, а ключевым параметром становится схема по сессиям или большое число пользовательских лицензий.
– Небольшое число удалённых сессий в каждый момент времени, но много пользователей, которые могут подключаться.
Пример: до 100 одновременных подключений, но около 150–200 сотрудников, которым нужно иметь право подключаться в разные дни. В этом случае упираемся не в фактическую нагрузку по сессиям, а в лимит по пользовательским лицензиям, потому что каждое активное разрешение занимает пользовательскую лицензию.
Отдельно стоит помнить: пользовательская лицензия привязана к факту наличия у пользователя хотя бы одного активного разрешения, а не к тому, зашёл он сегодня в PAM или нет. Именно поэтому число настроенных политик (разрешений) может давать гораздо большую нагрузку на лицензии, чем количество одновременных сессий.
– Много ресурсов, но мало параллельных сессий.
Пример: банк с сотнями серверов, но одновременно работают не более 50–100 администраторов. В такой конфигурации ресурсные лицензии становятся основной статьёй затрат, а пользовательских может быть немного.
– Немного ресурсов, но много параллельных сессий.
Пример: ограниченный набор критичных серверов, к которым ходит большое количество подрядчиков и админов. Здесь ресурсных лицензий нужно немного, а ключевым параметром становится схема по сессиям или большое число пользовательских лицензий.
– Небольшое число удалённых сессий в каждый момент времени, но много пользователей, которые могут подключаться.
Пример: до 100 одновременных подключений, но около 150–200 сотрудников, которым нужно иметь право подключаться в разные дни. В этом случае упираемся не в фактическую нагрузку по сессиям, а в лимит по пользовательским лицензиям, потому что каждое активное разрешение занимает пользовательскую лицензию.
Отдельно стоит помнить: пользовательская лицензия привязана к факту наличия у пользователя хотя бы одного активного разрешения, а не к тому, зашёл он сегодня в PAM или нет. Именно поэтому число настроенных политик (разрешений) может давать гораздо большую нагрузку на лицензии, чем количество одновременных сессий.
3. Особенности лицензирования и работы лицензий
3.1. Пользовательские лицензии
Пользовательская лицензия считается занятой, когда у пользователя появляется хотя бы одно активное разрешение. Если все пользовательские лицензии заняты, вы не сможете выдать новое разрешение другому пользователю, пока не освободите одну из лицензий.
Освобождение пользовательской лицензии происходит, когда:
P.S> есть возможность «автоматического очищения сессий в конце дня», это можно добиться с помощью скрипта, но в любом случае учтите, что лицензия освобождается не по календарю, а по изменению статуса разрешения.
3.2. Ресурсные лицензии
Ресурсная лицензия занимает место в момент, когда вы создаёте или восстанавливаете ресурс в PAM. Если лимит ресурсных лицензий исчерпан, добавить новый сервер или устройство нельзя, пока вы не удалите какой‑то ресурс или не докупите лицензии.
Ресурсная лицензия освобождается при удалении ресурса из PAM; ресурсы можно удалять и позже при необходимости восстанавливать, перераспределяя таким образом лицензии.
3.3. Сессионные лицензии (по одновременным подключениям)
Во второй схеме лицензирования — «по сессиям» — вы платите за максимальное количество одновременных подключений, а число пользователей и ресурсов формально не ограничено моделью лицензирования.
Особенности:
Это удобно, когда у вас очень много потенциальных пользователей и ресурсов, но относительно небольшой прогноз по одновременным подключениям.
3.4. Технические ограничения и планирование
Даже при выборе схемы по сессиям имеет смысл учитывать технические ограничения инсталляции, такие как предельное количество управляемых ресурсов, которое платформа может обрабатывать эффективно. Сама модель по сессиям не ограничивает число пользователей и ресурсов, но реальные инфраструктурные лимиты (производительность, архитектура, внутренние лимиты объектов) всё равно нужно обсуждать заранее. Здесь чем больше и точнее информация (в том числе сценарии на этапе пилота), тем лучше потом результат.
Пользовательская лицензия считается занятой, когда у пользователя появляется хотя бы одно активное разрешение. Если все пользовательские лицензии заняты, вы не сможете выдать новое разрешение другому пользователю, пока не освободите одну из лицензий.
Освобождение пользовательской лицензии происходит, когда:
- разрешение отзывается;
- приостанавливается;
- истекает срок действия разрешения.
P.S> есть возможность «автоматического очищения сессий в конце дня», это можно добиться с помощью скрипта, но в любом случае учтите, что лицензия освобождается не по календарю, а по изменению статуса разрешения.
3.2. Ресурсные лицензии
Ресурсная лицензия занимает место в момент, когда вы создаёте или восстанавливаете ресурс в PAM. Если лимит ресурсных лицензий исчерпан, добавить новый сервер или устройство нельзя, пока вы не удалите какой‑то ресурс или не докупите лицензии.
Ресурсная лицензия освобождается при удалении ресурса из PAM; ресурсы можно удалять и позже при необходимости восстанавливать, перераспределяя таким образом лицензии.
3.3. Сессионные лицензии (по одновременным подключениям)
Во второй схеме лицензирования — «по сессиям» — вы платите за максимальное количество одновременных подключений, а число пользователей и ресурсов формально не ограничено моделью лицензирования.
Особенности:
- сессионная лицензия считается занятой в момент открытия сессии;
- освобождается в момент завершения сессии, независимо от причины (нормальное завершение, разрыв, тайм‑аут и т.п.).
Это удобно, когда у вас очень много потенциальных пользователей и ресурсов, но относительно небольшой прогноз по одновременным подключениям.
3.4. Технические ограничения и планирование
Даже при выборе схемы по сессиям имеет смысл учитывать технические ограничения инсталляции, такие как предельное количество управляемых ресурсов, которое платформа может обрабатывать эффективно. Сама модель по сессиям не ограничивает число пользователей и ресурсов, но реальные инфраструктурные лимиты (производительность, архитектура, внутренние лимиты объектов) всё равно нужно обсуждать заранее. Здесь чем больше и точнее информация (в том числе сценарии на этапе пилота), тем лучше потом результат.
4. Ещё нюансы и практические приёмы
4.1. Ротация разрешений и «ручное» освобождение лицензий
Если вы используете схему по пользователям и ресурсам и регулярно упираетесь в лимит, помогает работа с жизненным циклом разрешений:
Так можно осознанно освобождать пользовательские лицензии под новых людей, а не расширять пул лицензий только потому, что старые разрешения никогда не закрываются.
Для больших инсталляций имеет смысл автоматизировать:
4.2. Работа с кэшем сессий и принудительное «обнуление» счётчиков
В сценариях с большим количеством краткосрочных подключений может возникать ситуация, когда сессия технически завершилась, но на стороне инфраструктуры ещё не всё полностью «отпустило» (подвисшие RDP‑сессии, сервисы мониторинга и т.п.).
Практические приёмы:
4.3. Почему важно обсуждать схему лицензирования до закупки
Опираясь только на маркетинговое описание («лицензии по пользователям и ресурсам» или «по одновременным сессиям»), легко недооценить влияние реальных сценариев доступа: кто, куда и как часто подключается, сколько политик нужно держать постоянно активными.
Перед покупкой PAM‑решения имеет смысл:
Это позволяет выбрать схему лицензирования (по пользователям/ресурсам или по сессиям), которая действительно соответствует вашему профилю использования, и понимать, сколько лицензий понадобится не только «в день запуска», но и через год‑два эксплуатации.
Если вы используете схему по пользователям и ресурсам и регулярно упираетесь в лимит, помогает работа с жизненным циклом разрешений:
- не держать активными разрешения для пользователей, которые давно не заходили;
- закладывать срок действия разрешений вместо бессрочных;
- при необходимости отзывать разрешения у сотрудников, которые больше не работают с конкретными ресурсами.
Так можно осознанно освобождать пользовательские лицензии под новых людей, а не расширять пул лицензий только потому, что старые разрешения никогда не закрываются.
Для больших инсталляций имеет смысл автоматизировать:
- скриптом периодически просматривать разрешения и переводить в приостановленные/отозванные те, кто не использовал доступ заданное время;
- по регламенту ревьюировать списки пользователей и ресурсов, удаляя или блокируя неактуальные записи.
4.2. Работа с кэшем сессий и принудительное «обнуление» счётчиков
В сценариях с большим количеством краткосрочных подключений может возникать ситуация, когда сессия технически завершилась, но на стороне инфраструктуры ещё не всё полностью «отпустило» (подвисшие RDP‑сессии, сервисы мониторинга и т.п.).
Практические приёмы:
- регламентное завершение «зависших» сессий средствами PAM и инфраструктуры;
- периодическая проверка и принудительный сброс зависших сессий, чтобы сессионные лицензии возвращались в пул в реальном времени.
4.3. Почему важно обсуждать схему лицензирования до закупки
Опираясь только на маркетинговое описание («лицензии по пользователям и ресурсам» или «по одновременным сессиям»), легко недооценить влияние реальных сценариев доступа: кто, куда и как часто подключается, сколько политик нужно держать постоянно активными.
Перед покупкой PAM‑решения имеет смысл:
- описать типовые потоки доступа: админы, подрядчики, операционисты, службы поддержки;
- посчитать количество ресурсов по классам (серверы, сети, рабочие станции, приложения);
- смоделировать, сколько людей должны иметь разрешение на постоянной основе, а сколько — разово или по запросу.
Это позволяет выбрать схему лицензирования (по пользователям/ресурсам или по сессиям), которая действительно соответствует вашему профилю использования, и понимать, сколько лицензий понадобится не только «в день запуска», но и через год‑два эксплуатации.
5. Что в итоге получаем
Разобравшись с особенностями пользовательских, ресурсных и сессионных лицензий Indeed PAM, можно:
- корректно посчитать объём лицензий под свои сценарии использования;
- избежать ситуации, когда лимит по пользователям достигается из‑за количества настроенных разрешений, хотя пик одновременных сессий далёк от критического;
- построить регламенты ротации разрешений и ресурсов, чтобы эффективнее использовать уже купленные лицензии;
- осознанно выбрать между схемой «пользователи/ресурсы» и «одновременные сессии», исходя из того, что у вас действительно больше: ресурсов, людей или параллельных подключений.