Hacker News Digest

Злоумышленники заявили о краже 10,6 ТБ данных из облачной платформы TiDB Cloud компании PingCAP — это 4 901 203 файла, включая полный контрольный слой продакшена. По их словам, выгрузка шла почти два месяца и оставалась незамеченной: 88 последовательных экспортов каждые шесть часов с 8 по 30 сентября, последний — в 06:02 UTC 30 сентября. Репликацию собственной базы данных TiDB Cloud они настроили через учётные данные, найденные в репозиториях самой компании: ключи сервисного аккаунта GCP и субъект Azure.

Среди похищенного — 180 046 организаций-арендаторов, 292 276 записей пользователей, 403 262 уникальных адреса электронной почты, 115 308 пар ключей API в открытом виде (42 612 активных), 20 645 574 SQL-запроса клиентов из редактора и Chat2Query, 102 003 766 подключений к шлюзу, 5 036 738 IP-адресов серверов заказчиков, 377 446 задач Jira, 433 928 контактов CRM, 92 ГБ данных о затратах AWS с метками арендаторов и 413 приватных репозиториев с исходным кодом. Также упоминаются 1 809 внешних конечных точек баз данных с учётными записями root и admin на хостах MySQL/Aurora заказчиков и 290 идентификаторов аккаунтов AWS.

Первый этап публикации — около 200 ГБ, доступен через торрент-файл размером 128,3 ГиБ. Атакующие подчёркивают, что PingCAP, будучи облачным провайдером, не заметил массовой выгрузки из AWS, GCP, Jira и Azure, хотя компания зарабатывает на обещании безопасности мультитенантной платформы.

Обсуждение указывает на катастрофический уровень операционной безопасности PingCAP: инженеры хранили production-учетные данные клиентов и ключи сервисных аккаунтов GCP и Azure в тикетах Jira и репозиториях. Это позволило атакующим настроить автоматическую репликацию данных в течение месяца. Сообщество ставит под сомнение заявления компании об отсутствии воздействия на данные, так как у хакеров есть полные дампы контрольного слоя. В споре о природе утечки @gregwebs считает, что утекли в основном метаданные, однако другие указывают на наличие SQL-логов с реальными данными клиентов. Проведенный ранее аудит NCC Group выявил разрыв между анализом кода и реальной безопасностью процессов. @kobieps отмечает необходимость перестройки индустрии пентестов, так как даже enterprise-grade вендоры допускают подобные провалы. @ozgrakkurt полагает, что безопасность была бы выше при использовании консервативной модели разрешений (как в Deno), где всё закрыто по умолчанию. Также пользователи иронизировали по поводу Rust, но @boorbat уточнил, что TiDB на 95% написан на Go.

OpenAI и Google Cloud заключили партнёрство: передовые модели OpenAI и агентные сценарии Codex появятся в Model Garden — каталоге моделей Google Cloud. Клиенты получат нативный доступ к этим моделям для сложных агентных задач, опираясь на управление данными и высокопроизводительную инфраструктуру Google Cloud. Покупка будет идти через Google Cloud Marketplace, а компании с обязательствами по расходам на GCP смогут зачесть эти траты в счёт своих обязательств. Общедоступность запланирована на ближайшие недели.

Интеграция особенно важна для регулируемых отраслей: модели OpenAI соединят со встроенными средствами контроля доступа и централизованным управлением данными Google Cloud. Вскоре модели появятся и в Google Antigravity, и в Gemini Agent — это даст заказчикам гибкость выбора модели под конкретную задачу. Президент и сооснователь OpenAI Грег Брокман назвал шаг важным для развития агентной экосистемы, а глава Google Cloud Томас Куриан подчеркнул ставку на широкий выбор моделей ради качества и снижения затрат. При этом Microsoft остаётся основным облачным партнёром OpenAI.

Доступ к моделям OpenAI через Google Cloud (GCP) базируется на юридических гарантиях и контрактах по конфиденциальности, а не на технических мерах. Технически чтение моделей затруднено, так как зашифрованные веса расшифровываются только внутри чипов Nvidia. OpenAI использует GCP для обслуживания корпоративных клиентов, требующих гарантий сохранения данных и уже работающих в экосистемах AWS или GCP, дополняя основного партнера Azure. Доходы от продажи моделей через Marketplace Google Cloud признаются по факту потребления. Внутри Google ведутся споры: одни считают, что Gemini страдает от бюрократии и нехватки средств, другие — что хостинг сторонних моделей приносит значительный доход для поддержки Gemini. Упоминание Microsoft как «первичного облачного партнера» OpenAI является формальностью, продиктованной контрактом. Компаниям, планирующим миграцию инференса в GCP, рекомендуется уточнить условия доступа к логам сессий для соблюдения требований к конфиденциальности.

Сбой питания в зоне GCP europe-west2-b вызвал перебои в работе банков Великобритании. Это спровоцировало критику зависимости компаний от облачных провайдеров и отсутствия реальной отказоустойчивости. В ходе обсуждения возникли следующие тезисы: — @nickcw удивлен отсутствием multi-AZ архитектуры, однако @Betelbuddy отмечает, что зоны Google могут фактически находиться в одном дата-центре. — Наличие нескольких зон не гарантирует доступность, так как компании редко тестируют симуляцию отказов и анализ вторичных эффектов (@robinson-wall). — Скрытые межзональные или межрегиональные зависимости могут превратить локальную проблему в глобальный сбой (@bsuvc). — Неравномерное распределение оборудования в GCP заставляет разработчиков выбирать между доступностью в нескольких зонах и требованиями к железу (@td521534f12). — Юридические ограничения по локализации данных вынуждают концентрировать инфраструктуру в ограниченном числе зон, что повышает риски. Переход в облако, обещавший надежность, создал структурные уязвимости, при которых один сбой парализует множество финансовых институтов. Также @physhster и @nickcw раскритиковали Google за использование тихоокеанского времени (PDT) в статусах европейских инцидентов.

GitHub сообщает о сбоях в операциях Git, влияющих на работу сервиса. Пользователи могут столкнуться с проблемами при выполнении Git-команд, хотя другие функции платформы могут оставаться доступными. Компания рекомендует следить за официальными каналами для получения актуальной информации о статусе восстановления.

Для отслеживания инцидента GitHub предлагает несколько способов уведомлений: email, SMS, интеграция со Slack и вебхуки. Пользователи могут настроить подписку на получение оповещений о создании, обновлении или решении инцидентов. Для подтверждения подписки требуется ввод OTP (одноразового пароля), а при выборе SMS-уведомлений доступен выбор страны и ввод телефонного номера.

• Массовые жалобы на сбой GitHub: проблемы с push/pull, Actions, raw.githubusercontent.com и SSH-аутентификацией.
• Рост обеспокоенности надёжностью облачных сервисов (AWS, GCP, Azure, GitHub), сбои происходят чаще.
• Критика централизации и приоритетов компаний: упрёки в пренебрежении инфраструктурой ради AI/прибыли.
• Поиск решений: рекомендации по самохостингу (Forgejo, Gitea), локальным кешированию git и отказу от полной зависимости от SaaS.
• Спекуляции о причинах: влияние AI на инфраструктуру, "vibe coding", общая хрупкость централизованных систем.

Автор сократил свои расходы на облачные услуги в 10 раз, переведя все проекты с AWS на самостоятельное хостинг, при этом улучшив производительность в 2 раза. Его месячный счет AWS снизился с $1,400 до менее $120, а инфраструктура стала мощнее. Автор утверждает, что страх перед управлением серверами обходится компаниям в 10 раз дороже, чем необходимо.

Многие разработчики в индустрии облаков заинтересованы в сохранении компаний на облачных платформах, так как их зарплаты зависят от сложности инфраструктуры. Облачные инженеры и DevOps специалисты не чувствуют финансовой боли от переплат, так как тратят чужие деньги, и заинтересованы в поддержании vendor lock-in.

Перейдя на Hetzner, автор получил доступ к серверам с 80 ядрами менее чем за $190 в месяц, в то время как аналогичные экземпляры в AWS стоят $2,500-$3,500 (в 13-18 раз дороже). Даже с резервированием экземпляров AWS остается в 7 раз дороже. Для небольших проектов доступны VPS с 8 ядрами и 32 ГБ ОЗУ за $50 в месяц.

• Обсуждение в основном свелось к тому, что для большинства проектов хостинг в облаке (AWS, GCP, Azure) в 2024 году оказывается дороже, чем аренда bare-metal в Hetzner/OVH, и что это не всегда оправдано.
• Участники споров подчеркнули, что «облако» всё ещё полезно для MVP, стартапов и сценариев с непредсказуемым трафиком, но при этом критикуют его стоимость для устойчивых рабочих нагрузок.
• Несколько человек упомянули, что большие компании могут позволить себе облако, потому что у них есть команды и бюджет на инфраструктуру и DevOps, тогда как мелкий бизнес и индивидуальные разработчики вынуждены искать более дешёвые решения.
• Также было отмечено, что важно различать «облако» как способ разработки (CI/CD, managed services) и как способ хостинга (IaaS), и что первое может быть дешевле, чем второе.

PlanetScale запустил общедоступную версию своей управляемой базы данных для Postgres, завершив этап приватного тестирования. Сервис предлагает миграцию с других провайдеров Postgres через гайды и поддержку sales-команды для сложных случаев. Компания уже пять лет развивает Vitess для MySQL, а теперь переносит этот опыт на Postgres, объединяя производительность своей платформы Metal с гибкостью Postgres.

Сотни компаний, включая Convex и Supermemory, уже используют PlanetScale для Postgres в продакшене, отмечая улучшение скорости и масштабируемости. Анонсирован также будущий инструмент Neki — решение для шардинга Postgres, построенное на принципах Vitess, но спроектированное с нуля для специфики Postgres; его открытую версию планируют выпустить позже.

• Успешная миграция на PlanetScale Postgres с улучшением производительности запросов и оперативной поддержкой команды, включая помощь в решении возникших проблем.
• Критика недостаточной ясности описания продукта и цен на сайте для новых пользователей, а также отсутствия бесплатного тарифа для тестирования.
• Вопросы о технических деталях: масштабировании записи (горизонтальное шардирование через Neki), использовании эфемерных дисков NVMe в GCP, поддержке расширений Postgres и сравнении с конкурентами (Aurora, Supabase).
• Положительные отзывы от пользователей бета-тестирования о высокой производительности и надежности продукта в production-среде.
• Объяснения от команды PlanetScale о архитектуре (репликация для надежности вместо сетевых дисков) и планах по развитию (горизонтальное масштабирование через Neki).

Rug-pull и вилки: кто кого в OSS

• В облаке всё решают гиганты (AWS, GCP, Azure); разработчики и пользователи — без прав.
• Компания-владелец проекта может «рвануть коврик»: сменить лицензию на закрытую, чтобы загнать облачных конкурентов.
• Пример: Elastic → SSPL, MongoDB → SSPL, Sentry → новая лицензия.
• Ответ — вилка (fork), но она требует людей и денег; без спонсора умирает.
• AWS форкнул Elasticsearch → OpenSearch: набрал контрибьюторов с нуля, теперь живёт.
• Puppet ушёл в Perforce и закрыл код → родилась OpenVox.
• Вывод: однокомпаночные проекты рискованны; выбирайте те, где власть распределена, или сразу готовьтесь вилковать.

• CLA = право перелицензировать → «rug pull» возможен; DCO такого не даёт.
• Elasticsearch, Redis, Mongo и др. перелицензировались не от банкротства, а чтобы ограничить конкурентов и поднять доход.
• Пользователи чувствуют «предательство»: проект начинали под FOSS-лицензией, привлекли вклад и клиентов, потом закрыли код.
• Форки (OpenSearch, Valkey) спасают, но требуют новой инфраструктуры и сообщества; большинство просто делают «снапшот» и уходят.
• Проблема устойчивости: без денег проект умрёт, но нынешняя модель дарения дарит прибыль крупным облакам, а не разработчикам.