Александр
Львов

аналитик Logictec
20.06.2022
© ComNews

С 2016 года в России начал формироваться Единый реестр российских программ, но активное обсуждение необходимости импортозамещения в IT-сфере началось фактически только с марта этого года, когда стало понятно, что нам с западным миром еще долгое время будет "не по пути". И вроде бы для многих зарубежных решений уже существуют и активно используются российские аналоги, однако вопрос безопасности использования отдельных продуктов из списка Минкомсвязи остается отрытым.

Менять нельзя использовать

Собственно, если у кого-то из российских высших чиновников и государственных топ-менеджеров и были сомнения в правильности замены импортного софта на отечественный, то Указ Президента РФ от 30 марта 2022 года № 166 о запрете закупки иностранного софта для критической информационной инфраструктуры (КИИ) в одночасье снял все вопросы. Более того, в ближайшие полгода Правительство РФ должно разработать дополнительную нормативку по импортозамещению на значимых объектах всех субъектов КИИ, а не только структур с государственным участием.

При этом коммерческие компании находятся в серьезных раздумьях – а так ли уж нужно ли делать следующие шаги по переходу на отечественный софт? Ведь, например, те же Atlassian, Zendensk или Notion, конечно, ушли с российского рынка и даже слегка "хлопнули дверью", но ведь пока нет ограничений на оплату соответствующих сервисов через белорусские банковские карты и никто пока не мешает использовать VPN для доступа к заветным "закромам"…

И главные проблемы кроются не только в очевидной сверхзатратности процесса перехода на новый софт, но и в вопросе безопасности использования незнакомого программного обеспечения. А пренебрежение "правилами техники безопасности" может бизнесу обойтись ох как дорого. Яркий пример – недавний трехдневный сбой в работе Rutube, который вызвал небывалое оживление в публичном пространстве и споры о том, что же на самом деле произошло – внутренняя диверсия или действия внешних "экспертов", нашедших таки недостатки в IT-структуре.

Насколько российский софт по-настоящему российский?

В реестр отечественного ПО сегодня включены более 13 тысяч программных продуктов, которые "официально признаны происходящими из Российской Федерации". Периодически список пополняется новыми решениями, но при этом параллельно происходит чистка реестра и исключение программного обеспечения, которое себя по какой-то причине скомпрометировало. Основные причины исключения связаны с постепенным, но планомерным выявлением использования зарубежного Open Source при разработке продуктов. Из последних примеров - продукт LibreOffice, который по сути являлся софтом, написанном на иностранном Open Sourсe, но забрендированном под отечественного производителя – компанию AlterOffice).

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

Таким образом, присутствие в данный конкретный момент программного обеспечения в Реестре вовсе не означает, что при его создании не использовались "запрещенные технологии" и, соответственно, не является гарантией "устойчивости" софта – а именно этот критерий сегодня является главным показателем "благонадежности" продукта в условиях санкционного давления со стороны мирового IT-сообщества.

Плохой хороший Open Source

При других текущих вводных повсеместное использование открытых кодов было бы абсолютно нормальным и правильным подходом – почему не использовать себе во благо имеющийся опыт тысяч разработчиков?

Однако общее настроение сегодня в международной IT-среде однозначно антироссийское. Например, крупнейший и самый популярный мировой репозиторий GitHub уже закрыл доступ десяткам российских разработчиков - включая профили попавших под западные санкции Сбербанка и Альфа-Банка - и продолжает пополнять перечень "неблагонадежных" аккаунтов. Ну и, конечно, "недружественность", в том числе, проявляется в среде разработчиков продуктов на Open Source, которые постепенно прекращают поддержку своих решений на территории нашей страны или даже блокируют возможность их использования российскими. В частности, о прекращении сотрудничества со своими партнерами из России и Белоруссии сообщила Red Hat (разработчик Linux-дистрибутива RHEL). Также в качестве примера можно привести уход Cisco, который владеет Open Source-продуктом Сlamav.

В общем, прекращение поддержки русскоязычного сообщества или запрет использования Open Source продукта на территории России – это достаточный повод, чтобы всерьез задуматься о замене на аналогичный продукт и продолжить работу без оглядки на санкции и возможные "косяки" в открытом коде. Но такая замена, как выясняется, возможна далеко не всегда.

Рассмотрим два примера архитектуры продуктов с использованием Open Source-решений (на примере ECM-систем).

1. Использование Open Source для формирования части "надстройки" над ядром – микросервисов, приложений для работы с внешним контуром и т.п. Пример – на рис. 1 (схема взята с сайта www.tadviser.ru и описывает архитектуру совместного продукта компаний Galantis и "Корпорация Галактика").

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

2. Использование Open Source в качестве основы продукта.

Пример – на рис. 2 (схема взята с сайта компании L2U и описывает архитектуру продукта InKnowledge).

В ядре продукта, используется решение от Liferay (разработка американской компании Liferay LTD). Продукт известный и популярный, и, кстати, включен в Реестр отечественного ПО несмотря на импортную основу.

Liferay Portal CE – Open Source не для всех.

Несмотря на то, что Liferay Portal CE – это Open Source продукт, его правообладатель в праве накладывать ограничения на использование своего продукта. Например, в части экспорта, Liferay LTD. придерживается политики США и вводимых ими санкций. На момент написания данной статьи правительством Соединенных Штатов Америки уже ограничена возможность вести деятельность как на отдельных территориях нашей страны, так и с конкретными организациями, которых в России уже более 14 000. И как быстро к этим компаниям добавятся новые, предсказать невозможно.

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

А вот что произойдет и какие у пользователей возникнут риски, если Liferay вслед за своими западными коллегами отключит Россию от "трубы поддержки" - попробуем разобраться далее.

Можно ли в России использовать продукт в основе которого лежит софт, подобный Liferay?

Формально Нет!

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

Но…

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

Теоретически Да…

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

…Но Небезопасно!

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

Практически Да…

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

Но результат не прогнозируем!

Cовершенно непонятно (и таких примеров нам, во всяком случае, неизвестно), как обновлять ядро Open Source при том, что в этом же ядре уже активно "покопались" собственные специалисты. То бишь компания встанет перед выбором между потенциальным улучшением качества и повышением безопасности продукта и риском появления в продукте внутренних противоречий – возможно, критических и неразрешимых. А также не будем забывать и про толпы хакеров, жаждущих ворваться в "личное" пространство российского бизнеса – причем в сегодняшних условиях порой по идеологическим соображениям, а не корысти ради.

Думайте сами, решайте сами…

Итак, резюмируем. Имеется масса примеров реализации систем на проприетарном коде, который при этом прекрасно поддерживается и вендором, и свободными разработчиками. Казалось бы, все всё предусмотрели, но… Свежий пример с демаршем Atlassian с российского рынка - и в топку летят десятки готовых программных продуктов, а про сотни наработок уже молчим.

При этом, повторимся - нельзя говорить, что Open Source – это плохо! Если на открытом коде написана только часть продукта, поскольку это действительно удобно и позволяет быстро получить нужное решение (или использовать уже готовую технологию). Некогда открытый поисковый движок Elasticsearch поменял свою лицензионную политику и перестал быть открытым. Разработчики, которые использовали этот код, столкнулись с определенной проблемой, но оперативно поменяли его на Opensearch и ему подобные, и все произошло незаметно для пользователей.

А вот если Open Source лежит в основе продукта (как в приведенном примере с Liferay), то "незаметно", быстро и качественно заменить его нельзя.

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

Читайте также

Новости