Иван Панченко, Postgres Pro: О вызовах в области безопасности СУБД и системе минимизации рисков

TAdviser: В линейке Postgres Pro сейчас 5 редакций СУБД. Какая из них сегодня более востребована российскими заказчиками и почему?

Иван Панченко: Линейка СУБД Postgres Pro отражает рыночный спрос на системы разного уровня. Postgres Pro Standard популярна среди средних компаний. Postgres Pro Enterprise — частый выбор для отказоустойчивых высокопроизводительных систем. Компании, которые предъявляют высокие требования к инфобезопасности, выбирают сертифицированные версии этих редакций — Postgres Pro Enterprise Certified и Postgres Pro (Standard) Certified. А по запросу крупных заказчиков с базами данных в десятки и сотни ТБ мы совсем недавно представили нашу новую распределенную реляционную СУБД Postgres Pro Shardman. Требования и приоритеты у всех разные, важно дать возможность каждому решить задачи с помощью оптимальной редакции.

TAdviser: Все редакции СУБД основаны на базе PostgreSQL. Чем они отличаются от опенсорсной системы?

Иван Панченко: Мы развиваем несколько функциональных направлений СУБД: безопасность, производительность, надежность, масштабируемость, облегчение миграции. В нашей флагманской версии, Postgres Pro Enterprise, больше 100 разработок для удовлетворения требований крупных заказчиков. Среди ключевых: механизм сжатия данных CFS, который позволяет в разы сократить объем базы данных; 64-разрядный счетчик транзакций для решения характерной для PostgreSQL проблемы зацикливания счетчика транзакций; приоритизация ресурсов, модуль анализа исторической нагрузки для поиска ресурсоемких операций pgpro_pwr, расширение Multimaster, превращающее СУБД в синхронный кластер active-active без разделения ресурсов; интеграция с расширением Citus для обработки аналитических данных; инкрементальный бэкап, позволяющий быстро сбрасывать на диск только те данные, которые изменились с момента снятия полной резервной копии. Отмечу, что в открытой версии PostgreSQL тоже есть такая возможность, но для этого нужно прочесть все журналы изменений, произошедших с момента предыдущего полного бэкапа, которых может быть очень много. У нас же данные о том, какие блоки базы данных изменились с прошлого раза, копятся непосредственно в самой базе, поэтому инкрементальный бэкап можно получить мгновенно.

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

Подобного рода изменений в сравнении с открытой версией Postgres у нас очень много, в том числе механизмы для оптимизации, созданные с учетом особенностей конкретных SQL-запросов, например, в «1С», других сложных системах. К слову, Postgres Pro — первая российская СУБД, полностью совместимая с «1С:Предприятие». Мы давно выпускаем специальные версии для «1С», которые максимально адаптированы для работы с платформой и включают значительное количество оптимизаций.

TAdviser: Совсем недавно вышла новая версия СУБД — Postgres Pro Enterprise 16, которую вы назвали рекордной по количеству новых доработок. Что туда вошло?

Иван Панченко: Это так, релиз Postgres Pro Enterprise 16 стал самым масштабным за последние несколько лет по количеству новых разработок. Одна из важных функций — встроенная система отказоустойчивого управления кластером (Built-in High Availability или кратко BiHA). Раньше для того, чтобы создать на базе Postgres отказоустойчивый кластер, использовались системы сторонних разработчиков, как правило — Open Source.

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

В 16 версию Enterprise также вошла новая версия адаптивного оптимизатора планов запросов, который, во-первых, стал удобнее в применении, а во-вторых, стал лучше обучаться. Это простейшая система машинного обучения, которая подсказывает, какой план запросов будет оптимальным. Адаптивный оптимизатор планов запросов позволяет получать информацию из БД эффективней и быстрей.

Еще мы выпустили графический пользовательский интерфейс для управления кластерами — Postgres Pro Enterprise Manager (PPEM). Это платформа, которая в режиме «единого окна» позволяет администратором любого уровня подготовки управлять большим количеством серверов Postgres Pro. Отмечу, что мы продолжаем активно совершенствовать и BiHA, и PPEM, и оптимизатор запросов. Будем выпускать их улучшения в течение года, не дожидаясь очередного мажорного релиза.

TAdviser: К слову о релизах… Postgres Pro — единственная российская СУБД, обновленные версии которой выходят уже через несколько недель после выхода открытой СУБД PostgreSQL. Рекордные для рынка сроки. Почему это важно?

Иван Панченко: Мы постоянно работаем над тем, чтобы сокращать разрыв между выходами релизов PostgreSQL и Postgres Pro. Новые ванильные версии возникают не просто так: в них исправляются уязвимости, присутствуют важные доработки — фичи, которые должны вовремя — а лучше первыми — получать наши заказчики. Если прекратить забирать изменения из СУБД с открытым кодом, через какое-то время коммерческие продукты на ее основе неизбежно устареют и станут представлять серьезную угрозу для информационных систем заказчиков. Нам, как разработчику, важно обеспечить максимальную защиту и свести любые риски к минимуму.

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

TAdviser: Насколько сложно поддерживать такую частоту обновлений?

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

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

Для заказчика идеально, если строго соблюдаются два условия:

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

Мы научились делать и то, и другое. Это достаточно трудоемко, но по-другому качественным вендором не будешь.

TAdviser: Можно предположить, что наличие большого количества изменений в Postgres Pro усложняет выпуск релизов…

Иван Панченко: Действительно, усложняет, поскольку стоит задача своевременно добавлять в коммерческую СУБД актуальные обновления базовой системы с открытым кодом. Раньше мы проводили большое сравнение слияний изменений раз в год, когда выходила новая версия Open Source. Это был довольно сложный процесс, поскольку изменений было много, а часть из них в некоторых случаях даже могла противоречить друг другу. Поэтому несколько лет назад мы перешли к практике непрерывного слияния изменений. Делаем это постоянно, практически ежедневно, как только изменения принимаются в открытой версии. Благодаря такому подходу мы свели техническое отставание к минимуму: выпускаем обновленную версию Postgres Pro Standard всего через несколько дней после выхода PostgreSQL, а Postgres Pro Enterprise — через несколько недель.

TAdviser: Как устроен релизный цикл в Postgres Professional? Сколько релизов вы выпускаете в год?

Иван Панченко: Мы отталкиваемся от релизного цикла PostgreSQL. Примерно раз в год выходит мажорная ванильная версия под новым номером, затем к каждой мажорной версии ежеквартально выходят четыре минорных обновления, содержащие, как правило, исправления. Если вдруг выявляются критические уязвимости, то выпускаются внеочередные релизы PostgreSQL.

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

Мы одновременно поддерживаем пять мажорных версий Postgres Pro, поскольку цикл жизни каждой из них составляет пять лет. По каждой мажорной версии в год выпускается четыре минорных обновления — это уже двадцать релизов. У нас пять редакций СУБД — Postgres Pro Enterprise, Postgres Pro Enterprise Certified, Postgres Pro Standard, Postgres Pro Certified, Postgres Pro Shardman, умножаем еще на пять — получаем 100 релизов. Кроме того, делаются доработки под разные ОС, процессоры. Таким образом, мы выпускаем в год несколько сотен релизов, десятки тысяч пакетов обновлений: больше 58 000 в 2023 году.

TAdviser: Есть у нового подхода к релизному циклу свои особенные сложности?

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

TAdviser: Как выстроен процесс тестирования новых релизов на ошибки?

Иван Панченко: Тестирование кода начинается уже на этапе разработки. После решения о принятии новых разработок в очередной релиз, наши разработчики собирают их воедино, обеспечивают их совместимость и проводят интеграционное тестирование предварительно собранного продукта. Затем разработки поступают на окончательную сборку нового релиза.

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

TAdviser: Совсем недавно вы объявили о выходе в широкое пользование новой СУБД Shardman. Чем она отличается от других продуктов и какие задачи решает?

Иван Панченко: Postgres Pro Shardman решает задачи построения горизонтально масштабируемого отказоустойчивого кластера до сотни серверов. Эту СУБД мы создали специально по запросу крупных заказчиков, чьи системы находятся под высокой транзакционной нагрузкой, с которой один сервер не способен справиться. В этом случае база данных распределяется на несколько серверов, чтобы каждый из них работал со своей частью базы — это называется шардингом.

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

TAdviser: К слову о ФСТЭК — Postgres Pro уже сертифицирована по новым стандартам безопасности от 2023 года?

Иван Панченко: Да, осенью 2023 года. Подчеркну, что Postgres Pro — первая российская СУБД, сертифицированная по новым правилам.

TAdviser: Каких доработок потребовала сертификация?

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

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

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

Это более надежный и понятный подход, когда «что не разрешено, то запрещено».

TAdviser: А что же вы сделали с суперпользователем?

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

TAdviser: Какие еще доработки потребовались для удовлетворения требований ФСТЭК?

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

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

TAdviser: Обращались ли к вам заказчики с просьбами разработать какой-нибудь функционал, связанный с информационной безопасностью?

Иван Панченко: Вопрос хороший, но во многом терминологический. Времена меняются, слова порой приобретают другой смысл, поэтому возникают новые термины. Следует понимать, что, когда говорят о безопасности, никогда не подразумевается 100%-ная гарантия отсутствия рисков.

Обеспечить абсолютную безопасность невозможно нигде и никогда.

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

TAdviser: То есть, можно сказать, что появление нового термина связано, скорее, с маркетинговыми активностями и желанием выделить свой продукт на рынке?

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

TAdviser: Какие планы по развитию Postgres Pro ставите на 2024 год?

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