Сегодня мы все зависим от облачных гигантов, но что будет, если с ними что-то случится?

Автор: Эндрю Фитцджеральд, директор по продажам в Западной Европе и странах Африки, Cohesity

Первые шаги в облачных приложениях были сделаны в нулевых, тогда это были Salesforce, Google Apps, Taleo, Ariba и NetSuite. В 2010-х началось распространение облачных сервисов, а пионеры индустрии заняли позицию «облако – прежде всего» и использовали платформы (включая AWS, Microsoft Azure и облачную платформу Google) для пилотирования, тестирования и запуска сервисов. В 20-х годах абсолютно точно компании попытаются использовать свои уже существующие облачные инвестиции: формализовывать мульти-облачные и гибридные облачные стратегии и возвращать контроль с помощью консолей, которые обеспечивают видимость и управляемость все более разрозненных объектов.

Но есть некоторые неуправляемые области, куда облако ещё не добралось, хотя прогрессивные компании сегодня спрашивают «почему не облако?». Может ли этот режим распространения по умолчанию новой технологии быть рискованным? Короткий ответ – «да». Инновации в ИТ традиционно несут в себе большой риск ещё со стабильных дней работы мэйнфрейма IBM, поскольку они увеличивают количество хранилищ, и ИТ становятся более рассредоточенными. Одновременно с такими темпами изменений технологий растет и количество киберугроз, которые могут подорвать безопасность любой мыслимой инфраструктуры.

Облако тоже может делать ошибки

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

Облачные сервисы не застрахованы от сбоев, взломов, стихийных бедствий или чего-то ещё. Только в 2019 году мы увидели, что Office 365 Exchange Online вышел из строя, и вскоре за ним последовали другие службы Microsoft. Затем были Google Gmail и Drive, Azure, Google Cloud, Salesforce, AWS и другие потребительские платформы, такие как Facebook, Instagram и Apple Cloud. Если уж эти супер-гиганты могут дать сбой, то произойти может все, что угодно и с кем угодно. Поэтому необходимо иметь план быстрого восстановления, если произойдет наихудший сценарий.

Кто за что отвечает?

Согласно недавнему отчету McAfee, 69 процентов директоров по информационной безопасности доверяют своим поставщикам облачных услуг обеспечение надежности своих данных, а 12 процентов считают, что поставщики несут за это полную ответственность. Но правда в том, что облачная безопасность – это общая ответственность. Стремясь обучить своих клиентов тому, что от них требуется, гиганты облачных провайдеров создали модель совместной ответственности (Shared Responsibility Model) облака или сокращенно SRM.

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

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

Облако 2020: наведение порядка

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

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

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

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

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

Ссылка на источник