Причина проста. В банках и любых других организациях, оперирующих такой критичной информацией, как клиентские данные (в том числе персональные данные), обычно уделяют очень серьезное внимание распределению ролей пользователей. Что включает разграничение прав доступа как к данным, так и к функциональным возможностям той или иной бизнес-системы. Например, информация из CRM- (Customer Relationship Management — управление отношениями с клиентами) или АБС-систем, доступная одним сотрудникам, может быть не видна другим. Этими правами можно относительно легко управлять и иметь их актуальный перечень. Но ни одна информационная система и, что важно, СУБД, входящая в ее состав, не обходится без учетных записей привилегированных пользователей — это администраторы, разработчики, контрагенты. Учитывая максимально широкие права доступа этих групп лиц, крайне важна возможность мониторинга их действий.
Сложность в том, что не всегда запросы данных пользователей можно контролировать на сетевом уровне. Это может происходить как из-за возможности физического (локального) подключения к серверам БД, при наличии физического доступа в ЦОДы и серверные помещения, так и в случае подключения по протоколам удаленного доступа (RDP, SSH и так далее). Именно для контроля таких пользователей и типичных для них способов подключения используются агентские решения контроля доступа к базам данных.
Какие возможности для безопасности организации дают агенты?
Рассмотрим, как работают агентские решения и чем они могут быть полезны, на примере банковской сферы. Классическая система класса DAM (database activity monitoring) строится по принципу пассивного мониторинга обращений пользователей к базам данных. Контроль на сетевом уровне дает офицеру информационной безопасности возможность ответить на вопросы, кто сделал тот или иной запрос, когда он был сделан, что собой представлял запрос (это может быть чтение, удаление, изменение) и какую информацию получил пользователь из защищаемой системы.
В идеальных случаях офицер информационной безопасности в ретроспективе увидит ту же информацию, какую видел пользователь в своем веб-браузере или приложении. Большинство инцидентов в таком случае могут происходить по причине неправильно настроенных матриц доступа.
Сложность контроля активности привилегированных пользователей баз данных в том, что они не оперируют интерфейсом бизнес-систем, а обладают доступом непосредственно к «сырым данным», находящимся в базах. В большинстве случаев они хорошо представляют себе их структуру, понимают, в какие таблицы, колонки следует сделать запросы, чтобы получить нужную информацию в обход приложения.
Кроме этого, агентские решения часто помогают защищать базы данных, так как сетевые сегменты трафика невозможно получить другими средствами. Причины могут быть разными, к ним можно отнести:
- отсутствие сетевого оборудования, способного перенаправлять копию трафика на DAM-системы;
- широко используемые технологии виртуализации и построенные на их основе частные облака, когда к физическому оборудованию подсоединиться невозможно.
Принцип работы агентских решений
Внедрение любого дополнительного ПО на серверы баз данных ключевых бизнес-систем всегда имеет ряд сложностей. К ним можно отнести и потенциальное снижение производительности систем, и влияние агентского ПО на работоспособность защищаемой системы, и так далее. Разрабатывая агентские решения, входящие в состав системы защиты баз данных и веб-приложений «Гарда БД» от «Гарда Технологии» (входит в «ИКС Холдинг»), мы учитываем все эти моменты. Таким образом, дополнительная нагрузка на процессоры серверов баз данных по результатам различных тестов не превышает 5–7%, а необходимый объем оперативной памяти не выходит за пределы 2 Гбайт. С учетом архитектуры и принципа работы системы вся дополнительная нагрузка проецируется только на локальные запросы, так как именно их контроль ведется на более низком уровне.
Практика внедрения агентских решений отличается от пассивных решений. Агент — активное решение, так как он ставится непосредственно на оборудование заказчика. Поэтому для минимизации опасений со стороны заказчика необходимой практикой становится внедрение агентов на тестовые базы данных. Как правило, у крупных компаний есть такие тестовые стенды, которые по своей нагрузке и наполнению приближены к «боевым». Пилотные проекты дают клиенту уверенность в корректности работы решений, упрощая последующую эксплуатацию в реальных условиях.
Частый вопрос служб безопасности — как скрыть работу агентского ПО. Ответ прост, технически подкованный специалист может найти любой дополнительный модуль, внедренный на сервер базы данных, более того, часто в установке агентских решений задействованы именно администраторы БД. Другой вопрос в том, что в момент, когда что-то происходит с агентским решением, остановка или удаление сервиса, в службу безопасности поступает мгновенное оповещение как через электронную почту, так и через SIEM-систему (security information and event management). Таким образом получается оперативно отреагировать на отключение агента и выяснить причину произошедшего.
На текущий момент агентские решения АПК «Гарда БД» — это полнофункциональное решение, позволяющее контролировать как локальные, так и сетевые подключения ко всем популярным СУБД, установленные на серверы под управлением ОС семейства Red Hat, CentOS, Oracle Linux, Solaris, Windows Server, openSUSE, а также AIX. Как показывает практика, внедрение агентских решений даже в качестве дополнительного модуля позволяет контролировать действия пользователей на всех сегментах, формируя полноценную базу для ретроспективных расследований.
Практика применения агентов — взаимодействие с базами данных через локальные запросы. Выявление обращений к «спящим» счетам
В автоматизированной банковской системе заказчика хранится информация обо всех счетах, всех остатках по счетам и датах последних обращений по этим счетам. Обладая доступом к этой информации, нередко пытаются реализовать мошеннические схемы, такие как эта.
Злоумышленники выявляли счета, на которых хранилась крупная сумма денег, это депозитный пролонгируемый счет. То есть владелец редко обращался к нему для проведения каких-то операций. Имея доступ к информации по счету и данным его владельца, инсайдер — сотрудник банка — передавал их внешнему злоумышленнику для изготовления поддельных документов на имя владельца. Подставной человек приходил в банк и снимал деньги со счета. Сложность выявления и расследования подобного инцидента в том, что обращение законного владельца может произойти через длительный промежуток времени.
Внедрение системы защиты баз данных позволило отследить все обращения пользователей и помочь в расследовании текущего инцидента еще до обращения клиента.
В дальнейшем с помощью системы «Гарда БД» сотрудник службы информационной безопасности настроил политики, благодаря которым уже при первых несанкционированных попытках доступа к данным срабатывает оповещение системы. Это позволило оперативно выявлять и нивелировать последствия подобных инцидентов.
