ИБ в новой реальности. Как меняется защита данных и инфраструктуры

Анна Ерманок, генеральный директор Picodata: «Сертификация больше не воспринимается как разовый формальный этап. Для вендора это постоянная работа с кодом, зависимостями, тестированием и актуализацией требований регулятора на всём жизненном цикле продукта».

Новый контур рисков

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

Этот сдвиг особенно заметен в системах реального времени, которые составляют основу в банковском секторе, у телеком-операторов, в государственных сервисах и в крупных цифровых платформах. В таких контурах широко распространены западные продукты, в частности, Redis и Cassandra, которые долгое время считались стандартом для высоконагруженных систем. Однако практика последних лет показала, что использование зрелых технологий вовсе не снимает с повестки вопросы безопасности и управляемости (например, CVE-2024-31449 в Redis, CVE-2025-23015 в Apache Cassandra и CVE-2024-10979 в PostgreSQL).

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

Регуляторная среда

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

Именно этот подход применяет Picodata (входит в Группу Arenadata) – поставщик одноимённой распределённой СУБД для критической инфраструктуры, совместимой с PostgreSQL, Redis и Cassandra.

Безопасность на уровне разработки

Если на раннем этапе формирования рынка получение сертификата часто воспринималось как разовый и формальный шаг, то сегодня сертификация, а главное – регулярная сертификация ФСТЭК всех обновлений, – невозможны без глубокого изменения процессов разработки, постоянной актуализации требований и сверки с отраслевой практикой.

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

Безопасность в такой модели охватывает не только собственный код, но и весь технологический стек. На практике такой подход реализуется через:

• опору на доверенную базу сертифицированных дистрибутивов там, где это возможно;
• индивидуальную проверку остальных зависимостей;
• разметку поверхности атаки для используемых компонентов;
• устранение потенциально уязвимых мест на основе отчётов инструментов статического анализа кода и опубликованных в базах CVE сведений;
• контроль библиотек и внешних модулей, которые во многих open source-продуктах поставляются вне системного контура ОС или включаются в статическую сборку;
• фаззинг-тестирование реализаций сетевых протоколов как постоянное требование к процессу разработки и проверки.

Существенную роль играет и выбор языков разработки. Многие новые функции Picodata написаны на Rust, что снижает класс рисков, связанных с ошибками управления памятью, и сокращает время на их выявление и отладку. Так как ядро продукта по-прежнему содержит компоненты на C, сама платформа поддерживает сборку и тестирование в режиме address sanitizer для всего кодового контура.

Эра консолидации

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

Именно здесь возникает запрос на консолидацию: требуется сократить число компонентов, сохранив совместимость с уже используемыми приложениями и привычными интерфейсами. В Picodata эта логика реализована через совместимость с Redis и Cassandra. Плагин Picodata Radix выступает как Redis-совместимый слой для защищённых контуров, а Picodata Sirin позволяет использовать Cassandra-сценарии без изменений в прикладном ПО.

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

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

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