14 апреля 2022 г.
Вариантов действий, способных повлиять на санкционную устойчивость СПО для российских компаний, довольно много: изменение лицензионной политики, искусственное ограничение применимости СПО для российских заказчиков и ограничение техподдержки.
Стоит отметить, что принципиально ничего нового не появилось. «Подобные риски существовали всегда, — говорит Михаил Кузнецов, коммерческий директор iFellow. — Из-за текущей ситуации они стали просто более вероятными». С ним солидарен Александр Казеннов, руководитель корпоративной практики ДКИС ALP Group: «В условиях санкционного давления данные риски лишь возросли».
Три потенциальных варианта ограничений СПО
Распространение СПО идет под лицензиями, о чем мало кто задумывается. Лицензии создают упомянутые в предыдущем материале некоммерческие фонды и другие компании, которые могут корректировать лицензионные правила в зависимости от обстоятельств. Обратной силы новые версии лицензий, скорее всего, иметь не будут, но их действие вполне могут распространить на новые релизы. Однако к лицензиям на территории РФ отношение достаточно мягкое, поэтому данным видом санкционного давления можно пренебречь.
Техподдержка СПО обычна доступна по двум каналам: со стороны комьюнити и со стороны коммерческих компаний, внешних организаций, которые таким способом монетизируют свою экспертизу в тех или иных свободно-распространяемых приложениях. С точки зрения лицензий все корректно — компании берут деньги не за сами программы, а за сервис для них. Но компании, предоставляющие техподдержку, могут ввести ограничения для работы с заказчиками из РФ! Хотя в данном случае ситуация будет даже лучше, чем с традиционным коммерческим ПО — ведь остается доступной поддержка комьюнити! Конечно, уровень обслуживания будет совсем «не бизнесовый», но это все же лучше, чем ничего.
Поддержку СПО на бизнес-уровне российские заказчики могут обеспечивать самостоятельно, равно как и развитие релизов под задачи, хотя это сложно и затратно. «Использование СПО подразумевает необходимость доработки, поддержки и развития решения для своих задач, — говорит Александр Виноградов, руководитель платформы Tarantool. — На отечественном рынке не так много разработчиков, умеющих создавать ПО на основе Open Source для решения специфичных для конкретной отрасли задач, это редкие и дорогие специалисты, компании всегда конкурируют за них».
Наиболее опасно «отлучение» российских компаний от новых версий, которое может быть реализовано в достаточно изощренных формах. Любое современное ПО — вне зависимости от формы лицензирования, сказанное справедливо как для коммерческого, так и для СПО — существует благодаря постоянно действующему конвейеру разработки, который актуализирует софт, добавляя новые функции, удаляя уязвимости, оптимизируя код и т. д. В очередном релизе некоторые функции, актуальные для локальных рынков, могут как пропасть, так и не появиться. Например, может пропасть из APU поддержка доступных в стране протоколов кодирования, стандартов электронной подписи и т. д., что серьезно усложнит применение данного программного решения корпоративными заказчиками.
Можно ли обойти ограничения
Теоретически ничто не мешает локальным компаниям добавить недостающее в релиз — тексты СПО обычно открыты — но практически это проблематично: ведь результат придется самостоятельно тестировать «с нуля», при этом не обладая потенциалом тестирования, которым располагают разработчики исходного релиза, а это создает очевидные риски ИБ.
Еще раз подчеркнем, что к соответствию СПО требованиям ИБ нужно относиться очень тщательно. Даже в коммерческих релизах бывают как «закладки», случайно или намеренно оставленные разработчиками, так и эксплойты, которые тем или иным способом внедрили внешние команды хакеров. Подчеркнем, что хакерам существенно проще внедриться в группы разработчиков СПО, чем в коммерческие компании, поэтому риск эксплойтов будет заметно выше. Анализировать миллионы строк кода СПО, конечно, возможно, но это будет не быстро и достаточно затратно.
Вместо заключения
Рассмотренные примеры — напомним, что они наиболее общие! — показывают, что на практике СПО не является универсальной «палочкой-выручалочкой», способной обеспечить внутреннему рынку страны технологическую независимость. СПО несет ряд очевидных рисков, с которыми нужно уметь работать и располагать для этого соответствующей компетенцией. «Риски и проблемы будут требовать оперативной реакции со стороны государства и ИТ-отрасли», — говорит г-н Кузнецов.
Нивелировать риски — как имеющиеся, так и будущие — могут локальные компании с нужной экспертизой, но данные услуги будут, разумеется, далеко небесплатны. «Единственный действенный вариант — это квалифицированный отдел разработки, обладающий технической экспертизой во внедрении таких продуктов, или надежный партнер, который сопровождает компанию», — говорит Кирилл Владимиров, генеральный директор компании Only.
Подчеркнем, что существуют и более радикальные взгляды на ситуацию. «Нужно внедрять и использовать только российские разработки, которые развиваются на отечественном технологически независимом репозитории пакетов свободных программ, — уверен Григорий Сизоненко, генеральный директор ИВК. — Технологии и инструменты ведения репозитория и сборки ПО, разработанные российскими программистами, сводят к минимуму риски доступа злоумышленников к цифровым ресурсам организации».
Такой подход в современных условиях вполне рационален, например, для объектов КИИ, а при усилении санкционного давления может стать актуален и для других сегментов экономики страны.
Источник: Александр Маляревский, внештатный обозреватель IT Channel News