Эволюция требований к безопасности систем управления базами данных в России прошла через несколько этапов, каждый из которых оказал существенное влияние на процессы разработки и сертификации системного ПО. Ситуация принципиально изменилась с выходом Приказа ФСТЭК России № 76 от 2 июня 2020 года, установившего уровни доверия к средствам защиты информации. Документ обязал всех заявителей, претендующих на сертификацию, выполнять требования к разработке и производству средств защиты, проведению испытаний и последующей поддержке безопасности этих средств. Для разработчиков СУБД ключевыми изменениями стали введение обязательных процедур анализа уязвимостей и проверки исходного кода, включая статический и динамический анализ; углубленное внутреннее тестирование на проникновение; переход от разовой проверки готового продукта к регулярному подтверждению процессов безопасной разработки.

Существенные изменения произошли и с утверждением Приказа ФСТЭК России № 64 от 14 апреля 2023 года, в котором требования по безопасности информации впервые были напрямую применены к системам управления базами данных. Этот документ значительно расширил перечень обязательных функций. Ранее существовавшие требования к управлению доступом, идентификации и аутентификации, контролю целостности, регистрации событий безопасности получили более четкие формулировки и детализацию. Одновременно появились новые требования: резервное копирование и восстановление, обеспечение доступности, очистка памяти, контроль производительности, ограничение программной среды.

Требования к СУБД

На сегодняшний день ключевым документом, регулирующим безопасность систем управления базами данных, является Приказ ФСТЭК России № 64, устанавливающий специализированные требования к СУБД как к классу ПО, значительно расширяя и детализируя перечень обязательных функций безопасности. Согласно документу, защищенная СУБД должна надежно идентифицировать пользователей и управлять их доступом к системе, обеспечивать криптографическую защиту данных, включая шифрование по ГОСТ и контроль целостности. Обязательны также средства аудита и мониторинга событий для расследования инцидентов.

Особое внимание в документе уделяется защите от атак и несанкционированного доступа, в том числе противодействию SQL-инъекциям через параметризованные запросы и защите от DDoS- и сетевых атак с помощью гибкого управления подключениями и таймаутами.

Одним из наиболее значимых стало требование по обеспечению доступности системы управления базами данных. В объект оценки при сертификации вошел сервис построения отказоустойчивого кластера. Если изначально это решение существовало как отдельный компонент, то теперь стало обязательной частью сертифицированного продукта

Все эти меры основаны на фундаментальных требованиях Приказов № 17, № 21 и № 76, задающих стандарты защиты для государственных информационных систем, персональных данных и подтверждения безопасности процессов разработки.

Эволюция регуляторных требований, особенно Приказ № 64, заставила разработчиков СУБД не только расширить документацию, но и кардинально пересмотреть механизмы обеспечения безопасности.

РЕД База Данных и вопросы безопасности

СУБД РЕД База Данных развивается вместе с отраслевыми стандартами с 2006 года, вбирая в себя актуальные практики безопасной разработки и механизмы прозрачного шифрования данных — в архитектуре системы изначально предусматривались возможности разграничения доступа, криптографической защиты и аудита. Сегодня продукт соответствует 4-му классу защиты и 4-му уровню доверия ФСТЭК России.

Технические средства защиты

Регуляторные требования и прежде всего Приказ № 64 предъявляют к современным СУБД широкий перечень обязательных функций безопасности — РЕД База Данных закрывает каждую такую позицию, изначально акцентируя внимание на вопросах сохранности пользовательских данных.

Для повышения уровня безопасности используется многофакторная аутентификация, поддерживаемая плагином политик безопасности Policy, плагинами аутентификации Srp, Certificate, GostPassword и др. На первоначальном этапе работы сервер осуществляет независимую верификацию каждого фактора с применением плагинов: Srp проводит проверку пароля, Certificate валидирует цифровой сертификат. Результаты проверок фиксируются, но окончательное решение о предоставлении доступа к системе еще не принимается. Далее плагин Policy анализирует, все ли требуемые политикой безопасности факторы были успешно подтверждены, и принимает окончательное решение о допуске пользователя в систему.

РЕД База Данных поддерживает несколько методов подтверждения личности пользователя:

  • пароль. Это может быть как традиционный пароль СУБД, так и пароль, защищенный по протоколу SRP (Secure Remote Password) или с использованием российских криптографических алгоритмов;
  • сертификат. Пользователь может подтвердить свою личность с помощью электронного сертификата X.509. Сам сертификат хранится в защищенном контейнере, доступ к которому защищен PIN-кодом. Использование сертификата подтверждает доступ пользователя к закрытому ключу, с помощью которого формируется сессионный ключ для аутентификации и шифрования сетевого трафика;
  • проверка сервера. В некоторых схемах аутентификации используется не только проверка клиента сервером, но и обратная проверка. Плагин VerifyServer позволяет клиенту удостовериться, что он подключается к подлинному серверу, а не к системе-ловушке. Активация происходит в соответствии с политиками информационной безопасности.

Сервер РЕД Базы Данных может использовать LDAP в качестве источника данных для аутентификации. Там могут храниться как хэши паролей пользователей, так и их сертификаты, которые будут сверяться с сертификатами, предъявленными пользователями. Это добавляет еще один уровень контроля и централизует управление учетными данными.

Если многофакторная аутентификация предназначена для верификации личности пользователя, то ролевая модель и политики безопасности регулируют доступ к ресурсам, определяют допустимые действия и процедуры их выполнения. Приказ № 64 изменил перечень предустановленных ролей, что потребовало привести модель в соответствие с новыми стандартами.

Роли определяют функциональные возможности пользователя в системе, в то время как политики безопасности устанавливают процедуры и правила, регулирующие способы выполнения действий с точки зрения обеспечения информационной безопасности. Политики представляют собой комплекс требований к парольным политикам и общим принципам работы пользователей. С их помощью администратор имеет возможность установить минимальную длину пароля, обязательные элементы (буквы, цифры, регистры), а также определить период действия пароля, например, 60 дней. Политика может содержать ограничения на повторное использование последних паролей. Кроме того, политики безопасности позволяют установить лимит на количество неудачных попыток аутентификации, после чего учетная запись временно или постоянно блокируется. Также предусмотрена возможность автоматической блокировки учетной записи в случае длительного отсутствия активности.

Политики безопасности тесно интегрированы с механизмами многофакторной аутентификации. В рамках политики можно определить, что для доступа к системе пользователь должен использовать не только пароль, но и дополнительные методы аутентификации, такие как сертификаты.

Когда речь заходит о защите данных в критически важных информационных системах, особенно в государственных учреждениях или компаниях с повышенными требованиями к безопасности, использование международных алгоритмов шифрования может быть недостаточным или даже недопустимым. Для таких случаев в РЕД Базе Данных реализована поддержка российского криптографического провайдера КриптоПро, который обеспечивает работу с криптографическими алгоритмами ГОСТ Р 34.10-2012 для электронной подписи, ГОСТ Р 34.11-2012 для хэширования и ГОСТ 28147-89 для шифрования, которые актуализированы в более новых стандартах, таких как ГОСТ 34.12-2015.

Основные сценарии использования криптографии:

  • аутентификация пользователей. Пароль в открытом виде по сети не передается — вместо этого используется метод защищенного обмена данными с применением алгоритмов ГОСТ, который подтверждает знание пользователем пароля, при этом сам пароль остается недоступным для перехвата. Метод аутентификации называется GostPassword. Для его реализации необходимо, чтобы на сервере и на клиентском устройстве был установлен и корректно настроен КриптоПро CSP;
  • шифрование отдельных компонентов базы данных, включая страницы с данными, индексами и большими двоичными объектами (BLOB). Для реализации шифрования используется плагин Crypto_Api. Процедура шифрования инициируется администратором и выполняется в асинхронном режиме, что позволяет обеспечить непрерывность работы для пользователей;
  • контроль целостности данных. Администратор может верифицировать важные компоненты базы данных, включая хранимые процедуры, а также файлы СУБД. Для этой цели применяются утилиты mint и hashgen расчета контрольной суммы (хеша) объектов с использованием алгоритма хеширования ГОСТ Р 34.11–2012. В случае выявления несоответствия вычисленного хеша эталонному значению система фиксирует факт модификации и может инициировать соответствующие меры, включая уведомление пользователя и остановку работы СУБД.

В РЕД Базе Данных шифруется не весь файл базы данных целиком, а только наиболее важные с точки зрения конфиденциальности элементы: страницы с пользовательскими данными, страницы индексов и страницы с большими объектами. Перечень шифруемых объектов предустановлен и определяется архитектурой механизма прозрачного шифрования — администратор не может изменить его в настройках, что исключает риск случайного или намеренного отключения защиты. Однако администратору доступно управление ключами шифрования: именно он инициирует процедуру шифрования и отвечает за хранение и ротацию ключей. В случае компрометации ключа или подозрении на утечку предусмотрен механизм перешифрования базы данных с использованием нового ключа, что позволяет сохранить конфиденциальность данных даже при возникновении нештатных ситуаций. Такой подход позволяет сосредоточить вычислительные ресурсы именно на защите содержимого, а не служебной информации и одновременно дает администратору инструменты для реагирования на инциденты безопасности.

Прозрачное шифрование защищает данные на уровне файловой системы от несанкционированного доступа — без него злоумышленник может извлечь конфиденциальную информацию, получив физический доступ к серверу или дискам. Прозрачное шифрование делает файлы нечитаемыми без ключа. Это стандарт информационной безопасности, обязывающий на уровне хранения защищать персональные данные и другую критическую информацию.

В РЕД Базе Данных процесс шифрования можно запустить как для новой, так и для уже существующей базы. Шифрование происходит в фоновом режиме, страница за страницей, не требуя остановки сервера или перевода базы данных в монопольный режим.

Аудит в РЕД Базе Данных — способ отслеживания всех важных событий. В журнале записываются все действия пользователи, независимо от того, удались они или нет, включая случаи, когда пользователь предпринимал действия, выходящие за рамки его полномочий.

Система аудита позволяет протоколировать события как в текстовом, так и в бинарном формате. Кроме того, предусмотрена возможность передачи данных в системный журнал ОС для обеспечения дополнительной безопасности и контроля или передачи событий в другие приложения.

Аудит обеспечивает информационную безопасность и помогает расследовать инциденты, показывая, кто изменил или удалил данные, идентифицируя попытки несанкционированного доступа и взлома паролей.

Файл fbtrace.conf содержит описание конфигурации, поддерживающей функционирование системы аудита. Он предоставляет администратору возможность активации или деактивации регистрации различных типов событий. Например, система может быть настроена таким образом, чтобы фиксировать исключительно подключения к базе данных и завершение длительных запросов либо осуществлять запись всех действий, включая каждое изменение любого элемента в таблице.

При возникновении события система аудита записывает его в журнал во время завершения операции, что позволяет фиксировать не только факт события, но и его результат.

Журналы могут подвергаться ротации — по достижении установленного размера файл автоматически архивируется, а взамен него создается новый. Это предотвращает бесконтрольный рост объема файлов и упрощает их последующее хранение.

Защита от атак и несанкционированного доступа

Защита данных включает в себя не только меры против действий легальных пользователей, но и борьбу с внешними угрозами, исходящими от злоумышленников или вредоносного ПО: внедрение SQL-кода через пользовательский ввод; атаки DdoS; попытки прямого доступа к файлам базы данных, минуя стандартные механизмы сервера.

Механизмы защиты в РЕД База Данных работают на разных уровнях: от сетевого периметра и параметризованных запросов до контроля целостности данных и очистки памяти.

SQL-инъекция — внедрение вредоносного SQL-кода в запрос через пользовательский ввод. Основным механизмом защиты является использование параметризованных запросов. Подход основывается на разделении структуры запроса и пользовательских данных на этапе их взаимодействия с сервером. Приложение передает на сервер шаблон запроса, в котором места подстановки конкретных значений обозначены специальными маркерами. Сервер компилирует шаблон, определяя логическую структуру планируемой операции. После этого передаются сами значения, которые подставляются в готовый и уже проанализированный запрос. Поскольку структура запроса фиксируется на момент подстановки и не подлежит изменению, любые данные, предоставленные пользователем, интерпретируются исключительно как значения, а не как элементы исполняемого кода. Попытка внедрения служебных символов или SQL-команд в такие данные не приводит к изменению логики исходного запроса, поскольку они воспринимаются системой как обычные строковые литералы.

Система разграничения прав доступа. В случае внедрения вредоносного кода возможные операции ограничены правами учетной записи. Если учетная запись не имеет прав на деструктивные действия, система их блокирует. Это реализуется по принципу минимальных привилегий — приложения получают только необходимые им права. Система аудита может фиксировать все неудачные попытки, помогая выявлять подозрительную активность.

Помимо защиты от целенаправленных попыток внедрения вредоносного кода, РЕД База Данных оснащена средствами, предотвращающими нарушения доступности системы и пресекающими попытки несанкционированного проникновения. Эти механизмы работают на разных уровнях — от сетевого взаимодействия до управления учетными записями.

DDoS-атаки. В РЕД Базе Данных имеются средства снижения ущерба от таких атак и обеспечения стабильной работы системы. Прежде всего речь идет о системе управления сетевыми подключениями — администратор может ограничить доступ к серверу посредством параметра RemoteBindAddress, который определяет список допустимых сетевых интерфейсов для входящих соединений. Кроме того, имеется возможность модификации стандартного порта подключения, указанного параметром RemoteServicePort. Функция усложняет задачу злоумышленникам, пытающихся идентифицировать сервер посредством автоматизированных сетевых сканеров, так как изменяется стандартный порт, ожидаемый для установки соединения.

На уровне соединений установлены ограничения времени — параметр ConnectionTimeout определяет предельное время ожидания соединения. По его истечении неудачная попытка соединения прерывается. Эта мера предотвращает ситуации, при которых большое количество незавершенных подключений приводит к исчерпанию ресурсов сервера. Для уже установленных, но неактивных соединений предусмотрен параметр ConnectionIdleTimeout. По истечении установленного интервала такие соединения разрываются, освобождая ресурсы.

Параметр LoginFailureDelay задерживает подключение к базе данных при превышении максимального числа неудачных попыток аутентификации, что усложняет автоматизированный перебор паролей. Вместе с политиками безопасности, блокирующими учетную запись после определенного числа попыток, формируется надежный барьер против атак.

Защита от несанкционированного доступа основывается на идентификации и аутентификации, разграничении доступа к файлам, а также контроле целостности данных. Пользователь должен предоставить учетные данные и подтвердить личность с помощью одного или нескольких факторов. Система поддерживает различные методы аутентификации, включая SRP и цифровые сертификаты. Успешная аутентификация необходима, но не достаточна для доступа к базе данных.

Важную роль играет разграничение доступа на уровне файловой системы. В ОС семейства Linux серверный процесс функционирует от имени пользователя reddatabase. Права доступа к файлам базы данных, конфигурационным файлам и журналам аудита должны быть настроены так, чтобы только этот пользователь имел разрешения на чтение и запись. Прямой доступ к файлам базы данных для других пользователей ОС ограничен, что предотвращает несанкционированное копирование или модификацию данных, минуя сервер.

На уровне серверного управления доступом к файлам баз данных применяется параметр DatabaseAccess. Администратор ограничивает перечень каталогов, в которых сервер имеет право открывать файлы баз данных. Это предотвращает несанкционированный доступ к файлам, расположенным за пределами разрешенных каталогов. Также этот параметр можно установить в значение NONE, что запретит доступ к файлам баз данных по полным путям. В результате возможным останется только доступ по псевдонимам, описанным в файле databases.conf администратором СУБД. Аналогичный механизм контроля доступа реализован для внешних таблиц и библиотек пользовательских функций.

Механизм контроля целостности файлов сервера обеспечивает дополнительную защиту СУБД. Администратор может генерировать контрольные суммы (хэши) для критически важных файлов сервера. При обнаружении несоответствия между вычисленной и эталонной контрольной суммой система регистрирует нарушение целостности и принудительно останавливает сервер. Параметр конфигурации IntegrityShutdownAttempts при этом задает количество попыток «мягко» остановить сервер, завершив все подключения и освободив используемые ресурсы. Если попытки остановить сервер не срабатывают, он немедленно останавливается принудительно. Это предотвращает несанкционированную модификацию файлов и внедрение вредоносного кода.

Наконец, важную роль играет очистка освобождаемых ресурсов. Параметр MemoryWipePasses анонимизирует оперативную память и дисковое пространство после удаления данных или освобождения используемой памяти. Это предотвращает несанкционированное чтение конфиденциальной информации с помощью специализированных программ.

***

Сегодня СУБД РЕД База Данных — полноценный центр обеспечения безопасности данных, в котором каждый механизм работает на их защиту, начиная от многофакторной аутентификации и прозрачного шифрования по ГОСТ и заканчивая параметризованными запросами, отражающими SQL-инъекции еще на этапе компиляции. В СУБД реализован полный стек технологий поддержки выполнения требований ФСТЭК: ролевая модель, аудит, очистка памяти и контроль целостности. Это позволяет применять СУБД в самых требовательных средах — от объектов критической информационной инфраструктуры до государственных информационных систем, где обязательна сертификация по 4-му классу защиты и 4-му уровню доверия.

Роман Симаков (roman.simakov@red-soft.ru) — заместитель директора дивизиона системного программного обеспечения, РЕД СОФТ (Москва).