ЕДИНОЕ ИНФОРМАЦИОННОЕ ПРОСТРАНСТВО ДЛЯ УПРАВЛЕНИЯ АКТИВАМИ ПО
Любая организация, внедряющая управление лицензиями или полноценное управление активами программного обеспечения (Software Asset Management, SAM), рано или поздно сталкивается с трудностями при сопоставлении данных о приобретенных лицензиях и установленных экземплярах ПО. Рассмотрим основные условия, необходимые для успешного создания единого информационного пространства управления активами ПО, а также основные проблемы, подстерегающие на этом пути.
ОСНОВНЫЕ ИСТОЧНИКИ ДАННЫХ
Для успешного создания единого информационного пространства, которое затрагивает инвентаризационный, финансовый и контрактный аспекты SAM, необходимы как минимум три источника данных (рис.1).
- Репозиторий (база данных) системы управления активами ПО, где хранится информация о лицензиях ПО.
- Система автоматической инвентаризации (автодискаверинг), которая позволяет собирать информацию об установленных и используемых экземплярах ПО с различных типов клиентов.
- Корпоративная система управления финансами, в которой хранится информация о договорах и затратах, связанных с владением лицензиями ПО.
Рис.1. Основные источники данных
Данные, необходимые для эффективного управления лицензиями, могут быть агрегированы либо на уровне репозитория системы управления ИТ-активами либо, если в организации существуют требования обеспечения федеративности данных в виде «сквозного» перехода между различными источниками. В результате появляется возможность построить единое информационное пространство (в контексте управления ИТ-активами), позволяющее анализировать данные по ИТ-активам в различных разрезах, прежде недоступных.
Основная задача – правильно сопоставить данные в различных системах таким образом, чтобы создать единое информационное пространство SAM, способное помочь в достижении нужных целей: оптимизации затрат, снижения рисков и пр.
Для этого необходимо выполнить несколько условий.
УСЛОВИЯ ДЛЯ УСПЕШНОГО СОПОСТАВЛЕНИЯ ДАННЫХ
ОПРЕДЕЛЕНИЕ КЛЮЧЕВОЙ ИНФОРМАЦИИ
Определение одного или несколько «ключей» – стандартная процедура для интеграции данных из различных систем. Как правило, наиболее востребованными «ключами» в случае управления активами ПО являются SKU и наименование ПО.
Stoсking Keeping Unit (SKU)
Википедия определяет SKU как «ассортиментную позицию (единицу одной товарной группы, марки, сорта в одном типе упаковки одной емкости), артикул». Многие производители программного обеспечения используют подобный артикул для своих продуктов. Если есть даже очень небольшие различия между двумя названиями программного обеспечения, проданного производителем/торговым посредником, то они обычно имеют два SKU:
- SKU: 810-03324;
- Product: Microsoft SQL Server 2005 Enterprise Edition Win-64Bit 1 Processor German 2 Years Software Assurance OPEN C.
- SKU: 810-03537;
- Product: Microsoft SQL Server 2005 Enterprise Edition Win-64Bit 1 Processor German 2 Years Software Assurance OPEN NL.
Таким образом, даже то, что кажется нам одним и тем же программным обеспечением, на самом деле является разными продуктами; например, только Microsoft Office 2007 имеет больше 400 SKU.
Чем более объемную библиотеку SKU имеет система управления ИТ-активами, тем больше шансов на успешное сопоставление. Есть разные оценки необходимого минимума: 100 тыс., 300 тыс., 500 тыс. SKU. Чаще всего в различных источниках знаний встречается 300 тыс. SKU.
SKU очень удобно использовать в качестве ключевой информации, поскольку такой артикул уникален. И здесь мы сталкиваемся с первой серьезной проблемой: к сожалению, не все производители используют SKU для своих продуктов. Например, некоторые продукты Oracle не имеют артикула. В таких случаях приходится использовать в качестве уникального ключа для сопоставления наименование продукта (программного обеспечения).
Наименование продукта
Как было показано в примере, каждый SKU ссылается на уникальное именование продукта. Из именования продукта можно вычленить много ценной информации:
- производитель (Microsoft);
- версия продукта (SQL Server 2005 Enterprise Edition Win-64Bit);
- тип лицензирования (Processor, на процессор);
- язык (German);
- программа лицензирования (OPEN, Microsoft Open Licensing);
- уровень цен (NL, начальный – для участия в программе лицензирования достаточно приобретения пяти лицензий);
- опция программы лицензирования (2 Years Software Assurance, предполагает двухгодичное участие в программе Software Assurance for Volume Licensing).
Так как стандартов для именования продуктов не существует и производители руководствуются собственными правилами, то и количество полезной информации в именованиях программного обеспечения варьируется.
Однако уникальные имена продуктов бесполезны, если они по-разному именуются в различных системах. Поэтому такую информацию необходимо нормализовать.
НОРМАЛИЗАЦИЯ ДАННЫХ
Под нормализацией понимается приведение информации о программном обеспечении к определенному виду. Основные цели нормализации данных: удобство восприятия данных и возможность дальнейшего сопоставления такой информации в различных источниках. Обычно нормализации подвергаются следующие данные.
- Название программного обеспечения. Например, система инвентаризации может обнаружить приложение Oracle как Oracle (Sun Microsystems) Java 2 Runtime Environment и как Oracle Java 2 RE. Оба наименования могут быть трансформированы в Oracle Java 2 Runtime Environment для дальнейшего успешного сопоставления с информацией из репозитория системы управления ИТ-активами. Нередки случаи, когда одно и то же приложение до нормализации имеет 5-6 разных именований, хотя информация собирается одной системой инвентаризации.
- Название производителя. Очень похоже на ситуацию с названием ПО. К примеру, Microsoft может быть опознан системой инвентаризации как Microsoft Corp, Microsoft Rus или «Майкрософт».
- Версия ПО. Нормализация необходима также в случае учета обновлений версий приложений. Например, если есть потребность учитывать только основные (major) версии браузера: можно указать, что Internet Explorer 7.00.6001.18000 и Internet Explorer 7.00.6002.18005 на самом деле являются Internet Explorer V07.
Нужно понимать, что приведение данных к «нормальному» виду может очень сильно зависеть от задач, которые решаются в рамках проектов управления активами ПО. Если, к примеру, нет необходимости отслеживать версии сервисных пакетов (service packs), то и SQL Server 2008 sp1, и SQL Server 2008 sp2 могут трансформироваться в SQL Server 2008. В другой же организации такой подход к нормализации может оказаться неприемлемым.
Определение корректных правил сопоставления
Наличие ключевой информации гарантирует правильное сопоставление, но не гарантирует правильное определение использования ПО (правильный подсчет экземпляров ПО в соответствии с правами использования). Правила распространения и использования ПО определяются лицензией, а на сегодня в мире существует множество различных типов лицензирования: на пользователя, на компьютер, на процессор и др. Необходимо принимать во внимание множество факторов – виртуальные среды, права на апгрейды/даунгрейды, пакетное ПО, различные коэффициенты-мультипликаторы. На рис. 2 приведен пример, как может отличаться подсчет использования лицензий Oracle в зависимости от типа лицензирования.
Рис. 2. Результаты подсчета лицензий Oracle в зависимости от типа лицензирования
Поэтому необходимо определить правила сопоставления обнаруженных экземпляров ПО и прав использования. Это может быть серьезной проблемой, так как нужно хорошо разбираться в программах лицензирования производителей программного обеспечения, а в некоторых случаях правила сопоставления могут содержать достаточно сложную логику.
К счастью, многие вендоры в своих инструментах управления активами ПО обеспечивают автоматическое сопоставление с корректным подсчетом экземпляров ПО, иногда даже сертифицируя свои решения у наиболее крупных производителей. Примером такого пакета может служить HP SAM best practice package, который выпускается периодически и содержит не только библиотеку именований ПО, но и набор стандартных отчетов, а также правила нормализации и сопоставления данных.
СОПОСТАВЛЕНИЕ
Если выполнить основные вышеперечисленные условия, то в большинстве случаев будет обеспечено корректное сопоставление информации. Однако здесь нас поджидают типичные проблемы, о которых необходимо знать.
СОПОСТАВЛЕНИЕ С КОНТРАКТАМИ И ФИНАНСАМИ
Как правило, первичным источником о финансовом и контрактном аспекте лицензий является корпоративная система управления финансами (или бухгалтерская система). Это совершенно логично, так как лицензия – объект договора и в соответствии с централизованными процессами управления договорной деятельностью и закупками предприятия информация о лицензиях (с точки зрения финансового и контрактного аспектов) в большинстве случаев попадает в эту систему в первую очередь. Как было отмечено выше, основным ключом для сопоставления является SKU продукта. Но при обработке человеком входящих документов, информация из которых должна попасть в систему автоматизации, есть вероятность ошибки. Ошибка в SKU или именовании продукта повлечет за собой ошибки сопоставления данных.
На рис. 3 приведен пример входящих документов для лицензий Adobe и Microsoft. Видно, что в случае с лицензиями Microsoft артикул указан отдельно от наименования продукта, а для лицензии Adobe и артикул, и именование входят в «Описание SKU». Какая информация будет внесена в корпоративную финансовую систему?
Рис. 3. Форматы описания позиций ПО в документах (сертификатах) у различных производителей
В данном случае в решении проблемы поможет договоренность, лучше всего документально зафиксированная, о правилах именования и внесения информации о лицензиях в различные системы. Это позволит облегчить интеграцию между системой управления ИТ-активами и системами управления закупками, контрактами и финансами.
НЕИЗВЕСТНОЕ ПО
Безусловно, любой инструмент автоматической инвентаризации не способен знать обо всем выпускаемом ПО и особенно о ПО собственной разработки. В таком случае система инвентаризации пасует, и экземпляр ПО определяется как "неизвестный» (рис. 4).
Рис. 4. Пример обнаружения «неизвестного» ПО
Многие производители предусматривают возможность «обучения» систем инвентаризации, что помогает решить проблему. Как правило, это реализуется посредством внесения записей в библиотеку известного ПО, которые соответствуют сигнатурам нового «неизвестного» ПО.
ОБНАРУЖЕНИЕ КЛИЕНТ-СЕРВЕРНОГО ПО
При использовании клиент-серверного ПО большую сложность представляет обнаружение клиентской части приложений, особенно если используются тонкие клиенты. Особенностью клиент-серверного ПО является то, что, даже если на рабочей станции присутствует установленный клиент, то это не означает его использование (а следовательно, и использование соответствующей лицензии). Система инвентаризации может без проблем обнаружить установленный толстый клиент, однако не всегда сможет обнаружить факт использования такого приложения: агенты системы инвентаризации собирают информацию с хоста циклично, в соответствии с расписанием. В случае же с тонким клиентом дело обстоит еще хуже: на компьютере фактически нет установки приложения, обнаружить запуск и использование такого ПО с помощью системы инвентаризации очень трудно.
Выходом из подобной ситуации может стать либо более тщательная настройка агентов системы инвентаризации (использование скриптов для поиска специфических «следов», которые остаются после запуска приложений), либо использование систем мониторинга. К сожалению, это может потребовать больших дополнительных затрат и негативно влиять на производительность рабочих станций пользователей, а потому необходимо взвесить все плюсы и минусы развертывания подобных решений.
К тому же многие клиент-серверные приложения имеют механизмы, которые не дают возможности использовать больше клиентских лицензий, чем было приобретено, тем самым снижаются риски недолицензирования. Однако вопрос с эффективностью использования приобретенных клиентских лицензий в данном случае остается открытым.
ОДНОЗНАЧНОЕ СОПОСТАВЛЕНИЕ
Рассмотрим следующую ситуацию: организация приобрела пакет Microsoft Office с правом на 10 установок ПО с определенным ключом активации продукта. Допустим, один из пользователей устанавливает пиратскую версию с другим ключом. Как понять, что одно из установленных приложений нелегально? Ведь у легальной и пиратской копии могут совпадать и SKU, и наименование продукта. Получается, что для однозначного сопоставления необходимы ключевые данные, отличные от SKU и наименования продукта, например серийный номер.
Для того чтобы лучше понять проблему однозначного сопоставления лицензии и установленного экземпляра ПО, обратимся к стандарту ISO 19770, а точнее, ко второй его части – ISO 19779-2:2009.
ISO 19779-2:2009 регламентирует использование идентификационных меток установленного ПО (software identification tag, SWID). Подобный идентификатор может генерироваться или вручную, или автоматически при запуске инсталлятора (или при использовании специализированных средств распространения ПО). В идеале такая метка должна облегчить автоматическое сопоставление экземпляра и лицензии ПО, поскольку содержит набор уникальных данных: наименование, версию, принадлежность к пакету и т. п. Другими словами, метка помогает точно идентифицировать ПО. В большинстве случаев это действительно так, особенно если речь идет только о соответствии приобретенных и фактически используемых лицензий.
Однако, если необходимо выявить нелегальное ПО, то на практике все обстоит не так замечательно. Рассмотрим структуру идентификатора более детально.
В соответствии со стандартом атрибуты метки разбиваются на три группы: 7 обязательных, 30 опциональных и произвольное число дополнительных. Нас больше интересуют обязательные атрибуты, так как опциональные и дополнительные производитель (или распространитель ПО) имеет право не использовать:
- <entitlement_required_ indicator>. Значение True говорит нам о том, что данный экземпляр ПО требует лицензирования. Значение False используется для пробных или нелицензируемых экземпляров ПО.
- <product_title>. Идентифицирует приложение. Фактически это наименование ПО. Например – Acrobat X Pro.
- <product_version>. Версия продукта.
- <software_creator>. Создатель ПО, например Adobe Systems Incorporated.
- <software_licensor>. Лицензиар продукта, например Adobe Systems Incorporated.
- <software_id>. Уникальный идентификатор, определяющий версию конкретного приложения, служит для точного «опознания» приложения. Может выглядеть следующим образом: AcrobatPro-AS1-Win-GM-MUL, Microsoft-OfficeProPlus-2007wSP2, Windows-8-Release-Preview и т. д.
- <tag_creator>. Создатель метки. Например, regid.1991-06.com.microsoft. В данном случае запись указывает на то, что метка создалась автоматически при инсталляции продукта Microsoft (создатель – Microsoft, домен microsoft.com прошел регистрацию в регулирующем органе в июле 1991 года ).
Мы видим, что данных об уникальном серийном номере среди обязательных атрибутов нет. Этот атрибут относится к опциональной группе, а значит, необязателен для заполнения. Получается, что серийный номер или ключ активации для однозначного сопоставления использовать не получится, поскольку нет гарантии наличия данных. К тому же стандарт не рекомендует в атрибуте <serial_number> указывать непосредственно сам ключ (указывается либо его идентификатор, например Microsoft_select_7654321_Office-2007-suites, либо место расположения).
Среди обязательных атрибутов в большинстве случаев тоже нет информации, которую можно было бы использовать в качестве ключа для однозначного сопоставления экземпляров и лицензий ПО. Даже обязательный атрибут с многообещающим названием <software_id> может не обеспечивать необходимой уникальности.
Дело осложняется тем, что не все производители ПО поддерживают стандарт ISO 19779-2:2009. Некоторые производители уже начали использовать стандарт для новых продуктов, однако старая продуктовая линейка не поддерживает генерацию идентификаторов.
Что можно сделать в таком случае? Генерировать для устанавливаемого в организации ПО собственные метки!
Стандарт допускает пользовательские метки. И в этом случае при развертывании ПО можно использовать действительно уникальные идентификаторы, благодаря которым можно будет с легкостью вычислить факт использования неавторизованного ПО. На рис. 5 приведен пример генерации собственных меток в соответствии со стандартом для ПО в определенной организации. Значения атрибутов выделены желтым.
Рис. 5. Пример использования пользовательских меток SWID в соответствии со стандартом ISO 19770-2
Пример наглядно показывает, как обеспечивается точная идентификация ПО, приобретенного и разрешенного к использованию в компании.
- Атрибут <software_id> (подраздел <unique_id>) содержит значение Core-Image-Sep10, что указывает на конкретный авторизованный образ диска, который используется для установки ПО на все ноутбуки и рабочие станции компании (это подтверждается значением опциональных атрибутов <abstract_application_info> и <complex_of>).
- Значение атрибута <tag_creator> (подразделы <name> и <regid>) говорит о том, что идентификатор сгенерирован компанией Agnitio Advisors.
Если обнаружена метка без подобной информации, то это сигнал о том, что ПО установлено из нелегального дистрибутива или образа диска.
ЗАКЛЮЧЕНИЕ
В настоящее время многие производители решений для управления ИТ-активами делают все возможное, чтобы сопоставление информации, необходимой для эффективного управления активами ПО, происходило в автоматическом режиме. Однако не все зависит от них.
Несмотря на богатый арсенал инструментов, в реальной жизни всегда есть проблемы. Ни изощренные алгоритмы обнаружения, сопоставления и подсчета лицензий, ни огромное число записей в библиотеках известного ПО не гарантируют сопоставления на сто процентов.
Создание единого информационного пространства SAM зависит не только от наличия автоматизированных инструментов и интеграции различных источников данных, но и от организации определенных процедур и политик. Например, от процедуры централизованного распространения ПО в организации, реакции на обнаружение неизвестного ПО, соглашения об именованиях ПО при постановке лицензий на учет в различных системах и др., которые помогут повысить эффективность процессов управления активами ПО.
Эта статья была впервые опубликована издательством "OSP": www.osp.ru/itsm/2014/11/13043674.html
Михаил Тобурдановский, ITAM2.RU Project, управляющий партнер