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

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

Иван Панченко: Мы развиваем несколько функциональных направлений СУБД: безопасность, производительность, надежность, масштабируемость, облегчение миграции. В нашей флагманской версии, 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С», которые максимально адаптированы для работы с платформой и включают значительное количество оптимизаций.

Иван Панченко: Это так, релиз 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, и оптимизатор запросов. Будем выпускать их улучшения в течение года, не дожидаясь очередного мажорного релиза.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эта разработка потребовала серьезных исследований и глубоких изменений в коде, которые, к сожалению, почти невозможно перенести в ранние версии Postgres Pro, но все пользователи 16-й версии редакции Enterprise и ее сертифицированного варианта могут воспользоваться преимуществами защищенной схемы или, по-другому, опции «администратор без доступа к данным».

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

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

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

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

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

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