У меня гибридное облако. Кто отвечает за ИБ, и какие новые угрозы появляются?
Гибридное облако образуется в двух случаях: у кого-то остался парк железа, который ещё надо самортизировать, либо же стоят какие-то уникальные серверы, которые невозможно закупить у облачного провайдера.
Самая частая ситуация — слияние-поглощение, когда вы купили конкурента, а у него куча старого, но ещё хорошего железа. А у вас уже облачный подход. Или когда вы настолько круты, что у вас есть P-машины IBM либо какие-то особенные хранилища (бывают у телестудий и медицинских центров). В любом случае вы столкнетесь с ситуацией, когда есть безопасники в облаке, есть департамент ИБ на вашей стороне и куча костылей — посередине.
По данным Garnter, есть вероятность 90%, что вопрос переезда в облако коснётся вас в этом или следующем году, поэтому стоит задуматься над кибербезопасностью уже сейчас.
Ниже в статье — базовые вещи на тот случай, чтобы можно было легче договориться с провайдером о зонах ответственности и внедрить лучшие практики обеспечения информационной безопасности. Соответственно разделение зон ответственности и практики по ИБ мы используем в Техносерв Cloud для заказчиков с гибридными средами и потому знаем, что и где может пойти не так.
Гибридные облака используются всё чаще
Потому что таких сделок всё больше и больше. С точки зрения архитектуры гибридные облака — это не лучшая история, с точки зрения бизнес-процессов — это временная замена полному переходу в облако, а с точки зрения ИБ — это больше хаоса и общения с подрядчиками. Но, по данным Gartner, к 2020 году около 90% организаций примет возможности управления гибридной инфраструктурой. В этом году многие доминирующие поставщики облачных услуг предприняли шаги по расширению своих гибридных и мультиоблачных предложений — ещё один явный признак того, что рынок готов и ждёт спроса.
Провайдер защищает инфраструктуру облака, на базе которой работают предлагаемые сервисы. Эта инфраструктура состоит из аппаратного и программного обеспечения, сетей и объектов, на базе которых работают облачные сервисы. Ответственность клиента зависит от сервиса. Ниже в таблице — небольшое сравнение по четырём моделям предоставления сервиса:
- PaaS — Platform as a Service — платформа как услуга;
- IaaS — Infrastructure as a Service — инфраструктура как услуга;
- SaaS — Software as a service — программное обеспечение как услуга;
- DaaS — Desktop as a Service — рабочее место как услуга.
Выбор того или иного вида сервиса определяет объём работ по настройке политик безопасности, которые необходимо выполнить клиенту в рамках своей зоны ответственности. Например, IaaS потребует выполнения большинства настроек безопасности и задач управления виртуальной инфраструктурой. Клиенты, которые развёртываются в IaaS, отвечают за управление гостевой операционной системой (включая установку обновлений и исправлений безопасности), управление приложениями или сервисными компонентами, установленными в виртуальной инфраструктуре, и за настройку брандмауэра (группы безопасности), предоставляемого IaaS. В PaaS провайдер управляет уровнем инфраструктуры, операционной системой и платформой, а клиенты получают доступ к конечным точкам для хранения и извлечения данных. Клиенты отвечают за управление своими данными (включая параметры шифрования), классификацию своих ресурсов и использование различных инструментов для применения соответствующих разрешений.
Ликбез про 10 основных угроз
- Нарушение безопасности данных. Риск взлома и нарушения безопасности данных не является уникальным для облачных вычислений, но он неизменно — главная забота для облачных клиентов.
- Человеческая ошибка. По исследованиям Gartner, «до 2020 года 95% сбоев в облачной безопасности будет являться ошибкой клиента».
- Потеря данных без резервного копирования. Да, есть ещё люди, которые не делают бекапы. На полном серьёзе. Авария или атака могут привести к потере информации за годы работы.
- Инсайдерские угрозы. В недавнем исследовательском отчёте Gartner отмечалось, что »53% опрошенных организаций подтвердили инсайдерские атаки на их организации». Зачастую это ситуации, когда обиженный сотрудник уходит с базой данных (или её частью), или когда конкурент целенаправленно устраивает на работу к жертве своего шпиона.
- DDoS-атаки. Здесь строительная сфера может многое рассказать про особенности подготовки к конкурсам. DDoS уже давно стал в цифровом мире аналогом «наезда» из 90-х. Это уже аргумент в переговорах, способ показать давление либо способ «положить» неугодный сайт с какой-то важной в моменте информацией.
- Небезопасные API. Как общедоступная «парадная дверь» вашего приложения API, вероятно, будет начальной точкой входа для злоумышленников. С учётом того, сколько людей выставляет свои API наружу (случайно после переезда или думая, что они Неуловимый Джо), проблема стоит остро. После случая с выставленным наружу API касс крупной розничной сети я мало чему удивляюсь.
- Эксплоит. Многопользовательская природа облака (когда клиенты совместно используют вычислительные ресурсы) означает, что совместная память и ресурсы могут создавать новые поверхности для атак злоумышленников.
- Взлом аккаунта. Используя украденные учётные данные, злоумышленники могут получить доступ к критически важным областям служб облачных вычислений, что ставит под угрозу конфиденциальность, целостность и доступность этих служб. С учётом того, что пароль нестойкий — это его фактическое отсутствие, — уязвимо очень много систем.
- Расширенные постоянные угрозы. Многие продвинутые группы угроз нацелены на облачные среды, при этом для их реализации используются публичные облачные сервисы. В России это часто банальные «заказы» на извлечение определённых данных или атаки на инфраструктуру вроде АСУ ТП. Но они довольно редки за пределами крупных конкурентных войн.
- Аппаратная уязвимость. Злоумышленники могут использовать аппаратные уязвимости для просмотра данных на виртуальных серверах, размещённых на одном и том же физическом оборудовании. Это может иметь катастрофические последствия для облачной инфраструктуры.
Что меняется в гибридной среде?
Существенно ничего, модель угроз та же самая, только ответственность размазана между двумя отделами ИБ двух компаний — облачным и «домашним». Гибридные среды создаются по мере того, как компании переходят от чисто локальных решений к средам с несколькими облачными вычислениями. Сохраняются локальные приложения. Любая облачная безопасность основана на модели совместной ответственности, когда поставщик отвечает за безопасную и надёжную инфраструктуру, а клиент отвечает за безопасность своих активов в облаке.
Но именно при использовании гибридных облаков особенно видны точки стыков этих зон ответственности. Развёртывание средств контроля безопасности данных, передаваемых между облачными и локальными системами, может быть довольно сложным из-за собственных API или инструментов. Это может привести к глубоким пробелам в контроле и аудите. За некоторыми исключениями потребители облачных сервисов принимают эту модель совместной ответственности и выходят за рамки вопроса о том, являются ли облачные сервисы безопасными или могут ли они осуществлять управление и регуляторный контроль над системами.
Проще говоря, если отделы ИБ клиента и поставщика не будут пускать друг друга в свои процессы, то будет создана прямая угроза ИБ. Именно поэтому нужны чёткое разделение зон ответственности и формальная процедура взаимодействия, описанная в рамках договора (соглашения) между поставщиком услуг и клиентом.
Ниже — таблица с высокоуровневым сравнением публичного, частного и гибридного облаков по различным направлениям:
При использовании гибридного облака организации (клиент и поставщик) должны иметь возможность самостоятельно проводить аудит и подтверждать соответствие ряду нормативных требований по ИБ. Это означает, что важно обеспечить переносимость данных, чтобы в случае изменения бизнес-приоритетов компания могла безопасно обмениваться или переносить данные между локальными и общедоступными облачными средами с минимальными дополнительными усилиями.
Правило простое: изменилось что-то в процессе — предупреди другую службу ИБ.
Важно, что при использовании гибридного облака вы можете распределить рабочую нагрузку по общедоступным и частным облакам в соответствии с требованиями законодательства по ИБ, а также в соответствии с внутренними требованиями по ИБ. И это тоже хорошая практика. Вот пример, какие сегменты предлагает Техносерв Cloud:
Парадигма «Принеси своё собственное шифрование» (BYOE) и централизованное управление ключами для обеспечения безопасности данных с максимальным контролем, видимостью и мобильностью — это круто. Это даёт компаниям гибкость в развёртывании правильных решений для защиты данных там, где это важнее всего, без передачи контроля над ключами облачным провайдерам.
На всякий случай: да, у нас и в обычной облачной инсталляции можно зашифровать всё и не хранить ключи на облачных серверах. Это хорошая практика. Но даже в незашифрованных средах мы не ходим дальше гипервизора, то есть даже не знаем, лицензионная ли у вас ОС на ВМ.
Итог: гибридное облако по ИБ похоже на обычное, но требует очень плотного взаимодействия двух служб ИБ, кросс-аудитов (в идеале) или чего-то вроде BYOE. В любом случае лучше сначала обсудить с облачным провайдером нюансы защиты, прежде чем принимать решение о переезде. Если у вас есть вопрос по этой теме относительно нашего Техносерв Cloud или вы хотите узнать, где возможны трения конкретно в вашей архитектуре, то можно обсудить это в комментариях или в почте MKoptenkov@technoserv.com.
