Доклады, выступления, видео и электронные публикации

Локальный сервер лицензирования ПО с механизмом отзыва лицензий.

А. Ю. Чадов, Д. В. Угаров

Закрытое акционерное общество «ОКБ САПР», Москва, Россия

Продажа лицензии на программное обеспечение (ПО) является одним из основных способов продажи программных продуктов. Так как рынок ПО огромен (333 млрд долл в 2016 г. [1]), вопрос лицензирования программных продуктов достаточно актуален.

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

  • разработка схемы лицензирования продукта;

  • разработка механизма распространения лицензий.

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

Наиболее распространёнными механизмами передачи лицензий являются следующие:

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

  • Формирование привязанного к рабочей станции ключа лицензирования. В данном случае ключ — это тоже набор символов для активации ПО, но теперь в нем указан идентификатор рабочей станции. Отличием от предыдущего способа распространения является многоэтапность процесса: необходимо считать данные с рабочей станции, передать их продавцу и затем передать готовый код обратно покупателю. Этот процесс может быть реализован, к примеру, при помощи центрального сервера лицензирования или путем общения по почте/телефону между сотрудниками фирмы-покупателя и фирмы-продавца.

  • Передача USB-ключа (такого, как HASP) — устройства, на котором хранится информация, проверяемая при старте ПО, или некие данные, необходимые для работы программы, или, в некоторых случаях, часть кода программы. Обычно передается заказчику от продавца вместе с дистрибутивом. Ключ должен быть постоянно подключен к рабочей станции, чтобы ПО работало. Соответственно для каждой копии ПО нужно отдельное устройство.

У всех указанных способов есть свои недостатки. Это слабая защищенность, сложность и длительность процесса, наложение дополнительных условий (к примеру, наличие Интернета у конечного пользователя) и необходимость поддержки сервера в случае передачи лицензий через центральный сервер лицензирования, увеличение цены продукта в случае использования аппаратных ключей [2].

Мобильный носитель лицензий

В статье [3] был описан новый способ распространения лицензий, позволяющий избежать указанных недостатков. Решение получило название

"мобильный носитель лицензий" (МНЛ). Лицензии создаются пользователем самостоятельно, при помощи USB-устройства, которое, будучи подключенным к рабочей станции, по запросу пользователя само может сформировать код активации лицензии. В устройстве есть процессор, что позволяет ограничивать доступ пользователя к данным, необходимым для формирования лицензии. Также наличие процессора позволяет устройству проконтролировать, что пользователь сможет при помощи МНЛ создать лицензии в количестве, не большем, чем разрешил продавец. В одно устройство можно занести данные для генерации лицензий на различные продукты, и указать число лицензий, которое оно сможет сгенерировать для каждого из них. Таким образом, при продаже программных комплексов достаточно передать дистрибутивы и одно устройство, в котором будет указано число лицензий, которое оно может создать для каждого из продуктов.

Но и это решение обладает определенными недостатками в плане удобства:

  • необходимость физического доступа того, кто создает лицензии при помощи МНЛ, к каждому АРМ;

  • ему требуется носить устройство с собой;

  • USB-порты могут быть опечатанными;

  • процедуру создания лицензии нельзя автоматизировать, однотипные действия отнимают много времени.

Локальный сервер лицензирования

Указанные недостатки становятся критичными для информационных систем, содержащих хотя бы 100 АРМ. Чтобы нивелировать эти недостатки, предлагается разработать ПАК, включающий сервер, содержащий ОС со специализированным ПО, и МНЛ (рисунок).

Архитектура решения

ПО на сервере может работать в двух режимах:

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

  • лицензируемое ПО обращается к локальному серверу и запрашивает лицензию.

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

Физический компьютер должен обладать рядом свойств:

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

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

  • малое потребление энергии (мощность ИБП в серверной не бесконечна, поэтому предпочтительней выбрать вариант, не оказывающий значительной нагрузки на уже существующую систему);

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

Исходя из этих требований предлагается использовать в качестве аппаратной базы сервера микрокомпьютеры (МК) [4—11].

Сервер, содержащий ОС со специализированным ПО, и МНЛ

Отзыв лицензий

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

Сложность реализации отзыва лицензии ПО при помощи ПО на этом же АРМ заключается в том, что какие бы действия не производились в ОС с лицензируемым ПО, ее (ОС) всегда можно переустановить или восстановить из бэкапа. По этой причине решение необходимо искать в применении внешних по отношению к ОС средств, например принудительно распространяя списки отозванных лицензий на АРМ с лицензируемым ПО. Однако лучшее решение проблемы — не допустить ее возникновения.

Для этого предлагается следующее решение: при помощи сервера выписывать лицензии на определенный период и затем выписывать новые по окончании этого времени. Период действия таких лицензий может варьироваться, но не может быть меньше одного дня и не может превышать срок действия лицензии, указанный продавцом. Чем меньше период действия, тем меньше время ожидания в случае переноса ПО с одного АРМ на другой. Но с другой стороны, чем больше этот период, тем меньше риск простоя системы в случае сбоя (например, потери сетевого соединения). Однозначно решить, какой из параметров важнее для администратора ИС, нельзя, так как заранее не известно, какие компоненты в системе зарезервированы и каково поведение лицензируемого ПО в случае окончания срока лицензии. По этой причине выбор срока должен быть настраиваемым.

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

Но в таком случае меняется схема работы с МНЛ: вместо разового использования мы переходим к регулярной работе с ним. Поэтому более актуальной по сравнению с механизмом выписывания долгосрочных лицензий становится задача обеспечения отказоустойчивости системы.

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

Как уже упоминалось, сервер может быть в двух вариантах: на ВМ или на микрокомпьютере. В случае ВМ покупатель может решить данный вопрос самостоятельно. Это может быть как резервирование ВМ, так и специальный функционал системы виртуализации (например, в случае VMware vSphere функция кластера High Availability). Таким образом, в случае сбоя сервера восстановить работоспособность комплекса не составит труда. В случае работы с микрокомпьютером для резервирования достаточно приобрести дополнительный МК.

Вторая сущность, которую необходимо продублировать, — МНЛ. Нельзя просто дать пользователю резервную копию устройства, которое может генерировать лицензии. Необходимо защитить продавца от неправомерного использования покупателем резервных устройств для удвоения доступных лицензий. Для этого предлагается использовать 3 типа устройств: одно выписывающее, одно дублирующее и набор пустых. Выписывающее и дублирующее устройства работают только в паре на одном сервере. Выписывающее устройство генерирует лицензию только с разрешения дублирующего. Число лицензий уменьшается на обоих устройствах. В случае, если одно устройство выходит из строя, при помощи оставшегося в рабочем состоянии и пустого устройства создается замена сломанному. Если у пользователя окажется 2 пустых устройства (а минимум два ему необходимы, т. к. выписывающее и дублирующее работают одновременно, соответственно и ресурс у них исчерпывается идентично), то он сможет сделать второй комплект. Чтобы избежать этого, предлагается устанавливать на пустые устройства пин-коды, которые будут предоставляться пользователю по факту обращения (при этом пользователь обязан будет вернуть вышедшее из строя). Таким образом, покупатель не сможет использовать одно из дублирующих устройств отдельно и не сможет создать две рабочие пары.

Выводы

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

Литература

  1. Gartner: в 2017 году мировой рынок ИТ вырастет до 3,5 трлн долл. [Электронный ресурс] URL: http://www.computerworld.ru/news/Gartner-v-2017-godu-mirovoy-rynok-IT-vyrastet-do-35-trln-doll (дата обращения: 15.04.2017).

  2. Цены и заказ [Электронный ресурс]. URL: http://www.guardant.ru/purchase/store/ (дата обращения: 17.04.2017).

  3. Чадов А. Ю. Новый защищенный способ распространения лицензий на ПО // Вопросы защиты информации. № 2, С. 73—74.

  1. Конявский В. А. Компьютер с вирусным иммунитетом // Информационные ресурсы России. 2015. № 6. С. 31—34.

  1. Компьютер типа "тонкий клиент" с аппаратной защитой данных. Патент на полезную модель № 118773. Опубл. 27.07.12. Бюл. № 21.

  1. Компьютер с аппаратной защитой данных от несанкционированного изменения. Патент на полезную модель № 137626. Опубл. 20.02.2014. Бюл. № 5.

  1. Мобильный компьютер с аппаратной защитой доверенной операционной системы. Патент на полезную модель № 138562. Опубл. 20.03.2014. Бюл. № 8.

  1. Мобильный компьютер с аппаратной защитой доверенной операционной системы от несанкционированных изменений. Патент на полезную модель № 139532. Опубл. 20.04.2014. Бюл. №11

  2. Мобильный компьютер с аппаратной защитой доверенной операционной системы. Патент на полезную модель № 147527. 10.11.2014. Бюл. № 31.

  1. Мобильный компьютер с аппаратной защитой доверенной операционной системы от несанкционированных изменений. Патент на полезную модель № 151264. Опубл. 27.03.2015. Бюл. №9

  2. Рабочая станция с аппаратной защитой данных для компьютерных сетей с клиент-серверной или терминальной архитектурой. Патент на полезную модель № 153044. Опубл. 27.06.2015. Бюл. №18

Авторы: Чадов А. Ю.; Угаров Д. В.

Дата публикации: 01.01.2017

Библиографическая ссылка: Чадов А. Ю., Угаров Д. В. Локальный сервер лицензирования ПО с механизмом отзыва лицензий // Вопросы защиты информации. М., 2017. № 3. С. 64–67.


Метки документа:
лицензии и лицензирование по  

Scientia potestas est
Кнопка связи