Факторы безопасности, которые нельзя игнорировать при планировании перехода к облаку

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

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

В этом руководстве мы собрали некоторые из этих золотых принципов, правил и методов перехода к облаку.

Полное понимание вашего перехода к облаку

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

Поймите идею «разделенной ответственности»

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

Вопросы, на которые вы должны быть в состоянии ответить:

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

Нет простых ответов. Однако хорошей отправной точкой является матрица управления облачными средами (CCM) Альянса по безопасности облачных сред. Матрица поможет вам по-настоящему оценить все проблемы, вопросы и соображения безопасности при переходе в облако.

Критический вопрос совместимости

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

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

Расположение данных

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

Вместо этого вам лучше обсудить это с продавцом. Обсуждение должно быть направлено на получение ответов на следующие вопросы:

• Как поставщик гарантирует, что ваши данные не будут смешиваться с данными другого клиента?
• Как поставщик гарантирует, что доступ к данным имеют только уполномоченные лица?
• Что делает поставщик, чтобы данные оставались в безопасности все время, пока они хранятся на общем сервере?

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

Получите элементы управления тестированием на проникновение

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

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

Хорошо подумайте о аварийном восстановлении

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

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

Применение DevOps к кибербезопасности

Гибкость общедоступного облака — одно из основных бизнес-обоснований для организаций, которым следует отказаться от локальной среды в пользу облака. Однако, если группам безопасности не удастся обновить свои методы, они могут свести на нет эти преимущества. Рассмотрим ситуацию, когда разработчик запускает сервер в течение нескольких минут, но затем должен ждать 10 дней, пока команда безопасности не подпишется. Чтобы предотвратить это, компаниям необходимо применять принципы DevOps к кибербезопасности и предоставлять разработчикам высокоавтоматизированные службы безопасности.

Безопасность в конечном счете зависит от вас

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