Как с помощью PAM-системы Krontech Single Connect, разработанной компанией Krontech, можно обеспечить защиту баз данных Oracle Database, Microsoft SQL Server, MySQL, Cassandra DB? В материале сфокусируем внимание на мониторинге SQL-запросов к серверам баз данных, расскажем о динамическом маскировании данных (Dynamic Data Masking) и о механизме поиска критической информации в базах (Sensitive Data Discovery), реализованных в Krontech Single Connect.
- Введение
- Мониторинг SQL-запросов к серверу при помощи Krontech Single Connect
- Динамическое маскирование данных (Dynamic Data Masking)
- Поиск критичных данных (Sensitive Data Discovery)
- Выводы
Введение
Защита баз данных является одной из самых важных и сложных задач в обеспечении безопасности любой информационной системы. Нарушения безопасности баз данных могут привести не только к утечке критически важных данных, таких как финансовая информация (счета, платежи), персональные данные сотрудников или клиентов, но и к полному отказу работоспособности системы и нарушению функционирования бизнес-процессов компании.
Существуют разные способы, как защитить базы данных. Одним из них является контроль привилегированных сессий к СУБД, поскольку штатные разработчики и администраторы баз данных имеют широкие привилегии. Контролировать таких пользователей необходимо, поскольку высок риск утечки конфиденциальной информации из баз, возникновения сбоев в работе информационных систем компании или нарушения деятельности компании в целом.
Для разбора полетов необходима система, которая может параллельно проследить действия администраторов и записать их. В статье мы расскажем, как с помощью PAM-системы Krontech Single Connect, разработанной компанией Krontech, можно обеспечить защиту баз данных Oracle Database, Microsoft SQL Server, MySQL, Cassandra DB. Не так давно мы уже делали «Обзор Krontech Single Connect — системы управления привилегированным доступом». Сегодня сфокусируем внимание на мониторинге SQL-запросов к серверам баз данных, расскажем о динамическом маскировании данных (DDM) и о механизме поиска информации в базах (Sensitive Data Discovery), реализованных в Krontech Single Connect.
Мониторинг SQL-запросов к серверу при помощи Krontech Single Connect
Учитывая, что изменение и извлечение информации из баз осуществляется с помощью языка SQL, необходимо производить мониторинг и контроль SQL-запросов привилегированных пользователей — разработчиков и администраторов БД.
Мониторинг сессий в СУБД в Single Connect осуществляется с помощью модуля SQL Proxy. В общем случае процесс мониторинга выглядит следующим образом:
- В Krontech Single Connect администратором ИБ настраиваются политики контроля SQL-запросов: это может быть белый (разрешающий) или черный (запрещающий) список команд. Также может быть применен механизм маскирования данных.
- Пользователь инициирует SQL-запрос к базе данных с помощью стандартных SQL-клиентов. Запрос обрабатывается настроенными политиками безопасности на сервере Krontech Single Connect в модуле SQL Proxy.
- Действия (SQL-запросы) регистрируются в журнале событий Krontech Single Connect.
- Если команды, вводимые пользователем политиками безопасности Krontech Single Connect, запрещены, SQL-запрос блокируется. Если не запрещены — действия администратора БД регистрируются.
- Администратор ИБ в консоли Krontech Single Connect просматривает лог сессии или наблюдает онлайн за открытыми сессиями — просматривает SQL-запрос.
Рисунок 1. Процесс мониторинга SQL-запросов в Krontech Single Connect
Прежде чем приступать к подробному описанию механизмов контроля SQL-запросов, отметим, что в рассматриваемой новой версии Single Connect 2.9 теперь доступен русифицированный интерфейс. Это делает более удобной работу с системой тем, кто плохо владеет иностранными языками.
Рисунок 2. Русифицированный интерфейс Krontech Single Connect
Для мониторинга запросов в Krontech Single Connect необходимо выполнить соответствующие настройки.
Во-первых, необходимо настроить источники данных — целевые сервера СУБД, к которым будет осуществляться доступ.
Рисунок 3. Управление источниками данных в Krontech Single Connect
Нужно еще создать устройства и определить порты.
Рисунок 4. Создание устройств и определение портов в Krontech Single Connect
Определение свойств устройств для БД.
Рисунок 5. Определение свойств устройств для БД в Krontech Single Connect
Кроме того, необходимо завести учетные записи администраторов СУБД в Krontech Single Connect, создать группу пользователей и добавить в нее созданные аккаунты.
Рисунок 6. Определение группы в Krontech Single Connect
Создать группу устройств, добавить в нее сервера СУБД, а также создать область устройств.
Рисунок 7. Область устройств в Krontech Single Connect
Область устройств должна быть создана, чтобы определить, какая группа пользователей авторизована для какой группы устройств.
Следующим этапом необходимо определить политики безопасности для мониторинга привилегированных сеансов СУБД. Как уже отмечалось, это могут быть белые или черные списки команд, маскирование данных.
Рисунок 8. Свойства группы политик в Krontech Single Connect
Рисунок 9. Свойства ключей политик в Krontech Single Connect
После настройки пользователей, устройств и политик попробуем подключиться к MySQL, используя Session Manger.
Рисунок 10. Подключение к MySQL, используя Session Manger
Выполняем SQL-запросы к базе данных. Например, select * from titles;.
Рисунок 11. Выполнение SQL-запросов к базе данных
В консоли Krontech Single Connect можно увидеть всю историю SQL-запросов к базе данных и посмотреть детали команды.
Рисунок 12. Просмотр истории SQL-запросов к базе данных в Krontech Single Connect
Динамическое маскирование данных (Dynamic Data Masking)
Динамическое маскирование данных (Dynamic Data Masking) заключается в предоставлении фиктивных данных вместо реальных. Динамическое маскирование данных можно использовать, когда необходимо запретить просмотр конфиденциальных данных в средах разработки приложений, например, во время тестирования и апробации программного обеспечения, где требуются не «реальные», а «синтетические» данные.
В Single Connect правила маскирования включают в себя:
- Замену исходных значений на символы. Например, номера телефонов в таблице заменяются на «X»: 511- 5671918 -> XXX – XXXXXXX
- Перестановку исходных значений. Например, код «34670» после маскирования с перестановкой выглядит так: «43706».
- Добавление или вычитание случайного значения к исходному значению с ограничениями. Например, дата рождения 11.4.2001 изменяется на 29.7.2001 при условии, что случайное значение будет в пределах от -100 до +100 дней).
- Токенизация — маскировка части исходного значения. Например, оригинальный номер кредитной карты 1111-2222-3333-4444 будет изменен на 1111-1234-5678-4444.
- Замена исходного значения другим случайным значением, выбранным из предопределенного набора. Например, первоначальное имя Джон меняется на Адам, который случайно будет выбран выбранный из предопределенного списка имен.
- Кастомные правила маскирования, которые задаются администратором Single Connect регулярными выражениями.
Отметим, что на данный момент Single Connect является первым и единственным PAM-решением на рынке, которое предлагает динамическую маскировку данных в дополнение к другим функциям защиты привилегированных сеансов СУБД.
Для реализации маскирования данных в Krontech Single Connect необходимо создать соответствующие методы (шаблоны) маскирования.
Рисунок 3. Шаблоны методов маскирования в Krontech Single Connect
Привязать политики маскирования к базе данных — указать таблицу, колонку таблицы и метод маскирования.
Рисунок 14. Привязка политики маскирования к базе данных в Krontech Single Connect
При запросе, например, в MSSQL значений колонки Birthdayтаблицы dbo.customer выгружаются маскированные значения.
Рисунок 15. Выгрузка маскированных значений таблицы для колонки Birthday в MSSQL
Поиск критичных данных (Sensitive Data Discovery)
Для поиска критичной с точки зрения ИБ информации в базах данных можно использовать механизм Sensitive Data Discovery в Krontech Single Connect. Эта функция позволяет найти и защитить все многообразие корпоративных конфиденциальных данных, например имена и адреса работников, номера телефонов, кредитных карт, пароли, хранящиеся в открытом виде, и т. д.
Рисунок 16. Шаблоны поиска критичных данных в Krontech Single Connect
Для тестирования поиска создадим в СУБД две таблицы:
- contacts с колонкой Address, которая содержит адреса электронной почты;
- user_location с колонкой Location, которая содержит IP-адреса.
Рисунок 17. Создание в СУБД таблицы contacts с колонкой Address, которая содержит адреса электронной почты
Рисунок 18. Создание в СУБД таблицы user_location с колонкой Location, которая содержит IP-адреса
В Krontech Single Connect в разделе поиска критичных данных создадим условия их обнаружения — выберем соответствующие шаблоны обнаружения Email и IP и запустим поиск для СУБД MS SQL DB.
Рисунок 19. Результаты поиска критичных данных в Krontech Single Connect
Результаты обнаружения критичных данных выводятся внизу консоли Krontech Single Connect.
Выводы
В статье мы рассказали, как с помощью Krontech Single Connect можно обеспечить защиту баз данных Oracle, MSSQL, MySQL, Cassandra DB. Single Connect проводит мониторинг обращений к базам данных в режиме реального времени, регистрирует SQL-запросы и выявляет запрещенные политикой безопасности операции.
Динамическое маскирование данных в Krontech Single Connect ограничивает возможность раскрытия конфиденциальных данных за счет маскирования этих данных для привилегированных пользователей — разработчиков и администраторов СУБД. Это позволяет предотвращать утечку конфиденциальной информации и персональных данных, а также повышает надежность защиты баз данных.
Поиск критичных данных (Sensitive Data Discovery) в Krontech Single Connect позволяет найти в базах данных и защитить все многообразие корпоративных конфиденциальных данных, например имена и адреса работников, номера телефонов, кредитных карт, пароли, хранящиеся в открытом виде, и т. д.
