Как защитить данные ваших клиентов в облаке: чек-лист для компаний
Привет! Меня зовут Андрей Иванов, в Yandex.Cloud я отвечаю за развитие сервисов ИБ. В этой статье расскажу, какие ошибки компании часто совершают при миграции в облако и как их не допустить. Спойлер: придется перестать перекладывать все решения на безопасников.
Справка: чем облако отличается от дата-центра
В дата-центрах под каждого клиента выделяется отдельный сервер или стойки. Обслуживание на стороне клиента, при этом арендованные мощности часто не используются полностью. Поэтому для многих компаний дата-центры невыгодны.
Публичное облако предоставляет различные сервисы на базе единой технологической инфраструктуры. Сама инфраструктура располагается в дата-центрах, но в данном случае обслуживание лежит на облачном провайдере. Он же распределяет данные по этой инфраструктуре, гарантируя, что системы разных клиентов изолированы друг от друга.
Как компании выбирают провайдера сейчас
В большинстве российских компаний отношения между бизнесом и безопасниками построены неправильно: бизнес передает полный контроль службе ИБ и лишь получает от нее инструкции вида: «можно» или «нельзя».
Такая система сложилась 10-15 лет назад и серьезно устарела. Безопасники, чувствуя груз ответственности, ввели множество требований, часть которых уже не актуальна. Они не всегда разделяют важные и не важные бизнес-данные и в итоге применяют жесткие ограничения ко всей корпоративной информации, в том числе запрещают перенос данных в облако.
Как лучше выбирать провайдера
В идеале бизнес должен быть вовлечен в оценку безопасности облачной платформы. Ведь никто лучше бизнеса не знает ценность тех или иных данных и потенциальный урон, если с ними что-то случится.
Отдел ИБ должен оценить важность данных, которые будут переноситься в облако, обозначить риски, объяснить какой моделью угроз они руководствовались, и, исходя из этого, обозначить для бизнеса условия, на которых можно пользоваться облачными сервисами. В зависимости от провайдера эти условия могут различаться. А бизнес должен принимать финальное решение о том, использовать ли облако и какое.
Что нужно оценивать при выборе облачного провайдера
1. Доверие к бренду на рынке
Это не значит, что не стоит работать с малоизвестными провайдерами. Просто проверять их надо тщательнее.
2. Расположение серверов и стоек
От того, в России они или нет, зависят трудозатраты при переходе в облако и вообще возможность этого перехода.
3. Меры безопасности, которые провайдер предлагает для защиты вашей системы
Они различаются в зависимости от системы, которую клиент переносит в облако. Это могут быть просто данные, которые компания держит в хранилище, или сложная отказоустойчивая система, распределенная по всем availability-зонам провайдера. В случае, когда клиент использует облачное хранилище, его безопасность обеспечивает провайдер, но доступ к данным контролирует клиент, поэтому важно понять, насколько гибкие и удобные настройки по управлению доступом предлагает провайдер. При размещении в облаке системы со сложной архитектурой, требования к наличию в облачной платформе различных инструментов безопасности возрастают.
Например, компания поднимает в облаке виртуальную машину. У нее есть внешний IP-адрес, который смотрит в интернет. Нужно узнать, есть ли у провайдера средство, ограничивающее доступ к виртуальной машине. У нас это встроенный межсетевой экран Security Group.
Если же у провайдера нет необходимых для защиты инструментов — оцените, можете ли вы обеспечить безопасность другими средствами. В примере с виртуальной машиной клиент может с помощью локального файрвола запретить доступ откуда угодно и разрешить его только с конкретных ресурсов. И тут нужно понять, удобен ли для вас такой подход. Если нет — ищите другого провайдера.
4. Формальное соответствие требованиям законодательства в области персональных данных
Сюда относятся требования законодательства в области персональных данных, например, ФЗ-152, и обязательные индустриальные стандарты, такие как ГОСТ 57580. Если облачный сервис обеспечивает формальное соответствие — клиенту придется совершать примерно на 30% меньше шагов для обеспечения соответствия системы. При использовании собственной инфраструктуры он должен сначала приводить в соответствие саму инфраструктуру и прикладную часть размещенных в ней систем. Если же провайдер уже обеспечил соответствие инфраструктурной части, то на клиенте остаются организационные моменты, такие как согласие на обработку персональных данных, подписание документов и защита своей прикладной части.
В зависимости от сложности системы это будут разные трудозатраты. Расскажу на нашем примере: если вы используете только облачное хранилище, то кроме организационной части вам не надо ничего делать — данные в нем защищены со стороны. А если вы переносите в облако более сложную систему, которая использует такие сервисы, как Yandex Compute Cloud или Yandex Managed Service for PostgreSQL, то вам нужно будет обеспечить формальное соответствие внутри прикладной логики своих систем, использующих эти сервисы, и своего кода.
Если же провайдер не выполняет требования формального комплаенса, то, размещая систему в его облаке, компания не будет соответствовать требованиям законодательства по работе с персональными данными.
5. Другие сертификаты
Это не обязательный пункт, но если у провайдера есть сертификаты — значит, он перепроверяет себя и повышает зрелость процессов и инструментов защиты. К наиболее известным в России сертификатам в этой сфере относятся:
ISO 27001
ISO/IEC 27017:2015
- ISO 27018:2019
- CSA-матрица
Удобнее всего подготовить для оценки провайдера чек-лист, учитывая специфику облачных сервисов. Список вопросов можно составлять, опираясь на требования международных сертификатов. Далее вы либо предлагаете провайдеру ответить на вопросы из чек-листа, либо запрашиваете сертификаты. Если они есть, тогда сертификаты и подтверждают соответствие всем пунктам чек-листа — этот вариант проще для бизнеса.
Чем защита данных в облаке отличается от защиты в локальной инфраструктуре
Глобально, как и при защите информации внутри своей инфраструктуры, при защите облака служба безопасности должна следить за тремя главными параметрами:
Конфиденциальность
Целостность
- Доступность
При этом в облаке есть специфические средства безопасности. Новые и не всегда привычные инструменты ИБ из облака придется изучить, понять логику их работы и встроить в свои процессы. К таким, например, относится сервис Identity and Access Management (IAM) — без него работа с облаком невозможна.
Еще при внедрении облачных решений очень важно следить за распределением ролей. В локальной среде некоторых компаний привыкли полагаться на файрволы, считая их «божественным забором», который защищает ото всего. На самом деле это давно не так, но, конечно, до определенной степени файрволы страхуют: вытащить сервис из локального периметра вовне непросто. А в облаке это можно сделать в пару кликов, имея определенную роль. Служба ИБ должна понимать, что выдача излишних ролей может привести к тому, что разработчики или администраторы смогут открывать свои ресурсы вовне, класть туда данные, что в конечном счете приведет к утечке.
При работе с облаком есть разделение ответственности. Компании привыкли, что при аутсорсе линию разделения ответственности можно двигать. В случае с облаком кто за что отвечает зависит не от желания компании, а от того, какими облачными сервисами она пользуется. Разделение ответственности различается в зависимости от модели использования облачных технологий (IaaS — инфраструктура как услуга, PaaS — платформа как услуга, SaaS — программное обеспечение как услуга).
Покажу на нашем примере:
Страшные истории или инциденты
Связанные с облаками инциденты ИБ зачастую связаны с ошибкой на стороне клиента, которая приводит либо к утечке данных, либо ко взлому. При этом хакеры атакуют не инфраструктуру облака — это слишком сложно и дорого — а инфраструктуру клиента, расположенную в облаке. Если она недостаточно защищена, то злоумышленник сначала проникает в облако клиента, а потом по VPN-тоннелю попадает в локальную инфраструктуру — от этого не спасут локальные файрволы, если они блокируют только трафик извне.
Конкретный пример: компания тестировала облако и завела в нем несколько виртуальных машин, которые не были доступны извне. Она работала с этими машинами через VPN из своей инфраструктуре. Но кто-то из сотрудников назначил на одну машину внешний IP-адрес, а на ней по неудачному стечению обстоятельств был необновленный софт. В результате машину быстро взломали, а поскольку она была соединена VPN-каналом с локальной инфраструктурой — злоумышленники проникли и туда. На этом этапе подозрительную активность засекли безопасники и остановили дальнейшее проникновение.
Если следовать распространенному принципу минимальных привилегий, то при изначальной настройке надо было сделать так, чтобы кто угодно не мог назначать внешний IP-адрес на машину. Этот процесс должен согласовываться внутри. Второй момент: нужно оценивать состояние машин, которые заводятся в облако, и следить, чтобы они покрывались процессом управления уязвимостями (vulnerability-менеджмент), — в идеале, даже если это тестовые машины.
Если инцидент ИБ все же случился — важно быстро на него среагировать. И для этого тоже стоит учесть особенности работы в облачном окружении, встроив их в собственный процесс управления инцидентами. При переходе в облако появляется часть инфраструктуры, которую компания не контролирует, поэтому надо знать, к кому обращаться на стороне провайдера в случае инцидента, какие вопросы задавать, каких действий требовать.
Хотя в российской практике выбор облачного провайдера сильно зависит от отдела ИБ, бизнесу стоит погружаться в процесс, анализировать аргументы безопасников и, в свою очередь, помогать им, определяя важность данных, которые планируется перенести в облако, и связанные с этим бизнес-риски. А безопасности, после выбора провайдера, надо не забыть «учесть» новую инфраструктуру в текущих внутренних регламентах по защите данных. Такой подход поможет выбрать надежный облачный сервис и пользоваться удобными инструментами, не жертвуя безопасностью.
Подписывайтесь на блог Yandex.Cloud, чтобы узнавать еще больше новостей и историй об IT и бизнесе.
Другие истории, которые активно читают наши подписчики: