Про котиков и единорогов: плюсы и минусы хранения информации в облаках

Как правило, компании хранят данные на своих серверах или частично размещают в облачных ресурсах. Мы в Whoosh все сделали по-своему и пользуемся исключительно облаками. Почему мы приняли такое решение, какие у него плюсы и минусы, рассказывает наш аналитик по информационной безопасности Анастасия Гайнетдинова.

При чем тут вообще котики и единороги? Начнем с единорогов, точнее, с единорога в облаках — это мы, Whoosh:) Звучит как шутка, но это чистая правда: в прошлом году мы вышли на IPO, а вся наша работа ведется на облачных серверах. Своего железа у нас нет.

Специалистов по ИТ и информационной безопасности, которые к нам приходят, это поначалу удивляет: а что, так можно было? У нас нет привычной «коробки комфорта» – того самого внутреннего контура, для которого выстраиваются знакомые эшелоны защиты, стандартные политики и типовые СЗИ.

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

Не всю информацию надо защищать одинаково. Более того, не каждый актив есть смысл защищать одинаково. Мы доверяем нашим котикам-разработчикам (почему назвала их котиками — объясню ниже). Да, у нас стоят меры защиты на каждом рабочем устройстве, но вся ключевая логика, все критичные активы находятся в облаках. Наш подход состоит в том, чтобы защищать не конкретную коробку, а именно активы — то, что для нас по-настоящему важно. И степень защиты зависит от уровня критичности.

Чем больше мы доверяем вендору и чем ниже критичность данных, тем больше информации можем доверить его защите. И наоборот: если информация очень ценная, мы усиливаем собственные меры безопасности. Так, защиту номеров банковских карт стоит продумать вплоть до физической архитектуры — например, на уровне гипервизора. Да, придется больше времени потратить на конфигурирование, разделение доступа и установку ОС — зато вы будете уверены, что все необходимые меры выполнены: и по требованию комплаенса, и по вашим собственным ощущениям.

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

Для менее критичной рабочей информации мы можем подняться до уровня приложений. Сюда относится, например, модель PaaS — платформа как сервис. В этом случае конфигурация приложений ложится на плечи вендора, а мы настраиваем только политики безопасности. Еще шажок выше — FaaS (функция как сервис): здесь мы полностью доверяем защите вендора, а сами лишь пользуемся удобной функцией. Продвижение по уровням вверх не означает, что защита уменьшается: просто на нижнем пороге доверия мы сами контролируем все, а на верхнем – полагаемся на меры безопасности вендора.

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

На что мы обращаем внимание при выборе вендора:

Что касается оценки рисков, для этого у нас есть два способа. Так, мы пользуемся релевантными статистическими данными, которые берем, например, из отчетов и аналитических записок коллег из Kaspersky Lab и Positive Technologies. Но если статистических данных не хватает, мы подключаем для анализа наших экспертов. Изначально такая оценка получается во многом эмпирической, но она дает точку отсчета для собственных наблюдений.

Здесь мы подошли к главному — зачем это все. Почему мы тратим время на поиск и проверку вендора вместо того, чтобы купить свои собственные сервера?

Конечно, все индивидуально для каждой компании, поэтому нужно рассчитывать бюджет и риски.

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

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

Напоследок вернемся к котикам. Помните, я обещала рассказать, почему так назвала разработчиков?

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

Вторая причина — котик просится за закрытую дверь не потому, что ему туда надо, а потому, что дверь закрыта. Это относится к теме блок-листов, стоп-листов, разрешенных списков и так далее. Поэтому у нас нет жестких ограничений, куда разработчикам можно ходить, а куда нет — в любом случае мы это видим. Если он куда-то идет — значит, ему туда надо. А если вы не понимаете, зачем, всегда можно спросить, почему именно туда и сейчас. К слову, отсутствие блок-листов – отличная мотивация, чтобы выстроить грамотный и полный мониторинг.

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

И еще один факт: у разработчиков иногда много энергии, а интересы не ограничены только лишь разработкой. И наша задача — направить эту энергию в нужное русло. Периодически возникают вопросы из серии «что будет, если…» Что, если в эту часть приложения поместить такие-то данные? Что, если поэкспериментировать с защитой и посмотреть, как она отработает при падении?