Крупный бизнес не может себе позволить работать с бесплатными СУБД

Николай Нашивочников

На рынке присутствуют достаточно зрелые решения отечественных производителей, которые рассматриваются как дополнения к СУБД

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

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

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

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

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

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

Компания «Газинформсервис» более 16 лет занимается внедрением решений в сфере информационной безопасности. В нашем арсенале шесть линеек ИБ-продуктов собственной разработки. Во многом появление Jatoba связано с тем, что в рамках наших проектов мы не могли закрыть потребность в безопасной и функциональной СУБД за счет сторонних решений.

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

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

Николай Нашивочников

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

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

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

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

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

Ограничение доступа администратора к защищаемым данным было реализовано нами практически с нуля, так как в имеющихся на рынке продуктах (и в том числе — с открытым кодом) эта функция не реализована.

У нас было несколько крупных проектов по миграции решений с Oracle RDBMS на СУБД Jatoba, и тогда мы проработали варианты минимизации работ по изменению кода процедур и функций PL/SQL (Oracle). Мы использовали ряд расширений к СУБД Jatoba, которые позволили работать с глобальными сессионными переменными, использовать конструкции кода, специфичные для Oracle, а также псевдо-таблицу dual, функции работы с временем и датами, функции генерации случайных чисел и так далее. Схожие задачи мы решали для обеспечения большей совместимости с MS-SQL.

В конце 2019 года мы начали этап активного тестирования на совместимость СУБД Jatoba с продуктами наших партнеров. На данный момент уже проведены успешные тесты со СКУД АПК «Бастион-2», ПО для ЭВМ «Этос» от компании «Стройформ», гиперконвергентным комплексом «Скала-Р» производства Rubytech и др.

Также СУБД Jatoba была зарегистрирована в реестре российских программ для электронно-вычислительных машин и баз данных.

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

Николай Нашивочников

СУБД Jatoba построена на базе кода PosgreSQL, и мы этого никогда не скрывали

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

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

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

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

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

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

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

Также наши разработчики информируют сообщество о выявленных нами дефектах и предлагают варианты решений. Например, из последнего: нами был выявлен дефект, связанный с пересечением наименований идентификаторов переменных с ключевыми словами С++ в модулях процедурного языка PL/pgSQL.

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