Что делать бизнесу, чья инфраструктура завязана на Яндекс?

В начале октября 2026 г. несколько дата-центров Яндекса вышли из строя в результате атак беспилотников. Часть сервисов компании до сих пор работает с перебоями, а облачная платформа Yandex Cloud переведена в аварийный режим. Для бизнеса, чьи клиенты, данные и процессы зависят от этих сервисов, ситуация означает одно: нужно срочно решать, как действовать дальше. Разбираемся, чего ждать по срокам, что изменилось в оферте и как перенести инфраструктуру на другую площадку.

Ведущий специалист по информационной безопасности компании Б-152 Александра Даньшина

Отсутствие точных сроков восстановления работы и изменения в оферте

Точных сроков восстановления работы компания не называет. Но, по экспертной оценке, минимум 2-3 недели может уйти на стабилизацию ядра массовых сервисов за счет перенаправления трафика и отключения второстепенных функций. А вот восстановление поврежденных дата-центров потребует значительно больше времени — от нескольких месяцев, на закупку обычных серверов, до 2 лет на GPU-серверы и около 1,5 лет на строительство новых ЦОДов.

Отдельно стоит обратить внимание на изменение пользовательского соглашения сервисов Яндекс. Как пишет CNews, компания включила атаки БПЛА в условия освобождения от ответственности при форс-мажоре. Теперь в нем упомянуты не только беспилотники, но также военные действия, теракты, ракеты, обстрелы и взрывы.

При этом само изменение пользовательского соглашения не означает освобождение Яндекса от ответственности во всех случаях. Для клиентов Yandex Cloud возможность компенсации зависит в том числе от условий заключенного договора и соглашения об уровне обслуживания (SLA).

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

Чек-лист: как экстренно перенести данные

1. Расстановка приоритетов. Сначала необходимо перенести самое ценное — это базы данных, элементы безопасности (например, ключи шифрования), наиболее важные документы. Затем — сервисы, которые держат нагрузку. И только потом все остальное; 
2. Сохранение копий. Скопируйте все, что возможно. При переносе не удаляйте и не отключайте первоисточник, пока резервная площадка не заработает стабильно;
3. Запустите сначала минимальный функционал, а далее — фоновые функции, аналитику и другое. Постепенно;
4. Поставьте на паузу обновления и другие изменения в инфраструктуре. Любые перемены могут повлечь за собой новые риски;
5. Фиксируйте все принятые решения. Документация решений, сроков и ответственных поможет для разбора потенциального инцидента, составления отчета, коммуникации с клиентами и регулятором. 

Ошибки при аварийном переносе: как не усугубить ситуацию

• Ошибка 1: Удалять данные и ресурсы в ЦОД, из которого осуществляется экстренная миграция, до подтвержденного запуска на новой площадке.
• Ошибка 2: Останавливать репликацию и бэкапы для минимизации нагрузки на систему, не оценив последствия такого решения.
• Ошибка 3: Выдавать широкие права доступа, отключать 2FA и передавать ключи через мессенджеры и открытую почту.
• Ошибка 4: Переходить по ссылкам в письмах о «срочной миграции» и вводить данные на сторонних страницах. 
• Ошибка 5: Переносить ПДн на случайные площадки без шифрования и без решения ответственного за обработку ПДн и ответственного за обеспечение защиты информации. Если временное размещение неизбежно, фиксируется решение, срок и план переноса на подтвержденную площадку.
• Ошибка 6: Переключать трафик без плана отката и без проверки новой площадки под нагрузкой.
• Ошибка 7: Оформлять срочные многолетние контракты с первым ответившим провайдером. На аварийный период целесообразно заключить краткосрочный договор с возможностью расширения.
• Ошибка 8: Принимать на веру слухи и непроверенные сообщения о состоянии площадок. 

Куда переносить данные: выбор провайдера и доступные площадки на данный момент

Перенос инфраструктуры логично разделить на два этапа: 

1. Быстрый перенос на те ЦОДы, где есть документальное подтверждение мощностей;
2. Через 1-4 недели перенос критических систем на более удаленные площадки, также с документальными подтверждениями мощностей и функциональности.

При выборе провайдера лучше рассмотреть сразу несколько вариантов и заранее проверить у них наличие документов, подтверждающих выполнение требований к защите информации, в том числе применимых требований к ИСПДн. Если облачных мощностей нет, обратите внимание на ЦОДы с услугами Bare Metal или Colocation. Также стоит изучить окружение площадки и запросить документы, подтверждающие ее устойчивость к внешним воздействиям.

¹ https://www.rtcloud.ru/about/bezopasnost/

² https://timeweb.cloud/legal-docs/cert-3.pdf

³ https://cloud.ru/documents/security/topics/certificates

⁴ https://mws.ru/cloud/security/compliance/

⁵ https://selectel.ru/about/security/

⁶ https://k2.cloud/about/documents/

⁷https://cloud.vk.ru/solutions/152-fz/

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