Журнал "Information Security/ Информационная безопасность" #4, 2026

актуален для сред с мультитенантностью. Предикаты доступа привязываются к атрибутам сессии пользователя. Кри- тичным аспектом является производи- тельность: на больших таблицах неин- дексированные поля в предикатах могут приводить к значительным задержкам. Поэтому перед вводом RLS в продук- тивную среду необходимо выполнить нагрузочное тестирование и оптимизи- ровать индексы. 3. Ревизия прав. Периодичность пере- смотра матрицы доступа установлена не реже 1 раза в квартал. Факт ревизии фиксируется отдельным актом. В JDS для этого используются механизмы "Мат- рица доступа" и "Анализ рисков". Наи- более частое нарушение – выданные на время отладки права остаются актив- ными спустя месяцы. Обеспечение целостности и ограничение программной среды Для 4 КЗ установлен норматив конт- роля целостности не реже 1 раза в сутки. В СУБД "Ятоба" за реализацию отвечает модуль ja_CSum, обеспечивающий про- верку контрольных сумм системных и конфигурационных файлов. Настроечный минимум включает: l автоматизацию запуска через плани- ровщика ОС; l настройку периодичности в ja_csum.check_interval (по умолчанию 1440 минут); l размещение результатов проверки в защищенном каталоге с разграниче- нием доступа; l настройку оповещения при обнару- жении расхождений. Важно отметить, что в JDS не реали- зован контроль целостности, поэтому его использование для установки рас- ширений и изменения конфигураций СУБД недопустимо. При нарушении целостности ja_CSum и SecurityProfile автоматически блокируют доступ поль- зователей к СУБД (кроме суперпользо- вателя). Все активные транзакции пре- рываются. В условиях промышленной эксплуатации это является критическим фактором, который необходимо учиты- вать при планировании. Ограничение программной среды заключается в запрете установки и выполнения любых модулей, не вклю- ченных в утвержденный реестр. В при- ложениях 1 и 2 к руководству по компо- ненту ja_CSum приведен перечень рас- ширений, доступных для установки. Ревизия реестра проводится при каждом обновлении версии СУБД. Аудит событий, интеграция SIEM Требованиями определены следующие типы событий, подлежащие регистрации: входы в систему (успешные и неудач- ные), изменения прав доступа, DDL-опе- рации, изменения конфигурации. В СУБД "Ятоба" первичный сбор логов идет через ja_seceventlog, реализующий требования ГОСТ Р 59548–2022, и ja_Log с последующей передачей в JDS и SIEM- системы заказчика. Рекомендации из практики: l Избегать включения всех типов собы- тий без фильтрации, так как это приво- дит к переполнению дисков. Выделить критические события (неудачные аутен- тификации, эскалация привилегий, опе- рации DROP/ALTER на продуктивных схемах) и информационные (успешные входы, чтение данных), для которых ста- вить разные сроки хранения. l Настроить корреляционные правила в SIEM: например, "более 5 неудачных попыток входа с одного IP за 5 минут" – предупреждение, "серия неудачных попыток + успешный вход + изменение ролей" – инцидент высокого уровня. Неизменяемость журналов обеспечи- вается хранением на отдельном файло- вом томе с ограничением прав на запись и удаление, а также дополнительным контролем целостности файлов логов. Специализированные защитные механизмы "Ятоба" 1. SQL Firewall. Рекомендуется экс- плуатация в режиме белых списков для приложений со стабильной структурой запросов. На этапе внедрения обяза- тельна проверка на тестовой нагрузке во избежание ложных срабатываний и деградации производительности. Пер- воначальный сбор шаблонов запросов проводится в течение 1–2 недель в мони- торинговом режиме. 2. Маскирование данных. Статическое маскирование – для тестовых и обучаю- щих сред; динамическое – для аналити- ков и прикладных пользователей. Тре- буется предварительная разметка чув- ствительных полей в схеме данных. 3. Обфускация кода. Применяется к пользовательским хранимым процеду- рам и функциям с целью затруднения реверс-инжиниринга. Системные объ- екты JDS обфускации не подлежат. Внедрение этих механизмов рекомен- дуется выполнять поэтапно, начиная с наименее критичных сегментов для отработки методологии. Очистка остаточной информации В рамках мер по защите от утечек за счет остаточной информации конфигу- рируется режим гарантированного уда- ления (многократная перезапись диско- вых блоков) для удаляемых данных и временных таблиц. Соответствующие процедуры закрепляются в регламенте эксплуатации СУБД, который разраба- тывается в рамках эксплуатационной документации на систему. Верификация настроек и тесты Завершающий этап – подтверждение работоспособности мер защиты. Тести- рование проводится в 2 стадии: 1. Изолированная тестовая среда. Моделируются типовые атаки: эскалация привилегий, SQL-инъекции, модифика- ция кода хранимых процедур, нарушение целостности. 2. Пилотный сегмент продуктивной среды. Под усиленным мониторингом проверяется влияние настроек на биз- нес-процессы. Каждый тестовый сцена- рий протоколируется. В случае выявле- ния уязвимостей выполняется коррек- тировка настроек и повторный цикл тестирования. Результаты оформляются в виде отчета о тестировании, который является приложением к комплекту экс- плуатационной документации. Документальное сопровождение и эксплуатационный контроль Комплект организационно-распоряди- тельной документации должен включать: l политику информационной безопас- ности и парольную политику; l утвержденную матрицу доступа с опи- санием ролей; l регламенты контроля целостности и аудита; l протоколы тестирования; l инструкцию по реагированию на инци- денты; l регламент управления изменениями, фиксирующий любое изменение кон фигурации СУБД с обязательным согла- сованием и проверкой. Пост-внедренческий этап включает квартальный аудит прав, мониторинг обновлений безопасности СУБД "Ятоба", проведение тренировок по инцидент менеджменту и использование систем контроля конфигураций для обнаруже- ния несанкционированных изменений. Практика вместо формальностей СУБД "Ятоба" располагает функцио- нальными средствами, покрывающими требования по безопасности информа- ции для 4-го класса защиты. Однако техническая реализация не гарантирует выполнение требований без системного подхода, включающего построение модели угроз, сегментированную настройку механизмов ИАФ, управления доступом, целостности, аудита, валида- ционное тестирование и последующий эксплуатационный контроль. Наиболее частые причины неудач при аудите – избыточные привилегии сервисных учет- ных записей, отсутствие автоматизиро- ванного контроля целостности и недо- статочная проработка процесса управ- ления изменениями. Представленный алгоритм основан на практическом опыте и позволяет минимизировать риски получения предписаний при про- верках. В сложных случаях рекоменду- ется привлекать консультантов, имею- щих опыт работы с сертифицированны- ми СУБД и прохождения контрольных мероприятий в органах по аттестации ФСТЭК России. l Демонстрацию, демоверсиюили пилот можно запросить на сайте Jatoba.ru • 49 СУБД И БЕЗОПАСНОСТЬ www.itsec.ru