Атаки на дата-центры Яндекса и их последствия для бизнеса

Какие сервисы Яндекса пострадали и что делать бизнесу

С 8 октября 2026 года несколько дата-центров Яндекса вышли из строя из-за атак беспилотников. Повреждена часть серверной инфраструктуры, резервные мощности ограничены, а облачная платформа Yandex Cloud перешла в аварийный режим.

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

Хронология событий

• 8 октября — атака на ЦОД в Сасово Рязанской области. Пожар, площадка полностью остановлена.
• 9 октября — атака на ЦОД в Калуге. Несколько модулей выведены из строя.
• 10 октября — Яндекс перешел на ручное управление квотами на вычисления и диски. Пользователям доступен небольшой дополнительный объем ресурсов сверх используемых, создание новых сверх лимитов ограничено. Также изменено пользовательское соглашение: добавлен раздел с основаниями освобождения от ответственности и обстоятельствами непреодолимой силы.
• 11 октября — атака на ЦОД во Владимире. Нарушение электроснабжения, площадка остановлена, платформа в аварийном режиме.

В связи с ограниченным режимом работы платформ принято решение о предоставлении бесплатного доступа к сервисам Yandex Cloud текущим клиентам во всех зонах доступности РФ с 8 по 31 октября включительно. В счете за октябрь будут отражены только расходы на ресурсы, использованные до 7 октября.

В каких сервисах наблюдались сбои

По данным на 13 октября, сбои в работе обнаружены более чем в 60 сервисах облачной инфраструктуры: Yandex Cloud Status.

• Вычислительные ресурсы и контейнеры — Compute Cloud, Container Registry, Managed Service for Kubernetes, Serverless Containers, Cloud Apps, Cloud Desktop, Yandex BareMetal.
• Сети и балансировка нагрузки — Virtual Private Cloud, Network Load Balancer, Application Load Balancer, Cloud Interconnect, Cloud DNS, Cloud Router.
• Хранилища и объектное хранение — Object Storage, Yandex StoreDoc, Cloud Backup.
• Управление идентификацией и доступом — Identity and Access Management, Key Management Service, Yandex Lockbox, Yandex Identity Hub.
• Управление ресурсами и оркестрация — Resource Manager, Cloud Quota Manager.
• Базы данных — Managed Service for PostgreSQL, ClickHouse, MySQL, Valkey, YDB, OpenSearch, Apache Airflow, Prometheus, Trino, Sharded PostgreSQL, Apache Spark, Yandex MPP Analytics Engine for PostgreSQL.
• Обработка и передача данных — Data Processing, Data Transfer, Data Streams, Message Queue, DataSphere.
• ИИ, распознавание и перевод — SpeechKit, Translate, Vision OCR, YandexGPT API, SmartCaptcha, SpeechSense, Yandex AI Studio.
• Бессерверные и событийные вычисления — Cloud Functions, API Gateway.
• Мониторинг, логирование, аудит — Monitoring, Cloud Logging, Audit Trails, Yandex Query.
• Инструменты разработки и DevOps — Managed Service for GitLab, SourceCraft, SourceCraft Code Assistant, Cloud Registry, Marketplace.
• Безопасность и защита — Smart Web Security, GOST Gateway, Yandex Cloud Detection and Response, Yandex SIEM.
• Интеграции, медиа и вспомогательные сервисы — Tracker, Forms, Wiki, Yandex Cloud Video, Yandex MetaData Hub, Support Center, Cloud Notification Service, Yandex Cloud Postbox, Yandex WebSQL, Yandex Neurosupport, Stackland, Monium, VibeCraft.

Яндекс предупреждает о мошенниках 

Мошенники могут использовать ситуацию в своих интересах. Яндекс предупреждает о возможных фишинговых сообщениях от лица компании. Типичные предлоги:

• Данные повреждены — войдите для восстановления.
• Аккаунт заблокирован из-за сбоя.
• Компенсация за простой — укажите реквизиты.
• Срочная миграция — откройте вложение.

Компания никогда не просит по электронной почте пароли, коды двухфакторной аутентификации, API-ключи, реквизиты карт и удаленный доступ.

Как распознать мошенническое письмо

• Отправитель. Реальный адрес должен быть на домене @yandex.cloud.
• Ссылки. Наведите курсор до клика. HTTPS ≠ безопасность. Вместо перехода по кнопке в письме откройте сайт вручную.
• Срочность. Фразы вроде «подтвердите за 24 часа» — признак атаки.
• Вложения. Не открывайте .exe, .js, .zip с паролем и .docm.

Как безопасно перенести данные на другую площадку

1. Начните с самого важного. В первую очередь перевозите то, без чего бизнес не выживет: базы данных, ключи шифрования, ключевые документы. Следом — сервисы, на которых держится нагрузка. Остальное можно переносить в последнюю очередь.
2. Сделайте копии всего, что получится. Также исходную площадку нельзя отключать или чистить до тех пор, пока на новом месте не будет подтверждено, что данные целы и все работает.
3. Запускайте по минимуму. На новой площадке сначала поднимите только базовые функции — чтобы сотрудники и пользователи могли войти и выполнить основные действия. Аналитику, фоновые задачи и второстепенные интеграции подключите позже.
4. Поставьте обновления на паузу. Пока идет переезд, лучше воздержаться от релизов и изменений. Любая лишняя правка, не связанная с восстановлением, может создать новые проблемы.
5. Не ослабляйте защиту. Даже в аварийном режиме безопасность должна оставаться на уровне. Снижение контроля в такой момент — прямой путь к новым атакам.
6. Записывайте все. Фиксируйте каждое принятое решение и каждое выполненное действие. Это понадобится и для разбора ситуации, и для отчетов перед регулятором и клиентами.

Какие ошибки нельзя допускать при переносе данных

• Не удаляйте данные в старом ЦОД, пока не убедились, что все работает на новом. Держите оба контура, пока не подтвердится целостность.
• Не останавливайте резервное копирование и репликацию ради снижения нагрузки, не оценив последствия. Лучше снизить приоритет задач и перенести окна на ночное время.
• Не выдавайте широкие права доступа и не отключайте двухфакторную аутентификацию. Используйте временные роли с ограниченным сроком и защищенные хранилища для ключей.
• Не переходите по ссылкам из писем о «срочной миграции». Проверяйте любые запросы через официальные каналы: статус-панель, личный кабинет, телефон поддержки с официального сайта.
• Не переносите персональные данные на случайные площадки без шифрования и без решения ответственного за обработку данных. Площадка должна соответствовать требованиям для размещения ИСПДн.
• Не переключайте трафик без плана отката. Проведите нагрузочное тестирование, подготовьте план отката и переводите трафик постепенно.
• Не подписывайте многолетние контракты с первым ответившим провайдером. На аварийный период используйте краткосрочные договоры с четкими SLA, критериями выхода и правом расторжения.
• Не доверяйте слухам. Определите официальный источник статусов и назначьте ответственного за мониторинг.

Как выбрать нового провайдера для переноса инфраструктуры

Перенос инфраструктуры логично разбить на два шага. Сначала — быстрый переезд в те ЦОДы, где наличие мощностей подтверждено письменно. Затем, через одну–четыре недели, — перенос критичных систем на более удаленные площадки, защищенные подтверждающими документами.

На что обратить внимание при выборе провайдера

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

Доступные провайдеры:

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

Включение поставщика в реестр провайдеров хостинга также следует проверять по актуальным сведениям Роскомнадзора. 

Александра Даньшина

ведущий специалист по информационной безопасности компании Б-152