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

    ГОСТ Р ИСО/МЭК 19941-2021

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационные технологии

ОБЛАЧНЫЕ ВЫЧИСЛЕНИЯ

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

Information technology. Cloud computing. Interoperability and portability

ОКС 35.020;

01.040.35

Дата введения 2022-01-01

Предисловие

1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью "Информационно-аналитический вычислительный центр" (ООО ИАВЦ) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационные технологии"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 19 ноября 2021 г. N 1523-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 19941:2017* "Информационные технологии. Облачные вычисления. Интероперабельность и переносимость" (ISO/IEC 19941:2017 "Information technology - Cloud computing - Interoperability and portability", IDT).

ИСО/МЭК 19941 разработан Подкомитетом ПК 38 "Облачные вычисления и распределенные платформы" Совместного технического комитета СТК 1 "Информационные технологии" Международной организации по стандартизации (ИСО) и Международной электротехнической комиссии (МЭК)

5 ВВЕДЕН ВПЕРВЫЕ

6 Некоторые положения международного стандарта, указанного в пункте 4, могут являться объектом патентных прав. ИСО и МЭК не несут ответственности за идентификацию подобных патентных прав

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

Введение

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

Облачные вычисления определяются как парадигма предоставления сетевого доступа к масштабируемому и эластичному пулу разделяемых физических или виртуальных ресурсов с обеспечением самообслуживания и администрированием по требованию. ИСО/МЭК 17788 и ИСО/МЭК 17789 обеспечивают основу для понимания различных типов интероперабельности и переносимости, отношений между деятельностями, ролями и типами облачных вычислений. Интероперабельность, переносимость данных и переносимость приложений имеют важное значение для использования служб облачных вычислений. Целью интероперабельности является обеспечение взаимодействия между необлачными и облачными службами, между службами облачных вычислений, а также создание новых служб из композиции нескольких служб. Цель переносимости - позволить потребителям служб облачных вычислений перемещать свои данные или приложения между необлачными службами и одной или несколькими службами облачных вычислений, а также между службами облачных вычислений. Преимущества интероперабельности заключаются в снижении затрат на интеграцию и повышении ценности услуг за счет обогащения существующих или добавления новых функциональных возможностей благодаря композиции служб облачных вычислений. Преимущества переносимости заключаются в повышении эффективности за счет снижения затрат на миграцию. Как интероперабельность, так и переносимость предлагают больше возможностей для потребителей служб облачных вычислений благодаря уменьшению последствий привязки к конкретной службе облачных вычислений или поставщику службы облачных вычислений. Несмотря на то, что не существует никаких разногласий в том, что интероперабельность и переносимость являются преимуществами облачных вычислений, нет единого способа использования этих возможностей. Применение интероперабельности или переносимости без детального анализа того, что конкретно должно быть перенесено или должно быть совместимым, бессмысленно и не приводит к облачным решениям, которые отвечают бизнес-целям потребителя служб облачных вычислений и поставщика служб облачных вычислений. Это приводит к значительной и продолжающейся путанице в области облачных вычислений и требует разрешения.

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

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

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

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

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

1 Область применения

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

Настоящий стандарт связан с другими стандартами, а именно ИСО/МЭК 17788, ИСО/МЭК 17789, ИСО/МЭК 19086-1, ИСО/МЭК 19944, и, в частности, содержит ссылки на сквозные аспекты и компоненты, определенные в ИСО/МЭК 17788 и ИСО/МЭК 17789, соответственно.

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

2 Нормативные ссылки

В настоящем стандарте нормативные ссылки отсутствуют.

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями.

ИСО и МЭК поддерживают терминологические базы данных для использования в области стандартизации по следующим адресам:

- МЭК Электропедия: доступна по адресу http://www.electropedia.org/

- платформа ИСО для онлайн-просмотра: доступна по адресу http://www.iso.org/obp

3.1 Термины, относящиеся к интероперабельности

3.1.1 интероперабельность (interoperability): Способность двух или более систем или приложений обмениваться информацией и взаимно использовать эту информацию.

[ИСО/МЭК 17788:2014, статья 3.1.5]

3.1.2 облачная интероперабельность (cloud interoperability): Способность системы потребителя службы облачных вычислений взаимодействовать со службой облачных вычислений или способность одной службы облачных вычислений взаимодействовать с другими службами облачных вычислений путем обмена информацией в соответствии с предписанным методом для получения предсказуемых результатов.

Примечание - Взаимодействие служб облачных вычислений между собой происходит посредством отношения CSP: поставщик инфраструктуры межоблачных вычислений.

3.1.3 интероперабельность на уровне транспорта (transport interoperability): Вид интероперабельности (3.1.1), при которой обмен информацией использует установленную коммуникационную инфраструктуру между участвующими системами.

3.1.4 синтаксическая интероперабельность (syntactic interoperability): Вид интероперабельности (3.1.1), позволяющей участвующим системам понимать форматы обмениваемой информации.

3.1.5 интероперабельность на уровне семантики данных (semantic data interoperability): Вид интероперабельности (3.1.1), позволяющей участвующим системам понимать значение модели данных в контексте предметной области.

3.1.6 интероперабельность на уровне поведения (behavioural interoperability): Вид интероперабельности (3.1.1), при которой фактический результат обмена достигает ожидаемого результата.

3.1.7 интероперабельность на уровне политик (policy interoperability): Интероперабельность (3.1.1), при которой соблюдаются требования законодательства, регламентов организаций и политик, применимые к участвующим системам.

3.2 Термины, относящиеся к переносимости данных

3.2.1 переносимость данных (data portability): Возможность легко передавать данные от одной системы к другой без необходимости повторно вводить данные.

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

[ИСО/МЭК 17788:2014, статья 3.2.21]

3.2.2 облачная переносимость данных (cloud data portability): Переносимость данных (3.2.1) от одной службы облачных вычислений в другую службу облачных вычислений или между системой потребителя службы облачных вычислений и службой облачных вычислений.

[ИСО/МЭК 17788:2014, статья 3.2.6 изменена с добавлением фразы: "или между системой потребителя службы облачных вычислений и службой облачных вычислений"]

3.2.3 синтаксическая переносимость данных (data syntactic portability): Переносимость данных (3.2.1) с использованием форматов данных, которые могут быть декодированы в целевой системе.

3.2.4 семантическая переносимость данных (data semantic portability): Переносимость данных (3.2.1), при которой целевая система понимает значение модели данных в контексте предметной области.

3.2.5 переносимость политики данных (data policy portability): Переносимость данных (3.2.1), при которой соблюдаются требования законодательства, регламентов организаций и политик, применимые и к исходной, и к целевой системам.

3.3 Термины, относящиеся к переносимости приложений

3.3.1 переносимость приложений (application portability): Возможность переноса приложения из исходной системы в целевую систему.

3.3.2 облачная переносимость приложений (cloud application portability): Возможность переноса приложения от одной службы облачных вычислений к другой службе облачных вычислений или между системой потребителя службы облачных вычислений и службой облачных вычислений.

[ИСО/МЭК 17788:2014, статья 3.2.2 изменена с добавлением фразы: "или между системой потребителя службы облачных вычислений и службой облачных вычислений"]

3.3.3 переносимость синтаксиса приложений (application syntactic portability): Переносимость приложений (3.3.1), при которой формат артефактов приложения может быть декодирован в целевой системе.

3.3.4 переносимость инструкций приложения (application instruction portability): Переносимость приложения (3.3.1), при которой набор инструкций приложения выполняется в целевой системе.

3.3.5 переносимость метаданных приложений (application metadata portability): Переносимость приложения (3.3.1), при которой метаданные приложения сохраняются и корректно обрабатываются в целевой системе.

3.3.6 переносимость поведения приложения (application behaviour portability): Переносимость приложения (3.3.1), при которой выполнение в целевой системе дает результаты, эквивалентные полученным в исходной системе.

3.3.7 переносимость политики приложения (application policy portability): Переносимость приложений (3.3.1), при которой соблюдаются требования законодательства, регламентов организаций и политик, применимые и к исходной, и к целевой системам.

4 Сокращения

В настоящем стандарте использованы следующие сокращения:

5 Обзор интероперабельности и переносимости в облачных вычислениях

5.1 Описание интероперабельности и переносимости в облачных вычислениях

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

Настоящий раздел содержит обзор и модели (известные как "модели аспектов"; подробные сведения приведены в 5.2.1, 5.2.2 и 5.2.3) облачной интероперабельности, облачной переносимости данных и облачной переносимости приложений. Существуют различные точки зрения на интероперабельность и переносимость. Такие точки зрения называются "аспектами".

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

5.1.2 Аспекты облачной интероперабельности

A - между приложением и службой облачных вычислений; B - между службами облачных вычислений

Рисунок 1 - Высокоуровневое представление об облачной интероперабельности

ИСО/МЭК 17788 определяет интероперабельность как "способность двух или более систем или приложений обмениваться информацией и использовать эту информацию". В контексте облачных вычислений интероперабельность далее описывается как сквозной аспект, обеспечивающий системе потребителя облачной службы возможность взаимодействовать и обмениваться информацией со службой облачных вычислений в соответствии с предписанным методом и получать предсказуемые результаты (см. ИСО/МЭК 17788:2014, подраздел 6.6). Кроме того, интероперабельность включает в себя способность одной службы облачных вычислений взаимодействовать с другими службами (см. ИСО/МЭК 17789:2014, пункт 8.5.5). Взаимодействие в облаке происходит между приложением потребителя службы облачных вычислений и службами облачных вычислений, а также между службами облачных вычислений, как приведено на рисунке 1. Также следует отметить, что в обоих случаях, как правило, задействованы несколько интерфейсов, что обозначено на рисунке наличием нескольких стрелок.

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

При рассмотрении вопросов облачной интероперабельности необходимо учитывать множество факторов, в том числе:

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

- способность службы облачных вычислений работать с другими службами облачных вычислений;

- свойства, необходимые для обеспечения успешного взаимодействия между средствами ИКТ организации и службой облачных вычислений;

- роли и деятельности, определенные в ИСО/МЭК 17789;

- типы облачных возможностей, определенные в ИСО/МЭК 17788;

- интерфейсы между различными функциональными компонентами, определенными в ИСО/МЭК 17789:2014, подраздел 9.2.

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

5.1.3 Факторы переносимости в облачной вычислительной среде

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

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

Следует иметь в виду, что переносимость в облачных вычислениях редко ограничивается выбором между "возможно" и "невозможно". Чаще всего переносимость "возможна, но с учетом затрат на перенос". Для определения целесообразности переноса приложений и/или данных требуется анализ затрат и выгод. Таким образом, сходство систем потребителя службы облачных вычислений и поставщика службы облачных вычислений в отношении аспектов, описанных в 5.2.2 и 5.2.3, заключается скорее в снижении стоимости переноса, чем в "обеспечении" переносимости, поскольку практически любая переносимость возможна, если клиент готов к ней и способен заплатить за нее. Вопросы переносимости не ограничиваются затратами; они также сопряжены с некоторыми рисками и обычно влекут за собой затраты сил и времени потребителя службы облачных вычислений, а также возможный перерыв в обслуживании.

При рассмотрении переносимости в облачных вычислениях необходимо учитывать множество факторов, которые включают в себя:

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

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

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

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

Переносимость является одним из аспектов миграции. Другие вопросы, связанные с миграцией, в настоящем стандарте не рассматриваются.

5.1.3.2 Облачная переносимость данных

A - между системой потребителя службы облачных вычислений и службой облачных вычислений; B - между службами облачных вычислений

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

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

К факторам, связанным с облачной переносимостью данных, относятся:

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

- синтаксис данных. В идеальном случае синтаксис данных в исходной и целевой службах совпадает. Однако, если синтаксис данных различен, например, исходная система использует синтаксис JSON, а целевая система использует XML, можно произвести преобразование данных с помощью общедоступных инструментов;

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

5.1.3.3 Облачная переносимость приложений

A - между системой потребителя службы облачных вычислений и службой облачных вычислений; B - между службами облачных вычислений

Рисунок 3 - Высокоуровневое представление об облачной переносимости приложений

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

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

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

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

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

- облачная переносимость приложений требует, чтобы определенные деятельности потребителя службы облачных вычислений и партнера службы облачных вычислений и их подролей, поддерживаемые в исходной системе, также поддерживались целевой системой и ее компонентами с приемлемой точностью. На практике различные службы облачных вычислений редко предоставляют одинаковые возможности для поддержки всех деятельностей всех подролей. Необходимо принимать во внимание усилия, требуемые для корректировки этих различий, и потенциальные выгоды. Например, облачное приложение, реализованное в службе облачных вычислений с типом возможностей инфраструктуры (ИСО/МЭК 17788:2014, пункт 3.2.25), перемещенное в другую службу того же типа, может предоставлять идентичные возможности для поддержки деятельности подроли CSC:пользователь службы облачных вычислений, которая связана с развертыванием и работой с приложением, но очень разные возможности для подроли CSC:администратор службы облачных вычислений, управляющей использованием этой службы.

5.1.4 Взаимосвязь между облачной интероперабельностью и облачной переносимостью

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

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

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

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 - Краткое описание различных аспектов облачной интероперабельности

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 и не может быть легко перенесена в систему конкурента.

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

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

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

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

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

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

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

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 - Краткое описание различных аспектов облачной переносимости приложений

5.3 Основные проблемы, связанные с интероперабельностью и переносимостью в облачных вычислениях

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

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

5.3.2 Безопасность

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

Для обеспечения интероперабельности необходимо применять к интерфейсам между системами потребителя службы облачных вычислений и службой облачных вычислений средства обеспечения безопасности, например, определенные в стандартах серии ИСО/МЭК 27000. Эти средства включают в себя защиту связи между системами потребителя службы облачных вычислений и службой облачных вычислений, что обычно достигается использованием различных видов шифрования. В состав средств обеспечения безопасности могут входить протоколы шифрования, такие как HTTPS или протокол безопасности транспортного уровня (Transport Layer Security, TLS), или может использоваться виртуальная частная сеть (Virtual Private Network, VPN) между системами потребителя службы облачных вычислений и службой облачных вычислений. Существует ряд стандартов в области безопасности, которые обеспечивают возможность интероперабельности с точки зрения безопасности.

Вторая проблема, связанная с интероперабельностью, касается идентификации и управления доступом, подробно описанными в 5.3.3.

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

- содержат ли данные персональные данные;

- если данные являются персональными, насколько они конфиденциальны;

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

- подлежат ли данные регулированию и если да, то какие ограничения или требования налагаются правилами.

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

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

Если необходимо шифрование, следует рассмотреть форму шифрования, например, соответствует ли шифрование требованиям стандарта, такого как федеральный стандарт обработки информации США (Federal Information Processing Standard, FIPS) 140-2 [17], а также механизмам, используемым для обработки ключей шифрования. Обработка ключей шифрования может включать в себя службы хранения ключей и использование аппаратных модулей шифрования. Кроме того, возможности шифрования различаются между системами потребителя службы облачных вычислений и облачной службой или между облачными службами, и эти различия должны учитываться в процессе переноса.

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

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

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

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

5.3.3 Аутентификация и управление доступом (АУД)

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

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

Интероперабельность АУД поддерживается рядом стандартов, такими, как упрощенный протокол доступа к каталогу (Llightweight Directory Access Protocol, LDAP) [18], OAuth [19] OpenID Connect [20] и язык разметки безопасности (Security Assertion Markup Language, SAML) [21]; они могут помочь в удовлетворении ключевых требований интегрированного управления персональными данными и единого входа (Single Sign-On, SSO).

В тех случаях, когда система АУД изменяется при переносе в службу облачных вычислений, потребитель службы облачных вычислений должен предпринять необходимые меры для миграции персональных данных пользователей к/от выделенной системы АУД службы облачных вычислений. При переносе персональных данных пользователей идентификаторы, используемые для конкретных объектов, могут изменяться.

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

При рассмотрении переносимости данных и приложений необходимо помнить, что файлы данных не являются самостоятельными, даже если они полностью соответствуют формату документа. У них имеются связанные с ними метаданные, такие как права владения объектами, списки управления доступом (access control list, ACL), история аудита, история изменений и т.д. У некоторых файлов документов будет подробная информация о том, кто вносил и какие изменения, кто создавал и читал комментарии и т.д. Все эти функции зависят от цифровых идентификаторов, управляемых системой АУД. Метаданные файлов могут оказаться непереносимыми, даже если сами файлы являются переносимыми.

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

Поэтому для перехода на другую службу облачных вычислений необходимо выполнение следующих условий:

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

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

5.3.4 Безопасность во время миграции

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

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

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

Кроме того, стоит вопрос о влиянии измененных цифровых идентификаторов, подробно рассмотренный в 5.3.3.

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

5.3.5 Динамическая миграция

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

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

5.3.6 Интерфейсы, API и интероперабельность

Интероперабельность применяется к трем типам интерфейсов или элементов API, связанных с каждой службой облачных вычислений: интерфейсам службы, интерфейсу администрирования и деловому интерфейсу, как приведено в 6.1.

Для служб облачных вычислений в целом существует сравнительно немного стандартов, применимых к этим интерфейсам, что может затруднить интероперабельность. Для транспортного и синтаксического аспектов интероперабельности интерфейсов служб облачных вычислений на практике обычно используют протоколы TCP/IP и HTTP и форматы JSON или XML, а также принципы REST, что позволяет обеспечить интероперабельность по этим аспектам относительно просто.

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

В случае служб облачных вычислений с типом возможностей платформы для интероперабельности интерфейсов также нет глобального соглашения о поведенческих и семантических аспектах интерфейса службы. Бывают случаи, где различные поставщики служб облачных вычислений используют одинаковое базовое программное обеспечение для своих служб облачных вычислений, и в этих случаях элементы API службы могут совпадать для исходной и целевой служб облачных вычислений, хотя это - небольшая часть рынка. Контейнерные технологии, такие как Open Container Initiative

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

________________

https://www.opencontainers.org/

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

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

5.3.7 Открытый исходный код

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

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

6 Вопросы интероперабельности и переносимости, связанные с типами облачных возможностей

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

Чтобы понять техническую осуществимость и стоимость интероперабельности и переносимости по отношению к службам облачных вычислений, полезно сгруппировать сценарии и варианты использования, чтобы их можно было рассмотреть совместно с достаточной детализацией. В настоящем разделе описана структура такого рассмотрения, в которой используются типы возможностей служб облачных вычислений, определенные в ИСО/МЭК 17788, а также архитектурные концепции, описанные в ИСО/МЭК 17789. В данном разделе описывается, как общее пространство интероперабельности и переносимости служб облачных вычислений можно подразделить на категории, имеющие общие свойства.

Полезно начать с набора диаграмм функциональных компонентов, основанных на рисунке 9-2 ИСО/МЭК 17789:2014, в которые добавлены элементы, необходимые для понимания облачной интероперабельности, облачной переносимости данных и облачной переносимости приложений. Функциональные компоненты, приведенные на рисунке 9-2 ИСО/МЭК 17789:2014, не включают в себя дополнительные компоненты, представленные в настоящем разделе, см. рисунки 7, 8 и 9.

Рисунок 7 - Компоненты интероперабельности облачных вычислений

Рисунки 7, 8 и 9 упрощены для облегчения понимания.

Многоуровневые функции сведены к одному высокоуровневому компоненту, расположенному с правой стороны.

Уровень ресурсов и уровень доступа упрощены, чтобы увеличить доступное пространство для других уровней.

Рисунки 7, 8 и 9 расширены - в них добавлены компоненты, полезные для понимания облачной интероперабельности, облачной переносимости данных и облачной переносимости приложений:

а) в верхней части рисунков 8 и 9 добавлен блок "Необлачные системы потребителя службы облачных вычислений". Он представляет системы потребителя службы облачных вычислений, которые содержат приложения и наборы данных потребителя службы облачных вычислений;

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

b) на рисунке 8 приложение потребителя показано в функциональном компоненте "Функция пользователя" пользовательского уровня. В соответствии с подпунктом 9.2.1.1 ИСО/МЭК 17789:2014 следует: "В некоторых случаях функциональный компонент "Функция пользователя" может быть таким же простым, как и браузер, работающий на персональном компьютере. Однако в других случаях он может включить в себя сложную корпоративную систему, управляющую бизнес-процессами, приложениями, промежуточным программным обеспечением и связанной инфраструктурой". Таким образом, функция пользователя может содержать приложение, которое потребитель службы облачных вычислений хочет перенести в службу облачных вычислений;

c) на рисунке 8 приложение потребителя находится в блоке "Необлачные системы потребителя службы облачных вычислений", представляя собой приложение, изначально работающее в системе потребителя, не связанное с какими-либо облачными вычислениями, которое потребитель службы облачных вычислений может перенести в службу облачных вычислений;

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

e) на рисунках 8 и 9 компонент "Возможности служб" на уровне служб расширен, чтобы предоставить пространство двум добавленным в него компонентам:

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

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

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

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

Рисунок 10 - Примеры взаимосвязей и взаимодействий между деятельностями и функциональными компонентами

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

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

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

Следует обратить внимание на то, что на рисунках 7, 8 и 9 представлен случай потребителя службы облачных вычислений и одной службы облачных вычислений, а также интероперабельность и переносимость между системами потребителя службы облачных вычислений и этой службой облачных вычислений. На рисунке 10 приведен другой важный случай, связанный с интероперабельностью, когда существуют две (или более) службы облачных вычислений. В этом случае переносимость как данных, так и приложений связана с переходом от исходной облачной службы к целевой службе облачных вычислений, а интероперабельность связана с необходимостью системы потребителя службы облачных вычислений взаимодействовать с обеими службами облачных вычислений.

На рисунке 10 показан один потребитель службы облачных вычислений, взаимодействующий с двумя службами облачных вычислений: службой облачных вычислений 1 (слева) и службой облачных вычислений 2 (справа). Служба облачных вычислений 1 рассматривается как исходная служба, а служба облачных вычислений 2 - как целевая служба для переноса приложений и данных. Следует обратить внимание на то, что на рисунке 10 дополнительно упрощены уровень доступа и уровень службы для двух служб облачных вычислений, чтобы избежать загромождения рисунка компонентами, не относящимися к интероперабельности и переносимости.

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

6.2 Функциональные компоненты интероперабельности