У меня гибридное облако. Кто отвечает за ИБ, и какие новые угрозы появляются?

Гибридное облако образуется в двух случаях: у кого-то остался парк железа, который ещё надо самортизировать, либо же стоят какие-то уникальные серверы, которые невозможно закупить у облачного провайдера.

Самая частая ситуация — слияние-поглощение, когда вы купили конкурента, а у него куча старого, но ещё хорошего железа. А у вас уже облачный подход. Или когда вы настолько круты, что у вас есть P-машины IBM либо какие-то особенные хранилища (бывают у телестудий и медицинских центров). В любом случае вы столкнетесь с ситуацией, когда есть безопасники в облаке, есть департамент ИБ на вашей стороне и куча костылей — посередине.

По данным Garnter, есть вероятность 90 %, что вопрос переезда в облако коснётся вас в этом или следующем году, поэтому стоит задуматься над кибербезопасностью уже сейчас.

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

Гибридные облака используются всё чаще

Потому что таких сделок всё больше и больше. С точки зрения архитектуры гибридные облака — это не лучшая история, с точки зрения бизнес-процессов — это временная замена полному переходу в облако, а с точки зрения ИБ — это больше хаоса и общения с подрядчиками. Но, по данным Gartner, к 2020 году около 90 % организаций примет возможности управления гибридной инфраструктурой. В этом году многие доминирующие поставщики облачных услуг предприняли шаги по расширению своих гибридных и мультиоблачных предложений — ещё один явный признак того, что рынок готов и ждёт спроса.

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

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

Ликбез про 10 основных угроз

1. Нарушение безопасности данных. Риск взлома и нарушения безопасности данных не является уникальным для облачных вычислений, но он неизменно — главная забота для облачных клиентов.
2. Человеческая ошибка. По исследованиям Gartner, «до 2020 года 95 % сбоев в облачной безопасности будет являться ошибкой клиента».
3. Потеря данных без резервного копирования. Да, есть ещё люди, которые не делают бекапы. На полном серьёзе. Авария или атака могут привести к потере информации за годы работы.
4. Инсайдерские угрозы. В недавнем исследовательском отчёте Gartner отмечалось, что «53 % опрошенных организаций подтвердили инсайдерские атаки на их организации». Зачастую это ситуации, когда обиженный сотрудник уходит с базой данных (или её частью), или когда конкурент целенаправленно устраивает на работу к жертве своего шпиона.
5. DDoS-атаки. Здесь строительная сфера может многое рассказать про особенности подготовки к конкурсам. DDoS уже давно стал в цифровом мире аналогом «наезда» из 90-х. Это уже аргумент в переговорах, способ показать давление либо способ «положить» неугодный сайт с какой-то важной в моменте информацией.
6. Небезопасные API. Как общедоступная «парадная дверь» вашего приложения API, вероятно, будет начальной точкой входа для злоумышленников. С учётом того, сколько людей выставляет свои API наружу (случайно после переезда или думая, что они Неуловимый Джо), проблема стоит остро. После случая с выставленным наружу API касс крупной розничной сети я мало чему удивляюсь.
7. Эксплоит. Многопользовательская природа облака (когда клиенты совместно используют вычислительные ресурсы) означает, что совместная память и ресурсы могут создавать новые поверхности для атак злоумышленников.
8. Взлом аккаунта. Используя украденные учётные данные, злоумышленники могут получить доступ к критически важным областям служб облачных вычислений, что ставит под угрозу конфиденциальность, целостность и доступность этих служб. С учётом того, что пароль нестойкий — это его фактическое отсутствие, — уязвимо очень много систем.
9. Расширенные постоянные угрозы. Многие продвинутые группы угроз нацелены на облачные среды, при этом для их реализации используются публичные облачные сервисы. В России это часто банальные «заказы» на извлечение определённых данных или атаки на инфраструктуру вроде АСУ ТП. Но они довольно редки за пределами крупных конкурентных войн.
10. Аппаратная уязвимость. Злоумышленники могут использовать аппаратные уязвимости для просмотра данных на виртуальных серверах, размещённых на одном и том же физическом оборудовании. Это может иметь катастрофические последствия для облачной инфраструктуры.

Что меняется в гибридной среде?

Существенно ничего, модель угроз та же самая, только ответственность размазана между двумя отделами ИБ двух компаний — облачным и «домашним». Гибридные среды создаются по мере того, как компании переходят от чисто локальных решений к средам с несколькими облачными вычислениями. Сохраняются локальные приложения. Любая облачная безопасность основана на модели совместной ответственности, когда поставщик отвечает за безопасную и надёжную инфраструктуру, а клиент отвечает за безопасность своих активов в облаке.

Но именно при использовании гибридных облаков особенно видны точки стыков этих зон ответственности. Развёртывание средств контроля безопасности данных, передаваемых между облачными и локальными системами, может быть довольно сложным из-за собственных API или инструментов. Это может привести к глубоким пробелам в контроле и аудите. За некоторыми исключениями потребители облачных сервисов принимают эту модель совместной ответственности и выходят за рамки вопроса о том, являются ли облачные сервисы безопасными или могут ли они осуществлять управление и регуляторный контроль над системами.

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

Ниже — таблица с высокоуровневым сравнением публичного, частного и гибридного облаков по различным направлениям:

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

Правило простое: изменилось что-то в процессе — предупреди другую службу ИБ.

Важно, что при использовании гибридного облака вы можете распределить рабочую нагрузку по общедоступным и частным облакам в соответствии с требованиями законодательства по ИБ, а также в соответствии с внутренними требованиями по ИБ. И это тоже хорошая практика. Вот пример, какие сегменты предлагает Техносерв Cloud:

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

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

Итог: гибридное облако по ИБ похоже на обычное, но требует очень плотного взаимодействия двух служб ИБ, кросс-аудитов (в идеале) или чего-то вроде BYOE. В любом случае лучше сначала обсудить с облачным провайдером нюансы защиты, прежде чем принимать решение о переезде. Если у вас есть вопрос по этой теме относительно нашего Техносерв Cloud или вы хотите узнать, где возможны трения конкретно в вашей архитектуре, то можно обсудить это в комментариях или в почте MKoptenkov@technoserv.com.

Автор: TS_Security

Источник