Выбор проприетарных или opensource-приложений для бизнеса | Блог Касперского

Можно ли переходить на open source и бесплатные приложения в компании.

Приложения с открытым исходным кодом (open source) прочно обосновались в IT-системах крупного и среднего бизнеса. Начав с доминирования в таких сегментах, как веб-серверы, базы данных и аналитика, сегодня opensource-решения также весьма популярны для контейнеризации, машинного обучения, DevOps и, конечно, для разработки софта. Многие организации переходят на open source и для «не айтишных» задач, таких как CRM, производство графического контента и публикация блогов. В целом, по оценке Gartner, боле 95% организаций в сфере IT используют opensource-решения, но и среди не-IT-компаний цифры тоже уже превышают 40%. И это без учета тех многочисленных случаев, когда библиотеки с открытым исходным кодом используются внутри проприетарных приложений.

В России дополнительный толчок движению open source дало импортозамещение, поскольку адаптировать качественные opensource-разработки для отечественных реалий проще, чем вести их с нуля. Поэтому в России ускорились темпы перехода на открытые ОС, офисные инструменты и так далее.

Выбор открытого (open source) или проприетарного (closed source) решения далеко не прост — это не просто выбор «платного» против «бесплатного» или «без техподдержки» против «с техподдержкой». Для каждого IT-решения и для конкретной организации надо учитывать целый ряд важных аспектов.

Стоимость и график внедрения

Хотя стоимость лицензии на решения open source часто равна нулю, внедрение в организации не будет бесплатным. В зависимости от сложности решения потребуется выделить время IT-команды, привлечь специализированных консультантов по внедрению, а то и нанять разработчиков, которые будут все время адаптировать приложение под нужды организации.

Встречается гибридная модель лицензирования, когда community edition (общедоступная версия) приложения может быть использована бесплатно, но расширенная версия с корпоративными функциями все же требует платной лицензии.

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

Преимуществом open source на фазе внедрения, безусловно, является возможность полноценного тестирования. Даже если разворачивать opensource-разработку планируется в виде управляемого хостинга или с помощью специализированного подрядчика, запустить пилот (proof of concept) своими силами значительно эффективней, чем смотреть видеодемонстрации проприетарных решений. Сразу будет понятно, насколько функционально и применимо решение в условиях конкретной организации.

До внедрения, сравнивая решения open source и closed source, довольно важно понять, сколько времени есть на тестирование и допустимо ли сменить продукт на ранних этапах теста. Если запас есть и на второй вопрос ответ положителен, то разумно будет подробно протестировать open source.

Стоимость поддержки

Повседневная поддержка и настройка многих opensource-приложений промышленного масштаба, а также их адаптация к высокой вычислительной нагрузке требуют от IT-команды весьма специфического и глубокого опыта. Если его нет, опыт придется покупать — либо нанимая в штат специалистов, либо привлекая аутсорсинг. Наиболее распространенные виды аутсорсинга — это специалисты по эксплуатации конкретного приложения (формат Red hat) или управляемый хостинг, оптимизированный под конкретное IT-решение (формат Kube Clusters, WP engine и тому подобные).

Разумеется, для проприетарных решений платная поддержка тоже типична; нельзя сказать, что это нужно только для open source. Расходы сопоставимы! Как показывает практика внедрения open source, годовая техподдержка типичного корпоративного приложения в этом случае всего на 10-15% дешевле, чем для проприетарных решений.

Доработки и масштабирование

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

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

Кроссплатформенность и интеграция

Для масштабных многокомпонентных решений, между которыми ведется активный обмен данными, вопросы интеграции и кроссплатформенности могут быть одним из ключевых факторов выбора конкретного программного продукта. Здесь в приоритете соблюдение индустриальных форматов хранения и обмена данными, хорошо документированные прикладные интерфейсы (API). Иногда оказывается, что моновендорное решение с закрытым исходным кодом удовлетворяет этим требованиям лучше, чем зоопарк opensource-решений, даже качественных. Но полезным будет оценить стоимость доработки opensource-решения, если по другим критериям оно выигрывает и при этом успешно прошло пилотную фазу.

Риски, безопасность и лицензионные требования

Достоинством open source часто называют более высокую безопасность. Ведь если все видят исходный код и любой может исправить найденную ошибку, то это безопасней проприетарного «черного ящика»?

В реальности все сложнее. Во-первых, многие opensource-приложения насчитывают миллионы строк кода, который никто не способен проаудировать целиком. Большое количество обновлений этого кода только затрудняет задачу. Впрочем, малый размер тоже не спасает. Например, уязвимость Shellshock прожила незамеченной в коде bash 20 лет!

Во-вторых, существует острая «проблема зависимостей» (dependencies), поскольку в приложениях и коде есть своя «цепочка поставок» (supply chain). Opensource-приложение может использовать стороннюю opensource-библиотеку, которая в свою очередь ссылается на еще одну стороннюю библиотеку, и те, кто проверяют само приложение, вряд ли заодно проверят все библиотеки. Риски этой цепочки уже многократно продемонстрированы: уязвимость в бесплатной библиотеке ведения логов Log4j отразилась на тысячах крупных opensource-решений, затронув продукты таких грандов, как Amazon, Cloudflare, Elastic и им подобных. Атака с заменой npm-библиотек на вредоносных «однофамильцев» успешно сработала с Apple и Microsoft. Ну и наконец, отказ независимого разработчика от поддержки крошечной библиотеки left-pad в репозитории npm, «положил» более тысячи популярных приложений и сайтов (включая Facebook) на несколько часов.

Источник: xkcd.com/2347

Другой аспект зависимостей — проблема лицензирования. Лицензии на open source довольно специфичны, и отсутствие платежей не означает отсутствия правообладателя. Само приложение и его библиотеки могут поставляться с различными лицензиями, и нарушение более строгих из них (copyleft) чревато судебными исками. По аналогии с налаженным процессом ИБ-аудита и устранения уязвимостей, у крупных пользователей и разработчиков open source должен быть подобный процесс регулярной проверки лицензионного соответствия, в идеале полуавтоматизированный.

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

Все вышесказанное вовсе не означает, что open source — худшее с точки зрения ИБ решение. Просто все риски нужно учитывать: команде внедрения надо оценивать культуру разработки и регулярность выхода обновлений безопасности в приложениях-кандидатах, контролировать зависимости и лицензии, например, при помощи software bill of materials. Кроме того, если ваша компания занимается разработкой ПО, разумно внедрить в процесс DevSecOps процедуру сканирования используемых пакетов c открытым исходным кодом на уязвимости и вредоносную функциональность.

07.03.2023