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

В этом посте расскажем, как работает database activity monitoring, какие мощности нужны, чтобы анализировать гигабиты трафика на лету, и в чем внешний мониторинг превосходит встроенный.

Каждый месяц, а то и чаще, базы какой-нибудь крупной компании попадают в сеть. То Marriott упустит имена 5,2 млн клиентов, то из-за бага у DigitalOcean утекут платежные данные. Такой риск существует и в случае с программой лояльности, ведь в ней много ценного: ФИО и телефоны, адреса электронной почты и адреса доставки, даты рождения и списки покупок.

Если подобная база окажется в открытом доступе, парой гневных постов на Хабре дело может не закончиться. Все перечисленное — персональные данные, которые, согласно закону, требуют особого обращения. Мало защитить такую базу от утечек, вдобавок нужно выполнить массу формальных требований ФСБ, ФСТЭК и Роскомнадзора, подготовить кипы документации. И здесь важно понимать, что именно и как делать.

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

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

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

Как защищаются компании

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

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

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

Второй подход — раздельное хранение и обработка данных. Есть мнение, что если хранить, например, ФИО на одном сервере, а номера телефонов на другом, то можно выйти из-под действия 152-го Федерального закона и обойтись без оформления документации и установки дополнительных СЗИ. Так вот, это плохая идея.

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

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

Централизованная архитектура и грамотная система безопасности будут и проще, и надежнее.

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

Программа лояльности изнутри

Программа лояльности состоит из набора сервисов — это сайт и клиентское мобильное приложение, через которые можно делать заказы, а также интеграции с партнерами по доставке: Delivery Club, Яндекс.Еда и СберМегаМаркет.

Мобильные телефоны, ФИО и другие персональные данные с сайта, из мобильного приложения и от партнеров поступают в инфраструктуру ритейлера. СберМегаМаркет подключается напрямую к 1С, используя REST. Delivery Club и Яндекс.Еда отправляют их при помощи SOAP через отдельный шлюз.

Затем данные аккумулируются в базе Greenplum и по необходимости отправляются в Manzana. Это сервис для автоматизации и управления программами лояльности. Он нужен для подсчета баллов и выдачи скидок.

Как защищать базы данных

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

Неважно, что случилось: хакер проник через веб-сервер, администратор вынес базу на флешке, менеджер перед увольнением выписал в блокнот потенциальные сделки или сфоткал экран (от этого никакая DLP не застрахует) — это отслеживается на уровне доступа к базе. Поэтому во многие базы данных встроено логирование. Однако, это неоптимальное решение для нагруженных систем.

Контроль доступа встроенными средствами увеличивает нагрузку на базу. Взять аудит в Oracle Database. Он позволяет настраивать правила реагирования на доступ к определенным данным и оповещает об их срабатывании, но уже при настройке десятка правил производительность проседает.

По нашим подсчетам локальные мониторинги снижают ее на 10–40%, в зависимости от базы и типа запросов. Придется наращивать серверные мощности, а Oracle по ним лицензируется. В итоге мониторинг еще и влетит в копеечку.

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

Наконец, если с базой что-то случится, расследовать инцидент может быть невозможно.

Представьте себе такой случай: в одном банке перестал работать сервер базы данных. Его восстановили из резервной копии, но возникли подозрения, что его кто-то взломал. Вызвали специалиста из MS SQL. А тот говорит: «Зря вызывали. Вы все логи затерли, когда поднимали базу из бекапа»…

Поэтому мы считаем, что оптимальное решение — внешний мониторинг обращений к базам. Для этого мы развернули Гарду БД, инструмент, который используют в инфраструктуре банков и сотовых операторов, — гибрид DAM (Database Activity Monitoring) и DBF (Database Firewall).

Что умеет Гарда БД

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

Затем Гарда БД строит статистические профили пользователей и проводит поведенческий анализ (UBA).

Система запоминает, с каких адресов входит пользователь, какие компьютеры и приложения использует. А еще, какие базы он смотрит и сколько данных использует в работе.

Гарда БД засекает отклонения от профиля по различным параметрам, например, если обращения к базе поступают с нового компьютера, или сотрудник запрашивает данные клиентов из другого подразделения компании. А еще система сравнивает получившийся профиль с другими пользователями и находит аномалии — подозрительные действия и нетипичное поведение.

Например, пользователь просматривал 50 клиентов в неделю, но в этот раз смотрел уже 100. Или в среднем кассир-операционист 30 раз в день обращается к базе, но один из них делает это 130 раз.

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

Как это работает

Гарда БД состоит из пары серверов: анализатора трафика и центра управления, который объединяет хранилище с данными и веб-интерфейс. Они работают на CentOS и устанавливаются в сети заказчика.

Когда кто-то обращается к базе, TCP-поток, либо его копия отправляются на анализатор. Дальше в дело вступают слои декодеров. Они в режиме реального времени собирают из «сырых» данных сессию и вычленяют из нее запрос к базе данных. В результате получается выжимка, которая включает в себя текст запроса и различные переменные.

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

В Гарду БД встроен набор готовых правил, например, мониторинг массовых выгрузок или политика тотального перехвата. Она подразумевает сохранение всех запросов к базе данных. Однако, это только вспомогательный инструмент, основную защиту обеспечивают настраиваемые политики безопасности.

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

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

Интеграция в сеть

Гарда БД либо работает с копией трафика, либо устанавливается в разрыв. В первом случае система работает в режиме мониторинга, снимает трафик с сетевого узла, через который общаются приложения.

При установке в разрыв Гарда БД работает как сетевой экран, в режиме L3 reverse прокси. Она принимает SQL-запрос от пользователя, кладет в кеш, проксирует запрос в базу данных, получает ответ. Затем система сверяет данные с политиками безопасности и принимает решение — отправить пользователю ответ или разорвать соединение.

В случае с программой лояльности мы решили устанавливать Гарду БД в режиме мониторинга, а не в разрыв. Это оптимальный вариант для первой установки.

Интеграция системы мониторинга в сеть без учета Manzana

При установке в разрыв неправильные политики безопасности могут парализовать работу баз данных, а идеально настроить правила с первого дня работы системы сложно. Они сильно зависят от бизнес-процессов компании, а те еще не устоялись.

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

Зато Гарда БД в режиме сетевого экрана не только блокирует любые подозрительные запросы, но и позволяет разграничивать доступ пользователей к разным таблицам. Так можно реализовать ролевую модель на уровне всей сетевой инфраструктуры компании.

Железо

За фильтрацию запросов в режиме реального времени приходится платить высокими требованиями к железу.

Анализатор трафика, рассчитанный на 2 гигабита/с — это пара процессоров по 16 ядер, например Intel Xeon Gold 6226R, 256 ГБ оперативной памяти и, обязательно, сетевая карта на Intel i350. Требования к чипсету объясняются тем, что для работы анализатора необходима поддержка DPDK.

Центр управления загружает работой 24 процессорных ядра, 256 ГБ оперативки и внушительный дисковый массив, никак не меньше RAID6 емкостью 20 ТБ. Там разворачивается графовая база данных, разработанная специально под эту систему.

При входящем трафике в 2 гигабита/с этого хватает на год хранения данных. Дело в том, что TCP-поток записывается по правилам и не в сыром виде. Анализатор очищает трафик. Даже если активировать политику тотального перехвата, в хранилище центра управления поступает около 30% того, что приходит на анализатор.

Для проекта с ритейлером хватило всего пары серверов. По меркам 2021 года это ниже среднего. Обычно требуется обрабатывать 5–8 гигабит/с, а самый крупный заказчик, у которого ставили эту систему, прогоняет через Гарду БД 20 с лишним гигабит трафика в секунду.

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

Установка Гарды БД

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

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

К тому времени, как закончилось функциональное тестирование системы, мы как раз успели подготовить все остальное: обновили уже готовые документы, написали проектную документацию на систему, подобрали конфигурации ОС и СУБД, внедрили средства антивирусной защиты, которые необходимы по закону. Теперь и данные клиентов в безопасности, и Роскомнадзор носа не подточит.