Тихий указ и громкий дрон: почему №604 — это не про национализацию, а про управление переходом
Указ Президента РФ №604 «О мерах по обеспечению безопасности объектов критической инфраструктуры Российской Федерации» вступил в силу 24 августа, но прошел почти незамеченным на фоне летних отпусков и более громких сюжетов. А 8 октября дрон ударил по дата-центру «Яндекса» в Сасово. И оказалось, что указ писался ровно под этот сценарий.
Напомню, Сасово — не рядовой объект: 2014 год, более 6 млрд рублей на его создание, 12 МВт, здесь находятся два из трех суперкомпьютеров компании. В ночь на 8 октября дрон ударил по Сасово, начался пожар, дата-центр полностью остановил работу. На следующее утро, 9 октября, — удар по дата-центру в Калуге, где несколько модулей оказались полностью выведенными из строя. А 11 октября стало известно о третьем ударе — по дата-центру во Владимире, работа которого также полностью остановлена.
Три удара за четыре дня. Три площадки — Сасово, Калуга, Владимир. Это уже не серия инцидентов, а система. У сотрудников «Т-Банка» замолчал корпоративный мессенджер, встали рассылки. Облачные платформы «1С», ТСП, сайты девелоперов и сервисы электронной отчетности — все это на несколько часов стало недоступно для миллионов людей. Пик жалоб пользователей на порталах мониторинга сбоев (например, СБОЙ.РФ) пришелся как раз на эти дни. Мы привыкли обсуждать кибербезопасность как вопрос технологий. Но удар дрона, включая последствия — это вопрос архитектуры. И указ — это не про наказание, а про то, как государство пытается управлять переходом от одной архитектуры к другой. Разберем ситуацию с цифрами и без паники.
Что именно написано в указе
Указаны пять оснований для временного управления:
Непринятие или несвоевременное принятие мер по обеспечению безопасности.
Нарушение установленных требований безопасности.
Создание угрозы безопасности или нормальному функционированию объекта.
Выявление неэффективности мероприятий по пресечению угроз БПЛА.
Невосстановление или несвоевременное восстановление функционирования.
Временным управляющим назначается Росимущество либо иное лицо по поручению Президента. Полномочия собственника: владение и пользование, без распоряжения. Финансирование — за счет доходов от имущества. Решение принимает Правительство по поручению Президента.
Президент 1 сентября подчеркнул: документ «не подразумевает национализации», и собственникам, которые примут меры для защиты и восстановления, «не о чем беспокоиться». Это важная рамка. Но если сказать юридически точнее: рамка — это еще не критерий.
Новый указ: инструмент защиты или ловушка для бизнеса?
Ключевая юридическая особенность указа — отсутствие формализованных критериев. Что такое «своевременное» принятие мер? Каков предельный срок восстановления? Как измерить «эффективность» противодействия БПЛА, если нет ни методики, ни эталонного уровня защиты?
Получается как в притче о крепости, стены которой возвели после того, как неприятель разрушил жилища. Указ требует немедленной защиты, но не говорит, какой именно и в какие сроки. А без этого требования превращаются в инструмент, который можно применить к любому, кто не успел или «не угадал».
Президент РСПП, уполномоченный по правам предпринимателей Александр Шохин уже официально заявил, что документ «требует уточнений для обеспечения прозрачности правоприменения». Он конкретно указал на три вопроса: что означает «несвоевременное восстановление»? Кто несет «зеркальную» ответственность временного управляющего? Как финансируется эта ответственность — нужны механизмы страхования.
Шохин также предупредил: временное управление не должно стать инструментом недобросовестной конкуренции. Это означает, что даже без формальной национализации механизм создает риск перераспределения активов — и регулятор это слышит. Я с большим уважением отношусь к коллегам, которые готовили документ №604 — все стараются. Но системная проблема очевидна: мы снова получили механизм без метрики. А механизм без метрики — это не управление, а имитация управления. Только на этот раз — в сфере, где цена ошибки измеряется не репутацией, а непрерывностью платежей.
Не только ЦОДы: указ как требование инженерной зрелости для всей ИТ-инфраструктуры
Мы обсуждаем указ как историю про дата-центры. Но посмотрите на пункт 6: объекты связи, энергетики, транспорта, логистики, ЖКХ, «иные объекты, имеющие особо важное значение». Под действие подпадают ЦОДы уровня Tier III и выше, обслуживающие госорганы, банки, федеральных операторов. Ключевой критерий — объекты связи. Поэтому указ не про «крупные ЦОДы», он про всю отрасль, включая региональных операторов.
И вот здесь кроется ключевое обстоятельство для банковского сообщества. Банки годами выстраивали двухконтурную архитектуру: собственный ЦОД как «суверенный контур», внешнее облако как «быстрый контур». Логика была разумная: свое — для критичного, чужое — для гибкого. Три удара по «Яндексу» показали: граница между контурами оказалась проницаемой. Если CRM, колл-центр, платежный модуль или аналитика завязаны на внешнее облако — банк уязвим точно так же, как провайдер. Это, конечно, не значит, что двухконтурность не работает. Это значит, что ее придется достраивать: резервные контуры, автоматическое переключение, географическое распределение. Указ — это не наказание за двухконтурность, а требование довести ее до инженерной зрелости.
Риск и инструмент: две стороны указа
Указ можно прочитать как угрозу за архитектуру, построенную без учета нынешних реалий СВО. Но можно и так: защита интересов и помощь тем, кто готов вкладываться в безопасность.
Сам факт появления единой рамки надо приветствовать: до указа не было единого документа, задающего требования к физической защите, антидроновым системам и всему прочему из этой серии. Теперь появилась важная рамка для планирования CAPEX и обоснования затрат перед акционерами и правлением. Документ также подталкивает операторов не концентрировать мощности в одном регионе — для банков это означает появление большего числа площадок с резервированием. Банк, арендующий мощности, сегодня просто обязан проявить активность и запросить подтверждение соответствия указу — и если провайдер не соответствует, есть формальное основание менять поставщика. Однако Шохин прямо предупредил: механизм не должен стать инструментом недобросовестной конкуренции.
И еще один момент, который отмечу: CISO часто слышат от правления «безопасность — непроизводственные расходы». Указ меняет тональность подобного разговора — практически все пожелания CISO превращаются в требования, за несоответствие которым может последовать временное управление. Это весомый аргумент, которого не было.
Практический вывод: документ — не только ограничение, но и инструмент развития. Для операторов, готовых вкладываться в безопасность, он создает понятные правила игры. Для банков — основание требовать от провайдеров соответствия.
Связка, которую нельзя игнорировать: пункт о форс-мажоре vs. Указ
После ударов по трем ЦОДам «Яндекс» внес во все свои договоры новый пункт — о форс-мажоре, распространяющийся на атаки беспилотников. Логика компании понятна: если инфраструктура повреждена внешним воздействием, компания не должна нести договорную ответственность за сбои в сервисах.
Но отмечу ключевой момент: пункт о форс-мажоре и указ работают в разных плоскостях — они не отменяют друг друга.
Пункт о форс-мажоре решает гражданско-правовую задачу: освобождает «Яндекс» от ответственности перед клиентами и партнерами за невозможность предоставить услугу. Это защита в суде — если клиент подаст иск о компенсации убытков. Указ же решает административную задачу: наделяет государство правом ввести временное управление, если оператор не принял эффективных мер защиты. Это уже не про суды, а про управление.
Поэтому пункт о форс-мажоре не освобождает от обязанности обеспечивать безопасность. Если оператор ссылается на «атаку дрона» как на форс-мажор, но при этом не развернул антидроновые системы, не усилил физическую защиту, не обеспечил резервирование — он все равно становится кандидатом на временное управление. Форс-мажор объясняет, почему произошел сбой (атака БПЛА). Обсуждаемый НПА спрашивает: что вы сделали, чтобы сбоя не произошло. По сути «Яндекс» с опозданием решил защитить себя от договорных претензий. Однако, законодатель через указ заявил: если провайдер не защитил инфраструктуру — я приду к нему управлять. Эти два пассажа не противоречат друг другу. Они — две стороны одной монеты: первый ограничивает частные иски, второй создает административный риск.
Для всех операторов ЦОД это означает: даже тщательно прописанный пункт о форс-мажоре — это не индульгенция. Это лишь инструмент судебной защиты. Фундаментальный способ избежать риска — реальные меры физической защиты, а не изощренные юридические формулировки.
Что все это значит для клиентов и операторов ЦОД
Для оператора ЦОДа. Соответствие новым требованиям — часть нормальной операционной практики. Затраты на модернизацию лягут на оператора, их важно планировать заранее. Рост CAPEX транслируется в стоимость услуг — это неизбежно. Кроме того, три удара по инфраструктуре одного игрока показывают: географическое распределение перестает быть просто «хорошей практикой» и становится критичным условием выживания.
Для банка-клиента. Если банк арендует мощности у провайдера, банку важно незамедлительно убедиться, что провайдер соответствует требованиям указа. Это вопрос не только операционной устойчивости, но и регуляторной предсказуемости. Договоры, SLA, условия о форс-мажоре — все это стоит пересмотреть. И отдельно — проверить, не завязаны ли критичные сервисы на площадку, которая уже была атакована.
Что делать? Три вещи, которые важнее остальных
Я специально не стал делать длинный чек-лист. Вот три вещи, которые действительно меняют картину.
Первое: аудит зависимостей. Ответ ИТ-шников «мы не знаем, где хостятся наши критичные сервисы» становится регуляторным риском. Нужна карта: какой сервис, какой ЦОД, какой провайдер, какой контур резервирования. Без этой карты невозможно ни пересмотреть договоры, ни подготовить учения — вы просто не знаете, что именно проверять.
Второе: пересмотр договоров с провайдерами. Есть ли резервный ЦОД с автоматическим переключением? Есть ли физическая защита от БПЛА? Соответствует ли он требованиям указа? Если нет — это не просто коммерческий риск, а регуляторный. И помните: пункт о форс-мажоре у провайдера — не ваша тема в переговорах. Ваша тема–соответствие указу.
Третье: учения по сценарию «внешний ЦОД недоступен». Проверьте на практике, а не на бумаге, что работает при отключении основного контура. Три удара по «Яндексу» — это три возможных сценария для учений.
Ну и киберустойчивость никто не отменял. Физическая атака — только одна сторона. Пока вы разбираетесь с последствиями удара дрона, вас могут атаковать через киберканал. Задокументируйте меры защиты — чем прозрачнее ваша система оценки рисков, тем проще подтвердить соответствие указу.
Вместо послесловия
Указ №604 — это про управление переходом от одной архитектуры критической инфраструктуры к другой. Механизм временного управления — крайняя мера для исключительных случаев. Для добросовестных операторов, которые своевременно модернизируют защиту и документируют решения, он не создает непреодолимых рисков.
Сасово — по оценкам аналитиков, это примерно 5% от общей емкости «Яндекса». Но это первый масштабный инцидент, который задает планку для всей отрасли. Теперь к нему добавились Калуга и Владимир. Три площадки, три удара, четыре дня.
Когда я дописывал этот текст, мне прислали скриншот из чата ИТ-директоров: кто-то спрашивал, где срочно искать антидроновые системы, а кто-то отвечал, что их все равно нет в наличии. Это, пожалуй, лучшая иллюстрация момента — пока одни спорят о тонкостях указа, другие уже пытаются что-то сделать. Разница существенная — кто-то сочтет и этот текст как руководство к действию, а кто-то — только как повод для паники.
Срочно добавленный «Яндексом» пункт о форс-мажоре, конечно, защитит компанию от исков со стороны условного «Т-Банка». Но он не защитит саму инфраструктуру.
Указ №604 напоминает: государство будет оценивать не юридические формулировки, а реальное положение дел на площадках. И главная проблема сегодня кроется не в самом документе, а в жестком дефиците визионеров, способных оперативно трансформировать новые требования в работающую ИТ-архитектуру.
При этом самый неудобный вопрос лежит вне плоскости «Яндекса» или регуляторики. Наземный ЦОД уязвим по определению: сколько ни прикрывай его системами ПВО, растет лишь стоимость его уничтожения. Финны это поняли давно, поэтому строили свои критические дата-центры в скальных породах с расчетом на ядерный удар. Вопрос в другом: кто в нашей стране должен был озаботиться этой проблемой заранее и почему этого не сделал?
Это и есть новая реальность, в которой нам придется работать. И, судя по всему, долго.