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

Различия терминов: что на самом деле означает «мультиоблако»?

Мы неоднократно замечали, что сам термин «мультиоблако» имеет несколько различных трактовок. Чтобы избежать недопонимания, мы сразу обозначим, что под мультиоблаком подразумеваем облачную архитектуру, в которой одновременно сочетаются различные модели облаков — как модели вычислений (например, SaaS, IaaS, PaaS), так и модели развертывания (частные, публичные, гибридные). Дело в том, что нередко мультиоблаком называют использованные комбинации исключительно публичных облачных решений, как правило, от мировых вендоров типа AWS, Google Cloud, Microsoft Azure, Oracle Cloud и т. д. Однако было бы правильнее рассматривать мультиоблако именно как сочетание разных типов облаков, и на это есть некоторые причины.

  1. В статьях о мультиоблаке часто акцентируют внимание на различиях между ним и гибридным облаком, подчеркивая, что гибридное облако может быть частью мультиоблака. Поскольку само по себе гибридное облако является композицией как частных, так и публичных облачных ресурсов, да и частное облако (причем не одно) сейчас можно развернуть у сторонних провайдеров, говорить о мультиоблаке только как о сочетании публичных облаков не совсем корректно.
  2. Большинство авторитетных ресурсов, например Techopedia сходятся на том, что мультиоблако включает различные типы облаков, и частные в том числе. Это же подтверждают и результаты опроса компании BMС Software, проведенного среди ИТ-специалистов 11 стран. 52% респондентов считают, что мультиоблако — это комбинация публичных и/или частных облаков, а также локальных (on-premise) платформ компании.

Мультиоблачная стратегия как мировой тренд

Согласно отчету Rightscale State of the Cloud Report, в 2018 году мультиоблачную стратегией располагал 81% компаний (в опросе участвовали 525 крупных предприятий и 472 компаний малого и среднего бизнеса со всего мира). В среднем мультиоблачные организации используют чуть больше трех облаков (3,1), что согласуется с результатами исследования Cloudify: в 2017 году 85% мультиоблачных компаний имели до четырех облаков.

Разумеется, с добавлением облачных ресурсов расширяется и усложняется ИТ-архитектура. Вместе с тем увеличиваются площади для кибератак и потенциальные информационные риски. На данный момент именно информационная безопасность, наряду с организацией управления данными и автоматизацией, считается главным вызовом для мультиоблачных компаний. По прогнозам BMC, именно на информационную безопасность будет выделяться большая часть инвестиций компаний в ИТ. Учитывая, к каким убыткам сегодня приводят облачные киберугрозы, эти стратегические финансовые решения кажутся вполне обоснованными. Для подтверждения приведем данные Kaspersky Lab, согласно которым инциденты, связанные с облачной безопасностью, обходятся крупным компаниям приблизительно в 1,2 млн. долл., а предприятиям малого и среднего бизнеса — минимум в 100 000 долл. И в основном мишенью атак становится критически важная для бизнеса информация: конфиденциальные данные клиентов (49% случаев в СМБ, 40% — в крупных компаниях), информация о сотрудниках (35 и 36% соответственно), а также электронные письма и внутренняя связь (31 и 35% соответственно).

Как защитить мультиоблако?

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

То есть здесь мы сталкиваемся минимум с двумя проблемами.

  1. Разные облачные продукты предполагают разные подходы к организации безопасности и использование разных инструментов защиты. При этом единого универсального решения, которое бы CIO мог внедрить для всех облаков одновременно, увы, не существует.
  2. Не всегда клиент понимает, где заканчивается ответственность провайдера и где начинается ответственность пользователя. Недавнее исследование Ponemon Institute по заказу Gemalto подтвердило, что единого мнения на этот счет нет даже у практикующих специалистов, занимающихся ИТ и информационной безопасностью. Треть респондентов считает, что облачная безопасность — это обязанность провайдера, треть — что это забота пользователей, и треть — что ответственность нужно разделять.

Согласно Cloud Security Alliance, так называемая модель общей ответственности подразумевает выполнение двух требований:

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

Как решить эти две проблемы?

Мультиоблачной компании важно внимательно изучить соглашение об уровне услуг каждого провайдера, услугами которого она пользуется. Нужно оценить и смоделировать риски, выстроить стратегию защиты уровней архитектуры совместно с отделом информационной безопасности. Удивительно, но, как показало все то же исследование Ponemon Institute, сделанное по заказу Gemalto, большинство компаний (79%) задействуют свои отделы ИБ в процессе принятия решений, связанных с облаками, лишь время от времени, то есть довольно редко. Фактически такое поведение можно расценивать как попытку переложить ответственность за облачную защиту на плечи провайдеров, хотя спешить с выводами тоже не стоит.

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

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

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

Безопасность в мультиоблаке: классификация данных и прозрачность ИТ-инфраструктуры

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

Законодательные ограничения межграничной передачи данных (выбранные страны, по состоянию на 2017 год)

Китай

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

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

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

Европейский Союз

Передача персональных данных за пределы ЕС/ЕЭС разрешена только в страны, предоставляющие соответствующий уровень защиты персональных данных и соблюдение прав приватности. Официально такими странами признаны лишь 12. Среди них Андорра, Аргентина, Канада, Швейцария, Израиль, США, Уругвай, Новая Зеландия и др. Чтобы доказать наличие должного уровня защиты данных, компания может использовать несколько методов: Standard Contractual Clauses (SCC) с подписанием договора EU-US Privacy Shield («Щит приватности»), получить сертификат Binding Corporate Rules (BCRs) или соответствовать утвержденным в отрасли Кодексу профессиональной этики либо механизму сертификации. В редких случаях передача может осуществляться с явным, информированным, согласием субъекта данных или с применением других исключений.

Россия

Законодательство РФ содержит значительные ограничения по обработке данных, включая требования о согласии пользователей на большую часть форм обработки информации. Однако самое главное ограничение — с сентября 2015 года компании обязали хранить персональные данные граждан России на серверах внутри РФ (в частности, из-за отсутствия физических серверов в России была запрещена социальная сеть Linkedin). Эти данные можно передавать, но только после того, как изначально они будут сохранены на российских серверах.

Источники: ITIF, Cloud Security Alliance

Примечание. Как мы все знаем, законотворческая лихорадка продолжается, и за год после выхода отчетов ITIF и Cloud Security Alliance некоторые страны, возможно, успели ввести новые интересные ограничения на трансграничный обмен данными.

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

Проблема «темных» данныx

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

Проблема легкости миграции между платформами

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

Проблема обработки запросов от контролирующих органов и пользователей

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

Чтобы избежать возможных трудностей компаниям необходимо выполнить такие условия:

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

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

Контроль пользователей и устройств

По мнению Мартина Немера, директора Accelerate Advisory Services, CEMEA, VMware, на сегодняшний день существует две главные проблемы облачной безопасности: отсутствие системного подхода к организации ИБ и возможность доступа в облако с огромного количества устройств, состояние безопасности которых совершенно не определено. «Многие облачные сервисы являются широкими площадками для атак киберпреступников, так как их одновременно использует огромное количество людей, заходящих в облако с устройств, состояние безопасности которых никак не отслеживается и не контролируется ИБ-отделом», — отмечет он.

Именно управление учетными данными и идентификация пользователей является одним из камней преткновения в мультиоблачной безопасности. В идеале все использующиеся для входа устройства должны быть зарегистрированы и проверены администраторами. Важно четко определить всех пользователей мультиоблака, их группы и роли. Для всех платформ должны действовать единые правила авторизации и аутентификации, которые, кстати, тоже можно установить с помощью облачного сервиса — Identity-as-a-Service (IdaaS).

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

Заключение

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

Автор статьи — аналитик немецкого хостинг-провайдера Colobridge.