Откройте серверную любой компании, которая работала с иностранными вендорами до 2022 года, и найдете коммутатор Cisco, СХД от Dell или сервер HPE. Все это до сих пор в работе: коммутатор передает трафик, СХД хранит данные, сервер обслуживает запросы. Только патчей для такого оборудования больше нет, гарантия не действует, а нужная плата для ремонта едет через третьи страны и обходится кратно дороже прайса.
С 27 мая 2026 года эта плата вообще не может попасть в Россию легально: Минпромторг исключил из параллельного импорта серверы, рабочие станции и накопители Cisco, HPE, IBM, Intel, Samsung и десятков других брендов. Для значимых объектов КИИ — тех, которым по итогам категорирования присвоили одну из трех категорий значимости, — действует отдельный срок: переход на доверенные программно-аппаратные комплексы к 1 января 2028 года, который Минцифры готово сдвигать до 2036 года при заключении отдельного проекта с правительством, но не отменяет совсем.
В этой статье команда SimpleOne ITAM разбирает, как найти оборудование ушедших вендоров в своей инфраструктуре, посчитать реальную стоимость его содержания и выстроить приоритеты замены на основе критичности, а не даты закупки.
В чем проблема импортного железа
Когда инфраструктура держится на ушедших вендорах, накапливаются три проблемы одновременно.
Иностранные вендоры, ушедшие из России — включая Cisco, Dell и HPE, — закрыли российским клиентам легальный доступ к обновлениям. Патчи и бюллетени по уязвимостям выходят по-прежнему, но получить их официально нельзя: контракт на поддержку не действует, портал загрузки закрыт, обращение в техподдержку и замена по гарантии недоступны. Прошивку можно найти в неофициальных источниках, но проверить её подлинность нечем — это не решение, а ещё один риск. В итоге уязвимость в прошивке или ОС коммутатора остаётся открытой до тех пор, пока оборудование не заменят или не изолируют вручную.
Гарантия на такое железо не действует. Если коммутатор сломался, вендорской поддержки ждать бесполезно, придется разбираться своими силами или искать инженера, который когда-то сертифицировался у производителя и еще помнит специфику модели.
Параллельный импорт закрыт для новых поставок именно тех категорий, где чаще всего требуется замена — серверы, СХД, сетевое железо. Оставшиеся каналы идут через третьи страны — Казахстан, Киргизию, Китай, — но и там становится сложнее: с апреля 2026 года выросли требования электронного мониторинга транзита, а часть грузов, идущих через Киргизию, вставала на границе на срок от полутора недель до нескольких месяцев из-за оформления разрешений.
Масштаб перехода на отечественные решения неравномерный. По оценке АРПП, к концу 2025 года на отечественный софт перешли 40–45% субъектов КИИ, а по серверным операционным системам замещение превысило 90%. С физическим железом ситуация хуже, но насколько — публично не считает никто: сопоставимой статистики по замещению оборудования нет. Причина отставания известна из практики: процессоры, СХД и сетевые устройства обновляются медленнее софта, потому что стоят дороже и требуют остановки сервиса на время миграции. В холдинговых структурах с несколькими юрлицами и ЦОДами масштаб проблемы обычно еще больше, поскольку у каждого филиала или дочерней компании свой парк, своя история закупок и свой уровень зрелости учета, поэтому единой картины по группе компаний чаще всего просто не существует.
Зачем разбираться с санкционкой
Содержание парка на ушедших вендорах имеет цену, и она растет с каждым годом эксплуатации.
Запчасть через параллельный импорт несёт риск не только переплаты, но и подделки: по данным CNews, доля контрафактных комплектующих для инфраструктурного оборудования в России в среднем составляет 18%, а в сегменте серверного и сетевого оборудования зарубежных вендоров — Dell EMC, Cisco, Lenovo, Hitachi — приближается к 80%. Простой без вендорского SLA считается не часами реакции, а днями ожидания детали из третьей страны. К этому добавляется риск-премия: если критичный сервис держится на оборудовании без поддержки, компания либо резервирует его дублирующим железом, либо смиряется с вероятностью длительного инцидента.
Но и замена — не бесплатный выход: российские серверы не решают проблему автоматически. По расчетам ИТ-компании ALP ITSM, отечественные серверы стоят в 2,5–3 раза дороже, чем Dell или HP стоили до 2025 года. Сравнивать при этом нужно с сегодняшней ценой: купить Dell по прежнему прайсу уже нельзя, а с наценкой параллельного импорта разрыв сокращается, а любой сервер съедает на обслуживание около 10–15% своей стоимости в год. Оценка принадлежит ИТ-аутсорсеру — стороне, которая обслуживание и продаёт, поэтому её стоит примерять на свои цифры. При цене сервера в 2,3 млн рублей это 230–350 тысяч рублей ежегодного скрытого расхода, который редко попадает в бюджет заранее.
Получается вилка: содержать старое — дорого и рискованно, купить новое — дорого сразу. Искать санкционку нужно для того, чтобы не выбирать между этими двумя вариантами вслепую, а понимать, Для конкретной единицы оборудования обычно берут простой сигнал: если сумма ремонтов за год превышает годовую амортизацию актива, чинить его дальше уже невыгодно. Это отправная точка для разговора, а не ответ. Амортизация — бухгалтерская величина, а не реальный расход, поэтому сравнение с деньгами на ремонт даёт только грубый ориентир; ближе к делу считать содержание против годовой доли стоимости замены. И даже такой расчет не учитывает, что выход из строя критичного узла обходится дороже, чем ремонт второстепенного, и что срок поставки замены иногда решает вопрос быстрее любых цифр. Для санкционного железа обе поправки весомее обычного: ремонт дорожает с каждым годом из-за закрытых каналов поставки.
Например, у компании есть два сервера Dell одного возраста и одинаковой остаточной стоимости: один обслуживает архивное хранилище, которым пользуются раз в квартал, второй — процессинг заказов в пиковый сезон. Формально оба попадают под замену по одинаковому расчету «ремонт дороже амортизации». Но для архивного сервера простой в две недели ожидания платы не критичен, а для процессингового — это прямые потери выручки каждый день простоя. В такой ситуации решение принимается не по формуле, а по риск-скорингу, где критичность сервиса перевешивает чистую экономику ремонта.
Как найти оборудование, которое несет риски
Списка такого оборудования в компании обычно нет, и это первое, с чем приходится столкнуться. Спросите ИТ-директора, сколько единиц Cisco или Dell работает в компании прямо сейчас, и в большинстве случаев вам скажут, что нужно уточнить.
Проблема в том, что единой отправной точки для поиска не существует. Данные об оборудовании где-то в компании есть — в инвентаризационных таблицах, закупочных документах, результатах сетевого дискаверинга, — но они разрозненны: их вели разные люди в разное время, часть техники покупали до 2022 года, часть — параллельным импортом позже, часть — вообще напрямую подразделениями, минуя централизованный учёт. Сами по себе эти источники никогда не сходятся друг с другом: инвентарные записи расходятся с закупками, дискаверинг не видит оборудование в изолированных сегментах, за NAT или без установленного агента. Учёт вели в Excel, который обновляли по настроению, или не вели вовсе.
Чтобы начать искать санкционное железо, компании сначала нужно собрать эти источники в одну достоверную картину. ITAM-система здесь работает как инструмент сведения данных: она сопоставляет то, что уже есть в разных источниках, и показывает расхождения между ними. Разовое сканирование эту задачу не решает — сведение данных растягивается на месяцы, особенно когда источники противоречат друг другу на значимых объектах КИИ, где сетевые сегменты закрыты для сканирования по требованиям безопасности.
Грубый срез можно получить сразу: по данным с сетевого оборудования и по закупкам видно, каких вендоров в парке больше всего. Достоверная картина складывается по мере сведения источников — но искать в обоих случаях нужно одно и то же:
сколько единиц оборудования числится за вендорами, ушедшими из РФ, и по каким моделям;
где физически стоит каждая единица — серверная, филиал, рабочее место конкретного сотрудника;
к какому бизнес-сервису привязано оборудование — что откажет, если сломается именно этот коммутатор;
когда закончилась официальная гарантия или контракт на поддержку;
есть ли по этой модели известные уязвимости, которые уже не закрываются.
Привязка оборудования к бизнес-услуге — отдельная сложность внутри этого списка: дискаверинг покажет физическую единицу, но связь «этот коммутатор обслуживает ERP филиала» появляется только там, где её либо задокументировали заранее, либо восстанавливают вручную через интервью с владельцами сервисов. Насколько трудоемким может быть даже этот шаг, показывает такой случай: у промышленной компании с одним ЦОДом обнаружился коммутатор Cisco Catalyst без владельца в CMDB — по закупочным документам он числился за отделом, который расформировали два года назад. Выяснить, что через него идёт трафик системы учета складских остатков, удалось только после того, как ИТ-служба вручную прошла по портам коммутатора и сопоставила MAC-адреса подключенных серверов с перечнем бизнес-приложений. На это ушло около трёх недель работы одного инженера — притом что оборудование всё это время оставалось без патчей и без понимания его критичности.
Дальше список превращается в план — но не автоматически, а через согласование с несколькими сторонами: службой безопасности (какие уязвимости критичны), финансами (бюджет и амортизация) и владельцами бизнес-сервисов (что действительно нельзя останавливать). На этом этапе нужно сделать три вещи.
Во-первых, выделить оборудование, которое одновременно относится к значимому объекту КИИ, потеряло гарантию и имеет известную уязвимость — именно оно уходит в приоритет на замену первым.
Во-вторых, отложить то, что не создает риска прямо сейчас: например, резервный коммутатор на складе может спокойно подождать следующего квартала, если он не нагружен и не привязан к критичному сервису.
Отложить — не значит ничего не делать. Пока замена ждёт бюджета, риск снижают компенсирующими мерами: управляющие интерфейсы выносят в закрытый сегмент, лишние сервисы управления отключают, доступ ограничивают списками, за оборудованием ставят мониторинг аномалий, а на складе накапливают детали с выведенных из работы машин. Для части парка выходом становится поддержка от сторонних сервисных компаний — в России это уже отдельный сегмент рынка.
В-третьих, если единиц оборудования не одна и не десять, а сотни или тысячи по нескольким ЦОДам и юрлицам — как это обычно бывает в enterprise, — переходить от ручного просмотра списка к скорингу по критичности. Скоринг собирается из признаков, которые уже есть в карточке актива: критичность бизнес-сервиса, статус объекта КИИ, наличие незакрытой уязвимости, доступность российского аналога и срок его поставки. Каждый признак получает вес, список сортируется сам, и приоритизация перестает занимать месяцы. Если на выяснение принадлежности одного коммутатора уходит три недели, тысяча единиц оборудования требует не списка, а системы скоринга, которая считает риск автоматически.
Резюме
Железо ушедших вендоров не исчезло из инфраструктуры — оно осталось работать без обновлений, без гарантии и с дорогими запчастями. Каждый год эксплуатации увеличивает риск, потому что уязвимость может остаться открытой, деталь может не найтись вовремя, а параллельный импорт закрывается по все большему числу позиций.
Первый шаг — инвентаризация, а закупка отечественных аналогов идет вторым. Без списка оборудования, привязки к бизнес-сервисам и данных о сроках поддержки замена идет наугад. Получается, бюджет уходит на менее критичный узел, а по-настоящему уязвимый остается без внимания до первого инцидента.
ITAM дает для этого исходные данные — что стоит, где стоит, что на нем держится и что закончилось, — но сами данные не появляются автоматически, поскольку система работает только там, где инвентаризация, закупки и дискаверинг регулярно сверяются между собой, а не проверяются один раз при внедрении. Приоритизация замены строится на конкретных признаках — значимость для КИИ, роль в инфраструктуре, наличие уязвимостей, доступность российского аналога — и на согласовании между ИТ, безопасностью и финансами.
А у вас в компании есть точный список оборудования на ушедших вендорах — или его придется собирать по серверным, филиалам и юрлицам вручную?