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

image

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

Самая частая ситуация — слияние-поглощение, когда вы купили конкурента, а у него куча старого, но ещё хорошего железа. А у вас уже облачный подход. Или когда вы настолько круты, что у вас есть 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 — рабочее место как услуга.




PaaS



IaaS



SaaS



DaaS



Безопасность



· Заказчик облачных услуг привязан к предоставляемой платформе.


· Выбор СЗИ ограничен и лежит на облачном провайдере.


· Заказчик может настраивать функции защиты приложений.



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



· Заказчик облачных услуг не имеет возможности выбора средств и механизмов защиты облака.


· Выбор СЗИ лежит на провайдере облачных услуг.



· Заказчик может настраивать функции защиты приложений.


· Выбор СЗИ ограничен и лежит на облачном провайдере.



Что контролирует заказчик?



· Данные, приложения.


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



· Данные, приложения, среду выполнения, операционные системы, виртуальную инфраструктуру (виртуальные машины, сети, вычислительные ресурсы).


· Заказчик должен разработать и регулярно тестировать процедуры реагирования на инциденты, которые основаны на совместной ответственности между клиентом и облачным поставщиком услуг.



Данные.



Приложения, данные.



Что контролирует поставщик услуг?



Среду выполнения, операционные системы, виртуализацию, серверы, системы хранения и сети.



Среду виртуализации, физические серверы, аппаратные системы хранения данных, физические и логические каналы связи.




· Приложения, данные, среду выполнения, операционные системы, виртуализацию, серверы, системы хранения и сети.



Приложения, данные, среду выполнения, операционные системы, виртуализацию, серверы, системы хранения и сети.





Выбор того или иного вида сервиса определяет объём работ по настройке политик безопасности, которые необходимо выполнить клиенту в рамках своей зоны ответственности. Например, 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:

Примеры сегментов

Критерий сравнения




Сегмент Техносерв Cloud



Обычный (открытый)



Защищённый



Закрытый



Размещение систем, в которых обрабатываются сведения, составляющие коммерческую тайну клиента.



Подходит для размещения систем, к которым не предъявляются требования по ИБ или предъявляются минимальные требования по ИБ.



Да.



Да.



Размещение информационных систем персональных данных.



До 3-го уровня защищённости персональных данных включительно.



До 1-го уровня защищённости персональных данных включительно.



Размещение государственных информационных систем.



Нет.



До 1-го класса защищённости включительно.



Размещение систем, обрабатывающих сведения о переводах денежных средств и/или данные держателей банковских карт.



Да.



Нет.



Соответствие законодательству РФ.





Приказ ФСТЭК России от 18.02.2013 № 21 (3-й и 4-й уровни защищённости);


Payment Card Industry Data Security Standard (PCI DSS);


Положение Банка России от 09.06.2012 № 382-п;


Стандарт Банка России (СТО БР).



Приказ ФСТЭК России от 11.02.2013 № 17 (до 1-го класса защищённости включительно);


Приказ ФСТЭК России от 18.02.2013 № 21 (до 1-го уровня защищённости включительно).



Средства защиты.



На уровне инфраструктуры.



Сертифицированные и несертифицированные ФСТЭК/ФСБ России средства защиты.



Исключительно сертифицированные ФСТЭК/ФСБ России средства защиты.



Сертификация/


Аттестация.





Сертификат соответствия (в качестве сервис-провайдера) требованиям PCI DSS.



Инфраструктура сегмента аттестована на соответствие требованиям защиты информации, предъявляемым к государственным системам до 1-го класса защищённости включительно и системам персональных данных с уровнем защищённости до 1-го класса включительно.




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

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

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