ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ
![](pnst_341-2019/pnst_341-2019_0.png)
ПРЕДВАРИТЕЛЬНЫЙ НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
пнет
341 — 2018
Интеллектуальные транспортные системы
АВТОМОБИЛЬНЫЕ ТРАНСПОРТНЫЕ СРЕДСТВА. ОБЩЕСТВЕННЫЙ ТРАНСПОРТ
Интероперабельная система оплаты проезда
(ISO 24014-1:2015, NEQ)
Издание официальное
![](pnst_341-2019/pnst_341-2019_1.png)
Москва Стакдартинформ 2019
ПНСТ 341—2018
Предисловие
1 РАЗРАБОТАН Обществом с ограниченной ответственностью «ТранснавиСофт» (ООО «Транс-навиСофт»)
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 57 «Интеллектуальные транспортные системы»
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 31 декабря 2018 г. № 73-лист
4 Настоящий стандарт разработан с учетом основных нормативных положений международного стандарта ИСО 24014-1.2015 «Общественный транспорт. Интероперабельная система оплаты проезда. Часть 1. Архитектура» (ISO 24014-1:2015 «Public transport — Interoperable fare management system — Part 1: Architecture», NEO)
Правила применения настоящего стандарта и проведения его мониторинга установлены в ГОСТ Р 1.16—2011 (разделы 5 и 6).
Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию cmandapnia можно направить не позднее чем за 4 мес до истечения срока его действия разработчику настоящего стандарта по адресу: 127083 Москва, ул. Мишина, д. 35 и в Федеральное агентство по техническому регулированию и метрологии по адресу: 109074 Москва. Китайгородский проезд, д. 7. стр. 1.
В случае отмены настоящего стандарта соответствующая информация будет опубликована в ежемесячном информационном указателе «Национальные стандарты» и также будет размещена на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет ()
© . оформление. 2019
Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии
I!
ПНСТ 341—2018
Содержание
1 Область применения .................................................................1
2 Термины и определения..............................................................1
3 Сокращения........................................................................3
4 Требования к модели интероперабельной системы оплаты проезда..........................3
5 Концептуальные основы..............................................................4
5.1 Описание ИОП-ролей интероперабельной системы оплаты проезда......................4
5.2 Основная структура обобщенной функциональной модели интероперабельной системы оплаты проезда.....................................................................6
6 Описание примеров использования интероперабельной системы оплаты проезда..............7
6.1 Сертификация...................................................................7
6.2 Регистрация.....................................................................9
6.3 Управление приложением........................................................10
6.4 Управление продуктом...........................................................13
6.5 Управление безопасностью.......................................................18
6.6 Управление обслуживанием клиента (опционное).....................................
7 Идентификация системного интерфейса................................................
8 Идентификация.....................................................................
8.1 Общие положения...............................................................
8.2 Схема идентификации...........................................................
8.3 Предпосылки...................................................................
9 Безопасность в интегральной системе оплаты проезда....................................
9.1 Защита интересов общественности.................................................
9.2 Активы, подлежащие защите......................................................
9.3 Общие требования безопасности в интегральной системе оплаты проезда................
ммюммммммм A^WWWWWWMM
Приложение А (справочное) Поток информации в интероперабельной системе оплаты проезда... .26
Приложение Б (справочное) Пример процессов в списке действий............................36
Приложение В (справочное) Область безопасности, угрозы и профили защиты.................38
Библиография.......................................................................40
III
ПНСТ 341—2018
Введение
Управление оплатой проезда (УОП) охватывает все процессы, предназначенные для управления распределением и использованием продуктов системы оплаты проезда в общественном транспорте (ОТ).
Система оплаты проезда называется интероперабельной, когда она позволяет клиенту использовать носимое электронное средство (например, контактную/бесконтактную смарт-карту), совместимое с оборудованием (в частности, на остановках, в розничных системах продажи, при входе на платформы остановок ОТ или на борту транспортных средств). Концепции интероперабельных систем оплаты проезда (ИСОП) также могут быть применены к системам управления тарифами, не использующим электронные носители.
Потенциальные выгоды для клиента включают сокращение потери времени в очередях, использование специальных и комбинированных тарифов, одного средства оплаты во многих приложениях, а также участие в программах лояльности.
Интероперабельные системы оплаты проезда обеспечивают также выгоды операторам и другим участникам процесса. Однако использование этих систем требует наличия общей архитектуры, которая определяет состав действующих участников процесса, их роли, отношения и интерфейс взаимодействия.
Интероперабельность также требует определения схемы безопасности для защиты конфиденциальности и целостности отношений между участниками для обеспечения справедливого и безопасного обмена данными в рамках ИСОП. Общая архитектура является предметом настоящего стандарта, в котором признается необходимость юридических и коммерческих соглашений между членами ИСОП. но не уточняется их форма. Техническио спецификации отдельных компонентов в общем и стандарты на средства оплаты пользователей (например, смарт-карты) в частности не включены в настоящий стандарт.
В связи с тем что не существует единой ИСОП. отдельные операторы, консорциумы операторов, государственные органы и частные компании могут управлять или принимать участие в управлении ИСОП. Данная система может распространяться и объединяться с другими подобными системами. Применение ИСОП требует обеспечения безопасности и регистрации функциональных возможностей. Настоящий стандарт описывает эти функции с целью координации/сближения существующих ИСОП для совместной работы.
Настоящий стандарт содержит описание трех основных преимуществ:
а) обеспечение основы для реализации совместимого УОП с минимальными трудностями:
б) сокращение времени и снижение стоимости закупок с помощью ИСОП. что позволяет покупателям понять, что именно приобретается. Закупки на основе открытого стандарта снижают стоимость, позволяют избежать дорогостоящей разработки системы на заказ.
в) упрощение взаимодействия между разными ИСОП. в котором заинтересованы все стороны процесса.
В приложении А дано описание потоков информации в ИСОП. В приложении Б приведено описание основных характеристик списков действий, относящихся к медиафайлам, приложениям или продуктам. которые выполняются в ИСОП. В приложении В описаны область безопасности, угрозы и профили защиты ИСОП.
В настоящем стандарте использованы разработки архитектуры электронной системы оплаты проезда Electronic Fee Collecion и другие документы', а также существующие международные стандарты по безопасности данных.
См. [1J —[3].
IV
ПНСТ 341—2018
ПРЕДВАРИТЕЛЬНЫЙ НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Интеллектуальные транспортные системы
АВТОМОБИЛЬНЫЕ ТРАНСПОРТНЫЕ СРЕДСТВА. ОБЩЕСТВЕННЫЙ ТРАНСПОРТ
Интероперабельная система оплаты проезда
Intelligent transport systems. Road transport vehicles.
Public transport Interoperable fare management system
Срок действия — с 2019—06—01 до 2022—06—01
1 Область применения
Настоящий стандарт обеспечивает основу для развития мультиоператорных/мультисервисных взаимодействующих интероперабельных систем оплаты проезда (далее — ИСОП) для общественного наземного (а также метро) пассажирского транспорта.
Настоящий стандарт предназначен для применения в организациях общественного транспорта (далее — ОТ) и связанных с ними службах при условии взаимодействия их систем и не подразумевает, что существующие совместимые системы оплаты проезда будут изменены, так как он применяется в пределах их допустимых изменений.
В настоящем стандарте определена эталонная функциональная архитектура для ИСОП и установлены требования, которые имеют отношение к обеспечению совместимости между несколькими участниками в контексте использования электронных билетов.
Настоящий стандарт определяет следующие основные элементы:
- идентификация различного набора функций по отношению к общей системе оплаты проезда.
- общая модель ИСОП. описывающая логическую и функциональную архитектуру и интерфейсы как внутри, так и между разными ИСОП;
- примеры взаимодействия и потоки данных между различными наборами функций:
- требования безопасности.
Настоящий стандарт не включает рассмотрение следующих тем:
- физическая среда и ее управление;
- технические аспекты интерфейса между носителем и устройством доступа к среде;
- обмен данными между носителем и устройством доступа к среде.
Примечание — Обмен данными между носителем и устройством доступа к среде рассматривается другими комитетами по стандартизации:
- финансовые аспекты ИСОП (например, платежи клиентов, способ оплаты, урегулирование, распределение).
2 Термины и определения
В настоящем стандарте применены следующие термины с соответствующими определениями:
2.1 действующее лицо: Лицо, или организация (2.6), или другая (вспомогательная) система, выполняющие связанный набор функций при взаимодействии с интероперабельной системой оплаты проезда в конкретном случае использования (2.14).
Издание официальное
1
ПНСТ 341—2018
2.2 интероперабельная система оплаты проезда: ИСОП: Все технические, коммерческие, защитные и юридические элементы, которые обеспечивают интероперабельность оплаты проезда (2.26).
2.3 ИОП-роль: Абстрактный объект, выполняющий набор функций в функциональной модели интероперабельной системы оплаты проезда (2.28).
2.4 коммерческие правила: Правила, определяющие расчет и комиссию в рамках интероперабельной системы оплаты проезда.
2.5 компонент: Аппаратное и/или программное обеспечение, которое выполняет одну или несколько функций интероперабельной системы оплаты проезда.
2.6 организация: Юридическое лицо, выполняющее функции и подразумеваемые обязанности одной или нескольких из следующих операционных ИОП-ролей (2.3): владелец приложения, розничный торговец приложения, владелец продукта, продавец продуктов, оператор услуг, а также юридическое лицо, выполняющее функции сбора и пересылки.
2.7 политика безопасности: Цели интероперабельной системы оплаты проезда для обеспечения общественных интересов и защиты активов в рамках данной системы.
2.8 политики интероперабельной системы оплаты проезда: Коммерческие, технические цели интероперабельной системы оплаты проезда, а также касающиеся безопасности и конфиденциальности.
2.9 поставщик компонентов: Физическое или юридическое лицо, осуществляющее поставки компонентов (2.5) в интероперабельную систему оплаты проезда.
2.10 правила использования: Правила, определяющие время использования, область использования. персональный статус и тип услуги.
2.11 правила применения: Требования к владельцу приложения.
2.12 правила продукта: Набор использования, ценообразование и коммерческие правила (2.4), определенные владельцем продукта.
2.13 правила ценообразования: Правила, определяющие отношения с клиентом, касающиеся цены, оплаты и выставления счетов.
2.14 прецедент: Описание процесса путем определения последовательности действий, выполняемых одним или несколькими действующими лицами (2.1) и интероперабельной системой оплаты проезда.
2.15 приложение: Реализованный и инициализированный шаблон приложения (2.29).
Примечания
1 Приложение идентифицируется уникальным идентификатором.
2 В приложении представлены продукты (2.16) и другая дополнительная информация о клиенте (описание клиента, предпочтения клиента).
3 Приложение может быть установлено на носителе устройства клиента или распределено на клиентских носителях и в подразделениях интероперабельной системы оплаты проезда.
2.16 продукт: Экземпляр шаблона продукта (2.30), хранящегося в приложении (2.15).
Примечание — Продукт идентифицируется уникальным идентификатором и позволяет клиенту воспользоваться услугой, предоставленной оператором обслуживания.
2.17 роль: Абстрактный объект, выполняющий набор функций.
2.18 спецификация приложения: Спецификация функций, элементов данных и схемы обеспечения безопасности, соответствующие правилам применения (2.11).
2.19 список действий: Список элементов, связанных с приложениями или продуктами (2.16) интероперабельной системы оплаты проезда, загруженными на устройства доступа к среде (2.27). обрабатываемых устройством доступа к среде, если и когда конкретное приложение интероперабельной системы оплаты проезда или продукт, упомянутый в списке, обрабатывается этим устройством доступа к среде.
2.20 сообщение: Набор элементов данных, передаваемых между двумя ИОП-ролями (2.3).
2.21 список правил: Правила для достижения политики интероперабельной системы оплаты проезда (2.8). выраженные как технические, коммерческие, защитные и правовые требования и стандарты. относящиеся только к интероперабельной системе оплаты проезда.
2.22 среда: Физический носитель приложений (2.15).
2.23 среда клиента: Среда (2.22). инициализированная приложением (2.15) клиента.
2.24 спецификация продукта: Полная спецификация функций, элементов данных и схема безопасности в соответствии с правилами продукта (2.12).
2
ПНСТ 341—2018
2.25 триггер: Событие, которое вызывает выполнение прецедента (2.14).
2.26 управление интероперабельной системой оплаты проезда: Все функции, связанные с процессом оплаты проезда, такие как управление приложением, работа с экземплярами шаблонов продукта (2.30). функции безопасности, сертификации, регистрации и идентификации, необходимые для обеспечения доступа клиента через оператора обслуживания с использованием одного портативного электронного устройства.
2.27 устройство доступа к среде: УДС: Устройство, имеющее необходимые средства (аппаратное и программное обеспечение) для связи со средой клиента (2.23).
2.28 функциональная модель интероперабельной системы оплаты проезда: Модель для определения функций объектов и их взаимодействия.
2.29 шаблон приложения: Исполняемый технический образец спецификации приложения (2.18).
2.30 шаблон продукта: Технический паттерн спецификации продукта (2.24).
Примечание — Шаблон продукта идентифицируется уникальным идентификатором.
3 Сокращения
В настоящем стандарте применены следующие сокращения:
- ИОП — интероперабельная оплата проезда,
- ИСОП — интероперабельная система оплаты проезда,
- ОТ — общественный транспорт;
- ПБ — подсистема безопасности:
- ПЗ — профиль защиты;
- УДС — устройство доступа к среде;
- ЦО — цель оценивания.
4 Требования к модели интероперабельной системы оплаты проезда
Целью настоящего стандарта является достижение совместимости всех используемых систем оплаты проезда при условии, что компании-участники коммерчески независимы при разработке собственных продуктов и при реализации своих бизнес-стратегий.
Конкретные требования к модели ИСОП заключаются в следующем:
- клиент должен иметь возможность использовать услуги всех операторов «бесшовно», используя единую среду;
- должна быть обеспечена возможность извлечения данных, соответствующих распределению доходов и статистике запросов операторов транспорта;
- среда может быть использована для дополнительных приложений, и наоборот, другие среды могут использовать приложения ИСОП;
- методы продажи билетов конкретного приложения должны предоставлять возможность снижения затрат времени на вход/выход пассажиров в системе ОТ и значительно уменьшать затраты на отработку платежей.
Модель ИСОП должна:
- соответствовать законамФравилам предоставления финансовых услуг и защиты данных (например. неприкосновенности частной жизни);
- обеспечивать возможность размещения новых спецификаций продукта по мере необходимости, независимо от уже существующих;
- распознавать и предотвращать внутренние или внешние хакерские атаки,
- идентифицировать клиентов, одновременно защищая их конфиденциальность:
- защищать конфиденциальность клиента;
- обеспечивать целостность обмениваемых данных;
- удовлетворять другим сервисам, таким как программы лояльности, оплата услуг каршеринга, оплата краткосрочной парковки, краткосрочной аренды велосипедов и т. д.;
- описывать взаимосвязь между определенными функциями в системе ОТ. посредством которых осуществляется взаимодействие между различными сетями операторов;
3
ПНСТ 341—2018
- описывать интерфейсы, которые необходимы для обеспечения функций пересылки данных между различными сетями операторов, позволяющих выполнять соглашения о распределении доходов;
- обеспечивать основу заключения коммерческих соглашений;
- быть нейтральной в отношении различных технологических особенностей при реализации системы. которые могут быть применены (например, контактная среда, бесконтактная среда, малая дальность. широкий диапазон);
- быть функционально нейтральной в отношении конкретных организационных структур ОТ.
5 Концептуальные основы
Интероперабельная система оплаты проезда может управляться транспортным предприятием, транспортным органом, объединением общественных и частных компаний или другими группами.
Менеджер ИСОП устанавливает и управляет ее политикой, реализуемой набором правил.
Для управления элементами ИСОП. рассматриваемыми в настоящем разделе, ее менеджер должен назначить менеджера службы безопасности и регистратора.
Функции и обязанности менеджера службы безопасности и регистратора могут быть распределены между несколькими организациями в рамках ИСОП. Это может быть необходимым условием для существующих ИСОП. Пример представлен в разделе В.З приложения В. в котором также показано, каким образом набор правил для объединенной ИСОП может быть построен с использованием существующих наборов правил для взаимодействующих ИСОП.
5.1 Описание ИОП-ролей интероперабельной системы оплаты проезда
Описание ИОП-ролей в ИСОП представлено в таблице 1.
ИОП-роли обозначаются заглавными начальными буквами.
Таблица 1 — Описание ИОП-ролей интероперабельной системы оплаты проезда
Роль | Описание роли |
Владелец продукта | Владелец продукта несет ответственность за свои продукты. Функции владения: - указание цен. установление правил использования и коммерческих правил. Функции очистки: - реконструкция: - агрегирование продукта на основе полученных данных с использованием правил определения продукта |
Розничный продавец продуктов | Розничный продавец, авторизованный владельцем продакта, продает и прекращает продажу продукта, осуществляет сбор и возврат средств клиенту. Розничный продавец продуктов — это единственный финансовый интерфейс между клиентом и ИСОП. связанный с продуктами |
Розничный продавец приложений | Розничный продавец, авторизованный владельцем приложения, продает и прекращает использование приложения, собирает и возвращает стоимость клиенту. Розничный продавец приложений — это единственный финансовый интерфейс между клиентом и ИСОП. связанный с приложением |
Служба сбора и пересылки данных | ИОП-роль службы сбора и пересылка являются упрощением обмена данными в ИСОП. Служба сбора и пересылки включает, как минимум, следующие функции сбора: - получение шаблона приложения от владельца приложения; - получение шаблона продукта от владельца продукта: - получение данных от операторов услуг; - получение данных от розничного продавца продукта: - получение данных от розничного продавца приложений: - получение данных из других служб сбора и пересылки: |
4
Окончание таблицы 1
ПНСТ 341—2018
Роль | Описание роли |
Служба сбора и пересылки данных | - получение данных списка безопасности от менеджера безопасности; - получение отчетов о взаиморасчетах от владельца продукта; - проверка согласованности и полноты данных, собранных на технический уровень; - получение от регистратора списка адресов всех ИОП-ролей в ИСОП. Функции пересылки: - пересылка данных «НЕ НА НАС» на другую службу сбора и пересылки; - запись данных «НЕ НА НАС»; - пересылка данных с поврежденным адресом назначения менеджеру безопасности; - передача данных «О НАС» владельцу продукта для клиринга и отчетност; - пересылка клиринговых отчетов, шаблонов приложений, шаблонов продуктов и данных списка безопасности продавцу продукта и услуг оператору услуг; - пересылка шаблонов приложений и данных списка безопасности розничному продавцу приложений оператору услуг. Примечание — Концепция «НА НАС» и «НЕ НА НАС» выгладит следующим образом: - специфическая функция сбора и пересылки — это сбор данных от одной ИОП-роли и их перенаправление другим ИОП-ролям; - логически может быть несколько служб сбора и пересылки в рамках ИСОП; - ИОП-роли могут быть связаны с другой службой сбора и пересылки, но каждая ИОП-роль может быть связана только с одной службой; - понятие «НА НАС» и «НЕ НА НАС» касается следующей функциональности: данные. хранящиеся в определенной службе сбора и пересыпки, могут быть либо данными «НА НАС», либо данными «НЕ НА НАС»; - данные, собранные с помощью конкретной службы сбора и пересылки, адресуются ИОП-ролям, непосредственно связанным с этой службой, и называются данными «НА НАС»; - данные, собранные с помощью определенной службы сбора и пересыпки, адресуются ИОП-ролям. не связанным с этой службой, и называются данными «НЕ НА НАС» |
Поставщик услуг | Поставщик услуг предоставляет услугу клиенту по использованию продукта |
Владелец приложения | Владелец приложения заключает контракт с клиентом на использование приложения |
Сервисная служба | В соответствии с коммерческими соглашениями сервисная служба для клиентов может предоставлять «телефон доверия» и любые аналогичные услуги. Эти услуги включают замену похищенных и поврежденных клиентских носителей и последующую переустановку продукта |
Покупатель | Клиент имеет приложение и приобретает продукты для пользования услугами ОТ |
Менеджер службы безопасности | Менеджер службы безопасности отвечает за формирование и координацию политики безопасности, а также: - за сертификацию организаций, шаблонов приложений, компонентов и шаблонов продуктов; - аудит организаций, шаблонов приложений/приложений, компонентов, шаблонов продуктов.'продуктов: - мониторинг системы и обеспечение безопасности ИСОП |
Регистратор | После сертификации регистратор выдает уникальные регистрационные коды для организаций. компонентов, шаблонов приложений и шаблонов продуктов. Регистратор также выдает уникальные идентификаторы или правила для создания уникальных идентификаторов для приложений, продуктов и создает сообщения |
5
ПНСТ 341—2018
5.2 Основная структура обобщенной функциональной модели интероперабельной системы оплаты проезда
Связи между используемыми ИОП-ролями ИСОП проиллюстрированы на рисунке 1. Эти связи представляют собой информационные потоки. Опциональные связи и ИОП-роли показаны пунктирными линиями.
Предполагается, что клиент уже имеет носитель или снабжен им одним из продавцов приложений, поэтому в модели представлены только приложения и продукты. В рамках ИСОП может быть несколько организаций, выполняющих функции ИОП-ролеи.
Менеджер ИСОП устанавливает и управляет политиками в данной системе. Эти политики реализованы в наборе правил. Менеджер ИСОП будет взаимодействовать с эмитентами среды; клиент — с эмитентом клиентской среды, которой он владеет. Кроме того, владелец приложения будет взаимодействовать с эмитентами среды.
![](pnst_341-2019/pnst_341-2019_2.jpg)
Рисунок 1 — Связи между операционными ИОП-ропями в ИСОП
Для управления элементами системы функциональная модель ИСОП включает две управляющие ИОП-роли:
- регистратор — ИОП-роль для идентификации любой организации, компонента, шаблона приложения и приложения, шаблона продукта и продукта, действующих в ИСОП;
- менеджер службы безопасности — вспомогательная ИОП-роль. ответственная за безопасную работу в ИСОП.
На рисунке 2 показаны два домена ИОП-ролей и взаимодействие между ними.
б
ПНСТ 341—2018
![](pnst_341-2019/pnst_341-2019_3.jpg)
![](pnst_341-2019/pnst_341-2019_4.jpg)
Рисунок 2 — Операционный и управляющий домены ИСОП
6 Описание примеров использования интероперабельной системы оплаты проезда
В этом разделе описаны примеры использования ИСОП. Набор данных примеров предоставляет инструментарий для внедрения ИСОП. Если процессы, описанные в примере применения, реализованы в рамках ИСОП. использование является обязательным. Однако приведенные примеры могут быть адаптированы с изменениями в зависимости от способов управления приложениями и продуктами. Приложение, продукт могут управляться либо из среды, либо из центрального операционно-учетного подразделения. Возможны любые варианты или комбинации между данными двумя подходами управления:
- из специализированного центра — основные процессы (например, расчет оплаты за проезд, биллинг) управления приложением и продуктом осуществляются между средой и УДС;
- центрального операционно-учетного подразделения — основные процессы управления приложением и/или продуктом осуществляются непосредственно в центральном операционно-учетном подразделении.
Ниже приведены примеры использования, описывающие функциональные аспекты ИСОП. Вопросы договорных отношений находятся вне сферы применения настоящего стандарта, но являются необходимым условием для реализации услуг. Наименования субъектов, действующих в приведенных примерах использования, приведены прописными буквами.
6.1 Сертификация
Каждый объект, который будет представлен в ИСОП. должен соответствовать требованиям ИСОП, доказательством чему является результат проверки объекта на соответствие набору определенных правил. Этот процесс называется сертификацией.
За проведение сертификации объектов отвечает менеджер службы безопасности. В рамках ИСОП сертифицируются:
- организации:
- компоненты, связанные с безопасностью;
- спецификация и шаблон приложения;
- спецификация и шаблон продукта.
Информация в отношении сертификации оформлена в табличной форме.
7
ПНСТ 341—2018
6.1.1 Сертификация организации
Наименование примера | Сертификация организации |
Схема сертификации | Каждая организация, которая хочет участвовать в ИСОП. соглашается соблюдать установленный список правил |
Инициализация | Инициализируется ОРГАНИЗАЦИЕЙ |
Действующие субъекты | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ. ОРГАНИЗАЦИЯ |
Описание примера | Если МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ подтверждает, что ОРГАНИЗАЦИЯ согласна соблюдать правила, го ОРГАНИЗАЦИЯ будет сертифицирована; иначе ОРГАНИЗАЦИЯ не будет сертифицирована |
6.1.2 Сертификация компонента
Наименование примера | Сертификация компонента |
Схема сертификации | Каждый компонент, который загружается в ИСОП. должен удовлетворять ее требованиям. Проверка данного условия осуществляется проверкой компонента на соблюдение установленного набора правил |
Инициализация | Инициализируется ПОСТАВЩИКОМ КОМПОНЕНТА |
Действующие субъекты | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ. ПОСТАВЩИК КОМПОНЕНТА |
Описание примера | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ проверяет компонент на соответствие набору правил, и если компонент соответствует набору правил, то компонент будет сертифицирован. Иначе компонент не будет сертифицирован |
6.1.3 Сертификация спецификации и шаблона приложения
Наименование примера | Сертификация спецификации и шаблона приложения |
Схема сертификации | Каждая спецификация и шаблон приложения, которые загружаются в ИСОП. должны удовлетворять ее требованиям. Проверка данного условия осуществляется проверкой спецификации и шаблона приложения на соблюдение установленного набора правил |
Инициализация | Инициализируется ВЛАДЕЛЬЦЕМ ПРИЛОЖЕНИЯ |
Действующие субъекты | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ. ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ |
Описание примера | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ проверяет спецификацию и шаблон приложения на соблюдение установленного набора правил. Если спецификация и шаблон приложения соответствуют набору правил, то спецификация и шаблон приложения будут сертифицированы. Иначе спецификация и шаблон приложения не будут сертифицированы |
6.1.4 Сертификация спецификации и шаблона продукта
Наименование примера | Сертификация спецификации и шаблона продукта |
Схема сертификации | Каждая спецификация и шаблон продукта, которые загружаются в ИСОП. должны удовлетворять ее требованиям. Проверка данного условия заключается в проверке спецификации и шаблона продукта на соблюдение установленного набора правил |
Инициализация | Инициализируется ВЛАДЕЛЬЦЕМ ПРОДУКТА |
Действующие субъекты | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ. ВЛАДЕЛЕЦ ПРОДУКТА |
8
Окончание таблицы
ПНСТ 341—2018
Наименование примера | Сертификация спецификации и шаблона продукта |
Описание примера | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ проверяет спецификацию и шаблон продукта на соблюдение установленного набора правил. Если спецификация и шаблон продукта соответствуют набору правил, то спецификация и шаблон продукта будут сертифицированы. В противном случае спецификация и шаблон приложения не будут сертифицированы |
6.2 Регистрация
Регистрация необходима для того, чтобы каждый экземпляр объекта был уникальным в рамках ИСОП. Это гарантируется присвоением экземпляру объекта уникального идентификатора. Процесс управления этими идентификаторами называется регистрацией. Объектами и экземплярами объектов в рамках ИСОП, которые должны быть зарегистрированы, являются:
- организации:
- компоненты;
- шаблон приложения и приложение:
- шаблон продукта и продукт.
За процесс регистрации несет ответственность РЕГИСТРАТОР ИСОП.
Информация, касающаяся регистрации, изложена в табличной форме.
6.2.1 Регистрация организации
Наименование примера | Регистрация орта цитации |
Схема регистрации | Каждой организации присваивается уникальный идентификатор |
Инициализация | Инициализируется ОРГАНИЗАЦИЕЙ |
Действующие субъекты | РЕГИСТРАТОР. ОРГАНИЗАЦИЯ |
Описание примера | ОРГАНИЗАЦИЯ высылает РЕГИСТРАТОРУ свой сертификат. РЕГИСТРАТОР в ответ высыпает ОРГАНИЗАЦИИ уникальный идентификатор |
6.2.2 Регистрация компонента
Наименование примера | Регистрация компонента |
Схема регистрации | Каждый компонент получает уникальный идентификатор |
Инициализация | Инициализируется ПОСТАВЩИКОМ КОМПОНЕНТА |
Действующие субъекты | РЕГИСТРАТОР. ПОСТАВЩИК КОМПОНЕНТА |
Описание примера | ПОСТАВЩИК КОМПОНЕНТА высылает РЕГИСТРАТОРУ сертификат компонента. РЕГИСТРАТОР в ответ высылает ПОСТАВЩИКУ КОМПОНЕНТА уникальный идентификатор компонента |
6.2.3 Регистрация шаблона приложения
Наименование примера | Регистрация шаблона приложения |
Схема регистрации | Каждый шаблон приложения, который загружается в ИСОП. получает уникальный идентификатор |
Инициализация | Инициализируется ВЛАДЕЛЬЦЕМ ПРИЛОЖЕНИЯ |
Действующие субьекты | РЕГИСТРАТОР. ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ |
Описание примера | ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ высылает РЕГИСТРАТОРУ сертификат шаблона приложения. РЕГИСТРАТОР в ответ высылает ВЛАДЕЛЬЦУ ПРИЛОЖЕНИЯ уникальный идентификатор шаблона приложения |
9
ПНСТ 341—2018
6.2.4 Регистрация приложения
Наименование примера | Регистрация приложения |
Схема регистрации | Каждое приложение, которое загружается в ИСОП. получает уникальный идентификатор |
Инициализация | Инициализируется ВЛАДЕЛЬЦЕМ ПРИЛОЖЕНИЯ |
Действующие субъекты | РЕГИСТРАТОР. ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ |
Описание примера | ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ высылает РЕГИСТРАТОРУ сертификат приложения. РЕГИСТРАТОР в ответ высылает ВЛАДЕЛЬЦУ ПРИЛОЖЕНИЯ уникальный идентификатор приложения |
6.2.5 Регистрация шаблона продукта
Наименование примера | Регистрация шаблона продукта |
Схема регистрации | Каждый шаблон продукта, который загружается в ИСОП. должен получить уникальный идентификатор |
Инициализация | Инициализируется ВЛАДЕЛЬЦЕМ ПРОДУКТА |
Действующие субъекты | РЕГИСТРАТОР. ВЛАДЕЛЕЦ ПРОДУКТА |
Описание примера | ВЛАДЕЛЕЦ ПРОДУКТА высылает РЕГИСТРАТОРУ сертификат шаблона продукта. РЕГИСТРАТОР в ответ высылает ВЛАДЕЛЬЦУ ПРОДУКТА уникальный идентификатор шаблона продукта |
6.2.6 Регистрация продукта
Наименование примера | Регистрация продукта |
Схема регистрации | Каждый продукт, который загружается в ИСОП. должен получить уникальный идентификатор |
Инициализация | Инициализируется ВЛАДЕЛЬЦЕМ ПРОДУКТА |
Действующие субъекты | РЕГИСТРАТОР. ВЛАДЕЛЕЦ ПРОДУКТА |
Описание примера | ВЛАДЕЛЕЦ ПРОДУКТА высылает РЕГИСТРАТОРУ сертификат продукта. РЕГИСТРАТОР в ответ высылает ВЛАДЕЛЬЦУ ПРОДУКТА уникальный идентификатор продукта |
6.3 Управление приложением
Управление приложением включает:
• распространение шаблонов приложений;
- получение приложений;
- прекращение использования шаблонов приложений;
- прекращение использования приложения.
Распространяться должны только сертифицированные и зарегистрированные шаблоны приложений.
Обновление приложения заключается в прекращении применения действующего приложения и приобретении нового приложения.
Информация, касающаяся управления приложениями, приведена в табличной форме.
10
ПНСТ 341—2018
6.3.1 Распространение шаблона приложения
Наименование примерз | Распространение шаблона приложения |
Схема распространения | Распространение шаблона приложения позволяет авторизованному розничному продавцу продавать приложение и авторизованному поставщику услуг осуществлять доступ к этому приложению |
Инициализация | Инициализируется ВЛАДЕЛЬЦЕМ ПРИЛОЖЕНИЯ |
Действующие субъекты | Продавец ПРИЛОЖЕНИЯ. ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ. СЛУЖБА СБОРА и ПРОДВИЖЕНИЯ. ПОСТАВЩИК УСЛУГ |
Описание примера | Распространение шаблона приложения включает распространение зарегистрированного шаблона приложения ВЛАДЕЛЬЦЕМ ПРИЛОЖЕНИЯ ПРОДАВЦУ через СЛУЖБУ СБОРА и ПРОДВИЖЕНИЯ |
6.3.2 Приобретение приложения
Наименование примера | Приобретение приложения |
Схема приобретения | Приложение загружается в среду покупателя |
Инициализация | Инициализируется Покупателем |
Действующие субъекты | Продавец ПРИЛОЖЕНИЯ. ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ. СЛУЖБА СБОРА и ПРОДВИЖЕНИЯ. ПОКУПАТЕЛЬ |
Описание примера | Авторизованный ПРОДАВЕЦ устанавливает экземпляр зарегистрированного шаблона приложения на носителе. Авторизованный ПРОДАВЕЦ: - устанавливает экземпляр зарегистрированного шаблона приложения; - пересылает идентификатор приложения и данных приложения ВЛАДЕЛЬЦУ ПРИЛОЖЕНИЯ через СЛУЖБУ СБОРА и РАСПРОСТРАНЕНИЯ |
6.3.3 Завершение применения шаблона приложения
Пример использования «Завершение применения шаблона приложения» включает следующее:
- нормальное завершение применения шаблона приложения;
- принудительное завершение применения шаблона приложения.
Данные примеры приведены в табличной форме.
6.3.3.1 Нормальное завершение применения шаблона приложения
Наименование примера | Нормальное завершение применения шаблона приложении |
Схема завершения | Шаблон приложения завершается в ИСОП по запросу ВЛАДЕЛЬЦА ПРИЛОЖЕНИЯ |
Инициализация | Инициализируется ВЛАДЕЛЬЦЕМ ПРИЛОЖЕНИЯ |
Действующие субъекты | ПРОДАВЕЦ ПРИЛОЖЕНИЯ. ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ, СЛУЖБА СБОРА и ПРОДВИЖЕНИЯ. РЕГИСТРАТОР. СЛУЖБА БЕЗОПАСНОСТИ |
11
ПНСТ 341—2018
Окончание таблицы
Наименование примера | Нормальное завершение применения шаблона приложения |
Описание примера | ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ закрывает шаблон приложения. Эго действие включает информирование: - ПРОДАВЦА приложения о завершении регистрации шаблона приложения через СЛУЖБУ СБОРА и ПРОДВИЖЕНИЯ; - ПОСТАВЩИКА УСЛУГ о прекращении регистрации шаблона приложения через СЛУЖБУ СБОРА и ПРОДВИЖЕНИЯ; - ПРОДАВЦА продукта о завершении регистрации шаблона приложения через СЛУЖБУ СБОРА и ПРОДВИЖЕНИЯ; - МЕНЕДЖЕРА СЛУЖБЫ БЕЗОПАСНОСТИ о прекращении регистрации шаблона приложения; - РЕГИСТРАТОРА о завершении регистрации шаблона приложения; - (необязательно) СЕРВИСНОЙ СЛУЖБЫ о завершении зарегистрированного шаблона приложения; - (необязагельно) ВЛАДЕЛЬЦА ПРИЛОЖЕНИЯ И МЕНЕДЖЕРА СЛУЖБЫ БЕЗОПАСНОСТИ через СЛУЖБУ СБОРА И РАПРОСТРАНЕНИЯ с помощью УДС об идентификаторе шаблона приложения и данных о завершении шаблона приложения |
6.3.3.2 Принудительное завершение применения шаблона приложения
Наименование примера | Принудительное завершение прикенеиия шаблона приложения |
Схема завершения | Шаблон приложения завершается в ИСОП РЕГИСТРАТОРОМ и МЕНЕДЖЕРОМ ИСОП |
Инициализация | Инициализируется МЕНЕДЖЕРОМ ИСОП |
Действующие субъекты | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ |
Описание примера | МЕНЕДЖЕР ИСОП посылает запрос на завершение шаблона приложения МЕНЕДЖЕРУ СЛУЖБЫ БЕЗОПАСНОСТИ |
6.3.4 Завершение применения приложения
Примеры использования «Завершение применения приложения» включает следующее: - нормальное завершение применения приложения.
- принудительное завершение применения приложения.
Данные примеры приведены в табличной форме.
6.3.4.1 Нормальное завершение применения приложения
Наименование примера | Нормальное завершение применения приложения |
Схема завершения | Приложение завершается в среде ПОКУПАТЕЛЯ |
Инициализация | Инициализируется ПОКУПАТЕЛЕМ |
Действующие субъекты | ПРОДАВЕЦ ПРИЛОЖЕНИЯ. ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ. СЛУЖБА СБОРА и ПРОДВИЖЕНИЯ. РЕГИСТРАТОР ПОКУПАТЕЛЬ |
Описание примера | ПОКУПАТЕЛЬ завершает применение приложения. Это действие включает; - деинсталляцию ПРИЛОЖЕНИЯ ПРОДАВЦОМ ПРИЛОЖЕНИЯ в среде ПОКУПАТЕЛЯ; - пересылку идентификатора деинсталлированного приложения ВЛАДЕЛЬЦУ ПРИЛОЖЕНИЯ через СЛУЖБУ СБОРА и ПРОДВИЖЕНИЯ; - пересылку ВЛАДЕЛЬЦЕМ ПРИЛОЖЕНИЯ РЕГИСТРАТОРУ идентификатора деинсталлированного приложения |
12
ПНСТ 341—2018
6.3.4.2 Принудительное завершение применения приложения
Наименование примера | Принудительное завершение применения приложения |
Схема завершения | Приложение помещается в список безопасности по запросу ВЛАДЕЛЬЦА ПРИЛОЖЕНИЯ |
Инициализация | Инициализируется ВЛАДЕЛЬЦЕМ ПРИЛОЖЕНИЯ |
Действующие субъекты | ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ. СЛУЖБА СБОРА и ПРОДВИЖЕНИЯ. МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ |
Описание примера | ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ завершает приложение и посылает идентификатор приложения МЕНЕДЖЕРУ СЛУЖБЫ БЕЗОПАСНОСТИ через СЛУЖБУ СБОРА и ПРОДВИЖЕНИЯ |
6.4 Управление продуктом
Управление продуктом включает следующее:
- распространение шаблона продукта;
- завершение действия шаблона продукта;
- управление списком действий;
- приобретение продукта;
- изменение параметров продукта,
- завершение действия продукта;
- использование и проверка продукта;
■ сбор данных,
- пересылка данных;
- генерация и распространение отчетов клиринга.
Информация, касающаяся управления продуктом, приведена в табличной форме.
6.4.1 Распространение шаблона продукта
Наименование примера | Распространение шаблона продукта |
Схема распространения | Распространение зарегистрированного шаблона продукта позволяет авторизованным действующим лицам работать с продуктом |
Инициализация | Инициализируется ВЛАДЕЛЬЦЕМ ПРОДУКТА |
Действующие субъекты | ПРОДАВЕЦ ПРИЛОЖЕНИЯ. ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ. СЛУЖБА СБОРА и ПРОДВИЖЕНИЯ. ПОСТАВЩИК УСЛУГ |
Описание примера | Распространение шаблона продукта включает следующее: - распределение шаблона продукта ВЛАДЕЛЬЦЕМ ПРОДУКТА через СЛУЖБУ СБОРА И ПРОДВИЖЕНИЯ; - распространение шаблона продукта через СЛУЖБУ СБОРА И ПРОДВИЖЕНИЯ авторизованным ПРОДАВЦАМ ПРОДУКТА; - распространение шаблона продукта через СЛУЖБУ СБОРА И ПРОДВИЖЕНИЯ авторизованным ПОСТАВЩИКАМ УСЛУГ |
6.4.2 Завершение применения шаблона продукта
Завершение применения шаблона продукта включает;
- нормальное завершение применения шаблона продукта;
- принудительное завершение применения шаблона продукта.
13
ПНСТ 341—2018
6.4.2.1 Нормальное завершение применения шаблона продукта
Наименование примера | Нормальное завершение применения шаблона продукта |
Схема завершения | Завершение применения шаблона продукта по решению ВЛАДЕЛЬЦА ПРИЛОЖЕНИЯ |
Инициализация | Инициализируется ВЛАДЕЛЬЦЕМ ПРИЛОЖЕНИЯ |
Действующие субъекты | ПРОДАВЕЦ ПРИЛОЖЕНИЯ. ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ. ПОСТАВЩИК УСЛУГ. СЛУЖБА СБОРА И ПРОДВИЖЕНИЯ |
Описание примера | Завершение применения шаблона продукта включает следующее: - распространение запроса на завершение шаблона продукта ВЛАДЕЛЬЦЕМ ПРОДУКТА через СЛУЖБУ СБОРА и ПРОДВИЖЕНИЯ; - распространение запроса на прекращение действия шаблона продукта через СЛУЖБУ СБОРА и ПРОДВИЖЕНИЯ авторизованному ПРОДАВЦУ ПРОДУКТА; - распространение запроса на прекращение действия шаблона продукта через СЛУЖБУ СБОРА и ПРОДВИЖЕНИЯ авторизованному ПОСТАВЩИКУ УСЛУГ; - отправка запроса на прекращение действия шаблона продукта ВЛАДЕЛЬЦЕМ ПРОДУКТА МЕНЕДЖЕРУ СЛУЖБЫ БЕЗОПАСНОСТИ; - (необязательно) отправка идентификатора завершенного шаблона продукта ВЛАДЕЛЬЦЕМ ПРОДУКТА РЕГИСТРАТОРУ |
6.4.2.2 Принудительное завершение применения шаблона продукта
Наименование примера | Принудительное завершение применения шаблона продукта |
Схема завершения | Принудительное завершение применения шаблона продукта по решению МЕНЕДЖЕРА ИСОП |
Инициализация | Инициализируется МЕНЕДЖЕРОМ ИСОП |
Действующие субъекты | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ |
Описание примера | МЕНЕДЖЕР ИСОП посылает запрос на завершение применения шаблона продукта МЕНЕДЖЕРУ СЛУЖБЫ БЕЗОПАСНОСТИ через СЛУЖБУ СБОРА и ПРОДВИЖЕНИЯ |
6.4.3 Управление списком действий
Наименование примера | Управление списком действий |
Схема управления | Управление списком действий позволяет выполнять действия, связанные с продуктами или приложениями |
Инициализация | Инициализируется ПРОДАВЦОМ ПРИЛОЖЕНИЯ. ПРОДАВЦОМ ПРОДУКТА или ПОКУПАТЕЛЕМ |
Действующие субъекты | ПРОДАВЕЦ ПРИЛОЖЕНИЯ. ПРОДАВЕЦ ПРОДУКТА. ПОКУПАТЕЛЬ. СЛУЖБА СБОРА и РАСПРОСТРАНЕНИЯ |
Описание примера | Управление списком действий включает: - добавление элемента в список действий, что приведет к одноразовому добавлению продукта'приложения к среде ПОКУПАТЕЛЯ: - добавление элемента в список действий, что приведет к однократному удалению продукта/приложения из среды ПОКУПАТЕЛЯ; - удаление элемента из списка действий; |
14
Окончание таблицы
ПНСТ 341—2018
Наименование примерз | Управление списком действий |
Описание примера | - объединение данных списка действий; - распределение списка действий для любого УДС. которое может обновлять продукты! приложения в среде заказчика через СЛУЖБУ СБОРА И РАСПРОСТРАНЕНИЯ. После обновления среды для клиентов УДС отправляет информацию в список действий |
6.4.4 Приобретение продукта
Наименование примера | Приобретение продукта |
Схема приобретения | Приобретение продукта позволяет ПОКУПАТЕЛЮ получать транспортные услуги |
Инициализация | Инициализируется ПОКУПАТЕЛЕМ |
Действующие субъекты | ПРОДАВЕЦ ПРОДУКТА. ПОКУПАТЕЛЬ. СЛУЖБА СБОРА И РАСПРОСТРАНЕНИЯ. ВЛАДЕЛЕЦ ПРОДУКТА |
Описание примера | Авторизованный ПРОДАВЕЦ ПРОДУКТА устанавливает экземпляр зарегистрированного шаблона продукта на зарегистрированном приложении. Розничный торговец продуктов выполняет следующие действия: - обнаружение и проверку зарегистрированного приложения: - проверку заявки в соответствии с политикой безопасности; - установку экземпляра зарегистрированного шаблона продукта; - распределение идентификатора продукта и данных о приобретении продукта ВЛАДЕЛЬЦУ ПРОДУКТА через СЛУЖБУ СБОРА И РАСПРОСТРАНЕНИЯ |
6.4.5 Модификация параметров продукта
Наименование примера | Модификация параметров продукта |
Схема модификации | Модификация изменяемых параметров продукта |
Инициализация | Инициализируется ПОКУПАТЕЛЕМ |
Действующие субъекты | ПРОДАВЕЦ ПРОДУКТА. ПОКУПАТЕЛЬ. СЛУЖБА СБОРА И РАСПРОСТРАНЕНИЯ. ВЛАДЕЛЕЦ ПРОДУКТА |
Описание примера | Авторизованный ПРОДАВЕЦ ПРОДУКТА модифицирует изменяемые параметры существующего продукта. ПРОДАВЕЦ ПРОДУКТА передает идентификатор продукта и данные модифицированного продукта ВЛАДЕЛЬЦУ ПРОДУКТА через СЛУЖБУ СБОРА И РАСПРОСТРАНЕНИЯ |
6.4.6 Прекращение испопьзования продукта
Прекращение использования продукта означает, что в дальнейшем он не может быть восстановлен.
Использование продукта прекращается только по уважительной причине, например: не выполнена оплата продукта или продукт продан по ошибке. Повторная активация такого продукта связана с риском его нелегитимного использования. Для лучшей практики требуется, чтобы прекращенные продукты не могли быть повторно активированы. Похожие продукты могут, конечно, заменить их. Прекращение использования продукта включает следующие варианты:
15
ПНСТ 341—2018
- нормальное прекращение использования продукта;
- принудительное прекращение использования продукта.
6.4.6.1 Нормальное прекращение использования продукта
Наименование примера | Нормальное прекращение использования продукта |
Схема | Прекращение использования продукта по запросу ПОКУПАТЕЛЯ |
Инициализация | Инициализируется ПОКУПАТЕЛЕМ |
Действующие субъекты | ПРОДАВЕЦ ПРОДУКТА. ПОКУПАТЕЛЬ. СЛУЖБА СБОРА И РАСПРОСТРАНЕНИЯ. ВЛАДЕЛЕЦ ПРОДУКТА |
Описание примера | Авторизованный ПРОДАВЕЦ ПРОДУКТА деинсталлирует продукт. ПРОДАВЕЦ ПРОДУКТА передает идентификатор продукта и данные деинсталлированного продукта ВЛАДЕЛЬЦУ ПРОДУКТА через СЛУЖБУ СБОРА И РАСПРОСТРАНЕНИЯ |
6.4.6.2 Принудительное прекращение использования продукта
Наименование примера | Принудительное превращение использования продукта |
Схема | Продукт заносится в список безопасности по запросу ВЛАДЕЛЬЦА ПРОДУКТА |
Инициализация | Инициализируется ВЛАДЕЛЬЦЕМ ПРОДУКТА |
Действующие субъекты | ВЛАДЕЛЕЦ ПРОДУКТА. МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ. СЛУЖБА СБОРА И РАСПРОСТРАНЕНИЯ |
Описание примера | ВЛАДЕЛЕЦ ПРОДУКТА прекращает действие продукта и отправляет идентификатор продукта МЕНЕДЖЕРУ СЛУЖБЫ БЕЗОПАСНОСТИ через СЛУЖБУ СБОРА И РАСПРОСТРАНЕНИЯ |
6.4.7 Использование и проверка продукта
Наименование примера | Использование и проверка продукта |
Схема | ПОСТАВЩИК УСЛУГ проверяет и собирает данные об использовании ПОКУПАТЕЛЕМ продукта при пользовании услугами ОТ |
Инициализация | Инициализируется ПОСТАВЩИКОМ УСЛУГ |
Действующие субъекты | ПОСТАВЩИК УСЛУГ. ПОКУПАТЕЛЬ. СЛУЖБА СБОРА И РАСПРОСТРАНЕНИЯ. ВЛАДЕЛЕЦ ПРОДУКТА |
Описание примера | ПОКУПАТЕЛЬ, использующий продукт в ОТ. Вариант использования состоит из следующих процессов, выполняемых ПОСТАВЩИКОМ УСЛУГ. - обнаружение и проверка приложения; - обнаружение, выбор и проверка продукта; - проверка приложения и продукта в соответствии с политикой безопасности; - обработка данных продукта; - установление связи между средой ПОКУПАТЕЛЯ и УДС; - расчет правил продукта; - сбор данных об использовании и инспекции продукта; - пересылка ВЛАДЕЛЬЦУ ПРОДУКТА данных об использовании и инспекции продукта через СЛУЖБУ СБОРА И ПЕРЕСЫЛКИ. |
16
Окончание таблицы
ПНСТ 341—2018
Наименование примерз | Использование и проверка продукта |
Описание примера | Инспекция состоит: - из простого обнаружения; - обнаружения и проверки, или - обнаружения, проверки и дальнейшей обработки |
6.4.8 Сбор данных
Наименование примерз | Сбор данных |
Схема | СЛУЖБА СБОРА И ПЕРЕСЫЛКИ получает данные и проверяет полноту и целостность данных |
Инициализация | Инициализируется следующими субъектами: ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ; ВЛАДЕЛЕЦ ПРОДУКТА; ПРОДАВЕЦ ПРИЛОЖЕНИЯ: ПОСТАВЩИК УСЛУГ; другая СЛУЖБА СБОРА И ПЕРЕСЫЛКИ; МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ: РЕГИСТРАТОР |
Действующие субъекты | ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ. ВЛАДЕЛЕЦ ПРОДУКТА. ПРОДАВЕЦ ПРИЛОЖЕНИЯ. ПОСТАВЩИК УСЛУГ. СЛУЖБА СБОРА И ПЕРЕСЫЛКИ. другая СЛУЖБА СБОРА И ПЕРЕСЫЛКИ. МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ. РЕГИСТРАТОР |
Описание примера | Полученные данные состоят из административных данных и данных транзакций. Действия: - получение шаблона приложения от ВЛАДЕЛЬЦА ПРИЛОЖЕНИЯ; - получение шаблона продукта от ВЛАДЕЛЬЦА ПРОДУКТА; - получение данных от ПРОВАЙДЕРА УСЛУГ; - получение данных от ПРОДАВЦА ПРОДУКТА; - получение данных от ПРОДАВЦА ПРИЛОЖЕНИЯ; - получение данных из других источников; - получение данных списка безопасности от МЕНЕДЖЕРА СЛУЖБЫ БЕЗОПАСНОСТИ; - получение клиринговых отчетов от ВЛАДЕЛЬЦА ПРОДУКТА; - проверка полноты и целостности данных, собранных на техническом уровне, и подтверждение получения отправителем; - получение от РЕГИСТРАТОРА списка адресов всех ИОП-ролей в ИСОП |
17
ПНСТ 341—2018
6.4.9 Пересылка данных
Наименование примера | Пересы л «а данных |
Схема | СЛУЖБА СБОРА И ПЕРЕСЫЛКИ пересылает данные |
Инициализация | Инициализируется СЛУЖБОЙ СБОРА И ПЕРЕСЫЛКИ |
Действующие субъекты | ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ. ВЛАДЕЛЕЦ ПРОДУКТА. ПРОДАВЕЦ ПРИЛОЖЕНИЯ ПОСТАВЩИК УСЛУГ. СЛУЖБА СБОРА И ПЕРЕСЫЛКИ, другая СЛУЖБА СБОРА И ПЕРЕСЫЛКИ. МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ |
Описание примера | Пересылка данных включает следующие действия: - пересылка данных «НЕ НА НАС» на другую СЛУЖБУ СБОРА И ПЕРЕСЫЛКИ; - передача данных «О НАС» ВЛАДЕЛЬЦУ ПРИЛОЖЕНИЯ; - передача данных «О НАС» ВЛАДЕЛЬЦУ ПРОДУКТА для клиринга и отчетности; - препровождение отчетов клиринга, шаблона приложения, шаблона продукта и данных списка безопасности ПРОДАВЦУ ПРОДУКТА и ПОСТАВЩИКУ УСЛУГ; - пересылка шаблонов приложений и данных списка безопасности ПРОДАВЦУ ПРОДУКТА и ПОСТАВЩИКУ УСЛУГ; - пересылка запроса на принудительное завершение МЕНЕДЖЕРУ СЛУЖБЫ БЕЗОПАСНОСТИ |
6.4.10 Формирование и распространение клиринговых отчетов
Наименование примера | Формирование и распространение клиринговых отчетов |
Схема | ВЛАДЕЛЕЦ ПРОДУКТА выполняет процедуру клиринга и распространяет результаты соответствующим ИОП-ролям |
Инициализация | Инициализируется ВЛАДЕЛЬЦЕМ ПРОДУКТА |
Действующие субъекты | ВЛАДЕЛЕЦ ПРОДУКТА. ПРОДАВЕЦ ПРИЛОЖЕНИЯ. ПОСТАВЩИК УСЛУГ СЛУЖБА СБОРА И ПЕРЕСЫЛКИ |
Описание примера | Формирование и распространение клиринговых отчетов состоит из следующих действий: - получение данных об использовании продукта и создание отчетов для продавца продукта и ПОСТАВЩИКА УСЛУГ ВЛАДЕЛЬЦЕМ ПРОДУКТА; - распределение клиринговых отчетов ПРОДАВЦУ ПРОДУКТА через СЛУЖБУ СБОРА И ПЕРЕСЫЛКИ; - распространение клирингового отчета ПОСТАВЩИКУ УСЛУГ через СЛУЖБУ СБОРА И ПЕРЕСЫЛКИ. Распространение отчетов по клирингу также может быть осуществлено путем их прямой передачи ВЛАДЕЛЬЦЕМ ПРОДУКТА |
6.5 Управление безопасностью
Политика безопасности направлена на защиту активов в ИСОП. конфиденциальности клиентов, а также на обеспечение целостности и сохранение данных транзакций.
Соответствие политике безопасности основано на соблюдении комплекса правил безопасности членами ИСОП.
18
ПНСТ 341—2018
За безопасность ИСОП отвечает менеджер службы безопасности.
Функции менеджера службы безопасности выполняет центральный орган ИСОП. Возможно делегирование этих функций другим доверенным организациям.
Менеджер службы безопасности отвечает за выполнение правил политики безопасности всеми участниками ИСОП.
Ответственность за безопасность наступает с самого начала работы субъекта в ИСОП. Когда новый субъект присоединяется к ИСОП. он должен принять и соблюдать правила политики безопасности данной системы.
Управление безопасностью состоит из следующих функций:
- мониторинг процессов;
- управление ключами безопасности;
- управление списками безопасности.
Информация, касающаяся управления безопасностью, приведена в табличной форме.
6.5.1 Мониторинг процессов ИСОП и жизненного цикла данных в системе
Наиисиоазние примера | Мониторинг процессов ИСОП и жизненною цикла данных ИСОП |
Схема | Мониторинг процессов и жизненного цикла данных, таких как генерация, движение, хранение, использование, изменение и удаление, выполняется с целью гарантии безопасной эксплуатации ИСОП. обеспечения доверия клиентов и операторов в отношении обработки и защиты активов и конфиденциальности информации |
Инициализация | Инициализируется МЕНЕДЖЕРОМ СЛУЖБЫ БЕЗОПАСНОСТИ |
Действующие субъекты | Все субъекты, действующие в ИСОП |
Описание примера | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ участвует в сборе информации, касающейся общего уровня безопасности всех организаций, и осуществляет аудит процессов ИСОП и компонентов, из которых генерируются данные до тех пор. пока они не будут удалены. МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ может собирать целевую информацию по всем вариантам использования элементов ИСОП и контролировать как процессы, гак и жизненный цикл данных в этой системе |
6.5.2 Управление ключами безопасности
Наименование примера | Управление ключами безопасности |
Схема | Создание, распространение, хранение и прекращение действия ключей безопасности ИСОП |
Инициализация | Инициализируется МЕНЕДЖЕРОМ СЛУЖБЫ БЕЗОПАСНОСТИ |
Действующие субъекты | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ ОРГАНИЗАЦИИ, использующий ключи безопасности ИСОП |
Описание примера | Управление ключами безопасности включает генерацию, регистрацию, сертификацию. снятие с учета, распространение, установку, хранение, архивирование, отзыв, вывод и уничтожение публичных или секретных материалов в соответствии с политикой безопасности ИСОП. Вариант использования инициируется любой организацией, которая будет получать, устанавливать, хранить и использовать ключи безопасности ИСОП. или МЕНЕДЖЕРОМ СЛУЖБЫ БЕЗОПАСНОСТИ как часть выполнения функций безопасности. Возможность хакерских атак должна быть принята во внимание |
19
ПНСТ 341—2018
6.5.3 Управление списками безопасности
6.5.3.1 Формирование списков безопасности
Наименование примера | Формирование списков безопасности |
Схема | Формирование списков безопасности МЕНЕДЖЕРОМ СЛУЖБЫ БЕЗОПАСНОСТИ |
Инициализация | Инициализируется МЕНЕДЖЕРОМ СЛУЖБЫ БЕЗОПАСНОСТИ |
Действующие субъекты | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ. ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ. ВЛАДЕЛЕЦ ПРОДУКТА. ПРОДАВЕЦ ПРИЛОЖЕНИЯ. ПРОДАВЕЦ ПРОДУКТА. ПОСТАВЩИК УСЛУГ. ПОКУПАТЕЛЬ |
Описание примата | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ формирует и предоставляет новый список безопасности для следующих субъектов: - ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ; - ВЛАДЕЛЕЦ ПРОДУКТА; - РОЗНИЧНЫЙ ТОРГОВЕЦ ПРИМЕНЕНИЯ: - РОЗНИЧНЫЙ ПРОДАВЕЦ ПРОДУКЦИИ; - ОПЕРАТОР УСЛУГ; - РЕГИСТРАТОР. а также {необязательно) пересылает список через СЛУЖБУ СБОРА И ПЕРЕСЫЛКИ |
6.5.3.2 Обновление данных списка безопасности
Наименование примера | Обновление данных списка безопасности |
Схема | Агрегирование данных списка безопасности, касающихся компонентов, носителя клиента, установленных продуктов и приложений |
Инициализация | Инициализируется: МЕНЕДЖЕРОМ СЛУЖБЫ БЕЗОПАСНОСТИ; ОРГАНИЗАЦИЕЙ: ВЛАДЕЛЬЦЕМ ПРИЛОЖЕНИЯ; ВЛАДЕЛЬЦЕМ ПРОДУКТА; ПРОДАВЦОМ ПРИЛОЖЕНИЯ; ПРОДАВЦОМ ПРОДУКТА; ПОСТАВЩИКОМ УСЛУГ; ПОКУПАТЕЛЕМ |
Действующие субъекты | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ. ОРГАНИЗАЦИЯ. ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ. ВЛАДЕЛЕЦ ПРОДУКТА. ПРОДАВЕЦ ПРИЛОЖЕНИЯ. ПРОДАВЕЦ ПРОДУКТА. ПОСТАВЩИК УСЛУГ. ПОКУПАТЕЛЬ |
Описание примера | Пример использования включает действия МЕНЕДЖЕРА СЛУЖБЫ БЕЗОПАСНОСТИ в отношении создания и ведения списков безопасности |
6.5.3.3 Добавление или удаление элементов из списка безопасности
20
ПНСТ 341—2018
Наименование примерз | Добавление или удаление элементов из списка безопасности |
Схема | Добавление или удаление элементов из списка безопасности |
Инициализация | Инициализируется: МЕНЕДЖЕРОМ СЛУЖБЫ БЕЗОПАСНОСТИ: ОРГАНИЗАЦИЕЙ; ВЛАДЕЛЬЦЕМ ПРИЛОЖЕНИЯ; ВЛАДЕЛЬЦЕМ ПРОДУКТА; ПРОДАВЦОМ ПРИЛОЖЕНИЯ: ПРОДАВЦОМ ПРОДУКТА; ПОСТАВЩИКОМ УСЛУГ; ПОКУПАТЕЛЕМ |
Действующие субъекты | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ. ОРГАНИЗАЦИЯ. ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ. ВЛАДЕЛЕЦ ПРОДУКТА. ПРОДАВЕЦ ПРИЛОЖЕНИЯ. ПРОДАВЕЦ ПРОДУКТА. ПОСТАВЩИК УСЛУГ. ПОКУПАТЕЛЬ |
Описание примера | Любая организация гложет запросить добавление или удаление компонента из списка безопасности, например: информацию о выведенном из эксплуатации автомате по выдаче карт или билетном автомате |
6.5.3.4 Добавление или удаление шаблона приложения из списка безопасности
Наименование примера | Добавление или удаление шаблона приложения из списка безопасности |
Схема | Добавление или удаление шаблона приложения из списка безопасности |
Инициализация | Инициализируется МЕНЕДЖЕРОМ СЛУЖБЫ БЕЗОПАСНОСТИ |
Действующие субьекты | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ |
Описание примера | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ запрашивает добавление/удаление шаблона приложения е/из списка безопасности. Примечание — В случае попадания шаблона приложения в список запрета МЕНЕДЖЕР ИСОП получит от МЕНЕДЖЕРА СЛУЖБЫ БЕЗОПАСНОСТИ подтверждение прекращения действия шаблона приложения |
6.5.3.5 Добавление или удаление приложения из списка безопасности
Наименование примерз | Добавление или удаление приложения из списка безопасности |
Схема | Добавление или удаление приложения из списка безопасности |
Инициализация | Инициализируется МЕНЕДЖЕРОМ СЛУЖБЫ БЕЗОПАСНОСТИ |
Действующие субьекты | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ |
Описание примера | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ запрашивает добавление/удаленив приложения в/из списка безопасности. Примечание — В случае попадания в список запрещенных приложений ВЛАДЕЛЕЦ ПРИЛОЖЕНИЯ позднее получит через СЛУЖБУ СБОРА И ПЕРЕСЫЛКИ подтверждение о завершении от ПРОДАВЦА ПРИЛОЖЕНИЯ |
6.5.3.6 Добавление или удаление шаблона продукта из списка безопасности
21
ПНСТ 341—2018
Наименование примера | Добавление или удаление шаблона продукта из списка безопасности |
Схема | Добавление или удаление шаблона продукта из списка безопасности |
Инициализация | Инициализируется МЕНЕДЖЕРОМ СЛУЖБЫ БЕЗОПАСНОСТИ |
Действующие субъекты | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ |
Описание примера | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ запрашивает добавление,'удаление шаблона продукта в/из списка безопасности. Примечание — В случае попадания в список запрещенных продуктов ВЛАДЕЛЕЦ ПРОДУКТА получит через СЛУЖБУ СБОРА И ПЕРЕСЫЛКИ подтверждение о завершении |
6.5.3.7 Добавление или удаление продукта из списка безопасности
Наименование примера | Добавление или удаление продукта из списка безопасности |
Схема | Добавление или удаление продукта из списка безопасности |
Инициализация | Инициализируется МЕНЕДЖЕРОМ СЛУЖБЫ БЕЗОПАСНОСТИ |
Действующие субъекты | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ |
Описание примера | МЕНЕДЖЕР СЛУЖБЫ БЕЗОПАСНОСТИ запрашивает добавление,'удаление продукта в/из списка безопасности. Примечание — В случае попадания в список запрещенных продуктов ВЛАДЕЛЕЦ ПРОДУКТА или ПРОДАВЕЦ получит через СЛУЖБУ СБОРА И ПЕРЕСЫЛКИ подтверждение о завершении |
6.6 Управление обслуживанием клиента (опционное)
Информация относительно управления обслуживания клиента (опционного) изложена в табличной форме.
Наименование примера | Управление обслуживанием клиента |
Схема | Управление обслуживанием клиента включает справочную службу и другие опции |
Инициализация | Инициализируется ПОКУПАТЕЛЕМ |
Действующие субъекты | ПОКУПАТЕЛЬ. СЕРВИСНАЯ СЛУЖБА. СЛУЖБА СБОРА и РАСПРОСТРАНЕНИЯ |
Описание примера | СЕРВИСНАЯ СЛУЖБА получает запрос от клиента и перенаправляет запрос соответствующим ролям ИСОП через СЛУЖБУ СБОРА и РАСПРОСТРАНЕНИЯ для получения ответа. СЕРВИСНАЯ СЛУЖБА отвечает на запрос |
7 Идентификация системного интерфейса
Все интерфейсы, описанные в приложении А. за исключением интерфейсов с приложением покупателя, будут указаны в дополнительных стандартах.
Интерфейсы с приложением покупателя не входят в сферу действия настоящего стандарта.
22
ПНСТ 341—2018
8 Идентификация
8.1 Общие положения
Под идентификацией понимается набор атрибутов, описывающих конкретное лицо или объект уникальным и однозначным образом, индивидуум может быть описан, например, по имени, дате рождения. полу, адресу и т. д.
Однозначно идентифицировать объект, например билетный автомат, можно по данным владельца, типу и серийному номеру.
Идентификация является важным моментом в ИСОП по следующим основным причинам:
- безопасность — идентификация ИОП-роли. объектов, приложений, продуктов и т. д., которая включает применение списков безопасности, например для учета украденных компонентов. Идентификация может быть также использована в процедуре аутентификации путем включения уникального идентификатора;
- связь — в сети ИСОП большое количество лиц. таких как организации, компании и компоненты, которые будут выступать в качестве отправителя и/или получателя информации. Уникальная идентификация использована для представления различных субъектов в сети;
- аудит — существует категорическое требование о возможности аудита любой транзакции и любой части информации в ИСОП. например: после использования транзакции от момента ее создания поставщиком услуг до тех лор. пока она не будет удалена или модифицирована владельцем продукта. В случае возникновения непредвиденных обстоятельств или при изменении любой информации в течение жизненного цикла должна быть возможность для выяснения причин того, что именно случилось и где именно в ИСОП это произошло.
8.2 Схема идентификации
Как минимум, следующие объекты должны иметь уникальный идентификатор в ИСОП:
- субъекты (организации), участвующие в ИСОП, например все владельцы продуктов и приложений. продавцы, поставщики услуг.
- шаблоны приложений;
- приложения (реализованные и инициализированные шаблоны приложений);
- шаблоны продуктов;
- продукты (экземпляры шаблонов продуктов);
- компоненты.
8.3 Предпосылки
Необходимые предпосылки для идентификации должны быть следующие:
- в ИСОП имеется один РЕГИСТРАТОР;
- любой объект, например шаблоны и компоненты, имеет владельца, который будет одним из участников в ИСОП:
- идентификация приложения и продукта должна быть как можно более короткой и компактной благодаря минимизации времени транзакции между средой клиента и УДС.
9 Безопасность в интероперабельной системе оплаты проезда
Интероперабельная система оплаты проезда является объектом мошенничества со стороны клиентов, операторов, а также других лиц. не входящих в нее.
Политика в отношении безопасности в ИСОП должна обеспечивать защиту как общественных интересов, так и активов системы.
9.1 Защита интересов общественности
Общественные интересы основаны не только на количественных финансовых аспектах, но и на гуманитарных/культурных аспектах. Далее изложены некоторые общие принципы соблюдения общественных интересов:
- качество обслуживания в ИСОП должно иметь соответствующий уровень сервиса как инструмент достижения стратегических целей транспортного обслуживания;
23
ПНСТ 341—2018
- справедливость оплаты — клиенты должны быть уверены в том. что каждый платит сумму, соответствующую действующим тарифным принципам;
- общественное доверие — клиенты должны быть уверены в том. что они платят справедливую сумму за предоставляемую услугу;
- общественная мораль — преднамеренный саботаж и мошенничество должны пресекаться и считаться незаконными. Это связано с принципами справедливости и общественного доверия;
- конфиденциальность — информация, генерируемая в ИСОП. должна быть защищена в соответствии с требованиями действующего законодательства.
Эти принципы носят общий характер и не конкретизированы в настоящем стандарте, но тем не менее должны быть учтены и соблюдены в каждой организации, ответственной за функционирование и эксплуатацию транспорта.
Что касается конфиденциальности, то. согласно международным и европейским правилам, на сбор, хранение, обработку и распространение данных, касающихся отдельных лиц и их поведения, налагают некоторые ограничения. По этой причине ИСОП должна защищать конфиденциальность пользователей. В связи с чем необходимо, по крайней мере, применять следующие правила.
- у клиента запрашиваются только соответствующие персональные данные, необходимые для работы ИСОП;
- детализированное раскрытие потребления услуг в счете-фактуре должно быть вариантом, который может быть выбран со стороны клиента;
- субъект ИСОП не может раскрывать информацию, связанную с клиентами, третьим лицам без конкретных указаний клиента;
- в рамках системы ИСОП клиентские данные должны обрабатываться только в соответствии с идентификационным номером договора (явного или неявного), заключенного между клиентом и владельцем продукта. Взаимосвязь между номером договора и именем клиента может быть установлена только путем договорных отношений по желанию заказчика.
9.2 Активы, подлежащие защите
Архитектура безопасности для ИСОП должна защищать активы. Активы могут быть классифицированы следующим образом:
- физические средства — компьютеры, серверы, системы коммуникаций, носители информации, средства массовой информации клиента, билетные автоматы, валидаторы и др.;
- программные активы — все программное обеспечение в ИСОП. включая программное обеспечение на носителе клиента;
- информационные активы — информация, содержащаяся в базах данных, среде клиента, в билетных автоматах, валидаторах;
- документация системы, руководства потребителя, процедуры при осуществлении деятельности. планы и т. д.
Информационные активы можно разделить на следующие категории:
- общедоступная информация, т. е. любая информация о ИСОП, находящаяся в открытом доступе;
- частная информация, т. е. информация, подлежащая защите данных в соответствии с действующим законодательством и правилами конфиденциальности;
- коммерческая информация, например информация, связанная с функционированием системы, коммерческие правила, клиринг, распределение и финансовые операции:
- конфиденциальная информация, например информация, связанная с процедурами безопасности и персональными данными;
- конфиденциальная информация, например ключи безопасности.
9.3 Общие требования безопасности в интероперабельной системе оплаты проезда
Интероперабельная система оплаты проезда должна удовлетворять следующим общим требованиям безопасности;
а) гарантировать, что информация не будет доступна или раскрыта неавторизованным физическим лицам, организациям или процессам (конфиденциальность):
б) гарантировать, что информация не изменена или уничтожена несанкционированным образом (целостность информации);
24
ПНСТ 341—2018
в) идентичность объекта или ресурса должна соответствовать заявленной (аутентичность) — аутентичность применяется к таким объектам, как пользователи, процессы, системы и информация;
г) обеспечивать защиту от ложного отрицания субъектом сообщения (отказ от создания), например: клиент, утверждающий, что он не воспользовался транспортным обслуживанием в определенном месте и в определенное время;
д) гарантировать защиту от ложного отказа получателя в получении сообщения и распознавании содержания сообщения (неотрицание доставки);
е) обеспечивать уникальность каждого сообщения, например транзакции, описывающей использование продукта;
ж) обеспечивать управление ключами безопасности, включая генерацию, регистрацию, сертификацию. снятие с учета, распространение, установку, хранение, архивирование, аннулирование, получение и уничтожение секретного материала ключей, в соответствии с общей политикой безопасности в ИСОП;
и) управлять списками безопасности, включая, но не ограничиваясь добавлением или удалением:
- компонентов из списка безопасности,
- носителя (среды) клиента в/из списка безопасности.
- продукта из списка безопасности, и
- установленной программы из списка безопасности.
25
ПНСТ 341—2018
Приложение А (справочное)
Поток информации в интероперабельной системе оплаты проезда
А.1 Общие положения
В настоящем приложении описан информационный поток в ИСОП.
Интерфейс ИОП-ропей ИСОП с менеджером службы безопасности и регистратором функции ИСОП описан в разделе А.2.
Сертификация и регистрация, интерфейсы между ИОП-ролями внутри интерфейсов ИОП-ролей ИСОП описаны в А.З—А.7.
А.2 Интерфейс ролей интероперабельной системы оплаты проезда с менеджером службы безопасности и регистратором
Управление безопасностью включает в себя сертификацию и аудит ИСОП и управление списками безопасности.
В контексте сертификации и аудита интерфейсы между ИОП-ролями и безопасностью находятся на организационной базе. Эти процессы указаны в 6.1.
В контексте управления списками безопасности интерфейсы представлены на рисунке А.1 ив таблице А.1.
![](pnst_341-2019/pnst_341-2019_5.jpg)
Рисунок А.1 — Интерфейсы между менеджером службы безопасности и ИОП-ролями
Таблица А.1 — Интерфейсы между менеджером службы безопасности и ИОП-ролями
Интерфейс | Накииооаиие примерз | Информация |
1а | Принудительное завершение приложения | Идентификатор приложения |
16 | Принудительное завершение шаблона приложения' приложения | Информация 36 и/или 66 |
2а | Принудительное завершение продукта | Идентификатор продукта |
26 | Принудительное завершение шаблона продукта/ продукта | Информация 36 и/ипи 66 |
За | — | Информация 8а |
26
Окончание таблицы А. 1
ПНСТ 341—2018
Интерфейс | Наименование примера | Информация |
36 | Принудительное завершение шаблона приложения | Идентификатор шаблона приложения и данные завершения шаблона приложения |
Принудительное завершение приложения | Идентификатор приложения и данные завершения приложения | |
Принудительное завершение шаблона продукта | Идентификатор шаблона продукта и данные завершения шаблона продукта | |
Принудительное завершение продукта | Идентификатор продукта и данные завершения продукта | |
6а | — | Информация 8а |
66 | Принудительное завершение шаблона приложения | Идентификатор шаблона приложения и данные завершения шаблона приложения |
Принудительное завершение приложения | Идентификатор приложения и данные завершения приложения | |
Принудительное завершение шаблона продукта | Идентификатор шаблона продукта и данные завершения шаблона продукта | |
Принудительное завершение продукта | Идентификатор продукта и данные завершения продукта | |
7 | — | Информация 1а. 2а. 36. 66. 8а (передача данных «НА НАС» и «НЕ НА НАС» — СБОР и ПЕРЕДАЧА) |
8а | Создание списков безопасности | Список безопасности |
86 | Принудительное завершение шаблона приложения | Информация 36 и’или 66 |
Принудительное завершение приложения | Информация 1а | |
Принудительное завершение шаблона продукта | Информация 36 и’или 66 | |
Принудительное завершение продукта | Информация 2а |
В контексте регистрации все организации, выполняющие одну или несколько функций ИОП-ролей. и компоненты в ИСОП получают уникальный идентификатор. Эти процессы определены в 6.2.1 и 6.2.2. Также информационный поток, связанный с приложением и продуктом, получит уникальный идентификатор.
Обмен данными между владельцем приложения’продукта и регистратором может быть осуществлен различными способами в зависимости от организационной и технической структуры ИСОП. для того чтобы обеспечить в оперативном режиме автономный процесс регистрации. Взаимодействие с регистратором может происходить через службу сбора и пересыпки или напрямую между ролью ИСОП и регистратором.
Интерфейсы для типовых процедур регистрации представлены на рисунке А.2 и в таблице А.2.
Таблица А.2 — Интерфейсы для регистрации шаблонов
Наименование примера | Передаваемая информация | Последовательность |
Регистрация шаблона приложения | Запрос владельца приложения регистратору: сертификат шаблона приложения Возврат от регистратора: идентификатор шаблона приложения | 1 2 |
Регистрация шаблона продукта | Запрос владельца продукта регистратору: сертификат шаблона продукта Возврат от регистратора: идентификатор шаблона приложения | 1 2 |
27
ПНСТ 341—2018
![](pnst_341-2019/pnst_341-2019_6.jpg)
Рисунок А.2 — Интерфейсы между регистратором и владельцем приложения и владельцем продукта для регистрации заявок и продуктов
Интерфейсы для процессов подачи заявок и регистрации продуктов представлены на рисунке А.2 и в таблице А.З.
Т а б л я ц а А.З — Интерфейсы для регистрации заявки и регистрации продукта
Интерфейс | Наименование примера | Передаваемая информация | Последовательность |
1а | — | Идентификатор приложения | 3 |
16 | — | 36 Информация | 2 |
2а | — | Идентификатор продукта | 3 |
26 | — | 36 Информация | 2 |
За | — | 1а и 2а Информация | 4 |
36 | 36 Регистрация приложения: Регистрация продукта: | Идентификатор шаблона приложения. Идентификатор шаблона продукта | 1 |
— | Отправить регистратору: - идентификатор шаблона приложения. Возврат от регистратора: - идентификатор приложения | — | |
— | Отправить регистратору: - идентификатор шаблона продукта. Возврат от регистратора: - идентификатор продукта | — |
А.З Интерфейс между ролями интероперабельной системы оплаты проезда
На рисунке А.З представлен интерфейс между ИОП-ролями в ИСОП при работе с сертифицированными и зарегистрированными шаблонами приложений, приложениями, шаблонами продуктов и продуктами. Интерфейсы при обмене информацией с менеджером службы безопасности и регистратором в настоящем стандарте не рассматриваются.
28
ПНСТ 341—2018
![](pnst_341-2019/pnst_341-2019_7.jpg)
Рисунок А.З — Интерфейс между ИОП-ролями в ИСОП при работе с сертифицированными и зарегистрированными шаблонами приложений, приложениями, шаблонами продуктов и продуктами
Каждая ИОП-ропь должна быть связана только с одной службой сбора и пересылки. Несколько служб сбора и пересылки могут сосуществовать в одной ИСОП.
А.4 Интерфейсы между ИОП-ролями для управления шаблонами приложений
На рисунках А.4. А.5. а также в таблицах А.4. А.5 представлены интерфейсы между ИОП-ролями. включая владельца приложения, продавца приложения и сервисную службу.
![](pnst_341-2019/pnst_341-2019_8.png)
Рисунок А.4 — Интерфейсы между ИОП-ролями для управления шаблонами приложений
29
ПНСТ 341—2018
![](pnst_341-2019/pnst_341-2019_9.png)
Рисунок А.5 — Управление шаблонами приложений с данными «НЕ НАНАСо
Таблица А.4 — Управление шаблонами приложений
Интерфейс | Наименование примера | Лоток информации | Последовательность о соответствии с рисунком 4 | Последовательность а соответствии с рисунком 5 |
1а | Распространение шаблона приложения Нормальное завершение шаблона приложения | Шаблон приложения. Запрос на завершение шаблона приложения | 1 | 1 |
За | — | Информация 1а | 2 | 3 |
ба | — | Информация 1а | 2 | 3 |
7 | — | Информация 1а (передача данных «НЕ НА НАС» «НА НАС») | — | 2 |
А.5 Интерфейс между ИОП-ролями при управлении приложением
На рисунке А.6 изображен интерфейс между службой сбора и продвижения и другими ИОП-ролями при управлении приложением.
![](pnst_341-2019/pnst_341-2019_10.jpg)
Рисунок А.6 — Интерфейс между ИОП-ролями при управлении приложением
30
ПНСТ 341—2018
В таблице А.6 дано подробное описание потока информации при взаимодействии между службой сбора и продвижения и другими ИОП-ролями при управлении приложением в различных ситуациях.
Таблица А.5 — Интерфейсы между ИОП-ролями для управления приложениями
Интерфейс | Наименование примера | Поток информации | Последователь* масть (рисунок А.6} | Последовательность (рисунок А.7) |
16 | — | Информация 36 | 4 | 5 |
36 | — | Идентификатор приложения и информация 46 | 3 | 3 |
4а | Получение приложения. Нормальноезавершение приложения | Шаблон приложения и идентификатор приложения. Инструкция завершения | 2 | 2 |
46 | Получение приложения. Нормальное завершение приложения | Идентификатор среды. Данные получения приложения. Идентификатор Приложения. Данные о завершении приложения | 1 | 1 |
7 | — | Информация 1а (передача данных «НЕ НА НАС». «НА НАС») | — | 4 |
![](pnst_341-2019/pnst_341-2019_11.jpg)
Рисунок А.7— Интерфейс между ИОП-ролями при управлении приложением сданными «НЕ НА НАС»
А.6 Интерфейсы между ИОП-ролями при управлении шаблоном продукта
На рисунке А.8 изображен интерфейс между службой сбора и продвижения и другими ИОП-ролями при управлении шаблоном продукта
31
ПНСТ 341—2018
![](pnst_341-2019/pnst_341-2019_12.jpg)
Рисунок А.8 — Управление шаблонами продуктов
В таблице А.6 подробно описаны потоки информации интерфейса между службой сбора и распространения и другими ИОП-ролями при распространении шаблона продукта.
Таблица А.6 — Управление шаблонами продуктов
Интерфейс | Наименование примера | Поток информации | Последовательность (рисунок А.81 | Последовательность (рисунок Л.б| |
2а | Распространение шаблона продукта | Шаблон продукта. Запрос на завершение шаблона приложения | 1 | 1 |
За | — | 2а информация | 2 | 3 |
ба | — | 2а информация | 2 | 3 |
7 | — | 2а информация (передача данных «НЕ НА НАС» по сбору данных в службу сбора и пересылки) | — | 2 |
На рисунке А.9 показано взаимодействие служб сбора и продвижения и других ИОП-ролей при управлении шаблоном продукта с данными «НЕ НА НАС».
![](pnst_341-2019/pnst_341-2019_13.jpg)
Рисунок А.9 — Управление шаблоном продукта с данными «НЕ НА НАС»
32
ПНСТ 341—2018
А.7 Интерфейсы между ИОП-ролями при управлении продуктом
Примечание — По определению продукт гложет быть договором (т. е. оплата продукта), а также продуктом в классическом понимании (билет).
Для наглядности интерфейсы для управления продуктом разделены на два основных случая:
а) приобретение’изменение/прекращение действия продукта;
б) использование продукта и распространение клиринговых отчетов.
А.7.1 Приобретение/изменение/прекращение действия продукта
На рисунке А. 10 отображен интерфейс при взаимодействии службы сбора и продвижения с владельцем продукта и продавцом продукта на различных стадиях жизненного цикла продукта.
![](pnst_341-2019/pnst_341-2019_14.jpg)
Рисунок А.10 — Интерфейсы приобретения/изменения/прекращения действия продукта
На рисунке А. 11 отображен интерфейс при взаимодействии служб сбора и продвижения с владельцем продукта и продавцом продукта на различных стадиях жизненного цикла продукта с данными «НЕ НА НАС».
![](pnst_341-2019/pnst_341-2019_15.jpg)
Рисунок А.11 — Интерфейсы для приобретения/модификации?прекращения продукта с данными «НЕ НА НАС»
Примечание — Согласно данным, приведенным в таблице А.7. идентификаторы продуктов не содержат информацию о продавце и владельце продукта. Если эти идентификаторы содержат эту информацию, то существует необходимость предоставлять идентификатор продавца и владельца продукта отдельно.
33
ПНСТ 341—2018
Таблица А.7 — Управление шаблонами продуктов
Интерфейс | Наименование примера | Поют информации | Последовательность (рисунок А 12) | Последовательность I рисунок А 13) |
36 | — | Идентификатор продукта и информация 46 | 3 | 3 |
4а | Получение продукта. Изменение параметров продукта. Нормальное завершение продукта | Шаблон и идентификатор продукта. Параметры продукта. Инструкция завершения продукта | 2 | 2 |
46 | Получение продукта (не обязательно). Изменение параметров продукта. Нормальное завершение продукта | Данные полученного продукта | 2 | 3 |
7 | — | Информация 36 (передача данных «НЕ НА НАС» на «НА НАС» службой сбора и продвижения) | — | 4 |
А.7.2 Использование продукта и распространение клиринговых отчетов
На рисунке А. 12 отображен интерфейс между службой сбора и продвижения и другими ИОП-ролями при использовании продукта и распространении клиринговых отчетов.
![](pnst_341-2019/pnst_341-2019_16.jpg)
Рисунок А. 12 — Интерфейсы для использования продукта и распространения клиринговых отчетов
34
ПНСТ 341—2018
![](pnst_341-2019/pnst_341-2019_17.jpg)
Рисунок А. 13 — Интерфейсы для использования продукта и распространения клиринговых отчетов данных «НЕ НА НАС»
В таблице А-8 описаны интерфейсы, реализуемые в процессе использования продукта и распространения клиринговых отчетов.
Таблица А.8 — Интерфейсы для использования продукта и распространения клиринговых отчетов
Интерфейс | Наименование примера | Поют информации | Последовательность (рисунок А.12) | Последователь ность (рисунок Л.131 |
2а | Формирование и распространение клиринговых отчетов | Клиринговый отчет | 5 | 6 |
26 | Распространение данных | Информация 66 | 4 | 5 |
За | Распространение данных | Информация 2а | 6 | 7 |
5а | Использование и проверка продукта | Идентификатор приложения. Данные продукта (идентификаторы продавца и владельца продукта, правила использования и т. д.). | 1 | 1 |
56 | Использование и проверка продукта | Данные использования (Проверка продукта) | 2 | 2 |
6а | Распространение данных | Информация 2а | 6 | 7 |
66 | Сбор данных | Идентификатор приложения, идентификатор продукта, идентификатор продавца, данные 56. данные проверки | 3 | 3 |
7 | — | Информация 66 (передача данных «НЕ НА НАС», данных «НА НАС» службой сбора и распространения) | — | 4 |
35
ПНСТ 341—2018
Приложение Б (справочное)
Пример процессов в списке действий
Б.1 Интерпретация списка действий
В дополнение к определению списка действий (2.1) в качестве примера приведена следующая возможная интерпретация. Список действий представляет собой список элементов, относящихся к медиафайлам ИСОП. приложениям или продуктам, загруженным в УДС. которые должны быть выполнены УДС. если и когда указанное приложение УДС или продукт, показанный в списке, упоминается тем же самым УДС.
Действия выполняются УДС без взаимодействия с пользователем. Список действий формируется из директив списка действий.
Б.1.1 Директивы списка действий формируются:
а) одним из действующих лиц во время взаимодействия с клиентом, но без контакта с картой (например, через вызов колл-центр, веб-сайт, обработку полученной почты);
б) в операционно-учетном подразделении действующим лицом на основе внутренней информации.
Б.1.2 Целью списка действий является:
а) обслуживание клиента по тем каналам, в которых он не может физически представить свою среду;
б) осуществление определенных мер в приложениях и/или продуктах, не вынуждая клиентов посещать пункт обслуживания.
Б.1.3 Разъяснение сферы применения
Процесс автоматического пополнения средств или модификация продукта, вызванные свойствами самого продукта, не входят в список действий.
Б.1.4 Сведения о процессе
С помощью списка действий можно разделить транзакции на две части: первая часть — заказ и оплата; вторая — доставка. Это связано с тем. что две части разделены в пространстве и времени и могут включать в себя разных действующих лиц.
Объектом действия может быть среда, приложение на среде или продукт в приложении.
Б.1.5 Содержание
Элементы в списке действий могут:
а) быть добавлены к продукту;
б) изменить продукт, например:
- добавить'вьгчесть значение в/из сохраненного значения продукта.
- изменить параметры пополнения для сохраненного значения продукта.
- разблокировать продукт;
в) завершить продукт (в процедуре возврата средств);
г) добавить приложение;
д) изменить приложение (например, добавить или изменить профиль держателя);
е) завершить приложение.
Единственный случай, когда объектом действия является среда. — это тот случай, когда действие добавляет приложение.
Б.2 Сравнение списков действий и списков безопасности
Так как списки действий и списки безопасности используют одни и те же механизмы распределения, список перспективных данных в области безопасности является подмножеством списка действий. Это отличается от мнения представителей бизнеса, которые считают, что список действий касается планируемых действий, а в списке безопасности содержится мгновенная реакция на инциденты безопасности.
Б.З Примеры информации, которая должна быть передана в списках действий
Список действий включает следующее:
- уникальный идентификатор среды, приложения или продукта;
- уникальный идентификатор действия;
- тип действия, которое необходимо предпринять (добавление продукта, добавление сохраненной ценности в продукт и т. д.);
- любой параметр, связанный с этим действием (например, количество, если действие заключается в добавлении сохраненного значения в продукт).
Действия могут быть следующими:
а) добавить продукт:
- добавление нового продукта (приложение, идентификатор продукта, параметры продукта).
36
ПНСТ 341—2018
- обновление продукта (старый идентификатор продукта, новый идентификатор продукта, параметры продукта):
б) изменить продукт:
- добавление сохраненного значения (идентификатор продукта, значение).
- вычисление сохраненного значения (идентификатор продукта, значение),
- удаление сохраненного значения (идентификатор продукта).
- инициализация параметров пополнения сохраненных прав на проезд (идентификатор продукта, параметры продукта).
- изменение параметров пополнения прав на проезд (идентификатор продукта, параметры продукта).
- остановка пополнения прав на проезд (идентификатор продукта).
- разблокировка заблокированного продукта (идентификатор продукта);
в) завершить продукт (идентификатор продукта);
г)изменить приложение:
- добавление профиля держателя (приложение, параметры).
- завершение профиля держателя (приложение, параметры).
- изменение настроек пользователя (приложение, параметры, такие как класс).
Кроме того, директива списка действий может содержать такие данные, как:
- один или несколько идентификаторов для выбора УДС. которые будут выполнять действие;
- оператор(ы) обслуживания;
- место(а):
- зона(ы);
- транспортный(ые) режим(ы);
- линию(ии);
- период, в течение которого действие должно быть принято;
- тип директивы — новое действие или аннулирование предыдущего действия;
- идентификация предыдущего действия (в случае аннулирования).
Б.4 Описание примеров использования
В приведенных примерах использования представлен набор инструментов для реализации списков дей-ствий в ИСОП. В данных примерах изложены варианты использования списков действий, в которых подробно описано управление предложенными вариантами и перечень, который не является исчерпывающим.
В этом описании использован термин «администратор списка действий» для сущности(ей). ответственной(ых) за администрирование. Администрирование списка действий подразумевает выполнение функции агрегирования действий в один список, однозначной идентификации каждого действия и контроля действий в течение их жизненного цикла.
Администрирование списка действий как функция гложет быть частью функций продавца продукта или приложения. владельца продукции или приложения, службы сбора и пересылки.
37
ПНСТ 341—2018
Приложение В (справочное)
Область безопасности, угрозы и профили защиты
В.1 Область безопасности
Для защиты активов владельцы ИСОП должны понимать, что представляют собой угрозы, как именно реагировать на них и какие меры и механизмы должны быть реализованы при этом.
Банки и финансовые учреждения находятся за пределами области безопасности, так как считаются доверенными лицами. Регистратор также находится за пределами области безопасности, потому что он считается заслуживающим доверия, а информация, управляемая секретарем, не требует конфиденциальности. Другие ИСОП недоступны в связи с тем, что владелец одной ИСОП не имеет никакого влияния или контроля над другими системами. Клиент также является внешним, так как контроль поведения клиента из области безопасности не возможен.
В.2 Угрозы
Основная цель анализа угроз и уязвимости заключается в том, чтобы минимизировать риски, связанные с внедрением и управлением ИСОП. Анализ угроз и уязвимостей включает общую оценку наиболее вероятных угроз и уязвимость системы по отношению к этим угрозам.
Анализ угроз включает выявление возможных хакеров, целей угроз и оценку уязвимости целей к применяемым хакерским методам для доступа, изменения, использования, копирования и'или извлечения активов.
Хакеров можно классифицировать следующим образом:
- класс 1 — умные (посторонние лица).
Эти лица могут быть квалифицированными и иметь соответствующие инструменты для проведения хакерских атак, но недостаточно осведомленными о системе и ее недостатках для достижения своих целей;
- класс 2 — знающие (посторонние лица).
Данная группа лиц потенциально имеет доступ ко всей системе, обладает специальным техническим образованием и опытом работы со специализированными инструментами, предназначенными для хакерских атак;
- класс 3 — финансируемые организации.
Группы посторонних организаций, тлеющие достаточное финансирование, обладающие специалистами, возможно, использующие хакеров класса 2 с набором самых современных инструментов для осуществления хакерских атак;
- класс 4 — инсайдер.
В этой группе лица, имеющие доступ к конфиденциальной информации, процессам и модулям, которые могут быть использованы ими или другими посторонними лицами.
Классификация хакеров (от 1-го до 4-го классов) приведена для того, чтобы показать, что чем выше класс, тем выше вероятность атак и тяжесть их последствий. С другой стороны, чем выше класс, тем меньше количество людей, которые могли бы осуществить хакерскую атаку, и наоборот. Это можно использовать позже для того, чтобы оценить вероятность осуществления фактической атаки.
В.З Профили защиты
Угрозы безопасности должны предупреждаться различными мерами безопасности, включая спецификации требований безопасности.
Под ПЗ понимается набор требований безопасности для категории продуктов или систем, которые отвечают конкретным потребностям. Типичным примером может служить ПЗ для среды клиента, которая будет использована в ИСОП. и в этом случае ПЗ будет независимым от реализации набором требований безопасное™ для среды клиента, удовлетворяющим потребности операторов и пользователей в безопасности.
Основная цель ПЗ состоит в том. чтобы определить требования к безопасности, связанные с угрозами, выявленными в результате анализа среды безопасности. Изучаемый предмет называется ЦО.
Содержание ПЗ организовано следующим образом:
а)введение;
б) ЦО — область применения ЦО. например валидатор, должна быть указана;
в) безопасная окружающая среда — определение методов разработки, функционирования и управления ЦО для уточнения рабочих/зкеплуатационных требований. В отношении этих требований должны быть указаны ИТ-активы, которые ЦО должна защищать, и угрозы безопасности, которым подвергается ЦО;
г) цели безопасности (ЦБ) — определение политики безопасности от угроз. ЦБ подразделены на технические политики и политику оперативного управления и должны соответствовать оперативным целям продукта. Политика операционного управления определена в качестве персональных и физических целей в статусе, в котором используется ЦО. Политика операционного управления включает в себя правила по управлению и эксплуатации для операторов;
38
ПНСТ 341—2018
д) требования безопасности — в соответствии с ЦБ конкретные требования безопасности для предотвращения угроз безопасности, указанных в перечислении в), состоят из функциональных требований (технических требований} и требований к обеспечению качества безопасности;
е) разумное обоснование/эффективность — содержание ПЗ проверяют при необходимости на соответствие требованиям безопасности для ЦО.
Проверенные элементы отображены следующим образом:
- удовлетворение всех необходимых условий безопасности;
- соответствие целям и условиям безопасности;
- обеспечение требований безопасности в соответствии с ЦБ.
39
ПНСТ 341—2018
Библиография
[1] ISO.TS 14904
Транспорт дорожный и интегрированные средства обработки и передачи данных о движении — Электронный сбор платежей (EFC) — Спецификация интерфейса для расчетов между операторами
(2] ИСО/МЭК 15408 (все части) Информационная технология — Методы и средства обеспечения безопасности — Критерии оценки безопасности информационной технологии
[3] ISO/IEC7TR 15446 Информационная технология — Методы и средства обеспечения безопасно
сти — Руководство по разработке профилей защиты и заданий по безопасности
40
ПНСТ 341—2018
УДК 656.035.21:006.354
ОКС 03.220.20
Ключевые слова: интероперабельные системы оплаты проезда, пассажирские транспортные средства. общественный транспорт, валидатор, электронный билет
41
БЗ 2—2019/31
Редактор Л.С. Зиминова Технический редактор В.Н. Прусакова Корректор О.В. Лазарева Компьютерная верстка Е.А. Кондрашовой
Сдано в набор 05.02.2019 Подписано в печать 08.02.2019. Формат 60’84%. Гарнитура Ариал.
Усл. печ. п. 5,12. Уч. изд. п. 4.40.
Подготовлено на основе электронной версии, предоставленной разработчиком стандарта
Создано в единичном исполнении ФГУП «СТАНДАРТИИФОРМи дпя комплектования Федерального информационного фонда стандартов.
117418 Москва. Нахимовский пр-т. д. 31. к. 2 w w* goslinfo.ru info@gos1info.ru