облако
13 статей с этим тегом
Утечка персональных данных Suntory Group (около 90 000 сотрудников и сотрудников партнеров, а также другие группы): имена и адреса электронной почты утекли после несанкционированного доступа к внешнему облачному сервису, и что делать соискателям и клиентам
Suntory Group 2 ноября 2026 года объявила, что подтвердила несанкционированный доступ третьего лица к внешнему облачному сервису, которым пользуется группа, и что часть скачанных третьим лицом файлов содержала персональные данные. Компания обнаружила аномалии 28 октября и заблокировала доступ, а 29 октября подтвердила, что в файлах есть персональные данные. Персональные данные, утечка которых подтверждена к 1 ноября, делятся на семь групп: имена и адреса электронной почты около 90 000 сотрудников группы и сотрудников компаний-партнеров; адреса электронной почты 7 323 человек, зарегистрированных на конец 2023 года в программе знакомства с деятельностью компании Mar de Shine; регистрационные данные личного кабинета (My Page) соискателей и др. (имя, адрес электронной почты, номер телефона и т. д.) 7 173 соискателей на открытый отбор бизнес-направления в рамках найма выпускников 2026 года Suntory Holdings; имена и номера телефонов 1 097 человек, сохраненные в двух служебных мобильных телефонах Suntory Beverage Solution; имена, адреса электронной почты и номера телефонов 324 сотрудников Monte Bussan и сотрудников компаний-партнеров; имена и сведения о месте доставки 96 клиентов доставки Izutsu Maisen и сотрудников, выполнявших доставку; а также имена и должности 25 сотрудников деловых партнеров Suntory. Кредитные карты и другие платежные данные не входят. На момент уведомления злоупотреблений не подтверждено. Компания сообщает, что связывается с затронутыми людьми индивидуально. Наш вывод: не открывайте ссылки в сообщениях от имени Suntory или компании группы об отборе, предложениях о работе, доставке или деловых вопросах; проверяйте через официальный сайт, который вы открыли сами, или через контакты на странице уведомления.
Инцидент безопасности Trigger.dev (ноябрь 2026): корневые ключи API и переменные окружения затронуты у 0,66 % клиентов, перегенерируйте ключи и смените секреты
Trigger.dev, платформа для запуска фоновых задач и ИИ-агентов, раскрыла инцидент безопасности 1 ноября 2026 года и опубликовала дополнительный отчёт 6 ноября. Компания сообщает, что оповещения инфраструктуры 1 ноября указали на аномальную активность, она сочла её вредоносной и заблокировала злоумышленника. Инцидент затронул 0,66 % всех клиентов. Злоумышленник получил корневые ключи API для некоторых клиентских сред; корневой ключ даёт полный доступ к настройкам среды, включая её переменные окружения. В некоторых средах он также запрашивал списки последних запусков, развёртываний и расписаний, и в ответ получал идентификаторы, названия задач, ключи идемпотентности запусков, статус запусков, теги, метаданные развёртываний и ошибки, внешние идентификаторы расписаний и метаданные запусков. Компания не нашла доказательств доступа к другим данным клиентов, другим сервисам, собственным производственным базам данных или аккаунтам клиентов в панели управления. Вектор атаки она не раскрывает, чтобы защитить расследование и клиентов. Затронутым клиентам писали по электронной почте (1 и 2 ноября) и показывали баннер в панели управления (время не указано), а потенциально затронутые ключи API были отозваны. Затронутым клиентам нужно перегенерировать ключи API и сменить учётные данные в затронутых средах, например пароли баз данных и сторонние ключи API, отозвав старые у поставщика. Компания заявляет, что клиенты, не получившие уведомления о воздействии, не затронуты, секреты подписи вебхуков не раскрыты, а самостоятельно размещённые развёртывания не затронуты. Вывод этого сайта: сначала проверьте почту и баннер в панели управления, а при затронутости перегенерируйте ключи и смените учётные данные, как просит компания.
Взлом производственной среды Chainstack (платформа блокчейн-узлов и API): что разработчикам и операторам dApp делать с данными аккаунтов и учетными данными узлов
В уведомлении от 3 ноября 2026 года Chainstack сообщает, что внешний злоумышленник получил доступ к части ее инфраструктуры через сторонний компонент: к среде разработки 26 октября и к части производственной среды 29 октября; доступ был обнаружен и перекрыт 31 октября, расследование завершено 2 ноября. Информация, которая могла быть раскрыта из базы данных аккаунтов клиентов, — названия организаций, имена владельцев аккаунтов, адреса электронной почты участников организаций и хеши паролей. Был также получен доступ к системам, где хранятся учетные данные узлов; доказательств того, что их читали, у компании нет, но она считает их раскрытыми. Она говорит, что не хранит данные платежных средств, что узлы, консоль и API не изменялись и что сервис продолжал работать. Число клиентов не указано. Вывод этого сайта: пользователям следует сменить пароль, заменить учетные данные узлов и API-ключи платформы и заменить эндпоинты, встроенные в приложения, CI и фронтенд.
Несанкционированный доступ и утечка данных у PingCAP (TiDB Cloud) (до примерно 50 000 записей в Японии): что администраторам организаций TiDB Cloud делать с данными аккаунтов, историей SQL-редактора и тикетами поддержки
PingCAP сообщает, что в период с 9 сентября по 7 октября 2026 года (по времени США) третья сторона с помощью украденных учётных данных проникла во внутренние системы и скопировала данные, и что, как выяснилось, утекло до примерно 50 000 записей персональных данных в Японии (японское уведомление). Категории, которые компания подтвердила как затронутые (различаются у разных клиентов): данные аккаунтов TiDB Cloud (имена пользователей, адреса электронной почты, связи организаций и проектов, история выполнения и ошибки SQL-редактора, а также информация об обращениях, то есть тикеты поддержки), деловая и платёжная информация (имена, почта, названия компаний, телефоны, заказы, условия оплаты, настройки выставления счетов) и зашифрованная часть Public Key API-ключей TiDB Cloud. Компания говорит, что утечка данных кредитных карт и несанкционированный доступ к самому TiDB Cloud не подтверждены, а Private Key не были раскрыты. Единица счёта (люди или записи) не указана. В английском уведомлении компании также сказано, что исходный код был получен. Вывод этого сайта: администраторам организаций TiDB Cloud стоит заменить API-ключи, проверить журналы доступа, участников и роли и сменить учётные данные, которые могли быть вставлены в SQL-редактор или тикет поддержки.
Несанкционированный доступ к сайту вакансий MyBRANDS и возможная утечка персональных данных (до примерно 135 000 аккаунтов): что делать соискателям и представителям работодателей, чьи имена, контакты и трудовая история под угрозой
iDA Co., Ltd. (Япония) объявила 30 октября 2026 года, что в результате несанкционированного доступа третьего лица к серверной среде сайта вакансий MyBRANDS информация зарегистрированных соискателей и представителей работодателей могла утечь за пределы компании. По её словам, облачный ключ доступа, которым пользовался подрядчик, был использован третьим лицом в период с 21 по 22 октября, а 26 октября компания узнала о записях об отправке данных наружу из копии базы данных. Что именно содержали отправленные данные, подтвердить не удалось, поэтому компания оповещает исходя из того, что затронута вся информация, которая у неё хранилась. Охват на 30 октября составляет до примерно 135 000 аккаунтов, включая людей, покинувших сервис. Это имя, адрес электронной почты, номер телефона, профиль (например, трудовая история) и пароль для входа (хранился в преобразованном виде); состав зависит от регистрации. Данные кредитных карт и банковских счетов компания не хранила, поэтому они не затронуты. Имя, адрес электронной почты, номер телефона и адрес хранились в зашифрованном виде, но ключ для расшифровки, по её словам, мог быть похищен тоже. Злоупотреблений (вторичного ущерба) пока не подтверждено. Вывод этого сайта: смените пароль на всех сервисах, где вы использовали тот же пароль, что и на MyBRANDS (представителям работодателей также во внутренних системах), а сообщения от якобы рекрутера или скаута проверяйте по официальному каналу, а не по ссылкам или номерам из них.
Инцидент безопасности Northflank (октябрь 2026): сохранённые переменные окружения считаются расшифрованными, сообщается о неправомерном использовании ключей API ИИ
30 октября 2026 года (UTC) облачная платформа развёртывания Northflank разместила на странице статуса сообщение об инциденте безопасности. Предупреждение об угрозе от поставщика средств безопасности поступило в 11:43 UTC; компания развернула патчи начиная с 12:02 UTC, в 13:40 UTC попросила клиентов сменить переменные окружения, а в 13:58 UTC — считать расшифрованными все переменные окружения. К 15:12 UTC на странице статуса уже было отмечено, что несколько пользователей сообщают об использовании их ключей ИИ, а в 23:38 UTC компания написала, что пользователи сообщили о несанкционированном использовании ключей API ИИ, хранящихся на платформе. 31 октября она включила журналы аудита для всех клиентов и по одному типу выпустила смену секретов для аддонов. В обновлении от 2 ноября (11:09 UTC, статус Monitoring) компания сообщила, что, по её оценке, остановила атаку в течение часа после первого предупреждения, что работающие нагрузки не затронуты и признаков доступа к нагрузкам или их данным она не видела, а атака, судя по всему, была направлена на секреты в плоскости управления. Независимые судебные аудиторы проводят проверку, компания отозвала токены доступа, сессии, интеграции с VCS и межаккаунтные роли IAM (поэтому пользователям нужно войти снова и заново подключить интеграции) и пообещала опубликовать анализ первопричины, когда выводы будут подтверждены. В обновлении от 6 ноября (10:09 UTC) компания сообщила, что первая известная расшифровка секретов произошла между 02:39 и 03:08 UTC 30 октября, до первого предупреждения в 11:43 UTC; что эксплойт был закрыт в течение 60 минут после уведомления, а клиентов уведомили в течение двух часов; что доказательств доступа к рабочим нагрузкам клиентов или их данным она не нашла; и что она работала с вышестоящими поставщиками, чтобы по возможности отозвать учётные данные. Судебная проверка продолжается. Число затронутых клиентов, способ проникновения злоумышленника и то, какие поставщики ИИ были затронуты, не раскрыты. Вывод этого сайта: отзовите все секреты, которые вы хранили в Northflank, у сервиса, который их выдал, затем проверьте использование и счета каждого поставщика ИИ и установите лимиты расходов.
Инцидент безопасности Zeabur (октябрь 2026, прочитано 3,22 млн переменных окружения): какие секреты заменить и что делать пользователям
19 октября 2026 года платформа для развёртывания приложений Zeabur опубликовала предварительный отчёт об инциденте безопасности 14–15 октября (UTC). По словам компании, атакующий с помощью утёкших внутренних учётных данных Zeabur проник в общий кластер, часть выделенных серверов (Dedicated Servers) и внутренние системы, а затем, с 16:10 до 16:47 UTC 15 октября, прочитал базу данных платформы. Компания подтвердила, что прочитаны 3 218 965 записей переменных окружения (имена и значения) и данные 321 810 аккаунтов (электронная почта, имя пользователя, номер телефона и другое), а также 566 API-ключей zSend, которые она отозвала. Компания заявляет, что первопричина лежит на Zeabur: долгоживущие административные учётные данные хранились в открытом виде и могли использоваться из публичного интернета. Она просит всех пользователей заменить все пароли и ключи, хранящиеся в Zeabur, даже если они уже заменили их после отдельного инцидента в августе. 17 октября Zeabur объявила, что прекратит работу 31 декабря 2026 года, а 22 октября установила 30 ноября 2026 года крайним сроком подачи требований о возмещении убытков от инцидента. Мнение этого сайта: считайте, что каждый секрет, который вы когда-либо помещали в переменную окружения Zeabur, известен кому-то ещё, сначала отзовите его у выпустившего сервиса и проверьте счета и журналы начиная с 14 октября.
Несанкционированный доступ к данным Nikkei (около 1,83 млн записей): имена, адреса электронной почты и другие данные утекли примерно по 150 000 записям — что делать пользователям
16 октября 2026 года японское газетное издательство Nikkei Inc. объявило, что к облачному сервису, который она использует для разработки систем, был получен несанкционированный доступ и что по состоянию на 16-е число утекло около 1,83 млн записей персональных данных. Около 150 000 из них содержали хотя бы одно из следующего: имя, адрес электронной почты, почтовый адрес, номер телефона или дату рождения; примерно в 120 000 из них был адрес электронной почты. Остальные примерно 1,68 млн состояли только из идентификаторов, которые сами по себе не позволяют определить человека. Данных кредитных карт среди них не было. По данным компании, учётные данные для доступа к облачному сервису были похищены неизвестным способом, а несанкционированный доступ происходил с ночи до утра 7 октября. Компания отключила использованные учётные данные и 11 октября сообщила об инциденте в Комиссию по защите персональной информации Японии. По состоянию на 16-е число вторичный ущерб, например неправомерное использование данных, а также сбои систем и подмена данных не подтверждены. Компания заявляет, что лично уведомит тех, чья утечка данных будет подтверждена. Компания группы Nikkei National Geographic 22 октября сообщила, что среди затронутых есть сведения о части пользователей её сервисов. Пользователи каких сервисов затронуты, сколько записей по каждому виду данных и как были похищены учётные данные, не раскрыто. Мнение этого сайта: не переходите по ссылкам и не звоните по номерам из писем и звонков от имени Nikkei; проверяйте информацию на официальном сайте.
Возможная утечка переменных окружения Railway (октябрь 2026, до 1,85% рабочих пространств): какие секреты заменить и что делать пользователям
21 октября 2026 года (UTC) Railway сообщила, что обнаружила аномальную активность в системах, где хранятся переменные окружения клиентов, и что неавторизованная третья сторона могла получить доступ к зашифрованным переменным окружения и для части из них получить расшифрованное содержимое. Согласно предварительному отчёту от 22 октября (по данным страницы статуса, опубликован в 16:38 UTC 23 октября), атака длилась с 13:58 UTC 20 октября до 03:32 UTC 22 октября. Она началась с попыток повышения привилегий в инфраструктуре сборки; 21 октября были использованы учётные данные среды CI, и часть зашифрованных переменных окружения была расшифрована. Не более 1,85% всех рабочих пространств (около 100 000 рабочих пространств, по данным компании) имели переменные окружения, часть из которых могла быть скомпрометирована. Компания заявляет, что к учётным записям пользователей Railway доступа не было, и до выхода итогового отчёта не исключает доступ к исходному коду. По-видимому, атакующий искал API-ключи поставщиков ИИ. Railway рекомендует всем пользователям заменить секреты, сохранённые до 21 октября, закрыть публичный сетевой доступ к базам данных и проверить журналы аудита GitHub и реестров (например, Docker Hub). Вывод сайта: даже если с вами не связывались, считайте секреты, хранившиеся на Railway, раскрытыми, перевыпустите их у источника и выполните повторное развёртывание до отзыва старых значений.
Что такое теневой ИИ (shadow AI)? Риски использования ИИ, которое не видит компания, и что делать организациям и сотрудникам
Теневой ИИ — это использование сотрудниками для работы ИИ-инструментов, которые компания не одобрила или не контролирует (чат-боты, ИИ-расширения браузера, помощники для кода, ИИ для протоколов встреч, ИИ-агенты, подключённые к рабочим аккаунтам). Это ИИ-разновидность теневых ИТ. Главные риски: введённые конфиденциальные или персональные данные могут храниться у провайдера и, в зависимости от тарифа и настроек, использоваться для обучения (условия для частных лиц и для бизнеса различаются); OAuth-разрешения и API-ключи дают сторонним инструментам доступ к почте и дискам; ошибки в ответах и проблемы с лицензиями; обязательства по законам о персональных данных и аудиту. Один только запрет уводит использование из поля зрения, поэтому предоставьте одобренный инструмент на бизнес-условиях без обучения на вводе, короткое правило о том, какие данные можно вводить, SSO и админ-контроль, регулярную проверку OAuth-разрешений и расширений и канал, куда можно сначала спросить.
Захват поддомена (висящая DNS-запись): как забытая запись DNS позволяет атакующим использовать ваш домен
Если удалить облачный ресурс, но не удалить запись DNS, остаётся висящая запись: любой может занять поддомен, создав ресурс с тем же FQDN. Ваши серверы не затронуты, а законный поддомен показывает содержимое атакующего. Ущерб не только внешний: приложения часто открывают сессионные cookie для всех поддоменов, поэтому захваченный поддомен может их прочитать. А документация прямо опровергает мнение, что сертификат защищает. Решение — встроить порядок удаления в процедуры и инструменты, а не полагаться на память.
Что такое SSRF (Server-Side Request Forgery)
SSRF злоупотребляет URL из внешнего ввода, чтобы заставить сервер обратиться к внутренним ресурсам (внутренние IP, облачные метаданные). Если вы загружаете URL, нужен allowlist назначений, блокировка внутренних целей и защита от обхода через редиректы/DNS-rebinding. Это стало причиной утечки Capital One.
Утечка Capital One (2019) — как один SSRF привёл к компрометации 100M+ записей и как защититься
Один SSRF достиг endpoint метаданных → переизбыточные временные учётные данные IAM → массовое копирование S3, утечка ~106 млн записей. Каждый шаг можно было остановить. В вашей среде: IMDSv2, минимальные привилегии IAM и список разрешённых адресов для исходящих запросов.