Стратегия мультиоблачности: маркетинговый ход или новая «нормальность»?

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

Дано

Термин «мультиоблачность» уже подхватили представители рынка. Однако при распространении нового термина первая реакция технарей часто формулируется примерно так: «это аналитики придумали какой-то новый маркетинговый термин, за которым ничего нет». Здравый смысл подсказывает, что если уж арендовать виртуальную инфраструктуру, то лучше это делать у одного поставщика. Именно на этом в свое время и поднялись так называемые гиперскейлеры: Amazon AWS, Microsoft Azure, Google Cloud Platform и примкнувший к ним в последнее время Huawei Cloud. Эти компании сейчас являются лидерами в предоставлении облачных услуг, но редкая компания пользуется услугами только одного из этих инфраструктурных поставщиков. Это связано с несколькими факторами. Например, подключение к Microsoft Azure идёт в коробке с операционными системами Windows, а в пакете с операционной системой Android идет целый набор облачных сервисов Google. Поэтому, если сотрудники пользуются компьютером на базе Windows и мобильным телефоном на базе Android, то уже возникает предпосылка для создания мультиоблачной архитектуры. А если вспомнить, что практически каждый крупный производитель программного обеспечения стремится создать собственное облако и привязать свои продукты к ним, то никаких сомнений быть не может: мультиоблачность - это новая нормальность, связанная с современными маркетинговыми стратегиями производителей сложных ИТ-решений.

В России переходу на «мультиоблачность» способствуют еще два фактора: требования регуляторов и отсутствие на нашей территории технических центров гиперскейлеров. Именно поэтому компаниям, которые должны соблюдать требования закона №152-ФЗ «О персональных данных», приходится базу ИСПДн хранить в специально оформленном и сертифицированном для этого облаке, а все остальное - в нормальных облаках. А что касается отсутствия технических центров гиперскейлеров в России, то сейчас появился даже новый пласт провайдеров - облако, построенное по технологии гиперскейлера, но расположенное в российских ЦОДах. Для этого, например, корпорация Microsoft даже выпустила специальный продукт Azure Stack. По аналогичному пути идут и другие гиперскейлеры, особенно Huawei.

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

Решение

Следует отметить, что для решения проблемы управления ресурсами в арендованных облаках технологии всё-таки есть. Например, можно использовать брокер облачных сервисов (cloud services broker - CSB), позволяющий следить за использованием облачных сервисов, или платформу управления облачными услугами (cloud management platforms - CMP), которая связывает ресурсы независимых провайдеров в единый пул.

Если же клиент хочет самостоятельно управлять ресурсами, распределенными между несколькими облаками, то для этого предназначена технология контейнеризации. Единицей управления в этом случае является виртуальная машина, которая содержит приложение, связанные с ним конфигурационные файлы и приложения. Она-то и называется контейнером. Для реализации такого подхода используются такие технологии, как Docker, rkt и PouchContainer, а наиболее популярной платформой управления является kubernetes и решения на её основе, такие как OpenShift, Docker Swarm и Apache Mesos. Правда, если приложение не адаптировано для использовании в облаке, то придется его вначале поместить в специальную рабочую среду - фреймворки Ansible, SaltStack, Chef или другие, предназначенные как раз для этого. В любом случае управление такой мультиоблачной средой требует определенных компетенций от сотрудников ИТ-службы клиента и расходов на хорошо обученный персонал.

По данным компании Serverspace, облачной платформой для управления мультиоблаком пользуются больше всего клиентов - 41,2%. На втором месте по популярности - управление конфигурациями и инфраструктурой облаков вручную, к этому прибегают 10,7% клиентов. На третьем месте - инструменты собственной разработки с долей в 6,9%, но рядом с ними с долей в 6,1% находится использование стандартных контейнерных решений. Впрочем, доля ответа "Другое" составляет очень большой процент - 29,4, что говорит о том, что общие подходы для управления мультиоблачными конфигурациями не установлены и процесс формирования рынка услуг и продуктов находится на ранних стадиях развития.

Не стоит забывать и о других аспектах мультиоблачной архитектуры. В частности, для организации сквозной аутентификации пользователей сейчас можно использовать различные инструменты федеративной аутентификации. Практически все гиперскейлеры имеют собственные решения для этого: Microsoft - Live ID, Google - Google Sign-In, "Яндекс" - "Яндекс.Паспорт". Часто в качестве базы для подобной аутентификации выступают социальные сети - Facebook, instagram, vk.com, "одноклассники" и другие. Для централизации же в рамках корпоративных ресурсов можно использовать решения однократной аутентификации SSO, которые сейчас уже поддерживают федеративные протоколы и стандарты.

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

Заключение

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

Фото: depositphotos.com

Читайте по теме: 

Облачные стереотипы: топ-5 возражений клиентов

Венди Пфайффер, Nutanix: «Управлять ИТ — это как управлять самолетом»