Недавно одна обширная торговая сеть запустила программу лояльности. Команда Бастион участвовала в этом проекте в качестве консультантов по информационной безопасности, и это отличный повод поговорить о защите баз с персональными данными.
В этом посте расскажем, как работает 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 анализаторов, перевязываем ленточкой. То же самое с центром управления. При этом данные мониторинга попадают в единый веб-интерфейс и для пользователей системы ничего не меняется. Так что, когда программа лояльности вырастет, проблем с масштабированием не будет.
Установка Гарды БД
Гарда БД — коробочное решение. Ее можно установить и настроить за неделю, но это в теории. На практике много времени уходит на сопутствующие работы: сбор сведений об инфраструктуре, согласование общего технического решения, оформление документации. Обычно на установку системы уходит около месяца. Так получилось и в этот раз.
Впрочем, задержка сыграла нам на руку. Система реализует часть требований закона, но это все же практическое средство защиты, а не зонтик, которым прикрываются от регулятора.
К тому времени, как закончилось функциональное тестирование системы, мы как раз успели подготовить все остальное: обновили уже готовые документы, написали проектную документацию на систему, подобрали конфигурации ОС и СУБД, внедрили средства антивирусной защиты, которые необходимы по закону. Теперь и данные клиентов в безопасности, и Роскомнадзор носа не подточит.
