- PVSM.RU - https://www.pvsm.ru -
Гибридное облако образуется в двух случаях: у кого-то остался парк железа, который ещё надо самортизировать, либо же стоят какие-то уникальные серверы, которые невозможно закупить у облачного провайдера.
Самая частая ситуация — слияние-поглощение, когда вы купили конкурента, а у него куча старого, но ещё хорошего железа. А у вас уже облачный подход. Или когда вы настолько круты, что у вас есть P-машины IBM либо какие-то особенные хранилища (бывают у телестудий и медицинских центров). В любом случае вы столкнетесь с ситуацией, когда есть безопасники в облаке, есть департамент ИБ на вашей стороне и куча костылей — посередине.
По данным Garnter, есть вероятность 90 %, что вопрос переезда в облако коснётся вас в этом или следующем году, поэтому стоит задуматься над кибербезопасностью уже сейчас.
Ниже в статье — базовые вещи на тот случай, чтобы можно было легче договориться с провайдером о зонах ответственности и внедрить лучшие практики обеспечения информационной безопасности. Соответственно разделение зон ответственности и практики по ИБ мы используем в Техносерв Cloud для заказчиков с гибридными средами и потому знаем, что и где может пойти не так.
Потому что таких сделок всё больше и больше. С точки зрения архитектуры гибридные облака — это не лучшая история, с точки зрения бизнес-процессов — это временная замена полному переходу в облако, а с точки зрения ИБ — это больше хаоса и общения с подрядчиками. Но, по данным Gartner, к 2020 году около 90 % организаций примет возможности управления гибридной инфраструктурой. В этом году многие доминирующие поставщики облачных услуг предприняли шаги по расширению своих гибридных и мультиоблачных предложений — ещё один явный признак того, что рынок готов и ждёт спроса.
Провайдер защищает инфраструктуру облака, на базе которой работают предлагаемые сервисы. Эта инфраструктура состоит из аппаратного и программного обеспечения, сетей и объектов, на базе которых работают облачные сервисы. Ответственность клиента зависит от сервиса. Ниже в таблице — небольшое сравнение по четырём моделям предоставления сервиса:
PaaS
|
IaaS
|
SaaS
|
DaaS
|
|
Безопасность
|
· Заказчик облачных услуг привязан к предоставляемой платформе. · Выбор СЗИ ограничен и лежит на облачном провайдере. · Заказчик может настраивать функции защиты приложений.
|
Заказчик облачных услуг может использовать любые средства защиты информации, устанавливаемые на предоставляемую аппаратную платформу.
|
· Заказчик облачных услуг не имеет возможности выбора средств и механизмов защиты облака. · Выбор СЗИ лежит на провайдере облачных услуг.
|
· Заказчик может настраивать функции защиты приложений. · Выбор СЗИ ограничен и лежит на облачном провайдере.
|
Что контролирует заказчик?
|
· Данные, приложения. · Клиент должен запрашивать регулярные отчёты о безопасности у своего поставщика облачных услуг и обеспечить понимание того, как эти данные должны быть защищены.
|
· Данные, приложения, среду выполнения, операционные системы, виртуальную инфраструктуру (виртуальные машины, сети, вычислительные ресурсы). · Заказчик должен разработать и регулярно тестировать процедуры реагирования на инциденты, которые основаны на совместной ответственности между клиентом и облачным поставщиком услуг.
|
Данные.
|
Приложения, данные.
|
Что контролирует поставщик услуг?
|
Среду выполнения, операционные системы, виртуализацию, серверы, системы хранения и сети.
|
Среду виртуализации, физические серверы, аппаратные системы хранения данных, физические и логические каналы связи. |
· Приложения, данные, среду выполнения, операционные системы, виртуализацию, серверы, системы хранения и сети.
|
Приложения, данные, среду выполнения, операционные системы, виртуализацию, серверы, системы хранения и сети. |
Выбор того или иного вида сервиса определяет объём работ по настройке политик безопасности, которые необходимо выполнить клиенту в рамках своей зоны ответственности. Например, IaaS потребует выполнения большинства настроек безопасности и задач управления виртуальной инфраструктурой. Клиенты, которые развёртываются в IaaS, отвечают за управление гостевой операционной системой (включая установку обновлений и исправлений безопасности), управление приложениями или сервисными компонентами, установленными в виртуальной инфраструктуре, и за настройку брандмауэра (группы безопасности), предоставляемого IaaS. В PaaS провайдер управляет уровнем инфраструктуры, операционной системой и платформой, а клиенты получают доступ к конечным точкам для хранения и извлечения данных. Клиенты отвечают за управление своими данными (включая параметры шифрования), классификацию своих ресурсов и использование различных инструментов для применения соответствующих разрешений.
Существенно ничего, модель угроз та же самая, только ответственность размазана между двумя отделами ИБ двух компаний — облачным и «домашним». Гибридные среды создаются по мере того, как компании переходят от чисто локальных решений к средам с несколькими облачными вычислениями. Сохраняются локальные приложения. Любая облачная безопасность основана на модели совместной ответственности, когда поставщик отвечает за безопасную и надёжную инфраструктуру, а клиент отвечает за безопасность своих активов в облаке.
Но именно при использовании гибридных облаков особенно видны точки стыков этих зон ответственности. Развёртывание средств контроля безопасности данных, передаваемых между облачными и локальными системами, может быть довольно сложным из-за собственных 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.
Автор: TS_Security
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/virtualizatsiya/353613
Ссылки в тексте:
[1] Источник: https://habr.com/ru/post/504528/?utm_source=habrahabr&utm_medium=rss&utm_campaign=504528
Нажмите здесь для печати.