Разделяемая ответственность (shared responsibility). На стороне облака

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

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

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

Разделяемая ответственность
Ответственность провайдера и клиента различается в зависимости от модели использования облачных сервисов (IaaS — инфраструктура как услуга, PaaS — платформа как услуга, SaaS — программное обеспечение как услуга) и имеющихся у облачного провайдера защитных механизмов и политик: возможностей соблюдения законодательства, стратегии управления рисками, модели угроз и других факторов.


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

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

При использовании управляемых сервисов (PaaS/SaaS) забот у конечного пользователя становится гораздо меньше, так как провайдер уже обеспечивает защиту компонент PaaS/SaaS-сервисов. Например, в случае Yandex Managed Service for ClickHouse провайдер защищает виртуальные машины сервиса, выполняет резервное копирование базы данных и шифрует пользовательские данные. В то же время клиент обязан классифицировать данные, обеспечить разграничение доступа к данным, настроить процессы для их защиты, а также отвечает за управление своими пользователями и конечными устройствами.

Безопасность на стороне Yandex.Cloud
С одной стороны, распределение ответственности удобно для клиентов. Им нужно меньше заботиться о безопасности, в сравнении с защитой системы при ее расположении на собственных мощностях. С другой стороны, данные и система все еще принадлежит конкретному клиенту, поэтому он не может безоглядно доверять провайдеру, просто полагаясь на его заверения. Точнее, все зависит от уровня экспертиз в части безопасности, которая есть (или нет) у конкретного клиента. Если такая экспертиза находится на зрелом уровне, то компания в состоянии оценить риски, уточнив особенности защиты на стороне провайдера и изучив определенные подтверждения рассказам провайдера (например сертификаты соответствия). Для удобства клиентов, Yandex.Cloud публикует определенную информацию о некоторых аспектах информационной безопасности платформы. Также мы всегда открыты для общения в режиме 1-1 для обсуждения деталей.

Яндекс обеспечивает безопасность облачной платформы на следующих уровнях:

• Безопасность дата-центров
• Безопасность инфраструктуры
• Защита на уровне данных
• Соответствие стандартам
• Безопасность дата-центров

ЦОДы можно считать фундаментом облачной платформы. Все серверные ресурсы Yandex.Cloud располагаются в собственноручно спроектированных и построенных дата-центрах на территории России, которые связаны собственными каналами связи. Это позволяет команде обеспечивать соответствующий уровень безопасности, включая необходимые параметры надежности. Кстати, о надежности наших ЦОДов мы уже рассказали первой статье серии. Меры безопасности в дата-центрах соответствуют лучшим практикам и включают в себя процедуры контроля доступа, видеонаблюдение и регламенты замены оборудования, реализующие процедуры очистки носителей с данными клиентов.

Безопасность инфраструктуры
В основе безопасности инфраструктуры облачной платформы Yandex.Cloud — разделение и изоляция ресурсов. Критичные с точки зрения безопасности сервисы запускаются под управлением виртуальных машин на отдельной группе физических хостов, на которой не запускаются пользовательские виртуальные машины. Все административные виртуальные машины запускаются в физически или логически изолированных сетях, а корпоративная сеть провайдера отделена от сети облачной платформы.

Безопасность физических машин и сервисных виртуальных машин обеспечивается на нескольких уровнях: используется ряд межсетевых экранов, а также дополнительные средства защиты (AppArmor, Seccomp, Osquery 4 и система мониторинга и оповещения о подозрительном поведении).

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

Защита данных. SDLC и defence in depth. Шифрование
Безопасность Yandex.Cloud организована таким образом, что одной угрозе противостоит набор средств защиты на разных уровнях. Такой подход удорожает любую потенциальную атаку и позволяет оперативно выявлять и предотвращать деятельность злоумышленников. Техническая команда платформы соблюдает процесс безопасной разработки (security development lifecycle, SDLC), выстраивая основу безопасности облачных сервисов с самых ранних этапов проекта. Дополняющая эти базовые принципы концепция эшелонированной обороны (defense in depth) обеспечивает многоступенчатую защиту, которая препятствует действиям злоумышленников и способствует раскрытию их деятельности еще при подготовке атаки.

Для шифрования разработаны несколько уровней:

• Шифрование на уровне storage.
• Шифрование на уровне баз данных Yandex Database. Данные шифруются непосредственно перед отправкой в storage.
• Шифрование резервных копий данных в Managed Services for Databases (MDB). Все резервные копии, создаваемые MDB, шифруются перед отправкой в постоянное хранилище.
• Шифрование данных при передаче.

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

Стандарты и законы
Как уже обозначалось выше, соответствие стандартам необходимо по двум причинам:

• Это перепроверка самих себя и возможность подтвердить определенные тезисы в части безопасности клиентам.
• Предоставление возможности клиентам приведения в соответствии (например, с 152-ФЗ или PCI DSS) их систем, при размещении в облаке.

В начале 2020 года Yandex.Cloud стала первой в России и СНГ публичной облачной платформой, выстроившей управление информационной безопасностью по стандарту ISO/IEC 27017:2015 и обеспечившей защиту персональных данных пользователей по международному стандарту ISO/IEC 27018:2019. Соответствие платформы требованиям международных нормативных документов подтверждено независимым аудитором — Британским институтом стандартов (BSI). Таким образом, наша платформа соответствует требованиям трех международных стандартов информационной безопасности: ISO/IEC 27001:2013, ISO/IEC 27017:2015, ISO/IEC 27018:2019.

В конце 2020 года Yandex.Cloud получила сертификат соответствия PCI DSS 3.2.1. PCI DSS содержит набор требований для защиты данных держателей карт. Так как требованиям стандарта соответствуют как ЦОДы, так и облачные сервисы, клиенты получили возможность размещать в облаке платежные шлюзы и другие системы, обрабатывающие данные платежных карт.

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

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

Заключение
Мы рассказали про аспекты безопасности, за которые отвечает Yandex.Cloud. В следующей статье мы расскажем про возможности обеспечения безопасности, которые есть у клиентов.