Статус сервисов, экстренный перенос данных и выбор нового провайдера
Александра Даньшина, ведущий специалист по информационной безопасности компании Б-152
В начале октября 2026 года инфраструктура Яндекса подверглась серии атак: беспилотники вывели из строя несколько дата-центров компании. Yandex Cloud переведен в аварийный режим, десятки сервисов недоступны, тысячи клиентов вынуждены искать резервные площадки.
Что произошло: хронология атак на ЦОДы Яндекса
- 8 октября – атака на ЦОД в Сасово Рязанской области. Пожар, работа площадки полностью остановлена. Недоступна зона ru-central1-b.
- 9 октября – атака на ЦОД в Калуге. Несколько модулей выведены из строя. Яндекс договорился с Selectel, K2Cloud и VK Cloud об ускоренном размещении пострадавших клиентов.
- 10 октября – переход на ручное управление квотами на вычисления и диски. Пользователям доступен небольшой дополнительный объем ресурсов сверх используемых, создание новых ресурсов сверх лимитов ограничено. Приоритет в расширении отдан клиентам, чьи критичные сервисы не восстановлены. Также изменено пользовательское соглашение сервисов Яндекс: добавлен раздел с основаниями освобождения от ответственности и обстоятельствами непреодолимой силы.
- 11 октября – атака на ЦОД во Владимире. Нарушение электроснабжения, площадка остановлена. Недоступна зона ru-central1-a. Платформа в аварийном режиме, выдача дополнительных квот приостановлена.
В связи с ограниченным режимом работы платформ Yandex Cloud принято решение о предоставлении бесплатной возможности использования сервисов Yandex Cloud текущими клиентами во всех зонах доступности РФ с 8 по 31 октября включительно. В счете за октябрь будут отражены только расходы на ресурсы, использованные до 7 октября включительно.
Текущий статус сервисов и когда ждать возобновления работы
По последним обновленным данным по состоянию на 13 октября затронуто более 60 компонентов облачной инфраструктуры, Yandex Cloud продолжает работать в аварийном режиме. Компания опубликовала рекомендации по восстановлению ресурсов, однако пока не называет конкретные сроки восстановления.
По экспертной оценке, возможны следующие сроки восстановления:
- 2-3 недели – на стабилизацию ядра массовых сервисов за счет перенаправления трафика и отключения второстепенных функций.
- 3-4 месяца – на закупку обычных серверов.
- до 2 лет – на закупку GPU-серверов.
- около 1,5 лет – на строительство новых ЦОДов, сопоставимых с поврежденными; оснащение оборудованием займет еще больше времени.
Экстренный перенос данных: пошаговый алгоритм
- Приоритезируйте перенос инфраструктуры. Переносите инфраструктуру на резервные площадки в следующей последовательности:
Приоритет Что входит Действие
П0 Невосстановимые данные, ключи шифрования, секреты, DNS-зоны, сертификаты, конфигурации и IaC Выгрузка за пределы облака немедленно, проверка контрольными суммами, локальные резервные копии
П1 Продуктовые БД и сервисы, приносящие основную выручку или критичные по требованиям клиентов Репликация или перенос на резервную площадку, запуск минимально жизнеспособного сервиса
П2 Второстепенные сервисы, внутренние системы, тестовые среды Перенос после П1 или восстановление из бэкапа по мере появления таких возможностей
П3 Архивы, пересоздаваемые окружения, кэши Оставить в облаке, пересоздать позднее
- Сохранение копий. Нужно постараться скопировать все, что только получится. И до момента, пока на новой площадке не будет подтверждено, что данные целы и система работает, старый контур отключать или удалять нельзя.
- Запуск в минимальной конфигурации. На резервной площадке первым делом поднимается только базовый набор функций, чтобы пользователи могли авторизоваться и выполнить ключевые действия. Аналитика, фоновые процессы и второстепенные интеграции подключаются на более позднем этапе.
- Пауза на изменения. Пока идет переезд, обновления и релизы лучше приостановить. Любое изменение, не связанное с восстановлением работы, способно добавить новых рисков.
- Безопасность в аварийном режиме. Даже когда все работает в режиме повышенной готовности, о защите забывать нельзя – ослабление контроля открывает дорогу атакам.
В Международном стандарте № ISO/IEC 27002:2022(E) от 01.02.2022 указана мера 5.29, которая так и звучит «Информационная безопасность во время сбоев». Исходя из данной меры:
- организация должна определить свои требования к адаптации средств контроля информационной безопасности в случае сбоев в работе. Требования к информационной безопасности должны быть включены в процессы управления непрерывностью бизнеса.
- необходимо разработать, внедрить, протестировать, проанализировать и оценить планы по поддержанию или восстановлению безопасности информации, связанной с критически важными бизнес-процессами, после прерывания или сбоя в их работе. Безопасность информации должна быть восстановлена на требуемом уровне и в требуемые сроки.
- Документирование. При аварийном переносе инфраструктуры на резервные площадки нужно фиксировать каждое принятое решение и каждое выполненное действие. Это пригодится и для разбора инцидента, и для отчетности перед регулятором и клиентами.
Временные ориентиры: что успеть за 4, 24 и 72 часа
События уже произошли, и никто их не ожидал. Но чтобы быть готовыми в следующий раз, рекомендуем следующие временные отрезки
Период Что должно быть сделано
Первые 4 часа Создана группа ответственных за перенос инфраструктуры, распределены роли и назначены задачи. Запущена выгрузка данных первого приоритета (П0). Отправлены запросы ресурсов минимум двум-трем провайдерам. Заморожены изменения.
До 24 часов П0 выгружен и проверен. Для П1 определена целевая резервная площадка и подтверждена емкость. Подготовлены образы, инфраструктура и сетевая схема на новой резервной площадке. Клиенты получили первое официальное сообщение.
До 72 часов П1 работает на новой площадке в урезанном режиме. Подготовлено переключение DNS и откат. Начат перенос П2.
После 72 часов Стабилизация, возврат полного функционала, настройка бэкапов и мониторинга на новой площадке, разбор ошибок и выстраивание дальнейшего плана работы.
Представленные сроки являются ориентировочными и зависят от масштаба инфраструктуры и возможности получения доступа резервной площадки.
Как выбрать нового провайдера в условиях дефицита
Перенос инфраструктуры логично разбить на два шага. Сначала – быстрый переезд в те ЦОДы, где письменно подтверждено наличие необходимых мощностей. Затем, через 1-4 недели, – перенос критичных систем на более удаленные площадки, защищенные подтверждающими документами.
Указанные локации не являются исчерпывающим перечнем площадок провайдеров. Перед переносом необходимо подтвердить наличие свободных мощностей в нужном регионе и проверить применимость документов о соответствии требованиям к выбранной услуге. Статус включения поставщика в реестр провайдеров хостинга Роскомнадзора следует проверять отдельно.
На что стоит обращать внимание при выборе площадки:
- Рассмотрите сразу несколько провайдеров и заранее проверьте наличие документов, подтверждающих выполнение требований к защите информации, в том числе применимых требований к ИСПДн.
- Запросите ресурсы. Если ответят несколько площадок – выберите ту, которая лучше подходит по условиям.
- Когда облачных мощностей нет, обратите внимание на ЦОДы с услугами Bare Metal или Colocation.
- Изучите окружение площадки и запросите документы, подтверждающие ее устойчивость к внешним воздействиям: конструктив здания, расчет на особые динамические нагрузки, секционирование и охрану периметра.