Как перейти к доверенным ПАК?

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

Как согласовать требования к доверенности

Первая проблема — согласование требований к доверенным ПАК. Действующее регулирование определяет доверенность через подтверждение российского происхождения: аппаратного обеспечения — через реестр Минпрома в соответствии с требованиями к уровню локализации 719 ПП; программного обеспечения — через реестр Минцифры. Все участники рынка — разработчики, заказчики, регуляторы — признают, что принятая норма не отвечает задачам технологического суверенитета, так как реестры наполнены продукцией, которая базируется на аппаратных и программных платформах зарубежной разработки. Эту норму можно принимать как временную, но не для долгосрочного планирования и технической политики. Критерии доверенных ПАК в форме технических стандартов готовит ТК 167 на базе НПО КИС «Росатома». Если кратко, то доверенный ПАК должен соответствовать трем группам требований — функциональной безопасности, информационной безопасности и требованиям по управлению жизненным циклом, начиная с разработки.

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

Чтобы снять это противоречие, нужно отказаться от описания требований функциональной и информационной безопасности в нормативной базе доверенных ПАК. Оставить управление этими требованиями отраслевым регуляторам или даже заказчикам: например, естественные монополии сами определяют функциональные требования в своей инфраструктуре, не нужно их дублировать. Требования информационной безопасности определяют ФСТЭК и ФСБ, это их поляна, она хорошо прорабатывается.

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

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

Требования технологической независимости не имеют специфики областей применения, они едины и должны быть общими для всех отраслей и групп заказчиков. Это снижает сложность и трудоемкость решения задачи, поставленной президентом: определить порядок перехода критической инфраструктуры на доверенные ПАК. Не нужна дополнительная сертификация доверенных ПАК, не нужны новые испытательные центры, все это уже есть в рамках существующих требований к функциональной и информационной безопасности, достаточно ссылаться на них и использовать соответствующие отраслевые сертификаты для подтверждения. Дополнительно нужно ввести только одно — подтверждение доверенного процесса разработки и наличия инженерных ресурсов для технической поддержки и развития внедряемых решений.

Бинарные требования — опасное упрощение

Вторая большая проблема — бинарные требования к доверенным ПАК. По-человечески понятно стремление к упрощению: доверенный или недоверенный, третьего не дано. Но с точки зрения практического управления любыми ресурсами, не только техническими средствами, упрощенный бинарный подход не работает. В реальном мире ни одно решение не может полностью покрывать все риски. Абсолютное доверие в бинарном подходе игнорирует риски, которые не могут быть покрыты конкретной разработкой. Абсолютное недоверие также игнорирует риски, так как на практике полный запрет всегда ведет к неуправляемому перечню исключений, которые выдают под обоснование невозможности обойтись без них. Исключения становятся нормой, а запрет — фикцией. Это можно видеть на примере запрета зарубежной электроники в продукции военного назначения, где исключения встали на поток. Порой уже российским производителям выгоднее отказаться от статуса отечественных, чтобы избавиться от дорогостоящих процедур контроля и подтверждения и проходить через заднюю дверь «при отсутствии аналогов».

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

Первый уровень технологической независимости задан непосредственно в указе № 166 — переход на программное обеспечение российской разработки. Мы уже отмечали, что не все российское ПО из реестра Минцифры является доверенным. Действительно, важно подтвердить, что российские разработчики в достаточной мере владеют своим продуктом, чтобы полноценно поддерживать его жизненный цикл. Лучшее подтверждение — совместимость ПО с российскими микропроцессорами. Перелицованный зарубежный софт не пройдет эту проверку. Возникают издержки на обеспечение совместимости, но они адекватны решаемым задачам: вендор ПО развивает необходимую в текущей реальности компетенцию использования разных микропроцессорных платформ, делает первый шаг к преодолению зависимости от глобальных монополистов рынка микропроцессоров, подготавливает условия для дальнейшего перехода на использование российских аппаратных микропроцессорных платформ.

Второй уровень технологической независимости — российская разработка аппаратных модулей, определяющих основной функционал ПАК. Эти модули включают в себя микропроцессоры, на которых работает системное и прикладное ПО. Например, системная (материнская) плата является платформенным модулем вычислительной техники. Разработка системных плат дает возможность управлять номенклатурой используемых электронных компонентов, в том числе выбором микропроцессоров. Нет разработки электронных модулей — нет спроса на российские электронные компоненты, нет также возможностей перепроектирования, замен компонентов, которые становятся недоступными, нет поддержки для разработчиков ПО, а значит, нет полноценной поддержки и для заказчиков. Локализация производства зарубежных разработок таких возможностей не дает. К сожалению, значительная часть реестра российской электроники — это локализация зарубежных разработок, никак не повышающая уровень технологической независимости.

Третий уровень — аппаратные платформы на основе микропроцессоров российской разработки.

Четвертый — микропроцессоры на основе доверенных библиотек микропроцессорных ядер и СФ-блоков российской разработки. Этот уровень создает предпосылки для развития российских полупроводниковых фабрик. Собственная полупроводниковая фабрика повышает суверенитет только при наличии собственной библиотеки IP-блоков, портированных на технологический процесс российской разработки.

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

Можно поставить вопрос так: как локализация производства должна учитываться в оценке уровня технологической независимости? Для этого нужно разобраться, на какие вызовы отвечает российская разработка, а на какие — производство. За поддержку оборудования в эксплуатации отвечает разработка. Риски информационной и функциональной безопасности парируют разработчики. Производство обеспечивает доступность продукции для закупок, не безопасность решения, а возможность покрытия рынка этими решениями. Если производство тиражирует зарубежные разработки и обеспечивает ими рынок инфраструктуры, такое производство закрепляет технологическую зависимость от зарубежных аппаратных платформ, а если тиражирует российские доверенные разработки — ускоряет продвижение к технологическому суверенитету. Таким образом, требования технологического суверенитета к разработке первичны, а производство хоть и очень важно, но вторично по отношению к разработке.

Без собственной разработки возникают риски потерять управление инфраструктурой, включая катастрофические сценарии, без производства — риски не выполнить планы расширения и модернизации, но это не несет рисков катастрофического характера. Правильно было бы разделить эти группы рисков и индексировать уровень технологической независимости дополнительными признаком. Например, если используется оборудование на основе российского микропроцессора, который изготовлен на зарубежной полупроводниковой фабрике, обозначать этот уровень 3.0, а если микропроцессор изготовлен на российской фабрике — 3.1. Такой подход позволяет расширять критерий индексами третьего уровня. Например, для микросхем, которые разработаны в России, кристаллы чипов изготовлены за рубежом, а корпусирование, тестирование и маркировка производится в России — 3.0.1. Корпусирование микросхем — важный процесс с точки зрения технологической независимости, так как по его итогам микросхема не только получает конечный конструктив, но и маркируется своим наименованием.

Нужно ли корректировать сроки перехода?

Третья большая проблема — срок перехода на доверенные ПАК. Сейчас это 2030 год. Заказчики — владельцы инфраструктуры добиваются переноса на более поздние сроки.

Почему не удается выполнить задачу до 2030 года? Как правило, отвечают так: промышленность не готова. Но никто не ответит, к чему именно не готова промышленность. К тому, чтобы обеспечить рынок КИИ «реестровой» продукцией? Выше было показано, что требования к «реестровой» продукции не соответствуют задачам технологической независимости и безопасности. К реализации задач технологической независимости промышленность готова и очень рассчитывает на этот спрос. Не к декларативному выполнению поручений на100%, а к реальному поэтапному повышению уровня технологической независимости инфраструктуры.

Эти реальные задачи составляют поэтапный план повышения технологической независимости КИИ. Реально до 2030 года перейти не только на использование доверенного ПО, но и на использование электронных модулей российской разработки и производства, как минимум во всех новых проектах по модернизации и расширению инфраструктуры. В проектировании и производстве электронного оборудования нет технологического отставания. По предложенной выше системе оценки это уровень 2.1. Для наиболее критичных с точки зрения рисков систем, должна быть произведена замена зарубежных разработок, несмотря на незавершенный срок амортизации. Это решать регуляторам в области безопасности. Российская промышленность в состоянии решить эту задачу и удовлетворить спрос владельцев критической инфраструктуры до 2030 года. И здесь не идет речи об увеличении бюджета, речь лишь о том, что весь имеющийся и, к сожалению, сокращающийся бюджет на закупки ПО и электронного оборудования владельцы КИИ направят российским разработчикам. С учетом расходов на жизненный цикл им это тоже будет экономически выгоднее, чем покупать импорт без полноценной поддержки. Могут пострадать некоторые планы цифровизации, которые сейчас предполагают использование зарубежных разработок, возможно, придется скорректировать планы внедрения искусственного интеллекта. Если цифровизация повышает уровень технологической зависимости от зарубежных разработчиков, не нужно с этим спешить.

Особая задача — переход на микропроцессоры российской разработки. Они не покрывают сейчас всех функциональных задач, технологическое отставание можно оценить примерно в 10‒15 лет в зависимости от типа процессора. Есть ограничения и по объемам, доступным для производства электронного оборудования. Поэтому здесь общий подход, когда регуляторы определяют состав требований, сроки исполнения и ответственность участников рынка, не подойдет. Чтобы сформировать рынок для российских микропроцессоров, на первом этапе необходимо попроектное планирование. Оно должно учитывать доступное количество микропроцессоров и их функциональные возможности. Сейчас доля американских микропроцессоров в инфраструктуре ЦОД, а также в сетевой телекоммуникационном инфраструктуре составляет более 99%. Уровень технологической зависимости таков, что для российских микропроцессоров не остается опорного рынка для развития. У компаний-разработчиков нет возможности реинвестировать в развитие, у них нет для этого рынка. Поэтому на первом этапе проекты внедрения российских микропроцессоров должны быть обеспечены субсидированием, как со стороны разработки, так и со стороны заказчиков. Если оценить объем субсидий по фонду оплаты труда всех специалистов, занятых в разработке и внедрении российских микропроцессоров, то годовой бюджет государственных расходов на такие сквозные проекты составит примерно 25 млрд рублей. Сейчас бюджет не может быть больше — не хватит разработчиков. И это цена выхода на третий уровень технологической независимости — уровень разработки микропроцессоров.