Из ГОСТ Р 70860–2023 Информационные технологии. Облачные вычисления. Общие технологии и методы

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

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

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

Долгосрочное хранение информации обеспечивается с помощью модели DSaaS. Сервисы DSaaS предлагают возможности хранения данных различных типов и эти функциональные возможности могут быть предложены как системам потребителя облачной службы, так и другим облачным сервисам. Сервисы DSaaS основаны на ресурсах хранения данных поставщика облачной службы, доступ к которым обычно осуществляется по сети через API. В некоторых случаях сервис DSaaS рекомендуется разместить вместе с вычислительным сервисом, чтобы устранить задержки в работе сети [из 12.1 Общие положения ГОСТ Р 70860—2023]

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

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

Сервисы хранения данных имеют следующие общие отличительные особенности:

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

б) доступность. Сервисы DSaaS обеспечивают хранение и извлечение данных по запросу для удовлетворения потребностей приложений и систем потребителя облачной службы;

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

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

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

DSaaS, как показано в таблицах 1 и 2, можно разделить по типу хранения и по категории сервисов. Каждый сервис хранения имеет один или несколько сервисных интерфейсов, таких как драйвер блочного устройства, интерфейс файловой системы или API хранилища объектов, которые используются клиентским ПО. Эти API работают через сеть, поскольку в большинстве случаев предполагается, что функциональные возможности для хранения данных существуют в системе, отличной от системы, на которой запущено клиентское ПО.

Таблица 1 — DSaaS по типу хранения данных

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

Таблица 2 — Преимущества для потребителей облачных служб

[из 12.2 Общие характеристики сервисов DSaaS ГОСТ Р 70860—2023]

В ГОСТ ISO/IEC 17788—2016, подраздел 6.4 определены следующие три различных типа функциональных возможностей:

• инфраструктурный (как в laaS);
• платформенный (как в PaaS);
• прикладной (как в SaaS).

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

Таблица 3 — Типы функциональных возможностей DSaaS

Типы облачных функциональных возможностей, применяемые к облачным сервисам, описанным в таблицах 1 и 2, варьируются (см. таблицу 3). Большинство облачных сервисов, описанных в таблице 1, как правило, предоставляются в виде облачных сервисов инфраструктурного типа. Облачные сервисы, перечисленные в таблице 2, как правило, относятся к платформенному или прикладному типу, за исключением федеративных сервисов хранения данных, которые, как правило, относятся к инфраструктурному типу [из 12.3 Типы функциональных возможностей DSaaS ГОСТ Р 70860—2023]

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

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

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

Еще одной функциональной возможностью, предлагаемой отдельными облачными сервисами хранения данных, является близость ресурсов. Речь идет об относительном физическом размещении экземпляров облачных сервисов хранения данных по отношению к другим облачным сервисам, в основном к экземплярам вычислительных сервисов, таким как ВМ и контейнеры. Одной из основных причин размещения экземпляров вычислительных сервисов рядом с экземплярами сервисов хранения является поддержание высокой скорости работы как с точки зрения снижения задержек, так и с точки зрения увеличения пропускной способности для данных, передаваемых между экземплярами вычислительных систем и систем хранения. Некоторые категории сервисов, например сервисы блочного хранения данных, часто предлагаются только в таком виде. Например, сервисы блочного хранения могут предлагаться только для использования экземплярами вычислительных сервисов, работающими на узлах в том же центре обработки данных, где между узлом хранения и вычислительным узлом имеется высокоскоростной канал, например оптоволоконный или Ethernet [из 12.4 Важные дополнительные функциональные возможности DSaaS ГОСТ Р 70860—2023]

Сетевое подключение является ключевым элементом облачных вычислений. Само определение облачных вычислений основано на том, что доступ к их функциональным возможностям осуществляется через сеть: обеспечение сетевого доступа к масштабируемому и адаптивному пулу совместно используемых физических или виртуальных ресурсов с поддержкой самообслуживания и администрирования по требованию (см. ГОСТ ISO/IEC 17788).

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

Таким образом, существуют два общих вопроса, связанных с сетями в облачных вычислениях. Первый — это сетевое подключение, с помощью которого осуществляется доступ к данному облачному сервису и доступ к любым функциональным возможностям внутри облачного сервиса, например к приложению, запущенному в рамках вычислительного сервиса. Оно называется «сетевое подключение для доступа к облаку» или «сетевое подключение для доступа к публичному облаку», если речь идет о публичных облачных сервисах. Второй — это сетевое подключение, используемое для соединения экземпляров облачных сервисов друг с другом. Это сетевое подключение не должно быть доступно за пределами конкретных экземпляров облачных сервисов. Оно называется «внутриоблачное сетевое подключение» [из 13.1 Ключевые аспекты создания сетевых подключений ГОСТ Р 70860—2023]

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

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

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

Для общедоступных интерфейсов также может потребоваться специальная настройка конфигурации. В частности, организации, приложение которой работает в облачном сервисе, может понадобиться, чтобы адрес, используемый для интерфейса, принадлежал ей, а не поставщику облачной службы. Эта концепция называется «Bring Your Own IP addresses» (BYOIP). Она дает возможность потребителю облачной службы настроить общедоступный интерфейс для приложения, работающего в облачном сервисе, с адресом, принадлежащим потребителю облачной службы. Подобного рода настройка может использоваться как для публичных облачных сервисов, так и для частных облачных сервисов [из 13.2 Сетевое подключение для доступа к облаку ГОСТ Р 70860—2023]

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

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

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

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

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

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

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

Виртуальные сети могут быть построены с использованием различных методов и технологий, включая программно-определяемые сети (SDN) и виртуализацию сетевых функций (NFV) [из 13.3 Внутриоблачное сетевое подключение ГОСТ Р 70860—2023]

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

• конфигурация «узел — шлюз» (Host-to-Gateway). При этой конфигурации автономная система, как правило, клиентский компьютер или устройство получает удаленный доступ к защищенной сети. В контексте облачных вычислений типичным сценарием использования является доступ клиентского устройства к облачным сервисам, приложениям и другим ресурсам, работающим в них;
• конфигурация «шлюз — шлюз» (Gateway-to-Gateway). При этой конфигурации защищенный сетевой обмен данными осуществляется между двумя отдельными защищенными сетями. При типичном сценарии использования облачные сервисы в облачной среде либо должны быть подключены к внутренним приложениям и системам потребителя облачной службы, либо должны быть подключены к другим облачным сервисам, работающим в другой облачной среде.

Рисунок 9 — Типы конфигурации сетей VPN

Для создания сетей VPN используются различные технологии, такие как L2TP/IPsec и OpenVPN. Публичными поставщиками облачных служб, как правило, поддерживаются один или несколько типов сетей VPN [из 13.4 VPN и облачные вычисления ГОСТ Р 70860—2023]