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

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

Открытый код ответственности не снимает

Безусловно, у продукта с открытой кодовой базой есть сильные стороны: прозрачность архитектуры, возможность независимого анализа, использование зрелых компонентов, скорость развития экосистемы. Но для поставщика решений это не упрощает, а усложняет задачу обеспечения безопасности. Если поставщик строит СУБД на основе открытого кода, то отвечает не за абстрактный проект, а за собственный форк, за состав зависимостей, за процедуру сборки и за то, как именно в его поставку попадают исправления уязвимостей. С практической точки зрения это означает, что компонент Open Source становится безопасным не потому, что его код открыт, а потому, что над ним выстроен строгий контур сопровождения.

Закрытый код, в свою очередь, облегчает централизованный контроль изменений, но не избавляет поставщика от тех же самых обязанностей. Заказчику не важно, видит или нет он исходники в публичном репозитории, — ему важно, что делает вендор после выхода очередной базы данных известных уязвимостей (Common Vulnerabilities and Exposures, CVE), как валидирует исправления, как документирует состав поставки и как подтверждает, что новая версия не нарушила ранее заявленные свойства безопасности. Поэтому для КИИ вопрос должен ставиться так: не открытое или проприетарное ПО, а кто несет полную ответственность за безопасность конкретного экземпляра продукта. Это особенно важно для современных распределенных СУБД, которые опираются на десятки библиотек и подсистем. Уязвимость может находиться не в SQL-слое и не в механизме репликации, а в библиотеке компрессии, криптографии, сериализации или сетевого обмена. Если продукт собирается с собственным набором зависимостей или часть библиотек статически включается в дистрибутив, то дефект в стороннем компоненте становится дефектом всей СУБД. Для атакующего это одна поверхность атаки. Для вендора — это один контур ответственности.

Где начинается внешняя угроза?

Классическая модель «поставим средство защиты информации (СЗИ) вокруг базы и закроем вопрос» давно не работает. В распределенной СУБД поверхность атаки многослойна: клиентские протоколы, межузловой обмен, интерфейсы администрирования, резервное копирование, инъекции SQL, плагины, механизмы аутентификации и сам исполняемый код. Защита должна строиться по принципу многих уровней.

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

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

Третий уровень — защита от дефектов в коде самой СУБД. И здесь происхождение продукта становится важным. Если наиболее чувствительные участки — парсеры протоколов, сетевые обработчики, плагины, логика разбора внешнего ввода — реализуются на языках, снижающих риск ошибок работы с памятью, часть атак отсеивается на уровне компиляции и формальной валидации программного кода. Но полностью уйти от исторического кода на Cи зрелые СУБД обычно не могут, поэтому поверх архитектурного выбора должен быть второй контур: статический анализ, фаззинг, тестирование с санитайзерами, контроль покрытия кода и повторная верификация после каждого значимого изменения. Например, в Picodata новые функции проходят проверку с учетом требований ИБ еще до этапа реализации. На уровне разработки это означает статический анализ кода, мониторинг CVE в используемых компонентах, фаззинг-тестирование чувствительных модулей и сборку кодового контура в режимах, позволяющих выявлять ошибки работы с памятью еще до выхода релиза. Смысл этого подхода в том, что безопасность рассматривается не как финальная проверка, а как свойство всего жизненного цикла программной системы.

За границей полномочий администратора

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

Первый — минимизация полномочий в ролевой модели СУБД. У администратора не должно быть больше прав, чем необходимо для его роли. Чем выше гранулярность модели доступа к ресурсам (Role-Based Access Control, RBAC), тем меньше вероятность, что учетная запись, наделенная высокими полномочиями для выполнения работ по эксплуатации, получит доступ к журналу аудита или сможет выполнить прикладной код.

Второй — разделение обязанностей на уровне организации. Администрирование, управление ключами, доступ к прикладным данным и аудит действий должны по возможности находиться в разных руках. Если организация действительно хочет скрыть наиболее чувствительные поля даже от части своих операторов инфраструктуры, это обычно означает вынесение части криптографического контура в приложение, аппаратный модуль безопасности (Hardware Security Module, HSM) или внешний сервис управления ключами. Сама СУБД в такой модели становится участником защищенной схемы, а не ее единственным гарантом.

Третий — избирательный, а при необходимости полный аудит. Логировать все подряд дорого и не всегда полезно. Практичнее включать детальный аудит в отношении привилегированных учетных записей и критичных операций: изменение ролей, доступ к системным таблицам, смена конфигурации безопасности, чувствительные операции управления и манипулирования данными в реляционных базах (Data Manipulation Language, DML). Такой подход лучше соответствует реальным сценариям расследования и не снижает производительность.

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

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

Безопасность vs производительность

Для систем реального времени вопрос защищенности решается в контексте цены защитных мер — любое журналирование, шифрование, проверка политик доступа и дополнительная верификация создают накладные расходы. В высоконагруженной системе их нельзя игнорировать, иначе безопасность начнет восприниматься как прямая угроза эксплуатационным характеристикам — всегда нужен баланс. Внешние и межузловые соединения должны быть защищены по умолчанию, но аудит следует настраивать избирательно. Наиболее уязвимые участки кода должны реализовываться с упором на обеспечение безопасности памяти, но это не означает переписывание всего зрелого ядра любой ценой. Статический анализ и санитайзеры должны использоваться на этапе тестирования и сборки, а не как накладной механизм в промышленной эксплуатации. Иными словами, безопасность должна быть встроена в конструкцию системы так, чтобы не превращаться в постоянный штраф к SLA. Это еще одна причина, по которой для КИИ все чаще обсуждается консолидация технологического ландшафта. Когда организация одновременно эксплуатирует отдельную СУБД, отдельный кэш, отдельное поколоночное хранилище и отдельные инструменты контроля доступа для каждого из компонентов, у нее множатся контрольные контуры, расходятся политики доступа, усложняется аудит и увеличивается объем обновлений.

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

Проверка зрелости: регулятор

Для российских объектов КИИ разговор о безопасности невозможно вести вне контекста регуляторики. Например, ФСТЭК не интересует происхождение кода, а важна подтверждаемая способность продукта соответствовать требованиям по разработке, тестированию, сопровождению и защите. Именно поэтому сертификация сегодня уже не воспринимается как разовый формальный этап. Для вендора это постоянная работа с кодом, зависимостями, тестированием и актуализацией требований регулятора на протяжении всего жизненного цикла продукта. Меняется и смысл повторной сертификации — это уже не бюрократическая нагрузка к следующему релизу ПО, а показатель того, что поставщик способен развивать продукт без потери заявленного уровня доверия. Для заказчика — это один из немногих объективных индикаторов зрелости: умеет ли вендор не только выпустить безопасную версию, но и непрерывно поддерживать ее после появления новых функций, зависимостей и уязвимостей.

Опыт Picodata

Архитектура Picodata. L — ведущий, F — ведомый

Picodata — российская распределенная реляционная СУБД для критической инфраструктуры. Платформа совместима с PostgreSQL и расширяется плагинами Radix и Sirin, добавляющими совместимость с СУБД ключ-значение Redis и поколоночной СУБД Cassandra. Picodata представляет собой кластер shard-per-core (см. рисунок): каждый инстанс (шард данных) работает на отдельном процессорном ядре, имеет собственные память, файлы и журнал транзакций, а отказоустойчивость обеспечивается за счет шардирования и синхронной репликации.

Защита от внешних угроз в СУБД реализована на всех слоях архитектуры. База данных предоставляет ролевую модель, совместимую с PostgreSQL. Для управления паролями учетных записей предоставляются настройки парольных политик. Авторизация реализована нативно для каждого поддерживаемого протокола (Redis, Cassandra, PostgreSQL) и работает с общей пользовательской базой. Возможна интеграция с внешними системами управления идентификацией пользователей (Identity Access Manager) по протоколу LDAP/LDAPS. Доступ к графическому пользовательскому интерфейсу и мониторингу также использует шифрование HTTPS, шифруется и внутрикластерный трафик (TLS). Возможна взаимная авторизация клиента и сервера (mTLS).

Защита от инсайдерских угроз в Picodata строится вокруг разграничения полномочий, централизуемого аудита и контроля целостности. В функциональном наборе безопасности прямо указаны роли администратора СУБД, администратора и пользователя базы, а также дискреционный и ролевой методы управления доступом. На каждом инстансе можно включить журнал аудита, параметры которого задаются централизованно, а вывод возможен в файл; протокол для сбора, передачи и хранения сообщений журналов (syslog) или через внешний процесс-коллектор. При этом аудит DML-операций включается выборочно, через AUDIT POLICY, что позволяет не создавать избыточную нагрузку на высоконагруженные системы. Контроль целостности охватывает конфигурацию СУБД, конфигурацию базы данных, исполняемый код и хранимые процедуры. При повторном запуске валидируются журналы *.xlog/*.snap, а в защищенной ОС дополнительно используются проверка контрольных сумм и регулярный контроль файловых объектов не реже одного раза в сутки. Факты нарушения целостности фиксируются в журнале аудита.

Существенная часть защитных свойств обеспечивается еще до ввода СУБД в эксплуатацию. Для сертифицируемой поставки применяются статический анализ собственного кода, плагинов и зависимостей, разметка компонентов, обрабатывающих внешние данные, динамическое тестирование со сбором покрытия, тестирование с санитайзерами и фаззинг наиболее чувствительных узлов, прежде всего реализаций сетевых протоколов. Многие новые функции реализуются на языке Rust, что сокращает класс ошибок работы с памятью; при этом для ядра на Cи поддерживается сборка в режиме AddressSanitizer для обнаружения ошибок работы с памятью.

СУБД Picodata имеет сертификат ФСТЭК России по четвертому уровню доверия на продукт и по шестому уровню доверия на ядро.

***

Выбор СУБД для КИИ — это ответы на конкретные вопросы: кто и как контролирует включение изменений в репозиторий исходного кода проекта; как осуществляется контроль подключаемых библиотек и устранение уязвимостей; соответствуют ли средства разграничения доступа требованиям Приказа ФСТЭК России № 64 от 14.04.2023. Шифрование всех клиентских соединений выходит за рамки требований ФСТЭК, поэтому его наличие следует уточнить явно. Заявленные функции аудита должны выдерживать промышленные сценарии эксплуатации, а ранее декларируемые свойства ПО в части безопасности должны сохраняться и после выпуска обновлений, появления новых функций и прохождения очередного цикла сертификации. Если поставщик способен предметно ответить на эти вопросы, продукт заслуживает дальнейшего рассмотрения. При этом открытость кода значения не имеет — важно наличие у вендора экспертизы во всех аспектах развития и эксплуатации СУБД. Именно экспертиза вендора в конечном итоге определяет, насколько итоговая промышленная система устойчива к внешним атакам, внутренним злоупотреблениям и ошибкам собственных компонентов. И именно она позволяет удерживать баланс между защищенностью и производительностью, без которого СУБД не может считаться пригодной для критических внедрений.

Анна Ерманок (anna@picodata.io) — генеральный директор, Picodata (Москва).