Приложение В (справочное). Сценарии действий и инструкции для поставщиков программного обеспечения

Приложение В
(справочное)

Сценарии действий и инструкции для поставщиков программного обеспечения

В.1 Введение

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

a) Простота идентификации

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

b) Точность идентификации

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

c) Контроль над процессами идентификации программного обеспечения

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

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

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

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

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

В.2 Роли, задействованные в процессе создания/изменения тега идентификации программного обеспечения

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

a) менеджер по продукту - это лицо определяет разрабатываемый/усовершенствуемый продукт и определяет множество аспектов продукта, которые должны быть отражены в теге. Использование для определения продукта информации, представленной в теге, позволят создавать более подробную документацию по продукту;

b) руководитель разработки - это лицо определяет технологию, используемую для разработки и поставки программного обеспечения.

Предварительно определенные спецификации тега позволят им более глубоко понимать окружение, в котором конечные пользователи будут использовать продукт;

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

В.3 Роль менеджера по продукту

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

Для менеджера по продукту наибольшую важность могут представлять следующие элементы (которые он должен хорошо понимать).

a) Обязательные элементы

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

1) entitlement required (необходима выверка прав на использование) - этот тег определяет, должно ли учитываться обнаруженное программное обеспечение в ходе процесса выверки прав на использование. Менеджер по продукту может четко указать случаи, когда выверка прав на использование необходима (когда лицензия на программное обеспечение продается потребителям программного обеспечения), а когда нет (если программное обеспечение устанавливается в режиме пробного использования или предоставляется бесплатно);

2) product title (наименование продукта) - этот элемент соответствует официальному рыночному наименованию продукта, определенному создателем программного обеспечения. Обычно этим именем является имя, которым специалист-практик по использованию процессов SAM и IT-специалисты называют продукт. Само по себе наименование не должно оказывать непосредственное воздействие на процессы выверки;

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

4) software creator identity (идентификационные данные создателя программного обеспечения) - назначение этого элемента состоит в уникальной и согласованной идентификации поставщика, изготовившего программное обеспечение. Учитывая, что названия некоторых региональных отделений программных компаний могут несколько отличаться друг от друга, важно добавить к имени идентификатор, который будет оставаться постоянным во всех странах, регионах и на всех языках - эта информация указывается в элементе regid. Это значение должно быть одинаковым для всех продуктов и релизов, созданных создателем программного обеспечения;

5) software unique identifier (уникальный идентификатор программного обеспечения) - менеджер по продукту совместно с остальными лицами, представляющими организацию-разработчика, определяет уникальный идентификатор для каждой версии продукта. Уникальный идентификатор позволяет обеспечивать надлежащее сравнение в процессе выверки.

b) Дополнительные элементы

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

1) component association (ассоциация с компонентами) и components list (список компонентов) - эти два дополнительных элемента позволяют менеджерам по продукту назначать тег программному продукту как компоненту объекта лицензирования продукта, например, набору или комплекту. Аналогично этому, элемент components list (список компонентов) предоставляет возможность формировать перечень оставшихся компонентов, связанных с одним и тем же объектом лицензирования (т.е. с набором). Включение одного или обоих дополнительных элементов в тег позволяет значительно повысить вероятность правильной идентификации, казалось бы, независимых установок программного обеспечения и одновременно гарантировать, что процесс выверки будет учитывать надлежащую лицензию на программное обеспечение набора по отношению к точечным продуктам, и наоборот;

2) license and channel information (информация о лицензии и канале) - этот дополнительный элемент еще более упрощает идентификацию программного обеспечения, установленного на данной машине, повышая эффективность работы специалиста-практика по использованию процессов SAM и эффективность всего процесса выверки лицензионных прав. Например, зная источник установки, специалисты-практики по использованию процессов SAM смогут с легкостью отделять программное обеспечение, приобретенное непосредственно, от ОЕМ-продуктов, включаемых в новые приобретаемые персональные компьютеры (ПК);

3) package footprint ("отпечаток" пакета) - этот элемент позволяет создателю программного обеспечения указывать файлы, записи реестра и другую информацию, которая может быть использована для идентификации программного пакета. Этот элемент разрешает размещение в файле нескольких записей, поэтому в одном ссылочном файле могут обрабатываться и патчи, и незначительные релизы программного обеспечения. Цель этого элемента состоит в предоставлении информации, которую агент обнаружения может использовать для проверки правильности идентификации тегом установленного программного обеспечения. Дополнительным преимуществом является то, что этот элемент позволяет инструментарию для обнаружения тегов исключать из списка обнаруженных файлов все "известные" файлы. Имея достоверный список файлов, записей реестра, записей WMI, а также другую информацию, относящуюся к платформе, по конкретному продукту, инструментарий для обнаружения тегов и специалисты-практики по использованию процессов SAM могут отфильтровывать информацию из списка всех обнаруженных элементов. Отфильтровывая "известную информацию", специалисты-практики, получают точную картину неизвестного или нового программного обеспечения, которое может быть установлено в их рабочем окружении;

4) product identifier (идентификатор продукта) - этот элемент представляет собой идентификатор, сопровождающий конкретный продукт от релиза к релизу. Этот элемент не должен использоваться в качестве маркетингового элемента продукта (как, например, наименование продукта), это должен быть просто идентификатор, не меняющийся от релиза к релизу. Например, организация может создавать и продавать продукт, называемый "Acme Widgets 2007 Pro". Если следующий релиз этого продукта выйдет под другим названием, к примеру, "Acme Widgets 2008 Expert", то специалист-практик, имея только наименование продукта, не будет знать, подпадают ли эти два продукта под действие конкретного соглашения об обслуживании. Тем не менее, если оба продукта имеют идентификатор продукта, например, "fc3cc419-b5a1-9f16-ed203e537c40", то специалист-практик может определить, что оба продукта подпадают под действие одного и того же соглашения об обслуживании, и затем установить их соответствие. Этот элемент позволяет организации, не идентифицируя конкретное наименование, указывать, какие обновления разрешаются осуществлять в рамках соглашений об обслуживании;

5) serial number (серийный номер) - необходимость включения серийного номера в состав тега прямо пропорциональна важности серийного номера как элемента прав на использование программного обеспечения для лицензии на программное обеспечение, приобретаемой потребителями программного обеспечения. Издателям программного обеспечения, требующим ввода серийного номера, привязанного к потребителю программного обеспечения и/или конкретной покупке, для установки и использования программного обеспечения, настоятельно рекомендуется включить в тег элемент serial number (серийный номер) для установления прямой взаимосвязи с заказом на покупку и/или правами на использование программного обеспечения в процессе выверки. Серийные номера известны на момент установки, поэтому между установкой и лицензированием прав на использование программного обеспечения можно определить прямую связь,

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

6) SKU - SKU может быть важным элементом для тех компаний, которые не используют серийные номера при активации программного обеспечения. При использовании SKU обычно требуется ассоциировать установленное программное обеспечение с правами на использование программного обеспечения;

7) supported languages (поддерживаемые языки) - элемент supported languages (поддерживаемые языки) позволяет создателям программного обеспечения указывать конкретный язык (языки), установленный на машине. Эта информация представляет важность для поставщиков программного обеспечения, продающих лицензии на программные обеспечение, привязанные к языку, поскольку в правах на использование программного обеспечения/заказе на покупку должны указываться продаваемые потребителю программного обеспечения продукты, привязанные к конкретному языку;

8) software creator alias (алиас создателя программного обеспечения) - этот дополнительный элемент отражает имя создателя, использовавшееся до получения текущего имени; данный элемент очень важен в том случае, если разрешается обновление от версии предыдущего создателя до версии текущего создателя. Этот элемент следует включать в тег при выпуске новых версий программных продуктов после приобретения;

9) upgrade for (обновление для) - этот элемент разработан для упрощения автоматизированных процессов выверки и обеспечивает правильную выверку обновлений. Этот элемент позволяет продукту идентифицировать самого себя как обновление конкретного продукта или продуктов. Используя данную информацию, специалисты-практики по использованию процессов SAM или аудиторы смогут осуществлять выверку существующих установок обновленного продукта с известными правами на использование старых продуктов. Учитывая, что создатели программного обеспечения будут обновлять лицензии, этот элемент позволяет ассоциировать текущие наименования с исходными версиями.

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

В.4 Руководитель разработки

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

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

a) создание тега идентификации программного обеспечения: когда и как будет создаваться тег идентификации программного обеспечения?

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

1) предварительно сформированный файл(ы) тега - включается в установочный диск, выбирается и копируется на целевую машину во время установки,

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

3) предварительно частично сформированный и обновляемый "на лету" файл тега - этот вариант позволяет выдавать тег идентификации программного обеспечения при первоначальной установке программного обеспечения и обновлять его при необходимости. Обновления могут заключаться в изменении состояния активации или других элементов по мере запуска и/или регистрации продукта;

b) файл тега идентификации программного обеспечения для объектов лицензирования множественных продуктов (например, наборов) - каким образом осуществляется создание и управление файлом тега?

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

c) управление жизненным циклом файлов тега идентификации программного обеспечения - как меняется файл тега идентификации программного обеспечения вместе с изменениями установленного программного обеспечения?

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

1) патчи и обновления - если патч ли обновление меняют версию продукта, файл тега должен отражать последнюю версию. Если элемент product version (версия продукта) был первоначально подписан, то подпись также должна быть обновлена,

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

3) лицензии на пробное использование - после истечения срока действия лицензий на пробное использование обновления тега должны отражать, что период пробного использования завершен (т.е. должен быть обновлен элемент состояния активации (activation status)),

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

d) дополнительные соображения по реализации

1) как можно проверить тег на правильность во время цикла QA?,

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

3) при выпуске готового к использованию коммерческого программного продукта (COTS) поставщику программного обеспечения предоставляется специальная информация об "отпечатке" пакета (см. элемент package footprint, 8.4.10). Такая информация об "отпечатке" может быть размещена на сайте создателя программного обеспечения и использоваться для целей управления. Предоставление информации об "отпечатке" пакета значительно облегчит работу инструментария SAM и специалистов-практиков по использованию процессов SAM, которые смогут осуществлять автоматическую фильтрацию "известных" файлов, записей реестра и записей WMI, а также других составляющих, найденных во время обнаружения, и практиковать применение процессов SAM на базе исключений,

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

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