Информационная безопасность не только возможность для компаний защититься от кибератак и действий инсайдеров, а еще и обязательное требование регулирующих органов, регламентированное в форме законодательных актов и отраслевых стандартов. Обеспечивать эти требования и избежать штрафных санкций позволяет внедрение специализированных ИБ-решений, таких как «Гарда БД».
Система защиты баз данных и веб-приложений «Гарда БД» от российского вендора «Гарда Технологии» помогает обеспечить соответствие требованиям стандартов безопасности, таких как PCI DSS от апреля 2016 года, Приказа ФСТЭК № 21 от 18.02.2016 года, новых банковских ГОСТов.
«Гарда БД» — это комплекс, позволяющий проводить аудит всех операций с базами данных и с веб-приложениями. Его основные задачи – мониторинг запросов, которые выполняются в базе, анализ этих запросов и ответов. Предусмотрен механизм для настройки политик по анализу этих запросов-ответов: контроль действий привилегированных пользователей, контроль удаленного доступа сотрудников. Также в системе есть возможность блокировки запросов.
Система позволяет сканировать сети на наличие баз данных, сами базы данных на наличие в них определенной информации, проверять открытые и закрытые уязвимости, строить матрицы доступа к данным.
В этой статье рассмотрим механизм работы системы защиты баз данных в части обеспечения требований регуляторов.
Аудит доступа к данным в СУБД
Большая часть требований стандартов безопасности, связанных с базами данных затрагивает вопросы аудита доступа к данным, хранящимся и обрабатываемым в СУБД.
Во многом это связано с особенностями предоставления доступа к ним:
- хранение данных централизованно, то есть с минимальным количеством возможных каналов доступа к ним;
- формат запроса данных и их представления унифицирован (SQL).
Пример: Выгрузка историй операций по расчетному счету
При контроле передачи этих данных средствами контентного анализа возникает следующая проблема: пересылаемые данные имеют вид таблицы из двух колонок, в одной содержится дата, в другой – сумма (так как это единственные данные, которые интересуют злоумышленника). С учетом того, что сумма может быть довольно разной длины, дата может быть в разных форматах – контентный анализ потребует формирования довольно сложного регулярного выражения, которое будет давать большой объем ложных срабатываний. Более того, данные могут быть переданы не в таблице, а в виде картинки, ручной записи или вообще устно – это контролировать невозможно.
Таким образом, стандарты безопасности предписывают контролировать доступ к этим данным на уровне СУБД. Поскольку доступ, как правило, осуществляется средствами SQL, – правила аудита легко формализуются параметрами SQL-запроса и дополняются контентным анализом ответа.
Стандарты безопасности и требования регуляторов в отношении СУБД предполагают несколько видов аудита доступа, связанных с СУБД:
- Аудит действий привилегированных пользователей (к ним относятся администраторы, подрядчики и другие пользователи, имеющие прямой доступ к таблицам СУБД).
- Аудит действий по изменению настроек самой СУБД (сюда относятся создание\изменение пользователей, прав доступа, структуры СУБД и др.).
- Аудит доступа к критическим данным (таблицы и поля).
Система аудита доступа к СУБД предлагают два способа выполнения этих требований:
- Непосредственный аудит.
Сюда входят правила аудита доступа явно указанные в требованиях стандартов – протоколирование всех изменений прав доступа к данным, обращений к критическим данным и др.
- Выявление событий, несоответствующих требованиям регуляторов.
Включает требования, которые нельзя описать средствами программ аудита доступа, но есть возможность выявления событий не соответствующих заданным требованиям. Например, выявление учетных записей с отсутствующим сроком действия пароля.
Правила аудита в системах класса DAM
Рассмотрим примеры формирования правил аудита на примере системы класса DAM «Гарда БД» (от англ.Data access management – управление доступом к данным).
Для создания правил аудита в системе используется понятие «Политика», содержащая в себе логическое правило из нескольких параметров, на соответствие которому проверяется каждый контролируемый SQL-запрос. Правило может включать в себя параметры:
- Дата/Время;
- IP-адрес:порт;
- Логин БД;
- Таблица/Объект;
- Поле таблицы/объекта;
- Логин ОС;
- Имя программы;
- Имя функции/процедуры;
- SQL-операции;
- Объём запроса;
- Объём ответа;
- Строк в ответе;
- Ключевое слово;
- Аутентификация.
Комбинирование этих критериев анализа дает широкий возможности по формированию политик.
Для удобства настройки политик в системе «Гарда БД» можно использовать списки критериев, например, списки УЗ с привилегированным доступом, списки таблиц\полей, списки ключевых слов и др. Сложность настройки заключается в том, что для выполнения некоторых требований данные списки необходимо регулярно актуализировать. Кроме того, специалисты по безопасности не всегда имеют актуальную информацию о том, в каких таблицах и полях находится контролируемая информация.
Для решения этой задачи в системе «Гарда БД» предусмотрено несколько механизмов:
- Формирование списков критериев на основе SQL-запроса в контролируемые СУБД.
- Контентное сканирование таблиц СУБД по наименованию полей или контенту с формированием списка таблиц и полей.
Рассмотрим использование этих технологий на примере требования PCI DSS 7.1 7.1 от апреля 2016 года: Доступом к вычислительным ресурсам и информации о держателях карт должны обладать только те сотрудники, которым такой доступ необходим в соответствии с их должностными обязанностями.
Это требование относится ко второму типу, когда правила аудита должны выявлять несоответствие требованию.
В этом случае в критериях политики указаны параметры: логин БД не соответствует ни одному из списка логинов с правами доступа к данным платежных карт (ДПК), запрашиваемая таблица соответствует одной из списка таблиц с данными ДПК.
Для формирования списка таблиц ДПК используется механизм сканирования СУБД. При сканировании в системе «Гарда БД» можно использовать предустановленные категории или же создать пользовательские. Сканирование может осуществляться по наименованиям полей или же по контенту. При этом можно использовать для описания искомых данных ключевые слова или регулярные выражения.
После выполнения сканирования система отображает список таблиц и полей, которые содержат указанную информацию. Выделив необходимые записи, можно сформировать из них список критериев. Для формирования списка учетных записей используют функцию получения данных запросом к СУБД. Этот запрос вернет список пользователей, которым назначена роль «оператор ДПК».
Подобным образом можно формировать списки и для других политик, например, списка учетных записей с дефолтными настройками безопасности, списки таблиц с разрешенным доступом роли public (от англ. сообщество, группа), списки пользователей с просроченным паролем и т.д.
Важная особенностью обоих механизмов формирования списков критериев — возможность выполнения этих задач по расписанию, что позволяет регулярно актуализировать списки без перенастройки правил аудита.
Контроль реализации настроек безопасности СУБД
Помимо правил аудита доступа, есть ряд требований к безопасности СУБД, не связанный с выполнением запросов или осуществлением доступа к СУБД вообще. Сюда можно отнести требования, относящиеся к настройкам безопасности СУБД, особенностям хранения критических данных и др.
Для выполнения этих требований стандартов в системе «Гарда БД» есть функция сканирования уязвимостей СУБД. Эта функция позволяет выполнять тестовый запрос к СУБД и анализировать возвращаемые им данные. Основное назначение этой функции – выявление незакрытых уязвимостей СУБД, связанных с парольной политикой, настройками безопасности и отсутствием необходимых патчей. Но с помощью тонких настроек эту функцию можно также использовать для проверки выполнения требований регуляторов.
При настройке проверки в «Гарда БД» задается текст тестового запроса и критерий успешности проверки:
- определенное значение в указанном столбце (или больше\меньше указанного значения);
- ответ возвращает определенное количество записей (или больше\меньше количества записей).
Рассмотрим примеры использования этой функции «Гарда БД»
Требование ГОСТ Р 57580.1-2017 УЗП.3: Выявление незаблокированных учетных записей сотрудников, отсутствующих на рабочем месте более 90 календарных дней.
Для проверки выполнения этого требования можно настроить тестовый запрос.
Согласно настройкам критерия успешности, такая проверка считается выполненной, если тестовый запрос вернет нулевое количество учетных записей.
Данные проверки также могут выполняться по расписанию для автоматизации задач оценки соответствия требованиям регуляторов.
Выявление несоответствий требованиям стандартов ИБ
Еще одним механизмом «Гарда БД» для обнаружения несоответствий стандартам безопасности является профилирование. Эта функция позволяет строить модели поведения учетных записей СУБД с учетом параметров:
- IP клиента;
- Операции;
- Логин\Логин БД;
- Логин ОС;
- Имя домена\компьютера;
- Приложение;
- Таблицы;
- Поля;
- Содержимое полей (контент).
В стандартах безопасности есть ряд требований, направленный на исключение неперсонифицированного доступа к критическим данным. К таким требованиям можно отнести ИАФ. 1, ИАФ. 6, АНЗ.4 Приказа № 21 ФСТЭК от 18.02.2013 г. и другие.
Для контроля выполнения этих требований «Гарда БД» позволяет настроить следующие задачи:
- Формирование политики по доступу к критическим данным. При настройках этой политики можно использовать рассмотренные ранее функции получения списков таблиц и полей.
- Режим профилирования в рамках настроенной политики.
При включении этого режима, для каждой учетной записи, контролируемой в этой политике, будет формироваться профиль, содержащий параметры доступа этой учетной записи.
При корректно настроенной идентификации пользователей в информационной системе, обрабатывающий критические данные, в каждом профиле должна содержаться только одна запись типа «имя компьютера» или «Логин ОС». Когда при профилировании пользователей будут обнаружены учетные записи, доступ к которым осуществляется разными доменными учетными записями, или разными компьютерами – это будет говорить о невыполнении указанных выше требований.
Профилирование может использоваться не только для выявления неперсонифицированных учетных записей, но и для обнаружения иного несанкционированного доступа к критическим данным – использование стороннего ПО, обнаружение доступа из сторонних подсетей и др.
Выполнение требований стандартов безопасности, федеральных законов и подзаконных актов, регулирующих надлежащее обеспечение безопасности данных клиентов и сотрудников организаций — это не только необходимость, чтобы избежать штрафных санкций, но и сокращение финансовых и репутационных рисков.
Система защиты баз данных и веб-приложений «Гарда БД» позволяет настроить и автоматизировать контроль всех защищаемых данных. Решение наделено функциональными возможностями, чтобы обеспечить соответствие требованиям информационной безопасности российских и международных стандартов и законодательных актов.
Автор: Дмитрий Горлянский — руководитель технического сопровождения клиентов «Гарда Технологии»
