Атака шифровальщика на IDCF Cloud: данные 495 клиентов в четырёх зонах не восстановить, у JR East под угрозой 6,09 млн аккаунтов

7 октября 2026 года шифровальщик атаковал облако IDCF Cloud японского провайдера IDC Frontier (дочерняя компания SoftBank). Пострадали 495 компаний и муниципалитетов, а данные в четырёх зонах региона East Japan Region 1 провайдер восстановить не сможет — вернуть их можно только из собственных бэкапов клиентов. Среди пострадавших — JR East, где под угрозой до 6,09 млн аккаунтов.

Это редкий случай, когда ransomware бьёт не по одной компании, а по самому облаку: сотни арендаторов одновременно теряют серверы и данные, хотя сами не были взломаны. Для бизнеса это прямой сигнал проверить, где лежат резервные копии и сколько займёт переезд к другому провайдеру, — такие вопросы решаются на уровне DevOps-архитектуры и процессов резервного копирования.

Второй урок — про данные клиентов. Утечка, которую раскрыли JR East и JR Kyushu, произошла у подрядчика, а уведомлять пользователей и отвечать перед регулятором пришлось им самим. Риски хостинга стоит закладывать в модель угроз ещё до выбора провайдера — с этим помогает аудит информационной безопасности.

Что произошло в облаке IDCF

По данным IDC Frontier, которые пересказывают Impress Watch и Mynavi TECH+, несанкционированный доступ начался около 3:40 утра по японскому времени 7 октября. Атака пришлась на регион East Japan Region 1, который обслуживается из дата-центра в Сиракаве (префектура Фукусима). Провайдер отключил регион от сети и остановил системы, чтобы не допустить дальнейшего ущерба и вывода данных, и подтвердил, что это атака шифровальщика со стороны третьих лиц.

• 7 октября — второй отчёт IDC Frontier: причиной сбоя названа ransomware-атака, затронуты 495 компаний и органов местного самоуправления.
• 8 октября — третий отчёт: данные клиентов в четырёх зонах региона (tesla, henry, pascal и joule) извлечь или восстановить, по оценке провайдера, будет затруднительно.
• 9 октября — клиенты IDCF начали раскрывать возможные утечки персональных данных своих пользователей.

Название группировки и способ проникновения на момент публикации не раскрыты. Срок полного восстановления IDC Frontier не называет.

Кого задела атака: JR East, JR Kyushu и сервисы на IDCF

Самые крупные последствия раскрыли железнодорожные компании. JR East сообщила, что могли быть скомпрометированы около 6,09 млн клиентских аккаунтов. В эту цифру входят пользователи сервиса бронирования Eki-net (около 1,67 млн адресов электронной почты), клуба Otona no Kyujitsu (около 390 тыс. записей — e-mail, номер участника, срок действия карты и дата рождения) и карточного сервиса VIEW's NET. JR Kyushu оценила возможную утечку примерно в 1,3 млн адресов электронной почты участников веб-программы.

Пострадали и B2B-сервисы, работавшие на IDCF. Six Apart лишилась 31 сервера Movable Type Cloud Edition — админки и сайты клиентов были недоступны, пока компания не перенесла их на другое облако из резервных копий. У Greenwich частично остановились сервисы управления остатками и ценами для интернет-магазинов.

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

Почему «восстановить не получится» — главный урок

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

Остальная инфраструктура провайдера, по его данным, не затронута: в зонах radian и newton того же региона, а также в East Japan Region 2–3 и West Japan Region 1 следов вторжения не нашли. Но и там на время проверки отключили консоли управления — клиенты не могли даже перенастроить свои ресурсы. Модель «облако само обеспечит отказоустойчивость» в этом инциденте не сработала.

Что сделать командам, которые держат продакшн в облаке

1. Правило 3-2-1 с копией вне провайдера. Хотя бы одна резервная копия должна лежать у другого облака или в офлайн-хранилище, с отдельными учётными данными.
2. Неизменяемые бэкапы. Включите object lock или WORM-хранилище, чтобы копии нельзя было удалить или зашифровать даже с правами администратора.
3. Проверка восстановления, а не наличия копий. Раз в квартал поднимайте сервис из бэкапа на чистой инфраструктуре и замеряйте реальные RTO и RPO.
4. Инфраструктура как код. Terraform или Ansible позволяют развернуть окружение у другого провайдера за часы, как это сделала Six Apart, а не за недели.
5. План на случай недоступной консоли. Держите контакты провайдера, DNS у независимого регистратора и сценарий переключения трафика, который не зависит от панели управления облаком.
6. Готовые шаблоны уведомлений. Если у подрядчика утекли персональные данные ваших пользователей, по 152-ФЗ оператором остаётесь вы — сроки уведомления Роскомнадзора короткие.

Часто задаваемые вопросы

Затронуты ли российские компании? IDCF Cloud — японский провайдер, и все раскрытые клиенты — японские компании и муниципалитеты. Но сценарий универсален: так же может пострадать любое облако или хостинг.

Утекли ли платёжные данные? По раскрытиям JR East, в составе возможной утечки — e-mail, номера участников, сроки действия карт и даты рождения. О полных номерах банковских карт компании не сообщали.

Можно ли полагаться на снапшоты облака как на бэкап? Нет. Снапшот в той же зоне и под теми же учётными данными — это защита от ошибки администратора, а не от шифровальщика или отказа провайдера.

Источники

Impress Watch — IDCFクラウドの障害は「ランサムウェア攻撃」が原因 495の企業・自治体に影響, 8 октября 2026 года.

Mynavi TECH+ — IDCフロンティアにランサムウェア攻撃、IDCFクラウドで障害, 8 октября 2026 года.

Nippon.com / Jiji Press — More Japanese Firms Hit by Large-Scale Data Breaches, 9 октября 2026 года.

The Japan Times — More Japanese firms hit by large-scale data breaches, 10 октября 2026 года.