Безопасность на потом: почему промышленность рискует не успеть к 2030-му

Переход на доверенные ПАК нужно завершить к 2030 году, а классический проект миграции занимает три-четыре года. Как промышленности выиграть это время.

Раньше меняли обвязку, теперь — саму основу

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

Требование о переходе на доверенную инфраструктуру — история принципиально другая. Постановление Правительства РФ 1912 обязывает субъектов КИИ перевести значимые объекты на преимущественное применение доверенных программно-аппаратных комплексов до 1 января 2030 года. И теперь речь идет не о вспомогательных компонентах, а о переносе основных производственных систем на новую, импортонезависимую инфраструктуру, которой раньше просто не было. Задача сложная.

Для промышленности это ощущается острее, чем для большинства отраслей. Практически каждое крупное предприятие — субъект КИИ со значимыми объектами. А переносить необходимо автоматизированные системы управления технологическими процессами (АСУ ТП). Если что-то пойдет не так, встанет производство.

Арифметика, которая не сходится

Посмотрим на классический интеграционный проект — любой план миграции устроен примерно одинаково.

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

Итого — три-четыре года. До дедлайна остается примерно столько же. Времени как будто бы уже в обрез: нужно бежать очень быстро, чтобы уложиться в срок. Это пугает — и парадоксальным образом именно страх чаще всего и тормозит старт.

Почему «мы подождем» — самая дорогая стратегия

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

Проблема в том, что соседа, который прошел этот путь до конца, пока не нашлось. А время идет. Стратегия ожидания хороша, когда у вас есть запас времени на второй заход. Здесь его нет: тот, кто начнет в 2027–2028 годах по классической схеме, к дедлайну не успеет, как бы потом ни старался.

Второй риск ожидания менее очевиден. Чем позже вы стартуете, тем плотнее окажется очередь: производители, интеграторы, собственные ИТ- и ИБ-команды — все ресурсы рынка будут разобраны теми, кто вышел раньше.

Безопасность нельзя достроить потом — особенно в промышленности

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

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

Получается ловушка: либо вы не выполняете требования по безопасности, либо ставите под угрозу работоспособность технологического процесса. Ни один директор по производству на такой выбор не согласится — и проект встанет.

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

Смещение безопасности в начало

Отсюда логика, которая сейчас становится мейнстримом на рынке инфраструктурных решений: функции безопасности закладываются в программно-аппаратный комплекс сразу, на этапе его создания в соответствии с концепцией Secure by Design.

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

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

Важный нюанс: незначительные задержки, которые вносят средства защиты, никуда не денутся — они появляются всегда. Но когда все ИТ-компоненты протестированы в составе программно-аппаратного комплекса заранее, эти показатели известны до внедрения, а не выясняются опытным путем на работающем производстве. Работоспособность АСУ ТП становится предметом гарантии, а не надежды.

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

Жизнь после внедрения: у кого зазвонит телефон

Сроки внедрения — только половина истории. Вторая половина начинается после запуска, и о ней думают заметно реже.

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

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

Когда за весь комплекс отвечает один вендор, схема другая: обновления тестируются на стороне производителя до того, как передаются заказчику, вместе с инструкциями по изменению конфигураций. А если что-то все же происходит — есть техподдержка 24×7 с жесткими SLA и единая точка ответственности. Для конечного заказчика это часто важнее, чем цена входа.

Чего рынку не хватает: единого реестра

Есть вещь, которая сегодня заметно мешает всем участникам процесса, и решить ее силами рынка невозможно.

Критерии доверенного ПАК определены: сведения о комплексе в реестре Минпромторга, программное обеспечение — в реестре Минцифры, а если ПАК реализует функции защиты информации, добавляются сертификаты ФСТЭК России, а для криптографии — ФСБ. Критерии есть. Единого реестра доверенных ПАК пока, увы, нет.

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

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

Открытая АСУ ТП и следующий шаг

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

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

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

Вместо вывода

Четыре года — реальный срок, если стартовать бодро и не пытаться пройти классический маршрут «проект — бюджет — закупка — внедрение — и только потом безопасность». Если же ждать соседа, который набьет шишки первым, времени может просто не хватить.

И еще одно наблюдение, к которому я прихожу все чаще. Как выглядит настоящая безопасность? Максимально незаметно. Она есть — но выглядит так, будто ее нет. Именно к этому состоянию и стоит идти: не к дополнительному контуру, который приходится обслуживать и оправдывать, а к свойству инфраструктуры, о котором на производстве просто не вспоминают. Главный ресурс здесь — время. И умение его сэкономить сегодня определяет, насколько эффективным будет бизнес завтра.