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

Ценность и самоценность ПО

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

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

  • Технические проблемы (сбой питания, обрыв сети, поломка оборудования).
  • Организационные проблемы, возникающие в ходе эксплуатации и связанные с некорректным взаимодействием пользователей с АС или обслуживающего персонала с используемым ПО. Сюда же следует отнести попытку несанкционированного доступа, DDoS-атаку и пр.
  • Технологические проблемы и дефекты, когда в самой системе или используемом ПО изначально была ошибка, которая не проявлялась и не была ранее обнаружена.

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

Наименее вероятны технологические проблемы и дефекты ПО, однако именно они наиболее критичны, поскольку потенциально могут приводить к серьезным последствиям, вплоть до неработоспособности АС в целом. Такие проблемы по определению нельзя ни смоделировать, ни заранее проверить на этапе тестирования и внедрения системы.

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

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

Ключевым здесь является то, что сообщество Open Source рассматривается как некий Оракул с безграничными возможностями [1], способный решить любую возникающую проблему, что, безусловно, подкупает своей красотой и лаконичностью. Однако бизнесу важна не абстрактная красота идей, а гарантированное решение конкретных проблем за четко обозначенное время. Важно понимать, каким образом для открытого ПО могут быть обеспечены требуемые гарантии.

Свобода, равенство, братство

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

Эти постулаты были взяты за основу еще на заре развития ИТ, когда разработкой ПО занималось небольшое число университетских лабораторий — все происходило в русле научных исследований и отвечало логике их функционирования: научные результаты (в том числе исходный код) должны быть доступны, публичны, проверяемы, свободно повторно используемы и пр. Но тут возникает нюанс — если направление исследований теряет актуальность, то его сворачивают вместе с соответствующим ПО, а связанное с ним сообщество исчезает. Бизнесу, который к этому моменту может уже существенно зависеть от данного ПО, остается лишь надеяться на то, что сообщество не исчезнет полностью.

Взаимодействие университетских лабораторий строилось на принципах свободы, равенство и братства, показавших свою эффективность в небольших сообществах, однако по мере развития общества применимость этих принципов существенно снизилась. Люди — тоже люди (см. Таблицу).

Скромное обаяние Open Source

Таким образом, принципы открытого ПО эффективны для создания экспериментальных систем силами небольшого сообщества. Для разработки больших и зрелых систем необходимо крупное сообщество, но при этом результат будет уязвим со стороны далеких от технологий факторов, влияющих на сообщество. Кроме того, нельзя забывать, что никто из членов сообщества (включая лидеров) не связан какими-либо обязательствами и в случае возникновения серьезных проблем виновных не найти. Насколько нормально такое положение вещей с точки зрения бизнеса и обеспечения информационной безопасности?

Коммерциализация

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

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

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

Критическая инфраструктура

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

Системы критической инфраструктуры проходят тщательную проверку и сертификацию. Здесь проприетарное и открытое ПО равнозначны — они обязаны пройти одинаковые процедуры. Авторы закрытого ПО должны предоставить полный исходный код своих продуктов, и наличие открытого сообщества не дает какой-либо дополнительной уверенности в качестве и надежности. Кто даст более высокие гарантии: большое и открытое независимое сообщество или компактное закрытое подразделение, изначально специализирующееся на поиске проблем и уязвимостей? Вопрос риторический.

Наличие открытого исходного кода в АС может, скорее, оказаться недостатком, чем достоинством: открытый код дает для злоумышленников больше возможностей при поиске потенциальных уязвимостей; все обнаруженные проблемы в открытом исходном коде будут автоматически «проверяться» злоумышленниками и на ПО для критической инфраструктуры. С этой точки зрения вопрос может быть поставлен радикально: сложное системное ПО должно быть либо открытым и использоваться для экспериментов, исследований и некритичного бизнеса, либо закрытым — и тогда оно может использоваться для критической инфраструктуры. Идея использования открытого ПО, в котором нет уязвимостей благодаря работе сообщества, звучит красиво, но сомнительна с точки зрения безопасности.

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

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

***

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

Открытое ПО создают романтики, развивают фанатики, а далее все зависит от конкретных поставщиков, что вряд ли устроит бизнес.

СУБД ЛИНТЕР БАСТИОН и ЛИНТЕР СОКОЛ

СУБД ЛИНТЕР БАСТИОН (сертификат МО и ФСТЭК) и ЛИНТЕР СОКОЛ — системы с закрытым по следующим причинам кодом:

  • привлечение инвестиций: закрытая модель кода позволяет изначально реализовать уникальные алгоритмы, архитектурные решения, ноу-хау и получить конкурентные преимущества;
  • единая архитектурная концепция [3]: закрытая разработка позволяет команде строго следовать единой архитектурной концепции без риска ее «размывания» из-за разнонаправленных комитов, как это принято в сообществе Open Source. Кроме того, при внесении архитектурных изменений команда может не отвлекаться на синхронизацию с сообществом;
  • безопасность: разработчики точно знают, кто имеет доступ к коду, что снижает риск внедрения на этапе разработки закладок для реализации целенаправленных атак;
  • минимизация попутных затрат: открытый код не имеет смысла без сообщества, но для создания сообщества необходимо и время, и ресурсы. Открытое сообщество — это далеко не единственный способ популяризации продукта.

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

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

Механизмы защиты данных ЛИНТЕР БАСТИОН исключают бесконтрольную власть администратора, что дает этой СУБД преимущество перед традиционными методами на основе периметра и ролевых моделей доступа.

Литература

1. Дмитрий Волков. Сила в сообществе // Открытые системы.СУБД. — 2016. — № 2. — С. 38–41. URL: https://www.osp.ru/os/2016/02/13049332 (дата обращения: 31.12.2025).

2. Константин Селезнев, Виталий Максимов. Импортозамещение: цель или средство // Открытые системы.СУБД. — 2015. — № 1. — С. 30–33. URL: https://www.osp.ru/os/2015/01/13045325 (дата обращения: 31.12.2025).

3. Константин Селезнев. Реляционная СУБД для современного оборудования // Открытые системы.СУБД. — 2023. — № 2. — С. 24–27. URL: https://www.osp.ru/os/2023/02/13057249 (дата обращения: 31.12.2025).

Константин Селезнев (konstantin.seleznyov@gmail.com) — главный специалист, НПП «РЕЛЭКС» (Воронеж).