Mind the cloud: готовы ли службы безопасности к новым реалиям бизнеса

Исторически задача DLP-систем связана с предотвращением утечек данных, т.е. их несанкционированного вывода за охраняемый периметр.

Начало двухтысячных годов, я учусь на четвертом курсе физического факультета. На ежегодном праздновании «дня Физмата» два моих однокурсника разыгрывают на сцене шуточный диалог. Один из них сидит за партой с книгой, а второй задает ему вопрос:

— Что ты читаешь?
— Кванты’! (учебник по квантовой физике)
— А почему вверх ногами?
— А какая разница?

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

В литературе этот прием, которым автор пытается описать и совместить совершенно противоположные понятия, называется оксюморон. Он встречается нам куда чаще чем можно представить; в названиях книг — «Конец Вечности», «Горячий снег», фильмов — «Правдивая ложь», «Обыкновенное чудо» и даже в музыке — «Led Zeppelin». Интересно, что и в мире информационных технологий и безопасности мы тоже сталкиваемся с этим приемом, и словосочетание «облачный DLP» — самый яркий тому пример.

Исторически задача DLP-систем связана с предотвращением утечек данных, т.е. их несанкционированного вывода за охраняемый периметр. Безопасники умеют анализировать информационные потоки, выделять узлы обработки, хранения и передачи информации. С этой информацией на руках уже можно обозначить периметр, как правило, ограниченный сетевыми устройствами, и совместно с ИТ службами сформировать и настроить сетевые доступы. С рабочими станциями работает немного другой подход. Технически каждая рабочая станция может послужить точкой утечки информации. Значит для того, чтобы ее предотвратить, нам нужно контролировать рабочую станцию. Ставим агента, настраиваем его согласно существующей модели угроз… Впрочем, вы и сами все это прекрасно знаете и проходили уже не раз. И все бы ничего, если бы не бизнес не использовал так активно облачные технологии.

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

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

Решение, которое лежит на поверхности, — попробовать распространить существующие практики защиты и контроля на новые ИТ-активы — облачные сервисы. И начать в первую очередь хочется с DLP как наиболее знакомого инструмента, приемы работы с которым уже отработаны и выверены. Силами контроля трафика на «старом» периметре уже не обойтись. Облачные сервисы помимо их сумасшедшего SLA и отсутствия расходов на поддержку обладают еще одним плюсом: они доступны откуда угодно. И будьте уверены, бизнес будет пользоваться этой прекрасной возможностью на полную катушку. Использование облачной почты сотрудниками в полях — это мелочи по сравнению с тем, что менеджеры по продажам будут работать с облачным CRM-решением из интернет-кафе сразу после встречи с клиентом (хорошо, если через VPN и 4G канал). Неделя за неделей, и вы начнете понимать, что статистика использования облачного сервиса показывает рост сессий и трафика, а на корпоративном прокси-сервере вы этого не видите.

Именно в этот момент на горизонте начинает маячить уже упомянутый в начале статьи оксюморон «облачный DLP». Давайте обозначим, как можно трактовать этот термин.

Вариант первый. Размещение.

Если DLP система, точнее, ее аналитическое ядро и подсистема хранения развернуты в облаке, это уже позволяет называть ее «облачной». С учетом того, что кроме публичных облаков на рынке полно гибридных и частных, знак вопроса о существовании такого типа решений автоматически снимается. Никто не мешает разместить основную часть DLP-системы в ЦОДе группы компаний или провайдера услуг информационной безопасности и использовать DLP как сервис, из облака. Решение вопроса с доверием к тому, где расположена система, обеспечивает либо управляющая компания, либо репутация, уровень доверия и официальные документы, предоставляемые сервис-провайдером.

Вариант второй. Контроль данных.

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

«Постойте, — остановит меня эксперт, много лет работающий с DLP системами, — но в случае с облачной почтой, например, Exchange Online, я могу настроить пересылку сообщений себе или на служебный почтовый ящик и анализировать корреспонденцию как и прежде!» И в этом эксперте сразу можно будет узнать человека, который хорошо знает свое дело, но не плотно работает с облачными сервисами и технологиями. Тот же самый Exchange Online в случае отправки сообщений с вложениями (порог может быть настроен гибко) может физически прикладывать к тексту сообщения не сам отправляемый файл, а ссылку на его копию, которую он сохраняет в сервисе OneDrive. Что эксперт-аналитик, что DLP-система увидят не то, что реально отправляется, а только ссылку на корпоративный OneDrive. Чтобы понять, что конкретно отправляет сотрудник наружу, придется «лезть» в хранилище, скачивать оттуда документ, да еще и как-то поддерживать в аналитической системе «связку» между этим файлом и соответствующим электронным письмом.

Этот кейс — один из примеров, подтверждающий, что без честного взаимодействия DLP с облачными сервисами или с их доверенными посредниками (CASB, cloud access security broker) искомую задачу не решить.

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

Представьте себе ситуацию, в которой сотрудники компании используют, например, Exchange Online, а DLP система, развернутая внутри защищенного периметра компании, получает копию почтового трафика. Также пять сотен сотрудников активно используют, например, Dropbox, корпоративный облачный мессенджер, систему контроля версий кода GitHub и десяток других севисов. И это только официально. Скажете, что ситуация нереальна? Опрос, который сейчас проходит на ресурсе shadow-it.ru показывает, что:

15% опрошенных считают, что в их компаниях только официально используется от 10 облачных сервисов.

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

Вы скажете, что облачные сервисы не касаются именно вашей компании? Но посмотрите на список Топ-5 облачных сервисов, которые, по мнению опрошенных, используются в их компании:

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

Вернемся к истории c несколькими облачными сервисами, трафиком и вопросом «где размещать DLP». Если DLP развернута внутри инфраструктуры владельца системы, то каждый гигабайт данных, отправленный в облако пользователями, будет скачиваться для анализа центральным офисом, а это вызовет увеличение объема трафика минимум в два раза. Скажете, что трафик не так уж дорог? Возможно и так, но не забывайте о стоимости сетевого оборудования, нагрузка на которое тоже увеличится, а также о качестве запасного канала связи (failover), который нужно будет держать в холодном резерве. Если же DLP-система размещена в облаке, то вопрос нагрузки на интернет-канал если и не снимается сразу, то становится гораздо более управляемым.

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

Ваш голос учтён!

нравится

не нравится

Рейтинг:

5

Всего голосов: 9

Новые материалы в Test:

Kaspersky: какие кибератаки ждут промышленные предприятия в 2021 году   // 07 декабря

Кибершпионаж, шифровальщики: Group-IB исследовала киберугрозы 2020 года   // 25 ноября

Обзор рынка платформ и сервисов киберразведки (Threat Intelligence) в России и в мире   // 03 июня

Посмотри в глаза малвари. Гайд по работе с вредоносными файлами для новичков   // 02 декабря