ГОСТ Р ИСО/МЭК 19941-2021. Национальный стандарт Российской Федерации. Информационные технологии. Облачные вычисления. Интероперабельность и переносимость

5.2 Модели аспектов облачной интероперабельности и облачной переносимости

5.2.1 Модель аспектов облачной интероперабельности

5.2.1.1 Общие положения

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

Модель аспектов интероперабельности, приведенная в настоящем стандарте, определяет пять аспектов в контексте облачной интероперабельности. Эти аспекты приведены на рисунке 4: транспорт, синтаксис и семантика данных, поведение и политика. Данная модель получена путем объединения и абстрагирования европейской модели интероперабельности [13] и уровней концептуальной модели интероперабельности (LCIM) [14].

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

Модель аспектов интероперабельности, приведенная в настоящем стандарте, определяет пять аспектов в контексте облачной интероперабельности. Эти аспекты приведены на рисунке 4: транспорт, синтаксис и семантика данных, поведение и политика. Данная модель получена путем объединения и абстрагирования европейской модели интероперабельности [13] и уровней концептуальной модели интероперабельности (LCIM) [14].

 

 

Рисунок 4 - Аспекты облачной интероперабельности

 

5.2.1.2 Интероперабельность на уровне транспорта

Интероперабельность на уровне транспорта означает общность инфраструктуры связи, созданной для обмена данными между системами. В контексте облачных вычислений интероперабельность на уровне транспорта - это механизм передачи данных между различными компонентами облачных вычислений, либо между компонентами потребителя службы облачных вычислений и компонентами поставщика службы облачных вычислений, либо между компонентами различных поставщиков служб облачных вычислений. Примеры включают в себя: HTTP/S, SOAP, протокол расширенной очереди сообщений (Advanced Message Queuing Protocol, AMQP) и транспорт очередей сообщений телеметрии (Message Queuing Telemetry Transport, MQTT).

5.2.1.3 Интероперабельность на уровне синтаксиса данных

Интероперабельность на уровне синтаксиса данных - это способность двух или более систем или служб понимать структуру информации, которой они обмениваются и которая представляет собой кодирование понятий прикладной области, определенных аспектом семантики данных. Примеры синтаксисов кодирования включают в себя: JSON, XML и синтаксисы, описанные средствами ASN.1.

5.2.1.4 Интероперабельность на уровне семантики данных

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

Интероперабельность на уровне семантики данных основана на моделях данных обмениваемой информации во время этого обмена. На уровне инфраструктуры это касается виртуальных машин (ВМ), контейнеров, хранилищ и сетей и управления ими. На уровне платформы это относится к приложениям, средам выполнения и развертывания и управления ими. На уровне приложений концепции прикладной области продиктованы самими приложениями, такими как управление человеческим капиталом (Human Capital Management, HCM), управление взаимоотношениями с клиентами (Customer Relationship Management, CRM), планирование ресурсов предприятия (Enterprise Resource Planning, ERP) и т.д.

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

5.2.1.5 Интероперабельность на уровне поведения

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

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

Интероперабельность на уровне поведения определяется следующими терминами:

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

b) определение ожидаемых результатов в описании службы облачных вычислений включает в себя:

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

2) постусловия, которые отражают состояние службы по завершении операции;

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

Аспект интероперабельности на уровне поведения абстрагируется от деталей реализации и описывает поведение программных компонентов независимым от представления способом.

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

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

5.2.1.6 Интероперабельность на уровне политики

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

5.2.1.7 Проблемы, влияющие на облачную интероперабельность

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

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

В случае транспортного аспекта интероперабельности, если одна система взаимодействует по протоколу REST HTTP, а другая система взаимодействует по протоколу MQTT, интероперабельность на уровне транспорта может быть достигнута посредством адаптера протоколов между системами, такого как сервисная шина предприятия (Enterprise Service Bus, ESB).

Аналогично, если две системы различаются по синтаксическому аспекту интероперабельности, то они могут взаимодействовать посредством транслятора синтаксиса; примером может служить преобразование синтаксиса между данными, закодированными в XML, и данными, закодированными в JSON.

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

Значительные проблемы для интероперабельности создают системы, отличающиеся семантикой данных. Если две системы имеют разные типы артефактов данных или значения артефактов данных различаются между системами, данные от одной системы не имеют смысла или непригодны для использования другой системой. Кроме того, может оказаться невозможным создать семантические адаптеры, позволяющие двум системам осмысленно контактировать. Возможно, удастся создать метаданные или семантические сопоставления для обеспечения некоторой формы (полной или частичной) семантической эквивалентности [2].

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

Интероперабельность на уровне политики может быть одной из самых сложных и трудных задач. Если существует юридический запрет для потребителя службы облачных вычислений на использование некоторой службы, например, по причине того, что служба работает в другой юрисдикции, то потребитель не может использовать эту службу облачных вычислений, даже если все остальные аспекты интероперабельности удовлетворены. Политика потребителя службы облачных вычислений в отношении размещения данных, например, конфиденциальных данных, также может быть существенным препятствием для интероперабельности на уровне политики (см. ИСО 9241-171:2008, подраздел 3.2). Кроме того, корпоративные политики потребителя службы облачных вычислений необходимо принимать во внимание, например, в тех случаях, когда требуются определенные возможности доступности. В некоторых случаях потребитель может вести переговоры с поставщиком службы облачных вычислений, чтобы изменить способ предоставления службы облачных вычислений на такой, который преодолевает проблемы регулирования или политики; например, публичная служба облачных вычислений может быть альтернативно предложена в качестве частной службы (с выделенными ресурсами для этого клиента), чтобы соответствовать политике безопасности клиента.

5.2.1.8 Краткое описание модели аспектов облачной интероперабельности

 

Таблица 1

 

Краткое описание различных аспектов облачной

интероперабельности

 

Аспект	Цель	Объект	Требования	Примеры
Транспортный	Передача данных между системами	Сигналы	Протоколы передачи данных	REST-интерфейс поверх HTTP/S, MQTT
Синтаксический	Получение данных в понятном формате	Данные	Стандартизированные форматы обмена данными	JSON, XML, ASN.1
Семантический	Получение данных с использованием понятной модели данных	Программное обеспечение	Одинаковая интерпретация модели данных	OData, общее понимание и интерпретация, OWL
Поведенческий	Получение ожидаемых результатов запросов к службе	Информация	Поведенческие модели служб облачных вычислений	Модели UML, пред- и постусловия, технические задания
Политика	Уверенность в том, что взаимодействующие системы соответствуют действующим нормативным актам и регламентам организации	Нормативные акты и регламенты организации и контекст взаимодействия	Требования и контроль за использованием и доступом	Политика безопасности клиентов, ограничение межграничной передачи данных, правила контроля ПДн

 

5.2.2 Модель аспектов облачной переносимости данных

5.2.2.1 Общие положения

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

Настоящий стандарт определяет три аспекта переносимости данных в контексте облачных вычислений. Эти аспекты, называемые соответственно политикой данных, синтаксисом данных и семантикой данных, приведены на рисунке 5. Данная модель основана на модели облачной интероперабельности, описанной в 5.2.1, адаптированной к особенностям облачной переносимости данных.

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

 

 

Рисунок 5 - Аспекты облачной переносимости данных

 

5.2.2.2 Синтаксическая переносимость данных

Синтаксическая переносимость данных определяется как передача данных от исходной системы в целевую систему с использованием форматов данных, которые могут быть декодированы в целевой системе, с использованием определенного синтаксиса для кодирования данных, такого как XML, или инкапсуляции данных в формат упаковки, такой как Открытый формат виртуализации (Open Virtualization Format, OVF) [3] или Zip [8].

5.2.2.3 Семантическая переносимость данных

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

5.2.2.4 Переносимость политики данных

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

5.2.2.5 Проблемы, влияющие на облачную переносимость данных

Основа облачной переносимости данных - это взаимное понимание семантики, зафиксированной в модели данных. Семантика может быть закодирована посредством различных синтаксисов, но при условии, что одинаковое понимание модели данных сторонами трансляция в другое синтаксическое представление приведет к минимальной потере информации. Аналогичным образом политики могут меняться, но семантическая переносимость данных обеспечивает согласованность.

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

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

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

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

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

Независимо от предметной области, особое внимание должно уделяться персональной информации. Например, согласно ссылке [16], субъект данных имеет право получать персональные данные в машиночитаемых, структурированных и широко используемых форматах. Персональные данные можно описать несколькими категориями. Информация об этих категориях данных содержится в ИСО/МЭК 19944. Кроме того, данные в любой категории могут предоставлять или способствовать получению информации, которая связана с физическим лицом, именуемой в настоящем стандарте персональными данными (ПДн). То, насколько отдельные лица непосредственно идентифицируются по данным, и насколько легко связать набор характеристик с данными конкретного лица, важно для отдельных лиц, потребителей службы облачных вычислений и лиц, принимающих решения, при оценке использования этой категории данных. Поэтому спецификация данных часто включает в себя не только тип этих данных, но также описание того, насколько данные могут идентифицировать человека (ИСО/МЭК 19944:2017, подраздел 8.3).

Стандарты, определяющие семантику некоторых элементов данных, могут помочь обеспечить переносимость семантики. Например, схема Dublin Core [1] представляет собой глоссарий, описывающий веб-ресурсы.

5.2.2.6 Краткое описание аспектов облачной переносимости данных

 

Таблица 2

 

Краткое описание различных аспектов облачной

переносимости данных

 

Аспект	Цель	Объект	Требования	Примеры
Синтаксис данных	Получение данных в машиночитаемом, структурированном и широко используемом формате	Данные	Распространенный машиночитаемый формат данных	XML, CSV, JSON
Семантика данных	Гарантированное значение данных	Схемы данных и онтологии	Одинаково понимаемые онтологии и метаданные	OWL, схема Dublin Core
Политика относительно данных	Соблюдение всех действующих нормативных актов и регламентов организации	Нормативные акты и регламенты организации	Согласованный набор применимых нормативных актов и регламентов организации	Уровни конфиденциальности, права на неприкосновенность частной жизни, трансграничная передача данных

 

5.2.3 Модель аспектов облачной переносимости приложений

5.2.3.1 Общие положения

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

Настоящий стандарт определяет пять аспектов облачной переносимости приложений в контексте облачных вычислений. Эти аспекты приведены на рисунке 6: синтаксис приложения, инструкции приложения, метаданные приложения, поведение приложения и политики приложения. Модель аспектов облачной переносимости приложений основана на модели аспектов интероперабельности облачных приложений, описанной в 5.2.1, и адаптирована к особенностям облачной переносимости приложений.

В отличие от модели облачной интероперабельности транспортный аспект не включен в модель облачной переносимости приложений, поскольку процесс переноса приложений между двумя системами является отдельным вопросом, который может быть решен несколькими способами.

 

 

Рисунок 6 - Аспекты облачной переносимости приложений

 

5.2.3.2 Переносимость синтаксиса приложений

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

5.2.3.3 Переносимость инструкций приложения

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

5.2.3.4 Переносимость метаданных приложений

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

5.2.3.5 Переносимость поведения приложения

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

5.2.3.6 Переносимость политик приложения

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

5.2.3.7 Краткое описание модели аспектов облачной переносимости приложений

 

Таблица 3

 

Краткое описание различных аспектов облачной переносимости

приложений

 

Аспект	Цель	Объект	Требования	Примеры
Синтаксис приложения	Формат перенесенного приложения понятен	Приложение	Распространенный формат упаковки	Zip, tar, jar
Инструкции приложения	Возможность выполнения инструкции приложения функционально эквивалентным образом	Инструкции приложения	Поддерживаемая среда выполнения	C++, Java, C#, BPEL
Метаданные приложения	Взаимное понимание зависимостей от среды, необходимое для правильного исполнения приложение	Метаданные приложения	Общая модель метаданных	XML, JSON, YAML
Поведение приложения	Возможность выполнения приложения для получения ожидаемых результатов	Функциональные и нефункциональные требования к приложению	Общие предположения об окружающей среде	Наборы тестов приложения
Политика приложения	Согласованный набор ограничений на использование приложения из нормативных актов и регламентов организации	Нормативные акты и регламенты организации	Условия и контроль использования и доступа	Лицензии, применимый регламент, политика предприятия