В СУБД Jatoba есть обфускация процедур, проработанная парольная политика, в open-source — этого нет

Денис Рожков, руководитель разработки из компании "Газинформсервис", рассказал Anti-Malware.ru о представленной в октябре 2019 года системе управления базами данных (СУБД) Jatoba. Во время беседы мы узнали о том, зачем нужна ещё одна отечественная СУБД и в чём заключается её технологическое преимущество, а также поговорили о тенденциях в данном сегменте на мировом и российском рынках.

Основная тема беседы — новый продукт "Газинформсервиса", СУБД Jatoba. В начале марта компания представила эту разработку публике. Расскажите немного об истории этого продукта. Зачем в России понадобилась ещё одна отечественная СУБД?

Д.Р.: Мы достаточно долго и основательно разрабатывали этот продукт, прежде чем представить его рынку.

Тематика импортозамещения актуальна не первый год; она коснулась и наших заказчиков, и нас как производителей программных продуктов. В связи с этим вопрос замещения, в частности, Oracle Database стоял давно. Oracle — основная RDBMS (объектно-реляционная система управления базами данных — прим. ред.), которую использовали мы в своих продуктах и, соответственно, заказчики в наших проектах. Мы прорабатывали возможность замены этой СУБД в разного рода решениях с разной степенью загрузки: где-то этого можно было достичь легко, где-то — не очень. Но так или иначе эта задача нас давно волновала. Чтобы точечно решать задачи проектов, нам как большой компании необходимы были единообразие и универсальный подход. Поэтому мы рассматривали несколько вариантов: переход на имеющуюся отечественную разработку, которая бы удовлетворяла нашим требованиям; написание собственной СУБД с нуля; использование open source-решения.

Создавать с нуля СУБД сейчас возможно, но нецелесообразно, потому что есть проверенные open-source решения, которые достаточно зрелы: с хорошей историей, с качественной проработкой и с надёжным кодом. Однако из готовых решений с открытым исходным кодом найти те, которые бы подошли для сегмента Enterprise, к сожалению, практически невозможно.

У нас был опыт использования open-source в своих инсталляциях. Соответственно, был опыт настройки и выявления проблем — мы понимали причины, по которым в чистом виде эти решения нам не подходили. Кроме того, мы столкнулись с ситуацией, когда в отечественном сегменте найти вендора, который бы полностью удовлетворял наши потребности — как в части обеспечения отказоустойчивости, так и в части, касающейся оказания качественного сервиса, — оказалось нереально. Не всегда вендор в рамках техподдержки готов устранять проблемы в проданном коробочном продукте, а если и готов, то делает это не так быстро, как этого требуют наши заказчики. Поэтому нам приходилось, купив коробочное решение, самостоятельно заниматься кастомизацией и сопровождением. В связи с этим возникал вопрос: а зачем тогда покупать, если всё равно приходится самим разбираться и «ковыряться» в нюансах?

Тогда уточним: тот же Oracle не устраивал вас по каким соображениям? Из-за цены или стремления к импортозамещению?

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

Почему тогда не подходил PostgreSQL? Ведь это — весьма популярная СУБД, и если говорить об open-source, то, наверное, — самая лучшая. Почему её нельзя было использовать в работе?

Д.Р.: PostgreSQL как "ванильное" open source-решение можно применять в небольших проектах. Но для сегмента Enterprise "ванильная" версия не подходит. В то время, когда мы начали заниматься разработкой, это были версии 9-10 PostgreSQL.

Приведу конкретный пример. Мы столкнулись с проблемой хранения большого объёма данных в таблице: вопрос секционирования в предыдущих версиях был недостаточно проработан. Поэтому приходилось использовать какие-то другие решения, самим заниматься тонкими настройками; так мы и получили этот опыт. Просто взять и начать использовать "ванильную" версию нам не удалось.

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

Мы выполнили те доработки, которые были важны для нас в имеющихся проектах, и начали тестировать в организациях, в которых был интерес к аналогичному решению (до сих пор собираем bad-log в заинтересованных компаниях).

В основе лежит код PostgreSQL?

Д.Р.: Да, мы этого не скрываем. Это — PostgreSQL, которую мы дорабатываем. Мы базируемся на ядре 11.5 этой СУБД. Продукт по-прежнему развивается, мы идём параллельно с open source-версией, сопровождая реализуемые нами доработки. Нюанс заключается в том, что мы содержим всё на своей инфраструктуре. Мы не берём напрямую то, что выложено на GitHub — мы разворачиваем всё у себя, проводим операции по валидации и проверке кода в соответствии с требованиями и компилируем у себя, на своей инфраструктуре. Первый этап, который мы выполняли в части разработки ПО, — возможность полностью автономного развития продукта. В данный момент мы это полностью реализовали, то есть мы храним, собираем и тестируем код на своих серверах в рамках регламента безопасной разработки, проверяем на наличие уязвимостей — проводим статический анализ кода, регрессионные тесты. Если в open-source выходит что-то новое, то мы на эти изменения смотрим, решаем, есть ли необходимость их внедрения в наши проекты, и внедряем их в наш продукт, если такая потребность появилась.

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

Есть ли сертификат ФСТЭК на Jatoba?

Д.Р.: На данный момент мы — в стадии сертификации. В марте испытательная лаборатория приступила к сертификационным испытаниям Jatoba в соответствии с решением ФСТЭК России. Планируем получить его к осени 2020 года. Основной отечественный тренд в ИБ — импортозамещение. А какие тенденции можно отметить на рынке СУБД? Д.Р.: Мировые тренды давно понятны и очевидны: все переезжают из собственной инфраструктуры в облачную. Это видно по тем доработкам, которые в последнее время выполнялись крупными вендорами. В российском сегменте это менее заметно и очевидно: у нас кроме того, что есть некоторая задержка в технологических решениях, имеется закостенелый подход к использованию собственной инфраструктуры. Существует определённое недоверие к облакам. Многие enterprise-заказчики не готовы к тому, что их данные будут храниться где-то за пределами их инфраструктуры. И надо отдать должное — не без оснований не готовы.

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

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

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

Ранее компетенция администратора RDBMS была ключевым нюансом всей системы. От того, как правильно администратор всё настроил, насколько быстро и адекватно он отреагирует в случае нештатной ситуации, зависело очень многое. Сейчас эти процедуры в большей степени автоматизируются.

Это — тоже одно из направлений развития сферы, так называемые автономные базы данных, когда БД проверяет без привлечения персонала своё "самочувствие", сигнализирует об изменениях, самостоятельно устанавливает патчи и реагирует на какие-то проблемы. Например, процедура восстановления резервного сервера после failover может происходить автоматически.

А эти интересные решения уже начали реализовываться в Jatoba?

Д.Р.: Да, нам пришлось создавать отдельный компонент, обеспечивающий отказоустойчивость. В сообществе open-source есть решения, которые могут делать что-то подобное, но мы чаще всего работаем в кластерных системах (это — не просто одна база данных, а как минимум основная и запасная), и, соответственно, возникает вопрос: кто и что делает в случае аварии?

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

Возникли ли какие-то технические ограничения и сложности при разработке собственной СУБД?

Д.Р.: Были проблемы, которые были понятны, но для них не было готовых решений — к примеру, парольные политики. Есть определённые (и вполне понятные) требования ФСТЭК России по реализации парольных политик в ПО. Готовых решений нет в "ванильной" версии, но есть разрозненные открытые проекты, в которых частично реализованы те или иные аспекты политики. Нормальной парольной политики, которая бы удовлетворяла и регулятора, и корпоративный сегмент, не было ни у кого, в связи с чем мы приняли решение о её реализации собственными силами.

Есть также и концептуальные нюансы, с которыми мы сталкиваемся на практике: это — как раз оптимизация СУБД при работе с большими данными. Хранить много ретроспективных данных — одну таблицу размером в несколько сотен гигабайт — было уже проблемой для «ванильной» версии. В сегодняшней версии PostgreSQL эта проблема, правда, не так актуальна, но в версиях 9-10 она имела место, и нам приходилось искать очень нетривиальные решения, которые бы позволяли комфортно работать как на небольших, так и на средних объёмах данных. Это — один из нюансов.

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

А каковы основные риски? На что в первую очередь необходимо обратить внимание заказчику при выборе средств защиты своей СУБД?

Д.Р.: Это напрямую зависит от специфики заказчика и его инфраструктуры. Если она — собственная, то решения одни; если облачная, то совсем другие.

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

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

Какие функции защиты реализованы в текущей версии?

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

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

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

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

Кроме обфускации нам приходилось работать с парольной политикой и расширением аудита. Аудит "ванильной" версии для нас был недостаточен, поэтому нам приходилось либо искать какие-то решения, либо писать свой дополнительный аудит. Даже PGAudit в ряде случаев работает не так корректно, как нам хотелось бы.

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

Шифрование данных в самой СУБД не осуществляется?

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

Понимание того, как приблизить PGCryptо к шифрованию по ГОСТ, есть, но актуальность этой разработки сейчас — под вопросом.

А что можно сказать по поводу зашифрованного удалённого подключения к СУБД?

Д.Р.: Как мы говорили, СУБД часто переезжает в облако. Если раньше защищённый периметр между приложением и СУБД создавался с помощью программно-аппаратных средств (настройки VPN, разбивки на VLAN и т.д.), то сейчас распространяется использование SSL, поскольку подключение по открытым протоколам ненадёжно. Поддержка OpenSSL есть и в «ванильной» версии, это — не наша заслуга. Единственное — что отечественная специфика нам ближе, и мы работаем в этом направлении. Однако говорить о том, что мы реализовали ГОСТ-шифрование при подключении к системе управления БД, пока рано.

Но это, насколько я понимаю, — общая тенденция? И законодательные инициативы нас подталкивают к тому, что рано или поздно придётся это реализовать?

Д.Р.: Если только с целью поставить галочку напротив пункта «Возможно использование SSL-подключения на базе ГОСТ-шифрования». Закрыть канал можно и другими средствами, и решений для этого достаточно. Стоит ли это делать на уровне СУБД? Если вы работаете через пуллинг, то обычный ("неГОСТовый") SSL особой нагрузки на создание соединения сейчас не создаёт. Впрочем, для наших заказчиков этот вопрос не так актуален: те, кто требует ГОСТ, — не в облаке, а тем, кто в облаке, не нужен ГОСТ. Поэтому мы используем и настраиваем OpenSSL, который есть в PostgreSQL, и нам, в принципе, его хватает.

Хотелось бы уточнить по поводу использования наложенных средств безопасности — например, специализированных DB Firewall или возможности подключения СУБД к IDM-системам. С какими продуктами тестировалась совместимость? Что, как показывает практика, было бы целесообразно использовать в качестве дополнительных мер защиты в комплексе с Jatoba?

Д.Р.: Мы сейчас находимся на стадии тестирования двух отечественных продуктов: "Крипто БД" (разработчик — "Аладдин Р.Д.") и "Гарда БД" (разработчик — "Гарда Технологии"). Говорить о завершении тестов пока рано, потому что мы — в процессе. Мы, как российская компания, сверяемся и налаживаем отношения с отечественными вендорами соответствующих технологических решений. Хотя, конечно, в том же Oracle есть проверенный RDBMS Firewall, который входит в инфраструктуру, и там всё выверено. Импортные решения — достаточно зрелые, а мы здесь выступаем в роли догоняющих.

Как обстоят дела с технической поддержкой? Для продуктов, базирующихся на open-source, это всегда было определённой проблемой. На что клиент может рассчитывать, покупая вашу СУБД? Какой уровень ТП ему будет оказываться?

Д.Р.: Я сейчас все SLA нашего сервисного центра не перечислю, но хотелось бы отметить следующее: наша компания 16 лет работает на отечественном рынке с крупными корпорациями, поэтому технология оказания сервисных услуг в enterprise-сегменте (даже с учётом ограничения доступа к площадкам заказчика) давно "обкатана". Чтобы обслуживать крупные компании, необходима распределённая сеть филиалов по всей стране. У "Газинформсервиса" есть такая сеть. Благодаря ей мы обеспечиваем бесперебойную оперативную техподдержку 24х7 для СУБД Jatoba и других наших продуктов. Телефоны горячей линии 8-800 всегда доступны. В случае необходимости мы организуем выезд наших инженеров для проведения регламентных, нештатных, аварийных процедур на площадках заказчиков.

На мой взгляд, мало кто в России может решать такие задачи. Простой данных по причине того, что инженер должен 12 часов ждать ближайший рейс из Москвы или Петербурга в Сибирь или на Урал, для наших заказчиков является неприемлемым. Поэтому наличие представителей в филиалах позволяет нам решать большинство вопросов с требуемым уровнем качества.

Если, например, станет известно об уязвимости в последней версии PostgreSQL, что вы будете делать? Вы будете ждать решения от сообщества или же самостоятельно предпринимать какие-либо действия для её закрытия и минимизации рисков?

Д.Р.: Тут ответ однозначен. И это — наше отличие от open-source. Мы обязаны по законодательству устранять выявленные уязвимости в определённый срок. Собственно говоря, компетенция инфраструктуры и уровень работы с самим программным продуктом должны именно этому требованию и отвечать. Если возникают проблемы, особенно касающиеся безопасности, выявленной уязвимости, то, конечно, они должны быть устранены в максимально короткий срок. Более того, в рамках даже не технической платной поддержки, а в рамках того, что продукт просто был у нас куплен, мы должны предоставить "заплатки" нашим заказчикам. И это — одна из задач нашей команды. Мы мониторим уязвимости PostgreSQL как в собственном банке данных угроз безопасности, так и в других БДУ (включая ФСТЭК). Если уязвимости выявляются, то мы проводим мероприятия по поиску готового способа их закрытия. Если готового решения нет либо оно нас не удовлетворяет, то мы его пишем сами.

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

Д.Р.: На этот год у нас есть непростая задача реализовать отказоустойчивое решение, схожее с Real Application Clusters (RAC) от Oracle, когда несколько узлов баз данных работают с единым хранилищем. Сможем ли мы выпустить эту "фичу" в 2020 году? — будем стараться.

Кроме этого у нас планируется выпуск утилиты, которая будет помогать администраторам оценивать уровень безопасности в СУБД и показывать те проблемы — именно безопасности, — которые мы автоматически можем выявить. Например, список пользователей, которые давно не меняли пароли; необходимость установки свежего патча; наличие данных, которые целесообразно каким-то образом защищать. Если мы видим персональные данные физических лиц (паспорт, Ф.И.О.), то мы вносим рекомендации о применении технологии RLS и маскирования к этим данным. Эта утилита у нас — в разработке, мы её планируем развить и выпустить в этом году. Она будет бесплатной для клиентов.

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