Утечка данных Nikkei затронула 1,83 млн записей после того, как злоумышленники вошли в систему разработки японской медиагруппы с украденными учётными данными. Для бизнеса это очередное напоминание: облачная инфраструктура и dev-среда не становятся безопаснее только потому, что доступ к ним защищён корпоративным логином.
Инцидент стал третьим раскрытым случаем кибербезопасности у Nikkei примерно за месяц, сообщает BleepingComputer. Компания владеет Financial Times и является крупнейшей в Японии группой деловых медиа. На этот раз атакующие получили доступ к облачным данным через development-систему внутри сети компании ранним утром 7 октября.
Nikkei сообщила, что в массиве было 1,83 млн записей. Однако персональные данные содержались не во всех: около 150 тыс. записей включали хотя бы один идентификатор — полное имя, адрес электронной почты, почтовый адрес, номер телефона или дату рождения. В 120 тыс. записей присутствовали email-адреса. Остальные 1,68 млн записей, по версии компании, не содержали данных, позволяющих идентифицировать человека. Информации о банковских картах среди скомпрометированных данных не было.
Скомпрометированные учётные данные остаются одним из самых неприятных сценариев для защитников: формально пользователь проходит привычную аутентификацию, а дальнейшие действия могут выглядеть как работа сотрудника. В такой ситуации периметровая защита и антивирусы мало помогают, если у компании нет строгого разграничения прав, многофакторной аутентификации, контроля аномалий и отдельных правил доступа к средам разработки.
После обнаружения инцидента Nikkei отозвала использованные злоумышленниками учётные данные и 11 октября уведомила японскую Комиссию по защите персональной информации. Компания продолжает оценивать масштаб последствий. По состоянию на 16 октября она не обнаружила признаков публикации или злоупотребления полученной информацией, а также не зафиксировала вмешательства в системы, подмены данных или перебоев в работе сервисов. Людей, чьи данные могли попасть в доступный атакующим набор, обещают уведомить индивидуально.
Проблема в том, что это не единичный сбой в спокойной инфраструктуре. Ранее в октябре Nikkei раскрыла инцидент, произошедший в конце июля: злоумышленники взломали Google Workspace-аккаунт сотрудника и получили доступ к персональным данным работников и деловых партнёров. В сентябре компания сообщала о захвате другого корпоративного аккаунта — уже в Microsoft 365. Его использовали для рассылки целевых фишинговых писем сотрудникам.
Три эпизода не обязательно означают единую кампанию или одного и того же атакующего: Nikkei этого не утверждает. Но последовательность выглядит тревожно. В июле был доступ к данным через Google Workspace, в сентябре — фишинг из Microsoft 365, в октябре — вход в систему разработки по похищенным реквизитам. Для ИБ-команд это знакомая цепочка: компрометация идентичности даёт точку входа, а разнородные SaaS-сервисы и внутренние среды усложняют расследование и отзыв доступа.
Для российских разработчиков и руководителей IT-подразделений утечка данных Nikkei важна не масштабом медийного бренда, а типом провала. Dev-среды часто получают расширенные права, доступ к тестовым копиям баз, логам, облачным секретам и интеграциям. Если туда попадают реальные клиентские или кадровые данные, «тестовый» контур превращается в полноценную цель. Минимальный набор гигиены здесь скучен, но работает: отдельные аккаунты для администрирования, MFA, короткоживущие токены, запрет общих учётных записей, инвентаризация секретов и регулярная проверка того, какие данные вообще лежат в non-production-средах.
Отдельный вопрос — насколько быстро организация замечает легитимный с виду вход. Отзыв украденного пароля уже после доступа ограничивает ущерб, но не отвечает на главный вопрос: какие действия выполнил аккаунт до блокировки. Логи аутентификации, выгрузки из облачного хранилища, доступ к системам разработки и почтовые правила стоит связывать в одну картину, а не расследовать по очереди после очередного уведомления об утечке.
История Nikkei показывает, что защита корпоративной идентичности перестала быть задачей исключительно для IAM-команды. Когда один и тот же бизнес за несколько месяцев сталкивается с захватом аккаунтов в Google Workspace, Microsoft 365 и доступом в dev-контур, проверять нужно не только конкретный пароль, но и всю модель доверия вокруг него. Иначе следующая утечка данных Nikkei или любой другой компании начнётся не с сложного эксплойта, а с обычного успешного входа.