ГОСТ Р ИСО/МЭК 19770-2-2014
Группа П85
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Информационные технологии
МЕНЕДЖМЕНТ ПРОГРАММНЫХ АКТИВОВ
ЧАСТЬ 2
Тег идентификации программного обеспечения
Information technologies. Software asset management. Part 2. Software identification tag
ОКС 35.080
ОКСТУ 4090
Дата введения 2016-01-01
Предисловие
1 ПОДГОТОВЛЕН Закрытым акционерным обществом "Консистент Софтвеа Дистрибьюшн" на основе аутентичного перевода на русский язык международного стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 076 "Системы менеджмента"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 19 ноября 2014 г. N 1684-ст
4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 19770-2:2009* "Информационные технологии. Менеджмент программных активов. Часть 2. Тег идентификации программного обеспечения" (ISO/IEC 19770-2:2009) "Information technology - Software asset management - Part 2: Software identification tag")
________________
* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - Примечание изготовителя базы данных.
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА
5 ВВЕДЕН ВПЕРВЫЕ
Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомления и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
Данная часть настоящего стандарта представляет собой Международный стандарт, описывающий теги идентификации программного обеспечения. Тег идентификации программного обеспечения представляет собой XML-файл, содержащий достоверную идентификационную и управляющую информацию о программном продукте. Тег идентификации программного обеспечения устанавливается на вычислительное устройство вместе с программным продуктом. Тег может создаваться в процессе установки или добавляться позднее для уже установленного программного обеспечения без тегов. Однако чаще происходит так, что тег создается при исходной разработке программного продукта, а затем распространяется и устанавливается вместе с программным продуктом. Наличие тега, начиная с самого начала разработки программного продукта, позволяет обеспечить более эффективное управление процессами распространения и переупаковки, выполняемых лицами, внешними по отношению к потребителю программного обеспечения, и последующими процессами управления релизами в организации потребителя программного обеспечения.
Данная часть настоящего стандарта поддерживает процессы управления программными активами, определенные в ИСО/МЭК 19770-1. Данный стандарт также предназначен для совместного использования с будущим ИСО/МЭК 19770-3, который будет представлять собой Международный стандарт, описывающий теги прав на использование программного обеспечения.
Теги идентификации программного обеспечения - полезный инструмент для всех заинтересованных лиц, занятых в процессах создания, лицензирования, распространения, выпуска релизов, установки и текущего технического обслуживания программного обеспечения. К основным преимуществам, связанным с использованием тегов идентификации программного обеспечения, относятся следующие:
a) возможность единообразной и достоверной идентификации программных продуктов для управления ими в любых целях, например в целях лицензирования, обновления, упаковки или для составления ведомости взаимозависимостей. Теги идентификации программного обеспечения содержат метаданные, необходимые для обеспечения более точной идентификации. Данный подход коренным образом отличается традиционных способов идентификации, ориентированных на файлы;
b) способность идентифицировать группы или наборы программных продуктов аналогично тому, как осуществляется идентификация отдельных программных продуктов, позволяет осуществлять управление целыми группами или наборами программных продуктов так же гибко, как и управление отдельными продуктами;
c) упрощение практических процессов стандартизации между различными создателями программного обеспечения и внутри самих организаций создателей программного обеспечения, определяющих, как именно следует идентифицировать различные версии программного обеспечения, что позволит потребителям программного обеспечения осуществлять более качественную идентификацию и управление этими различными версиями; например они смогут проводить различия между самостоятельными версиями и версиями, являющимися компонентами наборов, обновлений и пр.;
d) упрощение автоматизированных подходов к проверкам лицензионного соответствия с использованием информации, содержащейся как в теге идентификации программного обеспечения, так и в теге прав на использование программного обеспечения, который будет определен в ИСО/МЭК 19770-3;
e) возможность предоставления исчерпывающей информации о структурных составляющих пакетов, т.е. списка компонентов, таких как файлы и системные настройки, связанные с этим пакетом, с целью сопоставления процессов управления на уровне пакетов и на уровне файлов;
f) возможность предоставления информации о том, как именно должна осуществляться идентификация в случае активного или неактивного использования конкретного программного пакета;
g) Возможность управления сложностью программного обеспечения, установленного на съемных носителях, или носителях общего доступа, или в виртуальных средах (при условии, что платформы и программы-установщики будут совершенствовать технические возможности по идентификации устройств и окружений);
h) Возможность отражать в теге идентификации программного обеспечения идентификационные данные и требования различных объектов, в том числе создателей программного обеспечения, лицензиаров программного обеспечения, упаковщиков, дистрибьюторов, внешних по отношению к потребителю программного обеспечения, администраторов релизов в организации потребителя программного обеспечения и лиц, ответственных за установку и управление программным обеспечением, на постоянной основе;
i) Возможность выполнения проверки правильности (валидации) любой такой информации посредством дополнительного использования цифровых подписей любым лицом, создающим или изменяющим информацию в теге идентификации программного обеспечения;
j) Возможность для лиц, не являющихся создателями программного обеспечения (например, независимых поставщиков или внутреннего персонала), создавать теги идентификации программного обеспечения для устаревшего программного обеспечения, а также для программного обеспечения, поступившего от создателей программного обеспечения, которые сами не предоставили теги идентификации программного обеспечения;
k) по мере того, как отраслевые организации начнут применять единые подходы к работе с различными типами информации, не охватываемой в настоящее время данной частью настоящего стандарта, в настоящий стандарт будут вноситься формальные и неформальные усовершенствующие изменения, например в части активации продуктов.
1.1 Назначение
Настоящий стандарт устанавливает спецификации для создания и ведения тегов программного обеспечения с целью оптимизации процессов идентификации и управления таким программным обеспечением.
Настоящий стандарт применяется к следующим объектам:
a) провайдеры платформы: Провайдерами платформы являются лица, отвечающие за компьютерное оборудование, или аппаратное устройство, и/или соответствующую операционную систему, или виртуальную среду, на которых может устанавливаться или запускаться программное обеспечение. Провайдеры платформы, поддерживающие данную часть настоящего стандарта, кроме того, реализуют функциональность управления тегами на уровне платформы или операционной системы;
b) поставщики программного обеспечения: Поставщиками программного обеспечения являются лица, которые создают ("создатели программного обеспечения"), изменяют ("модификаторы программного обеспечения") или лицензируют ("лицензиары программного обеспечения") программное обеспечение для распространения или установки. К ним относятся производители программного обеспечения, независимые разработчики программного обеспечения, консультанты и переупаковщики ранее произведенного программного обеспечения. Поставщиками программного обеспечения также могут считаться разработчики программного обеспечения для внутренних целей организации;
c) поставщики тегов: Поставщиками тегов являются лица, которые создают ("создатели тегов") или изменяют ("модификаторы тегов") теги идентификации программного обеспечения. Поставщик тегов может являться частью организации поставщика программного обеспечения или может быть сторонней организацией или потребителем программного обеспечения;
d) поставщики инструментария для работы с тегами: К ним относятся лица, которые могут предоставлять любое количество инструментальных средств, с помощью которых можно создавать, изменять или использовать теги идентификации программного обеспечения. К такому инструментарию могут относиться среды разработки, обеспечивающие автоматическое формирование тегов идентификации программного обеспечения, средства установки, которые могут создавать и/или изменять теги от имени процесса установки, а также инструменты управления настольными системами, которые могут создавать теги для программного обеспечения, не имеющего тегов, и/или изменять теги, внося в них сведения о релизе, в течение жизненного цикла программного обеспечения. Более подробная информация о возможных способах использования тегов идентификации программного обеспечения поставщиками инструментария для работы с тегами приведена в приложении С;
e) потребители программного обеспечения: Потребителями программного обеспечения являются лица, которые приобретают, устанавливают и/или иным способом потребляют программное обеспечение, и которые считаются одними из главных получателей усовершенствованной информации, содержащейся в теге идентификации программного обеспечения, как это определено в данной части настоящего стандарта. Более подробная информация о возможных способах использования тегов идентификации программного обеспечения потребителями программного обеспечения приведена в приложении D.
В данной части настоящего стандарта не приводится описание процессов SAM, используемых для выверки прав на использование программного обеспечения с помощью тегов идентификации программного обеспечения.
В данной части настоящего стандарта не приводится описание процессов активации продуктов или контроля запуска.
Данная часть настоящего стандарта не имеет целью вступление в противоречие ни с политиками, процедурами и стандартами организации, ни с любыми внутригосударственными законами и регуляторными актами. Любое такое противоречие должно быть устранено до начала использования данной части настоящего стандарта.
2.1 Общие положения
Критерии соответствия могут применяться к продукту или организации. Для организационного соответствия определенная область действия должна охватывать как организационную область действия, так и продукты, включенные в эту область действия.
Если в отношении продукта или организации выдвигается претензия о соответствии, в претензии должна быть указана область действия, в которой было осуществлено тестирование соответствия.
В контексте данного пункта соответствие часто определяется в терминах, соответствующих требованиям 6.1, 8.3, 8.4 и 8.5. Требования к соответствию платформы также определены в 7.2. Также существуют нормативные требования, определенные в других подпунктах пунктов 6 и 7, при описании которых используются слова "должен", "должна", "должны" и пр., однако эти требования не включаются в содержание заявлений о соответствии, за исключением тех случаев, когда эти требования также включены в 6.1, 7.2, 8.3, 8.4 или 8.5. Заявления, содержащие слова "должен", "должна", "должны" и пр., являются рекомендательными, но не обязательными.
2.2.1 Примеры причин необходимости обеспечения соответствия продуктов
В организации могут иметься несколько причин, по которым организация может пожелать обеспечить соответствие отдельных продуктов данной части настоящего стандарта. Например, обеспечение соответствия может потребоваться, когда конкретный продукт поставляется на рынок, требующий соблюдения соответствия (например, если государственные организации требуют, чтобы продукт соответствовал данной части настоящего стандарта с целью включения в проект). Обеспечения соответствия также могут требовать провайдеры платформы, желающие организовать более безопасное и контролируемое хранилище тегов, которое может использоваться для однозначной идентификации того, какой именно конечный пользователь установил какой именно программный пакет.
2.2.2 Область действия продукта
Должно быть оформлено четко выраженное заявление об области действия продукта, однозначно описывающее программные продукты, к которым применяется данная область действия и, в соответствующих случаях, вносящее уточнения относительно продуктов, к которым данная область действия не применяется. Область действия соответствия продукта может определяться любым удобным способом, например, для конкретного программного продукта, для всех программных продуктов, для всех программных продуктов, установленных на конкретных платформах, для программных продуктов конкретных изготовителей и/или для всех программных продуктов, созданных после указанной даты, при условии, что такие определения области действия являются однозначными. В случае продукта, создающего или изменяющего теги идентификации программного обеспечения, областью действия будет считаться сам продукт и все программное обеспечение, произведенное или измененное продуктом при включенной функциональности обеспечения соответствия тегов.
2.2.3 Соответствие программных продуктов
Полное соответствие программного продукта достигается одним из двух способов:
a) Для продукта, предназначенного для установки, полное соответствие достигается посредством демонстрации того, что все теги идентификации программного обеспечения, установленные этим продуктом в процессе установки, соответствуют всем обязательным требованиям данной части настоящего стандарта, определенным в 6.1 и 8.3. Если используются дополнительные или расширенные элементы тегов, такие элементы тегов также должны соответствовать требованиям, определенным в 8.4 и 8.5.
Такое соответствие должно быть продемонстрировано посредством выполнения эквивалентного разбиения с критерием завершения, состоящим в том, что пройдены все тесты и достигнуто 100% эквивалентное разбиение в процессе создания/установки тега. Эквивалентные разбиения должны определяться на основании заявления об области действия продукта. Если программный продукт состоит из пакета других программных продуктов, то в программном продукте должны быть сохранены все теги компонентов и содержаться ссылки на все элементы дочерних тегов, которые при любых обстоятельствах по-прежнему должны идентифицироваться отдельно (с целью лицензирования, обеспечения безопасности или с другими целями);
b) для продукта, предназначенного для распространения, но еще не установленного, полное соответствие достигается посредством демонстрации того, что распространяемые сборки выпущены с уникальным тегом, который должен соответствовать всем обязательным требованиям данной части настоящего стандарта, определенным в 6.1 и 8.3. Если используются дополнительные или расширенные элементы тегов, такие элементы тегов также должны соответствовать требованиям, определенным в 8.4 и 8.5. Исключение: любые обязательные элементы, присущие конкретной системе, не включаются.
Такое соответствие должно быть продемонстрировано посредством выполнения эквивалентного разбиения с критерием завершения, состоящим в том, что пройдены все тесты и достигнуто 100% эквивалентное разбиение. Эквивалентные разбиения должны определяться на основании заявления об области действия продукта.
Если программный продукт состоит из пакета других программных продуктов, то в программном продукте должны сохраниться все теги компонентов и содержаться ссылки на все элементы дочерних тегов, которые при любых обстоятельствах по-прежнему должны идентифицироваться отдельно (с целью лицензирования, обеспечения безопасности или с другими целями).
2.2.4 Соответствие тегов идентификации программного обеспечения третьих сторон
Сторонние организации, предоставляющие теги, могут применять процессы создания тегов идентификации программного обеспечения для любых программных пакетов, не содержащих такие теги. Такие процессы могут применяться для программных продуктов более ранних версий, продуктов типа shareware/freeware или для продуктов компаний, принявших решение не обеспечивать соответствие данной части настоящего стандарта. Такие теги могут предоставляться организациям для того, чтобы они могли обнаруживать программное обеспечение и запускать процедуры идентификации.
Полное соответствие тегов идентификации программного обеспечения, созданных третьими сторонами, достигается посредством демонстрации того, что все теги идентификации программного обеспечения, созданные организацией, соответствуют всем обязательным требованиям данной части настоящего стандарта, определенным в 6.1 и 8.3. Если используются дополнительные или расширенные элементы тегов, такие элементы тегов также должны соответствовать требованиям, определенным в 8.4 и 8.5. Любые добавляемые новые данные должны соответствовать тем же стандартам, которые применяются к обеспечению соответствия устанавливаемого программного обеспечения.
Обеспечение соответствия тегов идентификации программного обеспечения, созданных третьими сторонами, требует, чтобы поставщики тегов продемонстрировали уникальность созданных ими идентификаторов программного обеспечения (software_id), и что для идентификации поставщиков программного обеспечения в таких идентификаторах используются согласованные значения. Предполагается, что поставщики тегов будут вести список уникальных поставщиков программного обеспечения для всех созданных тегов, причем такой список будет включать в себя согласованный регистрационный идентификатор (regid) поставщика программного обеспечения (являющийся ссылкой на домен поставщика) и уникальный идентификатор ID (которым может быть идентификатор GUID) для каждой ссылки, и эти сведения на согласованной основе будут использоваться в созданных тегах.
Такое соответствие должно быть продемонстрировано посредством выполнения эквивалентного разбиения с критерием завершения, состоящим в том, что пройдены все тесты и достигнуто 100% эквивалентное разбиение в процессе создания тега. Эквивалентные разбиения должны определяться как по диапазону программного обеспечения, к которому будет применяться инструментарий для работы с тегами, так и по соответствующим заявлениям об области действия продукта.