КИИ и дедлайн 2025: составляем дорожную карту перехода на отечественное ПО

ФСТЭК в очередной раз напомнила о существовании Указа Президента № 166 и сроке 1 января 2025 года для объектов КИИ. До дедлайна - полтора года. Звучит как много, но когда начинаешь раскладывать конкретный стек на конкретном объекте, полтора года превращаются в «надо было начинать год назад».

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

Почему инвентаризация - это первый шаг, а не формальность

Большинство организаций, которые приходят на аудит с задачей «оцените переход на отечественный стек», не имеют полного реестра ПО, которое нужно заменить. Есть представление об основных системах - АСУ ТП, СУБД, серверные ОС. Но когда начинаешь копать, выясняется, что:

• инженерные рабочие станции живут на Windows с десятком специализированных утилит от зарубежных вендоров, про которые никто не думал в контексте КИИ;
• сетевое оборудование - Cisco или HPE - формально под действие указа о ПО попадает частично, но там есть встроенный софт и лицензии, которые тоже нужно анализировать;
• средства резервного копирования и мониторинга - Veeam, Zabbix, что-то самописное - каждое со своим статусом в реестре отечественного ПО Минцифры;
• библиотеки и компоненты в составе самописных систем - открытые, зарубежные, никем не учитываемые.

Без полного реестра любой план перехода - это фикция. Вы не знаете, что менять, в каком порядке и сколько это займёт.

Как мы структурируем инвентаризацию

На объектах КИИ мы раскладываем ПО по слоям стека. Это не академическая классификация - это рабочий инструмент, который позволяет сразу видеть приоритеты и зависимости.

Первый слой - операционные системы серверов и рабочих станций. Здесь картина обычно самая понятная: Windows Server, RHEL или CentOS, иногда Debian. Отечественные замены существуют - Astra Linux, РЕД ОС, ALT Linux. Проблема не в выборе замены, а в том, что за каждой ОС тянется хвост зависимостей: драйверы оборудования, специализированный софт, который работает только под Windows, доменная инфраструктура на Active Directory.

Второй слой - СУБД. Это часто самая болезненная точка, потому что миграция данных и совместимость SQL-диалектов - не тривиальная история. Oracle, MS SQL, PostgreSQL (зарубежная редакция) - по каждому свой путь. Postgres Pro закрывает часть вопросов по PostgreSQL-совместимым системам, но Oracle - отдельный разговор.

Третий слой - прикладное ПО и промежуточные системы. Тут всё самое интересное: АСУ ТП, historian-базы, MES, ERP-фрагменты, HMI-терминалы. Это зона, где отечественных замен меньше всего, а вендорская зависимость максимальная. Здесь же - средства резервного копирования, мониторинга, управления конфигурациями.

Четвёртый слой - средства виртуализации и оркестрации. VMware, Hyper-V, и всё что на них крутится. VMware особенно интересен: в связи с ожидаемым поглощением Broadcom лицензионная история становится непредсказуемой, так что импортозамещение здесь пересекается с чисто коммерческими рисками. Отечественные варианты - zVirt, Basis Dynamix, и вот Deckhouse для контейнерных нагрузок.

Расстановка приоритетов: не всё одинаково горит

Когда реестр собран, нужно понять, что меняем в первую очередь. У нас есть три критерия, по которым мы оцениваем каждый компонент:

• Критичность для функционирования объекта. Если это SCADA-система, которая управляет технологическим процессом, - это первый приоритет по значимости, но, возможно, последний по порядку замены, потому что замена требует максимального тестирования.
• Наличие готовой отечественной замены. По серверным ОС замены есть и зрелые. По некоторым SCADA-системам - нет. По операционным СУБД - ситуация средняя. По специализированному промышленному ПО - часто никак.
• Зависимости. Некоторые компоненты нельзя заменить, не заменив сначала то, на что они опираются. Типичный пример: прикладная система, жёстко привязанная к MS SQL через хранимые процедуры - без предварительной работы по СУБД заменить её невозможно.

На практике это означает, что план перехода выглядит не как «заменяем по порядку критичности», а как «строим граф зависимостей и ищем правильную последовательность».

Реалистичная оценка сроков

Здесь самая неудобная часть разговора с клиентами. Когда видишь, что на объекте стоит Oracle с несколькими терабайтами данных и десятком приложений, которые работают через нативный OCI-клиент, - ты понимаешь, что эта замена займёт год только на подготовку. И это при наличии выделенных ресурсов и финансирования.

Типовые сроки, которые мы наблюдаем в реальных проектах:

• Замена серверной ОС на типовом сервере с типовой нагрузкой - 1-3 месяца с учётом тестирования и согласований. Если нагрузка нестандартная - больше.
• Миграция СУБД с PostgreSQL на Postgres Pro или с MS SQL на PostgreSQL-совместимую систему - от трёх месяцев до года, зависит от объёма данных и специфики SQL.
• Замена SCADA или MES - это история на год-полтора минимум, с пилотом, тестированием на стенде, параллельной работой и постепенным переключением.
• Замена VMware-инфраструктуры - зависит от масштаба, но меньше полугода редко получается.

До 1 января 2025 года - восемнадцать месяцев. Если начать инвентаризацию сейчас и расставить приоритеты к сентябрю, у части объектов есть шанс закрыть хотя бы первый и второй слои стека в срок. Третий и четвёртый - вопрос.

Где мы сейчас

На нескольких объектах мы уже ведём инвентаризацию. Картина предсказуемо неравномерная: кто-то успел заменить ОС на серверах год назад, у кого-то в реестре пусто и непонятно с чего начинать. Единого рецепта нет - есть методичная работа слой за слоем.

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