Процесс развертывания IBM Guardium Database Activity Monitoring в розничном банке подтвердил: создать работающую для конкретного заказчика политику сразу после развертывания системы нереально, она рождается на протяжении некоторого времени после ввода системы в строй совместными усилиями ИБ-отдела заказчика, ответственных специалистов и внешнего консультанта. Автор поделился опытом внедрения IBM Guardium Database Activity Monitoring и своими инсайтами.
- Введение
- Первый опыт внедрения IBM Guardium Database Activity Monitoring
- 2.1. Топология проекта
- 2.2. Принципы выстраивания архитектуры
- 2.3. Поиск аномалий
- Выводы
Введение
Финансовые организации — особенный тип заказчиков с точки зрения провайдера услуг кибербезопасности. Абсолютно каждое решение, предлагаемое им внешними консультантами, проходит двойной контроль. С одной стороны, ему надо вписаться в отраслевые стандарты защиты данных. С другой — что сложнее — понравиться специалистам отдела ИБ и не поссориться со специалистами департамента ИТ. Я расскажу историю внедрения IBM Guardium Database Activity Monitoring и дам несколько рекомендаций, которые могут оказаться небесполезными для читателей Anti-Malware.ru. Этот инструмент помог определить неочевидные бреши в безопасности баз данных, снизить нагрузку на инфраструктуру и быстро «накрывать» действующими политиками безопасности каждую из вводимых строй баз данных. Собственно, за всё это он и любим специалистами заказчика.
Первый опыт внедрения IBM Guardium Database Activity Monitoring
Первый опыт внедрения IBM Guardium Database Activity Monitoring команда «Инфосекьюрити» получила, что называется, в боевых условиях. Крупный коммерческий банк привлек нашу компанию на проект по приведению в порядок процессов, связанных с обеспечением безопасности конфиденциальной информации, хранящейся в различных автоматизированных банковских системах (АБС) заказчика. Информация хранилась в многочисленных базах данных, к которым, в свою очередь, имели доступ разнообразные приложения, и всё это контролировалось лишь фрагментарно со стороны ИБ.
Нельзя сказать, что до проекта нормативные требования и стандарты безопасности (например, PCI DSS) выполнялись банком лишь формально, но пробелов в соблюдении норм ИБ-стандартов хватало. В основном они были связаны с технологическими и ресурсными ограничениями. Например, при включении объектного мониторинга баз данных производительность БД в некоторых случаях падала настолько, что «отваливалась» функциональность бизнес-критичных приложений. Найти индивидуальный подход к каждой АБС, которая обрабатывала и хранила конфиденциальную информацию и требовала мониторинга, было нереально — баз данных у заказчика слишком много, они разных типов и работают на разных платформах. Требовалось технологичное решение, которое будет одинаково эффективно для всего «зоопарка» БД. При этом оно не должно оказывать существенного влияния на производительность инфраструктуры, в которую внедрялось.
Совместно с ДИБом банка мы сформировали цели проекта:
- Мониторинг и аудит всех действий с данными БД.
- Выполнение требований стандартов ИБ для БД (ЦБ РФ, PCI DSS и др.).
- Применение политик безопасности в режиме реального времени.
- Создание централизованного унифицированного хранилища данных аудита БД.
- Реагирование в режиме реального времени на попытки взлома и компрометации БД.
- Защита данных от несанкционированного доступа.
Поскольку проект виделся достаточно масштабным и подразумевал вовлечение целого ряда команд, находящихся в составе ИТ-департамента заказчика, мы составили план внедрения решения. Согласно плану, помимо отдела ИБ и отдела поддержки баз данных, предполагалось участие в проекте подразделений, обеспечивающих работоспособность бизнес-приложений — именно они выдвигают высокие требования по доступности БД и бесперебойности работы бизнес-приложений, которые эти БД обслуживают. План содержал типовую архитектуру решения и коротко объяснял, какие компоненты она содержит и как работает, что было очень полезно на этапах согласования подключения к разворачиваемой системе очередных критически-важных БД заказчика.
Топология проекта
На сервере БД устанавливается агент S-TAP. Он работает на уровне операционной системы БД, в процессе установки в большинстве инсталляций не требует прерывания сервиса и в том числе умеет «слушать» локальный и зашифрованный трафик, что являлось основным доводом использования агентского подхода, а не зеркалирования трафика, поступающего в БД с сетевого коммутатора. Агент создает копию трафика и направляет данные в коллектор, который представляет собой отдельный сервер, обрабатывающий полученный трафик от агента в соответствии с политиками, примененными к конкретной БД.
Данные, обработанные в коллекторе, собирает и консолидирует агрегатор. Он необходим для централизованного управления коллекторами и является местом сбора и обработки событий и нарушений политик безопасности, выявляемых на разных БД и подключенных к разным коллекторам. Это позволяет отслеживать и выявлять распределенные атаки и попытки нарушений политик ИБ, а также строить консолидированные отчеты.
Коллектор и агрегатор не предназначены для долговременного хранения данных, в случае такой необходимости собранные логи направляются во внешнее хранилище. При помощи встроенного алгоритма IBM Guardium данные, направляемые для долговременного хранения, эффективно сжимаются и хранятся в зашифрованном виде. Эта функциональность позволяет быстро восстановить данные из архива с помощью встроенных средств агрегатора и иметь оперативный доступ к историческим данным для возможности анализа событий, произошедших в более ранние периоды времени.
Система управляется фирменной консолью IBM Guardian. Это веб-клиент, через который администратор следит за статусом системы, управляет политиками ИБ и глобальными настройками компонентов системы в режиме реального времени, производит детальный анализ выявленных инцидентов и формирует необходимую отчетность. Через консоль можно настроить интеграцию с SIEM-системой, развернутой на предприятии, и представить IBM Guardium Database Activity Monitoring как один из источников данных.
Изначально заказчик считал, что у него есть исчерпывающее представление о количестве систем, где обрабатываются и хранятся критически важные данные, и которые, соответственно, надо контролировать. В его понимании, это «продуктивные» серверы и серверы горячего резерва (они же — standby). Но на этапе развертывания выяснилось, что конфиденциальные данные также содержатся и в тестовых средах, требования к которым с точки зрения ИБ были существенно ниже. В итоге тестовые БД большинства критически важных систем заказчика также были добавлены в список целевых контролируемых баз данных разворачиваемой системы, поскольку в большинстве случаев ответственные за выпуск новых релизов обычно не занимаются защитой конфиденциальных данных на тестовых серверах, а процесс маскирования таких данных достаточно сложен и во многих случаях нереализуем технически. По большинству систем заказчика маскировать данные не представлялось возможным, поскольку этот процесс представлялся трудоемким, а в некоторых системах приводил к бесполезности тестовой среды и невозможности ее использования.
Принципы выстраивания архитектуры
Вернемся немного назад — к принципам, по которым мы выстраивали архитектуру системы.
Первый принцип. Распределение коллекторов к подключаемым БД должно выполняться с учетом оптимизации нагрузки на сеть. Выше я говорил, что агент зеркалирует трафик на коллектор. И чтобы не создавать дополнительную нагрузку на сеть, коллектор надо располагать в том же сегменте сети, что и сама БД. И тогда взаимный сетевой обмен не будет забивать каналы связи между разными площадками, на которых функционирует совокупность информационных систем заказчика, что особенно важно при подключении высоконагруженных БД.
Второй принцип. Изначально подразумевалось, что для управления коллекторами будет использоваться один агрегатор. На этапе развертывания оказалось, что разные базы данных, содержащие разные типы конфиденциальной информации, находятся в разных сетевых сегментах, которые технологически изолированы. Поэтому для сегмента PCI DSS мы предложили выделить отдельную замкнутую инсталляцию системы (коллекторы и агрегатор). Административный доступ к ним осуществляется по защищенным каналам и с использованием специальных инструментов — например, контролируемых джамп-серверов. Для остальных баз данных вне сегмента PCI DSS используются отдельные коллекторы и отдельный агрегатор, не связанные с коллекторами и агрегаторами в сегменте PCI DSS.
Третий принцип. Нетривиальная схема подключения БД к IBM Guardium Database Activity Monitoring и тестирование производительности. Скажем, у нас есть сервис, который находится в сегменте PCI DSS. Он состоит из некоего количества баз данных, разделенных по типам — продуктив, standby и тест (в некоторых системах существовала дополнительно и предпродуктивные среды, но мы их для удобства рассматривали как тестовые). По разработанной методике мы начинали подключение с тестовых серверов БД и тем самым закрывали задачи функционального тестирования и создания политики безопасности БД, применяемой к конкретной системе. После окончания периода функционального тестирования команда заказчика, которая занимается тестовыми версиями, подтверждала, что функциональность приложений, обращающихся к тестовым БД, не нарушается. Далее, если есть возможность, на тестовые сервера подается нагрузка, сопоставимая с нагрузкой на продуктив. Команда проекта и заказчик производят анализ влияния, оказываемого системой на производительность БД, и предоставляет заключение (вычисляет средний процент деградации сервиса). Далее после получения приемлемых результатов на тестовом контуре принимается решение о подключении продуктивных БД. Тем самым мы оставляли себе возможность откатиться на сервера standby, если что-то пойдет не так с продуктивной БД, уже подключенной к DAM. И таким образом сохраняли SLA по доступности и работоспособности сервиса заказчика.
Подключение продуктивных серверов происходило в сервисные окна — глубокой ночью в выходные дни, когда нагрузка на бизнес-критичные приложения и БД минимальная. После 2-3 недель работы агента с включенными политиками безопасности, если не возникало замечаний, по аналогичной процедуре подключались standby-сервера БД. После этого можно было считать, что весь контур, относящийся к конкретной системе, подключен к решению IBM и функционирует нормально.
Для каждой информационной системы мы подготавливали подробную карточку с описанием подключаемой к IBM Guardium Database Activity Monitoring системы: архитектуры подключения, подробным описанием политики безопасности, примененной к БД, и данных по подключенным инстансам. В совокупности с верхнеуровневой схемой разворачиваемой системы карточки предоставляли заказчику полное и понятное описание системы в целом и её компонентов.
Поиск аномалий
На первоначальном этапе мы отслеживали абсолютно все обращения к базам данных — таким образом мы проверяли работоспособность БД и системы мониторинга под высокой нагрузкой в режиме полного логирования обращений в БД. Параллельно мы запрашивали у владельцев систем список таблиц, в которых содержатся критичные данные по каждой БД, что в дальнейшем при изучении трафика в режиме полного логирования позволяло производить тонкую настройку правил мониторинга с целью отсечения «лишних» данных и снижения нагрузки на сеть и инфраструктуры хранения.
В совокупности такой подход позволил сформировать и подготовить кастомизированные политики для каждой базы данных систем с учетом особенностей их функционирования.
В ходе этого первоначального накопления знаний мы сделали для заказчика небольшое открытие. Нас к нему сподвигло аномальное поведение одной базы данных, к которой DAM за несколько дней не зафиксировал ни одного обращения. Выяснилось, что приложение, которое должно было обращаться к таблице, берет данные из нее не прямым запросом, а через запрос на хранимую процедуру. Очевидно, что это потребовало пересмотреть ранее разработанные политики логирования с целью добавления дополнительного контроля в запросах вызова хранимых процедур, и самое главное — контроля создания новых хранимых процедур, обращающихся к критичным данным.
На этапе развертывания системы заказчик поставил задачу по демонстрации возможностей системы в боевых условиях — иными словами, нужно было выявить очевидное нарушение политик ИБ и продемонстрировать результаты вышестоящему руководству.
Нам помогло полное логирование, которое мы настраивали на первоначальном этапе подключения БД к системе. Мы пошли по самому простому, как нам показалось, пути —описать штатную работу использования БД со стороны приклада и пользователей и далее, рассмотрев полный лог аудита использования, попытаться выявить аномалии. Выгрузка подключений к базе показала, что к базе обращается сервер не из контура PCI DSS. Оказалось, что это был сервер из незащищенного сегмента, который периодически обращался из-под учётки SYS к СУБД с какими-то служебными запросами. А это, замечу, прямое нарушение стандартов безопасности и ненужные риски для заказчика, который был убежден в изолированности сегмента PCI DSS.
Когда картина с доступом с точки зрения сети стала ясна, мы перешли на уровень пользователей и проанализировали, под какими учетными записями осуществляются запросы к БД. Среди них также оказались «лишние» учётки. Далее — уровень приложений. Поскольку у каждого приложения есть логика обращений к БД, на атипичные типы запросов были повешены алерты.
Главный вывод, который мы смогли вынести из практического опыта разработки политик ИБ под конкретные БД, — для создания действительно эффективных политик необходимо на первоначальном этапе создавать карты штатной работы систем. Чем глубже будет описание штатной работы БД, тем более эффективную политику ИБ можно реализовать с помощью IBM Guardium Database Activity Monitoring.
Описанный выше подход позволил поэтапно обогащать политики мониторинга и фактически подтверждал классический для мира ИБ тезис: создать работающую и действительно подходящую для конкретного заказчика политику сразу после развертывания системы нереально, она рождается на протяжении некоторого времени после ввода системы в строй совместными усилиями ИБ-отдела заказчика, ответственных специалистов и внешнего консультанта.
Выводы
Взявшись за проект развертывания IBM Guardium Database Activity Monitoring в розничном банке, мы и подумать не могли, что первое наше внедрение этого решения станет, вероятно, самым масштабным на рынке. Развернута опорная инфраструктура из шести коллекторов и одного агрегатора. В scope проекта вошло около 30 АБС (Way4, 3Card, ЦФТ, ЕХД и др.) на разных платформах СУБД (Oracle, PostgreSQL, MS SQL) и типах ОС (RHEL, AIX, WinServer, OEL). Всего в периметр проекта вошли 110 серверов БД. По результатам проведенных нагрузочных тестов средняя деградация (увеличение времени отклика БД) составила не более 6%. При этом решение от IBM помогло в части некоторых систем снизить нагрузку на БД в части аппаратной утилизации дисковой подсистемы (в 2.5 раза) и высвободить порядка 30% дискового пространства за счет отключения средств нативного аудита СУБД, что, в принципе, ожидалось изначально. Но главное — после получения промежуточных результатов мы приобрели в союзники целую команду, отвечающую в ДИТе заказчика за сопровождение баз данных и прикладных систем. До старта проекта они были главными скептиками.
Я считаю, что на IBM Guardium имеет смысл обратить внимание, если в вашей организации есть не только базы данных enterprise-уровня, но и какие-либо решения Big Data. Сейчас любая компания — не обязательно очень крупная — собирает данные в надежде использовать их для оптимизации производства товаров и услуг и проведения глубокой аналитики. При этом озеро данных, куда стекается вся неструктурированная информация, как правило, ничем не защищено и доступ к данным не контролируется. Даже если в текущей инфраструктуре Big Data не содержится конфиденциальных данных, не факт, что она не окажется в этой инфраструктуре завтра. Ведь изначально внутренними заказчиками решений Big Data нередко выступают маркетинговые подразделения заказчика.
