ГОСТ Р ИСО/МЭК 19770-2-2014
если разрешается обновление or версии предыдущего создателя до версии текущего создателя. Этот элемент
следует включать в тег при выпуске новых версий программных продуктов после приобретения:
9)upgrade for (обновление для) - этот элемент разработан для упрощения автоматизированных процессов
выверки и обеспечивает правильную выверку обновлений. Этот элемент позволяет продукту идентифицировать
самого себя как обновление конкретного продукта или продуктов. Используя данную информацию, специалисты-
практики по использованию процессов SAM или аудиторы смогут осуществлять выверку существующих установок
обновленного продукта с известными правами на использование старых продуктов. Учитывая, что создатели про
граммного обеспечения будут обновлять лицензии, этот элемент позволяет ассоциировать текущие наименования
с исходными версиями.
Использование цифровых подписей обеспечивает целостность элементов, которые остаются неизменными
после создания тега. Для того чтобы принять решение о подписывании конкретных элементов в теге, необходимо
учитывать затраты на обеспечение дополнительной защиты в окружениях реализации и тестирования.
В.4 Руководитель разработки
Руководитель разработки работает непосредственно с менеджером по продукту, обеспечивая и четкое опре
деление и полноту спецификаций продукта. Руководитель разработки работает с информацией, уровеньдетализа
ции которой аналогичен уровню детализации информации, с которой работает менеджер по продукту.
Тем не менее, на этапе проектирования и реализации менеджер по продукту работает с более детализиро
ванной информацией. Ниже приводится сводный список сведений о реализации, которые необходимо принимать во
внимание и по которым необходимо принимать решения перед переходом на этап реализации:
a) создание тега идентификации программного обеспечения: когда и как будет создаваться тег идентифика
ции программного обеспечения?
Здесь необходимо учитывать несколько вариантов. Наилучший результат достигается, если учитывать кон
кретные обстоятельства каждого создателя программного обеспечения, циклы разработки и эксплуатационные и
производственные процессы. Возможные варианты:
1) предварительно сформированный файл(ы) тега - включается в установочный диск, выбирается и копиру
ется на целевую машину во время установки.
2) файл тега формируется в процессе установки - тег идентификации программного обеспечения создается
в рамках процесса установки. Это позволяет включить в тег специальные установочные параметры, например,
номер фактически устанавливаемой версии.
3) предварительно частично сформированный и обновляемый «на лету» файл тега - этот вариант позволяет
выдавать тег идентификации программного обеспечения при первоначальной установке программного обеспече
ния и обновлять его при необходимости. Обновления могут заключаться в изменении состояния активации или
других элементов по мере запуска и/или регистрации продукта;
b
) файл тега идентификации программного обеспечения для объектов лицензирования множественных про
дуктов (например, наборов) - каким образом осуществляется создание и управление файлом тега?
Руководители разработки должны учитывать, где и как осуществляется создание и управление
файлом(файлами) тега для компонентов набора. К вариантам создания тегов идентификации программного обе
спечения могут относиться предоставление тега идентификации программного обеспечения для набора и отдель
ных тегов идентификации программного обеспечения для каждого отдельного продукта или создание одного тега
идентификации программного обеспечения, описывающего весь набор. Кроме того, если продукт осуществляет
валидацию своего тега, определяется, будет ли он выполнять валидацию отдельного приложения и набора или всех
приложений, являющихся частью набора:
c) управлениежизненным циклом файлов тега идентификации программного обеспечения - как меняется файл
тега идентификации программного обеспечения вместе с изменениями установленного программного обеспечения?
Руководители разработки могут работать с несколькими сценариями жизненного цикла, воздействующими
на теги идентификации программного обеспечения; такими сценариями могут быть следующие:
1) патчи и обновления - если патч ли обновление меняют версию продукта, файл тега должен отражать по
следнюю версию. Если элемент product version (версия продукта) был первоначально подписан, то подпись также
должна быть обновлена,
2) отсутствующий файл тега идентификации программного обеспечения - файлы тега могут быть случайно
стерты конечными пользователями или повреждены; в этих случаях программное обеспечение должно запустить
механизмы самовосстановления для регенерации тега,
3) лицензии на пробное использование - после истечения срока действия лицензий на пробное использова
ние обновления тега должны отражать, что период пробного использования завершен (т. е. должен быть обновлен
элемент состояния активации (activation status)).
4) свидетельство взлома - если файл включает в себя подписанные элементы тега, программное обеспече
ние должно выполнять периодические проверки подписей с целью обнаружения возможного несанкционированно
го взлома тега. При обнаружении взлома тега программное обеспечение должно запустить механизм самовосста
новления для регенерации тега. Руководитель разработки и менеджер по продукту должны совместно определить
бизнес-политики в отношении взлома:
68