Технологический суверенитет против «оберточного софта»: почему ИБ-продукты нужно писать с нуля

После 2022 года на российском рынке ИБ появилось много продуктов, которые отечественные по документам, но не по коду: внутри работает зарубежный open source с новым интерфейсом и логотипом. Где проходит граница между нормальной работой с открытым кодом и «оберточным софтом», какие инциденты последних лет показали слабость такой модели и почему систему хранения секретов нельзя построить на чужом ядре.

Когда заказчик выбирает ИБ-продукт, он обычно проверяет две вещи: есть ли решение в реестре и есть ли сертификат. Главный вопрос при этом задают редко: от кого я на самом деле буду зависеть, если что-то пойдёт не так?

После 2022 года ответ на него часто неочевиден. Рынку срочно понадобилась замена ушедшим вендорам, и многие «отечественные» продукты появились по одному рецепту. Берётся зрелый открытый проект, интерфейс перекрашивается, ставится логотип, всё собирается под российскую ОС, и оформляются документы для реестра и сертификации. Заказчик платит за российский продукт, а ядро, ради которого он его покупает, по-прежнему развивают другие люди по своей дорожной карте. Часто вендор и сам мало знает о коде, который продаёт.

Открытый код тут ни при чём, на нём стоит вся мировая индустрия. Вопрос в том, чьё ядро.

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

Обёртка или нормальная работа с open source

Обёрткой я называю продукт, ядро которого, то есть то, за что заказчик платит, написал не вендор.

Доля чужого кода сама по себе ничего не решает. Открытые библиотеки использует вся мировая индустрия, это нормальная инженерная практика. Граница проходит по ядру. Мысленный эксперимент простой: убираем заимствованный компонент. Если от продукта что-то осталось, перед нами продукт. Если ничего, это упаковка.

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

Команда может проверить себя двумя вопросами. Сможем ли мы сами найти и закрыть критическую уязвимость в ядре, не дожидаясь авторов оригинального проекта? Понимаем ли мы, почему ядро устроено именно так?

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

Почему обёрток стало так много

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

Сверху наложились дефицит сильных системных разработчиков, ограниченные бюджеты и логика отчётности. Заказчику нужно отчитаться о переходе, и в моменте строчка в реестре для него важнее происхождения кода.

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

Хорошо видно на автопроме. Когда на рынке появляется «новый отечественный» автомобиль, подозрительно похожий на импортную модель и отличающийся от неё шильдиком и решёткой радиатора, технологическим прорывом его никто не называет. Своего двигателя, платформы и инженерной школы за ним нет. Вопрос даже не в том, хорошая ли машина. Вопрос в том, что будет, когда прекратятся поставки ключевых узлов. С софтом ровно то же самое.

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

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

«Дататека»: СХД судного дня

Как сохранить критически важные данные при разрушении ИТ-инфраструктуры, потере связи с облаком или атаке шифровальщика? «Умный архив» предлагает сценарий «СХД судного дня» на базе «Дататеки»: автономные копии на HDD, геораспределенное хранение и быстрое восстановление доступа к данным.

Что ломается у продуктов на чужом коде

Ниже случаи с мирового рынка, которые знает вся отрасль. Каждый по-своему бьёт по обёрткам.

Уязвимость в зависимости. Log4Shell, декабрь 2021 года. Одна ошибка в библиотеке журналирования Log4j затронула тысячи продуктов. Многие вендоры потом неделями выясняли, используют ли они эту библиотеку вообще.

Закладка. Бэкдор в xz Utils, 2024 год. Злоумышленник несколько лет зарабатывал доверие в проекте, стал мейнтейнером и встроил закладку. Обнаружили её почти случайно: разработчик обратил внимание, что вход по SSH стал занимать заметно больше времени.

Protestware. 2022 год, библиотека node-ipc. Автор популярного открытого пакета добавил код, который по геолокации повреждал файлы на компьютерах с российскими и белорусскими IP-адресами. Для нас это особенно наглядный пример: open source не всегда нейтрален.

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

Брошенный проект. Авторы теряют интерес, обновления прекращаются, и вендор обёртки остаётся единственным, кто сопровождает код. Только нужной экспертизы у него нет. Отдельно посмотрите, сколько времени проходит, пока исправление доберётся до заказчика. У обёртки цепочка выглядит так:

1. уязвимость находят в оригинальном проекте;
2. его авторы выпускают исправление;
3. вендор обёртки узнаёт об этом, если вообще следит за оригиналом;
4. переносит исправление в свою версию;
5. тестирует;
6. если продукт сертифицирован, согласует изменения;
7. выпускает обновление;
8. заказчик его устанавливает.

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

Что на самом деле подтверждает проверка на НДВ

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

На слово приходится верить во всём, что вендор сам до конца не понимает. Если в продукте сотни тысяч строк чужого кода, по-честному вендор может сказать только одно: «Мы прогнали анализатор и ничего не нашли». Тот же бэкдор в xz был спрятан в тестовых файлах и сборочных скриптах. Стандартная проверка исходного кода его бы не увидела.

Доверие к ИБ-продукту строится на уверенности, что вендор понимает каждую строку и готов за неё отвечать. Если значительная часть кода чужая, взять на себя такую ответственность невозможно. Сертификат подтверждает, что проверили предъявленное. Понимает ли вендор то, что предъявил, сертификат не подтверждает.

Почему хранение секретов нельзя «прикрутить» потом

Модель угроз закладывается в первый день разработки. Где хранятся секреты, у кого к ним есть доступ, что произойдёт при компрометации администратора, сервера или базы данных: из ответов на эти вопросы вырастает вся архитектура.

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

Решения, которые после запуска практически не переделываются:

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

Юридические риски применения ИИ

Кто должен отвечать за ошибки искусственного интеллекта и может ли человек их оспорить? Юристы считают необходимым уточнить правила применения алгоритмов, влияющих на права и интересы граждан.

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

Криптографию и безопасное хранение нельзя вынести в отдельный модуль, это свойство всей системы. Алгоритм шифрования поменять можно. Но если секрет на каком-то этапе оказывается в открытом виде в памяти, в журнале или во временном файле, заменой библиотеки это не исправить. В ИБ-продукте безопасность нельзя дописать в следующем релизе, на ней стоит всё остальное.

Когда своё писать не нужно

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

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

Что оказалось самым дорогим на нашем опыте

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

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

Возражения. Чаще всего мы слышим: «Нам проще взять перекрашенный продукт, он привычнее, пусть и не по-настоящему отечественный». Возражение честное, и отвечать на него надо так же. Привычность даёт удобство сегодня, зависимость несёт риск на годы вперёд. Переход на продукт с собственным ядром страхует заказчика от того, чтобы завтра снова оказаться в ситуации 2022 года.

Командам, которые сейчас стоят перед выбором, я советую сначала ответить себе на вопрос, за что вам платит заказчик. Эту часть пишите сами. Остальное можно брать, но с полным пониманием того, что вы берёте, и с готовностью сопровождать это своими силами.

Что спросить у вендора до покупки

Три вопроса, которые быстро показывают, с чем вы имеете дело.

1. «Если завтра в ядре вашего продукта найдут критическую уязвимость, кто её исправит и в какой срок?» Ответ «дождёмся исправления от авторов оригинального проекта» многое говорит о продукте.

2. «Какие ключевые компоненты вы заимствовали и почему?» Зрелый вендор ответит спокойно и конкретно, стыдного в заимствованиях ничего нет. Настораживать должно уклонение от ответа.

3. «Что умеет ваш продукт, чего нет в аналогичных открытых проектах?» Здесь сразу видно, где реальная разработка.

И ещё четыре места, куда стоит посмотреть самостоятельно:

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

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

Ловушка «зеленых метрик», или Работоспособность не равна эффекту

Как выстроить непрерывный контроль качества ИИ-систем и почему автоматических проверок здесь недостаточно.

Строчка в реестре не делает продукт суверенным

Реестр подтверждает, кому принадлежат права на продукт. От кого продукт зависит, он не показывает. Открытый проект с логотипом российской компании автоматически независимым не становится.

Open source может решать задачу суверенитета, но при одном условии: технологии ядра должны быть нашими, и мы должны знать, что внутри. Суверенитет на уровне инженерии я понимаю как способность самостоятельно развивать продукт, закрывать любую ошибку и уязвимость и принимать архитектурные решения без оглядки на чужую дорожную карту.

Поэтому я категорически не согласен с подходом «галочки в реестре», когда появление отечественной обёртки над открытым проектом считают решённой задачей импортозамещения. Задачу при этом только отложили. Не согласен и с логикой «сначала быстро заменим, потом разберёмся». Качество продукта со временем подтянуть можно. Разорвать внешнюю зависимость, когда на ней уже построен продукт и обучены заказчики, несравнимо сложнее. И наконец, такой подход расходует целевые деньги. Средства, выделенные на развитие отрасли, уходят на перекраску чужих решений, а действительно инновационные продукты, которые строятся годами, проигрывают тем, кто просто раньше вышел на рынок.

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

Мой совет заказчикам: выбирая продукт, спрашивайте не только, есть ли он в реестре, но и от кого вы будете зависеть, когда что-то пойдёт не так. Ответ на этот вопрос и есть реальная мера суверенитета.