Импортозамещение в России началось задолго до 2022 года. Этот процесс тянется с 2014 года: тогда на фоне санкций поставили задачу перейти с иностранного ПО на российское. Сначала правительство РФ запретило госорганам закупать и использовать зарубежные продукты, если на рынке присутствуют их отечественные аналоги. Уже в 2018 году правительство решило полностью перевести государственные компании на российское ПО.
В 2019 году государственные структуры закупали всего 35% ПО, разработанного в других странах. Однако, несмотря на грандиозный план, с импортозамещением есть проблемы. В этой статье на примере компании, в которой я работаю, расскажу, как этот процесс происходил у нас.
Какое ПО мы использовали до ввода санкций
Наша компания специализируется на внедрении решений, которые предназначены для защиты кластеров Kubernetes, контейнеров и микроядерных приложений. В таблице ниже я описал зарубежное программное обеспечение, которое мы использовали раньше, и его отечественную замену. Также в таблице я перечислил ключевые возможности каждого используемого ПО.
Также мы занимаемся внедрением инструментов безопасной разработки, которые тоже нужно было заменить на российский аналог.
Кроме того, некоторые инструменты мы ранее не использовали. Например, готовые продукты для обеспечения процессов DevSecOps начали применять уже после начала импортозамещения. До этого каждая команда сама выстраивала процессы и использовала нужные ей решения.
Со временем стало понятно, что нужен единый инструмент, поэтому внедрили российское ПО AppSec.Hub. В нем есть необходимая функциональность для реализации процессов DevSecOps, интеграция с CI/CD, визуализация и графики процессов сканирования. Решение поддерживает больше 30 различных инструментов: GitHub, GitLab, Jenkins, Nexus, SonarQube, Jira и другие.
Как происходил процесс перехода на отечественное ПО
В середине марта 2022 года мы начали переходить на продукты российских разработчиков. У некоторых зарубежных продуктов всё еще была активная лицензия, но поддержка со стороны вендоров перестала отвечать на наши ранее заведенные тикеты, и эксплуатировать ПО уже стало достаточно трудно.
Импортозамещение для каждого из заказчиков (банков, страховых и торговых компаний) проходило в несколько этапов:
1. От представителя заказчика мы получали список необходимых функций решения. Например, кому-то было важно наличие интеграции с CI/CD, другим необходима встроенная функциональность по генерации отчетов, а третьим — наличие интеграции с Jira.
2. Затем мы с командой приступали к поиску и выбору подходящего ПО. Мы детально обсуждали на созвонах, какой продукт будем использовать, какие у него есть возможности и недостатки. Здесь стоит выделить следующий момент: на самых первых этапах импортозамещения не все отечественные программы обладали нужной функциональностью. В таком случае мы временно использовали open source, чтобы закрыть бреши.
Например, в ПО Luntry не было сканера для поиска уязвимостей в Docker-образах, поэтому мы использовали утилиту trivy. Также в ней присутствовала интеграция с CI/CD (в нашем случае это был GitLab). По мере развития отечественного ПО надобность в open source отпала.
3. Команда готовила файл с небольшим описанием продукта и его возможностей, а затем отправляла его заказчику.
4. Если заказчик выражал интерес к продукту, то мы готовились к демонстрации, или, как у нас принято называть, «демо». Для этого мы заполняли необходимые документы, техническое задание, сетевые и архитектурные схемы, устанавливали и настраивали продукт, проверяли его работу. Далее демонстрировали решение заказчику. Если заказчик одобрял продукт, то мы начинали внедрять решение в инфраструктуру.
На первых порах при установке мы сталкивались с разными ошибками. Например, часть компонентов системы не поднималась, часть падала и уходила в ошибки. Даже если все компоненты успешно запустились, иногда мы не могли войти в веб-интерфейс или внутри программы отображались не все данные. Поэтому после внедрения начинался этап поддержки, включающий в себя установку новых версий, решение проблем.
Как правило, при возникновении каких-либо багов мы сразу обращались к вендорам. Критические проблемы, например с запуском, вылетами и неправильной работой программы, вендор исправлял в день обращения. То есть нам не приходилось ждать новую версию по несколько дней или недель. Однако были еще доработки, которые вендор выполнял строго по графику, например добавление новой функциональности. На текущий момент ситуация с внедрением нового ПО заметно улучшилась — ошибок стало намного меньше.
С какими проблемами мы столкнулись во время процесса импортозамещения
В начале импортозамещения процесс нельзя было назвать идеальным, поэтому при переходе на новое ПО мы сталкивались с различными сложностями.
Отсутствие нужной функциональности
В первые месяцы импортозамещения главной проблемой было то, что отечественные программы для ИБ не обладали такими обширными возможностями, как зарубежные. До событий 2022 года российское ПО широко не применялось, на рынке было не так много аналогов.
Чаще всего не хватало интеграции со сторонними сервисами, такими как Jenkins, GitLab, Active Directory, а также графиков, метрик и прочих вспомогательных функций. Эту проблему решали двумя способами:
- Отсутствующую функциональность заменяли сторонним продуктом, как правило, решениями open source.
- Если найти замену было невозможно, то приходилось дожидаться выхода нового релиза. Например, интеграция с Active Directory появилась в Luntry далеко не сразу.
Отсутствие клиентского портала для получения поддержки и заведения тикетов
При использовании сложных коммерческих продуктов вендор обычно предоставляет доступ к своему порталу. Там можно получить техническую поддержку, найти необходимую документацию и при необходимости завести тикет с возникшей проблемой. На ранних этапах внедрения отечественного ПО у некоторых продуктов такие порталы отсутствовали вовсе, поэтому с вендорами приходилось общаться в телеграм-чатах.
Отсутствие русского языка в интерфейсе
На фоне всех остальных этот недостаток выглядит довольно нелепо: продукт отечественной разработки без русского языка! Однако такая проблема существовала, и заказчиков это удивляло. Сюда же можно отнести неполный перевод, когда часть текста в программе локализована, а часть так и осталась на английском.
Сейчас русскоязычный интерфейс обязателен для всех отечественных продуктов.
Недоработанная функциональность
По сравнению с зарубежными продуктами, у отечественных решений были существенно урезанные возможности, и эта проблема актуальна до сих пор.
Стоит отличать недоработки от багов. Например, к недоработкам можно отнести невозможность подключить два и более одинаковых типа инструмента. Допустим, заказчик использует три репозитория GitHub, причем один из них находится во внешней сети, а другие во внутренней. Многие решения не позволяли интегрировать их все.
Также сюда можно отнести невозможность генерации и скачивания отчетов. Единственное решение данной проблемы — это выпуск новой версии, в которой все ошибки учтены и функциональность доработана.
Баги
Ну и куда же без багов и всевозможных ошибок. Сбои при входе в веб-интерфейс программы, неработающие кнопки, неожиданные вылеты — всё это периодически возникает при выпуске нового релиза и при эксплуатации ПО.
Еще раньше было много ошибок, когда программа не справлялась с нагрузкой. Например, если задать в веб-интерфейсе программы слишком объемную фильтрацию, то она намертво зависала, и для дальнейшего использования приходилось перезаходить в личный кабинет. Допустим, такое происходило при запросе на вывод всех ролей и их прав в кластере Kubernetes.
Итоги
За год с начала импортозамещения мы прошли достаточно тернистый путь. Переходить на отечественное ПО было трудно: мы и наши заказчики уже привыкли к тому ПО, которое до этого использовали годами, если не десятилетиями. Поэтому, увидев новый интерфейс или функциональность, мы испытывали что-то вроде неприятия или непонимания: как всё это использовать и как с этим жить дальше?
Но со временем начинаешь привыкать к новому. Часть проблем удалось решить, однако работы предстоит еще много. В частности, нужно больше интеграций со смежными системами, такими как HashiCorp Vault, GitLab, Grafana/Prometheus, SIEM-системы. Также необходимо наличие клиентских порталов с полноценной поддержкой от вендора и заведением тикетов. Ну и, конечно же, наличие полной и, самое главное, актуальной документации по продукту.
