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

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 Аутентификация и управление доступом (АУД)

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

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

Интероперабельность АУД поддерживается рядом стандартов, такими, как упрощенный протокол доступа к каталогу (Lightweight 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 <1>, могут упростить миграцию приложений, упакованных в их формате, даже если детали API службы, используемые для их развертывания и управления, различаются.

--------------------------------

<1> https://www.opencontainers.org/

 

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

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

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

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

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