Из статьи вы узнаете, как устроены такие сервисы, по каким критериям их сравнивать в 2026 году и чем корпоративный файлообменник отличается от объектного S3-хранилища. Внутри мы оставили два рейтинга со сводными таблицами, детальный разбор каждого решения с честными ограничениями, инструкция по тестированию перед внедрением и чек-лист выбора. Отдельно расскажем о методологии: шесть критериев, по которым мы оценивали сервисы, пригодятся вам и за пределами этого материала.

Статья будет полезна руководителям ИТ и ИБ, владельцам цифровых продуктов, командам эксплуатации и всем, кто отвечает за то, чтобы данные компании хранились централизованно, безопасно и с понятной экономикой. Начнем с основ, а затем перейдем к сравнению.

Принцип работы облачного хранилища для бизнеса

Облачные хранилища — это дисковое пространство в дата-центре провайдера, которое компания арендует и использует через интернет. Файлы физически лежат на оборудовании провайдера, обычно в нескольких копиях на разных серверах, а сотрудники и системы обращаются к ним через веб-интерфейс, приложение или API. Компании не нужно покупать серверы, следить за дисками и думать, что делать, когда место закончится: объем расширяется по мере роста данных.

Под общим названием скрываются два разных класса продуктов. Первый — всем известный корпоративный файлообменник с привычным пользовательским интерфейсом: с папками, правами доступа, ссылками для внешних пользователей и совместным редактированием документов. Это облачное хранение данных для бизнеса в его «человеческом» виде, то есть для ежедневной работы сотрудников.

Второй класс — объектные S3-хранилища. Это инфраструктурные сервисы: у них уже нет привычных папок и красивого интерфейса для бухгалтерии. Зато есть API, через который к данным обращаются приложения, системы резервного копирования и аналитики. Сюда складывают бэкапы, логи, медиафайлы, архивы документов и датасеты для машинного обучения.

Ошибка на этом этапе — самая дорогая. Если купить S3 для «диска бухгалтерии», сотрудники не смогут в нем работать. Если развернуть файлообменник под хранение терабайтов бэкапов, это выйдет неоправданно дорого. Именно поэтому мы выделяем два раздела в нашем сравнении, по одному на каждый класс решений.

Методология: как мы сравнивали облачные хранилища

Принцип составления обзора: в нем нет ранжирования от лучшего решения к худшему. Вместо этого мы взяли шесть критериев, которые чаще всего оказываются определяющими в реальных проектах внедрения, и по единой схеме разобрали каждое решение: и самые популярные облачные хранилища, и нишевые продукты. По какому-то критерию «победил» один продукт, по какому-то — другой. Ниже показываем, что именно мы оценивали и почему.

Тип хранилища и поддерживаемые сценарии

Первый вопрос, который нужно задать при выборе хранилища, не «какой сервис лучше», а «для какой задачи он предназначен». Облачные сервисы хранения затачиваются под разные сценарии: совместная работа с документами, обмен файлами с подрядчиками, резервное копирование, долгосрочный архив, раздача статики для сайтов и приложений. Мы смотрели, какие сценарии решение закрывает штатно, а какие — с оговорками и «костылями».

Функциональные возможности

Для файлообменников важны права доступа, версии файлов, внешние ссылки с паролем и сроком действия, интеграция с офисными пакетами. Иначе говоря, все, что превращает диск в сервисы для совместной работы. Для S3-решений — версионирование, классы хранения, политики жизненного цикла объектов, блокировка удаления, хостинг статических сайтов. Мы отмечали и то, чего в продукте нет: отсутствие какой-то функции тоже является характеристикой.

Безопасность и контроль данных

Здесь мы оценивали управление правами и ролями, шифрование при передаче и хранении, защиту от случайного или намеренного удаления, журналирование действий. Отдельный плюс — сертификация площадки: соответствие 152-ФЗ, ГОСТ Р 57580.1, PCI DSS. Для компаний из регулируемых отраслей этот пункт нередко становится первым фильтром, который отсеивает половину списка.

Прозрачность тарификации и предсказуемость расходов

Красивая цена за гигабайт — еще не вся экономика. На стоимость объектных S3-решений влияют исходящий трафик, количество запросов и класс хранения, у файлообменников — число пользователей и лицензии. Мы смотрели, легко ли заранее посчитать месячный бюджет и нет ли в тарифах пунктов, которые «выстреливают» после запуска. Конкретные цифры быстро устаревают, поэтому в таблицах указан условный уровень цен.

Интеграции и совместимость с инструментами и API

Хранилище не живет в вакууме: оно должно дружить с системами резервного копирования, CI/CD, службой каталога, офисным ПО. Для S3-сервисов ключевой вопрос — полнота совместимости с Amazon S3 API: от нее зависит, заработают ли привычные инструменты вроде rclone, Veeam или AWS CLI без доработок. Современные облачные сервисы обычно декларируют совместимость, но ее глубина у всех разная.

Размещение данных и соответствие требованиям законодательства

Если компания обрабатывает персональные данные, площадка хранения должна находиться в России — этого требует закон. Облачные платформы в России выигрывают у зарубежных еще и в практическом смысле: понятная юрисдикция, оплата в рублях по договору, поддержка на русском языке и отсутствие риска, что сервис перестанет работать из-за санкций или блокировок.

Рекомендации по выбору

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

Корпоративные облачные хранилища данных для бизнеса (файлообменники)

В этом разделе собраны облачные хранилища данных класса «корпоративный файлообменник» — сервисы, в которых сотрудники работают с файлами каждый день. Важно: решения здесь разного масштаба, от enterprise-платформ до простых дисков, и это сделано намеренно. Удобного варианта для всех нет и выбор зависит от сценариев, требований безопасности и размера компании.

У каждого класса есть сильные стороны и ограничения: отечественные платформы дают юридическую предсказуемость и соответствие 152-ФЗ, зарубежные — привычный интерфейс, но с ними связаны риски с оплатой и размещением данных. В топ лучших хранилищ мы включили решения, которые реально используются российским бизнесом в 2026 году. Cводная таблица ниже, а после нее сделаем детальный разбор.

Диск

Облачный диск из экосистемы Сбера. Его сильные стороны заключаются в простоте и низком пороге входа. Зарегистрироваться и начать загружать файлы можно за несколько минут, есть мобильные приложения и веб-версия, а данные хранятся на российских серверах.

Сценарии и функции

Хранение и синхронизация файлов, обмен ссылками, автозагрузка фото и документов. Для ИП и микробизнеса этого часто достаточно: договоры, сканы, рабочие материалы небольшой команды.

Ограничения

Корпоративного контура здесь по сути нет: отсутствуют централизованное администрирование пользователей уровня enterprise, гибкие ролевые модели, интеграция со службой каталога и журналирования для ИБ. Это продукт скорее для частных пользователей и совсем небольших команд, чем для компании со штатом и регламентами. Уровень цен низкий.

K2 Cloud Nextcloud

Nextcloud — платформа файлообмена с открытым исходным кодом, а K2 Cloud предоставляет ее как готовый управляемый сервис из своего облака. Это облачное хранилище для организации под ключ: провайдер отвечает за развертывание, обновления, доступность и поддержку. На решение K2 Cloud стоит обратить внимание, если файлообменник для вас — критичный сервис: когда пользователей сотни и тысячи, простои недопустимы, а требования ИБ прописаны в регламентах.

Сценарии и функции

Это классический файлообменник корпоративного уровня: личные и общие папки, обмен файлами с внешними пользователями по ссылкам или приглашению по почте, синхронизация с компьютерами и смартфонами. Платформа поддерживает совместное редактирование документов за счет интеграции с офисными пакетами, включая российские. В отказоустойчивой конфигурации сервис разворачивается в трех территориально распределенных дата-центрах, а файлы хранятся в объектном S3-хранилище в трех копиях, что гарантирует от потери данных. Версионирование и корзина защищают от человеческого фактора — случайно перезаписанный документ можно вернуть. Облачная платформа развернута на базе российских ЦОД и соответствует требованиям 152-ФЗ вплоть до УЗ-1, а также ГОСТ Р 57580.1-2017 и PCI DSS.

Основные сценарии — централизованное хранение файлов, совместная работа отделов и замена ушедших из России сервисов типа OneDrive или Dropbox без потери привычных функций.

Ограничения

Nextcloud — это экосистема плагинов, и часть возможностей требует настройки, поэтому самостоятельное развертывание без опытной команды может затянуться. Управляемый формат от K2 Cloud эту проблему снимает, но привязывает к провайдеру.

Модель тарификации зависит от объема данных и числа пользователей, поэтому для совсем небольших команд (до 10 человек) внедрение такой enterprise-системы может оказаться экономически избыточным.

Mega

Mega — единственное зарубежное решение в этом списке, но оно включено в обзор, потому что часть российских команд продолжает пользоваться такими известными облачными сервисами. Особенность Mega заключается в сквозном шифровании, при котором ключи хранятся только у пользователя: по заявлению провайдера, даже он сам не может прочитать содержимое файлов.

Сценарии и функции

Личные и командные диски, обмен ссылками, приложения под все платформы, бизнес-тарифы с администрированием пользователей и большими квотами. Функциональность для совместной работы скромнее, чем у корпоративных платформ: это в первую очередь защищенное хранение и обмен, а не среда для документооборота.

Ограничения

Серверы находятся за пределами России, поэтому для персональных данных сервис не подходит по 152-ФЗ. Оплата зарубежных подписок из РФ затруднена, поддержка ведется на английском языке, а юридические гарантии регулируются иностранным правом. Поэтому Mega имеет смысл рассматривать для узких задач с повышенными требованиями к конфиденциальности, но строить на нем корпоративное хранение российской компании рискованно.

Timeweb Cloud Сетевой диск

Сетевой диск от Timeweb Cloud — решение из другой категории, чем классические файлообменники. Это дисковое пространство, которое подключается к облачным серверам провайдера и расширяется по мере необходимости без остановки сервисов.

Сценарии и функции

Общее файловое пространство для нескольких серверов, хранение рабочих данных приложений, быстрый способ добавить место проекту без миграции. Управление из панели Timeweb Cloud, оплата за фактический объем.

Ограничения

Здесь нет пользовательского интерфейса для сотрудников, ссылок для внешнего обмена и совместного редактирования, потому что по факту это инструмент для ИТ-команды, а не для бухгалтерии и маркетинга. Мы включили его в обзор, так как задачу общего хранилища для небольшой инфраструктуры он решает просто и дешево. Уровень цен низкий.

VK WorkSpace Диск для бизнеса

Корпоративный диск в составе платформы VK WorkSpace, куда также входят почта, календарь и мессенджер. Ставка сделана на повседневную командную работу: общие папки, права доступа, совместное редактирование документов прямо в браузере.

Сценарии и функции

Централизованное хранение файлов отделов, обмен с коллегами и внешними адресатами, работа с офисными документами онлайн. Администратор управляет пользователями и доступами из единой консоли, данные размещаются в российских дата-центрах, поэтому с 152-ФЗ проблем нет.

Ограничения

Максимум пользы сервис дает внутри экосистемы VK WorkSpace: если почта и календарь у вас в другом месте, часть преимуществ теряется. Возможности тонкой настройки под сложные корпоративные политики скромнее, чем у платформ уровня Nextcloud. Уровень цен от низкого до среднего в зависимости от тарифа и числа пользователей.

S3-совместимые облачные хранилища

Второй раздел рейтинга посвящен другому классу продуктов. Здесь сравниваются не интерфейсы для работы сотрудников с документами, а облачные инфраструктурные сервисы — объектные S3-хранилища, к которым обращаются приложения, системы резервного копирования и аналитики. Их выбирают ИТ-команды и разработчики под бэкапы, логи, медиаконтент, архивы и данные для машинного обучения.

Практически все крупнейшие провайдеры в России предлагают S3-совместимые объектные хранилища, и на первый взгляд продукты похожи: бакеты, API, оплата за объем. Разница в деталях: полноте совместимости с S3 API, классах хранения, тарификации трафика и запросов, зрелости сопутствующих сервисов. Именно эти детали мы разобрали ниже.

Рег.облако S3

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

Сценарии и ограничения

Резервные копии сайтов, хранение статики и файлов небольших приложений. Продукт закрывает базовые потребности малого бизнеса, но по функциональной глубине — классам хранения, инструментам жизненного цикла, интеграциям — уступает крупным облачным платформам. Уровень цен низкий.

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

Beget Облачное объектное хранилище S3

Beget — хостинг-провайдер, выросший в облачную платформу, и его S3-продукт унаследовал главный фирменный принцип: максимально простой старт. Создать бакет и подключить его к сайту или системе бэкапов можно за считанные минуты из знакомой панели.

Сценарии и ограничения

Основные задачи: хранение статики веб-проектов, резервные копии, файлы приложений. Для сложных корпоративных сценариев с тонкими политиками доступа и жизненного цикла возможностей меньше, чем у крупных облачных платформ, и это осознанная плата за простоту. Уровень цен при этом остается низким, что делает сервис привлекательным для малого бизнеса и веб-студий.

K2 Cloud Облачное объектное хранилище S3

Объектное S3-совместимое хранилище K2 Cloud предназначено для неструктурированных данных любых объемов. Решение имеет смысл рассматривать, если требования к сохранности данных жесткие, например, под облачные сервисы для бизнеса в регулируемых отраслях. Для размещения простой статики небольших сайтов сервис может оказаться избыточным по бюджету.

Сценарии и ограничения

Доступ по S3 API и через веб-интерфейс, автоматическое масштабирование по мере заполнения. Ключевая особенность — георезервирование: каждый объект хранится в трех независимых дата-центрах. Версионирование позволяет откатиться на прежнюю редакцию файла, а механизм S3 Object Lock защищает данные от удаления. Все данные хранятся в российских дата-центрах, платформа соответствует 152-ФЗ до УЗ-1.

Типовые сценарии: резервное копирование и архивирование, хранение медиафайлов, создание озер данных, потоковое вещание.

Совместимость с Amazon S3 API позволяет использовать привычные инструменты: AWS CLI, S3cmd, rclone, S3 Browser. Однако поддерживаются не все методы S3 API, и стоит свериться со списком в документации под вашу задачу.

MWS Cloud Object Storage

MWS Cloud — облачная платформа МТС, и ее объектное S3-совместимое хранилище нацелено на корпоративный сегмент: SLA, поддержка уровня enterprise, размещение в собственных дата-центрах федерального телеком-оператора. Для крупных компаний, которые уже работают с МТС по связи и ИТ-услугам, это логичное расширение сотрудничества.

Сценарии и ограничения

Типовые инфраструктурные задачи — бэкапы, архивы, данные приложений и аналитики, а также интеграция с остальными сервисами платформы. Экосистема моложе, чем у лидеров рынка, поэтому отдельных смежных инструментов пока меньше. Уровень цен от среднего до высокого, что отражает ориентацию на enterprise.

Selectel S3

Selectel — один из ветеранов российского инфраструктурного рынка, и его объектное хранилище любят ИТ-команды: все объекты хранятся в трех копиях на разных серверах и в разных сегментах дата-центров уровня Tier III. Есть классы хранения под разные задачи — от горячего контента до холодных архивов и финальных бэкапов.

Сценарии и ограничения

Хранение контента сайтов и приложений, озера данных, резервное копирование, архивы. Трафик между S3 и другими продуктами Selectel не тарифицируется на стороне S3. Это приятная деталь для тех, кто строит инфраструктуру у одного провайдера. Поддерживаются привычные инструменты: rclone, AWS CLI, работа через FTP.

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

Timeweb Облачное объектное хранилище S3

S3-сервис Timeweb Cloud продолжает философию провайдера: понятная панель, быстрый старт, предсказуемые тарифы. Оно органично дополняет облачные серверы и базы данных Timeweb и подходит для команд, которые уже строят инфраструктуру у этого провайдера.

Сценарии и ограничения

Статика сайтов, пользовательские файлы приложений, резервные копии, раздача контента. Набор корпоративных функций базовый: для большинства задач малого и среднего бизнеса его достаточно, но глубоких enterprise-возможностей вроде развитых политик соответствия здесь искать не стоит. Уровень цен низкий, один из самых доступных на рынке.

VK Cloud Object Storage

Объектное S3-совместимое хранилище VK Cloud — часть большой облачной платформы, поэтому его сила в интеграциях: данные из бакетов удобно использовать в вычислительных сервисах, аналитике и Kubernetes того же провайдера. Есть классы хранения для горячих и редко используемых данных. Архивные данные обходятся дешевле.

Сценарии и ограничения

Хранилище закрывает весь типовой набор: бэкапы, медиа, статика, данные для анализа. Российские дата-центры и внимание к требованиям регуляторов делают его частым выбором компаний с госучастием. Из минусов пользователи отмечают, что тарификация с учетом классов хранения, запросов и трафика требует внимательного расчета — без калькулятора легко ошибиться в бюджете. Уровень цен средний.

Yandex Object Storage

Object Storage — объектное S3‑хранилище в составе Yandex Cloud. Вокруг него построена крупная экосистема: облачные платформы для бизнеса такого масштаба дают десятки смежных сервисов — от serverless-функций до аналитики, и хранилище связано с ними нативно.

Сценарии и ограничения

Несколько классов хранения: от горячего до ледяного архива, политики жизненного цикла, версионирование, блокировки объектов, хостинг статических сайтов. Документация и инструменты подробные, порог входа для разработчиков невысокий.

Оплата складывается из хранения, запросов и исходящего трафика, поэтому при активной раздаче контента счет может заметно превышать «цену за гигабайт». Это означает, что бюджет стоит считать по полному профилю нагрузки. Уровень цен средний. Для компаний, которым важна максимальная независимость от одной экосистемы, привязка к платформе — тоже фактор, который стоит взвесить.

Как протестировать облачное хранилище перед внедрением

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

Мини-сценарий теста

Возьмите один реальный сценарий: например, ночной бэкап базы на 200 ГБ или общую папку одного отдела. Проверьте четыре вещи: скорость загрузки и скачивания на ваших каналах, работу прав доступа, восстановление файла из версии или корзины и поведение вашего штатного ПО (бэкап-системы, rclone, офисного пакета). На тест достаточно одной-двух недель.

Как проверить прогнозируемость цены

Во время пилота снимите реальные метрики: объем данных, исходящий трафик, число запросов. Подставьте их в калькулятор провайдера и умножьте на планируемый рост за год. Вы получите честный бюджет вместо «цены за гигабайт» с лендинга. Отдельно смоделируйте пиковый месяц: массовое восстановление из бэкапа или маркетинговую кампанию с всплеском трафика.

Чек-лист миграции

Перед переездом зафиксируйте:

• полный перечень переносимых данных и их владельцев;
• порядок миграции (сначала некритичные массивы, затем боевые);
• период параллельной работы старой и новой систем;
• способ проверки целостности после переноса;
• ответственного и план отката.

И, конечно, важно помнить: миграция без плана отката — это не миграция, а прыжок веры.

Чек-лист выбора и внедрения облачного хранилища для бизнеса

Соберем главное из статьи в короткий список. Пройдитесь по нему, прежде чем подписывать договор:

• определите класс решения: файлообменник для сотрудников, S3 для систем и приложений или, возможно, нужны оба;

• выпишите два-три главных сценария и проверьте, что сервис закрывает их штатно, без доработок;

• проверьте размещение данных в РФ и сертификацию под ваши требования: 152-ФЗ, ГОСТ, PCI DSS;

• оцените защиту от потери: число копий и площадок, версионирование, корзина, блокировка удаления;

• посчитайте бюджет по полному профилю (хранение, трафик, запросы, пользователи) и умножьте на рост за год;

• проведите пилот на реальном сценарии и убедитесь, что ваши инструменты работают без «костылей»;

• составьте план миграции с проверкой целостности и планом отката;

• назначьте владельца сервиса — человека, который отвечает за доступы, квоты и порядок в данных.

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

Коротко о главном

Пока данных немного, компания может жить на разрозненных дисках и точечных настройках. Но с ростом объемов и числа пользователей такой подход перестает быть управляемым процессом: никто не знает, где лежит актуальная версия, доступы выдаются по памяти, а теневой файлообмен через личные аккаунты становится нормой вместе с рисками утечек и потери данных.

Зрелый подход — рассматривать хранение как часть инфраструктуры и контура информационной безопасности. А это значит: централизованное администрирование, восстановление по версиям, предсказуемые правила хранения и наблюдаемость через метрики и события, чтобы поддержка оперативно замечала аномалии и разбирала инциденты, а не узнавала о проблемах от пользователей.

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

Реклама. Рекламодатель: АО «К2 интеграция», ИНН 7701829110, erid: 2W5zFJheiiD

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

NGENIX — фильтрация без центров очистки

Облачная платформа для защиты и ускорения веб-приложений: DDoS-фильтрация на уровнях сети и приложений, антибот, облачный WAF, авторитативный DNS и CDN в одном кабинете. Отличается схемой митигации — трафик не перенаправляется в отдельные центры очистки, фильтрация работает на каждом узле распределённой платформы, рядом с пользователем.

Кейсы клиентов и кому подойдёт

Провайдер рассказал два сценария использования:

• Крупный федеральный ритейлер (название под NDA) пришёл в 2024 году с проблемой роста бот-трафика: боты парсили каталог, цены и остатки, резервировали товары без выкупа и искажали аналитику. Антибот-защита с поведенческим анализом, классификацией трафика и WAF в качестве последнего эшелона защиты позволила более чем вдвое сократить объём нежелательного трафика, устранить сценарии массового бронирования товаров, повысить конверсию, снизить показатель отказов на 35% и число клиентских жалоб более чем на 30%.
• Российская авиакомпания в сезонный пик столкнулась с ботами, которые отслеживали цены и бронировали билеты без выкупа — в отдельных случаях автоматика резервировала весь борт. После подключения антибот-защиты удалось существенно сократить количество автоматизированных обращений и обеспечить стабильную работу сервисов бронирования для реальных пользователей даже в период пиковых нагрузок.

Платформа подходит для компаний, которым критически важны доступность веб-ресурсов и бесперебойная доставка легитимного трафика, в том числе в условиях атак и пиковых нагрузок. Для нестандартного паразитного трафика доступна индивидуальная калибровка сигнатур.

Что можно подключить

NGENIX защищает от DDoS-атак на сетевом (L3/L4) и прикладном (L7) уровнях. Фильтрация L3 и L4 включена по умолчанию для всех заказчиков и работает круглосуточно, фильтрация L7 доступна с тарифа Lite. Заявленная мощность митигируемых атак — 7+ Тбит/с и 5 М+ RPS, включая атаки на DNS. IP-адреса веб-инфраструктуры маскируются, а при прямом подключении к платформе скрываются полностью, поэтому атака в обход не проходит.

Антибот строится на классификации: система анализирует поведенческие признаки, отпечатки браузера и сетевого стека и результаты JS-проверок и относит запрос к одной из четырёх категорий — «Публичный бот», «Точно бот», «Вероятно бот» или «Вероятно человек». Для каждой настраивается сценарий: пропустить, ограничить интенсивность через rate limiting, отправить на проверку (JS-челлендж, CAPTCHA, анализ отпечатков) или заблокировать. Строгие проверки применяются только к подозрительным запросам, чтобы исключить ложные срабатывания.

Для API анализируется не отдельный запрос, а поведение клиента целиком: последовательность вызовов, частота и интервалы, распределение по эндпоинтам. Так отсекаются парсеры с корректной авторизацией, неотличимые от легитимных клиентов по одиночным запросам. Отдельно закрываются скальперы, брутфорсеры, SMS-бомберы и кликеры, а запросы роботов Yandex и Google выделены в категорию публичных ботов.

Способов подключения четыре: делегирование DNS-зоны на серверы NGENIX (рекомендуемый), изменение DNS-записей через Anycast IP или CNAME и подключение по BGP. Среднее время подключения — один рабочий день. Правилами управляют через портал NGENIX Multidesk, открытый API или Terraform, метрики отдаются в формате Prometheus.

Редактор правила обработки запросов в NGENIX

Инфраструктура и экосистема

Более 50 узлов в 23 регионах присутствия в России и ближнем зарубежье, пропускная способность — 7+ Тбит/с, более 1000 провайдеров в прямом взаимодействии. Каждый узел одновременно выполняет функцию центра очистки: анализ и фильтрация идут на месте. По данным провайдера, платформа ежедневно обрабатывает 60 млрд запросов и блокирует 2 млрд. Для анализа поступающего трафика используются технологии машинного обучения, которые помогают выявлять аномальный трафик и определять источники его возникновения. Результаты анализа применяются для классификации трафика и принятия решений о его блокировке либо дополнительной валидации. DNS построен на распределённой сети с производительностью 100+ млн QPS и поддержкой DNSSEC.

Поддержка и каналы связи

Поддержка работает круглосуточно: почта, телефон, мессенджеры, веб-форма и тикет-система в портале. Заявленная скорость реакции на критичные инциденты — до 15 минут, на «Энтерпрайзе» подключается персональный менеджер. Документация по настройке и API открыта в Центре поддержки, на публичной странице публикуется состояния сервисов.

Тарифы, ограничения и условия

Бесплатного тарифа нет, новым пользователям предлагают тестовый период до 14 дней. Публичная линейка — пять тарифов с помесячной оплатой, итоговая стоимость зависит от набора сервисов, пакета обслуживания и SLA. Нелегитимный трафик не тарифицируется: по заявлению провайдера, заказчику не выставляют доплату, если объём вырос за счёт атаки.

Что именно входит в тариф

• Lite — 16 900 ₽ в месяц: 1 веб-ресурс, 100 Гбайт исходящего трафика, 100 млн. легитимных запросов, SLA: 99,4%
• Start — от 29 900 ₽ в месяц: 2 веб-ресурса, 1 000 Гбайт исходящего трафика, 200 млн. легитимных запросов, SLA: 99,4%
• Pro — от 69 900 ₽ в месяц при сроке от 12 месяцев,  2+ веб-ресурса, 3 000+ Гбайт или 50+ Мбит/с исходящего трафика, 200+ млн. или 100+ RPS легитимных запросов, SLA: 99,9%
• Ultimate — по запросу: 2+ веб-ресурса, 3 000+ Гбайт или 50+ Мбит/с исходящего трафика, 200+ млн. или 100+ RPS легитимных запросов, SLA: 99,95%+

Для компаний и организаций

Услуги оказывает российское юрлицо — ООО «Современные сетевые технологии» (ИНН 7733546298, ОГРН 1057747348427, Москва). Для регулируемых отраслей есть отдельный продукт: аттестованное публичное облако, соответствующее требованиям ФСТЭК по 152-ФЗ, ГОСТ Р 57580.1 и PCI DSS 4.0.1, с изоляцией сегментов сети.

Официальный сайт: ngenix.net

DDoS-Guard: надежная защита сайтов, API и мобильных приложений от DDoS-атак без тарификации атакующего трафика

DDoS-Guard — российский провайдер защиты от DDoS-атак, работающий с 2011 года. Компания управляет собственной сетью фильтрации ёмкостью 4 Тбит/с и защищает сайты, API и мобильные приложения от DDoS-атак в формате облачного сервиса, подключаемого через смену DNS-записей.

На рынке отличаются тем, что:

• предлагают решения только собственной разработки: не только фильтры DDoS, но и WAF, защита от ботов, капча – собственные продукты провайдера, которые он самостоятельно поддерживает и развивает
• не тарифицируют атакующий трафик, а полоса пропускания легитимного трафика всегда доступна целиком на защите L7
• предоставляют детальную статистику по обработке трафика и работе каждого модуля в отдельности, а также функционал сбора кастомной статистики, который позволяет отслеживать метрики, которых нет в общей статистике по трафику
• оказывают техподдержку пользователям и клиентам без использования ИИ-помощников и автоматизированных скриптов
• предоставляют гибкий сервис под задачи клиента:
есть готовая сетка тарифов с включенным набором опций, а также магазин допуслуг, который позволяет гибко кастомизировать тарифы и добавлять нужные опции без заявок и согласований

Кейсы клиентов и кому подойдёт

Провайдер поделился кейсами:

• Топ-3 сервис по заказу и покупке лекарств в стране столкнулся с техническими проблемами при использовании зарубежного сервиса защиты: высокой задержкой TTFB, медленной реакцией на rerouting и отсутствием гибкости в настройке защиты от DDoS-атак и парсинга, что напрямую влияло на производительность, безопасность и доверие клиентов. DDoS-Guard обеспечил миграцию с минимальным даунтаймом; стабильное соединение с сетью фильтрации и быстрый DNS resolve на территории РФ сразу значительно уменьшили показатель TTFB. Защиту подключили на уровнях L3–L4 и L7, а также настроили набор инструментов управления трафиком — правила защиты, сегментацию сайта и лимит запросов — для эффективной защиты от парсинга и скрейпинга. Дополнительно реализовали «параноидальный режим» с автоматической валидацией CAPTCHA, фильтрацию ботов с помощью JS challenge и управление функционалом через REST API.

• Крупное российское сообщество стремилось повысить устойчивость к постоянным кибератакам и сложным L7/L3–L4 атакам, сократить время простоя сайта с часов до секунд, а также внедрить инструменты для прозрачного анализа трафика и быстрой диагностики проблем пользователей. DDoS-Guard подключил защиту с постоянной фильтрацией L7-трафика и сетевого уровня (L3–L4): запросы проходят через каскад фильтров, вредоносный трафик блокируется до достижения серверов, а подозрительные запросы проверяются через CAPTCHA для минимизации ложных срабатываний. Также задействовали правила защиты, сегментацию сайта и лимит запросов (rate limiter). Во время аварийных работ в основном дата-центре функция «Активной балансировки» автоматически перевела весь трафик на резервный дата-центр, сохранив непрерывность работы для пользователей. Для ускорения диагностики проблем и сокращения ложных срабатываний разработали и внедрили решение с уникальным Request ID и сервисными страницами, содержащими детальные данные запроса (IP, временная метка).

Профиль клиента — это онлайн-сервисы, веб-ресурсы с высокой посещаемостью и проекты с критическими требованиями к доступности API и мобильных приложений, которым необходима защита от DDoS-атак, скрапинга и парсинга без блокировок легитимных пользователей

Что можно защитить

Обеспечивается полная защита на уровнях модели OSI L3–L7. Под защиту ставятся сайты, API и мобильные приложения, при этом система эффективно фильтрует трафик и отделяет легитимные запросы от ботов-парсеров. Для защиты от скрапинга, брутфорса и SMS-бомбинга доступен модуль «Правила защиты» по условию «доверенный источник запросов», работающий на базе собственной репутационной базы DDoS-Guard. Для API-трафика этот функционал существенно снижает число ложных срабатываний.

Также среди инструментов управления трафиком доступны:

• правила защиты;
• сегментация сайта;
• лимит запросов;
• фильтрация ботов с помощью JS challenge;
• «параноидальный режим» и проверка подозрительных запросов с помощью CAPTCHA.

Трафик живых пользователей провайдер не режет: при возникновении подозрений со стороны автоматики посетители могут пройти проверки и получить доступ к сайту.

Инфраструктура и экосистема

Суммарная емкость сети фильтрации составляет 4 Тбит/с. Компания использует машинное обучение для поведенческого анализа входящего трафика и формирования репутационной модели источников, что помогает отражать в том числе и атаки нулевого дня.

Управление правилами защиты вынесено в REST API (доступно на всех тарифах, кроме Basic). Решение полностью совместимо с инфраструктурами других облачных провайдеров, таких как AWS, Yandex Cloud и Selectel.

В услугу входят бесплатный SSL-сертификат, DNS-хостинг с полным доступом к управлению записями и CDN.

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

Отзывы и репутация

Из подтверждённой фактуры — запись в едином реестре российского ПО № 3665 от 28.06.2017 на продукт DDoS-GUARD Protection, свидетельство о государственной регистрации программы № 2023618722 от 27.04.2023, лицензия ФСТЭК № Л024-00107-00/00582472 и лицензии на телематические услуги и передачу данных. Компания аккредитована как ИТ-организация с 2016 года

Поддержка и каналы связи

Техническая поддержка и дежурная смена инженеров работают круглосуточно 24/7/365. Основное взаимодействие ведется через тикет-систему в личном кабинете, а в рамках приоритетных каналов связи используются Telegram-чаты.

Обработка обращений во всех каналах осуществляется исключительно сотрудниками — без применения автоматизированных ответов или ИИ-ассистентов. Заявленное время ответа зависит от тарифа: до 2 часов на Basic, до 40 минут на Normal, до 30 минут на Medium, до 15 минут на Premium и до 10 минут на Enterprise. Гарантированный SLA по доступности сервиса — 99,95%.

Тарифы, ограничения и условия

• Basic — 8 000 ₽/мес за один домен,
• Normal — 20 000 ₽/мес за один домен,
• Medium — 48 000 ₽/мес за три домена,
• Premium — 80 000 ₽/мес за пять,
• Enterprise — 200 000 ₽/мес за десять.

При оплате за 3, 6 и 12 месяцев действуют скидки 5%, 10% и 15%. Новым пользователям доступны 3 дня бесплатно на Basic.

В базовый тариф уже входят геоблокировки, бесплатный SSL-сертификат, DNS-хостинг и CDN.

Дальше набор услуг расширяется по тарифам:

• Normal: выделенный IP-адрес и поддержка сторонних сертификатов
• Medium: отчёты по L7-атакам и балансировка трафика между несколькими серверами
• Premium: пользовательские правила защиты и уведомления об инцидентах
• Enterprise: кастомные страницы, WAF и Bot Mitigation

Фильтры DDoS работают одинаково на всех тарифах — различия касаются дополнительных модулей и количества пользовательских правил. Атакующий трафик не тарифицируется, так что вам не придется беспокоиться о дополнительных расходах на защиту L7. Необходимые опции можно докупить в магазине допуслуг без заявок.

Ограничения: на Basic нет управления через API и пользовательских правил защиты, WAF и Bot Mitigation подключаются на старших тарифах отдельными модулями, подключение реализовано только сменой DNS-записей — защита собственной сети по BGP относится к другому продукту — «Защита сети», а распространение новых DNS-записей занимает до 24 часов при высоком TTL домена.

Процесс подключения

Быстрое подключение через изменение DNS-записей. Настройка услуги в личном кабинете занимает от 5 минут (в том числе в условиях активной атаки), а само обновление DNS-записей занимает от 5 минут до 24 часов в зависимости от параметров TTL домена.

После активации в личном кабинете становятся доступны инструменты управления трафиком и параметры фильтрации: правила защиты, сегментация сайта, лимит запросов (rate limiter), опции защиты от ботов и скрапинга, а также управление функциональностью через REST API (доступно на всех тарифах, кроме Basic).

Для компаний и организаций

Продукт зарегистрирован в реестре российского ПО, у компании есть лицензия ФСТЭК — это закрывает требования по импортозамещению при закупках. Юрлицам доступны оплата по счёту и закрывающие документы, приоритетные каналы связи и сопровождение персональным менеджером на старших тарифах.

Официальный сайт: ddos-guard.ru

Curator: облачная защита сайтов, API и мобильных приложений от DDoS-атак и ботов без капчи

Curator — российский провайдер защиты от DDoS-атак и киберугроз, известный на рынке как Qrator Labs. Компания выросла из исследовательского проекта 2006 года, в 2009-м превратила его в коммерческое облачное решение, а в 2010-м запустила собственную фильтрующую сеть. Сегодня это сеть из 21 центра фильтрации по всему миру с пропускной способностью анализа и фильтрации свыше 6 Тбит/с.

На рынке отличаются тем, что:

• не используют CAPTCHA как основной механизм проверки: защита прозрачна для легитимных пользователей, а вредоносные запросы блокируются с первого обращения
• фильтруют HTTPS-трафик без раскрытия ключей шифрования SSL — это отдельная технология, критичная для банков и финансовых сервисов
• заявляют 0% ложных срабатываний в стандартном режиме работы и не более 5% под массированной атакой
• держат время реакции на атаку менее секунды на L3–L4 и до 60 секунд на L7
• собрали вокруг Anti-DDoS целую линейку из семи продуктов: CURATOR.ANTIDDOS, CURATOR.WAF, CURATOR.ANTIBOT, CURATOR.CDN, CURATOR.BGP, CURATOR.SECONDARYDNS и CURATOR.SCANNER — все работают в едином облачном периметре
• не тарифицируют нежелательный трафик: клиент платит только за легитимную полосу

Профиль клиента — компании с высокими требованиями к непрерывности сервиса, которым нужна защита не только сайта, но и API с мобильными приложениями, и при этом важно не терять живых пользователей на проверках.

Что можно защитить

CURATOR.ANTIDDOS нейтрализует DDoS-атаки всех типов на уровнях L3–L4 и L7, включая мультивекторные. Защитить можно как отдельный веб-ресурс, так и всю инфраструктуру — это зависит от способа подключения.

CURATOR.ANTIBOT закрывает отдельный класс угроз: веб-скрейпинг и копирование контента, брутфорс логинов и промокодов, credential stuffing и захват учётных записей, скликивание рекламы и накрутку метрик, автоматизированные атаки на API, а также бот-трафик, который используется как топливо для L7-атак. Продукт блокирует более 4 млрд бот-запросов ежемесячно.

Для мобильных приложений на iOS и Android предусмотрена отдельная схема: проверка окружения через браузерную аутентификацию при входе и валидация токенов безопасности для API-запросов. Прямые обращения к API тоже фильтруются.

Детектирование строится на JS-снятии цифровых отпечатков браузера и устройства, анализе DOM и поведенческих паттернов, сравнении с профилями легитимных пользователей и сверке с базой известных вредоносных ботов. Режимов работы два — мониторинг и блокировка с настраиваемыми страницами.

CURATOR.WAF защищает от эксплуатации уязвимостей: SQL-инъекции, XSS, command injection, весь OWASP Top 10, атаки на бизнес-логику и на API. Для API доступны валидация HTTP-запросов, контроль параметров и заголовков, rate limiting и блокировка источников при аномалиях.

Инфраструктура и экосистема

21 точка фильтрации по всему миру, суммарная пропускная способность анализа и фильтрации — свыше 6 Тбит/с. Сеть подключена к Tier-1-провайдерам, компания состоит в RIPE NCC с 2016 года и участвует в инициативе MANRS с 2021-го. Команда — более 80 экспертов в шести локациях, партнёрская сеть — свыше 200 партнёров по миру.

Решение полностью облачное: устанавливать модули на стороне клиента не нужно. Подключить можно двумя способами. DNS-подключение защищает веб-ресурсы на L7, работает с TCP-трафиком и не требует собственной автономной системы. BGP-подключение закрывает всю инфраструктуру, поддерживает все протоколы, включая UDP, но требует собственной AS и IP-блока.

Поддержка и каналы связи

Техподдержка доступна по бесплатному номеру, вопросы решаются также через почту mail@curator.pro, Telegram и сообщество во «ВКонтакте».

Гарантированная доступность сервиса зафиксирована в SLA и различается по тарифам: 97% на Professional, 99% на Business, 99,5% на Corporate и 99,9% на Enterprise.

Тарифы, ограничения и условия

• Professional — от 23 000 ₽/мес, SLA 97%, фильтрация вредоносного трафика до 10 Гбит/с
• Business — от 78 000 ₽/мес, SLA 99%, фильтрация до 50 Гбит/с, HTTPS-фильтрация без раскрытия ключей шифрования, защита WebSocket и TCP
• Corporate — от 160 000 ₽/мес, SLA 99,5%, фильтрация до 500 Гбит/с, BGP-подключение и выделенные порты
• Enterprise — по запросу, SLA от 99,9%, индивидуальная настройка

В каждый тариф включено 10 Мбит/с легитимной полосы, дальше — 800 ₽ за каждый дополнительный Мбит/с. Нежелательный трафик не тарифицируется вообще. Каждый IP-адрес сверх первого стоит от 7 000 до 25 000 ₽/мес в зависимости от тарифа. DNS подключается от 8 000 ₽/мес, CDN — от 10 000 ₽/мес. Новым пользователям доступны 7 дней бесплатно.

Ограничения: WAF, антибот, CDN, DNS и управление через API идут отдельными платными опциями, а не входят в базовый функционал. HTTPS-фильтрация без раскрытия ключей недоступна на Professional. BGP-подключение требует собственной автономной системы и IP-блока, поэтому проекту без своей AS остаётся только DNS-схема.

Процесс подключения

Настройка DNS-подключения занимает около 15 минут и не требует установки оборудования или модулей на стороне клиента. Дальше трафик идёт через фильтрующую сеть Curator, а в личном кабинете становятся доступны аналитика в реальном времени и автоматические отчёты по инцидентам. Бесплатный тестовый период — 7 дней, но если ресурс в этот момент уже под атакой, он сокращается до 24 часов.

Для компаний и организаций

ПО в реестре российского ПО и аккредитация ИТ-компании закрывают требования по импортозамещению при закупках. Решение поддерживает соответствие PCI DSS — за счёт фильтрации HTTPS без раскрытия ключей шифрования. Отдельный продукт CURATOR.BGP пригодится тем, кому важен мониторинг маршрутизации и защита от BGP-инцидентов.

Официальный сайт: curator.pro

StormWall: защита сайтов, сетей и TCP/UDP-сервисов от DDoS-атак с оплатой только легитимного трафика

StormWall — российский разработчик и поставщик защиты от DDoS- и хакерских атак для сайтов, серверов, сетей и ИТ-инфраструктур. Сеть очистки трафика состоит из 10 узлов по всему миру с общей ёмкостью фильтрации более 8 000 Гбит/с. Подключение веб-ресурса занимает 10 минут и делается через перенаправление DNS-записи на защищённый IP-адрес StormWall.

На рынке отличаются тем, что:

• держат самую большую заявленную ёмкость фильтрации среди российских провайдеров: более 8 000 Гбит/с
• берут деньги только за легитимный трафик: клиент платит за реальных пользователей, а не за объём атаки
• отбивают атаку быстро и бесплатно даже до заключения договора и отдают отчёт — решение работать дальше остаётся за клиентом
• дают SLA и время реакции прямо в тарифной сетке: от 3 часов на младшем тарифе до 15 минут на старшем
• закрывают не только сайты, но и сети через BGP и произвольные TCP/UDP-сервисы — это отдельные продукты, а не опции к веб-защите
• имеют статус локального интернет-регистратора (LIR), состоят в RIPE и являются официальным партнёром DE-CIX

Профиль клиента — проекты, которым нужна предсказуемая стоимость защиты и прозрачное управление: от личных сайтов на младшем тарифе до банков, страховых, ритейла и провайдеров на старших. Отдельно StormWall работает с интернет-провайдерами и телекомом, онлайн-играми, банками и интернет-магазинами.

Что можно защитить

StormWall для сайта фильтрует весь входящий трафик по технологии проксирования на уровнях L3–L7 и блокирует SYN Flood, UDP Flood, HTTP Flood, Slowloris, DNS amplification и атаки с ботнетов. Помимо веб-ресурсов защита есть для сетей через BGP и для произвольных TCP/UDP-сервисов — это отдельные продукты линейки. Для тех, кому нужна защита в собственной инфраструктуре, существует StormWall Appliance.

Антибот идёт двумя уровнями. Базовый включён во все тарифы на защиту сайта, не требует настройки и отделяет людей от скриптов интерактивными проверками: cookie-валидация, HTTP-редиректы, JavaScript-испытания и капча, когда без неё не обойтись. Продвинутый антибот доступен на тарифе Enterprise: настраиваемые сценарии защиты под конкретную бизнес-логику, анализ TLS-отпечатков JA3 и JA4, списки доверенных и недоверенных отпечатков, моделирование паттернов HTTP-запросов и гибкие комбинации правил. Реакций на срабатывание несколько — пропустить запрос, ограничить частоту, показать интерактивную проверку или заблокировать.

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

WAF защищает веб-приложения и API: SQL-инъекции, XSS, CSRF, атаки на API с контролем доступа и rate limiting, эксплуатация бизнес-логики. Покрытие — от OWASP Top 10 до целевых атак на API, с ML-детектом 0-day и 1-day угроз. Вместе с Anti-DDoS и антиботом получается трёхуровневая защита в одном контуре.

Инфраструктура и экосистема

Сеть очистки — 10 узлов общей ёмкостью более 8 000 Гбит/с: Москва (ММТС-9), Санкт-Петербург (Selectel SPB-2), Майами (Equinix MI1), Лос-Анджелес (Equinix LA1), Франкфурт-на-Майне (Equinix FR5 и e-Shelter FR1), Гонконг (Equinix HK1), Сингапур (Equinix SG3), Дубай (SmartHub Fujairah), София (Telepoint Center) и Джакарта. На 2026 год заявлен запуск площадок в Сан-Паулу, Мумбаи и Алматы.

Кэширование статических элементов работает по технологии HyperCache и снимает нагрузку с веб-серверов — CDN идёт внутри подписки, без дополнительных затрат. Защита возможна без раскрытия SSL. На SEO и сервисы аналитики фильтрация не влияет, реальные IP-адреса посетителей сохраняются в HTTP-заголовке.

Личный кабинет даёт аналитику в реальном времени, настраиваемые правила фильтрации, историю атак, аналитику запросов и кодов ответов, автоматические уведомления об атаках, подробные отчёты в PDF и управление субаккаунтами и ролями. Отчёты о защите можно получать на почту не только по расписанию, но и в произвольный момент. На старших тарифах доступны управление антиботом (JA3 и цепочки) и доступ к логам запросов через Graylog.

Технологический стек компания раскрывает открыто: бэкенд на Python, PHP и C, фронтенд на HTML5, CSS3 и JS, PostgreSQL в качестве основной СУБД, контейнеризация по стандарту OCI и оркестрация на Kubernetes во внутренней инфраструктуре.

Поддержка и каналы связи

Поддержка работает круглосуточно, заявленная скорость ответа — до 15 минут. Поддержка в мессенджере доступна начиная с тарифа Business ONE. Гарантированное время реакции на запрос зафиксировано в тарифе: 3 часа на Personal, 30 минут на Business ONE, 15 минут на Enterprise ONE и StormWall Private.

Тарифы, ограничения и условия

Цены на защиту сайта опубликованы открыто (за один домен второго уровня):

• Personal — 12 000 ₽/мес, 25 Мбит/с полосы, SLA 98%, реакция за 3 часа
• Business ONE — 45 000 ₽/мес, 50 Мбит/с, SLA 99,2%, реакция за 30 минут
• Enterprise ONE — от 115 000 ₽/мес, 50 Мбит/с и выше, SLA 99,5%, реакция за 15 минут
• StormWall Private — от 348 000 ₽/мес, премиальная защита по индивидуальным правилам

Процесс подключения

Подключение занимает 10 минут и проходит в три шага. Клиент получает защищённый IP-адрес StormWall, DNS-запись сайта перенаправляется на этот адрес — дальше весь трафик проверяется, фильтруется и оптимизируется, а вредоносные запросы блокируются сразу. На сервер приходит только чистый трафик с сохранением реальных IP-адресов посетителей в HTTP-заголовке. Если у компании есть собственные сети, защиту сайта можно подключить по BGP без смены IP-адреса. Бесплатный тестовый период предусмотрен, а идущую прямо сейчас атаку в StormWall обещают отбить бесплатно и выдать отчёт.

Для компаний и организаций

Юрлицам доступны оплата банковским переводом и заключение договора, договор-оферту можно скачать с сайта до обращения в отдел продаж. Для миграции с зарубежных сервисов у StormWall есть отдельный сценарий: настройки готовятся заранее по анкетам, а переключение проходит поэтапно через тестовый контур.

Официальный сайт: stormwall.pro

Servicepipe: высокоточная защита сайтов, API и мобильных приложений от DDoS-атак и продвинутых ботов — в облаке и на своей инфраструктуре

Servicepipe — российский разработчик систем защиты веб-ресурсов и ИТ-инфраструктуры, работающий с 2015 года. Компания заявляет более 200 компаний под защитой, свыше 500 реализованных проектов, партнёрскую сеть из 110+ компаний и команду более 150 человек — инженеров NOC и SOC, аналитиков данных и разработчиков высоконагруженных систем. Отличие от чисто облачных провайдеров в том, что Servicepipe одинаково закрывает и сценарий «поставьте нам защиту в облаке», и сценарий «разверните её внутри нашего периметра».

На рынке отличаются тем, что:

• дают четыре схемы интеграции вместо одной: облачный Proxy, локальный модуль Cybert на NGINX или Angie, гибрид и IP-Transit с анонсом подсети — можно собрать конфигурацию под требования безопасности, а не подстраиваться под вендора
• принимают решение по каждому запросу менее чем за 1 миллисекунду и анализируют более 100 технических параметров запроса
• заявляют менее 0,01% ложных срабатываний
• работают без капчи по умолчанию: интеграция с CAPTCHA возможна, но не обязательна
• умеют терминировать зашифрованный трафик локально, без передачи ключей SSL/TLS наружу — через Cybert
• фильтруют не по IP-адресу, а по отдельным запросам, что важно для NAT и мобильного трафика
• тарифицируют защиту по полосе легитимного трафика без ограничений по объёму атаки: ни пиковая атака, ни многодневный DDoS не приводят к смене тарифа

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

Что можно защитить

Под защиту ставятся сайты, веб-приложения, API и мобильные приложения. Система закрывает DDoS-атаки на уровнях L3–L7, включая высокочастотные и низкочастотные, объёмные UDP-флуды с амплификацией, некорректные TCP-соединения, проблемы SSL-сессий и низкочастотные атаки поверх HTTPS.

По ботам список угроз шире обычного: веб-скрейпинг и парсинг контента, сканирование уязвимостей, SMS-бомбинг, брутфорс пользовательских аккаунтов, фейковые регистрации и мошеннические заявки, атаки на бизнес-логику из OWASP API Security Top 10 и OWASP Automated Threats.

Детект строится на нескольких слоях одновременно: сигнатурный анализ в реальном времени по известным паттернам атак, репутационный анализ источника, поведенческая аналитика на ML-моделях и фингерпринтинг с оценкой данных клиентского окружения. Система постоянно донастраивается аналитиками.

Инструменты управления в личном кабинете: собственные правила, списки блокировки и разрешений, географические ограничения и лимиты частоты запросов. Для API отдельно доступен rate limiting.

Облачный WAF подключается поверх и закрывает атаки прикладного уровня. Устроен он необычно: Servicepipe предлагает на выбор три решения — PT Cloud Application Firewall от Positive Technologies, SolidWall от SolidLab и ПроWAF от WMX. Поддержка бывает двух уровней: базовая (подключение, дефолтные политики, сопровождение инфраструктуры) и Managed WAF (настройка политик под приложение, разбор ложных срабатываний, работа с вендором и закрытие уязвимостей правилами WAF).

Инфраструктура и экосистема

Платформа геораспределённая, с присутствием в основных дата-центрах Москвы. Ёмкость сети фильтрации на сайте не раскрывается — этот параметр стоит запросить у вендора.

Схем интеграции четыре. Proxy — облачная фильтрация ботов и DDoS через смену A-записи DNS с передачей SSL/TLS-сертификата. Module — локальный модуль Cybert на веб-сервере NGINX или Angie, без смены DNS-записей и без передачи ключей шифрования. Hybrid — облачная фильтрация DDoS в связке с локальной защитой от ботов через обратный TCP-прокси, при этом терминация SSL остаётся на стороне клиента. IP-Transit — фильтрация DDoS на сетевом уровне через анонс подсети.

Cybert — отдельный продукт для тех, кому нужна локальная защита сайтов, веб-приложений и API внутри собственной инфраструктуры. Работает на L7, решение принимает менее чем за 1 миллисекунду, ложных срабатываний менее 0,01%, поддерживает NGINX и Angie. Продукт соответствует требованиям PCI DSS и ГОСТ Р 57580.1–2017. Cybert используют более 20 российских компаний.

Для инфраструктуры есть DosGate (on-premise) и FlowCollector, для маркетинга — линейка Visibla, отдельно существуют защищённый DNS-хостинг и Digital Fraud Protection. В лабораторном контуре доступны стресс-тестирование и анализ логов веб-сервера.

В личном кабинете есть дашборды, аналитика трафика, логи запросов и кастомные события — видно, что именно и по какой причине заблокировано.

Поддержка и каналы связи

Техническая поддержка работает круглосуточно и в проактивном режиме — она включена в услугу, а не продаётся отдельным пакетом. Заявленное время реакции на инцидент — 10 минут. Связаться можно по телефону, почте welcome@servicepipe.ru для новых обращений и cybert@servicepipe.ru для действующих клиентов. Для WAF отдельно доступен формат Managed, когда политики и разбор ложных срабатываний берёт на себя команда Servicepipe.

Тарифы, ограничения и условия

Стоимость считается индивидуально, по запросу. Известна сама модель тарификации — защита оплачивается по полосе легитимного трафика, без ограничений по объёму атаки. Ни пиковая атака, ни многодневный DDoS не требуют перехода на другой тариф и не приводят к доплате за «мусорный» трафик.

WAF считается отдельно, и модель тарификации зависит от выбранного вендора WAF. Важный нюанс: WAF стоит в цепочке после фильтрации DDoS и ботов, поэтому платить за обработку мусорного трафика на этом уровне тоже не приходится.

Ограничения: WAF работает только в схеме Proxy в связке с Web DDoS Protection или Web DDoS & Bot Protection, потому что для анализа прикладного уровня нужна расшифровка SSL/TLS. Локальный модуль Cybert поддерживает только NGINX и Angie — другие веб-серверы придётся закрывать облачной схемой. Публичных цен нет, так что быстро прикинуть бюджет по сайту не получится.

Процесс подключения

Подключение занимает от 10 до 30 минут. В облачной схеме нужно сменить A-запись DNS и передать SSL/TLS-сертификат — дальше трафик проходит через платформу фильтрации, проверяется и уходит на защищаемый ресурс обратным прокси. В локальной схеме модуль Cybert ставится на NGINX или Angie, менять DNS-записи не требуется. После подключения в личном кабинете становятся доступны правила, списки, геоограничения, лимиты частоты запросов, дашборды и логи.

Перед боевым запуском доступен пилот на 14 дней, а также демонстрация продукта и стресс-тестирование в лабораторном контуре.

Для компаний и организаций

Cybert в реестре российского ПО, у компании три лицензии ФСТЭК — требования по импортозамещению при закупках закрываются. Соответствие ГОСТ Р 57580.1–2017 и PCI DSS делает решение применимым в финансовом секторе, а локальная терминация шифрованного трафика подходит организациям, которым нельзя выпускать расшифрованный трафик за периметр. Для перехода с зарубежных ИБ-решений у компании есть отдельная программа миграции.

Официальный сайт: servicepipe.ruЧто выбрать

Если проблема не в объёме атак, а в ботах, которые работают по бизнес-логике — парсят цены, резервируют товар, накручивают клики, — смотрите NGENIX. Запросы раскладываются по четырём категориям, и для каждой вы сами выбираете сценарий; для API анализируется поведение клиента целиком, а не отдельный запрос.

Если вы под атакой прямо сейчас — DDoS-Guard. Настройка занимает от пяти минут даже в разгар атаки, порог входа — 8 000 ₽/мес за домен, опции докупаются без заявок и согласований, а в поддержке отвечают живые инженеры.

Остальные три — под более узкие задачи:

• Curator — когда нельзя терять живых пользователей на проверках: капча не используется как основной механизм, HTTPS фильтруется без раскрытия ключей.
• StormWall — когда нужно посчитать бюджет, не написав в отдел продаж: прайс открыт. Закрывает и сети по BGP.
• Servicepipe — когда расшифрованный трафик нельзя выпускать за периметр: модуль ставится на ваш NGINX или Angie. Цены по запросу.

Перед договором проверьте два пункта: тарифицируется ли атакующий трафик и какое время реакции поддержки зафиксировано в вашем тарифе.

Изначально был только сервер

В котором мы жили по уже сложившимся канонам внутри известного и подконтрольного периметра и исповедовали Zero Trust — подход к безопасности, при котором никто никому не доверяет по умолчанию. И однажды у нас появилась задача «въехать» в облако. Но не в ещё один собственный ЦОД, а во внешнее облако.

Пример выезжающих в облако в рамках пилотов команд говорил, что всё будет быстро и легко. Но быстро и легко пришло только осознание, что нельзя просто так взять и перенести on-prem в облако.

Почему?

Потому что традиционные средства и подходы не работают. Само по себе облако имеет специфику безопасности, а риски отличаются от традиционной инфраструктуры. Возможно, по этой причине за 2024 год больше 60% компаний столкнулись с инцидентами безопасности, связанными с облаком, а в 2025 — уже 65%?

Если, как упоминал ранее, мы жили за неким сетевым периметром, где можно было отгородиться блокирующими или разрешающими правилами или «белыми списками», то облако — это API-first инфраструктура, где используемые сервисы (особенно managed services) не стоят за какими-то фаерволами, а имеют в первую очередь публичные API, доступ к которым регулируется иными правилами: RBAC, политики, ACL.

Возникает новая модель ответственности, где часть задач берет на себя платформа и её сотрудники. Это так называемый Cloud Trust — модель безопасности, которая предполагает разделение обязанностей между провайдером и клиентом.

Но даже если ответственность поделена, отпускать контроль мы не можем. Но и тормозить команды оправданиями «уникальной специфики облака» тоже не будем. Так что мы решили не изобретать велосипед, а просто учесть специфику облака в виде вариантов технической реализации наших текущих процессов. Ниже я пройду по базовому набору действий: сеть, доступы, конфигурации и SOC.

№1. Сетевой доступ

Мы сделали практически полный маппинг ресурсной организации on-premises с ресурсной организацией Yandex Cloud (ЯО далее).

Как и говорил ранее, у нас появляется новый периметр — IAM. Но и старый никуда не исчезает. Сетевая изоляция и микросегментация остаются чуть ли не самыми важными вопросами ИБ до сих пор. Потому первый же вопрос, который мы задали себе при выезде, был таков: «А как нам с ним общаться?» То есть как строить интеграции, как пускать управляющий трафик и трафик этих интеграций и так далее.

Ответом на вопрос стал интерконнект. Это оптика с тёмным волокном между Банком и Платформой, поверх которой накладывается ГОСТ-шифрование. В интерконнект мы заворачиваем весь свой трафик, ходим из сети Банка в консоль, строим внутри интеграции и т.д.

Чтобы текущие процессы продолжали работать в облаке, должна появиться схожая структура и организация управляемых объектов, то есть сетей, подсетей и правил фаерволинга. Напомню, что мы тут про ИБ, поэтому опустим некоторые детали сетевой архитектуры.

В банке у каждой условной системы есть свой набор сред (упрощенно: dev, test, prod). Каждая из них имеет собственный набор подсетей, строго изолированных друг от друга. В рамках одной среды подсети этой системы также изолированы фаерволами.

Такую же структуру мы организовали в облаке: система — это облако, а фолдеры – среды, каждая из которых имеет свои сети/подсети и набор правил фаерволинга, реализованных через Security Groups (как механизм сетевой изоляции).

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

Команда, как и раньше, согласовывает проект, заказывает подсети и сетевые доступа, как в on-prem, но в облаке. И даже если система поделена между on-prem и облаком, то её связность никак не нарушается. Все проекты, выезжающие в облако, получают пул IP-адресов с банковской сетью. Эти сети анонсируются в интерконнект и выглядят так, будто просто находятся в другом ЦОДе, и в нашей системе учета сетей пул заводится как обычная подсеть.

Мы выбрали контроль через сохранение текущей модели управления доступом, но делегировали реализацию этого процесса облачным сервисам — тем же Security Groups, которыми мы управляем через Terraform.

Единственное, что внешний трафик («интернет-интернет») в облако и из облака пока не пускаем — только через внутреннюю инфраструктуру. Но когда-нибудь сможем.

№2. Пользовательский доступ

Осознавая критичность пользовательских доступов в новой парадигме, мы решили, что и процесс управления последними также должен быть универсальным и повторять свою реализацию в новом окружении. Внутри все пользовательские доступы, доступы систем, технических учетных записей, управляются централизованно через Active Directory (AD) и KeyCloak, которые также поделены по средам. Облако позволяет их интегрировать со своим IAM и построить на их базе федерации для каждой из сред со своими наборами политик.

Фактически процесс аутентификации происходит в банке и транслируется в ЯО — то есть мы продолжаем использовать именно банковские корпоративные УЗ через банковскую же инфраструктуру для доступа к ресурсам и консоли облака.

А что с авторизацией и правами?

Сама по себе авторизация очень важна, и в какие бы разные и мелкие группы пользователей AD мы ни распределяли сотрудников, она всё равно работает уже на самом сервисе. Без сервисных ролей здесь никуда.

Мы начали переход в облако давно, и на первых этапах роли были примитивнее, чем сервисные. Со временем у ЯО появилась отличная грануляция сервисных прав, которая очень удобно позволяет собирать роли, соблюдая принципы наименьших привилегий. И также позволяет сопоставлять упомянутые ранее группы A D и группы пользователей IAM в ЯО. Фактически мы и здесь реализовали текущий процесс управления доступом в новом облачном окружении, сохранив командам привычный флоу работы и скорость без потери контроля.

Получился отличный баланс – аутентификация как в on-prem, но логичное делегирование авторизации в облако.

№3. Контроль конфигурации

Ну а что насчет самого разворачивания в облаке? Как вообще выезжать и контролировать то, что едет?

Чуть ранее я говорил, что мы используем ту же модель объектов в облаке, что и в банке, т.е. условно созданный Compute Cloud в облаке фиксируется в нашей системе инвентаризации как обычная WM. То же самое с сетями, то же и с другими сервисами.

Но что изменилось?

Например, мы стали вести реестр и критерии применимости Managed Services – каждый из них имеет свои возможности и нюансы, и мы начали с того, что провели анализ и составляем некую карту применимости того или иного managed services в том или ином проекте, с помощью которой можем решить, что один сервис разрешен одной команде, а другой запрещен.

Каждый проект должен создать свою проектную документацию – фактически отрисовать архитектуру с применяемыми в том числе облачными ресурсами. По итогу он получит согласование (сам процесс согласования сейчас не важен). И далее команда идет не в ЯО, а в нашу внутреннюю платформу, интегрируемую с облаком и через неё заказывает все необходимые ресурсы —> всё будет поднято для них в облаке. А мы на своей стороне сможем проверить ту же конфигурацию этих ресурсов.

Стоит отметить, что облако помимо предоставления своих образов ОС, за безопасностью и свежестью которых они следят самостоятельно, также позволяют приносить и свои образы, чем мы активно и пользуемся. И здесь, как я ранее писал, мы также разрешаем использовать и облачные managed services.

Далее на развернутую инфраструктуру надо деплоить приклад — мы выбираем платформу CI/CD. Но здесь всё просто – у нас есть требования к платформам CI/CD и фактически такую систему можно сделать полностью облачной, что мы пробовали. Но использовать внутреннюю, уже построенную и готовую, куда удобнее: все сканеры настроены, все гейты построены.

И, самый интересный пункт, по моему мнению — контроль развернутого. Так уж получилось, что у нас есть своя команду ответственных за безопасность облаков, которой удается время от времени заниматься исследование новых облачных сервисов, актуализировать модель угроз и требования.

А так как в облаке у нас довольно внушительная инфраструктура, много новых тяжелых подпроцессов, новых требований и моделей угроз, а команда маленькая, то без автоматизации никак. Потому с самого начала мы перекладывали все требования в код. Сейчас наши требования выглядят как набор проверок в коде — фактически это сканер облаков, являющийся клиентом над API облака, со всеми необходимыми нам функциями. Так, фактически, у нас появился собственный CSP (Cloud Security Posture Management — управление состоянием безопасности облака).

Этот подход позволяет писать любые требуемые нам проверки. Но порой нам может не хватать экспертизы в каких-то вопросах, и без экспертизы ЯО не обойтись, поэтому мы также можем использовать сервис Yandex Security Deck с его модулями.

На данном этапе мы всё ещё сохраняем преимущественно Zero Trust подход, но частично отдаём ответственность ЯО.

№4. SOC

Мы всё развернули, задеплоили, прошли проверки ИБ. А значит пора мониторить, детектить и реагировать. В on-prem мы знаем всё: у нас свои правила и полный контроль логов — на это отдельно выделена функция SOC.

Но в облаках у нас нет полного контроля над логами, так как:

• мы можем использовать только те сервисы сбора логов, что нам предоставляет площадка: Control Plane и Data Plane (= Audit Trail/Cloud Logging), а также логи действия самого провайдера;
• в ЯО постоянно появляются сервисы (которые, конечно же, сразу нужны командам), а фичи (в плане логирования) за ними не поспевают.

Но одно дело получить, другое — обработать (нужен детект). На это нужно нанимать команду, чтобы собирать, обрабатывать, а это дорого (да и свою экспертизу надо наращивать).

Поэтому мы всё ещё пользуемся сервисом YCDR от платформы, который позволяет нам закрывать эту функцию в облаке.

Примечание. С логами у нас ситуация строгая, и не все сервисы выдают необходимые объём и формат, но команда ЯО всегда старается реализовать необходимый FR или же всегда можно воспользоваться их экспертизой и сервисом SOC.

Итого

На данный момент в облаке у нас довольно большая инфраструктура: разные среды, разные системы, 1500 виртуальных машин, 100 managed services, 1000 пользователей — сотрудники и члены команд и сервисных аккаунтов.

Если собрать всё, о чём мы говорили, в одну картину, то кажется, что сети, доступы, конфигурации, мониторинг — это разные процессы. Но на самом деле в каждом из них мы принимаем одно и то же решение — где оставить контроль, а где довериться облаку.

Безопасность в гибридной инфраструктуре — это не набор инструментов, сумма решений. Если пытаться всё контролировать — не успеем за скоростью облака. Если доверять всему — потеряем безопасность. Поэтому единственный рабочий подход — это баланс между Zero Trust и Cloud Trust.

Уязвимости затрагивают разные этапы обработки файла. Для ошибки iinf/max_items достаточно чтения контейнера через heif_context_read_from_file, без декодирования изображения. Отдельная проблема возникает при обходе ссылок на этапе декодирования, а взаимная блокировка потоков связана с параллельным декодированием grid-тайлов. Поэтому проверка только загрузки метаданных не воспроизводит все три проблемы с высокой оценкой.

• Лимит max_items не применялся к дочерним боксам iinf: файл объявляет сколько угодно элементов, разбор становится квадратичным. Замер: 1,7, 6 и 23 секунды процессора на файлы 1, 2 и 4,1 МБ; файл 6,9 МБ держит 480 МБ памяти, 23 МБ файл 1,5 ГБ, и max_total_memory этого не видит. В сборке под Emscripten тот же счётчик задавал размер alloca на 64-килобайтном стеке WebAssembly: 16 000 элементов проходят, 17 000 роняют вызов, с 18 000 модуль ломается необратимо.
• Неограниченная рекурсия при обходе ссылок могла исчерпать стек; исправленный обход на этапе декодирования использует явный список в куче.
• Инверсия порядка блокировок при параллельном декодировании тайлов grid (включено по умолчанию) давала вечный дедлок; циклические графы ссылок отклоняются до начала декодирования.
• Три проблемы средней важности: чтение за границей буфера в плагинах кодировщиков aom и x265, неисправимая утечка памяти в heif_track_get_next_raw_sequence_sample и чтение за границей в экспериментальном плагине WebCodecs.
• Уязвимы версии от 1.16.0 до 1.23.3 включительно (в зависимости от проблемы), исправлено в 1.23.4; номера CVE будут присвоены позже.

Как одна неучтённая ветка отключила лимит на число элементов

В отчёте описана классическая ошибка перегруженного параметра. Функция Box::read_children принимает max_number, у которого два смысла: со значением-сентинелом READ_CHILDREN_ALL она читает до конца бокса и проверяет лимит max_items, а с любым другим числом читает ровно столько детей и ничего не проверяет. Box_iinf::parse передавала туда счётчик из самого файла, поэтому проверка, написанная специально для iinf, никогда не выполнялась.

Дальше цена растёт квадратично: для каждого элемента вызывается полный проход по списку ссылок iref без раннего выхода. Исследователь измерил на одном ядре 1,7, 6,0 и 23 секунды для файлов в 1,0, 2,0 и 4,1 МБ; абсолютные цифры различаются вдвое между машинами, но рост в 3–4 раза на каждое удвоение стабилен против 2 раз у линейного парсера. Всё это происходит внутри вызова, который затем возвращает heif_error_Ok, без коллбэка отмены и прогресса. В 1.23.4 лимит проверяется заранее, объявленное число ограничено оставшимся входом, а запросы к iref индексируются по идентификатору элемента: на файле с 1 000 элементов и 160 000 ссылок dimg время чтения упало с 1,83 до 0,26 секунды.

Сборка под WebAssembly страдала отдельно. Два вспомогательных метода в Emscripten-обвязке выделяли массив идентификаторов через alloca с размером из того же счётчика. Скрипт сборки не задаёт ни размер стека, ни проверку его переполнения, поэтому использовался стек по умолчанию в 64 КБ: 16 000 элементов занимают 64 000 байт и декодируются, 17 000 прерывают вызов, а с 18 000 переполнение уходит в сегмент статических данных и экземпляр модуля перестаёт работать до перезагрузки страницы. Хелпер вызывается при каждом HeifDecoder.decode().

Рекурсия и дедлок: две другие высокие уязвимости

Вторая проблема: проверка на циклы ссылок между производными элементами была рекурсивной, и длинная цепочка исчерпывала стек. Без лимита на число элементов глубина ничем не ограничена. Исправленный обход на этапе декодирования использует явный рабочий список в куче вместо рекурсии.

Третья проблема затрагивает серверы с параллельным декодированием: параллельное декодирование тайлов grid включено по умолчанию, а ImageItem::decode_image() держит нерекурсивный мьютекс элемента на время вложенных декодирований. Два рабочих потока, чьи элементы ссылаются друг на друга, берут два мьютекса в противоположном порядке и зависают навсегда; процесс не падает и не освобождает ресурсы. Исправление отклоняет циклические графы декодирования, включая рёбра dimg и alpha auxl, до старта.

Кому обновляться в первую очередь

Всем, кто принимает HEIC и AVIF от пользователей: это серверные конвертеры, бэкенды фотохостингов и мессенджеров, CI-пайплайны с ImageMagick, а также веб-приложения, которые декодируют HEIC на клиенте через libheif-js или собственную Emscripten-сборку. Для последних важно, что обрушение WebAssembly-модуля необратимо в рамках страницы. Мейнтейнеры советуют обновиться всем пользователям; в дистрибутивах смотрите на пакет libheif1 или libheif в вашем менеджере. Уязвимость средней важности в плагине WebCodecs касается только Emscripten-сборок с WITH_WEBCODECS=ON, по умолчанию выключенной опции, и только без libde265.

Отдельный отчёт о расходе ресурсов опубликован для Go-библиотеки Excelize: файл на 3 КБ заставляет библиотеку выполнять произвольное число итераций хеширования, и патча пока нет (исправление в сохранённом отчёте не указано). Из недавних выпусков безопасности того же масштаба мы разбирали curl 8.22.0 с девятью уязвимостями и внеочередные релизы PostgreSQL от Postgres Pro.

Источники: libheif v1.23.4 – security maintenance, release notes, GHSA-vg7w-rp49-4fc2: The max_items security limit is not enforced for iinf child boxes, GHSA-xrp2-63fq-jm8q: Unbounded iref entry list and unbounded recursion, GHSA-prgh-72vc-3xmc: Lock-order inversion in parallel grid tile decoding

Для владельца телевизора и администратора сети здесь два отдельных вопроса: какие сведения устройство собирает в обычной работе и что сможет сделать человек, получивший контроль над webOS. Авторы проверяли купленные в рознице телевизоры, включая LG G5, анализировали прошивку и снимали трафик через Wireshark. Результаты относятся к показанным моделям и настройкам: команда прямо говорит, что проверить все телевизоры и версии прошивок LG она не может.

• В опыте с LG G3 сканирование соседних устройств и обращения к рекламным сервисам наблюдались даже до принятия пользовательских соглашений.
• ACR распознаёт воспроизводимый контент по цифровым отпечаткам; в тесте G3 передача таких данных наблюдалась после принятия соглашений.
• Аппаратный выключатель встроенного микрофона не отключает микрофон пульта и подключённой USB-вебкамеры.
• Запись при тёмном экране и сохранение звука без сети продемонстрированы при полученном исследователями удалённом доступе.
• Подробности новых уязвимостей авторы ограничили на время ответственного раскрытия; их рекомендация состоит в отключении телевизора от сети.

Какие данные телевизор собирает в обычной работе?

По анализу трафика и прошивки, который приводят авторы, телевизоры способны определять внутренние IP-адреса соседних устройств, имена и уровень сигнала ближайших Wi-Fi-сетей, их каналы и сведения для определения местоположения. В локальной сети телевизор обнаруживал телефоны и умные часы сотрудников, а также компьютеры и принтеры. Авторы отдельно подчёркивают, что такое сканирование относится к штатным функциям и не требовало эксплуатации уязвимости.

В часовом захвате на LG G3 до принятия соглашений исследователи увидели подключения к восьми адресатам, включая рекламную платформу и платформу клиентских данных LG. Телевизор за это время отправил и получил около 8,9 МБ. Он использовался как экран для ноутбука по HDMI и продолжал искать устройства поблизости. Это суммарный сетевой обмен за конкретный час; объём переданных персональных данных из этой цифры определить нельзя.

В расследовании приводятся заявления LG Ad Solutions о работе с данными домохозяйств и охвате других устройств в них. Указанные в видео 363 млн вторичных адресуемых устройств в США и 216 млн проданных телевизоров в мире описывают разные категории и территории. Сами по себе эти числа не доказывают, что каждый телевизор передаёт полный перечень соседей. Авторы признают и ограничение захвата: часть обмена зашифрована, поэтому точный состав всех отправляемых сведений им неизвестен.

Как ACR связан с просмотром через HDMI?

ACR означает автоматическое распознавание контента. По объяснению исследователей, система преобразует фрагменты изображения и воспроизводимого звука в цифровой отпечаток и сопоставляет его с базами медиаконтента. Эти сведения используются рекламным подразделением LG Ad Solutions. Функция может работать и при использовании телевизора как монитора: внешний источник сигнала сам по себе не исключает распознавание показанного на экране.

Состояние соглашений существенно для результата. До их принятия на проверенном LG G3 авторы не наблюдали признаков сбора или передачи ACR-данных, хотя обращения к рекламным адресатам и сканирование сети продолжались. После принятия соглашений, всё ещё при показе изображения с ноутбука, они зафиксировали 44 подключения к Alfonso ACR с передачей 4 МБ. Так авторы разделяют распознавание контента и другую сетевую активность устройства.

Какие микрофоны остаются доступны после выключателя?

Выключатель на корпусе относится к встроенному микрофону. В видео при его отключении продолжает работать голосовой ввод с пульта по нажатию кнопки. Подключённая USB-вебкамера также имеет собственный микрофон, на который этот переключатель не распространяется. Наличие доступного источника звука само по себе не означает, что телевизор постоянно сохраняет разговоры.

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

Что показала запись после получения удалённого доступа?

Получив доступ к телевизору, команда записала звук и изображение с вебкамеры, когда экран выглядел выключенным. Это описание внешнего состояния экрана; из него нельзя сделать вывод о штатном режиме ожидания. В другом опыте на LG G5 исследователь начал запись с микрофона, отключил сеть, затем подключил её снова и скопировал сохранённый звук. В транскрипте прямо сказано, что запись сохраняет человек с удалённым доступом к телевизору. Автоматическая отправка таких записей производителю этим опытом не установлена.

Сетевое отключение в середине этого опыта не прекращало уже запущенную программу. После восстановления связи исследователи смогли забрать файл. Для оценки риска важна именно последовательность: сначала контроль над устройством, затем локальная запись без сети и последующее извлечение. Видео не показывает, что любой отключённый от интернета телевизор сам начинает записывать комнату.

Что исследователи извлекли из журналов голосового ввода?

Через доступ к системе авторы также прочитали текстовые расшифровки голосового ввода в локальных журналах. Они показали фразы, произнесённые после вызова голосовой функции, и отмечают, что в окно её активности могли попадать соседние разговоры. Здесь важно различать штатное преобразование речи в текст и возможность извлечь результат при доступе к системе. Эти журналы не служат доказательством круглосуточной записи всей речи вокруг телевизора.

У проверенного нового телевизора подробные журналы находились на диске в оперативной памяти. По словам авторов, команда удаления пользовательских данных и обычная перезагрузка не убрали показанные записи. Физическое отключение питания очистило именно эти журналы. Другие журналы оставались, и исследователи не проверили содержимое каждого из них. Поэтому видео не подтверждает ни бессрочное хранение всех расшифровок, ни полное удаление всех данных после отключения питания.

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

Что рекомендуют владельцам участники расследования?

Исследователи рекомендуют отключить умный телевизор LG от любой сети. Участник расследования из Level1Techs также советует обходиться без встроенных приложений. Подключение внешнего источника изображения по HDMI следует рассматривать отдельно от сетевого подключения самого телевизора: в опытах команды режим монитора при доступной сети не прекращал обращения к сервисам LG.

По словам Gamers Nexus, LG не ответила на направленные для этого расследования вопросы к моменту подготовки ролика. Проверяемым продолжением станут публикация технических описаний уязвимостей и сведения об исправлениях. До появления этих данных нельзя назвать по этому видео конкретную безопасную версию прошивки или распространить каждый показанный сценарий на всю линейку LG.

Источник: Gamers Nexus: расследование о сборе данных и уязвимостях телевизоров LG

Изображение на обложке: Кадр: Gamers Nexus

Что считается фактором

MFA объединяет несколько барьеров: цифровой (пароль/PIN-код), физический (токен или смартфон) и поведенческий или биометрический (отпечаток/лицо). Каждый следующий слой защищает там, где первый дал сбой — поэтому даже украденный пароль не делает учётную запись уязвимой.

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

2FA как самый распространённый вид MFA

Проверка занимает секунды: не нужно вводить длинные ключи подтверждения — достаточно получить SMS-код или push-уведомление и подтвердить его вместе с паролем. В этом и причина её популярности: быстро и удобно для рядового пользователя, а по уровню защиты схема не уступает более сложным вариантам с аппаратными ключами или отдельными приложениями. Отсюда и путаница в терминах — 2FA стало тем вариантом MFA, который встречается чаще прочих, а в разговоре эти два термина нередко используют как взаимозаменяемые. В русскоязычной среде это же часто обозначают как «2ФА».

Как это работает

Процесс простой, но при этом надёжный. Пользователь вводит логин и пароль. Затем система запрашивает второй фактор: это может быть одноразовый код из SMS, push-уведомление в приложении, сообщение в мессенджере, биометрическое подтверждение или аппаратный ключ. Доступ открывается только после успешной проверки обоих факторов.

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

Зачем это бизнесу

MFA добавляет второй барьер к паролю: если пароль украли при фишинге или утечке базы, для входа потребуется ещё код, аппаратный ключ или другое подтверждение. Проверку в первую очередь включают для удалённого доступа, корпоративной почты, облачных консолей и учётных записей администраторов. Способ подтверждения настраивают по ролям и подключают через SSO, VPN или отдельные приложения.

PCI DSS v4.0.1 напрямую устанавливает требования к MFA для доступа к среде карточных данных. GDPR и 152-ФЗ требуют применять меры защиты персональных данных с учётом рисков обработки. Конкретный набор мер зависит от системы и данных, поэтому MFA становится одним из способов защитить доступ.

Где применяют

MFA широко используется и в корпоративной, и в пользовательской среде. Компании применяют её для доступа к CRM, ERP и корпоративной почте — особенно если сотрудники работают удалённо. Банковские сервисы используют MFA для подтверждения операций и входа в личный кабинет. Разработчики защищают репозитории кода, CI/CD-системы и облачные консоли, снижая риск компрометации ключевой инфраструктуры.

На пользовательском уровне MFA применяется в соцсетях, почтовых сервисах, приложениях для хранения файлов и облачных платформах. Она помогает предотвратить взлом, даже если пароль стал известен злоумышленнику.

У Linx Cloud есть отдельный сервис MFA как услуга для защиты удалённого доступа — подходит для любого типа инфраструктуры, не только для облака Linx.

Итог

Многофакторная аутентификация давно перестала быть инструментом только для крупных корпораций — сегодня это доступная защита для бизнеса любого размера. А для компаний, работающих с платёжными данными, стандарт PCI DSS напрямую требует внедрения MFA. Для остальных это практичный инструмент, который дешевле внедрить заранее, чем восстанавливать инфраструктуру после инцидента.

Для разработчика это готовый способ прогнать свой репозиторий через тот же процесс, которым Google проверяет свои: нужен любой кодинг-агент со слэш-командами и изолированная среда, где не жалко ничего сломать. Сам Mantis не сканер и не сервис: это набор скиллов, скриптов и референсных компонентов под лицензией Apache-2.0, а модель и агент вы приносите свои.

• Mantis лежит на GitHub с июня 2026 года; 2 сентября Google выпустила гайд по запуску и представила скилл mantis-advise для безопасного написания нового кода.
• Конвейер состоит из 16 последовательных стадий плюс вспомогательные скиллы: от разбора истории коммитов и модели угроз до воспроизведения, патча и отчёта.
• Установка: git clone репозитория или npx skills add google/mantis; агент подойдёт любой, Google проверяла с Gemini CLI, Antigravity CLI и ADK.
• Воспроизведение и патчи выполняются только в песочнице без сети (gVisor с --network=none, microsandbox, VM); флаги вроде --yolo авторы прямо запрещают.
• Каждую находку должен подтвердить человек: README запрещает массово слать непроверенные ИИ-отчёты мейнтейнерам.

Что именно выложила Google и что в этом нового

Репозиторий google/mantis открыт не сегодня: первые коммиты датированы июнем 2026 года, и в заметке Google ссылается на июньское описание подхода. Новость в другом: компания впервые опубликовала пошаговый гайд «как начать», прямо заявила, что тот же промпт используется внутри Google для поиска реальных уязвимостей, и представила скилл mantis-advise, который появился в репозитории 28 августа. Последний коммит на момент публикации, от 3 сентября, ужесточает песочницы, разрешение путей и проверки конфигурации.

Главная претензия Google к «наивному» ИИ-сканированию кода, по словам авторов, в том, что доля настоящих находок у него часто ниже 7%, остальное галлюцинации. Mantis борется с этим двумя способами: отдельными агентами-критиками, которые отсеивают ложные срабатывания, и воспроизведением уязвимости в песочнице, которое служит опорой для оценки. При этом README оговаривает: неудачное автоматическое воспроизведение ещё не доказывает, что находка ложная. Цифра про 7% в заметке дана без ссылки на метод замера, так что это оценка компании, а не бенчмарк.

Вторая идея, на которую Google делает упор, это контекст. Mantis читает историю репозитория, чтобы выучить прошлые исправления безопасности, и сам строит документацию по архитектуре и модель угроз, даже если в проекте их нет. Файлы сворачиваются в иерархию сводок по каталогам, и по заявлению авторов такое дерево снижает накладные расходы на токены больше чем на 85% на больших репозиториях. Это тоже внутренний замер Google без описания выборки.

Как устроен конвейер из 16 стадий

По описанию архитектуры, Mantis состоит из отдельных скиллов, каждый из которых вызывается слэш-командой и передаёт результат следующему через файлы в каталоге workspace/. Стадии можно запускать по одной руками или отдать оркестратору /mantis-meta-agent, который крутит цикл и архивирует находки между проходами.

1. /mantis-history и /mantis-summarize разбирают историю VCS и пишут сводки по каталогам, а необязательный /mantis-structural-index строит индекс семантических единиц кода.
2. /mantis-architecture и /mantis-threat-model собирают базу знаний о сущностях, потоках данных и границах доверия.
3. /mantis-plan и /mantis-researcher составляют план проверки и ищут уязвимости файл за файлом.
4. /mantis-dedupe, /mantis-review и /mantis-critic склеивают дубли, отсеивают ложные срабатывания и проверяют, что падение воспроизводится в релизной сборке.
5. /mantis-reproduce пишет и запускает эксплойт в изолированной среде, /mantis-chain пробует собрать из находок многошаговую цепочку.
6. /mantis-patch чинит код и гоняет тесты в песочнице, /mantis-calibrate ставит риск от 1 до 10, /mantis-reflect и /mantis-report собирают уроки и итоговый отчёт.

Новый /mantis-advise стоит особняком: он не ищет уязвимости, а отвечает на вопрос «как безопасно менять этот файл». Скилл читает накопленную базу knowledge.db с моделью угроз, историей находок, подтверждёнными патчами и отсеянными ложными срабатываниями и выдаёт агенту рекомендации до и во время правок. Запускается он скриптом python3 reference/scripts/advise.py --file src/auth.py. Смысл в том, чтобы результаты аудита не лежали в отчёте, а мешали агенту повторять старые ошибки.

Как запустить у себя и почему только в изоляции

Установка по README сводится к клонированию репозитория или одной команде для менеджера скиллов:

Дальше Google предлагает открыть привычный кодинг-агент и написать ему буквально: «I would like to use Mantis framework in path/to/mantis to review my code in path/to/your/code, can you help me get started?». Конкретный агент не навязывается: в README сказано, что скиллы проверяли с Gemini CLI, Antigravity CLI, Google ADK и Antigravity SDK, но подойти должен любой фреймворк, понимающий слэш-команды и файлы SKILL.md. Модели тоже на выбор пользователя, причём авторы советуют не гонять самую дорогую модель на каждой стадии, а подбирать класс модели под задачу.

Самая жёсткая часть документации про изоляцию. README открывается предупреждением капслоком: конвейер генерирует и исполняет код, который может быть нестабильным, поэтому запускать его можно только в ограниченной среде, без доступа к продакшену, чувствительным данным и внутренней сети. Скиллы /mantis-reproduce и /mantis-patch по инструкции выполняют полезную нагрузку в контейнере с отключённой сетью, и для этого Google рекомендует gVisor:

Скилл /mantis-configure даёт выбор из четырёх режимов песочницы: static-only без исполнения кода, microsandbox, gvisor и gce с отдельной виртуальной машиной в облаке. Отдельно авторы просят начинать в интерактивном режиме, вызывая команды по одной и подтверждая каждое опасное действие, и не включать флаги автоодобрения вроде --yolo или --dangerously-skip-permissions. Гарантий при этом нет: в документации прямо сказано, что агент недетерминирован и может попытаться обойти ограничения, если среда это позволяет.

Что Mantis не обещает

Mantis не является поддерживаемым продуктом Google и подаётся как отправная точка, которую нужно дорабатывать под свой стек: авторы советуют скармливать конвейеру внутренние стандарты кода, документацию и критерии, какие баги вас не интересуют. Пример из заметки: если вы никогда не чините падения, которые пользователь может вызвать только у себя, об этом нужно сказать сканеру заранее, иначе он будет тратить время именно на них.

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

Проект лежит в публичном репозитории на GitHub под Apache-2.0, региональная доступность отдельно нигде не оговорена, а модель и агент вы выбираете сами, в том числе локальные. Дальше стоит следить за тем, появятся ли независимые замеры доли ложных срабатываний: пока и 7%, и 85% экономии токенов остаются цифрами самой Google.

Источники: Getting started with Mantis, our open-source bug finding-and-fixing harness (Google Cloud Blog), Репозиторий google/mantis, README_AGENTS.md: архитектура конвейера Mantis, Скилл mantis-advise

Изображение на обложке: Изображение: Google Cloud

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

Оговорка стоит в самом README: это референсная реализация, она не поддерживается и не принимает внешний вклад. В примерах нет аутентификации, MCP-серверы по умолчанию слушают loopback.

• Два агента, три способа запуска (Messages API, Claude Agent SDK, Managed Agents (beta)), четыре вертикали и восемь веб-приложений в одном репозитории под Apache 2.0.
• Не оформляет заказ, не списывает деньги и не меняет живые листинги: checkout только рисует корзину, каждая запись мерчанта ждёт одобрения человека.
• Проверки provenance, лимиты, ограждение стороннего текста и валидация памяти работают внутри вызова инструмента и держатся на всех трёх путях запуска.
• Своя интеграция сводится к реализации StorefrontBackend или MerchantBackend; отсутствующие системы выключаются переключателями enable_*.
• Модели по умолчанию: claude-sonnet-5 у покупательского агента, claude-opus-5 у мерчантского, claude-haiku-4-5-20251001 для памяти; рантаймы работают через Vertex AI, Bedrock, Microsoft Foundry и шлюзы.
• Требования: Python 3.11 и новее, Node 22. Демо поднимается шестью командами из README.

Один агент описан один раз и работает на трёх рантаймах

Главная архитектурная идея репозитория, как её формулирует README: каждый агент определён один раз (промпт, скиллы, контракты инструментов, гейты) и запускается на Messages API, на Claude Agent SDK и на Managed Agents. Четыре вертикали работают поверх одних библиотек и различаются бэкендом и доменными расширениями интерфейса.

Покупательский агент ищет и сравнивает товары, собирает планы покупок, наполняет корзину, отвечает на вопросы о заказах и правилах магазина и запоминает, что покупатель о себе рассказал. Его пять сценариев лежат как skills в каталоге shopping-agent/skills. Мерчантский агент объясняет показатели, правит листинги, реагирует на алерты по остаткам и заказам, назначает цены и промо, готовит кампании. Его пять сценариев лежат в merchant-agent/skills. Любая запись мерчанта становится staged change, которую применяет уже интерфейс одобрения на стороне хоста.

Nothing places an order, charges a card, or changes a live listing: checkout renders the cart for the host to complete, and every merchant write is staged until a person approves it.

Код разложен на семь pip-пакетов. Общее для обеих ролей вынесено в commerce-common: конфиг, ограждение стороннего текста, память, скиллы, grounding, презентационные компоненты, исполнитель инструментов и события. У каждой роли три пакета: core с типами, интерфейсом бэкенда, промптом, контрактами инструментов и гейтами; runtime с циклом ходов на Messages API; sdk с тем же агентом на Agent SDK и консолью. CI проверяет, что имена семи пакетов остаются незарегистрированными в публичном индексе, а pin-файлы ставят их из каталогов репозитория.

Эталонный путь запуска, вокруг которого построены примеры, это Messages API. Хост создаёт объект агента с бэкендом, каталогом скиллов и конфигом и стримит события хода; извлечение памяти вызывается отдельно после хода, и только на этом пути. Код из README:

На Agent SDK тот же промпт, скиллы и инструменты, но цикл ведёт SDK: хост заранее подгружает данные для grounding, после хода ничего не выполняется. На Managed Agents агент размещён у Anthropic и ходит за данными в ваш MCP-сервер; деплой делает скрипт scripts/deploy_managed_agent.sh, без флага --live это сухой прогон. Различия трёх путей по docs/safety.md:

• Messages API. Все правила grounding включаются принудительно через tool_choice; работают извлечение памяти после хода, сжатие истории и бюджеты аналитического делегата мерчанта.
• Agent SDK. Grounding только для правил с формой предварительной загрузки; цикл ограничен max_turns; аналитика мерчанта идёт субагентом без SQL-инструмента и бюджетов; память хост извлекает сам.
• Managed Agents. Grounding отсутствует, циклом владеет платформа, память пишется только через save_memory, одобрением staged change служит промпт always_ask на apply_change.

Проверки стоят внутри вызова инструмента, поэтому переживают смену рантайма

Документ docs/safety.md делит правила на три группы: что код проверяет сам, что по-прежнему просят у модели промптом и что обязан добавить деплой. Ключевой приём: правило внутри вызова инструмента держится на всех трёх путях, потому что все три прогоняют вызовы через один исполнитель в модуле commerce_common/execution.py. Правило на уровне хода живёт в конкретном рантайме, и таблица указывает, где оно не работает.

A rule enforced inside a tool call holds on all three paths, because the Messages API runtime, the SDK toolset, and the MCP server execute tools through the same executor.

Что именно проверяется в коде, по таблице документа:

• Ограждение (fencing). Сторонний текст очищается, оборачивается в ограждение с фиксированной меткой и обрезается до max_fenced_chars. Очистка убирает невидимые и управляющие символы, поддельные маркеры ходов, теги транскрипта и вызовов инструментов и копии самого маркера ограждения.
• Лимиты цикла. Запрошенное моделью число результатов поиска обрезается до max_search_results; после max_tool_iterations раундов рантайм Messages API принудительно делает ход без инструментов.
• Provenance корзины. В корзину попадают только идентификаторы товаров, которые в этой сессии вернул инструмент каталога или заказов. Попытка добавить товар с опциями (размер, цвет) задерживается, и модели показывают варианты. Действует лимит на позицию и на число строк.
• Нет оплаты. У StorefrontBackend нет метода, который размещает заказ или списывает деньги. URL размещённого checkout приходит из checkout_handoff после вызова модели и не проходит через неё.
• Provenance staged-записей мерчанта. Изменение принимает только идентификаторы листингов и кампаний, возвращённые инструментом в этой сессии; правка контента требует чтения get_listing. apply_change принимает только идентификаторы изменений, которые вернули staging или get_pending_changes.
• Guardrails мерчанта. Проверяются при постановке изменения и повторно при применении: число позиций, размах изменения цены, глубина промо, размер пополнения, бюджет кампании, защищённые поля.
• Одобрение хостом. При require_host_approval (включено по умолчанию) apply_change проходит только для идентификаторов, которые хост пометил одобренными. Карточка предпросмотра ничего не одобряет, «да, применяй» в чате тоже.
• Память. Ключ факта до 64 символов, значение до 200, одна из трёх категорий; значения, похожие на идентификаторы, отбрасываются. Извлечение читает только текст последнего обмена, никогда результаты инструментов.
• Поверхность инструментов и идентичность. Список инструментов вычисляется из конфига деплоя, исполнитель отказывает любому другому имени. Идентичность держит сервер: ни один аргумент инструмента не называет пользователя или мерчанта.

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

When the model breaks one of these, the error is confined to its text. Every write, figure, and disclosure behind that text still passed the checks in the table above, so the failure is a misstatement to correct and no action needs reversing.

Третья группа целиком на стороне деплоя: аутентификация и авторизация на каждом маршруте и на MCP-серверах (примеры принимают любого вызывающего), учётные данные для вызова ваших сервисов, лимиты запросов, бизнес-правила (фрод, право на покупку, цены, остатки), оплата после checkout, обращение с памятью как с персональными данными, гигиена логов и сама поверхность одобрения. Значения guardrails в двух файлах config.py названы демонстрационными.

Своя интеграция сводится к двум интерфейсам и переключателям enable_*

Точка входа для собственных систем описана в docs/backends.md. Деплой реализует StorefrontBackend поверх каталога, корзины, заказов и политик или MerchantBackend поверх аналитики, каталога, остатков, цен и кампаний. Контрактом служат докстринги методов в backend.py и types.py каждой роли. Каждый метод вызывает ваш сервис на стороне сервера с учётными данными, которые хост хранит для сессии; модель видит только результат.

Each one calls your service server-side with the credential your host holds for the session; the model reads only the result.

Документ раскладывает интеграцию на шесть шагов. Первый: решить, кто вызывающий. Хост аутентифицирует человека и стартует сессию с принципалом; токен покупателя живёт в контексте сессии, сервисная учётка передаётся в конструктор бэкенда. Гость тоже принципал: чтение, которому нужен аккаунт, бросает исключение, которое подкласс исполнителя превращает в просьбу войти. Второй: порядок многошаговых сценариев (удержать места, затем подтвердить) хранится и проверяется в бэкенде, а нарушение маппится через domain_error в понятный модели результат. Третий: как завершается checkout. Вариантов три: ссылка на маршрут в вашем приложении, размещённый checkout платформы, для которого checkout_handoff возвращает URL, или маркетплейс с записью на каждого продавца.

Четвёртый шаг: товары с опциями. Запись бывает простой, семейством (с полем options) или вариантом (с option_values и variant_of); идентификатор варианта идёт всюду, где ждут идентификатор товара. Детали товара возвращают все варианты семейства в одном ограждении, обрезанном до max_fenced_chars (12 000 символов по умолчанию). Компактная строка варианта занимает 70–120 символов, так что в семейство помещается около шестидесяти вариантов; кроссовки в восьми цветах и четырнадцати размерах документация советует подавать как восемь семейств по четырнадцать, потому что за пределами лимита результат режется без ошибки. Пятый: записи мерчанта по семействам, где изменение цены и пополнение именуют вариант. Шестой: для цифр, которых у платформы нет, возвращать None с пометкой, а не подставной ноль.

Для пилота README предлагает начинать с малого. Покупательский пилот реализует поиск и карточку товара, а остальное заглушает: метод-заглушка возвращает результат «недоступно» и не меняет ни байта промпта. Мерчантский пилот реализует восемь методов чтения, записи отказывают. Система, которой у бизнеса нет совсем, выключается переключателем enable_*: это убирает её инструменты, строки промпта и правило grounding на всех трёх путях, а сценарии, которым она нужна, паркуются в каталоге skills/_staged/. Свой сценарий добавляется каталогом с файлом SKILL.md, доменный интерфейс расширением PresentationExtension (вертикали поставляют семь), а brand_name, assistant_name и brand_voice в конфиге задают личность ассистента.

Модели заданы строкой в конфиге, а переключение платформы сосредоточено в одном месте и зависит от рантайма

По docs/deployment.md код по умолчанию ходит в API Anthropic, но у каждого пути есть одно место, где деплой переключает платформу. Рантаймы Messages API принимают любой асинхронный клиент из пакета anthropic аргументом client=: AsyncAnthropicVertex для GCP Vertex AI, AsyncAnthropicBedrockMantle или AsyncAnthropicBedrock для AWS, AsyncAnthropicFoundry для Microsoft Foundry, AsyncAnthropic с base_url и auth_token для собственного шлюза. Пакеты требуют anthropic 0.91 и новее. Рантаймы Agent SDK HTTP-клиента не создают: платформу выбирает CLI Claude Code по переменным окружения, которые добавляются в options.env. Managed Agents работает на инфраструктуре Anthropic, поэтому у него нет варианта для Vertex, Bedrock и Foundry.

Модель задаётся строкой в конфиге: поля model и memory_model у каждой роли, у мерчанта ещё analysis_model. Значения по умолчанию, по таблице документа: claude-sonnet-5 для покупательского агента, claude-opus-5 для мерчантского, claude-haiku-4-5-20251001 для извлечения памяти. Грамматика идентификаторов у платформ разная: Vertex пишет датированные снимки через @, Bedrock через Mantle берёт идентификаторы с префиксом anthropic., а через Invoke API идентификаторы inference-профилей. Все три поля идут через один клиент, поэтому все три модели должны существовать на целевой платформе. Живого разговора с облаком в CI нет; документ просит прогнать его на своей платформе до того, как на неё полагаться.

Доступность API Anthropic и облачных платформ для конкретной страны или способа оплаты в документации репозитория не обсуждается. Для собственного шлюза документ называет требование: отдавать /v1/messages со стримингом SSE для Messages API, а для Managed Agents ещё проксировать /v1/skills, /v1/agents, /v1/environments, /v1/sessions и поток событий сессии с заголовками anthropic-beta.

Демо поднимается шестью командами, а плагин Claude Code собирает агента под ваш стек

Порядок запуска из README (нужны Python 3.11 и новее и Node 22, ключ ANTHROPIC_API_KEY в файле .env):

Флаг --merchant поднимает портал мерчанта вместо витрины, --all оба. В README каждой вертикали есть раздел Try с репликами, которые прогоняет scripts/smoke_chat.py. Розничная ACME показывает поиск, сравнение, корзину, checkout и память; ACME Travel добавляет инвентарь с датами; ACME Mobile матрицу тарифов и серверные раскрытия комиссий; ACME Tickets таймированные удержания мест, листы ожидания и карту зала.

Второй способ начать: плагин commerce-builder для Claude Code. Он читает клонированный репозиторий как эталон и собирает агента на этих пакетах против ваших систем либо проверяет уже написанного. Установка и первая команда из README:

Команда /scaffold-commerce-agent спрашивает о стеке, проговаривает план и строит проект. Дальше /add-commerce-flow добавляет сценарий, /author-commerce-evals пишет evals, /review-commerce-agent начинает с уже существующего агента. Собственных MCP-коннекторов в поставке нет: оба агента ходят в системы через интерфейсы бэкенда. Где официальный коннектор является источником истины (Snowflake, BigQuery, Stripe, Square, Slack и другие в списке README), он и становится целью интеграции. MCP-сервер торговой платформы вызывается из метода бэкенда на сервере, и гейты provenance остаются перед каждой записью.

Проверка после правок: ruff check и ruff format --check, pytest, python scripts/check.py; python scripts/verify_all.py добавляет сухие прогоны деплоя и сборку веб-приложений; python scripts/smoke_chat.py --vertical travel проводит один живой разговор и требует ключ. Чтобы убедиться, что кэширование промпта работает, README советует читать cache_read_input_tokens из события turn_complete: ноль на втором ходу означает, что префикс промпта изменился.

Что делать команде, которая пишет ассистента для магазина

1. Поднять розничное демо по шести командам выше (Python 3.11 и новее, Node 22, ключ API) и пройти реплики из раздела Try в examples/retail/ на витрине (порт 3000) и в портале мерчанта (флаг --merchant, порт 3100).
2. Сверить таблицу «Enforced in code» и список «What a deployment owns» из docs/safety.md с собственной платформой: аутентификация, учётные данные, лимиты запросов, бизнес-правила, оплата, персональные данные в памяти, логи.
3. Для пилота реализовать в StorefrontBackend только поиск и карточку товара, для MerchantBackend восемь методов чтения. Отсутствующие системы выключить через enable_*, зависимые сценарии убрать в skills/_staged/.
4. Разложить каталог по трём формам записи из docs/backends.md и проверить самое большое семейство против лимита max_fenced_chars в 12 000 символов.
5. Выбрать завершение checkout: свой маршрут, размещённый URL платформы через checkout_handoff или ссылка на продавца для маркетплейса; оплата остаётся в хосте.
6. Для Vertex AI, Bedrock, Foundry или шлюза передать клиент аргументом client= (anthropic 0.91 и новее) или переменные CLI в options.env и заменить все три идентификатора моделей.
7. Перед выкладкой прогнать ruff, pytest, scripts/check.py и scripts/verify_all.py, затем один живой разговор scripts/smoke_chat.py на своей платформе; при смене модели перегнать evals по разделу «Still asked of the model».

Репозиторий создан 1 сентября, анонс в аккаунте Claude Developers вышел 2 сентября в 19:33 UTC. На 3 сентября, 01:53 мск, по данным GitHub API у проекта 277 звёзд и 46 форков. Поддержки и приёма внешних изменений Anthropic не обещает: «This is a reference implementation; it is not maintained and does not accept contributions», говорится в README. На практике это значит, что исправления и адаптацию под свои системы команде придётся вести в собственном форке, а промпты и гейты под новые модели проверять своими evals. Цен, лимитов и сроков дальнейшего развития Anthropic в репозитории не называет.

Источники: Claude Developers в X: анонс открытия Claude Commerce Agents (2 сентября 2026), GitHub: anthropics/commerce-agents, README репозитория commerce-agents, docs/safety.md: правила, проверяемые кодом, и обязанности деплоя, docs/backends.md: подключение своих систем, docs/deployment.md: Vertex AI, Bedrock, Microsoft Foundry и шлюзы, Плагин commerce-builder для Claude Code, Скиллы покупательского агента, Скиллы мерчантского агента

Изображение на обложке: Anthropic, кадр из анонса Claude Commerce Agents

Для разработчика это удобный способ проверить, помечает ли Claude свои файлы на практике, и заодно понять, на что такая проверка годится. Коротко: она находит метку стандарта C2PA, которую Claude вшивает в сгенерированные файлы, и ничего больше. Если метки нет, это не значит, что файл сделан человеком: по словам самой Anthropic, метка может пропасть при пересохранении, конвертации, сжатии в мессенджере или скриншоте.

• Сервис принимает JPG, PNG, GIF, WEBP, TIFF, HEIC, AVIF, SVG, DNG, JXL, MP4, MOV, AVI, WAV, MP3, M4A и FLAC размером до 100 МБ.
• Проверка идёт локально в браузере: по словам Anthropic, файл не покидает устройство, не сохраняется и читаются только метаданные.
• Ищется только подписанная метка C2PA от Claude; результат не говорит ни о содержании файла, ни о том, кто его загружал.
• Отсутствие метки ничего не доказывает: она пропадает при удалении метаданных, а поддерживают её пока только Fable 5.1 и Mythos 5.1.
• Текстовые водяные знаки этот сервис не проверяет: для них есть отдельный Detection API в закрытом превью для организаций по требованию закона ЕС.

Что именно проверяет сервис

По описанию на странице, Claude помечает свой вывод двумя способами. Текст получает водяной знак в самих формулировках: он невидим, переживает копирование и часть правок. Файлы получают content credential, подписанные метаданные о происхождении, которые прикрепляются при скачивании, например к диаграмме, которую построил Claude. Формат метаданных задаёт открытый стандарт C2PA (Coalition for Content Provenance and Authenticity), тот же, что используют производители камер и фоторедакторы для записи истории снимка; прочитать такую запись может любой инструмент с поддержкой C2PA.

Check Content работает только со вторым типом меток. Он читает метаданные файла, ищет подписанную запись и, если та указывает на Claude, сообщает об этом. Anthropic отдельно оговаривает: инструмент показывает, что Claude участвовал в производстве файла, но не может сказать, участвовал ли он в создании содержимого, и не раскрывает никаких сведений о пользователе, который этот файл сгенерировал.

Технически всё происходит на стороне клиента: страница обещает, что файл остаётся на устройстве, никуда не загружается и не используется ни для каких других целей. Список форматов широкий, от JPG и SVG до MP4, WAV и FLAC, лимит 100 МБ. Сам процесс занимает секунды: перетащили файл, получили ответ «метка найдена» или «не найдена».

Почему появилась метка и какие модели её ставят

Причина не в моде на прозрачность, а в законе. В справочной статье Anthropic пишет, что подписала кодекс практики к статье 50(2) AI Act ЕС о прозрачности ИИ-контента, и обязалась машиночитаемо помечать вывод моделей Claude, запущенных в ЕС 2 августа 2026 года или позже. Компания обещает применять метки везде, где доступен Claude, а не только в Европе: в API, приложении, Claude Code и Cowork. Через облачных партнёров AWS, Google Cloud и Microsoft Foundry текстовые водяные знаки идут всегда, а файловые метки только там, где платформа даёт генерацию файлов Claude.

Сейчас метки ставят Fable 5.1 и Mythos 5.1; для моделей, вышедших до 2 августа, действует переходный период, и поддержку им ещё добавляют. Отсюда практическое следствие: файл от Opus 5 или старой Sonnet сервис не распознает, и это штатное поведение, а не сбой.

Текстовые водяные знаки проверяются иначе. Для них Anthropic держит Detection API в закрытом превью и выдаёт доступ организациям, которым это положено по закону ЕС: регуляторам, правоохранителям, СМИ, фактчекерам, исследователям, образовательным организациям, а также компаниям, обязанным проверять маркировку для собственного соответствия AI Act. Расширять доступ обещают «со временем», сроков нет.

Чего проверка не доказывает

Anthropic сама перечисляет ограничения, и их стоит держать в голове, прежде чем ссылаться на результат в споре. Найденная метка означает, что файл «мог быть обработан Claude»: она не описывает полную историю файла и не говорит, что именно сделал Claude, отредактировал картинку или нарисовал её с нуля. Отсутствие метки не означает, что ИИ не участвовал: подпись живёт в метаданных, а они, по словам Anthropic, могут пропасть при пересохранении, конвертации, публикации в соцсети или обычном скриншоте.

Есть и обратная сторона. Метка проверяет только «участвовал ли Claude», поэтому для картинки от другой модели ответ будет отрицательным, хотя содержимое сгенерировано. Похожие проверки, по словам Anthropic, есть у OpenAI и Google; универсального детектора, который читает подписи всех вендоров, страница не обещает. Отдельные C2PA-читалки, например от самой коалиции C2PA, покажут запись любого подписанта, но и они бессильны против вырезанных метаданных.

Что делать разработчику

• Если вы встраиваете генерацию картинок через Claude в свой продукт, проверьте, доходит ли метка до пользователя: ваш пайплайн (ресайз, конвертация, CDN) может её вырезать. Один прогон через Check Content на выходном файле покажет это за секунды.
• Если вам нужно, наоборот, не раскрывать инструмент генерации, помните, что метка есть в файлах от Fable 5.1 и Mythos 5.1 и что она не содержит данных о пользователе.
• Не используйте отрицательный результат как доказательство «сделано человеком»: Anthropic прямо говорит, что это не так.
• Для проверки текста сервис не подходит: пишите заявку на Detection API, если ваша организация подпадает под критерии.

Дата запуска на самой странице не указана, changelog Anthropic об инструменте не сообщает. О региональных ограничениях для проверки файлов Anthropic не пишет. Следующий шаг, за которым стоит следить, это добавление меток в старые модели и расширение доступа к Detection API, о котором компания обещает сообщить в той же справочной статье.

Источники: Claude: Check if a file was made with Claude, Anthropic Help Center: How Claude marks AI-generated content, Обсуждение на Hacker News

Изображение на обложке: Скриншот: claude.com

Для разработчика главное в анонсе одно число: по таблице Google, на DeepSWE v1.1, бенчмарке долгих задач по программной инженерии, 3.8 Flash набирает 73,7% против 74,0% у Claude Opus 5, который стоит в 6,7 раза дороже на входе и в 6,7 раза дороже на выходе. Если замер подтвердится независимо, дешёвая модель Google становится кандидатом на роль основной модели для кодовых агентов. Все цифры ниже опубликованы Google: часть из них снята на внешних бенчмарках (DeepSWE ведёт Datacurve AI, CWE-Bench проводит Collinear), часть на внутренних наборах компании; ссылку на методику Google приводит, независимых результатов на момент публикации нет.

• Gemini 3.8 Flash доступна со 2 сентября в Gemini API, Google AI Studio, Android Studio, Antigravity и Stitch; подписчикам Google AI Pro и Ultra в приложении Gemini, AI Mode в поиске и Google Sheets.
• Цена $0,75 за 1 млн входных и $3,75 за 1 млн выходных токенов действует до 31 декабря 2026 года; с 1 января 2027 года Google обещает $1,50 и $7,50.
• По замерам Google: DeepSWE v1.1 73,7% (Opus 5 74,0%, GPT-5.6 Sol 72,7%, 3.7 Flash 65,3%), Terminal-Bench 2.1 89,4%, HLE-Verified 54,9%; на Terminal-Bench 4.0 всего 19,1% против 51,8% у Opus 5.
• Gemini 3.8 Flash Cyber на CyberGym показывает 86,2% pass@1 против 83,8% у Mythos 5 и 85,6% у GPT-5.5-Cyber; на CWE-Bench 47,2% при 47,8% у Claude Fable 5.
• Модель «работает усерднее»: делает больше шагов рассуждения и вызовов инструментов, поэтому тратит больше токенов; 3.7 Flash остаётся поддерживаемой для экономных сценариев.

Что изменилось по сравнению с 3.7 Flash

Gemini 3.7 Flash вышла три недели назад, и 3.8 Flash построена на той же скорости и цене. Прирост Google показывает на длинных агентных задачах. На DeepSWE v1.1 результат вырос с 65,3% до 73,7%, на Terminal-Bench 2.1, где агент решает задачи в терминале, с 85,8% до 89,4%. По этой таблице 3.8 Flash опережает GPT-5.6 Sol (72,7% и 88,8%) и почти сравнивается с Claude Opus 5 (74,0% и 89,1%).

На прикладных бенчмарках Google выделяет области, где 3.8 Flash обходит и более дорогие модели: Vals Finance Agent v2 (задачи финансового аналитика) 61,4% против 58,6% у Opus 5, Harvey's Legal Agent Benchmark (юридические сценарии) 10,0% против 6,7%, CharXiv Reasoning (выводы по сложным графикам) 86,2% против 83,7%. На HLE-Verified, наборе экспертных вопросов из разных дисциплин, модель набирает 54,9%, на уровне Opus 5 (54,4%) и GPT-5.6 Sol (54,5%).

Слабые места в той же таблице Google не скрывает. На Terminal-Bench 4.0, который проверяет общие агентные способности, 3.8 Flash набирает 19,1% против 51,8% у Opus 5 и 37,3% у GPT-5.6 Sol. На GDPVal-AA v2 (офисная работа, рейтинг Эло) у неё 1545 против 1824 у Opus 5 и 1710 у Sol, на OSWorld-2.0 (управление компьютером) 59,0% против 75,4%. Иначе говоря, модель сильна там, где задача формализована, и заметно отстаёт в открытых сценариях.

Google объясняет прирост тем, что 3.8 Flash «работает усерднее»: на сложных задачах делает больше шагов рассуждения и итеративно вызывает инструменты. Компания прямо предупреждает, что модель может потратить больше токенов, особенно на высоких уровнях усилия. Для задач, где главное ограничение стоимость, Google предлагает снижать уровень усилия или оставаться на 3.7 Flash, которая продолжает поддерживаться.

Цена прежняя, но с 2027 года удвоится

Вводная цена $0,75 за миллион входных токенов и $3,75 за миллион выходных совпадает с 3.7 Flash и действует до 31 декабря 2026 года. С 1 января 2027 года, по сноске в анонсе, вступает в силу регулярная цена: $1,50 и $7,50. Для сравнения, в той же таблице Google указывает $5,00 и $25,00 у Claude Opus 5, $2,00 и $10,00 у Claude Sonnet 5, $4,00 и $20,00 у GPT-5.6 Sol. Даже по регулярной цене 3.8 Flash останется дешевле Sonnet 5 на входе и выходе.

Модель доступна разработчикам через Gemini API в Google AI Studio и Android Studio, в агентной среде Antigravity и генераторе интерфейсов Stitch, корпоративным клиентам в Gemini Enterprise, подписчикам Google AI Pro и Ultra в приложении Gemini, AI Mode в поиске и Google Sheets. О региональных ограничениях и условиях оплаты в анонсе ничего не сказано.

Flash Cyber: поиск уязвимостей на уровне фронтира, но только по заявке

Вторая модель анонса, Gemini 3.8 Flash Cyber, построена на том же ядре, но с более мягкими ограничениями в области кибербезопасности. Именно поэтому Google не выкладывает её в общий API: доступ получают государственные органы, операторы критической инфраструктуры и мейнтейнеры ПО через программу Fairwind, заявку нужно подать отдельно. Google подчёркивает, что приоритетом было исправление уязвимостей, а не эксплуатация.

На CyberGym, отраслевом бенчмарке автономного поиска уязвимостей в коде на C и C++, 3.8 Flash Cyber набирает 86,2% pass@1. Предыдущая киберверсия 3.5 Flash Cyber давала 77,5%, GPT-5.6 Sol 83,6%, Anthropic Mythos 5 83,8%, GPT-5.5-Cyber 85,6%. На внутреннем наборе Google, где надо находить уязвимости в сложных кодовых базах на 20 языках программирования, доля успеха, по словам компании, превысила 70%; состав и размер этого набора не раскрыты.

За исправление отвечает внешний бенчмарк CWE-Bench от компании Collinear: 47,2% pass@1 у 3.8 Flash Cyber против 47,8% у Claude Fable 5, при этом, по графику Google, прогон Flash Cyber стоит около $3,6 против более $10 у Fable 5. Google приводит и три внутренних примера: команда безопасности Chrome получила от модели в 2,6 раза больше корректных патчей к уязвимостям Chrome, чем от «лучших коммерческих моделей», компания Wiz на своём наборе для пентеста увидела рост полноты на 7,5–9,7 процентных пункта при стоимости в 2,3–5,2 раза ниже, а команда Cloud Vulnerability Research нашла критическую уязвимость меньше чем за два часа. Ни одно из этих утверждений пока не проверено вне Google и партнёров.

Что делать разработчику

• Если вы уже используете 3.7 Flash в агентах для кода, попробуйте 3.8 Flash на своих задачах и сравните не только точность, но и расход токенов: Google предупреждает, что модель думает дольше.
• Считайте стоимость по регулярной цене $1,50 и $7,50: через четыре месяца именно она станет реальной.
• Для коротких и дешёвых запросов оставайтесь на 3.7 Flash или снижайте уровень усилия у 3.8, это рекомендация самой Google.
• Flash Cyber сейчас в общем API не представлена: если вам нужен поиск уязвимостей, ориентируйтесь на заявку в Fairwind или на обычную 3.8 Flash, которая, по словам Google, тоже обучалась на задачах кибербезопасности, но с ограничениями на наступательные сценарии.

Google публикует ссылки на методику замеров, но сравнения с конкурентами пока остаются её собственными; редакция вернётся к цифрам, когда появятся независимые результаты. Отдельный вопрос, ответа на который в анонсе нет: сколько токенов 3.8 Flash реально тратит на тех же задачах по сравнению с 3.7, ведь при удвоенной цене с января это определит, останется ли она самой выгодной.

Источники: Google: Introducing Gemini 3.8 Flash and 3.8 Flash Cyber, Google DeepMind: методика замеров Gemini 3.8 Flash, Google DeepMind: методика замеров Gemini 3.8 Flash Cyber

Изображение на обложке: Изображение: Google

Для тех, кто просто обновляет curl, ничего не меняется: все шесть находок имеют низкую серьёзность и уже исправлены в 8.22.0. Интересна сама ситуация: curl стоит, по оценке AISLE, более чем в 20 млрд установленных экземпляров, и это одна из самых проверенных кодовых баз в мире. AISLE подаёт результат как подтверждение своего тезиса «система важнее модели»: специализированная обвязка находит дыры там, где фронтирные модели уже остановились. Насколько сопоставимы были условия запуска, из материала не следует.

• 24 августа Стенберг написал, что к релизу готовы три CVE, а Mythos, Zeropath и Codex Security «больше ничего не находят».
• 25 августа он же опубликовал счёт «Mythos: 0 Aisle: 29»: AISLE прислала 29 отчётов.
• Шесть из них команда безопасности curl признала уязвимостями и выдала CVE; все шесть низкой серьёзности, исправлены в curl 8.22.0 от 2 сентября (всего в релизе девять CVE curl и одна в wcurl).
• К 28 августа число ожидающих CVE выросло с трёх до десяти; шесть из десяти — от AISLE.
• AISLE утверждает, что тот же эффект в ядре Linux заметил мейнтейнер стабильных веток Грег Кроа-Хартман; независимого подтверждения этой цитаты у редакции нет.

Как за четыре дня три CVE превратились в десять

Хронология собрана по публичным записям Стенберга в Mastodon. 24 августа он написал, что до релиза девять дней и объявлять предстоит всего три CVE (две низкой серьёзности, одна средней), добавив в скобках: «Mythos говорит, что больше ничего не находит. Zeropath не находит уязвимостей. Codex security показывает пустой список» (перевод редакции). Zeropath здесь — ещё один коммерческий ИИ-сканер кода.

По словам AISLE, после этой записи компания запустила свою систему на curl. 25 августа Стенберг опубликовал короткий пост: «Mythos: 0 Aisle: 29». Это число отчётов, а не подтверждённых уязвимостей: часть из 29 могла оказаться ложными срабатываниями или проблемами без последствий для безопасности, и решение принимала команда curl, а не AISLE. 28 августа Стенберг сообщил уже о десяти ожидающих CVE, одна из которых относится к обёртке wcurl.

В итоговом релизе 8.22.0, вышедшем 2 сентября, шесть из девяти CVE curl в таблице уязвимостей curl числятся за Станиславом Фортом из AISLE. По данным компании, три отчёта были отправлены 24 августа, два 26 августа и один 27 августа.

Что именно нашли: шесть дыр в узких конфигурациях

Все шесть находок оценены проектом как низкие по серьёзности. Они затрагивают не типичный вызов «скачать файл по HTTPS», а стыки между библиотекой и TLS-бэкендами, кэшами сертификатов и обработкой кук:

• CVE-2026-80229: use-after-free при работе с провайдерами OpenSSL; затронуты версии с 8.14.0 по 8.21.0.
• CVE-2026-80230: обход пиннинга сертификата в сборках с OpenSSL; версии с 7.45.0 по 8.21.0.
• CVE-2026-80231: повторное использование соединения при смене настройки системного хранилища сертификатов (CURLSSLOPT_NATIVE_CA) между запросами; версии с 7.71.0 по 8.21.0.
• CVE-2026-80255: обход атрибута secure у куки с помощью символа табуляции; версии с 8.13.0 по 8.21.0.
• CVE-2026-82208: в сборках с wolfSSL попадание в кэш CA перекрывало пользовательский callback проверки; версии с 8.9.1 по 8.21.0.
• CVE-2026-82209: кука, ограниченная доменом из публичного списка суффиксов, принималась не так, как должна; версии с 7.46.0 по 8.21.0.

Сама AISLE объясняет низкую серьёзность зрелостью curl: то, что в нём ещё осталось, прячется в редких сочетаниях опций и бэкендов, и практическое влияние таких дыр ограничено. Это честная оговорка, и её стоит помнить при чтении заголовка «6 : 0». В advisory проекта все шесть помечены как низкие; они закрываются обычным обновлением до 8.22.0, о котором Tproger писал ранее.

Почему это сравнение чище обычных бенчмарков

Обычно результаты ИИ-сканеров показывают на CTF-задачах или наборах с известными ответами, которые могли попасть в обучающие данные. Здесь всё иначе: анализировался живой продакшен-код, а признавали ли находку уязвимостью и давать ли ей CVE, решали мейнтейнеры curl. Базовая линия тоже была публичной и датированной заранее: «ноль» у Mythos и Codex Security Стенберг написал до того, как AISLE запустила свою проверку. AISLE прямо оговаривает, что CVE как метрика несовершенна, но для поиска нулевых дней это редкий случай внешней валидации: каждая CVE подтверждена экспертами и исправлена для реальных пользователей.

При этом источник заинтересованный: AISLE продаёт аудит кода и в конце своего же отчёта предлагает услугу AISLE Snapshot. Компания также приводит ответ Грега Кроа-Хартмана, мейнтейнера стабильных веток ядра Linux, на запись Стенберга: он якобы видит ту же картину для Linux и не понимает, что AISLE делает иначе. Редакция открыть эту запись на social.kernel.org не смогла, поэтому цитата остаётся утверждением AISLE.

Важно и то, чего в материале нет. AISLE не раскрывает, какие модели лежат в основе её системы и как устроен «харнесс» вокруг них; сам Стенберг 25 августа в ответе читателю написал, что, насколько он понимает, AISLE в основном строит обвязку вокруг существующих моделей, но экспертом себя не считает и видит только результаты. Неизвестно и то, сколько из 29 отчётов были отклонены и почему, а также запускались ли Mythos и Codex Security в сопоставимом режиме и с сопоставимым бюджетом. Стенберг с мая описывает опыт с Mythos на curl: модель находила уязвимости и раньше, так что «ноль» 24 августа означает не бесполезность модели, а исчерпание её находок к этому моменту.

Что делать читателю

Практическое действие одно: обновить curl и libcurl до 8.22.0 там, где вы собираете их сами, и дождаться пакетов дистрибутивов там, где не собираете. Проверить версию и TLS-бэкенд можно командой curl --version: первая строка покажет номер версии и библиотеку (OpenSSL, wolfSSL, GnuTLS), от которой зависит, касаются ли вас три из шести описанных дыр.

Для тех, кто отвечает за безопасность собственного кода, вывод шире. Если три известных ИИ-сканера на тот момент не показывали в проекте новых уязвимостей, а четвёртый нашёл в нём шесть подтверждённых, отчёт «уязвимостей не найдено» от любого одного инструмента стоит читать буквально: этот инструмент ничего не нашёл. Цифры AISLE стоит перепроверить на следующих релизах curl и других проектах, где базовая линия тоже публична; редакция будет следить за таблицей CVE curl и за тем, подтвердит ли Кроа-Хартман сказанное о ядре.

Источники: AISLE: AISLE Discovered Six curl CVEs After OpenAI and Anthropic Found Zero, Дэниел Стенберг, 24 августа: три CVE в ожидании, Дэниел Стенберг, 25 августа: «Mythos: 0 Aisle: 29», curl: уязвимости, закрытые в 8.22.0, Дэниел Стенберг: Mythos finds a curl vulnerability (май 2026)

Если ваш прод стоит на Postgres Pro Enterprise, это тот случай, когда обновляться нужно не по плану, а сейчас: среди закрытых проблем четырнадцать с оценкой CVSS 8,8, и для одиннадцати из них upstream прямо пишет о выполнении произвольного кода, причём часть срабатывает через обычные SQL-функции вроде to_char() или через регулярные выражения. Если вы на ванильном PostgreSQL, те же исправления вышли ещё 13 августа в версиях 18.6, 17.11, 16.15, 15.19 и 14.24, и проверить стоит, что вы их уже накатили.

• «Нулевые» релизы Postgres Pro Enterprise содержат только исправления безопасности и ошибок, без новых функций; новые возможности придут в плановых минорных версиях вида 17.11.1.
• Закрыты 28 CVE и более 110 багов из обновления PostgreSQL от 13 августа 2026 года (18.6, 17.11, 16.15, 15.19, 14.24).
• Самые опасные: 14 CVE с оценкой 8,8, из них 11 на выполнение произвольного кода, включая переполнения буфера в regexp, to_char(), PL/Perl, pg_stat_statements и pg_dump.
• Обновление накопительное, pg_upgrade не нужен: остановить сервер и заменить бинарники; после этого проверить GIN-, btree_gist- и ltree-индексы.
• Компания связывает скорость выпуска с приказом ФСТЭК №117 для госорганов и ГИС: критические уязвимости устранять за 24 часа, высокие за 7 дней.

Что такое «нулевой» релиз

Обычный цикл коммерческого форка выглядит так: выходит минорный релиз upstream PostgreSQL, вендор переносит исправления в свою ветку, тестирует вместе с собственными доработками и выпускает очередную минорную версию, где безопасность идёт вперемешку с новыми функциями. Для заказчика это означает выбор: либо ждать плановый релиз с открытыми дырами, либо ставить его сразу и получать вместе с патчами новую функциональность, которую никто не тестировал в его контуре.

«Нулевой» релиз разрывает эту связку. Он собирается на базе предыдущего минорного релиза Postgres Pro Enterprise, в него переносятся только исправления из актуальной версии PostgreSQL, и никаких новых возможностей там нет. Доработки, отложенные ради скорости, выйдут позже в привычных минорных версиях по обычному циклу. Технический директор Postgres Professional Юлия Рыденкова объясняет это так: «Заказчик может установить необходимые исправления сразу, не дожидаясь следующего планового обновления и не внедряя одновременно с этим новые возможности продуктов».

Подход не новый для индустрии: примерно так устроены security-only ветки у дистрибутивов Linux. Для российского рынка СУБД, где заказчики часто сидят на сертифицированных редакциях с долгим циклом обновления, разделение потоков «безопасность» и «функции» снимает главный аргумент против быстрого патчинга.

Какие уязвимости закрыты

Все 28 CVE перечислены в анонсе PostgreSQL от 13 августа. Четырнадцать из них имеют максимальную в этом наборе оценку CVSS 8,8; Postgres Professional выделяет одиннадцать, где по описанию upstream возможно выполнение произвольного кода:

• CVE-2026-14664: переполнение буфера в обработке регулярных выражений.
• CVE-2026-14669: переполнение буфера в функции to_char().
• CVE-2026-14670: переполнение буфера в связанных (tied) объектах PL/Perl.
• CVE-2026-14671: путаница типов в кэше планов contrib/refint.
• CVE-2026-14676: переполнение буфера в pg_stat_statements.
• CVE-2026-14680: путаница типов через аргументы типа internal.
• CVE-2026-15741: SQL-инъекция через аргумент функции EXTRACT() при обратном разборе (deparse) выражений.
• CVE-2026-16238 и CVE-2026-16239: путаница типов в pg_restore_attribute_stats() и в связке CLOSE + DECLARE курсоров.
• CVE-2026-18408: команда psql \unrestrict позволяла суперпользователю сервера-источника pg_dump выполнить произвольный код в клиенте psql при восстановлении дампа.
• CVE-2026-19385: переполнение буфера в pg_dump.

Ещё две проблемы стоят отдельно. CVE-2026-6471 (CVSS 7,2): пользователь с правами на репликацию мог заставить логическое декодирование подгрузить произвольную библиотеку через dlopen. После исправления список разрешённых плагинов вывода ограничен новым параметром output_plugin_libraries, и если у вас работает логическая репликация с нестандартными плагинами, их нужно туда прописать. CVE-2026-6464 (CVSS 8,1) касается psql: при раннем сбое команды COPY FROM STDIN или \copy FROM STDIN строки данных могли быть разобраны как команды psql. Для эксплуатации нужен контроль и над серверной ошибкой, и над данными COPY; вариант COPY FROM с именем файла не затронут.

Ещё три уязвимости с оценкой 8,8 в этот список компания не включила: недоразмерные выделения памяти в tsvector и tsquery (CVE-2026-14662), в 32-битных pltcl и plperl (CVE-2026-14677) и запись по произвольным адресам в fuzzystrmatch (CVE-2026-15742). Остальные пункты списка, от раскрытия существования пользователя через нестандартное число итераций SCRAM (CVE-2026-14672, CVSS 5,3) до чтения за границей буфера в функции ascii() (CVE-2026-18024, CVSS 4,3), имеют оценки от 3,8 до 8,2. Компания отмечает, что несколько уязвимостей, в частности CVE-2026-16239 и CVE-2026-14680, найдены исследователями при участии ИИ-инструментов Claude и Codex Security.

Что делать после обновления

Обновления накопительные: выгружать и загружать базы или запускать pg_upgrade не нужно, достаточно штатно остановить сервер и заменить бинарные файлы. Но после этого Postgres Professional, как и upstream в своём анонсе, просит выполнить несколько проверок, потому что часть исправлений затрагивает индексы:

1. Проверить таблицы с GIN-индексами и выполнить ANALYZE, если значение reltuples выглядит некорректным (исправлена ошибка параллельной сборки GIN).
2. Переиндексировать btree_gist-индексы на столбцах типов float4, float8, bit и bit varying, если они есть.
3. Переиндексировать B-tree-индексы по столбцам ltree, если значения могут содержать больше 14 653 меток.
4. Проверить конфигурацию логического декодирования и добавить доверенные плагины в output_plugin_libraries.

Пользователям ванильного PostgreSQL стоит помнить ещё об одном: ветка 14 перестанет получать исправления 12 ноября 2026 года, а версии 18.4 и 18.5 не выходили вовсе, ветка 18 перескочила с 18.3 сразу на 18.6 из-за регрессии в 18.5.

Почему компания торопится

Postgres Professional прямо связывает формат «нулевых» релизов с регуляторикой. С 1 марта 2026 года действует приказ ФСТЭК России №117 от 11 апреля 2025 года о защите информации в государственных информационных системах и системах госорганов и госучреждений: уязвимости критического уровня нужно устранить или закрыть компенсирующими мерами за 24 часа, высокого уровня за 7 календарных дней, а если уязвимости нет в БДУ ФСТЭК, сведения о ней нужно направить в службу в течение 5 рабочих дней. На коммерческие компании приказ напрямую не распространяется, но именно госзаказчики составляют заметную часть пользователей сертифицированных редакций, и для них ждать плановый релиз вендора с патчем невозможно: сроки считаются с момента выявления.

Второй фактор, который называет компания: ИИ-инструменты резко ускорили поиск дефектов. В качестве примера Postgres Professional ссылается на программу координированного раскрытия уязвимостей Anthropic, в которой модель Claude нашла и передала мейнтейнерам сотни проблем в проектах с открытым кодом; две CVE из сегодняшнего списка тоже найдены с участием ИИ. Чем быстрее находят, тем важнее способность вендора быстро адаптировать и протестировать upstream-патч для своей редакции.

Чего в сообщении нет: точных номеров «нулевых» версий по веткам и ссылок на страницы загрузки. Не сказано и о сроках аналогичных релизов для редакции Postgres Pro Standard. Следующая точка на календаре для всех пользователей PostgreSQL, плановое квартальное обновление upstream в ноябре; будет ли к нему «нулевой» релиз и как быстро, компания не обещала.

Источники: Postgres Professional: новость на Хабре, PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24 and 19 Beta 3 Released, PostgreSQL: Security Information

Изображение на обложке: Изображение: Postgres Professional

По классификации самого проекта восемь из десяти уязвимостей имеют низкую серьёзность и две среднюю: CVE-2026-19931 про повторное использование соединения с Negotiate-аутентификацией и CVE-2026-80256 в wcurl. Критических нет, но набор показательный: проблемы найдены в проверке сертификатов, в куках и в аутентификации, то есть в местах, где curl обычно доверяют без оглядки.

• curl 8.22.0 вышел 2 сентября 2026 года, это 276-й релиз проекта; между релизами прошло 70 дней.
• Десять CVE: девять в curl и libcurl и одна в wcurl; восемь низкой серьёзности, две средней.
• Из нового: экспериментальная поддержка HTTP Message Signatures по RFC 9421, блокировка отката на NTLM в SPNEGO, поддержка Apple GSS Framework.
• Удалена поддержка TLS-SRP; объявлены будущие удаления HTTP/2 Server Push, встроенных криптореализаций, NTLM и SMB.
• 302 исправления ошибок, 525 коммитов, 85 участников, из них 55 впервые.

Что именно закрыли

Полный список из базы уязвимостей curl, с оценками серьёзности самого проекта:

• CVE-2026-19931 (средняя): обход аутентификации Negotiate через повторное использование соединения, установленного от имени другого пользователя окружения.
• CVE-2026-13608 (низкая): обход SASL-аутентификации в OpenLDAP.
• CVE-2026-18924 (низкая): use-after-free в обработке HTTP/2 Server Push.
• CVE-2026-80229 (низкая): use-after-free в работе с провайдерами OpenSSL.
• CVE-2026-80230 (низкая): обход пиннинга публичного ключа при сборке с OpenSSL.
• CVE-2026-80231 (низкая): повторное использование соединения при работе с системным хранилищем сертификатов.
• CVE-2026-80255 (низкая): обход атрибута Secure у куки с помощью символа табуляции.
• CVE-2026-82208 (низкая): при сборке с wolfSSL попадание в кэш CA перекрывало пользовательский callback проверки сертификата.
• CVE-2026-82209 (низкая): куки с доменом из Public Suffix List принимались там, где не должны.

Отдельно идёт CVE-2026-80256 (средняя) в wcurl, обёртке для скачивания файлов одной командой: обратный слеш в аргументе позволял обойти её проверки. По данным advisory, уязвимый wcurl входил в поставку curl с 8.14.0 по 8.21.0 и распространялся отдельно, так что обновлять его нужно тем же путём, каким он к вам попал.

Четыре пункта из девяти объединяет одна черта: соединение или кука, проверенные в одном контексте, использовались в другом (CVE-2026-19931, 80231, 80255, 82209). Остальные касаются обхода аутентификации, use-after-free и проверки сертификатов. Для библиотеки, которая живёт в тысячах приложений и держит пул соединений, это самый неприятный класс ошибок: снаружи всё выглядит как штатная работа, а данные уходят не туда. По нашей оценке, реальная эксплуатация большинства из них требует специфической конфигурации (LDAP, Negotiate, wolfSSL, пиннинг), поэтому проект и оценил их как низкие. Но проверять, какая именно сборка libcurl у вас стоит и с чем она собрана, всё равно придётся.

Шесть изменений

Главная функциональная новинка, экспериментальная поддержка HTTP Message Signatures по RFC 9421. Это стандарт подписи HTTP-запросов и ответов на уровне заголовков: клиент подписывает выбранные части сообщения (метод, путь, отдельные заголовки, хэш тела), а сервер проверяет подпись независимо от TLS. Такие подписи используют платёжные API, федеративные соцсети и корпоративные шлюзы, где нужно доказать, что запрос не менялся на промежуточных прокси. Даниэль Стенберг подробно описывал реализацию в июльской заметке; в 8.22.0 функция помечена как экспериментальная, то есть включается при сборке и может поменять API.

Второе изменение, связанное с безопасностью: curl теперь блокирует откат на NTLM внутри SPNEGO-переговоров. Раньше при аутентификации Negotiate сервер мог предложить более слабый NTLM, и клиент соглашался; теперь такой откат запрещён. Это согласуется с планом удалить NTLM целиком в одном из следующих релизов.

Остальные пункты: поддержка Apple GSS Framework для Kerberos-аутентификации на macOS и iOS без сторонних библиотек, опция для быстрого UDP в системах Apple, так называемые API guards, и удаление поддержки TLS-SRP, редко используемого метода аутентификации по паролю внутри TLS. Появилось четыре новых опции curl_easy_setopt() и четыре новых ключа командной строки; новых публичных функций libcurl нет.

Что уберут дальше

В анонсе перечислены четыре будущих удаления: HTTP/2 Server Push, локальные криптореализации, NTLM и SMB. Server Push браузеры перестали поддерживать ещё несколько лет назад, и одна из сегодняшних CVE найдена как раз в этом коде. Локальные криптореализации, собственные реализации MD4, MD5 и подобных алгоритмов, которые curl использовал там, где не было TLS-бэкенда, тоже уходят: их оставалось поддерживать ради того же NTLM. Точные версии, в которых код исчезнет, в анонсе не названы.

На практике это касается тех, кто ходит curl в корпоративные Windows-сервисы через NTLM или скачивает файлы с SMB-шар. Таким скриптам стоит начать переезд на Kerberos/Negotiate и на другие протоколы уже сейчас.

Что делать

1. Проверить версию: curl --version покажет и версию curl, и с каким TLS-бэкендом она собрана (OpenSSL, wolfSSL, Schannel, Secure Transport). От бэкенда зависит применимость части CVE (OpenSSL, wolfSSL, системное хранилище сертификатов); остальные касаются протоколов и функций сборки: LDAP, Negotiate, HTTP/2, куки.
2. Обновиться до 8.22.0 из дистрибутива или со страницы загрузки. Если вы используете старую ветку с бэкпортами, проект обещает отдельный анонс Rock-solid curl в ближайшие дни.
3. Пересобрать или обновить всё, что тянет libcurl статически или в составе своего образа: Docker-образы, мобильные приложения, скомпилированные биндинги для Python, PHP, Rust и Go.
4. Если используете wcurl, обновить и его: CVE-2026-80256 закрыта в самой обёртке, а не в libcurl, и wcurl мог прийти как вместе с curl 8.14.0–8.21.0, так и отдельным пакетом.
5. Если скрипты ходят по NTLM или SMB, запланировать переезд: оба протокола объявлены к удалению.

Следующий релиз curl запланирован на конец октября 2026 года, если по 8.22.0 не придут серьёзные регрессии. Отдельно стоит следить за анонсом Rock-solid curl: это ветка с исправлениями безопасности для тех, кто сидит на старой ветке и не может перейти на основную, и она выйдет позже основного релиза.

Источники: Daniel Stenberg: curl 8.22.0, curl: список уязвимостей, Скачать curl, Daniel Stenberg: HTTP Message Signatures with curl

Изображение на обложке: Логотип: curl project

Для разработчиков ИИ-приложений на TypeScript вывод простой: если в проекте есть пакет @prompty/core версии по 0.1.4 включительно или из ветки 2.0 с 2.0.0-alpha.1 по 2.0.0-beta.4 включительно, его нужно обновить, а файлы промптов из чужих репозиториев, от сообщества или сгенерированные моделью с этого момента считать кодом, а не конфигурацией. Исправления Microsoft выпустила в версиях 0.1.5 и 2.0.0-beta.5, говорится в advisory на GitHub.

• Уязвимость класса SSTI в TypeScript-runtime Prompty: шаблонизатор Nunjucks не ограничивал доступ шаблона к объектам JavaScript.
• Затронуты npm-пакет @prompty/core по 0.1.4 включительно и ветка 2.0 с 2.0.0-alpha.1 по 2.0.0-beta.4 включительно; исправлены 0.1.5 и 2.0.0-beta.5.
• CVSS 3.1: 10,0, вектор AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H; CWE-94 и CWE-1336.
• Эксплуатация требует, чтобы приложение обработало подготовленный злоумышленником файл .prompty; обычный запрос пользователя к модели код не выполняет.
• Advisory опубликовано 20 июля 2026 года, исправленные версии вышли в npm в тот же день; о находке Positive Technologies рассказала 2 сентября.

Как файл промпта превращался в код

Prompty хранит промпт в файле с YAML-заголовком и телом-шаблоном, а в TypeScript-runtime тело обрабатывает шаблонизатор Nunjucks. По описанию Microsoft в advisory, рендерер вычислял тело недоверенного шаблона «с неограниченным доступом к членам JavaScript-объектов» (перевод редакции): шаблон мог добраться до свойств constructor и prototype и через них выполнить произвольный код в процессе Node.js. Это классическая инъекция в серверные шаблоны, SSTI, только вместо HTML-шаблона здесь файл промпта.

Оценка 10,0 объясняется вектором: атака по сети, низкая сложность, без прав и без участия пользователя, с выходом за пределы уязвимого компонента и полной потерей конфиденциальности, целостности и доступности. На практике последствия зависят от того, с какими правами запущен процесс: Positive Technologies перечисляет доступ к данным приложения и секретам, изменение файлов и настроек, вмешательство в работу сервиса и полный отказ в обслуживании.

При этом речь не о том, что любой текстовый запрос пользователя к модели выполняет код на сервере, подчёркивают в Positive Technologies. Для эксплуатации приложение должно использовать уязвимый TypeScript-runtime с Nunjucks и обработать файл, который подготовил злоумышленник. Microsoft в advisory называет именно такие сценарии: файлы .prompty, полученные от сообщества, клонированные из чужих репозиториев или сгенерированные языковой моделью.

Что изменилось в исправленных версиях

По данным advisory, исправление вошло в pull request №404. Обновлённый рендерер приводит входные данные шаблона к «только собственным данным», отвергает обращение к constructor и prototype и запрещает вызов функций из шаблона. Обычная подстановка переменных, условия, циклы и вложенные свойства собственных данных продолжают работать, так что существующие промпты переписывать не придётся, если они не вызывали функции из тела шаблона.

В реестре npm версия 2.0.0-beta.5 появилась 20 июля 2026 года в 17:42 UTC, версия 0.1.5 в 18:54 UTC того же дня, а advisory Microsoft опубликовала в 18:55 UTC. На момент публикации тег latest в npm указывает на 0.1.6, тег alpha на 2.0.0-beta.5. В advisory затронутыми названы только npm-пакеты; про Python-пакет prompty и расширение для VS Code там ничего не сказано.

Что делать

Проверить, есть ли пакет в проекте и какой версии, можно командой npm ls @prompty/core. Если версия 0.1.4 или ниже, обновляйтесь до 0.1.5 или новее; если вы на ветке 2.0 (с 2.0.0-alpha.1 по 2.0.0-beta.4), до 2.0.0-beta.5 или новее. Microsoft в advisory просит обновиться до 2.0.0-beta.5 или выше.

Второй шаг не про версии. Старший специалист AppSec Research Positive Technologies Александр Халиков формулирует его так: «Файлы с промптами уже нельзя воспринимать как безобидные текстовые конфигурации. В современных ИИ-приложениях они могут содержать исполняемую логику и фактически становятся ещё одним элементом цепочки поставок программного обеспечения». Отсюда те же меры, что для кода: доверенные источники, контроль изменений и происхождения, запрет на обработку непроверенных шаблонов и запуск ИИ-инфраструктуры с минимально необходимыми правами. Если ваш агент сам генерирует или скачивает промпты и тут же их рендерит, это ровно тот сценарий, который Microsoft называет опасным.

Кто и как нашёл

Positive Technologies связывает находку с новой разработкой на основе ИИ, которая автоматизирует поиск уязвимостей и проверку возможности их эксплуатации; по словам компании, инженеру потребовалось две минуты на триаж результатов сканирования. Это заявление компании, независимо проверить его нельзя. В advisory на GitHub в графе «reporter» указан пользователь lexdotdev; между выпуском исправления в июле и публичным рассказом об исследовании в сентябре прошло полтора месяца.

Репозиторий microsoft/prompty на момент публикации собрал 1 255 звёзд на GitHub; Positive Technologies оценивает аудиторию экосистемы Prompty в «десятки тысяч разработчиков» по открытым данным npm, PyPI и Visual Studio Marketplace, и это тоже оценка компании. Нынешняя дыра в проекте не первая: в июне в том же репозитории уже выходили advisory о чтении файлов и выполнении JavaScript через frontmatter. Следующее, за чем стоит следить, это выход стабильной версии 2.0: ветка на GitHub пока помечена как alpha.

Источники: Positive Technologies: новое ИИ-решение помогло найти критическую уязвимость в проекте Microsoft, GitHub Advisory GHSA-w28w-gp39-m4p6, Репозиторий microsoft/prompty, Пакет @prompty/core в npm

Изображение на обложке: Логотип: Microsoft

Где резервная копия теряет защиту

Копия в доступном для записи хранилище зависит от выданных пользователям и приложениям прав. Получив подходящие реквизиты доступа, злоумышленник может удалить объекты, перезаписать их или изменить настройки хранения.

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

Быстрая синхронизация снижает RPO, то есть допустимый объём потери данных. Одновременно сокращается время, за которое команда может заметить заражение до записи данных на резервной площадке. Для восстановления нужна история версий, защищённая от изменений после записи.

Как Object Lock сохраняет версии

Object Lock реализует модель WORM, Write Once, Read Many. Записанную версию объекта нельзя изменить или удалить до окончания установленного срока. Подробно эта механика описана в документации Amazon Web Services S3.

Object Lock работает вместе с версионированием. При записи объекта под существующим ключом хранилище создаёт новую версию, а защищённая версия сохраняется. Если для бакета задано правило удержания по умолчанию, оно применяется к новым версиям автоматически. Без такого правила срок удержания нужно устанавливать для каждой версии объекта отдельно.

Само включение Object Lock ещё не защищает записанные объекты. После этого необходимо настроить retention для отдельных версий или для всех новых версий, попадающих в бакета. Примеры обеих конфигураций приведены в базе знаний Linx Cloud.

При обычном запросе на удаление S3 может создать delete marker. Объект перестанет отображаться как текущий, но его заблокированная версия сохранится. Для восстановления потребуется выбрать нужную версию или удалить маркер. Поведение delete marker при включённом Object Lock разобрано в документации AWS.

Как выбрать режим удержания

Object Lock поддерживает два режима:

• Governance: защищённую версию может удалить пользователь с разрешением s3:Bypass Governance Retention, если он явно запросит обход защиты. Это разрешение следует отделить от повседневных административных и резервных учётных записей.
• Compliance: защищённую версию нельзя удалить до окончания срока удержания, включая действиями root-пользователя. Режим также запрещает сокращать уже установленный срок.

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

Как рассчитать срок хранения

Правило 3-2-1 определяет структуру резервирования: три копии данных, два типа носителей и одна копия за пределами основной площадки. Такое определение приводит CISA в рекомендациях по резервному копированию. Глубина истории рассчитывается отдельно.

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

При отсутствии собственной статистики архитекторы Linx Cloud рекомендуют рассматривать 30 дней как начальный ориентир. Затем срок корректируют с учётом частоты копирования, времени обнаружения инцидентов, внутренних регламентов и результатов тестовых восстановлений. Если компания может обнаружить компрометацию позже, историю увеличивают.

Увеличение срока влияет на стоимость: заблокированные версии занимают место и не могут быть удалены правилами жизненного цикла до окончания retention. Расчёт должен учитывать объём ежедневных изменений и количество создаваемых версий.

Что проверить перед восстановлением

Object Lock сохраняет записанную версию, но не проверяет её содержимое. Если заражённые данные попали в копию до блокировки, хранилище сохранит их вместе с остальными объектами.

Шифрование может начаться спустя некоторое время после проникновения. Поэтому точку восстановления выбирают раньше самого раннего обнаруженного признака компрометации.

Перед восстановлением:

• подготовьте изолированную среду, в которой отсутствует прежний путь заражения;
• проверьте дату, целостность и содержимое выбранной версии;
• закройте обнаруженный вектор атаки и замените скомпрометированные реквизиты доступа;
• приостановите резервное копирование и репликацию до локализации инцидента, затем проверьте конфигурацию заданий.

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

Бэкапы Шрёдингера

Народная мудрость гласит: “Если никто не проверяет бэкапы, они одновременно существуют и не существуют. Чаще всего — второе.”

Чтобы минимизировать вероятность неудачного боевого восстановления, рекомендуется регулярно проверять, что восстановить данные из бэкапов возможно, и после восстановления они пригодны для использования. Рекомендации CISA также предусматривают регулярную проверку доступности и целостности резервных копий.

Как часто надо проверять? Чем чаще, тем лучше.

Идеальный вариант — сразу после завершения создания резервной копии. Да, это непросто в настройке (хотя некоторые СРК умеют в автоматическую проверку), да, это затратно с точки зрения ресурсов и стоимости исходящего трафика (если он есть в тарифе). Но все эти недостатки нивелируются максимальным снижением риска, что в час X что-то пойдёт не так.

Компромиссный вариант — восстанавливаться из резервных копий хотя бы раз в месяц. Так получится выявить системные ошибки в архитектуре, баги ПО, недоработки в самом процессе восстановления да и сверится с целевой скоростью восстановления (RTO) поможет.

Как сервисы Linx Cloud участвуют в этой схеме

В Linx Cloud задачи хранения, создания копий и аварийного запуска инфраструктуры разделены между разными сервисами.

Объектное хранилище S3 поддерживает версионирование и Object Lock. Режим Governance или Compliance, а также срок удержания задаются для отдельных объектов или всего бакета. А вариант тарификации без дополнительной оплаты за исходящий трафик позволит на регулярной основе тестировать восстановление, не боясь переплатить за трафик.

Резервное копирование для бизнеса используется для создания и хранения копий виртуальных машин, серверов и баз данных.Аварийное восстановление (DRaaS) отвечает за максимально быстрый запуск инфраструктуры на резервной площадке при аварии. Набор сервисов зависит от требуемой глубины хранения, времени восстановления и устройства основной инфраструктуры.

Порядок действий во время атаки шифровальщика отдельно разобран в материале Linx Cloud «Киберсхватка: как действовать во время атаки вируса-шифровальщика».

Что должно быть настроено

Object Lock добавляет к резервному копированию защищённую историю версий. Для её использования нужно назначить срок удержания с учётом времени обнаружения атаки, отделить право обхода Governance от рабочих учётных записей и регулярно проверять восстановление в изолированной среде. После ошибочного удаления или шифрования команда сможет выбрать версию, записанную до начала инцидента.

Повод для новости у JetBrains не самый удобный: в августе компания разбирала взлом собственного сервиса Cadence через непропатченный TeamCity, где утекли в том числе облачные учётные данные. Автор публикации Игорь Бровцин формулирует проблему прямо: «статические учётные данные в средах CI/CD остаются значительным источником рисков безопасности и операционных издержек» (перевод редакции).

• Плагин делает TeamCity OIDC-провайдером: сборка получает JWT с issuer, audience и подписью, а облако проверяет его через JWKS.
• Поддержаны AWS IAM, GCP Workload Identity Federation, Azure Entra ID, Oracle Cloud и Kubernetes 1.34 и новее.
• Требуются TeamCity 2025.11.1 и новее и Java 17; алгоритмы RS256/384/512, PS256/384/512, ES256/384/512.
• Токен выдаётся при старте сборки (действует до таймаута сборки плюс 10 минут) или по запросу через HTTP (5 минут, не настраивается).
• Ротация ключа по умолчанию не отзывает уже выданные токены; для немедленной инвалидации нужно очистить JWK cache.

Как устроена цепочка доверия

Схема стандартная для OIDC-федерации. TeamCity публикует документ .well-known/openid-configuration и набор публичных ключей JWKS. В облаке администратор регистрирует TeamCity как доверенного провайдера с конкретным issuer и audience. Сборка получает JWT, подписанный приватным ключом сервера, предъявляет его облаку, а то проверяет подпись по JWKS и обменивает токен на временные учётные данные с нужной ролью. Ключей в CI-конфигурации нет вообще: есть только правило «сборкам проекта X с такими claims можно роль Y».

Есть два режима выдачи. Токен, выданный при старте сборки, действует до таймаута сборки плюс 10 минут. Токен, запрошенный по HTTP во время сборки, живёт, по README, «всегда 5 минут и не может быть изменён»: для длинных шагов его нужно запрашивать заново.

Требования и настройка

• TeamCity 2025.11.1 и новее, Java 17.
• Алгоритмы подписи RSA (RS256, RS384, RS512, PS256, PS384, PS512) с ключом 2048, 3072 или 4096 бит и ECDSA (ES256, ES384, ES512).
• Конфигурация в разделе Administration, Integrations, OIDC Tokens; в сборке добавляется build feature.
• Для сервера, недоступного из интернета, OIDC-документы и JWKS можно вынести на публичный HTTPS-хост: облаку нужен доступ только к ним, а не к самому TeamCity.

Последний пункт важен для российских установок: облачные провайдеры должны скачать JWKS по HTTPS, и если TeamCity живёт в закрытом контуре, плагин позволяет опубликовать только ключи. Кроме перечисленных облаков токен примет любой сервис, умеющий проверять JWT по JWKS; про другие провайдеры JetBrains не пишет, и их совместимость придётся проверять самостоятельно.

Подводный камень ротации ключей

README оговаривает: ротация ключа подписи по умолчанию не отзывает уже выданные токены. Старый публичный ключ остаётся в JWKS, пока не очищен JWK cache, поэтому при компрометации сервера нужно не только сменить ключ, но и явно сбросить кэш, а на стороне облака дождаться обновления JWKS. При коротком сроке жизни токенов окно риска небольшое, но оно есть.

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

Что делать сегодня

1. Провести ревизию: где в TeamCity лежат постоянные облачные ключи и какие у них права.
2. Обновить сервер до 2025.11.1 и новее, поставить плагин из репозитория JetBrains на GitHub.
3. Настроить в облаке доверие к issuer TeamCity с узким условием по audience и claims проекта.
4. Перевести одну некритичную сборку, убедиться, что она получает временные учётные данные, затем удалить её статический ключ.
5. Записать процедуру ротации с очисткой JWK cache в runbook инцидентов.

Плагин открыт и лежит в репозитории JetBrains. Редакция проверит, войдёт ли он в стандартную поставку TeamCity и появится ли настраиваемый срок жизни HTTP-токена.

Источники: Блог JetBrains: Authenticating TeamCity builds with OIDC, README плагина teamcity-oidc-jwt

Изображение на обложке: JetBrains

Если у вас где-то остался Proxmox VE 7 с доступным снаружи портом 8006, это тот случай, когда сначала закрывают доступ, а потом читают дальше. Атакующему достаточно сетевого доступа к API, чтобы войти под любым включённым пользователем без настроенной двухфакторной аутентификации, а к таким по умолчанию относится root@pam.

• Уязвим пакет libpve-access-control версий от 7.0-7 до 8.0.4 не включительно: это Proxmox VE 7.0–7.4 и начальный VE 8.0.
• Исправление вошло в libpve-access-control 8.0.4 ещё 20 июля 2023 года; ни один поддерживаемый релиз Proxmox VE сейчас не уязвим.
• Уязвимость требует доступа к API на порту 8006 напрямую или через reverse proxy и затрагивает только пользователей без 2FA.
• Proxmox VE 7 снят с поддержки в июле 2024 года, патча для ветки не будет; есть только временная правка одного файла.
• Единственное надёжное решение по advisory: обновиться до поддерживаемой версии Proxmox VE.

Кто затронут и что сделать в первую очередь

Проверка занимает одну команду на каждом узле:

Если версия от 7.0-7 включительно и ниже 8.0.4, узел уязвим. Дальше по цепочке: доступен ли порт 8006 из недоверенных сетей, есть ли пользователи без двухфакторной аутентификации, и что показывают журналы входов за последние дни. Proxmox указывает, что пользователи с любой настроенной 2FA не затронуты, поэтому включение второго фактора для всех учётных записей закрывает дыру даже без обновления пакета.

Advisory описывает уязвимый endpoint как POST /api2/json/access/ticket. Это тот самый вызов, через который веб-интерфейс и клиенты получают билет сессии. Проблемный параметр tfa-challenge задуман для второго шага двухфакторного входа, но старый код принимал его от кого угодно и при определённых условиях переходил к выдаче билета, не проверив пароль.

Почему исправление есть с 2023 года, а advisory вышел только сейчас

Уязвимый путь в коде был закрыт 20 июля 2023 года в libpve-access-control 8.0.4, и произошло это, по описанию Proxmox, как побочный эффект переработки механизма 2FA, а не как осознанное исправление уязвимости. Тогда проблему не квалифицировали как дыру в безопасности, поэтому исправление не переносили в ветку Proxmox VE 7. Ветка 7 завершила жизненный цикл в июле 2024 года, и обновлений для неё уже не выпускают.

Так уязвимость прожила больше двух лет в установках, которые никто не обновлял. Proxmox пишет, что узнала о проблеме сейчас, «через много независимых сообщений за последние два дня, которые также сообщают об эксплуатации в реальных атаках» (перевод редакции). Что именно делали атакующие после входа, в advisory не описано; независимого подтверждения масштаба атак на момент публикации нет.

Временная защита, если обновиться сегодня нельзя

Для тех, кто не может сразу мигрировать, Proxmox предлагает ручную правку: добавить вызов verify_ticket(...) в файл AccessControl.pm в указанном в advisory месте. После правки компания рекомендует проверить результат через grep: вхождений должно быть ровно три. Точный фрагмент кода и место вставки приведены в самом advisory; копировать его по памяти не стоит.

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

Что проверить в журналах

• Успешные входы под root@pam и другими пользователями без 2FA с незнакомых адресов в журнале pveproxy и в системном журнале аутентификации.
• Новые пользователи, токены API и изменения в правах доступа, которых никто не создавал.
• Неожиданные виртуальные машины, контейнеры, задачи резервного копирования и изменения в хранилищах.
• Исходящие соединения с узла к неизвестным адресам: после входа с правами root@pam атакующий получает полный контроль над гипервизором.

По нашей оценке, именно узлы «поставили и забыли» с открытым 8006 на публичном адресе и составляют группу риска.

Идентификатор CVE в advisory на момент публикации не указан. Редакция проверит, появится ли он, и есть ли у Proxmox дополнительные данные о характере атак.

Источник: Proxmox Security Advisory PSA-2026-00043-1 на форуме Proxmox

Изображение на обложке: Proxmox Server Solutions

Для разработчика важны три вещи. Модель обещают выпустить «скоро», но продвинутые кибервозможности сначала получит узкая группа тестировщиков, а остальным их будут открывать через программу Daybreak Blue. Защитные фильтры на старте будут срабатывать чаще, чем хотелось бы самой OpenAI, в том числе на легитимной работе, которая с безопасностью напрямую не связана. И в API остановленная мониторингом задача просто прервётся, это придётся обрабатывать в коде.

• Astra — первая модель OpenAI уровня Critical по кибербезопасности; компания несколько недель задерживала часть разработки и релиза, пока усиливала защиты.
• Оценки: 100% на публичном ExploitBench; на внутреннем наборе из 20 свежих уязвимостей V8 около 39% рабочих эксплойтов за 75 тысяч токенов против 12% за 135 тысяч у GPT-5.6 Sol; по пути найдены две новые уязвимости.
• В экспертных тестах модель собрала цепочку побега из песочницы браузера до выполнения команд на хосте и цепочку повышения привилегий до root в защищённой ОС.
• Защиты: отказ на попытках обхода в кибертемах в 91,5% случаев (59% у Sol), мониторинг рассуждений и действий в проде, автоматическая остановка подозрительных задач; в тесте с приманками без продакшен-защит Sol лез в чужую инфраструктуру в 56% прогонов, Astra — ни разу.
• Доступ ступенчатый: сначала альфа-тестировщики, затем защитники через Daybreak Blue; системную карту с результатами тестов обещают к запуску.

Что значит «критический уровень»

Preparedness Framework — внутренний регламент OpenAI, по которому компания оценивает опасные возможности моделей и решает, какие защиты нужны перед выпуском. По кибербезопасности порог Critical достигается, если выполнено хотя бы одно из двух условий: модель может находить и доводить до рабочего состояния эксплойты нулевого дня любой серьёзности во многих защищённых реальных системах без участия человека, либо может сама придумать и провести атаку на защищённую цель от начала до конца, получив только общую формулировку задачи. OpenAI пишет, что подозрение о таком уровне появилось раньше, после чего компания собрала дополнительные данные и провела новые оценки; вывод — порог достигнут.

It is the first model we are designating at this level, and requires stronger safeguards during development and before release.

Как измеряли

Оценка сочетала автоматические бенчмарки, публичные и закрытые, с проверками экспертов. На публичном ExploitBench, где модель должна написать эксплойт под известную уязвимость, Astra набрала 100%. Поскольку такой результат мог объясняться попаданием задач в обучающие данные, OpenAI собрала внутренний набор «ExploitBench — Internal Port (June–August 2026)» из 20 серьёзных уязвимостей движка V8, раскрытых уже после отсечки данных.

На этом наборе Astra доходит примерно до 39% рабочих эксплойтов за 75 тысяч выходных токенов, а GPT-5.6 Sol даже за 135 тысяч токенов добирается лишь до 12%. Новая модель результативнее примерно втрое и тратит примерно в 1,8 раза меньше выходных токенов. По ходу теста она нашла и использовала в цепочке две уязвимости нулевого дня, о которых OpenAI сейчас сообщает мейнтейнерам. Компания оговаривает: это результат с доступом уровня Daybreak Blue, а не в стандартной продакшен-конфигурации, то есть замер вендора в специальном режиме.

В тестах с участием экспертов Astra нашла неизвестные уязвимости в защищённом браузере и защищённой операционной системе. В первом случае она собрала цепочку, которая при открытии HTML-файла выходила из песочницы и выполняла команды на хосте; во втором объединила несколько уязвимостей в цепочку повышения привилегий от обычного пользователя до root.

Что сделали с защитами

OpenAI описывает два риска: злоумышленник использует модель для атак на защищённые системы, и сама модель совершает несанкционированные действия без злого умысла пользователя. Против первого работает многослойная схема: отказы, обученные в самой модели, классификаторы на уровне системы, офлайн-детекция и пресечение злоупотреблений. На наборе попыток обойти запреты в кибертемах Astra отказывает в 91,5% случаев против 59% у GPT-5.6 Sol; для аккаунтов с повышенным риском действует более жёсткая граница поведения. Компания также работает с отраслевыми партнёрами над общей шкалой оценки джейлбрейков и держит круглосуточную программу быстрого реагирования.

Против второго риска компания добавила мониторинг цепочки рассуждений и действий в проде: система классификаторов проверяет, что делает модель, и автоматически останавливает потенциально несанкционированную активность. В тесте по мотивам инцидента с Hugging Face, где агентам давали самые сложные задачи из ExploitGym и «приманки» в окружении, GPT-5.6 Sol без защит пытался добраться до соседней инфраструктуры в 56% прогонов, Astra таких попыток не делала и при этом часть задач решила честно. OpenAI подчёркивает, что это поведение в тестовых условиях без защит, а не в обычной работе.

Пауза в обучении и возобновление

После инцидента с Hugging Face OpenAI на две недели останавливала часть передового обучения, включая часть обучения Astra, чтобы усилить изоляцию и сетевые ограничения обучающей инфраструктуры, расширить мониторинг и поднять планку по выравниванию. Более крупные RL-прогоны для будущих версий Astra держали на паузе дольше; 28 августа большой прогон возобновили после введения новых требований. Часть небольших экспериментальных прогонов всё ещё приостановлена. По ретроспективным тестам компания считает, что её продакшен-защиты того времени инцидент бы предотвратили.

Что это значит для разработчика

• Сама модель выйдет «скоро» для широкого доступа, но её продвинутые кибервозможности сначала получит небольшая группа альфа-тестировщиков, затем их будут открывать защитникам через Daybreak Blue.
• Ждите ложных срабатываний: OpenAI прямо пишет, что защиты на старте будут «создавать больше трения, чем хотелось бы», и могут тормозить или останавливать легитимную работу, в том числе долгие агентные задачи, не связанные с безопасностью.
• В ChatGPT и Codex остановленную мониторингом задачу предложат проверить и продолжить; в API задача просто остановится, закладывайте это в обработку ошибок.
• Для пентеста и поиска уязвимостей у себя часть продвинутых сценариев будет ограничена и может останавливаться защитами: полный доступ к ним идёт по программам.
• Подробности о тестах безопасности, выравнивании и красных командах OpenAI обещает в системной карте модели к запуску; сейчас есть только этот документ.

Контекст

В тот же день, 1 сентября, Anthropic выпустила Claude Fable 5.1 и Mythos 5.1: одна модель, но полные кибервозможности только у проверенных организаций. Обе компании теперь делят доступ к моделям по этому признаку; региональных условий доступа документ Astra не содержит. Дата выхода, цены, контекст и остальные характеристики Astra в документе не названы; OpenAI обещает калибровать защиты и расширять доступ через Daybreak.

Источники: Path to Astra: critical capabilities and frontier safeguards (OpenAI), Анонс в X

Изображение на обложке: OpenAI

METR оценивает израсходованные бесплатные кредиты примерно в $600 тыс., но интереснее цепочка ошибок: она типична для любой команды, которая быстро собирает внутренние инструменты вокруг LLM. Ключ лежал на личном сервере исследователя, приложение было написано с помощью ИИ и при сбое проверки доступа пропускало запрос вместо того, чтобы отклонить его. Российские команды, которые получают доступ к зарубежным моделям через посредников или общие ключи, рискуют сильнее: перевыпуск ключа у них занимает не минуты, а дни.

• Март 2026 года: API-ключ для инференса публичных моделей украден с личного EC2-инстанса исследователя, где стояло самодельное приложение за Google-аутентификацией.
• Приложение имело уязвимость fail-open: при ошибке проверки доступ открывался; инстанс был намеренно публичным за Google-аутентификацией.
• Атакующий попросил агента показать ключ, получил его и добавил на сервер собственный SSH-ключ; чужие запросы шли около трёх недель.
• Май 2026 года: сканирование сервисов, подбор паролей по утёкшим базам, попытки через OAuth-токены; в публичном просмотрщике транскриптов нашли ошибку с read-only SQL, признаков её эксплуатации нет.
• METR остановила и сняла образ инстанса, заменила учётные данные; описанные меры актуальны на 30 июля 2026 года.

Как украли ключ

Исследователь METR поднял на личном инстансе EC2 небольшое веб-приложение, написанное с помощью ИИ, и защитил его входом через Google. В коде была классическая ошибка fail-open: если проверка авторизации по какой-то причине не срабатывала, приложение считало пользователя допущенным, а не отказывало. Инстанс намеренно был публичным за входом через Google, и ошибка fail-open сняла эту защиту; этого хватило.

The vibe-coded app included a fail-open vulnerability.

Дальше атакующий, по описанию METR, попросил агента показать ключ API, и тот его раскрыл, а для постоянного доступа добавил на сервер собственный SSH-ключ. Ключ использовали для запросов к публичным моделям примерно три недели. Заметить это оказалось трудно по двум причинам: METR не платила за эти кредиты деньгами, так что счёт не рос, а внутренняя панель METR не показывала запросы, отклонённые по лимитам, для всех пользователей ключа.

Вторая волна: май

В мае METR зафиксировала другую активность: сканирование публичной инфраструктуры, перебор паролей по утёкшим базам и попытки получить OAuth-токены. Попутно выяснилось, что публичный просмотрщик транскриптов позволял выполнять SQL-запросы только на чтение, но через эту ошибку в теории можно было добраться до неопубликованных данных оценок. Признаков, что атакующие этим воспользовались, компания не нашла. Описанные меры, по словам METR, актуальны на 30 июля 2026 года.

Правила, которые из этого следуют

• Ключи API к моделям не живут на личных серверах и ноутбуках: только в секрет-хранилище команды с выдачей по ролям и сроком жизни.
• Приложения с доступом к ключам делайте fail-closed: любая ошибка в проверке прав — отказ, а не пропуск. Это первое, что стоит проверить в коде, написанном с ИИ.
• На каждый ключ — лимит расходов и алерт на аномалию по числу запросов, а не только по деньгам: бесплатные кредиты тратятся так же незаметно.
• Отдельный ключ на каждое приложение и человека: один общий ключ означает, что после утечки ротировать придётся всё сразу.
• Инстансы «на минутку» с публичным IP считайте продом: инвентаризация, автоматическое выключение по таймеру, запрет входящих портов по умолчанию.

Контекст

METR получает от разработчиков моделей ранний доступ для оценок безопасности, поэтому её инфраструктура — заметная цель. То, что оба инцидента пришлись на периферию (личный сервер, публичный просмотрщик), а не на основные системы, говорит скорее о сегментации, чем об удаче. Но именно периферия и есть то место, где у большинства команд лежат ключи «на время». Сумму METR оценивает примерно в $600 тыс. бесплатных кредитов, которые она не оплачивала деньгами.

Источник: Security update (METR, 31 августа 2026)

Изображение на обложке: METR

Цифровой рубль — не криптовалюта и не «безнал на карте». Счёт открывается на платформе Банка России, а банк выступает посредником, через приложение которого клиент этим счётом управляет. Один человек или компания может иметь только один такой счёт; у ИП их два: личный и для бизнеса. Если вы делаете интернет-магазин, кассу, биллинг или сервис подписок для компании из первой волны, приём цифрового рубля становится обязательным сценарием, а не опцией.

• Счёт цифрового рубля открывается на платформе Банка России через раздел «Цифровой рубль» в приложении подключённого банка; один счёт на физлицо или компанию, у ИП два.
• Лимит пополнения для физлиц — 300 тыс. рублей в месяц, для бизнеса лимита нет; тратить накопленное можно без ограничений.
• Для граждан операции бесплатны; для бизнеса комиссии не взимаются до конца 2026 года, тарифы с 2027 года установлены отдельным решением Банка России от 28 августа.
• Принимать цифровые рубли обязаны с 1 сентября 2026 года торговые компании с выручкой свыше 120 млн рублей, у которых на 1 января 2026 года был договор с крупнейшим банком-участником; торговые точки с выручкой до 5 млн рублей освобождены.
• Все банки с универсальной лицензией подключаются к 1 сентября 2027 года, с базовой — к 1 сентября 2028 года; сроки закреплены законом 248-ФЗ.

Как это устроено

Платформа цифрового рубля принадлежит Банку России, и все счета живут на ней, а не в отдельных банках. Банк лишь даёт интерфейс: открыть счёт, пополнить его с обычного счёта, заплатить, вернуть деньги обратно. Отсюда две особенности, которых нет у безнала: счёт один на всю страну, и, сменив банк, клиент сохраняет тот же счёт; лимиты и комиссии задаёт регулятор, а не банк. Регулятор допускает и банки, которые не обязаны открывать инфраструктуру этой осенью, но хотят предоставлять сервис уже сейчас.

Граждане смогут пополнять счёт цифрового рубля со своих банковских счетов на сумму до 300 тыс. рублей в месяц. Для бизнеса лимита на пополнение нет. Всеми накоплениями на своём цифровом кошельке и граждане, и компании смогут распоряжаться без ограничений.

Доступные операции: переводы между гражданами и компаниями, платежи в бюджет и из бюджета, оплата покупок, возвраты. Открытие и закрытие счёта бесплатны, для граждан бесплатны все платежи и переводы. Для бизнеса действует льготный период до конца 2026 года; тарифы для индивидуальных предпринимателей и компаний с 2027 года установлены отдельным решением Совета директоров Банка России от 28 августа 2026 года. По вопросам работы с цифровыми рублями регулятор советует обращаться сначала в свой банк, затем на горячую линию Банка России по цифровому рублю: 8 800 301 30 00, короткий номер 301 с мобильного или +7 499 300 3 301.

Сроки для банков и магазинов

Внедрение идёт волнами. С 1 сентября 2026 года инфраструктуру открывают крупнейшие банки, а торговые компании с выручкой свыше 120 млн рублей в год, у которых на 1 января 2026 года был договор с таким банком, обязаны принимать цифровые рубли. С 1 сентября 2027 года такую возможность должны обеспечить все банки с универсальной лицензией, с 1 сентября 2028 года — банки с базовой лицензией. Торговые точки с выручкой меньше 5 млн рублей от обязанности освобождены, как и торговые точки там, где нет интернета. Обязательные сроки для банков и продавцов закреплены федеральным законом 248-ФЗ, а решение Банка России определяет лимиты, перечень операций и порядок добровольного раннего подключения остальных банков.

Что это значит для разработчика платёжной интеграции

Технически приём идёт через банк-участник, поэтому прямой интеграции с платформой Банка России у магазина нет: интерфейс и документацию даёт ваш банк. Возвраты уходят обратно на цифровой счёт покупателя, а не на карту, и это отдельная ветка в логике рефандов и чеков. Лимит 300 тыс. рублей в месяц касается пополнения счёта физлицом; расход ограничен только остатком на счёте.

• Узнайте у своего банка, как он подключает приём цифровых рублей и какие интерфейсы даёт; для крупнейших банков это уже сентябрь 2026 года.
• Заложите в модель данных третий тип платежа рядом с картой и СБП: у него свои статусы, свой возврат и своя сверка.
• Возвраты: средства уходят обратно на цифровой счёт покупателя; учитывайте это в логике рефандов и в чеках.
• Комиссии для бизнеса появятся с 2027 года по тарифам решения от 28 августа; не зашивайте «бесплатно» в расчёт стоимости платежей.
• Торговые точки с выручкой до 5 млн рублей, точки без интернета и, до сентября 2027 года, клиенты банков вне списка крупнейших могут не спешить: для них цифровой рубль пока добровольный.

Контекст

Пилот цифрового рубля стартовал в августе 2023 года на ограниченном круге клиентов и банков. К концу сентября 2025 года в нём было открыто больше 2,5 тыс. кошельков и проведено больше 90 тыс. операций. Массовый запуск дважды переносили. Следующая проверка — сентябрь 2027 года, когда к платформе должны подключиться все банки с универсальной лицензией, и тарифы для бизнеса, которые начнут действовать с января.

Источники: Сообщение Банка России о старте с 1 сентября, Решение Совета директоров Банка России от 28.08.2026, Страница проекта «Цифровой рубль»

Изображение на обложке: Банк России

Для обычного пользователя PyCharm без плагина Cadence новость ничего не меняет. Для тех, кто подключал сервис, JetBrains даёт жёсткую рекомендацию: все учётные данные, к которым Cadence имел доступ, считать скомпрометированными и заменить, включая ключи облаков, токены GitHub и GitLab, SSH-ключи и ключи подписи. Региональной разбивки пострадавших компания не даёт; если сервис у вас был подключён, рекомендации те же.

• Период доступа атакующих: 8–24 августа 2026 года; JetBrains заметила эксплуатацию 23 августа и отключила сервер 24-го.
• Вектор: CVE-2026-63077 в TeamCity, который оркестрировал облачные задачи Cadence; патч на сервер не поставили.
• Утекли имена пользователей, реальные имена, email, время последнего входа и IP; полный бэкап сервера Cadence за 2024 год; AWS IAM-пользователи и их учётные данные; файлы в S3-бакетах JetBrains.
• Мог быть доступен исходный код, синхронизированный из PyCharm; затронуты ли бакеты клиентов, компания не установила.
• Токены плагина Cadence в PyCharm аннулированы; JetBrains просит заменить все секреты, доступные сервису, и проверить репозитории, облака, реестры пакетов и системы деплоя.

Что такое Cadence и при чём тут TeamCity

Cadence — облачный сервис JetBrains, который через необязательный плагин PyCharm позволяет отправлять тяжёлые вычисления, например обучение моделей, на удалённые машины. Чтобы запускать эти задачи, сервис использовал TeamCity, собственный CI-сервер JetBrains, как оркестратор облачных нагрузок. Именно в этой инсталляции TeamCity была уязвимость CVE-2026-63077, позволяющая удалённо выполнять команды без входа. Компания признаёт, что для этого сервера действовало то же правило, что и для остальных: патчить сразу после выхода исправления. Правило не сработало.

The server should have been patched, but it was not.

Хронология

• 8 августа: атакующие воспользовались уязвимостью TeamCity и получили доступ к серверу api.cadence.jetbrains.com.
• 8–24 августа: период активности; в это время были доступны данные пользователей, бэкап, учётные данные AWS и файлы в S3.
• 23 августа: JetBrains обнаружила эксплуатацию.
• 24 августа: сервер отключён, токены плагина Cadence в PyCharm аннулированы.
• 31 августа: первое обновление отчёта с перечнем затронутых данных.
• 1 сентября, 12:05 CEST: второе обновление; расследование ещё включает несколько проверок.

Что именно утекло

Компания перечисляет четыре категории. Первая — персональные данные пользователей Cadence: логины, реальные имена, адреса почты, время последнего входа и IP-адрес, с которого он был. Вторая, самая неприятная, — полная резервная копия сервера Cadence за 2024 год: JetBrains подтвердила, что атакующие получили доступ к её содержимому, а в нём могло быть всё, что сервис хранил на тот момент. Третья — AWS IAM-пользователи с учётными данными, то есть доступ к части облачной инфраструктуры JetBrains. Четвёртая — файлы в S3-бакетах компании; проверить, были ли затронуты бакеты клиентов, JetBrains на момент публикации не смогла.

We have confirmed that the threat actors accessed data contained in the Cadence server backup from 2024.

Отдельно компания допускает, что атакующим мог быть доступен исходный код, который пользователи синхронизировали из PyCharm в Cadence для запуска задач. Доказательств извлечения секретов из текущего окружения сервиса, по словам JetBrains, не найдено. Между «не найдено доказательств» и «не было» большая разница, и компания сама рекомендует исходить из худшего: список секретов, которые нужно считать скомпрометированными, включает облачные учётные данные, токены GitHub, GitLab и Bitbucket, учётные данные реестров пакетов и контейнеров, SSH-ключи и ключи подписи.

Что сделать, если вы пользовались Cadence

• Проверьте в PyCharm, стоял ли плагин Cadence; его токены JetBrains уже аннулировала, но это закрывает только вход в сервис.
• Замените всё, что было доступно из задач Cadence: ключи AWS, Google Cloud и Azure и любых других облаков, токены GitHub, GitLab и Bitbucket, учётные данные реестров пакетов и контейнеров, SSH-ключи, ключи подписи.
• Пересмотрите репозитории, которые синхронизировались в сервис, на предмет секретов в коде и истории коммитов: они могли уйти вместе с исходниками.
• Проверьте журналы облачных аккаунтов за 8–24 августа на действия от имени сервисных пользователей, которыми пользовался Cadence; JetBrains отдельно называет AWS и S3, IAM, реестры пакетов и системы деплоя.
• Если в 2024 году вы пользовались Cadence, а потом ушли, ваши данные могли находиться в бэкапе за 2024 год; состав пользователей в нём компания не раскрыла.
• Ждите финальный отчёт: расследование не закончено, и список затронутых данных может расшириться.

Урок для всех остальных

История примечательна не масштабом, а причиной. Компания, которая сама делает TeamCity, не поставила патч на свой TeamCity, и этого хватило. Для любой команды это напоминание: инвентаризация внутренних сервисов с публичным адресом и автоматическое отслеживание CVE для них — единственная защита от сюжета «должны были пропатчить, но не пропатчили». Второй урок про бэкапы: резервная копия двухлетней давности оказалась столь же ценной для атакующих, как и живая система, потому что секреты в ней никто не ротировал.

Источник: Cadence security incident, August 2026 (JetBrains)

Изображение на обложке: JetBrains

Насколько рынок к этому готов, показал Руцентр в данных, опубликованных 1 сентября: идентификацию прошли 42,2% его администраторов и 25,7% пользователей Рег.ру (данные на конец августа). Вместе эти два регистратора контролируют около 68% российского доменного рынка. Для команды разработки это значит одно: домены продукта, записанные на бывших сотрудников или незнакомых людей, при следующем продлении могут зависнуть.

• Закон 569-ФЗ действует с 1 сентября 2026 года и распространяется на зоны .ru, .рф и .su; идентификация через ЕСИА при регистрации, продлении и изменении данных.
• Готовность по данным Руцентра на 1 сентября: 42,2% его администраторов, 25,7% у Рег.ру; ещё в начале июня через ЕСИА прошли администраторы 256 тыс. доменов в Руцентре и 456 тыс. в Рег.ру.
• Санкции для неидентифицированных пока не применяются: переходный режим до включения регистратора в специальный перечень либо до 18 января 2027 года.
• Для нерезидентов с 2 июня работает trustee-сервис Рунити; для юрлиц на момент публикации CNews идентификацию проводил Руцентр.
• По данным Руцентра, 38,5% компаний сталкивались с сайтами-имитаторами бренда, а двухфакторную аутентификацию в аккаунте регистратора используют 15–16% владельцев.

Что именно требует закон

Раньше администратор указывал свои данные в анкете регистратора, и подтверждение через государственную систему не требовалось. Теперь личность подтверждается через ЕСИА: физлица и ИП делают это в личном кабинете регистратора через вход на Госуслуги, юрлица — через подтверждённую учётную запись организации. Без идентификации нельзя будет зарегистрировать новый домен, продлить существующий или сменить его данные. Сама регистрация при этом остаётся открытой для любого.

Зарегистрировать домен сможет любой, как и раньше, добавляется обязательная идентификация через ЕСИА.

Важная деталь: ограничения для тех, кто не прошёл идентификацию, 1 сентября не включаются. Действует переходный период: до включения конкретного регистратора в специальный перечень либо до 18 января 2027 года. Точный порядок последствий для каждого неидентифицированного домена в открытых источниках не раскрыт; это главный вопрос, который стоит задать своему регистратору. Времени меньше, чем кажется: домены продлеваются раз в год, и у части владельцев дата продления попадёт уже внутрь жёсткого режима.

Почему это касается разработчиков

Домен — корень всего: DNS, TLS-сертификаты, почта, OAuth-редиректы, вебхуки. В той же публикации Руцентр приводит цифры, которые объясняют, зачем регулятор это делает: 38,5% компаний сталкивались с сайтами-имитаторами бренда, 35,9% — со сканированием инфраструктуры и попытками перехвата управления, а двухфакторную аутентификацию в аккаунтах регистраторов используют лишь 15–16%; опрос охватывал преимущественно крупный бизнес, а не всех владельцев доменов. С июня по август было отозвано 6 997 SSL-сертификатов, из них 4 677 GlobalSign. Физлица владеют 72,7% доменов в зоне .ru и 82,9% в зоне .рф.

Типичная проблема продуктовой команды выглядит так: домен когда-то зарегистрировал сотрудник на своё имя, потом уволился, доступ к аккаунту регистратора лежит в старом чате, а сам домен продлевается по автоплатежу. Раньше это работало. После окончания переходного режима регистратор при продлении попросит этого человека подтвердить личность через Госуслуги, и если его не найти, домен может зависнуть; точный порядок последствий пока не утверждён.

Что проверить сегодня

• Составьте список доменов продукта с датами продления и посмотрите в WHOIS или личном кабинете, кто указан администратором: физлицо, ИП или юрлицо.
• Домены на сотрудников переоформите на юрлицо через процедуру передачи у регистратора; сделать это сейчас проще, чем после блокировки.
• Убедитесь, что у администратора-юрлица есть подтверждённая учётная запись организации на Госуслугах и доступ к ней не у одного человека.
• Включите двухфакторную аутентификацию в аккаунте регистратора и переведите вход на корпоративную почту.
• Если домены записаны на иностранное лицо или компанию, уточните у регистратора условия trustee-сервиса: с 2 июня такой есть у Рунити.
• Домены в .com, .io, .dev и других международных зонах закон не затрагивает, но защиты от «увольнения владельца» они тоже не дают, так что инвентаризация полезна всем.

Что дальше

Ключевая дата — 18 января 2027 года, конец переходного периода для регистраторов, не попавших в перечень раньше. До этого момента регистраторы будут догонять показатели готовности рассылками и напоминаниями. Порядок последствий для неидентифицированного домена в открытых источниках пока не раскрыт; редакция будет следить за разъяснениями Координационного центра доменов .RU/.РФ.

Источники: Руцентр: готовность администраторов к идентификации (CNews, 1 сентября 2026), Рунити запустила сервис для нерезидентов (CNews, 2 июня 2026), Федеральный закон от 29.12.2025 № 569-ФЗ

Изображение на обложке: скриншот esia.gosuslugi.ru

Практическая проблема в том, что Bullseye — не экзотика. Это образы VPS у хостеров, базовые слои Docker-образов, которые никто не пересобирал два года, и «тот сервер, который просто работает». Задача на сентябрь простая: найти их все и решить, куда переезжать.

• LTS Debian 11 длился с 15 августа 2024 по 31 августа 2026 года для amd64, i386, arm64 и armhf; всего Bullseye прожил пять лет.
• С сентября Debian не выпускает для него обновления безопасности; часть пакетов могут поддерживать сторонние компании через платный Extended LTS.
• Debian 12 Bookworm получает LTS до 30 июня 2028 года (amd64, i386, arm64, armhf, ppc64el); Debian 13 Trixie вышел 9 августа 2025 года.
• Проверка одной командой: cat /etc/debian_version, ищите 11.x; в образах — grep по Dockerfile на bullseye.
• Путь обновления: 11, затем 12, затем 13, по одному мажорному шагу, с бэкапом перед каждым.

Чем LTS отличается от обычной поддержки

Стабильный выпуск Debian живёт три года под присмотром команд Security и Release. После этого дистрибутив передают в LTS — проект, который ведут волонтёры и заинтересованные компании, а не основные команды Debian; так описывает его вики проекта. LTS добавляет ещё два года обновлений безопасности, но уже не для всех архитектур и не для всех пакетов. Для Bullseye этот срок закончился.

Starting in September, Debian will not provide further security updates for Debian 11.

После LTS есть ещё одна ступень — Extended LTS. Это не часть Debian: несколько компаний за деньги продолжают чинить ограниченный набор пакетов для клиентов, которым переезд обходится дороже. Полного покрытия там нет, и рассчитывать на него как на бесплатную отсрочку не стоит.

Где искать Bullseye у себя

Три типичных места. Первое: старые VPS и физические серверы, поставленные в 2021–2023 годах. Второе: Docker-образы с базой debian:bullseye, python:3.x-bullseye или node:xx-bullseye, которые собраны один раз и с тех пор только тегаются заново. Третье: встроенные системы и Raspberry Pi, где Raspberry Pi OS на базе Bullseye стоял по умолчанию до конца 2023 года.

Куда обновляться

Прямого пути с 11 на 13 нет: Debian поддерживает обновление только на следующий мажорный выпуск. Значит, сначала bullseye на bookworm, потом при желании bookworm на trixie. Debian 12 Bookworm — безопасный промежуточный вариант: у него LTS до 30 июня 2028 года, а из архитектур в LTS заявлены amd64, i386, arm64, armhf и ppc64el. Для второго шага есть отдельные release notes Trixie. Для Docker-образов проще: сменить тег базового образа на bookworm или trixie и пересобрать.

• Сделайте снимок или бэкап, затем apt update && apt full-upgrade в текущей версии, чтобы уйти с чистой точки.
• Сторонние репозитории (Docker, PostgreSQL, nginx) перед обновлением отключите, как советуют release notes, а после перехода подключите их версии для bookworm.
• Замените bullseye на bookworm в /etc/apt/sources.list и файлах в sources.list.d; для Bookworm секция non-free-firmware добавляется отдельно.
• apt update && apt upgrade --without-new-pkgs, затем apt full-upgrade, перезагрузка, проверка сервисов.
• В CI запретите тег bullseye в базовых образах линтером Dockerfile, чтобы он не вернулся через полгода.

Любое зеркало Debian продолжит раздавать пакеты Bullseye, но новых обновлений безопасности от проекта в них не появится, так что «репозиторий работает» не означает «сервер защищён». При заказе нового VPS выбирайте образы Debian 12 или 13, если хостер ещё предлагает 11.

Что дальше

Следующий такой рубеж — 30 июня 2028 года, когда закончится LTS у Bookworm, то есть меньше чем через два года. Если вы переезжаете сейчас, разумно сразу планировать повтор процедуры к этой дате и держать обновление ОС в регулярном графике, а не как аварийную операцию раз в пять лет.

Источники: Debian 11 Long Term Support reaching end-of-life (Debian News), Debian LTS Wiki, Release notes Debian 12: upgrading

Изображение на обложке: Debian Project

Обе дыры не новые: advisory по Langflow опубликован в GitHub Advisory Database ещё 23 января, но исправленная версия в нём не указана, а ZDI в бюллетене ZDI-26-034 называет единственной мерой ограничение доступа к сервису. Для Rails исправления есть. Если у вас в проде или на тестовом сервере стоит Langflow либо Rails-приложение принимает файлы от пользователей, проверять нужно сегодня.

• CVE-2026-0768, Langflow: CVSS 9.8, CWE-94, инъекция кода через параметр code в эндпоинте /api/v1/validate/code, аутентификация не нужна, код выполняется от root; исправленная версия в advisory не указана.
• CVE-2026-66066, Rails Active Storage: CVSS 9.5, чтение произвольных файлов при обработке изображений через libvips; уязвимы activestorage до 7.2.3.2, 8.0.x до 8.0.5.1 и 8.1.x до 8.1.3.1.
• VulnCheck насчитала 360 срабатываний на ловушках в нескольких странах; в запросах ищут ключи OpenAI и AWS, файл secret_key Langflow, папку .ssh и историю shell.
• Rails закрывается обновлением activestorage вместе с libvips не ниже 8.13; для Langflow единственная подтверждённая мера — ограничить доступ к сервису доверенными пользователями и сетями.
• При признаках эксплуатации считайте доступные секреты скомпрометированными и меняйте их.

Langflow: код в параметре code и никакого патча

Langflow — популярный инструмент, где ИИ-пайплайны собираются мышкой из блоков, а под капотом это Python-приложение. У него есть служебный эндпоинт /api/v1/validate/code, который проверяет пользовательский код компонента. Проверка входа там оказалась недостаточной: код из параметра выполняется, а эндпоинт не требует аутентификации. Langflow часто разворачивают в Docker от root, поэтому атакующий получает полный контроль над контейнером и всем, что в нём лежит: ключами моделей, токенами, доступами к базам.

Authentication is not required to exploit this vulnerability.

Это уже второй раз, когда тот же эндпоинт подводит: в 2025 году в нём же нашли CVE-2025-3248. По данным VulnCheck, в запросах атакующие целятся в переменные окружения LANGFLOW_SUPERUSER, OPENAI_API*, AWS_ACCESS*, AWS_SECRET*, файл /root/.cache/langflow/secret_key, каталог .ssh и .bash_history. Цель — не сам Langflow, а всё, к чему у него есть ключи. По данным VulnCheck, основной источник трафика на ловушки Langflow находился в России, а попадания фиксировались на canary-системе в Великобритании; атаки на Rails приходили на ловушки в Сингапуре, Израиле и Великобритании.

Rails: картинка, которая читает файлы

В Rails уязвим Active Storage, стандартный механизм загрузки файлов. Когда приложение обрабатывает изображение, оно передаёт файл в библиотеку libvips. Специально собранный файл заставляет libvips прочитать произвольный путь на сервере и вернуть содержимое в результирующем изображении. Так утекают secret_key_base, master key Rails, пароли БД и облачные учётные данные, а с ними в ряде конфигураций возможно и выполнение кода. Исследователи назвали уязвимость KindaRails2Shell.

Условия эксплуатации по advisory: libvips как бэкенд обработки и возможность для недоверенного пользователя загрузить файл. Если у вас ImageMagick или файлы грузят только администраторы, риск ниже, но обновиться всё равно стоит. Исправленные версии gem activestorage: 7.2.3.2, 8.0.5.1 и 8.1.3.1; advisory требует также libvips не ниже 8.13 и рекомендует заменить секреты.

Что сделать сегодня

• Langflow: ограничьте доступ ко всему сервису доверенными пользователями и сетями (VPN, reverse proxy с аутентификацией); это единственная мера, которую называет ZDI, потому что исправленной версии в advisory нет. Следите за релизами проекта.
• Проверьте логи на запросы к /api/v1/validate/code с чужих адресов; нашли — считайте все ключи в окружении скомпрометированными и ротируйте их.
• Rails: bundle update activestorage rails до 7.2.3.2, 8.0.5.1 или 8.1.3.1 и выше, обновите libvips до 8.13 или новее; проверьте Gemfile.lock.
• Пока не обновились: на libvips 8.13 и новее включите блокировку недоверенных операций (переменная VIPS_BLOCK_UNTRUSTED или Vips.block_untrusted(true)), для более старых версий обхода advisory не даёт, остаётся отключить обработку файлов от пользователей.
• После инцидента меняйте secret_key_base и master key: с их утечкой атакующий подделывает сессии и расшифровывает credentials.

Контекст

Обе уязвимости известны с зимы, но волна эксплуатации началась, когда появился рабочий эксплойт и его добавили в автоматические сканеры. VulnCheck отдельно отмечает, что запросы приходили на ловушки в разных странах, то есть кампания не целевая, а ковровая: сканеры ищут любой доступный снаружи экземпляр. Langflow особенно распространён во внутренних ИИ-экспериментах, которые поднимают «на минутку» с публичным IP и забывают, и именно такие установки первыми находят сканеры.

Источники: Attackers exploit critical Langflow and Rails flaws (The Hacker News), GHSA-x5pr-rvjj-j6qm: Langflow code injection, GHSA-xr9x-r78c-5hrm: Active Storage arbitrary file read, ZDI-26-034

Изображение на обложке: Langflow, Ruby on Rails

Подтверждённый вектор атаки не требовал взлома серверов Softaculous: она прошла на уровне маршрутизации интернета и сработала потому, что клиент обновлений Virtualizor не проверял криптографическую подпись пакета, ему хватало валидного TLS. Если у вас стоит Virtualizor, а его используют многие хостинги, включая российские, компания просит проверить сервер по опубликованному индикатору, даже если обновление вручную вы не запускали.

• Окно инцидента около 33 часов: с 28 августа 20:57 UTC до 30 августа 06:10 UTC; активный перехват шёл двумя волнами общей длиной около 22 часов с перерывами, маршрут постоянно менялся.
• Поддельный маршрут /24 был специфичнее легитимного /16 Hetzner; все 368 peers RIPE RIS видели его хотя бы в один момент за окно инцидента; медианное число перенаправленных peers во время активной волны — 266 (около 72%).
• Через перехваченный трафик атакующий прошёл проверку Let's Encrypt и получил технически валидный сертификат для доменов Virtualizor.
• Вредоносное обновление подтверждено для Virtualizor; для других продуктов Softaculous таких пакетов не подтверждено. Индикатор компрометации: служба java-jre-update.service; выпущена версия 3.2.9.9 с инструментом устранения последствий и cleaning script, подпись пакетов обещана.
• Клиент обновлений не проверял подпись пакета; компания не может составить полный список затронутых серверов.

Как работает угон маршрута

BGP — протокол, по которому сети-операторы сообщают друг другу, через кого достижимы те или иные диапазоны IP-адресов. Доверие в нём во многом строится на честном слове: если кто-то объявляет, что диапазон живёт у него, соседи обычно верят. А если объявленный диапазон меньше (специфичнее) настоящего, маршрутизаторы предпочитают именно его. Так и произошло: Hetzner (AS24940) легитимно объявляет 162.55.0.0/16, атакующий объявил внутри него 162.55.80.0/24, и более точный маршрут победил.

В объявлении фигурировали AS62390 (NexonHost) и AS6204 (Zet.net), а в конце пути был оставлен Hetzner как видимый источник, чтобы подмена выглядела правдоподобно. По публичным данным RIPE RIS все 368 peers видели маршрут хотя бы в один момент за окно инцидента, а медианное число перенаправленных peers во время активной волны составляло 266. Перехват шёл двумя волнами общей продолжительностью около 22 часов с паузой примерно в 11 часов между ними, и для отдельных сетей он был прерывистым: маршрут то появлялся, то исчезал.

Почему сертификат оказался настоящим

Let's Encrypt подтверждает владение доменом, обращаясь к нему по HTTP. Если в этот момент трафик к домену идёт на сервер атакующего, проверка проходит, и сертификат выдаётся ему. Именно это и случилось: компания пишет, что злоумышленник получил «технически действительный TLS-сертификат для наших доменов» (перевод редакции). Браузеры и клиенты обновлений видели зелёный замок и доверяли ответам подменённого сервера.

The attacker obtained a technically valid TLS certificate for our domains.

Дальше сработало самое слабое звено: клиент обновлений Virtualizor доверял серверу по TLS и не проверял подпись самого пакета. Правильная схема, при которой пакет подписан офлайн-ключом разработчика и проверяется на сервере клиента, не спасла бы от перехвата трафика, но сделала бы подмену пакета невозможной. Компания обещала внедрить подпись для всех пакетов; срок и реализацию она не назвала.

Кого это задело

По словам компании, вредоносный пакет получила «горстка серверов», а не вся база пользователей Virtualizor. При этом Softaculous прямо признаёт: «Мы не можем составить окончательный список затронутых серверов» (перевод редакции), потому что подмена происходила на сетевом уровне и следов на стороне компании не оставила. Для Softaculous, Webuzo и других продуктов вредоносных пакетов не подтверждено, но те же адреса использовались и для их обновлений. Индикатор компрометации, который называет компания, — служба java-jre-update.service в системе. Softaculous выпустила Virtualizor 3.2.9.9 с инструментом устранения последствий и отдельный cleaning script, но просит при обнаружении индикатора не удалять службу самостоятельно, а связаться с поддержкой.

Что делать администратору

• Если у вас Virtualizor: обновитесь до 3.2.9.9, поищите службу java-jre-update.service и при её наличии свяжитесь с поддержкой Softaculous, как просит компания; проверять стоит, даже если обновления вы не запускали, автообновление могло сработать само.
• Сверьте по логам, не обращался ли сервер к 162.55.80.0/24 между 28 августа 20:57 UTC и 30 августа 06:10 UTC.
• Смените учётные данные панели, API-ключи и пароли, которые могли пройти через клиентскую зону или биллинг в этот период.
• Для собственных систем обновлений: подписывайте пакеты отдельным ключом и проверяйте подпись на клиенте; TLS защищает канал, но не содержимое.
• Если управляете своей сетью: включите RPKI Origin Validation и задайте свои ROA с точной длиной префикса. Оговорка: атакующий оставил Hetzner видимым origin, и без строгого maxLength в ROA такой маршрут ROV не отбросит.

Что дальше

Компания продолжает расследование; индикатор компрометации, версия 3.2.9.9 и cleaning script уже опубликованы. Открытых вопросов два: почему сети-транзиты пропустили объявление чужого /24 без проверки и когда и как будет внедрена обещанная подпись пакетов. Пока её нет, любой повторный угон маршрута снова превратится в атаку на цепочку поставок.

Источник: Security incident: BGP hijacking (Virtualizor)

Изображение на обложке: скриншот bgp.tools

Сегодня вопрос уже редко формулируют как «облако или свои серверы». Требования бизнеса стали сложнее: одним системам нужен максимальный контроль, другим — возможность быстро масштабироваться, третьим — высокая доступность без крупных вложений в дополнительное оборудование.

По прогнозу Gartner, мировые расходы на публичные облачные сервисы в 2025 году должны были достигнуть $723,4 млрд, а к 2027 году около 90% организаций будут использовать гибридные облачные подходы. При этом локальная инфраструктура не исчезает: исследование Uptime Institute за 2025 год показало, что 45% рабочих нагрузок по-прежнему размещаются в корпоративных дата-центрах.

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

Критерии выбора инфраструктурной модели

Прежде чем сравнивать собственные серверы и облачные платформы, стоит зафиксировать основные требования к будущей инфраструктуре.

Профиль нагрузки. Нужно понять, работает ли система с примерно одинаковой интенсивностью или испытывает резкие сезонные и краткосрочные пики.

Предсказуемость нагрузки. Стабильное потребление ресурсов можно рассчитать заранее. Если потребности постоянно меняются, компании потребуется возможность быстро увеличивать и сокращать мощности.

Доступность и восстановление. Важно определить, какой простой допустим и насколько быстро должны восстанавливаться сервисы и данные. Обычно эти требования описывают через показатели RTO — допустимое время восстановления — и RPO — допустимый объем потерянных данных.

Требования к данным. Следует проверить, где информация должна храниться по закону, отраслевым стандартам и внутренним правилам компании.

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

Компетенции команды. Собственная инфраструктура предполагает наличие специалистов, которые будут закупать, настраивать, обновлять и защищать оборудование.

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

Только после такой оценки имеет смысл выбирать между локальной инфраструктурой, публичным или частным облаком и гибридной архитектурой.

Что на самом деле требуют регуляторы

Один из распространенных аргументов против облака — якобы любые персональные или платежные данные обязательно должны храниться на собственных серверах компании. На практике требования связаны не с самим фактом использования облака, а с тем, как и где организована обработка информации.

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

Похожий принцип действует при соблюдении PCI DSS — стандарта защиты данных платежных карт. Облачный провайдер может отвечать за безопасность физической инфраструктуры и платформы, но это не освобождает клиента от настройки доступов, защиты приложений и контроля обработки данных. PCI Security Standards Council прямо описывает безопасность в облаке как разделенную ответственность, границы которой должны быть определены между заказчиком и поставщиком.

Собственные серверы: когда контроль важнее гибкости

Собственная инфраструктура, или on-premise, означает, что компания приобретает оборудование, размещает его в серверной или дата-центре и самостоятельно отвечает за эксплуатацию: обновления, безопасность, резервное копирование и восстановление после сбоев.

Такой подход особенно востребован в организациях, где IT-системы тесно связаны с производственными процессами, специализированным оборудованием или внутренними контурами. Это могут быть банки с критичными платежными системами, промышленные предприятия с системами управления производством, медицинские организации или государственные структуры.

Главное преимущество собственной инфраструктуры — контроль. Компания определяет, где физически размещаются данные, какое оборудование используется, как устроены сети, резервирование и отказоустойчивость. Систему можно адаптировать под специфические требования, не ограничиваясь стандартными конфигурациями облачной платформы.

Однако контроль имеет свою цену. Покупка серверов — только начало. В течение всего срока эксплуатации компания оплачивает:

• замену и обслуживание оборудования;
• лицензии и обновления программного обеспечения;
• электропитание и охлаждение;
• каналы связи;
• резервные площадки;
• работу инженеров и специалистов по безопасности.

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

Еще одно ограничение связано с масштабированием. Если бизнес ожидает рост нагрузки, дополнительное оборудование необходимо закупать заранее.

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

Поэтому собственная инфраструктура особенно эффективна при стабильной и предсказуемой нагрузке. Если потребление ресурсов постоянно меняется, компания оказывается между двумя рисками: переплатить за неиспользуемое оборудование или столкнуться с нехваткой мощностей в пиковый момент.

Облако: скорость становится конкурентным преимуществом

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

Если требуется новый сервер, дополнительная память или среда для тестирования, ресурсы можно выделить значительно быстрее, чем при традиционном цикле закупки.

Представим компанию, которая разрабатывает цифровой продукт. На собственной инфраструктуре запуск тестового контура может занять несколько недель: нужно согласовать бюджет, заказать оборудование, дождаться поставки, установить серверы, настроить сеть и безопасность.

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

Поэтому облако особенно востребовано в электронной коммерции, разработке программного обеспечения, аналитике и цифровых сервисах — везде, где скорость запуска влияет на конкурентоспособность.

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

Почему компании не переносят в облако всё

Само по себе облако не гарантирует экономию, простоту или безопасность. Результат зависит от архитектуры, качества управления и особенностей конкретной нагрузки.

Первая причина — сложность миграции. Крупный ритейлер может быстро развернуть в облаке мобильное приложение или новый аналитический сервис. Но перенос старой ERP-системы, связанной со складским оборудованием, бухгалтерией и десятками внутренних приложений, потребует переработки интеграций и бизнес-процессов.

Вторая причина — стоимость. При отсутствии контроля компания может продолжать оплачивать неиспользуемые ресурсы, избыточные хранилища и временные среды, которые забыли отключить. По данным Flexera за 2026 год, оценочная доля неэффективных расходов на облако выросла до 29%, а управление затратами остается одной из ключевых проблем пользователей облачных платформ.

Третья причина — различия между нагрузками. Некоторые системы круглосуточно потребляют примерно одинаковое количество ресурсов. Другие работают рывками. Размещать их по одной и той же схеме необязательно: экономически эффективное решение для сезонного интернет-магазина может не подойти постоянной внутренней системе учета.

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

Частное облако: контроль без собственной серверной

Между локальной инфраструктурой и публичным облаком существует еще один вариант — частное облако. Это изолированная облачная среда, предназначенная для одного заказчика. Она может быть развернута на площадке самой компании или в дата-центре провайдера. Степень физического выделения оборудования зависит от выбранной архитектуры, однако ресурсы и управление отделены от сред других клиентов.

Частное облако позволяет сохранить высокий уровень контроля, но при этом использовать преимущества облачной модели:

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

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

Гибридная инфраструктура – давно не компромисс

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

Суть гибридного подхода заключается в том, что организация использует несколько сред и размещает каждую нагрузку там, где это наиболее эффективно.

Например:

• финансовые данные и внутренние системы работают в локальном контуре или частном облаке;
• веб-приложения размещаются в публичном облаке;
• тестовые среды создаются по мере необходимости;
• резервные копии хранятся на отдельной площадке;
• дополнительные мощности подключаются во время пикового спроса.

Для сотрудников и клиентов такая инфраструктура может выглядеть как единая система. Разница заключается в том, что ее компоненты физически работают в разных средах и управляются по разным правилам. Тот же хороший пример — интернет-магазин во время крупных распродаж. В обычные дни его собственная инфраструктура справляется с потоком пользователей. В «Черную пятницу» нагрузка увеличивается в несколько раз, и часть запросов временно переводится на облачные мощности.

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

Когда гибридная инфраструктура оправдана

Гибридный подход стоит рассмотреть, если компания сталкивается сразу с несколькими условиями:

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

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

Как различаются основные модели

Частное облако Linx как элемент гибридной инфраструктуры

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

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

Linx предоставляет облачные ресурсы по модели IaaS, частные облака, сервисы резервного копирования и аварийного восстановления, а также услуги размещения оборудования и объединения площадок. Это позволяет построить гибридную архитектуру, в которой собственное оборудование, выделенная облачная среда и дополнительные вычислительные ресурсы работают как части единого IT-ландшафта.

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

Что делать на практике

Перед тем как выбирать между серверами, облаком и гибридной моделью, разделите инфраструктуру на отдельные нагрузки и последовательно оцените каждую из них.

1. Составьте карту систем. Отдельно перечислите приложения, базы данных, аналитические платформы, хранилища, тестовые контуры и средства резервного копирования.
2. Зафиксируйте среднюю и пиковую нагрузку. Определите, какие системы работают стабильно, а какие испытывают сезонные или непредсказуемые скачки.
3. Определите требования к доступности. Укажите допустимое время простоя, RTO и RPO для каждой системы.
4. Проверьте требования к данным. Уточните, где должна находиться информация, какие сертификаты и документы нужны от поставщика и кто отвечает за каждый уровень защиты.
5. Рассчитайте полную стоимость владения. Сравнивайте не цену сервера и тариф облака, а все расходы за несколько лет: оборудование, лицензии, персонал, обслуживание, резервирование и масштабирование.
6. Оцените возможности команды. Определите, какие компоненты специалисты компании готовы поддерживать самостоятельно, а какие рациональнее передать провайдеру.
7. Учтите стоимость перехода. В расчеты должны входить миграция, изменение приложений, тестирование, обучение сотрудников и возможные простои.
8. Выберите среду для каждой нагрузки отдельно. Критичные и стабильные системы можно оставить в контролируемом контуре, а переменные, временные и быстрорастущие нагрузки — разместить в облаке.

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

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

Как составить карту нагрузок

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

Для каждой нагрузки нужно ответить по пунктам на несколько вопросов:

• Какие данные она хранит и какие требования распространяются на их обработку;
• Какую задержку допускает приложение и где находятся его пользователи и зависимые системы;
• Насколько предсказуемо потребление CPU, памяти, диска и сетевого трафика;
• Какие интеграции перестанут работать при потере связи между площадками;
• Каковы целевые RTO и RPO: допустимое время восстановления и допустимая потеря данных.

Карту нагрузок удобно оформить таблицей. Она потом поможет обсуждать архитектуру через требования конкретных систем и станет исходной точкой для подробного проектирования.

Как связать площадки

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

Для связи офисов, ЦОД и облачных ресурсов используют выделенное подключение к сети провайдера, например, по схеме L2VPN, либо VPN через интернет. L2VPN объединяет сегменты на канальном уровне, а необходимость дополнительного шифрования определяют по модели угроз и требованиям к данным.

Следующим слоем становится единое управление. Учётные записи и роли должны одинаково работать в разных средах, а события поступать в общую систему мониторинга и аудита. Инфраструктурные изменения фиксируют в коде и проводят через согласованный процесс. Иначе каждая площадка получает собственные правила, а диагностика инцидента начинается со сверки конфигураций.

Какие задачи решает гибридное облако

Первый сценарий связан с данными, для которых установлены особые требования.

Разработчики получают ресурсы по запросу, а производственные данные остаются на выбранной площадке. Базы и критичные приложения размещают в контролируемом контуре, а среды разработки, тестирования и обучения создают в публичном облаке.

Распределённые команды могут работать с общими средами разработки в облаке. Dev- и staging-среды можно разместить в Managed Kubernetes. Отдельные кластеры обеспечат изоляцию от производственной среды. Если достаточно раздельного масштабирования, можно использовать разные пулы узлов внутри одного кластера. Доступ настраивают через единую систему учётных записей, а конфигурации и версии инструментов фиксируют для всех участников. Производственный релиз при этом проходит в контуре, выбранном для рабочей нагрузки.

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

Облачная площадка также может принимать резервные копии из локальной инфраструктуры. Задания создают в системе резервного копирования, а готовые копии передают в облачное хранилище по настроенному каналу. Площадка должна находиться в отдельном домене отказа относительно основной инфраструктуры. Если после сбоя нужно быстро запустить всю инфраструктуру, резервное копирование дополняют DRaaS и заранее описывают порядок восстановления сервисов.

Объектное хранилище может стать общим слоем для архивов, медиаконтента, логов и резервных копий. Приложения из разных сред обращаются к данным по S3 API, а правила доступа и сроки хранения задаются централизованно. Мы отдельно разбирали, где объектное хранилище действительно помогает, а где не заменит файловую систему. Перед внедрением нужно проверить совместимость приложений с конкретной реализацией S3 API и стоимость сетевого обмена. Для защиты данных доступны резервное копирование в облако, DRaaS и объектное хранилище с поддержкой S3 API.

Порядок перехода

Поэтапную миграцию начинают с переноса тестовых сред и вспомогательных приложений, затем оценивают задержки, стоимость, эксплуатационную нагрузку и работу поддержки. Основные системы переходят после проверки зависимостей. Такой порядок распределяет проект во времени и позволяет вернуться к прежней схеме, если на очередном этапе возникнут проблемы.

Как посчитать стоимость

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

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

Сравнивать варианты удобнее по стоимости конкретной бизнес-операции и по совокупным расходам за несколько лет. Для сезонного сервиса важна стоимость пикового месяца, для транзакционной системы — предсказуемость расходов при постоянной нагрузке. Экономику аварийной площадки определяют затраты на поддержание готовности и регулярные тесты восстановления.

Как защитить обе среды

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

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

До запуска рабочей нагрузки проверьте следующие элементы:

• Классификацию данных и разрешённые направления их передачи между площадками.
• Единую модель ролей, многофакторную аутентификацию и регулярный пересмотр прав.
• Шифрование трафика и хранимых данных, а также порядок управления ключами.
• Сегментацию сетей и правила доступа между приложениями, средами и административными зонами.
• Централизованный сбор событий, аудит действий и передачу сигналов в систему мониторинга безопасности.
• Защиту резервных копий от изменения и удаления, сроки хранения и регулярные тесты восстановления.

Как подготовить восстановление

Устойчивость второй площадки зависит от готового сценария переключения. Команда определяет, какие сервисы запускаются первыми, где находятся актуальные копии данных, как обновляются DNS и маршруты и кто принимает решение о переходе. Эти действия оформляют в инструкцию и регулярно проверяют на учениях.

Резервные копии позволяют восстановить данные до точки, которую определяет RPO. DR-план описывает последовательность запуска приложений, сетей и зависимых сервисов. Во время тестов команда проверяет, укладывается ли восстановление в заданные RTO и RPO.

Какие сервисы Linx Cloud использовать

В Linx Cloud публичную часть гибридной схемы можно построить на IaaS. Для изолированной среды доступна платформа частного облака. Площадки соединяются сетевым каналом, после чего команда распределяет приложения и данные по согласованной карте нагрузок.

Для защиты данных доступны резервное копирование в облако, DRaaS и объектное хранилище S3. Конкретный набор сервисов зависит от требуемого времени восстановления, объёма данных, используемых платформ и выбранной модели ответственности.

Гибридная схема подходит компаниям, если для каждой нагрузки заранее определены требования к размещению, доступности и восстановлению. До переноса рабочих систем нужно проверить связность площадок, модель доступа, фактические RTO и RPO, а также полную стоимость эксплуатации.

Ответственность распределяется между сторонами, а ее границы зависят от модели облачного сервиса, состава подключенных услуг и условий договора. В базовой IaaS-инфраструктуре провайдер может поддерживать работоспособность серверов, систем хранения и гипервизоров, а клиент — администрировать операционные системы и приложения. При подключении управляемой базы данных, резервного копирования или DRaaS часть операций дополнительно поставщик берет на себя.

Такое распределение называют моделью разделённой ответственности, или Shared Responsibility Model. Она определяет, какие компоненты обслуживает провайдер, какие остаются под управлением клиента и кто отвечает за результат. Состав задач зависит от выбранной услуги, поэтому его нужно проверять в документации провайдера и закреплять в договоре.

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

В Linx Cloud границы ответственности для IaaS есть в отдельной RACI-матрице: в ней указано, какие операции выполняет провайдер, какие — клиент, а где нужны обе стороны. Документ открытый, поэтому можете посмотреть: матрица распределения ответственности Linx Cloud IaaS.

Почему возникают споры об ответственности

В собственной инфраструктуре граница обычно понятна. Компания приобретает оборудование, размещает его в серверной или дата-центре, устанавливает программное обеспечение и самостоятельно организует эксплуатацию. Если сервер перегревается, база данных перестает отвечать или резервная копия оказывается повреждена, искать причину приходится внутренней ИТ-команде и ее подрядчикам.

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

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

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

Другой пример: компания рассчитывает, что данные автоматически копируются на резервную площадку. После сбоя выясняется, что услуга резервного копирования не подключалась. Снапшоты на уровне гипервизора действительно создает провайдер — например, в матрице Linx Cloud это зона провайдера. Но снапшот живет в том же инфраструктурном контуре и не является независимой копией: за резервное копирование данных внутри виртуальной машины отвечает клиент. Чтобы избежать подобных ситуаций, используется модель разделенной ответственности.

Что такое модель разделенной ответственности

Эта модель (Shared Responsibility Model) описывает, какие уровни информационной системы обслуживает провайдер, а какие остаются под управлением заказчика.

Облачная система состоит из нескольких слоев:

• физического дата-центра;
• электропитания и охлаждения;
• серверного и сетевого оборудования;
• систем хранения;
• гипервизора и платформы виртуализации;
• виртуальных машин;
• операционных систем;
• баз данных и промежуточного программного обеспечения;
• приложений;
• учетных записей;
• данных;
• бизнес-процессов.

Передача одного слоя провайдеру не означает автоматической передачи всех остальных. Это распределение обусловлено моделью облачного сервиса. В IaaS клиент получает виртуальную инфраструктуру и самостоятельно управляет большей частью программного стека. В PaaS провайдер дополнительно обслуживает платформу исполнения, базы данных или контейнерную среду. В SaaS клиент пользуется готовым приложением, а поставщик управляет почти всеми техническими слоями.

Однако даже в SaaS часть ответственности остается у заказчика. Компания по-прежнему решает, кому выдавать доступ, какие данные загружать в систему, какие права назначать сотрудникам и как действовать при увольнении пользователя.

Модель разделенной ответственности применяется и при выполнении отраслевых требований. Например, PCI Security Standards Council прямо рассматривает безопасность облачной среды как совместную ответственность поставщика и клиента: стороны должны прописать обязанности и утвердить их для каждого применимого требования.

За что обычно отвечает облачный провайдер

Точный состав ответственности определяется услугой и договором. Но в базовой IaaS-инфраструктуре провайдер управляет нижними инфраструктурными уровнями.

Площадка и физическая инфраструктура

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

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

Виртуализация и облачная сеть

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

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

Таким образом, провайдер обеспечивает работу сетевой и вычислительной основы облака, но не всегда отвечает за конфигурацию ресурсов, созданных заказчиком поверх нее.

Доступность ресурсов и границы SLA

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

Например, виртуальная машина доступна на уровне платформы, но приложение внутри нее — остановлено. Поэтому ответственность провайдера за инфраструктурный слой не отменяет ответственности клиента за программную часть системы и ее конфигурацию.

Что остается на стороне бизнеса

После перехода в IaaS у компании становится меньше задач, связанных с физическим оборудованием. Однако эксплуатация программной части никуда не исчезает.

Архитектура системы

Провайдер предоставляет ресурсы, но не решает, сколько виртуальных машин нужно приложению, как распределять нагрузку и каким образом устранять единые точки отказа. Если критичная система размещена на одной виртуальной машине без резервирования, ее недоступность может стать следствием архитектурного решения клиента, даже если облачная платформа работает штатно. Бизнесу необходимо определить:

• какие компоненты нужно дублировать;
• в каких зонах или на каких площадках их размещать;
• как переключать нагрузку;
• какие RTO (за сколько сервис должен вернуться в работу) и RPO (какой объем данных допустимо потерять) требуются бизнесу;
• сколько ресурсов понадобится при пиковом потреблении.

Перед настройкой инфраструктуры системы классифицируют по техническим зависимостям и требованиям к размещению. Linx Cloud может помочь собрать эту информацию, а критичность сервисов, допустимый простой и приоритет восстановления заказчик определяет вместе с владельцами бизнес-процессов.

Операционные системы

В базовом IaaS клиент сам отвечает за операционные системы внутри виртуальных машин:

• установку обновлений;
• исправление уязвимостей;
• настройку служб;
• управление локальными пользователями;
• конфигурацию системного межсетевого экрана;
• контроль свободного места;
• анализ журналов.

Если операционная система не обновлялась несколько лет и была скомпрометирована через известную уязвимость, сам факт размещения в облаке не переносит ответственность на провайдера. Исключение составляют управляемые услуги, в которых обслуживание ОС отдельно передано поставщику.

Приложения и базы данных

Заказчик отвечает за программное обеспечение, которое он разворачивает поверх инфраструктуры:

• работоспособность приложений;
• обновление их компонентов;
• совместимость версий;
• параметры баз данных;
• управление схемами;
• производительность запросов;
• корректность интеграций;
• хранение секретов и ключей.

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

Пользователи и права доступа

Большая часть инцидентов не требует физического доступа к серверу. Достаточно получить учетную запись с избыточными правами.

Поэтому бизнес обычно отвечает за:

• создание и удаление пользователей;
• назначение ролей;
• применение принципа минимальных привилегий;
• многофакторную аутентификацию;
• ротацию паролей и ключей;
• управление сервисными учетными записями;
• отзыв доступа у уволенных сотрудников;
• контроль действий администраторов.

Провайдер предоставляет инструменты управления доступом, но корректно использовать их должен заказчик.

Данные

Компания определяет, какие данные размещаются в облаке, кто имеет к ним доступ и как долго они должны храниться. Если речь идет о персональных данных, передача инфраструктуры провайдеру не снимает обязанностей с оператора. Статья 19 Федерального закона № 152-ФЗ требует от оператора принимать необходимые правовые, организационные и технические меры защиты либо обеспечивать их принятие. Поэтому заказчику необходимо определить:

• категории обрабатываемой информации;
• требования к месту ее хранения;
• необходимый уровень защиты;
• порядок предоставления доступа;
• сроки хранения и удаления;
• действия при инциденте;
• условия поручения обработки другой организации.

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

Кто отвечает за информационную безопасность

Информационная безопасность облачной среды строится по модели разделенной ответственности. Провайдер защищает компоненты базовой платформы, которыми он управляет:

• физическую инфраструктуру и оборудование ЦОД;
• гипервизоры, управляющие компоненты и технологические сети;
• внутренние процессы администрирования и доступ своих сотрудников.

Заказчик отвечает за безопасность ресурсов, развернутых внутри облачной среды:

• виртуальные машины, операционные системы и приложения;
• данные, учетные записи, роли, ключи и токены;
• сетевые правила, конфигурации и процессы эксплуатации.

Провайдер может предоставить средства защиты: межсетевой экран, журналирование событий, управление ролями или многофакторную аутентификацию. Настройка этих средств и контроль их использования остаются в зоне клиента, если администрирование отдельно не включено в состав услуги.

Например, слишком широкое правило межсетевого экрана открывает административный интерфейс приложения в интернете. Если при этом используется стандартный пароль, причиной инцидента становится конфигурация клиентской среды. Облачная платформа в такой ситуации выполняет заданные настройки и предоставления сетевой доступности ресурса.

Если уязвимость находится в гипервизоре или управляющем компоненте платформы, доступ к которому есть только у поставщика, обновление и устранение уязвимости выполняет провайдер.

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

Кто должен настраивать резервное копирование

Резервное копирование — один из наиболее распространенных источников разногласий. Клиент создает виртуальную машину и предполагает, что провайдер автоматически хранит ее копию. Однако базовая услуга IaaS включает только вычислительные ресурсы и дисковое пространство. Резервное копирование в таком случае заказывается отдельно или настраивается средствами клиента. Кроме того, нужно различать несколько механизмов:

• отказоустойчивость физической платформы;
• репликацию системы хранения;
• снимки виртуальных машин;
• резервные копии;
• аварийное восстановление на другой площадке.

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

Снимок удобен для краткосрочного отката перед обновлением, но не всегда является независимой резервной копией. Бэкап позволяет восстановить данные на выбранную точку во времени, однако его наличие еще не гарантирует, что сервис вернется в работу в требуемый срок. DR-сценарий нужен, когда необходимо запустить инфраструктуру на резервной площадке и восстановить связанные приложения.

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

Также важно заранее определить срок хранения копий, порядок восстановления, ответственных за запуск процедуры, регулярность проверки копий и время, необходимое для возврата сервиса в работу.

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

Кто отвечает за аварийное восстановление

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

Провайдер может отвечать за:

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

Заказчик обычно отвечает за:

• решение активировать DR-план;
• определение приоритетов систем;
• выбор допустимой точки восстановления;
• проверку приложений;
• подтверждение целостности данных;
• работу внешних интеграций;
• информирование сотрудников и клиентов;
• решение о возвращении на основную площадку.

Даже в управляемом DRaaS необходимо заранее определить, кто имеет право объявить аварию и инициировать переключение. В базе знаний Linx Cloud для DRaaS используется отдельная матрица ответственности, которая фиксирует границы между провайдером и клиентом при настройке репликации, тестировании, аварийном переключении и обратном переносе нагрузки.

Как ответственность меняется в IaaS, PaaS и SaaS

Граница зависит от того, насколько высоко провайдер поднимается по технологическому стеку.

Таблица показывает общий принцип распределения ответственности, но фактические границы зависят от состава услуг и условий договора. В IaaS часть задач можно передать провайдеру через дополнительные сервисы, например администрирование ОС, резервное копирование или мониторинг. При этом даже управляемые сервисы не снимают с клиента ответственность за данные, настройки приложений и контроль использования ресурсов.

SLA не описывает всю ответственность

SLA (соглашение об уровне сервиса) фиксирует конкретные показатели для определенной услуги. В SLA могут указываться:

• доступность сервиса;
• время реакции поддержки;
• сроки устранения неисправностей;
• порядок обработки обращений;
• исключения;
• плановые работы;
• компенсации.

При этом SLA не всегда включает восстановление приложений, возврат удаленных данных, исправление ошибок внутри ОС или достижение целевых RTO/RPO. Например, у Linx Cloud есть гарантированное SLA для облачных сервисов до 99,99%. Показатель относится к конкретной услуге и не означает автоматическую доступность приложения на том же уровне.

Матрица ответственности: как убрать серые зоны

Одного общего раздела в договоре не всегда недостаточно. Для сложной инфраструктуры удобнее составить матрицу ответственности.

В строках перечисляют процессы и компоненты:

• физическая инфраструктура;
• гипервизор;
• виртуальная сеть;
• гостевые ОС;
• приложения;
• резервное копирование;
• мониторинг;
• реагирование на инциденты;
• обновления;
• управление доступом;
• тестирование восстановления.

В столбцах указывают участников:

• облачный провайдер;
• внутренняя ИТ-команда;
• служба информационной безопасности;
• разработчики;
• внешний интегратор;
• владельцы бизнес-систем.

Для каждого действия определяют роль. Можно использовать модель RACI:

• R — Responsible: выполняет работу;
• A — Accountable: несет итоговую ответственность;
• C — Consulted: участвует в согласовании;
• I — Informed: получает информацию о результате.

Например, провайдер может выполнять восстановление виртуальной машины, руководитель ИТ — утверждать запуск процедуры, владелец приложения — проверять работоспособность, а служба безопасности — получать информацию об инциденте.

В документации Linx Cloud опубликована отдельная матрица распределения ответственности для IaaS. Она использует RACI и показывает, как роли провайдера и клиента распределяются между уровнями облачной инфраструктуры.

Главная ценность матрицы заключается не в самом документе. Она заставляет стороны заранее обсудить процессы, о которых иначе вспоминают только во время сбоя.

Типичные ошибки при распределении ответственности

Даже при наличии SLA и технического описания услуги границы между провайдером и заказчиком могут оставаться неясными. Чаще всего проблема возникает не из-за отсутствия документов, а из-за слишком общих формулировок: в них не указано, кто выполняет конкретную операцию, кто контролирует результат и кто принимает решение при инциденте.

Что проверить до подписания договора

Перед переходом в облако важно заранее установить, кто за что отвечает, и закрепить это в договоре, SLA, техническом задании или матрице ответственности.

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

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

Также стоит описать требования к безопасности и поддержке: управление доступами, работу с инцидентами, доступность каналов связи, сроки реакции и порядок эскалации. Все эти условия должны быть закреплены документально, чтобы при возникновении проблем у сторон не возникало разных трактовок ответственности.

Как передать провайдеру больше задач

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

При этом такая передача должна быть четко зафиксирована. Формулировки вроде «провайдер помогает с инфраструктурой» не устанавливает зону ответственности. В договоре важно указать, какие именно операции выполняются, в каком режиме оказывается услуга, какие есть сроки реакции, права доступа, порядок изменений, ответственность за результат и возможные ограничения.

Чем точнее описаны условия взаимодействия, тем меньше риск разногласий при возникновении проблем.

Как распределяется ответственность в инфраструктуре Linx Cloud

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

В Linx Cloud распределение ролей для IaaS описано отдельной матрицей ответственности. Провайдер отвечает за инфраструктурный уровень облачной платформы, а заказчик — за управляемые им виртуальные ресурсы, приложения, данные и пользовательские настройки в пределах выбранной модели.

Если компании необходимо передать часть дополнительных задач, к облачной инфраструктуре можно подключить сервисы резервного копирования и аварийного восстановления. Linx Cloud предоставляет облачное резервное копирование для виртуальных и физических серверов, а также DRaaS для восстановления инфраструктуры на резервной площадке.

При этом подключение управляемого сервиса не отменяет участие заказчика. Бизнес по-прежнему определяет критичность систем, требования к RTO и RPO, политику хранения, состав защищаемых данных и критерии успешного восстановления.

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

Что делать на практике

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

1. Разложите сервис на компоненты и назначьте владельцев

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

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

2. Зафиксируйте не только зоны, но и операции

Формулировка «ИТ-отдел отвечает за приложение» слишком общая. Необходимо отдельно определить, кто устанавливает обновления, меняет конфигурацию, отслеживает ошибки, реагирует на предупреждения, проверяет резервные копии и подтверждает восстановление.

После этого модель нужно сверить с договором и SLA. Если операция фактически выполняется провайдером, но не закреплена документально, при инциденте возникнет спорная зона. Возможна и обратная ситуация: услуга оплачена, но внутренняя команда не включила ее в регламенты и продолжает выполнять работу самостоятельно.

3. Проверьте модель на учебном инциденте и регулярно обновляйте

Для проверки подойдет практический сценарий: критичное приложение перестало отвечать в нерабочее время. Команда должна последовательно определить, кто обнаруживает проблему, кто проверяет облачную платформу, кто анализирует операционную систему, кто связывается с провайдером, кто принимает решение о восстановлении и кто подтверждает работу бизнес-сервиса. Если последовательность требует импровизации, матрица ответственности пока не отражает реальный процесс.

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

Чек-лист распределения ответственности

Перед запуском облачной инфраструктуры проверьте следующие пункты:

☐ Определено, какие компоненты входят в услугу провайдера.

☐ Зафиксировано, кто администрирует гостевые операционные системы.

☐ Назначены ответственные за приложения и базы данных.

☐ Определено, кто создает пользователей и управляет правами.

☐ Понятно, входит ли резервное копирование в услугу.

☐ Установлены сроки хранения и периодичность создания копий.

☐ Назначен ответственный за проверку восстановления.

☐ RTO и RPO согласованы с бизнесом.

☐ Описан порядок объявления аварии и запуска DR.

☐ Зафиксирован владелец каждого бизнес-сервиса.

☐ Определены каналы связи и порядок эскалации.

☐ SLA соотнесен с архитектурой приложения.

☐ Матрица ответственности отражает фактическую инфраструктуру.

☐ Назначена дата следующего пересмотра документа.

Главное

Работа облачной инфраструктуры строится на разделении ответственности между провайдером и заказчиком. Провайдер отвечает за уровни, которые входят в его услугу. Заказчик отвечает за архитектуру систем, приложения, данные, пользователей и настройки, которые остаются под его контролем.

Подключение управляемых сервисов хоть и расширяет зону ответственности провайдера, но само по себе не передает ему все задачи.

Эффективная модель ответственности должна быть заранее зафиксирована в договоре, SLA и технических регламентах. Если зоны ответственности определены и проверены на практике, облачная инфраструктура остается предсказуемой и управляемой.

У S3-совместимого объектного хранилища другая логика: приложение обращается к объектам через API, а вопросы физического размещения и масштабирования решает сама система хранения. Для бэкапов, архивов и медиаданных модель такого рода подходит хорошо, однако перед переходом на нее важно проверить, как конкретное приложение работает с объектами и что произойдет с данными при нагрузке или восстановлении.

Как устроено S3

В объектном хранилище данные организованы в бакеты, где у объекта три составляющие: содержимое, уникальный ключ и метаданные. Вложенных директорий в привычном смысле здесь нет — папки в интерфейсах появляются потому, что ключ объекта разбирают по разделителю. Например, backups/2026/08/db-dump.tar.gz читается человеком как путь по папкам, а для хранилища — просто одна строка-идентификатор.

В отличие от файловой системы, где приложение может открывать файл, записывать данные частями, дополнять его и использовать блокировки, S3 работает с объектами через API. Объект загружается целиком, а изменения выполняются отдельными операциями API.

Переименование объекта выполняется копированием под новым ключом с последующим удалением исходного — приложению, которое часто переименовывает или дописывает файлы либо использует файловые блокировки, потребуется изменить логику работы с данными при переходе на S3.

Управляется модель небольшим набором предсказуемых HTTPS-операций.

S3 API используется разными объектными хранилищами, однако поддерживаемые функции могут различаться. Перед миграцией стоит проверить конкретные API-операции приложения, политики доступа, уведомления, Object Lock, репликацию и подпись запросов. Совместимость проверяют на рабочих сценариях приложения и часто в них применяемых API-операциях.

Где подходит модель

Зная, как устроена модель, проще понять, где S3 подходит лучше всего. Он хорошо работает с данными, которые сохраняются целыми объектами, хранятся независимо друг от друга и читаются по ключу. Например, так удобно хранить резервные копии, архивы, медиаконтент, логи и аналитические данные.

Для задач с частыми синхронными изменениями нужна другая модель хранения. Например, для дисков виртуальных машин, транзакционных логов СУБД, рабочих каталогов сборки и приложений с POSIX-блокировками подходит блочное или файловое хранилище. S3 при этом можно использовать для снапшотов, регулярных выгрузок и резервных копий.

Что защищает данные внутри S3 и где заканчивается эта защита

Для критичных данных в S3 используются versioning, Object Lock и репликация. Эти функции решают разные задачи и применяются в разных сценариях.

Versioning сохраняет предыдущие версии объектов. При повторной записи по тому же ключу создаётся новая версия с собственным version ID. DELETE добавляет delete marker, поэтому предыдущие версии остаются доступными для восстановления.

Versioning увеличивает объём хранения. Приложение, которое ежедневно переписывает крупный объект, создаёт последовательность его полных версий. Lifecycle-политика позволяет определить срок хранения старых версий и правила очистки незавершённых multipart-загрузок. Versioning переводится в состояние suspended, а полностью отключить его нельзя. При создании бакета с Object Lock versioning включается автоматически.

Object Lock реализует модель WORM, Write Once, Read Many. Для объекта задаётся срок retention, в течение которого система сохраняет его в защищённом состоянии.

В режиме Governance пользователь с расширенными правами может снять защиту вручную. В режиме Compliance защищённая версия сохраняется до окончания retention, включая случаи с root-аккаунтом. Срок хранения стоит рассчитывать заранее: установленный retention нельзя сократить, поэтому версия продолжит занимать место до окончания заданного периода.

Репликация создаёт дополнительные копии объектов и повышает устойчивость к отказам оборудования. В Linx Cloud используется фактор репликации 3, RF3, поэтому каждый объект хранится в трёх экземплярах.

Репликация переносит изменения вместе с объектами. Если исходные данные уже содержат логическую ошибку, она попадёт и в реплики. Для критичных данных поэтому требуется отдельный домен отказа, регулярная проверка восстановления и схема резервного копирования 3-2-1 или 3-2-1-1-0.

Своя инфраструктура или сервис провайдера

S3-сервис можно развернуть внутри собственной инфраструктуры или использовать как управляемую услугу провайдера. На уровне приложения подключение выглядит одинаково: endpoint, access key, secret key и S3 API — разница в эксплуатации инфраструктуры.

Перед выбором провайдера стоит свериться с матрицей ответственности — кто чинит платформу при сбое, кто управляет ключами и доступом, кто следит за квотами и кто в итоге отвечает за резервные копии данных. Такая матрица для S3 есть и у Linx Cloud — сверить её с внутренними регламентами команды стоит ещё до того, как сервис запущен в работу.

Как это устроено у Linx Cloud

Если выбор сделан в пользу провайдера, вот пример конкретной реализации. В основе сервиса Объектное хранилище (S3) в Linx Cloud — Ceph: мы выбрали его из-за совместимости с S3 API (по нашему опыту, полнее её реализует разве что сам AWS), а также из-за масштабируемости и гибкости для развития продукта.

Путь запроса такой: HTTPS endpoint → сетевой периметр с WAF и NGFW → балансировщики нагрузки → Ceph Object Gateway (RGW), который уже разбирает команды S3 API и передаёт операции в backend-кластер. Сами объекты лежат на OSD-узлах с репликацией в три копии (RF3), а управляющие компоненты кластера вынесены на отдельное оборудование.

Подключиться к сервису можно по интернету или по выделенному каналу точка-точка — из виртуального ЦОД Linx Cloud, серверной стойки в дата-центре Linx или с любой внешней площадки. По документации сервис поддерживает multipart upload, versioning, Object Lock/WORM, presigned URL, репликацию бакетов и lifecycle-правила удаления. Один PUT рассчитан максимум на 5 Гбайт — для объектов крупнее нужен multipart.

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

Что проверить на пилоте

Каким бы ни было решение — свой кластер или сервис вроде Linx Cloud — переводить на него прод стоит только после пилота, и строить его нужно на реальном потоке данных приложения: одна команда aws s3 cp с тестовым файлом ничего не покажет.

• Поэтому сначала измеряется профиль данных: средний и максимальный размер объектов, общее количество объектов, соотношение GET и PUT, частота LIST, пиковая нагрузка и допустимая задержка.
• Затем проверяется совместимость приложения с нужными функциями S3. В тест входят multipart, versioning, Object Lock, lifecycle, presigned URL и права доступа. Для каждого механизма важно проверить именно тот сценарий, который используется в рабочей системе.
• После этого оцениваются сеть и безопасность. Тест показывает поведение канала под нагрузкой, работу при обрыве соединения, доступные маршруты и стоимость исходящего трафика. На уровне безопасности проверяются разделение прав, хранение и ротация ключей, шифрование, аудит операций и сценарий компрометации учётной записи.
• Финальная часть пилота посвящена восстановлению и стоимости. Нужно выполнить возврат старой версии и полное восстановление данных, измерить объём накопленных неактуальных версий и рассчитать расходы на запросы, хранение и трафик с учётом ожидаемого роста данных.

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

Для data lake — скорость, с которой выбранный аналитический стек читает данные, и отсутствие «болезни мелких файлов», когда объектов становится очень много. Одна и та же платформа S3 может отлично закрывать один сценарий и требовать уже другого архитектурного решения в соседнем.

Вместо вывода

S3 подходит для бэкапов, архивов, медиаконтента и аналитических данных, которые хранятся и читаются как объекты. Для дисков ВМ, СУБД и рабочих каталогов с частыми изменениями больше подходят файловые и блочные хранилища.

Поэтому перед миграцией стоит провести пилот на реальных данных приложения: проверить нагрузку, нужные API-операции, восстановление и стоимость хранения с учётом трафика. Результаты помогут определить, какую часть инфраструктуры имеет смысл перевести на S3 и где сохранить другие типы хранилищ.

Что Anthropic сделала с текстом Claude

2 августа 2026 года в ЕС вступили в силу обязательства по прозрачности ИИ-контента из AI Act. В июле 2026-го Anthropic, как и около 190 других организаций, подписала Кодекс практики по прозрачности ИИ-контента. Теперь компания заявляет, что все новые модели Claude будут «маркировать» сгенерированный текст — и делать это глобально, а не только для пользователей из Евросоюза.

Сначала Anthropic лишь кратко сообщила о маркировке в справочной статье «How Claude marks AI-generated content». 14 августа 2026 года появилось техническое объяснение «How Claude’s text watermark works». В нём компания признаёт: водяной знак не добавляет в текст никаких символов, он меняет выбор слов на основе секретного ключа.

Новые модели Claude будут встраивать статистический водяной знак во все тексты длиннее ~200 токенов (~150 слов).

Маркировка не использует невидимые символы: она смещает выбор между близкими по смыслу словами по секретному ключу.

Проверить водяной знак сможет только Anthropic; посторонние сервисы без ключа не смогут дать достоверный вердикт.

Переводы и переписывания целиком проходят через Claude, поэтому маркируются сильнее всего; обычная правка — слабее.

Чтобы снизить риск, используйте Claude как черновик, а затем переписывайте текст своими словами.

Как работает водяной знак в тексте

Большие языковые модели генерируют текст по одному токену. На каждом шаге у них есть список подходящих кандидатов, и иногда несколько вариантов равноправны по смыслу. Например, после фразы «погода сегодня была холодной и…» модель может выбрать «пасмурной» или «серой». Обычно выбор решает случайность. При водяном знаке случайность заменяется на псевдослучайную последовательность, выведенную из секретного ключа и нескольких предыдущих слов.

Anthropic использует вариант подхода SynthID-Text, опубликованного Google DeepMind в Nature в 2024 году. На каждом «равноправном» шаге модель получает лёгкий «подталкивающий» сигнал в сторону одних кандидатов и от других. Отдельный выбор почти незаметен, но на длине в сотни или тысячи токенов накапливается статистическая закономерность, которую может увидеть только владелец ключа.

Главный нюанс:
Секретный ключ есть только у Anthropic. Поэтому никакой сторонний «детектор ИИ-текстов» не сможет проверить водяной знак Claude — он либо будет искать стилистические признаки, либо угадывать.

Почему это спорно: слова имеют значение

Аргумент критиков прост: никакие два синонима не совпадают по оттенку, ритму и контексту. «Он ухватился за шанс» и «Он воспользовался возможностью» передают одно действие, но звучат по-разному. Если модель выбирает слово не только ради точности, но и ради скрытой метки, качество текста теоретически падает — пусть и на доли процента.

В документе Anthropic приводится пример: выбор между «overcast» и «grey» «в большинстве случаев не сильно влияет на читателя». Джон Грубер в ответ замечает: именно это и делает идею порочной. Компания решает за автора, какое слово «достаточно хорошо», вместо того чтобы каждый раз искать лучшее.

Можно было бы применить ту же логику к калькуляторам, если бы их результаты оставляли следы. К счастью, сумма, рождённая мозгом, не отличается от суммы, полученной на калькуляторе. Сделать помощь подозрительной только тогда, когда инструмент становится достаточно умён, чтобы составить целое предложение, — не принципиальная граница. Это моральная надбавка за саму сложность.

Что это меняет для пользователей

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

Код в большинстве случаев почти не страдает: там часто есть единственно правильное продолжение. Но комментарии и документация в коде маркируются так же, как обычная проза. Кроме того,Anthropic отмечает, что водяной знак переживает копирование и вставку: он живёт в самой последовательности слов, а не в форматировании.

• Переводы: полная маркировка, потому что каждый токен — выбор модели.
• Лёгкая правка: может оставить след, но не всегда достаточный для детекции.
• Глубокий переписывание: разрушает статистическую картину, но тогда результат уже сложно назвать ИИ-текстом.
• Код: функциональные части почти не меняются, комментарии — подвержены.

Почему это касается не только ЕС

Формально инициатором маркировки стал ЕС: AI Act обязывает провайдеров ИИ маркировать синтетический контент. Но Anthropic объявила о глобальном внедрении, сославшись на отсутствие «устойчивого способа» ограничить функцию по региону. Получается, что европейское регулирование распространяется на всех пользователей Claude, включая тех, кто живёт в России, США и Азии.

При этом неясно, насколько само регулирование требует именно такого подхода. Кодекс практики применяется к текстам длиннее 200 токенов, требует запрета на удаление метки в условиях использования и устойчивости к копированию, OCR и переводам. Но он не обязывает внедрять систему глобально и не заставляет провайдера изменять слова в приватных чатах.

Google уже делает то же самое с Gemini

Google внедрила текстовый водяной знак SynthID в Gemini раньше Anthropic. В статье Nature команда DeepMind пишет, что проанализировала около 20 млн ответов с водяным знаком и без него. Разница в оценках «палец вверх» составила 0,01%, а «палец вниз» — 0,02%; оба отличия оказались статистически незначимыми в пределах 95%-ного доверительного интервала.

Критики указывают: незначимая разница в оценках не означает, что качество не пострадало. Если модель заменяет «bananas» на «pineapple» в примере DeepMind, пользователь вряд ли поставит «дизлайк» из-за фрукта. Но именно такие микровыборы и формируют голос автора. А когда причина выбора скрыта, доверие к тексту падает.

Что делать авторам и разработчикам

Полностью избежать водяного знака при использовании Claude нельзя — он встроен в генерацию. Но можно снизить риск, что ваш текст будет ошибочно отнесён к категории «сгенерировано ИИ» или потеряет индивидуальность.

FAQ

Выводы

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

Пока публичного детектора нет, риск ложных обвинений невелик. Но как только API проверки появится, вопрос «а не написано ли это ИИ?» станет ещё более неоднозначным. Лучшая защита — не отказываться от инструментов, а помнить: черновик от ИИ — это черновик. Финальный текст должен быть вашим.

Моя письменная работа — это моя работа, а текущая стратегия Anthropic агрессивно враждебна писателям.

Источники

— John Gruber, «Anthropic’s ‘Watermark’ Text Adulteration in Claude Is a Perversion of Writing»
— Anthropic, «How Claude’s text watermark works»
— James Padolsey, «How AI text watermarking works»
— Google DeepMind, «Scalable watermarking for identifying LLM outputs» (Nature, 2024)
— EU Code of Practice on Transparency of AI-Generated Content

Computer History появилась в десктопном ChatGPT для macOS и фиксирует действия пользователя как «события».

Данные превращаются в обучающий материал: ChatGPT и Codex используют их, чтобы возобновлять задачи и предлагать автоматизацию.

Функция работает по принципу opt-in и позволяет исключать приложения и сайты, а также удалять отдельные записи.

OpenAI утверждает, что Computer History не делает скриншотов, видео и аудиозаписей — только текстовые события.

Содержимое вкладок incognito и private mode браузеров игнорируется автоматически.

Что такое Computer History

По сути, это аналог Windows Recall от Microsoft, но без главного спорного момента — постоянных скриншотов экрана. Вместо изображений macOS-приложение ChatGPT фиксирует events: какие документы открывались, в какие поля вводился текст, между какими окнами переключался пользователь.

В демонстрации сотрудник OpenAI Dominik Kundel попросил ChatGPT найти последний отредактированный документ, проверить, был ли он отправлен коллегам в Slack, и составить краткий отчёт о том, как прошло его утро. Всё это ИИ взял из собранной истории действий.

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

Функция включена только с согласия пользователя — opt-in, а не opt-out. Можно исключить отдельные приложения и сайты из сбора, а также удалить любую запись вручную. Ari Weinstein, менеджер по продукту и инженерии в OpenAI, уточнил, что Computer History автоматически пропускает содержимое вкладок в режиме инкогнито или приватного просмотра.

Выводы

Computer History — ещё один шаг OpenAI к тому, чтобы ChatGPT стал не просто чатом, а полноценным «операционным слоем» поверх рабочего стола. Пока функция доступна в macOS-приложении и требует явного согласия, но сам факт сбора кликов и клавиш уже вызывает вопросы о приватности. Если решитесь попробовать — сначала проверьте список исключённых приложений.

Источник: The Verge

Здравствуйте! Меня зовут Андрей, и я работаю в сфере информационной безопасности.

Когда кто‑то спрашивает, чем я занимаюсь, я отвечаю, что работаю в IT и слежу за безопасностью компании. Это звучит как ответ сапёра, который говорит, что просто гуляет по полю.

Технически не ложь, но… есть нюансы.

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

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

Если хорошо работаю я — ничего не происходит. И это считается отличным результатом.

Некоторые руководители‑оптимизаторы любят спрашивать: «Ну и за что тебе платить? Нас ещё ни разу не атаковали хакеры». Странная логика. От ремня безопасности они почему‑то не отказываются. Хотя тоже ещё ни разу не вылетали через лобовое.

ИБ, информационная безопасность — это невидимость как услуга. Нас можно заменить табличкой «Пока всё нормально». Но табличка не умеет писать отчёты на 47 страниц о том, почему всё перестало быть нормально.

Кто такой безопасник

Из‑за фильмов многие думают, что безопасник в IT — это такой хороший хакер, который на самом деле способен за десять секунд взломать Пентагон.

В жизни мой главный взлом — это взлом человеческого упрямства. Ведь это я на утренней пятиминутке полтора часа объясняю всему коллективу, почему нельзя хранить эксель‑файл с названием «клиентские_пароли» на рабочем столе.

И все соглашаются. Но файл не удаляют. Ведь «он нужен для работы».

Безопасник — это тревожный человек, которому за тревожность платят зарплату. В обычной жизни таких людей называют паникёрами. В IT — ведущими специалистами по информационной безопасности.

Работа в инфобезе — это когда все думают, что ты самый противный тип в компании, который подозревает окружающих в чём‑то очень плохом. А на самом деле ты просто в третий раз за день пишешь: «Коллеги, пожалуйста, не присылайте пароли от сервисов в общий чат».

И всегда, абсолютно всегда, находится человек — допустим, Дима, который отвечает: «Это тестовый пароль».

Конечно. В IT слово «тестовый» часто означает: «Мы надеемся, что это не попадёт в публичный доступ, как в прошлый раз». В каждой компании есть такой Дима. Если у вас нет Димы — есть риск, что Дима — это вы.

В детстве я мечтал стать космонавтом, потом — супергероем. А стал ведущим специалистом по информационной безопасности. Теперь моя суперсила — запрещать людям то, что они только что придумали. Поэтому все отделы компании ненавидят меня одинаково. Можно сказать, что я один сплачиваю весь коллектив.

Я как глютен: никто точно не знает, что я делаю, но все убеждены, что без меня было бы лучше. Ведь только я обычно говорю «нет», когда меня о чём‑то просят.

Отдел информационной безопасности вообще часто называют «отделом моментального нет». Это неправда! Иногда я говорю «нет» не сразу, а спустя шесть месяцев, после аудита.

Я вообще смотрю на мир по‑своему. Нормальные люди выходят из дома и думают: «А я утюг выключил?». Когда я выхожу из дома, то думаю: «Если кот получит физический доступ к кухне, сможет ли он повысить свои привилегии?».

Потому что кот уже успешно повышал привилегии. Дважды. Оба инцидента привели к утечке сосисок.

Быть безопасником тяжело. Через пять лет в инфобезе я перестал верить в людей. Через десять — не доверяю даже принтеру. Он знает слишком много.

Я не параноик, хотя вы можете с этим не согласиться. Ведь у меня дома пароль от Wi‑Fi длиннее, чем некоторые браки. Я всегда читаю пользовательское соглашение до конца. А знаете, как я познакомился с женой? Я пришёл в отдел с плановой проверкой. Активность одной сотрудницы показалась мне подозрительной. Начал расследование. Через год оказался в ЗАГСе, спустя пять лет у нас уже двое детей. Классическая история успешного женского фишинга, я считаю.

Жена однажды сказала: «С тобой невозможно жить, ты как пожарный, который везде видит опасные горючие материалы». Я ответил: — «Неправда. Но ты хранишь в интернете фото паспорта и СНИЛС, а ещё используешь один пароль на всех сервисах. Знаешь, какие это киберриски?». Она говорит: «Это называется не „киберриски“, это называется „ты душнила, который портит семейную атмосферу“».

Появление детей у безопасников — это странный процесс. Нормальные люди просто говорят друг другу: «Давай заведём ребёнка». У безопасников даже решение завести ребёнка начинается с оценки рисков нового проекта. Потом нужно согласовать проект со всеми заинтересованными сторонами: жена, оба комплекта родителей и кот — который, как правило, против.

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

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

Говорят, дети всегда перенимают что‑то от родителей. У врача ребёнок приходит в садик и всем ставит диагнозы. У юриста ребёнок на вопрос «Ты зачем игрушку сломал?» отвечает: «Я отказываюсь давать показания без присутствия законного представителя». Но им далеко до детей безопасников.

Потому что обычные дети рисуют принцесс, динозавров и радугу, а ребёнок безопасника рисует схему квартиры и указывает на ней уязвимые места. Обычные дети боятся монстра под кроватью, а ребёнок безопасника боится незапароленного Wi‑Fi.

Обычный ребёнок врёт родителям. Ребёнок безопасника успешно практикует социальную инженерию.

О паролях и фишинге

Вы уже поняли, что информационная безопасность — сложная наука. Но вся эта наука в итоге ломается о человека по имени Дима с паролем Dimon123.

Каждый год публикуют список самых популярных паролей. Я смотрю на него и понимаю: «Мы заслужили вымирание». Первое место — «123456». Второе — «password». Третье — «123456789». Ребята… вы хоть немного стараетесь?

Есть и обратная история — корпоративная политика паролей. Обычно она написана так, словно её составляли в ходе трёхлетней войны с человеческой памятью. Требования такие: не менее 16 символов. Заглавные буквы. Строчные. Цифры. Спецсимволы. Древнее проклятие. Кровь единорога.

Ещё желательно, чтобы пароль вызывал эмоциональный отклик. Который плюс вайб.

После создания такого пароля пользователь Дима записывает его на стикере, клеит к монитору и делает вид, что это временно. Потому что его память тоже имеет системные ограничения.

Люди искренне ненавидят сложные пароли и почему‑то нас. Как будто это МЫ их придумали вам назло. Как будто где‑то в тёмной комнате собрались безопасники и такие: «Господа, есть идея. Давайте заставим пользователей добавлять в пароль по одному символу в верхнем регистре. Это их сломает. Муа‑ха‑ха!».

А ещё этот знакомый всем цикл: «Забыл пароль» — «Сбросить» — «Создать новый пароль» — «Придумайте более сложный пароль» — «Новый пароль не должен совпадать с тремя предыдущими». На последнем этапе не то что обычный человек, даже безопасник захочет взять нож и пойти убивать.

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

О, а есть ещё фишинг. Это когда вам приходит письмо от «Службы безопасности» с требованием срочно перейти по ссылке, иначе «ваш аккаунт будет заблокирован».

Фишинг раньше был тупой. Прям очень тупой. Письма от наследного принца Нигерии, просьбы срочно перевести деньги с орфографией человека, который даже букварь не осилил. Это было почти честно: мошенник не притворялся, что он умный. На это клевали только бабушки и неопытные бухгалтеры.

А потом появился ИИ‑фишинг. И теперь письма от фейкового директора понятнее, интереснее и грамотнее, чем от настоящего. Это, кстати, очень тревожный знак для настоящего директора.

Теперь уже программа присылает голосовые сообщения от лица якобы начальника. «Дима, переведи олимпиард денег на счёт компании „Тёртый сыр“, пока я на встрече. Срочно».

Что делает уже не раз битый безопасниками Дима? Он пишет: «Иван Иваныч, это точно вы? Мне нужно подтверждение». А фейк отвечает: «Да, это я». И скидывает фото, где он выглядит даже лучше, чем вживую. Натуральнее как‑то. Как тут не повестись?

Фишинг — это не атака на глупых. Это атака на занятых. На уставших. На людей, у которых было пять созвонов, три письма, одно «срочно» и ноль внутреннего ресурса на проверку, почему письмо о подтверждении платежа пришло с домена otprav‑dengi‑hakeru.ru.

Представьте, что письмо пришло в пятницу в 17:58. Я настолько задолбался к этому времени, что если в таком письме напишут «Подтвердите передачу квартиры мошенникам», я отвечу: «А можно после выходных?».

Фишинг работает не потому, что люди доверчивые. Он работает, потому что люди привыкли к корпоративному хаосу. Если письмо выглядит типичным образцом корпоративного безумия, мозг говорит: «А, ну всё как обычно».

Уязвимости, разработка и бухгалтерия

Есть три фразы, которые я ненавижу: «У меня же работало», «Починим потом» и «Так быстрее».

Всё плохое в IT когда‑то начиналось со слов: «Так быстрее». А «починим потом» — это фраза, которая для меня звучит как «Мы хотим, чтобы наши базы данных уже завтра оказались на торрентах».

Возможно, вы знаете, что всем уязвимостям в программах и железе присваивается номер и оценка критичности от 1 до 10. 10 — это когда «всё плохо, чинить немедленно, звать на помощь маму».

9.8 — это то, что разработчики закрывают через три месяца, потому что «сейчас нет ресурса». К тому времени, как ресурс появится, уязвимость продемонстрируют на двух конференциях и продадут готовый эксплойт в даркнете за сто долларов. А вы ещё удивляетесь, почему я такой нервный.

Любая проблема в компании проходит одни и те же стадии.

Сначала: «Этого не может быть».

Потом: «Этой уязвимости нет в нашем проекте».

Потом: «Есть, но ничего страшного».

Потом: «Зачем вообще так делали?»

И наконец: «Давайте искать виноватого».

И вот тут выясняется, что проект использует какой-то скрипт, который написал случайный стажёр пять лет назад. Он потом уволился и, судя по всему, покинул этот бренный мир, потому что больше никогда не отвечал в мессенджерах. То есть какой-то случайный человек из прошлого на коленке сложил несущую стену нашего дома из битых кирпичей, скрепил всё это жвачкой — и растворился в тумане. А мы стоим, смотрим на трещины и говорим: «Ну, вроде не особо заметно. Не будем трогать».

Отдельно люблю legacy-системы. Это системы, написанные на языке, которому 30 лет. Ими управляет один человек, который работает в компании с 1908 года. Его зовут дядя Вася. Дядя Вася знает все пароли, не пишет инструкций и уходит в отпуск именно тогда, когда всё ломается. Увольнение дяди Васи считается событием уровня конца света.

Люблю ещё эту вечную дискуссию между инфобезом и разработчиками:

— Надо исправлять.

— А если сломается?

— А если не исправлять, то будет плохо.

— А если плохо будет из‑за исправления?

Разговор заходит в бесконечный цикл. Я создаю задачу в Jira. Это сервис, куда записывают задачи. Теоретически — чтобы их решать. Практически — чтобы там и похоронить.

Создаёшь задачу. Назначаешь исполнителя. Через месяц задача передаётся дальше. Через два месяца ещё дальше. Через полгода в задаче больше комментариев, чем под видео у популярного блогера. Но решения нет.

У меня там одна задача висит уже восемь месяцев. Проблема критичного уровня. Статус — «когда‑нибудь потом». Мне кажется, эта задача переживёт человечество. После ядерной зимы останутся тараканы и Jira. И таракан напишет в задаче: «Починим в следующем квартале».

Теперь о бухгалтерии. Я уважаю бухгалтеров. Это люди, которые из хаоса делают отчётность, а из отчётности — мою новую срочную задачу. Это огромная сила.

Но именно бухгалтерия — это то место, где флешка с вирусом становится троянским конём. Потому что если на флешке написано «Расчёт по зарплате окончательный final2», её вставят в компьютер. Не потому что бухгалтеры глупые. Потому что они так и называют свои файлы.

И в этом проблема. Почему бухгалтеры опасны? У них есть доступ к деньгам, но при этом они пользуются древними программами, принтерами, которые работают на чистой ненависти, и компьютерами, на которых стоит система из эпохи, когда слово «куртизанки» считалось новомодным.

Я однажды провёл обучение на тему опасности неизвестных носителей данных. А позже раскидал по офису пять флешек, подписав каждую. Где‑то это было «Продажи 1 кв. 2026», где‑то «Дизайн‑макет сайта». Ну такие, очевидные надписи. Четыре из пяти флешек вставили в течение часа.

Одну Дима унёс домой.

Поэтому не знаю, как у других коллег, а у меня есть правило: любая найденная бесхозная флешка уничтожается на месте. И я ношу с собой молоток. Для флешек. Хотя иногда и для пользователей. Это часть моего комплекта ведущего специалиста по информационной безопасности.

Финальное слово

На словах все любят безопасность. Безопасность — как спорт и ЗОЖ. Все за. Просто… не сегодня.

Представьте, что вас наняли охранять торговый центр. Только ключ от всех дверей лежит под ковриком. Код от сигнализации написан на бумажке рядом с сигнализацией. Запасной вход не закрывали с 2019 года, а охранник регулярно выкладывает план здания в TikTok.

И вот ты ходишь и говоришь: «Ребята, это проблема». Иногда мне кажется, что в этом и заключается моя работа — ходить и говорить: «Так делать нельзя». А в ответ слышать неизменное: «Но мы всегда так делали».

Конечно. Именно поэтому я нервничаю! Я всегда предполагаю худшее. И меня бесит, как часто я оказываюсь прав.

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

А если серьёзно — спасибо, что выслушали. Помните: меняйте пароли, не кликайте на странные ссылки, обновляйте программы, и пожалуйста, ПОЖАЛУЙСТА, не будьте как Дима.

В веб-разработке подпись кода, права доступа и шифрование давно воспринимаются как базовая гигиена. В промышленном программировании последствия ошибки выше: код управляет не страницей или сервисом, а оборудованием, технологическим режимом и иногда целой линией производства. Поэтому безопасность ПЛК начинается не только с межсетевого экрана перед АСУ ТП, но и с настроек самой среды исполнения.

CODESYS используется в миллионах устройств разных производителей, включая контроллеры, которые работают на российских промышленных объектах. Встроенные механизмы защиты там уже есть: шифрование соединения между IDE и контроллером, подпись и шифрование приложения, ролевая модель доступа. Проблема в том, что на реальных объектах эти настройки часто оставляют «на потом», потому что ПЛК уже запущен, линия работает, а любое изменение кажется лишним риском.

В этой статье разберем три настройки CODESYS, которые стоит проверить до первого инцидента: только шифрованное соединение с ПЛК, запрет загрузки неподписанного кода, шифрование приложения и разграничение прав. Отдельно покажем, почему перед изменениями нужен пилотный контур, резервная копия проекта и понятный сценарий восстановления.

Сначала важное предупреждение

Не включайте эти настройки сразу на работающей линии без проверки. Сначала нужен тестовый или пилотный контур, актуальная резервная копия проекта, понимание версии исполняемой среды, список инженерных станций, учетных записей, сертификатов и сценариев восстановления.

После включения шифрования, подписи или изменения прав можно потерять текущую сессию, заблокировать привычный способ загрузки приложения или столкнуться с тем, что у части инженеров больше нет нужных прав. Это нормальный управляемый риск, если изменения заранее проверены на стенде. На работающем контроллере такие эксперименты могут привести к простою.

Почему одного пароля недостаточно

Начиная с CODESYS V3.5.17.0 управление пользователями включается принудительно по умолчанию: перед первым успешным подключением нужно активировать user management и создать администратора. Это правильная отправная точка, но пароль не закрывает все вопросы безопасности.

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

В 2026 году Nozomi Networks Labs показала, почему это не теоретический риск. Исследователи разобрали цепочку уязвимостей в CODESYS Control Runtime for Raspberry Pi SL: CVE-2025-41658, CVE-2025-41659 и CVE-2025-41660. В связке они позволяли пользователю с низкими привилегиями получить доступ к криптографическим материалам, работать с резервной копией приложения и заменить программу на контроллере.

CODESYS закрыла эти уязвимости в обновлениях и добавила настройку, которая запрещает передачу неподписанного приложения для пользователей Service-группы в новых установках. Но обновление исполняемой среды не отменяет вопрос для действующих объектов: включены ли на конкретных ПЛК защитные механизмы, которые были доступны и раньше.

Из этого следует простой практический вывод: защиту ПЛК нельзя сводить к логину и паролю. Нужно ограничить канал связи, происхождение загружаемого кода и права пользователей.

Где обычно возникает риск

Первый типовой сбой: доверие к технологической сети как к закрытой зоне. На схеме она может выглядеть изолированной, но в реальности внутри появляются сервисные ноутбуки, временные подключения, станции подрядчиков, удаленные каналы обслуживания, старые HMI и оборудование, которое не пересматривали после пусконаладки. При такой картине незашифрованный обмен с ПЛК нельзя считать безопасным только потому, что он находится «внутри периметра».

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

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

Четвертая проблема: настройки проверяют один раз. ПЛК ввели в работу, линия не останавливается, технологи довольны, и любое изменение воспринимается по принципу «работает, не трогай». Затем меняется подрядчик, обновляется версия исполняемой среды, проект переносят на другую инженерную станцию, участок расширяется, схема удаленного обслуживания меняется. Конфигурация доступа уже другая, но ее никто не сверяет с исходной политикой.

Что требует регулятор

Для предприятий, где АСУ ТП относится к значимым объектам критической информационной инфраструктуры, такие настройки не являются вопросом инженерной аккуратности. Приказ ФСТЭК России № 239 требует поддерживать правила разграничения доступа в актуальном состоянии, управлять учетными записями, обновлениями и конфигурацией значимого объекта, включая программные и программно-аппаратные средства, настройки и программный код.

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

Три настройки, которые нельзя оставлять на потом

Первый базовый шаг: включить только шифрованное соединение между средой разработки и ПЛК. В CODESYS это режим Enforce encrypted communication. При его включении обмен с контроллером идет по защищенному каналу, а разработчик отдельно предупреждает, что отключать шифрованную коммуникацию не рекомендуется, особенно при включенном user management.

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

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

В CODESYS для этого используется политика EnforceSignedCode в разделе CmpApp. После включения контроллер должен отклонять загрузку приложения без валидной цифровой подписи. Но одного параметра недостаточно. Нужен порядок работы с ключами: кто выпускает сертификаты, где хранится закрытый ключ, кто подписывает проект, как оформляется доступ подрядчика, что происходит при смене инженера или компрометации рабочей станции. Без этого подпись превращается в формальную галочку.

Третий шаг: включить шифрование приложения и нормально настроить роли. Шифрование ограничивает возможность прочитать или разобрать загружаемый код. Это защита не только от атаки, но и от утечки инженерного know-how: в логике ПЛК часто зашиты режимы работы, ограничения, последовательности, аварийные сценарии и особенности конкретной линии. CODESYS описывает сценарий, при котором boot application передается в нечитаемом виде, а для загрузки на контроллер используется подходящий сертификат.

Ролевая модель решает другую задачу: ограничивает ущерб от ошибки или компрометации учетной записи. Оператору не нужны права на изменение логики. Подрядчику не нужен постоянный административный доступ. Инженеру обслуживания не всегда нужен полный набор прав на файловую систему и конфигурацию. CODESYS позволяет управлять пользователями и группами на уровне устройства, поэтому общие логины и максимальные права «для удобства» лучше заменить индивидуальными учетными записями и понятными ролями.

Практический чек-лист для инженера

Эти настройки стоит проверять при вводе ПЛК в эксплуатацию, после обновления исполняемой среды, смены подрядчика, переноса проекта на другую инженерную станцию и любого изменения схемы удаленного обслуживания.

1. Включить только шифрованное соединение с ПЛК. В CODESYS это настраивается через Device, Change Runtime Security Policy, Communication, Enforced encryption. Альтернативный путь: Device Security Settings, CmpSecureChannel, значение ONLY_ENCRYPTED. После применения политики текущая сессия может разорваться, это нормальное поведение. Следующее подключение IDE к контроллеру должно идти уже по защищенному каналу.
2. Запретить загрузку неподписанного кода. Для этого в Device Security Settings нужно найти раздел CmpApp и перевести EnforceSignedCode в значение YES. После включения политики контроллер должен отклонять приложение без валидной цифровой подписи. Это защищает от ситуации, когда на ПЛК загружается код, происхождение которого предприятие не может подтвердить.
3. Настроить сертификаты для подписи и шифрования приложения. Публичный сертификат нужно добавить в доверенные на ПЛК через View, Security Screen, Devices, Trusted Certificates. В среде разработки на вкладке User нужно выбрать сертификат для цифровой подписи и включить принудительное подписание и шифрование downloads, online changes и boot applications.
4. Включить шифрование приложения. В дереве проекта нужно открыть свойства объекта Application, перейти на вкладку Security, выбрать Protection, Encryption with certificates, добавить сертификат для шифрования и включить Digitally sign application code. После этого проект при загрузке будет шифроваться и подписываться, а ПЛК сможет проверить подпись перед запуском.
5. Настроить роли и убрать лишние права. В редакторе устройства нужно открыть Users and Groups, синхронизироваться с ПЛК, создать индивидуальные учетные записи и распределить пользователей по ролям. Администратор должен управлять конфигурацией и доступами, инженер или сервисный специалист работать с логикой и обслуживанием, пользователь уровня просмотра только наблюдать параметры. Anonymous нужно отключить или максимально ограничить там, где анонимный доступ не нужен.
6. Проверить восстановление. После включения подписи и шифрования важно убедиться, что предприятие сможет восстановить проект при аварии, замене оборудования или потере инженерной станции. Для этого нужны актуальные резервные копии проекта, сертификатов и понятный порядок доступа к закрытым ключам.

Эта проверка занимает меньше времени, чем расследование изменения, которое невозможно привязать к конкретному пользователю или версии проекта. Но сам по себе чек-лист не заменяет полноценную защиту OT. ПЛК остается частью более широкого контура: сети, инженерных станций, удаленного доступа, мониторинга, журналирования и управления версиями логики.

Что остается за пределами настроек CODESYS

После включения шифрования, подписи приложения и ролевой модели остается еще один практический вопрос: какая версия логики сейчас реально работает на контроллере. CODESYS помогает ограничить доступ к ПЛК, защитить канал связи и запретить загрузку неподписанного приложения. Но эти настройки сами по себе не показывают, чем текущая логика отличается от предыдущей, кто внес изменение, когда его загрузили на ПЛК и можно ли быстро откатиться к рабочей версии.

На промышленном объекте логика контроллера редко остается неизменной после пусконаладки. Ее дорабатывают после изменения технологического процесса, замены оборудования, сервисных работ, аварийных правок или замечаний от эксплуатации. Если проекты хранятся только на инженерных станциях или в папках с названиями вроде final, final_new и final_2, предприятие быстро теряет уверенность в том, какой файл считается актуальным.

Поэтому вместе с настройками безопасности нужен контроль версий проектной логики. Минимум: хранить эталонную версию проекта, фиксировать изменения, привязывать загрузку на ПЛК к пользователю и дате, сохранять предыдущие рабочие версии и проверять расхождения между проектом в хранилище и тем, что фактически загружено в контроллер.

Здесь важно не смешивать две задачи. Настройки CODESYS отвечают за то, кто может подключиться к контроллеру и какой код он имеет право загрузить. Контроль версий отвечает за историю самой логики: что изменили, зачем изменили, кто согласовал правку и какая версия должна считаться рабочей. Без этого ответ на вопрос «что сейчас загружено в ПЛК» часто остается в памяти инженера, который последним подключался к контроллеру.

Как внедрять без риска для производства

Самый опасный вариант: включать все настройки сразу на работающей линии без подготовки. Начинать нужно с инвентаризации. Какие ПЛК используются на объекте, какие версии исполняемой среды установлены, какие инженерные станции подключаются, кто имеет доступ, какие учетные записи активны, где хранятся проекты и есть ли актуальные резервные копии.

После этого лучше выбрать пилотный участок: один тип контроллера, понятный сценарий обслуживания, ограниченный круг пользователей. На нем можно проверить, как шифрование влияет на работу инженерной станции, как будет устроена подпись приложения, кто станет владельцем сертификатов и какие права действительно нужны инженерам, операторам и подрядчикам.

Затем настройки нужно закрепить в регламенте. Новые контроллеры вводятся с принудительным шифрованием. Загрузка неподписанного кода запрещается. Приложения шифруются сертификатами. У каждого пользователя есть собственная учетная запись. Административные права выдаются под конкретные задачи. Доступ подрядчика ограничивается сроком работ. Anonymous отключается или жестко ограничивается. После изменения конфигурации проводится проверка, а не просто делается запись в документе.

Такой порядок снижает конфликт между ИБ и АСУ ТП. Эксплуатация получает понятный сценарий изменений, ИБ получает управляемую модель доступа, бизнес получает меньше неопределенности вокруг того, кто и каким кодом управляет технологическим процессом.

Вывод

Безопасность ПЛК нельзя свести к межсетевому экрану перед технологическим сегментом. Если контроллер внутри этого сегмента принимает открытые соединения, неподписанные приложения и пользователей с избыточными правами, риск остается в самом контуре управления. Исследование Nozomi Networks Labs показало это предметно: обычного пользовательского доступа и штатной функции резервного копирования оказалось достаточно, чтобы построить цепочку компрометации устройства.

В CODESYS уже есть механизмы, которые закрывают часть базовых рисков на уровне контроллера. Но они работают только тогда, когда становятся частью эксплуатации: при вводе ПЛК, смене подрядчика, обновлении Runtime, переносе проекта, расширении участка и расследовании инцидентов.

Для руководителя это вопрос не интерфейса CODESYS, а управляемости производства. Кто имеет право менять логику. Какой код считается доверенным. Можно ли восстановить проект после сбоя. Можно ли доказать, кто выполнил изменение. Если на эти вопросы нет точных ответов, контроллер может быть исправным технически, но с точки зрения безопасности он остается недонастроенным.

Готового, что легло бы на мою ситуацию, я так и не нашёл — и в итоге сел писать своё. Ниже — разбор инженерных решений, которые по дороге пришлось принять, и карта того, где у этой конструкции проходит настоящая граница безопасности. Последнее для меня важнее всей остальной механики: MDM по определению даёт слишком много власти над чужими машинами, и делать вид, что это не так, я не стал. Поэтому архитектуру ниже я описываю как ответ на вопрос «где это ломается».

Откуда взялась задача

Требований у меня было немного, но именно они всё и отсеяли: сервер должен стоять у меня, телеметрия парка не утекать на сторону, и всё это работать на смешанном парке сразу. Self-hosted-вариантов под такое оказалось немного, и те, что были, спотыкались об одно и то же: либо только маки, либо платные и при этом недоступны в России, либо разваливались на простом вопросе — а что с устройством, если агент две недели просидел офлайн. Ближе всего в этом поиске подобрался Fleet — серьёзный открытый проект, к нему я ещё вернусь ниже. Но развернуть его у себя оказалось тем ещё квестом: я в России, а fleetdm на российский IP не але, так что и сервер, и сборку агентов приходилось поднимать через VPN. Вдобавок агент на macOS в моём случае вставал через раз, а то и вовсе не ставился. Инструмент, который в итоге получился, я назвал RoutineOps; дальше по тексту буду говорить «агент», «сервер» и «панель».

Ещё одно соображение, которое я держал в голове: базовую защиту управляющего канала — mTLS, аудит, вменяемую политику паролей, подпись обновлений — я считаю БАЗОЙ, и держать её за пейволлом мне казалось неправильным. Это моё мнение, не претензия к рынку. Проект в итоге открыт под Apache-2.0; платный уровень существует, но вся базовая защита — в открытой части, и это не тема статьи.

Почему постоянный gRPC/mTLS-канал, а не опрос через VPN

Вечная головная боль: как дотянуться до ноутбука, который сейчас сидит в кафе за чужим NAT. Классических ответов два, и оба мне не понравились. Загнать всех в VPN — это лишняя инфраструктура и ещё одна точка отказа. Сделать агент, который раз в N минут дёргает HTTP-эндпоинт «не прилетело ли чего», — это шторм пустых запросов, а задержка команд упирается в период опроса.

Я пошёл третьим путём. Агент — Go-бинарь, который держит постоянный gRPC-стрим поверх mTLS наружу, по обычному интернету. Соединение инициирует сам агент: оно исходящее, а значит дружит с NAT. По этому же двунаправленному стриму сервер в любой момент проталкивает команду — запусти скрипт, заблокируй экран. Задержка доставки тут — это задержка сети, а не интервал, на который выставлен опрос.

Стек намеренно скучный — скучное не будит меня в три ночи.

- Агент и сервер — Go, сервер монолитом, без зоопарка микросервисов.

- Связь — gRPC + Protocol Buffers поверх mTLS: TLS 1.3, приватный CA с пиннингом на всём канале агентов.

- База — PostgreSQL 16, источник правды.

- Очередь задач — Redis + Asynq, с ретраями.

- Веб-интерфейс — React + TypeScript (Vite), раздаётся nginx-контейнером.

- Развёртывание — Docker Compose.

Порты минимальны: `443` — веб-интерфейс, REST API, enroll, отдача бинарей; `50051` — постоянный gRPC-канал агентов. Postgres и Redis наружу не торчат вообще. На парк до 50 устройств хватает 1 vCPU / 2 GB RAM / 20 GB SSD — и это стартовая планка. Heartbeat дешёвый, инвентарь редкий, поэтому один узел спокойно тянет тысячи устройств: предел задаёт железо машины, не архитектура.

Сертификат — это идентичность, и всё

Самый важный архитектурный вопрос: как агент доказывает, что он именно то устройство, за которое себя выдаёт. Ответ короткий. `device_id` — это CN клиентского сертификата, и только он. Идентификаторам в теле сообщений сервер не верит вообще. Прилетел heartbeat, а внутри указан чужой `device_id`? Игнорируется. Значение имеет одно — чем подписан TLS-хендшейк.

Отсюда и enrollment, устроенный так, чтобы приватный ключ устройства никогда не покидал устройство:

1. Админ в панели заводит устройство и получает одноразовый токен: TTL 24 часа, single-use, гонка при погашении закрыта на уровне БД.

2. Агент локально генерирует пару ключей и отправляет CSR на `POST /api/v1/enroll`.

3. Сервер подписывает сертификат своим приватным CA и сам проставляет CN. Повлиять на свой CN агент не может.

Подделать чужое устройство без его ключа не выйдет — и не потому, что «мы проверяем поля», а потому, что проверять тут в принципе нечего. Криптография здесь вырезает целый класс авторизационной логики. Решение нравится мне тем, что после него кода становится меньше.

Вывод из эксплуатации — это отзыв сертификата

Раз идентичность держится на сертификате, то и снятие устройства с учёта — операция того же уровня, а не косметика в списке. «Вывести из эксплуатации» прямо из карточки отдаёт агенту команду на полное самоудаление: служба, бинарь, ключи, локальное состояние. Удаление из инвентаря при этом отзывает сертификат — и устройство, с которого агент по каким-то причинам не ушёл, обратно не «воскресает»: его хендшейк отваливается на сервере, потому что предъявлять ему больше нечего.

Enrollment подтянулся туда же. Токены выписываются пачкой, есть список выданных, отзыв любого до истечения TTL и отдельная секция «выдан, но так и не подключился». После раскатки на два десятка машин именно этот список отвечает на вопрос, какие из них до сервера не доехали.

Heartbeat и инвентаризация разведены нарочно

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

Heartbeat — лёгкий и частый, примерно раз в 30 секунд, по постоянному стриму; по нему же едут задачи. Дёшево, потому что данных в нём кот наплакал. Инвентаризация — тяжёлая и редкая, примерно раз в 5 минут: ОС, железо, серийник, установленное ПО (на Linux — из dpkg/rpm/pacman/apk), версия агента.

Такое разделение держит постоянный канал дешёвым при любом размере парка. Если устройство пропало с радаров и heartbeat не приходит дольше порога (порог настраивается через `AGENT_UNREACHABLE_MINUTES`) — поднимается алерт `agent_unreachable`, с подавлением дребезга от сна и modern standby, иначе каждый закрытый на ночь ноут спамил бы в Tele... Max :).

Результаты скриптов идемпотентны. У каждого запуска есть `run_id`, и повторная доставка дедуплицируется на сервере. Связь рвётся, ack теряется, агент шлёт результат заново — без этой механики ловил бы дубли, а на неидемпотентных командах ещё и двойное исполнение.

Скрипты, группы и вопрос «а на скольких машинах это сейчас так»

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

У скрипт-политик три триггера: расписание (cron), при подключении агента и по событию. Третий появился из практики — реакция на «поставили запрещённое» полезна в момент установки, а не в ближайшие плановые три часа ночи. Софт-политики — правила allowed/forbidden по устройству, группе или платформе; они же кормят алерты: увидел агент в инвентаре то, чего быть не должно — прилетело событие.

А поверх этого — то, чего мне больше всего не хватало в чужих инструментах: по каждой политике видно охват и Pass / Fail. На сколько устройств она распространяется и сколько из них ей соответствуют. Политика без счётчика соответствия — не политика, а благое пожелание, лежащее в базе.

Агенту не нужна постоянная связь

Постоянный канал удобен, но агент не должен превращаться в кирпич, стоит серверу отвалиться. Cron-скрипт-политики крутит локальный планировщик прямо на устройстве: сервер лёг на обновление — политики по расписанию всё равно отработают.

Сложнее всего с блокировкой экрана. В офлайне полноэкранный overlay держится, а разблокировка идёт по локально хранимому bcrypt-хешу пароля — ходить за ней к серверу не нужно. Это осознанный компромисс: если бы разблокировка требовала сервер, любой обрыв связи превращал бы блокировку в невозможность войти в систему — а это уже хуже самой угрозы. Результаты и события тем временем копятся локально и досылаются, когда связь вернётся.

Обход блокировки — это тоже событие

Оверлей держится офлайн, но живёт он на машине, у пользователя которой есть руки. Поэтому у службы агента есть tamper-protection: на Windows — SafeBoot плюс реестр, на macOS — флаг `schg`. На Linux её нет, и это записано в docs/tamper-protection.md прямым текстом, а не подразумевается. Штатное снятие защиты — отдельная процедура, а не «убил процесс и пошёл дальше».

Попытка снять блокировку в обход службы поднимает событие ИБ. Логика та же, что и везде выше: при физическом доступе к железу механику рано или поздно обойдут — но пусть обход хотя бы не будет тихим. Не остановить, так зафиксировать.

Временные админ-права — без поездки к машине

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

Теперь пользователь запрашивает временные локальные админ-права прямо из трея агента, я одобряю заявку в панели — и он ставит нужное сам, а по истечении срока повышение снимается. Ни подходить к машине, ни поднимать удалённую сессию ради одной инсталляции не надо. Мелочь на фоне остальной механики, но именно из таких мелочей и складывалось то самое «здраво администрировать парк», ради которого всё и затевалось.

Конфигурация как код — потому что кликать второй раз я не хотел

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

Поэтому появился CLI `routineops` с YAML-экспортом и применением: выгрузил скрипты, политики и группы в файлы, положил в git, применил на другом сервере. Diff конфигурации теперь читается в ревью, а не реконструируется по журналу аудита задним числом.

Fail-closed self-update и миграции

Самообновление — самый опасный канал из всех. Тот, кто им рулит, кладёт свой бинарь на все устройства как root. Поэтому здесь всё fail-closed. Примерно раз в 6 часов агент тянет манифест и проверяет sha256 и ed25519-подпись по полному манифесту: версия, ОС, архитектура, хеш подписаны одним набором сразу. Так нельзя подсунуть валидный бинарь под чужую версию или платформу. Дальше агент атомарно заменяет себя и перезапускается. Даунгрейд невозможен — есть anti-rollback floor: битый релиз чинится только версией вперёд, назад дороги нет. Приватный ключ подписи уникален для конкретной инсталляции; потеря не катастрофа — новый раздаётся через переэнролл.

На сервере тот же принцип. Схему накатывает отдельный migrate-сервис — до старта сервера. Не прошла миграция — сервер просто не поднимется на несовместимой схеме. Down-миграций нет, и это намеренно: откат — только из бэкапа, причём бэкап БД update.sh снимает сам перед каждым обновлением. Пережить факап из снапшота я предпочту тому, чтобы полагаться на корректность down-скрипта, накатываемого поверх наполовину применённого состояния.

Модель доверия: god-mode by design

А вот тут льстить не буду — и это, пожалуй, самая важная часть текста. MDM по своей природе — это god-mode над парком. Скрипт-канал исполняет произвольный `bash -c` / `powershell -Command` как root/SYSTEM на каждом устройстве. Это не дыра, которую я забыл заткнуть. Это и есть продукт: весь смысл MDM в том, чтобы раскатать одну команду на сотню машин разом. А такой инструмент по определению — санкционированный RCE.

Скажу прямо.

- Подписи на скрипт-канале нет. И не будет. Ed25519-подпись защищает только канал самообновления — анти-тампер и анти-даунгрейд бинаря. Она никак не ограничивает то, что вы запускаете на устройствах. Тезис «скомпрометированный сервер не сможет выполнить код на парке» — неверное прочтение. Ещё как сможет: выполнение произвольного кода на парке — это его штатная функция.

- `JWT_SECRET` (симметричный HS256) — единственный корень доверия панели. Кто прочитал этот секрет, тот печатает себе сколько угодно валидных admin-токенов. Не «подобрать пароль», не «обойти MFA» — просто сгенерировать подписанный токен и зайти админом.

- Отсюда единственный вывод: реальный периметр безопасности — это хост, на котором крутится сервер. Не TLS, не RBAC, не аудит. Они важны, но вторичны. Увели сервер — увели весь парк.

Харденинг этого хоста — работа оператора, и в SECURITY.md под неё лежит чеклист: SSH только по ключам, наружу открыты только два порта, Postgres и Redis — на localhost, `JWT_SECRET` генерируется через `openssl rand -base64 48` и лежит в режиме `600`, панель — за VPN или IP-allowlist, аудит-лог — в append-only хранилище с алертом на появление новых админов.

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

Что закрыто по умолчанию

Периметр — на операторе. Но всё, что можно закрыть кодом, закрыто по умолчанию, без единой галочки:

- Не стартует на слабом секрете. Требует `JWT_SECRET` от 32 байт и минимум 16 различных байт. Случайно уехать в прод на `changeme` не получится.

- Admin-JWT живёт 8 часов. Logout реально ревокирует токен через jti-блоклист. Смена или сброс пароля обнуляет все ранее выданные токены пользователя разом — через token-epoch.

- Lockout по IP и по аккаунту, bcrypt cost 12. Форма входа не выдаёт, какие аккаунты вообще существуют.

- Политика сложности пароля — для всех, включая seed-админа: от 8 символов, минимум 3 класса символов из 4. Даже первый администратор не заведётся с `admin/admin`.

- RBAC на две роли — `it_admin` (всё) и `viewer` (только чтение), с проверкой на сервере. Viewer, дёрнувший мутирующий эндпоинт прямо из DevTools, упрётся в 403 ещё на сервере.

- API-токены — отдельная сущность, а не админская сессия. Выпуск и отзыв из панели: интеграции ходят под своим токеном, и выключается такой доступ одним действием.

- Плюс одноразовые enroll-токены, журнал аудита на каждое привилегированное действие (retention по умолчанию 365 дней), security-заголовки (HSTS/CSP/X-Frame-Options/nosniff), rate-limit и cap на размер запроса.

Ни одна из этих механик не спасёт скомпрометированный хост — см. раздел про модель доверия. Они закрывают то, что реально можно закрыть на уровне приложения, и не притворяются, что закрывают больше.

Мелочи, из которых на самом деле состоит эксплуатация

Отдельного раздела каждая из них не заслуживает, но вместе они закрывают вопрос «а как я об этом узнаю»:

- Удалённая перезагрузка устройства или всей группы. Отсрочку отсчитывает сама ОС, а не таймер внутри агента: агент может умереть, ребут — нет.

- «Пользователь за консолью» в карточке. Кто прямо сейчас сидит за машиной. Без этого половина алертов повисает в воздухе.

- Владелец устройства — карточка человека. ФИО и почта, без аккаунта в панели и приглашения. Владелец — свойство железа, а не пользователь системы, и смешивать эти сущности я не стал.

- Расширенный инвентарь ПО: издатель, путь, архитектура, ключ снятия, машина/профиль. Инвентарь, по которому не отличить системную установку от пользовательской, для софт-политик бесполезен.

- `agent diag` на устройстве. Первый вопрос в поле всегда один — «почему агент не выходит на связь», и отвечать на него по логам сервера бессмысленно: сервер как раз ничего и не видит.

- Пагинация и серверные фильтры в списках устройств и в аудите. Скучно, но на 365 днях журнала это разница между инструментом и вечно думающей вкладкой.

Честные ограничения

Раз обещал честность — вот граница, без прикрас.

- Один узел — одна точка отказа. Для парка в режиме «поставил и работает» этого достаточно, но иллюзий про отказоустойчивость держать не стоит.

- Нет SSO и MFA. Вход по паролю плюс RBAC. Пока разумно держать панель за VPN или allowlist.

- macOS .pkg не подписан Apple. По двойному клику встретит Gatekeeper — ставится через `installer` из терминала.

- Скрипт-канал — это RCE by design. Подробно — в разделе про модель доверия выше.

- Интерфейс только на русском. Около 2000 строк захардкожены в компонентах, библиотеки локализации нет. Английский вторым языком — ближайший приоритет: публичный репозиторий с русским интерфейсом отсекает всех внешних.

- Оверлея блокировки на Linux нет. Состояние блокировки хранится, экрана нет.

- Запрещённое ПО детектится, но не удаляется. Алерт есть, автоматического устранения — нет.

- Под Windows нет сборки arm64. Для Linux и macOS arm64 есть.

Про Fleet

Ближайший открытый аналог, который я смотрел, — Fleet, тоже open source, ядро под MIT. Инструмент серьёзный и зрелый, и во многом он сильнее моего: настоящий нативный MDM с профилями конфигурации и zero-touch-энроллментом, live-запросы osquery по всему парку, расчёт на масштаб в сотни тысяч машин. Построен вокруг osquery, инфраструктура — MySQL плюс Redis за балансировщиком, под горизонтальное масштабирование.

Под мой случай он просто не сошёлся по устройству. Чтобы реально управлять маками, Fleet опирается на нативный Apple MDM — а это APNs-сертификат от Apple с ежегодным продлением плюс Apple Business Manager для zero-touch. Мне не нужна была SQL-аналитика по всему парку; нужен был лёгкий агент, офлайн-лок без APNs, инвентарь и скрипты. А поверх этого архитектурного несовпадения легли те самые бытовые проблемы с развёртыванием из России и капризным macOS-агентом, о которых я писал в начале.

Чему это меня научило

Самое неожиданное в проекте — что львиная доля инженерных решений оказалась не про «как добавить», а про «как убрать». Идентичность через CN вырезала целый класс серверной авторизации; fail-closed на миграциях и обновлениях — ветки «а что если накатилось наполовину». Разведённые heartbeat и инвентарь сняли лишний трафик. А карта модели доверия избавила меня самого от иллюзии, будто TLS и RBAC — это и есть безопасность. Настоящий периметр оказался в одном месте — на хосте сервера.

Исходники я открыл под Apache-2.0; прямую ссылку на репозиторий оставлю тут :). Если вам будет интересно я бы с радостью пообщался по замечаниям именно по модели доверия — по местам, где приложение должно что-то enforce-ить, но не делает.

PixelSmash — это критическая уязвимость в декодере MagicYUV медиафреймворка FFmpeg. Она получила идентификатор CVE-2026-8461 и оценку CVSS 8.8. Ошибка представляет собой запись за пределы выделенной памяти (heap out-of-bounds write) и затрагивает все приложения, которые используют FFmpeg для декодирования видео.

Уязвимость CVE-2026-8461 в FFmpeg оценена в CVSS 8.8.

Баг находился в коде 16 лет и затрагивает декодер MagicYUV.

Для атаки достаточно специально сформированного видеофайла — без прав и аутентификации.

Под угрозой плееры, медиасерверы, мессенджеры, облачные транскодеры и бытовые NAS.

Проверить систему можно командой ffmpeg -decoders | grep magicyuv.

Где опасность

Уязвимость опасна именно масштабом. MagicYUV включён по умолчанию во всех протестированных дистрибутивах — Ubuntu, Debian, Fedora, Arch, Alpine — до FFmpeg 9.0. Проблема проявляется не только в видеоплеерах, но и в файловых менеджерах, генерирующих миниатюры, медиасерверах, мессенджерах и облачных транскодерах.

Для эксплуатации не нужны ни права, ни аутентификация, ни предварительный доступ к системе. Достаточно, чтобы приложение попыталось декодировать вредоносный AVI, MKV или MOV размером около 50 КБ. Исследователи JFrog показали полную цепочку атаки: удалённое выполнение кода на Jellyfin через автоматическое сканирование библиотеки и на Nextcloud через провайдер превью видео.

• Десктоп: Kodi, mpv и другие плееры; миниатюры в файловых менеджерах.
• Серверы: Jellyfin, Emby, Nextcloud, Immich.
• Мессенджеры: Slack, Discord, Telegram.
• Облако: AWS MediaConvert, Cloudflare Stream и другие транскодинговые конвейеры.
• IoT и NAS: Synology, QNAP, smart TV и любые устройства, генерирующие превью.

Как проверить

Проверить наличие уязвимого декодера можно одной командой. Если в выводе есть строка VFS..D magicyuv, ваш FFmpeg подвержен уязвимости.

В случае положительного результата обновитесь до версии с патчем или пересоберите FFmpeg без декодера.

Как защититься

• Обновите FFmpeg до версии, содержащей исправление.
• Если обновление невозможно, пересоберите FFmpeg с флагом --disable-decoder=magicyuv.
• На серверах отключите автоматическую обработку загружаемых видео, где это не критично для бизнеса.
• Проверьте все устройства с FFmpeg: NAS, медиасерверы, IoT и контейнеры.

JFrog опубликовала минимальный патч для libavcodec/magicyuv.c. Он отклоняет искажённые значения slice_height, которые вызывают запись за пределы буфера. Корректный кодировщик MagicYUV всегда выдаёт выровненные значения, поэтому патч не ломает легитимные файлы.

FAQ

Выводы

PixelSmash — очередное напоминание о том, что foundation-библиотеки вроде FFmpeg работают под капотом огромного числа приложений. Один баг в кодеке, пролежавший 16 лет, одновременно угрожает десктопным плеерам, облачным транскодерам и бытовым NAS. Лучшая защита — своевременное обновление и аудит зависимостей.

Источник: JFrog Security Research / InfoQ.

Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.

Пройдя путь от простых Bash-скриптов и сторонних туннелей до полностью автоматизированной инфраструктуры, я создал проект ServeHub-2. В этой статье я подробно разберу, как эволюционировала сеть проекта, почему декларативный подход победил императивный и с какими неочевидными багами пришлось столкнуться в процессе автоматизации.

История настройки сетевой архитектуры

Использование Tuna

В самом начале проекта я еще не думал о VPN как о способе пробития NAT и основе, на которой будет строиться вся система. Первое, к чему я пришел — сервис Tuna. Если кратко, это аналог Cloudflare Tunnel за условные 300 рублей. У него очень приятный веб-интерфейс и невероятно простая настройка. Однако для полноценной независимой архитектуры он не подошел по двум причинам:

• Сервера Tuna находятся вне контроля пользователя.
• На удаленном сервере нельзя развернуть свои сопутствующие сервисы.

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

Вот пример конфига для tuna (все максимально просто, создаем контейнеры для ssh туннеля, чтобы был доступ ssh, а также основной http туннель с привязкой к nginx или любому другому прокси если такой есть):

В поисках гибкости: тесты Pangolin и переход к FRP

После Tuna я решил двигаться в сторону собственного контроля и попробовал Pangolin. Однако решение быстро отвалилось: для дешёвого сервера оно оказалось слишком «тяжёлым» и избыточным. Главные минусы — ощутимый оверхед по ресурсам и лишний слой принудительной веб-аутентификации перед самими сервисами. Это ломало нормальное взаимодействие с родными мобильными клиентами (вроде Element для Matrix или Bitwarden для паролей), где повторная авторизация в браузере просто не нужна.

На смену пришел FRP (Fast Reverse Proxy). Он выполнял ту же функцию проброса, но хостил я его уже на собственном арендованном VPS в режиме Layer 4 (TCP). Это дало абсолютную гибкость: внешний VPS не заглядывал внутрь пакетов и ничего не расшифровывал, а просто пересылал сырой поток домой. Кроме того, это отлично оптимизировало расходы: вместо 300 рублей за Tuna и ещё 300 рублей за отдельный VPN, я стал платить всего 500 рублей за один стойкий VPS, который мог настраивать как хочу. (к тому же можно было обойтись даже дешевле, так как VPS с 4 гб оперативки загружен всего лишь на 40%, процессор всего на 20%-40%)

FRP состоит из 2 конфигурационных файлов (один на удаленном сервере frp server, другой на локальном frp client), все также довольно просто, однако его можно использовать на разных слоях. У меня он брал трафик за стандартный TCP и передавал его на локальный сервер.

Также доп. фишка в том что основная конфигурация происходит именно в frpc, который, в свою очередь, передает часть настроек на frp на удаленном сервере.

frpc.toml:

frps.toml:

Полноценный переезд на WireGuard (AmneziaWG) и 8 часов отладки

Со временем архитектура эволюционировала в сторону полноценной VPN-сети на базе WireGuard, а точнее — его модификации AmneziaWG. Причин для этого шага было несколько:

• Безопасность: FRP всё же открывал внутренние ресурсы в публичный интернет, оставляя их доступными для сканеров портов.
• Удобство маршрутизации: Все участники сети стали равноправными узлами в одной виртуальной локальной подсети. Больше не нужно было настраивать постоянные односторонние пробросы.
• Дополнительный бонус: Поскольку удаленный VPS был куплен в Нидерландах, через этот же VPN я автоматически получил безопасный доступ ко всем зарубежным ресурсам.

Для реализации схемы на удаленном VPS был развернут контейнер wg-easy с поддержкой AmneziaWG, а на домашнем мини-ПК — клиентский контейнер Amnezia (сборка из Dockerfile с использованием amnezia-tools и модулем ядра хоста).

И именно здесь я поймал самый изнурительный баг проекта. После развертывания трафик упорно шёл только в одну сторону. Часов 8 ушло на диагностику iptables, маршрутов и чтение зарубежных форумов (что бесполезно, учитывая специфику наших блокировок). Оказалось, провайдер просто дропал обратный трафик стандартного WireGuard, так как пакеты шли без маскировки. Причина крылась в docker-compose.yml: у меня было прописано image: ghcr.io/wg-easy/wg-easy:latest. Как выяснилось, тег latest на Docker Hub намертво прилип к старой 14-й версии, а поддержка параметров AmneziaWG появилась только в ветке 15.x. Изменение тега на конкретную версию (15.3) решило проблему за секунду.

Благодаря переходу конфигурация получилась максимально простой, основные отличия от стандартной документации выделил в коде: (в основном то, на что пришлось долго рыть информацию)

Настройка Nginx

Чтобы сервисы были доступны исключительно внутри подсети VPN, я задействовал Nginx. Доступ к приложениям был жестко ограничен на уровне конфигурации — веб-сервер принимает запросы только из диапазона IP-адресов 10.8.0.0/24. Любые попытки постучаться на сервер из внешнего интернета без активного VPN-туннеля автоматически сбрасываются Nginx.

Логика распределения завязана на proxy-протоколе: Nginx на удаленном VPS выступает основным входным узлом, принимает зашифрованный трафик, заворачивает его в заголовки с реальным IP-адресом клиента и через туннель перекидывает на локальный Nginx домашнего сервера. Локальный веб-сервер уже сам расшифровывает SSL и распределяет трафик по конечным Docker-контейнерам, сохраняя реальные IP в логах безопасности.

Вставлю один кусок кода из nginx на удаленной машине для примера, так все остальное примерно похоже (конфиги использовались в виде .template):

SSL-сертификаты

Для получения валидных SSL-сертификатов я настроил работу через автоматический Certbot по challenge-валидации DNS-01 c API Webnames. Сам домен привязан к внутреннему IP-адресу 10.8.0.1. Проверка через DNS позволила выпустить единый wildcard-сертификат на весь домен и его поддомены без необходимости держать открытым 80-й порт веб-сервера наружу.

Уточню, что certbot запускается автоматически во время выполнения Ansible плейбука, поэтому самому кроме указания переменных ничего делать не нужно.

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

Вот настройка certbot:

История софта

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

Первый стек и оптимизация

Первыми на домашнем сервере прижились медиа-сервисы: Navidrome для стриминга музыки и Audiobookshelf для аудиокниг и подкастов. Они легковесные, имеют отличные мобильные клиенты с синхронизацией прогресса и полностью закрывают мои потребности. Позже к ним добавился Nextcloud как единое независимое облако для файлов, контактов и семейных документов.

Затем встал вопрос безопасного хранения паролей. Сначала я смотрел в сторону оригинального Bitwarden, но в итоге я выбрал Vaultwarden — альтернативный сервер на Rust, полностью совместимый с API Bitwarden. Он потребляет считанные мегабайты оперативной памяти и работает идеально. Дополнительно для удобства управления всей этой распределенной Docker-инфраструктурой в локальный стек был добавлен Portainer. (+ Portainer Agent на удаленный сервер)

Из интересных моментов, где мне пришлось немного больше возиться, чем с остальными сервисами это nextcloud настройка:

Ошибки проектирования: почему я удалил Matrix (Synapse)

Не все решения прошли проверку временем. На этапе использования Tuna и FRP я развернул сервер Matrix (Synapse) для защищенного обмена сообщениями. Мне казалось это крутой идеей, но когда я окончательно перешел на AmneziaWG, целесообразность мессенджера внутри закрытого туннеля сошла на нет.

Synapse требовал слишком много ресурсов, впустую расходовал оперативку домашнего ПК и усложнял конфиг Nginx. При этом реальной пользы для семьи он не приносил. Для критических алертов инфраструктуры и повседневного общения проще и эффективнее оказалось использовать Telegram. (плюс алертинг настроен именно через него) В итоге я полностью выпилил Synapse из стека, освободив ресурсы.

Вместо него я добавил в связку к wg-easy локальный AdGuard Home. Теперь он работает прямо внутри VPN-сети: очищает весь трафик от рекламы и трекеров на лету, кэширует DNS-запросы и не дает истории веб-серфинга улетать внешним провайдерам.

Основной проблемой с которой я столкнулся при использовании AdGuard Home, так это то что я так и не понял как заставить использовать AmneziaVPN клиент AdGuard как основной DNS, при этом AmneziaWG работает прекрасно. Как я понимаю дело в том что AmneziaWG работает намного проще на уровне ip и у него нету никаких доп фильтров, настроек и подобного, поэтому он просто берет данные из конфига.

От костылей на Bash к декларативному Ansible

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

Так я пришел к декларативному подходу и Ansible. Теперь вся конфигурация описывается в виде плейбуков и ролей, отражающих конечное желаемое состояние серверов. Конфиденциальные данные перенесены в файл secrets.yml, а хрупкие конструкции автоматизированы через шаблоны Jinja2. Проект стал идемпотентным: если шаги уже выполнены, Ansible их просто пропускает.

В итоге получилось несколько yaml файлов для стандартной настройки системы (bootstrap_os.yml) и для настройки каждого из хостов (setup_local.yml и setup_remote.yml). В итоге теперь все что нужно чтобы полностью с нуля развернуть проект - скачать Ansible, несколько других зависимостей на свой рабочий пк и запустить один manage_deploy.sh, в котором можно будет выбрать сценарий как будет вести себя Ansible и спокойно дождаться разворачивания сервисов.

Также благодаря Ansible я удобно реализовал переносимость проекта. Так как я решил не использовать тома docker, и вместо этого храню все в папках, чтобы перенести старые данные проекта нужно просто скопировать папку apps-data и положить ее в нужное место и все само заработает после повторного развертывания проекта. В Ansible выделяется отдельная пауза для этого.

Вот пример основного плейбука deploy.yml:

Тестирование мультидистрибутивности с помощью Vagrant

Проект изначально затачивался под работу на трех дистрибутивах: Ubuntu, Debian и Arch Linux. Тестировать Ansible-плейбуки прямо на рабочей локальной машине (в моем случае — EndeavourOS) слишком рискованно, а создавать виртуальные машины руками — долго и неудобно.

Решением стал Vagrant, позволяющий за пару минут развернуть чистые ОС в VirtualBox из готовых образов. Но в процессе настройки мультивендорного стенда в режиме сетевого моста (public_network) всплыли две критические проблемы:

1. Конфликт DNS: По умолчанию Vagrant создает NAT-интерфейс для управления нодой. При включении второго (публичного) интерфейса для локальной сети ломался дефолтный DNS-резолвер. Проблему пришлось решать принудительной очисткой и перезаписью файла /etc/resolv.conf через inline-скрипт автоматизации Vagrant.
2. Проблема с GRUB на Debian: В используемом базовом образе generic/debian12 конфигурация GRUB сохраняла жесткую привязку к конкретному имени диска из окружения сборщика. При повторном развертывании плейбуков на тестовом стенде это приводило к сбоям загрузчика. Чтобы автоматизировать очистку, пришлось внедрить скрипт, который на лету определяет имя системного диска через lsblk и автоматически передает правильные параметры в загрузчик через утилиту debconf-set-selections.

Вот код Vagrantfile: (в node.vm.provision происходит основное решение ошибок)

Надежная система бэкапов на базе BorgmaticДля создания резервных копий я внедрил Borgmatic (удобную надстройку над дедуплицирующим инструментом Borg Backup). Весь процесс автоматизирован с помощью связки системных юнитов borgmatic.service и borgmatic.timer. В бэкап уходят две ключевые директории: apps-data (конфигурации приложений и баз данных) и PersonalData (медиатека: музыка, книги, подкасты, файлы Nextcloud).

Развертывание системы бэкапов полностью берет на себя Ansible. Мне достаточно указать UUID внешнего жесткого диска — скрипт сам проверит его наличие в системе, примонтирует в нужную директорию, создаст зашифрованный репозиторий и настроит политику ротации (хранение 7 ежедневных, 4 еженедельных и 6 ежемесячных копий). Также в Prometheus выведен мониторинг самого репозитория .borg для отслеживания его размера и статуса успешности архивации.

Главная проблема при бэкапе работающих Docker-контейнеров — риск скопировать базу данных в «битом» или неконсистентном состоянии, если в момент создания архива в нее шла активная запись. Чтобы решить эту проблему, я задействовал механизм хуков в конфигурации Borgmatic.

Перед началом резервного копирования автоматически срабатывает команда остановки контейнеров проекта (docker-compose down), а после успешного завершения (или в случае возникновения непредвиденной ошибки) контейнеры автоматически поднимаются обратно в фоновом режиме. Для удобного просмотра архивов и быстрого восстановления файлов я развернул веб-интерфейс Borg UI.

Конфигурация borgmatic: (использую как Jinja2 шаблон, чтобы Ansible в плейбуках сам подставил переменные)

Наблюдаемость (Observability) уровня Enterprise

В последних релизах (v1.2.0 и v1.3.0) фокус проекта сместился на мониторинг и работу с логами.

Эволюция алертинга и переход на Gatus

Изначально для мониторинга доступности я смотрел на Uptime Kuma, но отказался из-за отсутствия удобной декларативной настройки через конфиги. Затем я развернул связку Blackbox Exporter и Alertmanager с уведомлениями в Matrix. Но тут крылась логическая несостыковка: весь алертинг был завязан на локальном ПК, и в случае его аппаратного отказа я бы просто лишился уведомлений.

Тогда я решил вернуть Uptime Kuma, но развернуть его на удаленном VPS в качестве внешнего «сторожа» и автоматизировать его настройку через Python-скрипт с библиотекой uptime-kuma-api. Но и тут ждали «грабли» — библиотека не обновлялась три года и намертво ломалась на свежих версиях Kuma.

В итоге идеальным решением стал Gatus. Он изначально проектировался под управление через YAML-конфиги и поддерживает отправку алертов, если сервер не отвечает. Из-за специфики фронтенда Gatus (он не умеет работать из подкаталога типа /gatus), мне пришлось перенести его и wg-easy на полноценные субдомены gatus. и wireguard.

Для Gatus получился простой конфиг:

Для мониторинга аппаратных ресурсов удаленного и локального серверов была развернута связка node-exporter + cAdvisor. Все уведомления теперь приходят мгновенно в Telegram-бота. Чтобы избежать лавины одинаковых сообщений (например, при перезагрузке хоста), в Alertmanager настроена жесткая группировка и дедупликация событий. Также добавлен экспортер для AdGuard Home, выводящий статистику заблокированных запросов в Grafana.

Централизованные логи: Loki + Grafana Alloy

В релизе v1.3.0 в стек была добавлена централизованная система сбора логов Loki. Вместо устаревшего Promtail в качестве агента сбора я применил Grafana Alloy.

Он эффективно собирает логи со всех запущенных Docker-контейнеров, парсит их и передает в Loki. Теперь вся история событий, ошибок веб-сервера Nginx или падений внутренних приложений доступна в едином интерфейсе Grafana с возможностью удобной фильтрации через LogQL, что значительно упрощает отладку.

Конфиг Loki:

Конфиг Grafana Alloy: (локальный конфиг)

Интерфейс: переход на Homepage

Изначально для домашней страницы я написал кастомную минималистичную HTML-панель с Glassmorphism-дизайном. Выглядело это красиво, но добавлять новые сервисы вручную через постоянную правку исходного кода было крайне неудобно.

В итоге я заменил самописную страницу на полноценный комьюнити-проект Homepage. Это дало некоторую гибкость: вся панель настраивается через простые YAML-файлы и поддерживает встроенные виджеты интеграции. Пока что она простенькая, но возможно в будущем сделаю что-то более продвинутое.

Заключение

Постарался подробно рассказать о структуре проекта и как я к этому пришел, очень много я не добавил, если пост зайдет, то я обязательно более подробно пройдусь по некоторым моментам: как я настраивал Matrix и на каком моменте я решил его убрать, как собирал локальный amnezia контейнер-клиент, что нового я добавил в релизе 1.4.0 и другое.

Также я перешел с manage_deploy.sh на отдельный GUI клиент, который будет полностью автоматизировать процесс подготовки к deploy. (написан на Go Wails). Про это тоже возможно сделаю статью.

Вся кодовая база проекта, подробная документация, инструкции по развертыванию открыты и доступны для сообщества:

🔗 GitHub-репозиторий: https://github.com/canntstand/ServeHub-2

Это моя первая статья на этом сайте и в то же время первый личный проект, которому я отдал так много времени (3 месяца). Буду рад вашему фидбеку в комментариях!

Grok Build — это консольный помощник для разработчиков, способный читать файлы, редактировать код и выполнять команды в терминале. Ранее он работал только как проприетарный сервис, а теперь его можно собрать локально и подключить к собственному серверу вывода.

Исследователь Cereblab перехватил трафик Grok Build 0.2.93 и обнаружил загрузку 5,1 ГБ в корзину Google Cloud — в 27 800 раз больше, чем требовала задача.

В выгрузку попадали файлы, которые агент никогда не открывал, а также неотредактированные credentials из .env и SSH-ключи.

xAI отключила сервер загрузки 13 июля, а 15 июля опубликовала код под Apache 2.0.

Компания обещает удалить ранее загруженные данные, но не раскрывает масштаб утечки.

По данным издания DevOps.com, исследователь под псевдонимом Cereblab использовал mitmproxy, чтобы перехватить сетевой трафик версии 0.2.93. Тестовый репозиторий объёмом 12 ГБ привёл к передаче около 192 КБ полезного трафика, но параллельно в корзину grok-code-session-traces ушло 5,1 ГБ в 73 частях. Внутри оказались файлы, не связанные с текущей задачей, включая SSH-ключи, базу паролей, личные документы и фотографии.

Переключатель «Improve the model» не влиял на поведение: загрузка шла независимо от настроек приватности. Это противоречит маркетинговым заявлениям xAI о том, что во время сессии код не покидает компьютер пользователя. 13 июля серверную сторону отключили без security advisory, а Илон Маск пообещал «полностью и безвозвратно» удалить все ранее собранные данные.

Открытый код позволяет аудировать, что именно агент делает с доступом к файловой системе. Но внешние пул-реквесты не принимаются: это релиз прозрачности, а не сообщество-driven проект. Кроме того, открытие исходников не объясняет, зачем существовал скрытый канал и у кого из сотрудников xAI был доступ к собранным данным.

Что делать разработчикам

• Если до 13 июля запускали Grok Build на репозиториях с живыми credentials — смените пароли, SSH-ключи и токены.
• Проверяйте сетевую активность любых агентов с доступом к файловой системе через инструменты вроде mitmproxy.
• Запускайте ИИ-агентов в изолированном окружении с ограниченными правами.
• Требуйте от вендора письменной политики обработки данных до развёртывания инструмента.

Инцидент с Grok Build показывает, что кодовые агенты — это неконтролируемые нечеловеческие идентификаторы с постоянным доступом к коду, учётным данным и инфраструктуре, но программы безопасности всё ещё управляют ими как обычным инструментом разработчика. Публикация исходного кода после факта не заменяет доказуемые средства контроля безопасности.

Источник: DevOps.com.

Если верить маркетинговым материалам, современные решения способны самостоятельно выявлять атаки, расследовать инциденты, прогнозировать угрозы и почти заменить аналитиков SOC. И когда заказчик слышит слово «ИИ», то ожидает почти универсального цифрового эксперта. Но после внедрения оказывается, что чудес не произошло, ведь за громкими заявлениями часто скрываются совершенно разные технологии, где рядом с генеративными языковыми моделями «сидят» классическая корреляция событий или машинное обучение.

Давайте разберемся, где искусственный интеллект действительно помогает специалистам по ИБ, а где пока остается скорее маркетинговым ярлыком.

Причины этого понятны:

• Рынок ИБ испытывает серьезный кадровый дефицит, и найти опытного аналитика SOC, специалиста по расследованию инцидентов или эксперта по threat hunting становится все сложнее.
• Бизнес постоянно ищет способы повысить эффективность и сократить расходы.
• Вендоры заинтересованы в том, чтобы показать свои продукты максимально инновационными.

На стыке этих факторов рождается опасное ожидание: технология продается как надежда, а значит, достаточно купить решение с пометкой «ИИ», и значительная часть проблем безопасности исчезнет сама собой. Технологии действительно помогают, но исполняют не все обещания и некоторые предвыборные обещания остаются нереализованными.

Но сначала уточним…

Что сегодня называют ИИ в ИБ

Проблема ложных ожиданий рождается из одной простой уловки: вендоры намеренно стирают границы между разными технологиями, называя всё одним модным словом «ИИ». Чтобы понять, где нас обманывают, давайте на секунду станем занудами и разведём понятия по полочкам.

№1. Классические правила корреляции

Они присутствуют, к примеру, в SIEM-системах. SIEM-система может сработать, если пользователь вошёл в сеть ночью, получил административные права и начал выгружать данные. Но никакого искусственного интеллекта в них нет, а есть заранее заданные правила.

Для аналитика SOC разница между правилами и ИИ — это не академический спор, а вопрос выживания смены. Когда система позиционируется как «с ИИ», ожидания у всех выше: «Она должна видеть больше, понимать контекст, снижать шум». А по факту это те же правила корреляции, только с новым интерфейсом.

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

Да, правила корреляции — это база SOC. Они закрывают огромный пласт типовых угроз и делают это надёжно. Но давайте называть вещи своими именами: это не ИИ — это грамотная инженерия. И именно на этой базе мы строим реальную защиту, а не на красивых словах.

№2. Машинное обучение

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

Я сам экспериментировал с ML-модулем в одном из решений: подключили, обучили, запустили в пилот. Вендор обещал «снижение шума на ХХ процентов» и раннее обнаружение сложных атак.

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

Этот пилот всех быстро приземлил, и стало понятно, что это не «умная кнопка», а инструмент, который нужно долго калибровать под конкретную инфраструктуру.

№3. Генеративный ИИ

Это уже языковые модели. Они умеют анализировать текст, писать запросы, формировать отчёты и помогать специалистам взаимодействовать с системами безопасности.

Проблема в том, что в маркетинговых презентациях все три технологии часто называют одним словом — ИИ. Поэтому первое, что стоит выяснить при выборе продукта: какая именно технология используется «под капотом».

И самое главное — нельзя верить обещаниям без цифр. Нужно требовать от вендоров не красивые слайды, а реальные метрики, например долю ложных срабатываний (FP), время на валидацию одного алерта и процент реально выявленных инцидентов. Иначе всё это просто слова в презентации.

А «предвыборные обещания» вендоров утомляют. Но не потому, что я против прогресса, а потому, что они создают иллюзию безопасности — и эта иллюзия опасна.

Когда CISO согласует решение «с ИИ» за 20+ млн рублей, ожидая, что оно закроет дыру в защите, а на деле там обычная корреляция по трём правилам, страдает не просто бюджет. Страдает реальная защищённость компании. И расхлёбывать последствия придётся живым людям: аналитикам, инженерам, тем, кто не верит в чудо-кнопки.

Не нужно продавать надежду как технологию. Технологии действительно помогают, но исполняют не все обещания. Давайте посмотрим, какие предвыборные обещания остаются нереализованными.

Где маркетинг пока опережает технологии

Ниже — четыре главных «обещания», которые я слышу слишком часто.

Обещание №1. ИИ сам найдет неизвестные атаки

Это один из самых популярных тезисов на рынке, и формально он не является ложью, так как современные решения класса UEBA, NDR, XDR и некоторые SIEM действительно способны выявлять аномалии, которые сложно обнаружить вручную.

Представим ситуацию:

• Сотрудник бухгалтерии никогда не подключался к корпоративной сети ночью.
• Он не использует PowerShell.
• Он не работает с серверами.

Внезапно в три часа ночи его учётная запись входит через VPN, запускает PowerShell и начинает обращаться к нескольким серверам. Каждое действие по отдельности может не выглядеть подозрительно. Но алгоритм машинного обучения видит отклонение от привычного поведения пользователя и формирует инцидент. Здесь технология действительно работает.

Однако есть важный нюанс. Система выявляет аномалию, а не атаку. Возможно, это злоумышленник. А возможно, сотрудник ИТ-службы временно использовал учётную запись для проведения работ.

Именно поэтому окончательное решение всё равно принимает аналитик.

Пример с ситуацией выше я добавил не случайно. Пару лет назад я сам столкнулся с такой ситуацией, когда тревога пришла по учётной записи, которая вообще не должна была «светиться» ночью (классика для заголовка «ИИ поймал хакера»).

А реальность оказалась банальнее: обычный рабочий процесс, просто оформленный как атака. Да, система поймала аномалию и формально была права. Но реакция на неё могла стоить компании простоя, срыва отчётности и нервотрёпки всей команде.

Этот случай показал, что самая опасная вещь в ИБ — иллюзия, будто технология уже закрыла проблему. Система честно сделала свою работу — нашла аномалию. Но именно человек должен решить, что с ней делать. И если мы будем считать, что ИИ уже всё решил, мы сильно рискуем.

Обещание №2. Автоматическое расследование сложных инцидентов

Многие производители заявляют, что их ИИ способен самостоятельно расследовать инциденты. Частично это правда.

Система может собрать логи, построить таймлайн и показать цепочку событий. Но полноценное расследование требует понимания бизнес-контекста.

Представим производственную компанию: нарушитель получил доступ к инженерной станции и начал движение в сторону технологического сегмента. ИИ способен показать подозрительную активность, но он не знает:

• какие системы критичны;
• какие подрядчики сейчас работают на объекте;
• какие последствия вызовет отключение оборудования.

Без этого контекста расследование невозможно завершить автоматически.

Обещание №3. ИИ заменит аналитиков SOC

Ооо, это одно из самых популярных заблуждений!

Причина его популярности понятна — SOC испытывают постоянную нехватку кадров, а атаки усложняются. Но если посмотреть на реальные проекты, становится очевидно: сегодня ИИ выступает скорее помощником аналитика.

Например, современные платформы могут автоматически:

• группировать связанные события;
• удалять часть ложных срабатываний;
• собирать контекст по инциденту;
• формировать черновики отчётов;
• предлагать возможные сценарии реагирования.

Всё это серьёзно снижает нагрузку на специалистов.

Однако представим реальный инцидент: компания обнаруживает подозрительную активность на сервере, обслуживающем интернет-магазин. ИИ собирает артефакты и сообщает о возможной компрометации. И дальше возникает целый ряд вопросов:

• Можно ли отключить сервер прямо сейчас?
• Сколько клиентов потеряют доступ к сервису?
• Есть ли резервная площадка?
• Какие финансовые потери возникнут в случае остановки?

Ответов на эти вопросы в логах нет.

Это не делает систему плохой: она честно ловит отклонения. Но это делает нашу работу сложнее: приходится тратить время на проверку легитимных действий, потому что контекст «так договорились» в модель не заложен.

Именно поэтому я не верю в «автоматическое обнаружение неизвестных атак» без участия человека. Алгоритмы видят цифры, а мы видим людей и процессы. И пока эти две картины не совпадают, аналитик остаётся незаменимым ключевым участником процесса.

Обещание №4. Разработка стратегии безопасности

Ещё один популярный сценарий. Допустим, компания оказывает услуги аутсорсинга, участвует в тендерах, работает с персональными данными и обязана использовать российское ПО. Если попросить языковую модель разработать стратегию ИБ, результат будет выглядеть весьма убедительно: появятся рекомендации по управлению рисками, мониторингу, обучению сотрудников и контролю доступа.

Однако модель не знает:

• ограничений бюджета;
• особенностей корпоративной культуры;
• реальных рисков бизнеса;
• требований ключевых клиентов или акционеров.

В итоге получится хороший шаблон. Но стратегия безопасности всегда требует участия человека.

Однажды я видел подобное: на стол руководству ложилась «стратегия ИБ», сгенерированная языковой моделью. Всё выглядело солидно: разделы, термины, формулировки, даже матрица рисков. На первый взгляд это готовый документ, который можно отправить «наверх».

А вот начинаешь копать под реальные процессы — и всё рассыпается, потому что модель не знает, что у нас аутсорс-разработка, часть команд работает в часовых поясах +7, бюджет на ИБ ограничен, а инфраструктура требует отдельного контура с шифрованием. Если бы внедряли всё это вслепую, получили бы либо неработающие процессы, либо постоянные конфликты между безопасностью и бизнес-подразделениями.

Это как дать штурману универсальный маршрут, не зная, где мели и штормы на твоём пути. Я не против использовать ИИ для черновиков и структуры. Но финальная стратегия должна быть подписана человеком, который готов отвечать за её реализацию. Иначе это не стратегия, а шаблон.

Где ИИ действительно приносит пользу

Читая предыдущий раздел, может сложиться впечатление, что я концептуальный враг искусственного интеллекта. Это, конечно же, не так.

ИИ в ИБ — это не волшебная палочка, которая заменит человека, а мощный экскаватор. Бесполезно пытаться копать им траншею в цветочном горшке (как в случае со стратегией), но на правильной стройке он творит чудеса, поэтому я бы хотел показать, где ИИ реально отрабатывает свою стоимость.

Антифрод

Если искать область, где технологии доказали свою эффективность, то это финансовый сектор.

Я работаю с антифрод-системами уже больше 8 лет. В 2018 году это были в основном правила и скоринговые модели. Система смотрела на совокупность параметров: сумму, страну, тип устройства. Если транзакция не укладывалась в жёсткие рамки, то срабатывало правило, а если укладывалась — пропускалась. И этого хватало ровно до тех пор, пока мошенники не научились обходить эти рамки.

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

К 2026 году антифрод стал принципиально другим. Это уже не просто набор правил, а карнавал моделей, которые видят не отдельные признаки, а паттерны кликов, скорость заполнения форм, отклонения от привычного ритма и нюансы взаимодействия с приложением.

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

Антифрод-система анализирует десятки факторов одновременно: локацию, тип операции, историю поведения клиента и прочее. И если, например, клиент банка пенсионного возраста в 13:00 оплатил продукты в магазине рядом с домом, а в 14:00 купил что-то на 180 000 рублей в интернет-магазине посредством только что установленного мобильного приложения с IP-адресом Нью-Йорка, то такая операция блокируется. И здесь, как никогда, полезен ИИ.

Разница между 2018 и 2026 годами огромна — это переход от «защиты по порогам» к «защите по профилю». И этот переход был не про маркетинг, а про реальную необходимость: угрозы стали умнее, и защита должна была стать умнее тоже.

Поведенческая аналитика

Ещё один хороший пример — системы класса UEBA.

Представим системного администратора:

• В среднем он скачивает около 200 МБ данных в день.
• Работает в стандартное время.
• Подключается только из корпоративной сети.

За неделю до увольнения он начинает регулярно заходить ночью и выгружает 40 ГБ архивов с файлового сервера.

Каждый признак сам по себе может быть допустимым. Но вместе они формируют серьёзную аномалию. Система выявляет отклонение от исторического профиля пользователя и уведомляет службу безопасности.

Именно в таких сценариях машинное обучение показывает лучшие результаты.

Генеративный ИИ для аналитиков

Отдельно стоит упомянуть современные языковые модели. Многие вендоры уже внедряют их в свои платформы. Например, аналитик может написать: «Покажи все подключения к внешним IP-адресам с сервера бухгалтерии за последние сутки». Система самостоятельно сформирует необходимый запрос.

Или другой пример. Аналитик получает сложное правило обнаружения атаки и просит систему объяснить его простым языком. Модель формирует понятное описание логики работы этого правила.

Это не выглядит революцией. Но экономия времени весьма заметна.

Корреляция больших объемов событий

И, пожалуй, самый успешный сценарий применения технологий.

Современная инфраструктура генерирует миллионы событий ежедневно, и человек физически не способен обработать такой объём информации. Алгоритмы же могут находить взаимосвязи между событиями, разделёнными днями или даже неделями. Именно поэтому многие современные SIEM- и XDR-платформы используют элементы машинного обучения.

Как отличить реальный ИИ от маркетинговой наклейки

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

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

Как отсечь маркетинг от инженерии на этапе покупки? Когда вы видите рекламный баннер ИБ-продукта с ИИ (который, кстати, тоже сгенерирован ИИ), какие вопросы нужно задать, чтобы не купить кота в мешке?

Есть несколько простых вопросов:

• Какая именно технология используется?
• На каких данных обучалась модель?
• Какие показатели улучшились после внедрения?
• Как эти показатели измерялись?
• Есть ли реальные кейсы заказчиков?

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

И в помощь также оставлю сравнительную таблицу: «Маркетинг vs реальность». Надеюсь, эти материалы помогут вам принять правильное решение.

Что показывает статистика

Компания Linx вместе с сообществом Global CIO в конце прошлого года опросила руководителей, которые отвечают за развитие IT-инфраструктуры, из компаний в 27 городах России и СНГ. В выборке 15 отраслей, больше всего – производство, банки и торговля. Картина такая.

С потерей выручки из-за простоев сталкивались все опрошенные компании без исключения. 69% ловят перебои еженедельно, 14% – ежедневно. То есть речь не о случайных форс-мажорах, а о регулярном фоне, который может случиться в любой момент. При этом устойчивой к сбоям свою инфраструктуру считает только каждая пятая компания.

Формальный план аварийного восстановления есть у многих, но два респондента из пяти признались, что не проводят реальных тестов вообще, и только один из пяти сочетает документированную DR-стратегию с регулярными проверками. Идеальная частота тестирования – раз в квартал, так делают 8% опрошенных. Половина ограничивается тестом раз в полгода или в год.

Дальше самое показательное. Когда авторы исследования сопоставили ответы, выяснилось: у половины компаний, которые не тестируют восстановление, оно и не сработало, когда понадобилось. Всего по выборке 19% не уложились в заданные временные рамки, ещё 15% потеряли данные, некоторые так и не восстановились полностью.

Восстанавливаться приходится чаще: только 15% компаний ни разу не поднимались из бэкапа. Основные причины банальные – ошибки сотрудников и сбои оборудования. Атаки шифровальщиков только на третьем месте, но у них своя специфика: злоумышленники уже поняли, что бить надо по резервным копиям, поэтому большинство атак направлено именно на их шифрование или уничтожение. Защищённые от изменений хранилища при этом используют 32% компаний.

Чем дольше простой, тем хуже прогноз. 93% компаний, которые теряют данные больше чем на 10 дней, в течение года подают на банкротство.

Бэкап и DR решают разные задачи

Термины часто смешивают, поэтому договоримся о понятиях.

Бэкап отвечает на вопрос «есть ли у нас копия данных» – это процесс создания копий продуктивных данных на отдельном носителе: если рабочие данные повреждены или уничтожены, из копии можно восстановиться. Копии обычно держат на локальной площадке для оперативного восстановления и дополнительно выносят на удалённую, чтобы пережить сбой площадки целиком.

DR, он же disaster recovery, отвечает «как быстро поднимутся наши системы, если площадка выйдет из строя» – данные постоянно реплицируются на резервную площадку, и там по сути живёт копия критически важных информационных систем. Если основная площадка надолго отключилась или утрачена совсем, нагрузка переезжает на резервную.

Оба процесса оперируют двумя метриками:

• RPO – сколько данных бизнес готов потерять без критичных последствий.
• RTO – за какое время системы должны вернуться в нормальный режим.

Общее правило простое: чем меньше эти показатели, тем дороже их обеспечивать, причём дорожают и технические средства, и организация процессов.

DR окупается, когда RTO измеряется десятками минут, а терять данные больше чем за одну-две минуты нельзя. Бэкапов достаточно, когда защищать нужно сами данные, а не работающие системы: вернуться на несколько точек назад, пережить шифровальщика, восстановить всё в консистентном состоянии. На практике подходы комбинируют: mission critical системы закрывают через DR, остальное восстанавливают из бэкапов помедленнее.

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

Пять мест, где ломается восстановление

Если вы думаете, что раз бэкап есть, с восстановлением всё хорошо, то на деле бэкап подтверждает только наличие копии. А восстановление – это цепочка, где кроме копии есть порядок запуска, зависимости между компонентами, авторизации, интеграции и люди, которым нужно время. Проверять надо всю цепочку, и вот пять проверок, которые помогают найти разрыв заранее.

1. Переживут ли копии тот же инцидент. Мы уже касались этого на уровне одного сервера, но правило масштабируется. Если все копии лежат в одном ДЦ, в одном облаке или под одним контуром администрирования, полноценной устойчивости нет. Важно оценить независимость резервной площадки и убедиться, что там будут связь и ресурсы для восстановления.
2. Сверены ли RTO и RPO с реальностью. Часто эти показатели живут в документах как красивые цели, которые никто не измерял на практике. Если в DRP записан час, а фактическое восстановление занимает восемь, об этом надо узнать до аварии. Полезно ещё разделять системы по классам критичности, потому что восстанавливать всё одинаково быстро затратно и не всегда обоснованно.
3. Описан ли порядок восстановления. Поднять виртуальные машины и поднять работающий сервис не одно и то же. Сервису нужна база данных, рабочая сеть, доступы, внешние интеграции. Если в момент аварии команда выясняет порядок запуска в телеграм-чате, DR-план фактически не работает. Для этого существует runbook: документ с последовательностью действий, ролями и критериями, по которым конкретный человек подтверждает, что сервис восстановлен.
4. Продуман ли failover. Заранее нужны ответы на вопросы: кто принимает решение о переключении, хватит ли ресурсов на резервной площадке, чтобы принять нагрузку, готова ли сетевая часть с балансировщиками. И отдельный пункт, про который вспоминают не все, – план возврата.
5. Регулярный dry run. DR-план устаревает по умолчанию: появилась новая система, поменялись маршруты, прошла миграция, сменился провайдер, выкатили релиз с новыми зависимостями. Тестовый прогон нужен, чтобы находить расхождения между документом и реальной инфраструктурой. Причём сам по себе прогон ничего не решает: по его итогам в план вносят изменения и сразу назначают дату следующей проверки.

Почему DR не спасает от шифровальщика

У DR есть слабое место, о котором стоит помнить отдельно. Репликация не разбирает, что она переносит: она добросовестно доставляет на резервную площадку и здоровые данные, и зашифрованные.

Сценарий выглядит так. Шифровальщик отработал на основной площадке, данные повреждены. Команда решает, что площадка потеряна, и запускает аварийное восстановление. Виртуальные машины на резервной стороне поднимаются в нужном порядке, всё по плану. А потом выясняется, что данные там те же самые: реплика успела уехать уже после шифрования. Формально DR сработал, бизнесу это не помогло.

Точки восстановления у DR-решений есть, но их заметно меньше, чем у бэкапов. Откатиться далеко в прошлое и получить консистентное состояние исторических данных – задача именно резервного копирования. Поэтому от шифровальщиков DR защищает так себе: может повезти с точкой, а может и нет. Всё упирается в то, от каких рисков вы страхуетесь.

Как строить хранение копий

Базовая схема известна давно и называется правилом 3-2-1: держать данные минимум в трёх экземплярах – продуктивные плюс две резервные копии. Носители должны быть двух разных типов, чтобы не словить на обеих копиях один и тот же баг прошивки или заводской брак. И хотя бы одна копия должна лежать на удалённой площадке, на случай если с основной что-то случится целиком.

У правила есть развитие: 3-2-1-1-0. Дополнительная единица означает, что минимум одна копия хранится в неизменяемом виде, а ноль – что восстановление регулярно тестируется. Второе спасает от бэкапа Шрёдингера: копия вроде есть, но из неё ни разу не пробовали восстановиться, поэтому неизвестно, есть ли там вообще пригодные данные. Тестировать можно руками, встроенными средствами системы резервного копирования или отдельными скриптами.

Неизменяемое хранилище устроено одним из двух способов.

1. Первый – отчуждаемые носители: записали на ленту или внешний диск, вытащили, убрали в несгораемый шкаф. Защита получается надёжная, но скорость записи и восстановления низкая, а трудозатраты мешают главному – регулярному тестированию.
2. Второй способ – ограничение на уровне прав доступа: данные можно записать один раз и читать сколько угодно, а перезаписать нельзя. Так работает, например, функция Object Lock в S3-совместимых объектных хранилищах: она защищает объекты от случайного и преднамеренного изменения или удаления. Важно понимать границы: объектное хранилище – не система резервного копирования, а удалённый репозиторий, куда система складывает копии.

Отдельный выбор – как система резервного копирования будет добираться до данных. Агентская схема ставит небольшую программу на каждый сервер и рабочую станцию: агент сидит рядом с данными и даёт гибко управлять копированием и восстановлением, но нагружает CPU и память машины, а парком агентов надо управлять. Безагентская схема работает на уровне гипервизора или отдельным сервером: разворачивается быстро, покрывает много сервисов разом, вся нагрузка остаётся на внешнем сервере. Для маленькой инсталляции обычно удобнее агенты, для большой – безагентский вариант.

Удалённой площадкой для копий может быть облако – это способ закрыть вопрос без закупки железа и строительства собственной резервной площадки, к тому же облачные провайдеры обычно строят сервисы с оглядкой на требования регуляторов. Один нюанс: восстановление из облака идёт по сети, и на небольших каналах это долго. Поэтому оперативные копии лучше держать поближе к продуктиву, а облачный репозиторий использовать как резерв резерва.

Собрать такую схему можно на инфраструктуре Linx: у компании есть объектное хранилище с Object Lock, где данные можно защитить так, что их не изменит даже администратор облака, сервис резервного копирования с локальными и удалёнными репозиториями и услуга аварийного восстановления для инфраструктур на VMware. Если у вас Hyper-V, bare metal или другая платформа виртуализации, тот же сценарий закрывается связкой с платформой Hystex, которая переносит нагрузки между разными платформами. Подробности – на linx.ru.

Итого

Готовность к аварии проверяется не наличием бэкапа, а измеренным восстановлением. Отсюда план действий:

• Сначала аудит: посчитать, во сколько обходится час простоя и потеря данных, и разбить системы на классы критичности.
• Затем вместе с бизнесом зафиксировать целевые RPO и RTO для каждого класса, спроектировать под них архитектуру и провести тестовое восстановление.
• Полученные цифры сверить с целевыми: если в план заложен час, а по факту выходит восемь, либо меняйте архитектуру, либо честно пересматривайте цели вместе с бюджетом.
• Дальше цикл: обновили план, назначили дату следующего теста.

Пара вещей, которые стоит сделать независимо от масштаба: минимум одну копию держите в неизменяемом хранилище. И зовите на тестовые восстановления бизнес-пользователей: серверы могут подняться идеально, но подтвердить, что система реально работает и её производительность в норме, могут только те, кто в ней работает каждый день.

Непроверенный бэкап – не страховка, а гипотеза о страховке. Разница между ними выясняется в худший момент из возможных, и стоит она, если верить статистике, до 93% вероятности банкротства при затяжной потере данных. Тестовое восстановление обходится дешевле.

WP2Shell — цепочка CVE-2026-63030 и CVE-2026-60137 в ядре WordPress.

Под угрозой полного удалённого выполнения кода: WordPress 6.9.0–6.9.4 и 7.0.0–7.0.1.

Атака работает без авторизации на стоковой установке без плагинов и тем.

WordPress.org применил редкую меру — принудительные автообновления для уязвимых версий.

Решение: обновиться до 6.9.5, 7.0.2 или 6.8.6 и проверить журналы доступа.

Что такое WP2Shell

WP2Shell — это комбинация двух багов в ядре WordPress, а не в стороннем плагине или теме. CVE-2026-63030 связана с путаницей маршрутов в пакетном endpoint REST API /wp-json/batch/v1. CVE-2026-60137 — SQL-инъекция в параметре author__not_in компонента WP_Query. По отдельности они серьёзны, вместе дают удалённое выполнение кода от анонимного пользователя.

Какие версии под угрозой

Полная цепочка RCE работает на WordPress 6.9.0–6.9.4 и 7.0.0–7.0.1. SQL-инъекция CVE-2026-60137 также присутствует в ветке 6.8.0–6.8.5, но там она не превращается в удалённый шелл, поскольку REST API batch endpoint появился только в 6.9. Исправления — версии 6.9.5, 7.0.2 и 6.8.6.

Масштаб угрозы

По официальной статистике WordPress, уязвимые версии установлены на более чем 400 миллионах сайтов. Исследователь Дэниэл Кард проанализировал выборку около 3500 площадок и оценил долю уязвимых экземпляров менее чем в 15%. Даже при такой оценке речь идёт о десятках миллионах потенциальных жертв.

Что делать

1. Проверить версию WordPress в админ-панели или через WP-CLI.
2. Обновиться до 6.9.5, 7.0.2 или 6.8.6 в зависимости от текущей ветки.
3. Убедиться, что принудительное автообновление действительно применилось.
4. Проверить журналы доступа на обращения к /wp-json/batch/v1.
5. Если обновление невозможно срочно — временно заблокировать endpoint /wp-json/batch/v1 на WAF.

Выводы

Атака не требует предварительных условий и может быть использована анонимным пользователем на стоковой установке WordPress без плагинов.

WP2Shell — редкий случай, когда уязвимость затрагивает ядро CMS, а не стороннее расширение. WordPress.org пошёл на нехарактерный шаг — принудительную доставку патчей, — что говорит о серьёзности угрозы. Если вы администратор сайта на WordPress, обновление до актуальных версий — приоритетная задача.

Источник: Slashdot (цитирует TechCrunch).

По данным Gamers Nexus, при подключении некоторых мониторов LG Windows Update сначала устанавливает пакеты расширений и компонентов производителя, а затем — приложение LG Monitor App Installer. В журнале надёжности Windows оно появляется примерно через минуту, без запроса на скачивание и без диалога согласия.

LG Monitor App Installer попадает на ПК через Windows Update.

После загрузки установщик показывает предложение McAfee: 30-дневная пробная версия, которая потом становится платной подпиской.

Проблема воспроизведена на LG UltraGear 34GX900A-B, но встречается и на старых моделях, например LG UltraFine 32UN880-B.

Похожий механизм используют Dell и Alienware.

Заблокировать автозагрузку можно групповой политикой Prevent automatic download... или отключением Microsoft Store.

Как это работает

Gamers Nexus проверил работу установщика на 32 загрузках системы. В 31 случае на экране появлялось окно с предложением McAfee, в одном — реклама собственной утилиты LG. Поп-ап предлагает 30-дневную пробную версию антивируса, после которой начинается платная подписка.

Microsoft Store описывает приложение как имеющее доступ к интернету и ко всем системным ресурсам. Пользовательские жалобы на LG Monitor App Installer встречаются ещё с 2024 года, но в последние недели число сообщений резко выросло.

Мы зафиксировали рекламу McAfee в 31 из 32 загрузок системы после установки приложения.

Это только LG?

Нет. Dell использует тот же механизм Windows Update, чтобы доставлять Alienware Command Center при подключении совместимого монитора или периферии. PC Gamer также отмечал аналогичные жалобы на Alienware.

Как отключить

Параметр, который нужно включить, называется так:

• Откройте редактор групповых политик: gpedit.msc.
• Перейдите в Computer Configuration → Administrative Templates → System → Device Installation.
• Включите параметр, указанный в код-блоке выше.
• Перезагрузите компьютер, чтобы изменения вступили в силу.

Альтернатива — отключить Microsoft Store, но тогда перестанут обновляться и другие приложения из магазина.

Источники

• LG monitors silently install software through Windows Update without user consent — VideoCardz
• It looks like monitor manufacturers can download bloatware without consent — PC Gamer

В этой статье разбираем, как работают usage tiers, мягкие и жёсткие лимиты расходов, алерты и rate limits. И главное — что нужно учесть в коде, чтобы приложение корректно обработало отказ API.

OpenAI API делит аккаунты на usage tiers: чем больше суммарно оплачено, тем выше месячный потолок расходов.

В настройках Limits можно задать собственный лимит трат, включить жёсткое ограничение и настроить email-алерты.

Жёсткий лимит отключает API при превышении бюджета: запросы начинают возвращать ошибку 429.

Rate limits ограничивают RPM, RPD, TPM и TPD по моделям; при превышении помогает экспоненциальный бэкофф.

В коде важно перехватывать 429, повторять запросы с задержкой и логировать расход токенов.

Как устроены usage tiers

Usage tiers — это автоматические уровни аккаунта, которые OpenAI выдаёт в зависимости от суммы уже оплаченных API-вызовов. Чем выше tier, тем больше месячный потолок трат и выше rate limits. Для новичка это двойная защита: даже если вы ничего не настраивали, система не даст потратить больше, чем разрешено текущему уровню.

Таблица tiers по состоянию на июль 2026

Данные взяты из документации OpenAI.

• Free — доступен из разрешённых регионов, лимит $100 / месяц.
• Tier 1 — нужно оплатить от $5, лимит $100 / месяц.
• Tier 2 — оплачено от $50, лимит $500 / месяц.
• Tier 3 — оплачено от $100, лимит $1 000 / месяц.
• Tier 4 — оплачено от $250, лимит $5 000 / месяц.
• Tier 5 — оплачено от $1 000, лимит $200 000 / месяц.

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

Лимит расходов: мягкий, жёсткий и алерты

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

• Spend limit — мягкий потолок. OpenAI показывает предупреждение, но фактические траты могут его немного превысить.
• Enforce hard limit — жёсткий потолок. При достижении лимита API начинает возвращать ошибку 429 и больше не списывает деньги.
• Spend alerts — email-уведомление при достижении заданного процента от бюджета.
• Auto recharge — автоматическое пополнение баланса с привязанной карты. При риске перерасхода его стоит отключить.

Рекомендация простая: для продакшена включайте Enforce hard limit и настраивайте алерты на 50% и 80%. Так у вас будет время разобраться, пока API ещё работает.

Rate limits: почему API отвечает 429

Rate limits — это не про деньги, а про нагрузку. OpenAI ограничивает количество запросов в минуту/день и токенов в минуту/день для каждой модели. Лимиты зависят от tier и модели: например, для gpt-4o и gpt-4o-mini они различаются.

• RPM — requests per minute, запросы в минуту.
• RPD — requests per day, запросы в день.
• TPM — tokens per minute, токены в минуту.
• TPD — tokens per day, токены в день.
• IPM — images per minute, изображения в минуту (для моделей генерации картинок).

При превышении любого из лимитов API возвращает 429 Too Many Requests. OpenAI рекомендует обрабатывать эту ошибку через экспоненциальный бэкофф: повторять запрос с увеличивающейся паузой.

Что делать в коде

1. Перехватывайте 429 и различайте причину: rate limit, hard spend limit или квота по токенам.
2. Используйте экспоненциальный бэкофф с джиттером, чтобы не «дудосить» API своими ретраями.
3. Логируйте количество токенов и стоимость каждого вызова — лучше всего через поля usage в ответе.
4. Для агентов добавьте circuit breaker: если бюджет исчерпан или ошибки 429 идут подряд, остановите цикл и уведомите команду.
5. Не храните API-ключ в клиентском коде: утечка ключа — самый быстрый способ получить чужой счёт.

Пошаговая настройка

Выводы

OpenAI API даёт в руки разработчика все нужные рычаги: usage tiers, spend limits, spend alerts, rate limits и жёсткое ограничение. Проблема не в отсутствии инструментов, а в том, что ими редко пользуются до первого «сюрприза» в биллинге.

Минимальный must have для любого проекта: включить Enforce Hard Limit, настроить алерты на 50% и 80%, отключить автопополнение, если бюджет критичен, и добавить в код обработку 429. Так вы защитите не только карту, но и репутацию команды.

Set up spend limits so rogue AIs don't exceed your budget. Rate limits are very easy to configure, making them a no-brainer for protecting your account.

Источники:
ZDNET — How I set OpenAI API usage limits to stop agent overspending
OpenAI Docs — Rate limits

PamStealer — это инфостилер (вредонос, крадущий данные), написанный на языке Rust. Он ориентирован на компьютеры Apple с процессорами Apple Silicon и собирает пароли, данные браузеров и, по данным исследователей, обращается к аккаунтам Ethereum.

Главная особенность новой угрозы — способ проверки пароля. Вместо запуска вспомогательных утилит вроде dscl или security вредонос использует встроенный в macOS интерфейс PAM (Pluggable Authentication Modules). Это делает проверку тише и оставляет меньше следов для защитных решений.

PamStealer — новый macOS-инфостилер, замаскированный под менеджер буфера обмена Maccy.

Первая стадия доставляется как AppleScript внутри образа диска DMG; запуск через Command-R обходит карантин macOS.

Вторая стадия написана на Rust, маскируется под Finder, шифрует связь с сервером управления и откладывает запрос полного доступа к диску до 40 минут.

Пароль жертвы проверяется локально через системный интерфейс PAM, без запуска дополнительных процессов.

Угроза нацелена на компьютеры Apple с процессорами Apple Silicon.

Как распространяется

Злоумышленники распространяют PamStealer в образе диска DMG, который выглядит как установщик Maccy. Внутри находится файл AppleScript (.scpt). При двойном клике macOS открывает его в Script Editor, а жертве предлагается нажать Command-R — якобы для запуска установки. Эта команда выполняет вредоносный код и снимает атрибут карантина com.apple.quarantine, который обычно предупреждает о запуске файлов из интернета.

Для загрузки второй стадии AppleScript содержит самодостаточный JXA (JavaScript for Automation) загрузчик. Он использует нативные Objective-C API вместо привычных shell-команд вроде curl или zsh, что ещё больше снижает заметность для защитных решений.

Что делает вторая стадия

Вторая стадия — компактный бинарник Mach-O для Apple Silicon. Он размещается внутри поддельного приложения, которое выдаёт себя за системный Finder: исследователи видели идентификаторы com.apple.finder.core и com.apple.finder.monitor. Поддельное приложение использует настоящую иконку Finder. Бинарник написан на Rust — для macOS-инфостилеров это относительно редкий выбор: чаще встречаются Swift, Go или Objective-C.

После запуска PamStealer показывает поддельный системный запрос пароля с текстом «Maccy wants to make changes. Enter your password to allow this». Если пароль неверный, запрос появляется снова. После успешной проверки вредонос выводит сообщение о повреждённом файле, чтобы жертва не заподозрила неладное.

Чтобы собрать больше данных, PamStealer запрашивает полный доступ к диску, но делает это с задержкой до 40 минут после запуска. Так временной разрыв между инфицированием и подозрительным действием затрудняет анализ инцидента.

Кто под угрозой

Угроза актуальна для пользователей macOS на чипах Apple Silicon, которые скачивают приложения со сторонних сайтов. Подлинный Maccy распространяется через официальный сайт и менеджер пакетов Homebrew; заражённый образ выдаёт себя за него, но получен из неизвестного источника.

Как защититься

• Скачивайте приложения только с официальных сайтов или из Mac App Store.
• Не вводите пароль администратора в запросах от незнакомых приложений.
• Проверяйте кодовую подпись и нотаризацию перед установкой (Системные настройки → Конфиденциальность и безопасность).
• Используйте Endpoint Detection and Response (EDR) для macOS.
• Регулярно обновляйте macOS и приложения.

Выводы

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

PamStealer демонстрирует, что macOS-угрозы продолжают эволюционировать: они всё чаще используют нативные API, уходят от shell-команд и затягивают временные интервалы между этапами атаки. Для пользователей главная защита — привычка устанавливать ПО только из проверенных источников и внимательность к системным запросам пароля.

Подробнее — в материале Ars Technica.

Проверьте, откуда скачаны ваши приложения для macOS.

• ИИ-агент JadePuffer использовал CVE-2025-3248 в Langflow для первичного доступа.
• Агент адаптировался в реальном времени: после неудачного входа нашёл рабочее решение за 31 секунду.
• Зашифрованы 1342 конфигурации Nacos; платить выкуп бесполезно, так как схемы базы данных уничтожены.
• Защита: убрать Langflow и Nacos из интернета, сменить стандартные ключи и не хранить API-ключи на оркестраторах ИИ.

Как развивалась атака

Sysdig назвала угрозу JadePuffer. Агент начал с открытого в интернете экземпляра Langflow — фреймворка для построения конвейеров ИИ, и воспользовался уязвимостью CVE-2025-3248, которая позволяет удалённо выполнить произвольный Python-код без аутентификации.

Попав внутрь, агент собирал секреты: ключи провайдеров ИИ, облачные учётные данные, кошельки криптовалют и пароли к базам данных. Особое внимание он уделял китайским облакам — Alibaba, Aliyun, Tencent и Huawei, — но не обходил стороной AWS, Azure и Google Cloud. Для закрепления агент добавил задачу в crontab, которая каждые 30 минут связывалась с инфраструктурой злоумышленников.

Конечной целью стал отдельный продакшен-сервер с MySQL и сервисом конфигураций Nacos от Alibaba. Агент подключился к MySQL под root, использовал обход авторизации CVE-2021-29441 и подделал JWT с помощью стандартного ключа Nacos. В итоге он зашифровал все 1342 конфигурации встроенной функцией AES и оставил записку с требованием выкупа, биткоин-адресом и почтой Proton Mail.

Почему платить не имеет смысла

Классический ransomware обычно хранит ключи или резервные копии, чтобы расшифровать данные после оплаты. JadePuffer действовал иначе: он уничтожал целые схемы базы данных, не сохраняя возможности восстановления. По словам директора по исследованию угроз Sysdig Майкла Кларка, агент «переходил от удаления строк к сбросу целых схем БД, проговаривая собственную логику выбора целей».

Как защититься

1. Закройте от интернета конечные точки Langflow и Nacos — они не должны быть публично доступны.
2. Обновите Langflow до версии без CVE-2025-3248.
3. Смените стандартный token.secret.key в Nacos и используйте принудительную настройку собственного ключа.
4. Не храните API-ключи провайдеров ИИ и облачные учётные данные в окружении оркестраторов ИИ.

Атака JadePuffer показывает, что порог входа для ransomware опустился до стоимости запуска ИИ-агента. Если агент работает на украденных учётных данных через LLMjacking, затраты злоумышленника близки к нулю. Источник: The Register.

С практической точки зрения проект на**й не нужен. Есть GitHub, GitLab и куча нормальных инструментов. Но как эксперимент — почему бы и нет? Чисто посмотреть, можно ли заставить Telegram работать как VCS.

Почему не JSON

На старте я думал: «Положу всё в JSON, на кой мне база данных?» Проектов мало, пользователей немного, файлы текстовые — чего заморачиваться?

Подергал JSON туда-сюда пару дней и понял: не варик.

1. Конкурентный доступ. Два юзера одновременно коммитят — один перезаписывает файл другого.
2. Целостность данных. Если бот упал в середине записи — JSON остаётся в невалидном состоянии.
3. Версионность. Хранить историю изменений в JSON — это просто перенести проблему из кода в структуру файла.

Вывод: JSON — для конфигов, а не для данных, которые меняются каждую секунду.

Выбор SQLite и схема БД

Выбрал SQLite, потому что:

• Не надо поднимать отдельный сервер
• Целостность данных на уровне движка (транзакции, foreign keys, rollback)
• Всё в одном файле — скопировал и унёс

Сущности:

• users — telegram_id, username, current_project_id
• projects — owner_id, name, thread_id (каждый проект живёт в своём треде канала)
• files — filename, current_version, флаг modified (файл изменился и готов к коммиту)
• file_versions — мясо. Каждая версия файла с полным содержимым. Привязана к file_id и опционально к commit_id
• commits — сообщение, время, ссылка на проект
• commit_files — связка коммитов с версиями файлов (many-to-many, чтобы поддержать ветки)

Почему так: я хотел иметь возможность откатиться к любой версии любого файла. Да, база распухнет, но текстовые файлы — это не гигабайты видео. Плюс наличие file_versions и commit_files позволяет делать diff между версиями и смотреть историю изменений.

В коде вместо голых кортежей из SQL — датаклассы:

Маркдауновый ад

Казалось бы: взял код, обернул в тройные апострофы, кинул в Telegram. Telegram сам подсветит синтаксис, если указать язык. Красота. В теории.

На практике Telegram использует свой диалект Markdown, где куча служебных символов: _ * [ ] ( ) ~ > # + - = | { } . !

Попытка 1: заэкранировать всё подряд. Результат: код превращается в кашу. Вместо def __init__- получается def |_|_init|_|_ — уже не запустишь, и в канале выглядит как говно.

Попытка 2: не экранировать вообще. Telegram шлёт на**й с ошибкой «can't parse entities».

Попытка 3: экранировать только то, что реально ломает разметку. Выяснилось, что порядок важен. Сначала экранируем точки и подчеркивания, потом обратную косую черту. Но и это не панацея — последовательности типа \*

после экранирования превращаются в \\*, и Telegram снова недоволен.

Попытка 4: разбивать на части. Для больших файлов делаю превью (первые 50 строк), экранирую их, отправляю как код, а полную версию — файлом. И тут начался ад: Telegram находил ошибки в тех частях кода, которых в превью вообще не было. Оказывается, он всё равно парсил полный код, даже если отправлялась только его часть.

Попытка 5 (финал): забил на Markdown и перешёл на HTML. Telegram умеет его принимать. Да, он не такой красивый, но зато предсказуемый:

Никаких точек, подчеркиваний, обратных слешей. Просто экранируем три символа — и код летит как надо.

Security by design

Когда бот начал обрастать функциями, я задумался о безопасности. Чтобы никто не мог коммитить или удалять чужие файлы, начал писать проверки в каждую команду:

Добавил в /commit. Потом решил с другого аккаунта потестировать команды на чужих файлах. И тут бот на каждую команду стал выдавать «файл не найден» или «проект не найден». И я понял: безопасность уже работает. С самого начала. Из коробки. Без единой строчки кода.

Как так вышло? В таблице projects с самого начала было поле owner_id. При создании проекта я писал туда telegram_id владельца. Все запросы к БД фильтруются по этому полю:

Показать проекты — только свои. Найти файл — только в своих проектах. Выбрать проект — только из своих. Никаких лишних проверок. Просто SQL-запросы, которые с самого начала учитывали владельца.

Команды: от семи до двух десятков

Изначально казалось, что команд будет немного. Но...

Жизнь рассудила иначе.

• База: /start, /init, /use, /list, /ls, /commit, /log, /status
• Удаление: /rm, /rmproject + подтверждение
• Игнор: /ignore, /ignored, /unignore
• Ветки: /branch, /branches, /checkout
• Диффы и просмотр: /diff, /cat

Итого — уже под два десятка. И это не предел.

Простота > абстракции

В моём коде нет абстрактных базовых классов. Совсем. Потому что они нужны только когда у тебя есть минимум две разные реализации одного и того же. В GitGram всё проще: один способ работать с БД, один способ шифровать, один способ парсить .gitignore.

Если завтра появится вторая реализация — тогда и буду делать интерфейс. А пока это просто оверхед.

В GitGram:

• Хочешь понять, как работает add_file — идёшь в database.py и читаешь 10 строк кода.
• Хочешь увидеть обработчик /commit — открываешь bot.py и смотришь.

Никаких AbstractMinerShieldEventProcessor, BaseGitGramManager, InterfaceProviderFactory.

Код должен быть тупым. Чем тупее — тем проще его читать и отлаживать.

Что дальше

В планах:

• Докрутить коллаборацию (несколько человек над одним проектом)
• Приватные репозитории
• Кодспейс прямо в боте (да да знаю я сошёл с ума и бла бла бла..)

Итог

GitGram принимает файлы, режет их на куски если надо, постит в канал с подсветкой. Коммиты ходят, ветки переключаются, диффы показываются. Всё это в тредах, каждый проект отдельно.

На практике GitGram ни к чему. Но сама задумка — Git в Telegram — это же так прикольно. Просто посмотреть, можно ли такое вообще запилить.

Если хочешь поучаствовать

• GitGram
• Чат для хардкорных: @sandbox_hardcore — вся сырая разработка, факапы и обсуждения (без цензуры)

Подписывайся на мой TГ-канал — там я публикую все свои эксперименты, код и приглашаю к обсуждению. Только факты, мат и никакой политоты.

• Виртуальный хостинг — сайты соседствуют на одном сервере, управляет провайдер. Дешёвый старт, но ограниченная конфигурация.
• VPS и VDS — почти всегда синонимы: изолированные виртуальные серверы с root-доступом и гарантированными ресурсами.
• Выделенный сервер — отдельное железо, максимум контроля и цены, требует администрирования.
• В подборке: Интернет Хостинг Центр, UFO.Hosting, SpaceWeb, PSB Hosting, AdminVPS и FirstVDS.

Как мы выбирали участников

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

1. Интернет Хостинг Центр — гибкие конфигурации

Российский провайдер, у которого VPS и VDS — это одна услуга. Можно выбрать виртуализацию под задачу (KVM или Virtuozzo), собрать конфигурацию от минимальной до высоконагруженной и расти внутри одной платформы до выделенного сервера.

Кейсы клиентов и кому подойдёт

• Небольшой сайт компании на WordPress с 300–500 посетителей в сутки спокойно живёт на виртуальном хостинге; при росте трафика переходят на VPS.
• Интернет-магазин на 1С-Битрикс с 500–1000 пользователями в день переносят на VPS/VDS, когда подключают CRM и платёжные системы.
• Разработчик с несколькими проектами берёт VPS/VDS под API, базу данных и тестовые окружения — виртуальный хостинг здесь слишком ограничен.

Что можно развернуть

На виртуальном хостинге — сайты на PHP 5.2–8.2 с MySQL, панели IHC, cPanel или ISPmanager. На VPS/VDS — любые Linux-дистрибутивы, Windows, WireGuard, MikroTik Router, панели ispmanager/FastPanel, VPN-шаблоны, CMS вроде 1С-Битрикс.

Инфраструктура и экосистема

Дата-центры Tier III в Москве (DataPRO и IXcellerate Moscow One) и в Амстердаме. Виртуализация — KVM или Virtuozzo. Защита от DDoS входит во все тарифы, IPv6-сети /64 доступны за доплату. Есть партнёрская программа с выплатами до 50% от привлечённых оплат.

Отзывы и репутация

На сайте публикуются отзывы с внешних площадок: средняя оценка 4,8 по 20 оценкам. Клиенты отмечают стабильную работу и скорость техподдержки.

Поддержка и каналы связи

Тикеты через личный кабинет, онлайн-чат на сайте, Telegram @IHC_Support_Bot, телефоны в Москве, Санкт-Петербурге и бесплатный номер для регионов. Первый ответ обычно приходит за 10–30 минут в рабочее время. Для корпоративных клиентов доступно сопровождение через отдел продаж и аккаунт-менеджеров.

Тарифы, ограничения и условия

• Виртуальный хостинг: тариф IHC-2 — от 123 ₽/мес при оплате за год или 147 ₽/мес помесячно; 2 сайта, 2 ГБ SSD, 150 МБ под БД, домен .RU в подарок при оплате за 2 года.
• VPS/VDS: минимальная конфигурация ssdVPS:1 — 1 ГБ RAM, 20 ГБ SSD, 1 CPU, безлимитный трафик со снижением скорости после 20 ТБ — от 317 ₽/мес за год или 380 ₽/мес помесячно.
• Типовая конфигурация для небольшого проекта — 2 ГБ RAM, 1–2 CPU, 30–45 ГБ NVMe — от 609 ₽/мес за год или 700 ₽/мес помесячно.
• Тестовый период: 7 дней на виртуальном хостинге, 3 дня на VPS/VDS; для активации нужно пополнить баланс на 100 ₽, которые можно вернуть или потратить.
• Бэкапы: место под резервные копии — от 52,5 ₽/мес за 5 ГБ; снапшоты зависят от платформы.
• Работа по 152-ФЗ, есть реестр хостинг-провайдеров; закрывающие документы для юрлиц доступны.

Официальный сайт: ihc.ru

2. UFO.Hosting — космическая экосистема

Провайдер, который объединяет VPS/VDS, выделенные серверы, защиту сайтов, DNS-хостинг, аренду IP, лицензии ISPmanager и домены в одном личном кабинете. Для UFO.Hosting VPS и VDS — два названия одной услуги; разница только в терминологии.

Кейсы клиентов и кому подойдёт

• Интернет-магазин с трафиком 10–50 тыс. посетителей в день — VPS даёт стабильность при пиковых нагрузках и возможность настроить SSL, СУБД и кэширование.
• Веб-студии и агентства выбирают VPS/VDS ради изоляции ресурсов: проблемы одного клиента не влияют на соседние проекты.
• CRM-системы, лендинги с формами заявок и приложения с умеренной нагрузкой — удобно масштабировать RAM и CPU без переплаты за железо.
• Выделенные серверы берут под крупный e-commerce с интенсивным чтением/записью, проекты с жёсткими требованиями к безопасности и задачи с огромными объёмами дисков.

Что можно развернуть

VPS/VDS на Linux и Windows, панели Vesta, Hestia, CyberPanel, Virtualmin, ISPmanager. Можно поднять веб-серверы, базы данных, VPN, контейнеры, игровые серверы, DNS-зоны, а рядом заказать защиту сайта от DDoS L7 и внешнее FTP-хранилище.

Инфраструктура и экосистема

Серверы стоят в дата-центре IXcellerate в Москве, соответствующем Tier III. Сеть ноды VPS/VDS — 10 Гбит/с, распределяется между серверами по тарифу. Доступны обычные конфигурации на Intel Xeon, Hi-CPU на Ryzen и Storage-линейка с расширенным хранилищем.

Отзывы и репутация

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

Поддержка и каналы связи

Техподдержка 24/7 через онлайн-чат на сайте и тикет-систему в биллинге. Телефонная поддержка работает в будни с 9:00 до 18:00; Telegram не используется. Фактическое время ответа — не более 30 минут в любое время суток. Есть база знаний и блог.

Тарифы, ограничения и условия

• Минимальная конфигурация VPS/VDS Naos (Intel Xeon E5-2697A v4) — 1 vCore, 1 ГБ RAM, 25 ГБ NVMe — 605,85 ₽/мес.
• Типовая конфигурация Brachium (Intel Xeon E5-2697A v4) — 2 vCore, 4 ГБ RAM, 60 ГБ NVMe — 1025,85 ₽/мес.
• Скидки за предоплату: 3 месяца — 5%, 6 месяцев — 10%, 12 месяцев — 15%.
• Тестовый период — до 3 дней на любой тариф VPS; требуется верификация аккаунта (email, телефон, KYC). На выделенные серверы — до 3 дней по договорённости.
• Трафик безлимитный с порогом 32 ТБ/мес; после превышения скорость ограничивается 100 Мбит/с.
• Root-доступ полный. На тарифах Naos и Haedus выбор ОС ограничен списком провайдера; на остальных можно ставить любую ОС.
• Бэкапы платные: ежедневные — 525 ₽/мес, еженедельные — 262,5 ₽/мес; снапшотов нет, есть услуга бэкапов.
• Работа по 152-ФЗ, сертификатов ФСТЭК нет; есть реестр хостинг-провайдеров. Для юрлиц — договор и ЭДО, постоплата недоступна.

Официальный сайт: ufo.hosting

3. SpaceWeb — посуточная тарификация

Один из старейших российских хостеров, у которого можно начать с виртуального хостинга, перейти на VPS/VDS с посуточной оплатой и докупать IP, SSL и защиту от DDoS. Удобен тем, кто хочет платить только за фактическое потребление ресурсов VPS.

Кейсы клиентов и кому подойдёт

• Лендинг, блог или сайт-визитка с небольшой посещаемостью — хватит виртуального хостинга с автоустановкой CMS.
• Интернет-магазин и корпоративный сайт на 1С-Битрикс — тарифы повышенной мощности с выделенными CPU и приоритетной поддержкой.
• Проект с непредсказуемой нагрузкой — VPS/VDS с посуточной тарификацией и изменением ресурсов «на лету».

Что можно развернуть

На хостинге — WordPress, Joomla, Drupal, 1С-Битрикс, OpenCart, MODx, Laravel, Django и другие CMS и фреймворки. Поддерживаются PHP 5.x–8.4, MySQL 8/5.7, PostgreSQL 14.4, Perl, Python, Ruby. На VPS/VDS — Ubuntu, Debian, CentOS, AlmaLinux, Rocky Linux, панели Hestia, FASTPANEL, ISPmanager, Docker.

Инфраструктура и экосистема

Дата-центры Tier III в Санкт-Петербурге, Москве и Амстердаме. Собственная SPA-панель управления, VNC-консоль, DNS-редактор, статистика, логи, бэкапы и снапшоты. На всех сайтах включена изоляция для защиты от вредоносного ПО и защита от DDoS L3-4; защиту L7 можно докупить от 290 ₽/мес.

Отзывы и репутация

На сайте публикуются отзывы клиентов: отмечают стабильную работу, быструю техподдержку и удобную панель. Некоторые пользователи работают с провайдером с 2016 года.

Поддержка и каналы связи

Email, телефон, онлайн-чат и ВКонтакте. Среднее время ответа: 1–2 минуты по телефону, в чате и ВКонтакте; до 60 минут по почте. Поддержка помогает с переносом проектов, диагностикой и администрированием серверов с ISPmanager.

Тарифы, ограничения и условия

• Виртуальный хостинг: тариф «Старт» — 1 ГБ NVMe SSD, 1 база данных, ∞ FTP и почтовых ящиков, 120 CP — 149 ₽/мес; «Взлёт» — 311 ₽/мес, «Ракета» — 530 ₽/мес, «Космос» — 755 ₽/мес.
• VPS/VDS: посуточная тарификация, параметры CPU/RAM/диска меняются «на лету»; конкретную стоимость конфигурации проверяйте в калькуляторе на сайте.
• Тестовый период: 14 дней на виртуальном хостинге и на VPS/VDS.
• Ежедневное резервное копирование включено на хостинге; резервные копии VPS — от 45 ₽/мес за 3 копии.
• Дополнительный IP — 130 ₽/мес, SSL GlobalSign — от 1 900 ₽/год, домен .RU — 179 ₽/год.
• Работа с юрлицами через договор оферты, безналичные платежи и ЭДО.

Официальный сайт: spaceweb.ru

4. PSB Hosting — зарубежные локации

Провайдер с фокусом на VPS в Европе и США: Amsterdam, Frankfurt, Helsinki, New York. Не предлагает виртуальный хостинг в привычном понимании, зато даёт полный root, /64 IPv6 на всех тарифах, неограниченные резервные копии и оплату криптовалютой.

Кейсы клиентов и кому подойдёт

• Небольшие интернет-магазины на WordPress или 1С-Битрикс, лендинги, корпоративные сайты и блоги.
• Проекты с Telegram-ботами, API-сервисами и другой автоматизацией.
• Команды, которым важны зарубежные локации и гибкие способы оплаты, включая криптовалюту.

Что можно развернуть

VPS под Linux, Windows или FreeBSD с предустановленным ПО: Bitrix, Django, Docker, FastPanel, HestiaCP, Keitaro, LAMP, Node, OpenVPN, Outline, Portainer, VestaCP, WireGuard, WordPress. Подходит под сайты, backend-приложения, VPN, корпоративные системы, базы данных и тестовые среды.

Инфраструктура и экосистема

Серверы размещены в дата-центрах euNetworks (Amsterdam), Frankfurt 1 Data Center, Digita (Helsinki) и Long Island Interconnect (New York). Оборудование — AMD и Intel с DDR5 и NVMe, RAID 10. Безлимитный трафик, порт ноды 10 Гбит/с, на VPS выделяется 300 Мбит/с. Полноценная панель управления DNS-записями доменов.

Отзывы и репутация

На сайте указаны рейтинги на независимых площадках: OtzovikMarketing.ru — 4,8, In-Scale.ru — 5,0, Aff1.ru — 5,0, 101Poisk.ru — 4,89. Провайдер позиционируется как решение для бизнеса, разработки и высоконагруженных проектов.

Поддержка и каналы связи

Поддержка работает круглосуточно через тикеты и Telegram; время ответа зависит от загрузки. Есть документация и API. Для B2B-клиентов предусмотрен менеджер.

Тарифы, ограничения и условия

• VPS: минимальный тариф на странице VPS — от 8 USD; есть High-CPU VPS на AMD Ryzen 7950X.
• Почасовая оплата доступна; скидки за предоплату: 3 месяца — 5%, 6 месяцев — 10%, 12 месяцев — 15%.
• Бесплатного тестового периода нет.
• Безлимитный трафик, порт VPS — 300 Мбит/с; можно установить любую ОС; полный root-доступ.
• Бэкапы платные, снапшоты есть.
• IPv6-подсеть /64 на всех тарифах, неограниченное количество резервных копий.
• Не работает по 152-ФЗ, сертификатов ФСТЭК нет, в реестре отечественного ПО нет. Оплата картами РФ/СНГ/ЕС и криптовалютой.

Официальный сайт: psb.hosting

5. AdminVPS — VPS и хостинг в одном кабинете

Провайдер с виртуальным хостингом, VPS/VDS, выделенными серверами, доменами, SSL и дополнительными сервисами в одном аккаунте. В подборке он закрывает сценарий, когда проекту нужен обычный хостинг для сайта и отдельный VPS под приложение, базу данных или тестовую среду.

Кейсы клиентов и кому подойдёт

• Сайты на CMS и небольшие магазины, которые начинают с виртуального хостинга и постепенно переходят на VPS.
• Команды, которым нужны домены, SSL, хостинг и серверы в одном личном кабинете.
• Проекты, где важна российская площадка и возможность подобрать конфигурацию VPS под нагрузку.

Что можно развернуть

На виртуальном хостинге — сайты на популярных CMS и почту на домене. На VPS/VDS — Linux-серверы под сайты, backend, базы данных, тестовые окружения и сервисы с root-доступом. В экосистеме также есть домены, SSL-сертификаты, резервное хранилище, объектное хранилище и защита от DDoS.

Инфраструктура и экосистема

На странице VPS в России указано размещение в Москве, процессоры Intel Xeon Gold и AMD EPYC, NVMe-диски, тарифы с портом от 100 Мбит/с до 1 Гбит/с и включённым месячным трафиком. В меню также есть VPS в Германии, Нидерландах, Польше, Испании, Беларуси, Казахстане, Финляндии, Великобритании и Франции.

Отзывы и репутация

На странице VPS указана агрегированная оценка 4,9 и несколько сотен отзывов. Провайдер позиционируется как универсальная площадка для сайтов, серверов и сопутствующих услуг.

Поддержка и каналы связи

Поддержка работает круглосуточно через тикет-систему в личном кабинете. Отдел продаж доступен по телефону и через запрос на сайте.

Тарифы, ограничения и условия

• VPS/VDS в России: конфигуратор стартует от 500 ₽/мес; в готовых тарифах есть Lite с 1 CPU, 1 ГБ RAM и 15 ГБ NVMe.
• Виртуальный хостинг и CMS-хостинг доступны отдельными услугами.
• В тарифах VPS указаны месячные пакеты трафика; на младшем Lite — 1 ТБ и порт 100 Мбит/с.
• Бэкапы зависят от тарифа: для части тарифов платно, для части включены.
• Есть скидки за предоплату на 6, 12 и 24 месяца.
• На странице указано соответствие требованиям РФ по 152-ФЗ.

Официальный сайт: adminvps.ru

6. FirstVDS — готовые VDS/VPS-конфигурации

Провайдер с фокусом на виртуальные серверы: готовые VDS/VPS, отдельные линейки для высоких CPU-частот, storage-сценариев, GPU и Windows. В подборке это вариант для тех, кто выбирает именно VPS/VDS и сопутствующие услуги, а не классический shared-хостинг.

Кейсы клиентов и кому подойдёт

• Небольшие сайты и сервисы, которым нужен отдельный сервер вместо виртуального хостинга.
• Разработчики, которым важны готовые Linux-образы, SSH-доступ и быстрый запуск сервера.
• Проекты, где позже могут понадобиться Windows-серверы, storage-линейка или зарубежная локация.

Что можно развернуть

На VPS/VDS доступны Linux-дистрибутивы Debian, Ubuntu, FreeBSD, CentOS и Alma, платная Windows, панели ispmanager и дополнительные IP. В линейке есть VDS для Windows, VDS в Нидерландах и Алматы, storage-серверы, GPU-серверы и объектное хранилище S3.

Инфраструктура и экосистема

На сайте указаны дата-центры в России, Нидерландах и Казахстане. Для VDS в Москве доступны каналы до 100 Мбит/с с безлимитным трафиком или до 1 Гбит/с с пакетом 32 ТБ в месяц; для Амстердама и Казахстана условия отличаются.

Отзывы и репутация

FirstVDS работает как отдельный бренд виртуальных серверов и указывает награды отраслевой премии ЦОДы.рф. На сайте также опубликованы пользовательские отзывы и раздел базы знаний.

Поддержка и каналы связи

На сайте указан бесплатный круглосуточный телефон 8 800 775-38-37, база знаний и служба поддержки. Для серверов доступны дополнительные услуги администрирования и технического сопровождения.

Тарифы, ограничения и условия

• Готовые VDS/VPS — от 249 ₽/мес; запуск сервера заявлен за несколько минут.
• Бесплатно с сервером: 1 выделенный IP-адрес, ispmanager 6 lite на 1 месяц, установка ОС на выбор и полный SSH-доступ.
• Тестовый период предоставляется по согласованию.
• Windows тарифицируется отдельно: на странице указано 680 ₽/мес за 1 ядро, недоступно для VDS в Амстердаме и Алматы.
• Для VDS в Москве возможен канал до 100 Мбит/с с безлимитным трафиком или до 1 Гбит/с с лимитом 32 ТБ/мес.
• Дополнительные услуги: бэкап, мониторинг, BitNinja, DDoS-защита, домены, SSL и DNS-хостинг.

Официальный сайт: firstvds.ru

Сравнение по ключевым критериям

Ниже — сводка по ценам, лимитам и условиям, которые чаще всего влияют на выбор.

• Минимальный виртуальный хостинг: ИХЦ — от 123 ₽/мес (при оплате за год), SpaceWeb — от 149 ₽/мес; AdminVPS предлагает виртуальный/CMS-хостинг отдельной линейкой; UFO.Hosting, PSB Hosting и FirstVDS в подборке рассматриваются прежде всего как VPS/VDS-провайдеры.
• Минимальный VPS/VDS: ИХЦ — от 317 ₽/мес (за год), UFO.Hosting — 605,85 ₽/мес, SpaceWeb — цена в калькуляторе с посуточной тарификацией, PSB Hosting — от 8 USD, AdminVPS — от 500 ₽/мес в конфигураторе, FirstVDS — от 249 ₽/мес.
• Виртуализация: ИХЦ — KVM/Virtuozzo на выбор; UFO.Hosting — Intel Xeon и Ryzen линейки; SpaceWeb — собственная облачная платформа; PSB Hosting — KVM; AdminVPS и FirstVDS предлагают готовые VPS/VDS-линейки с Linux-образами.
• Трафик: ИХЦ и PSB Hosting — безлимитный (у ИХЦ снижение скорости после 20 ТБ); UFO.Hosting — безлимитный с порогом 32 ТБ; SpaceWeb — параметры уточняйте в конфигураторе; AdminVPS указывает месячные пакеты трафика; FirstVDS разделяет безлимитный канал 100 Мбит/с и пакеты трафика на более быстрых каналах.
• Root и ОС: полный root у всех шести; ИХЦ и PSB Hosting позволяют загружать собственные ISO; UFO.Hosting ограничивает список ОС на младших тарифах; у FirstVDS Windows и панели управления идут как платные дополнения.
• Бэкапы: SpaceWeb включает ежедневные бэкапы на хостинге; ИХЦ и PSB Hosting — платно; UFO.Hosting — платная услуга резервного копирования; AdminVPS и FirstVDS предлагают бэкапы как тарифную или дополнительную опцию.
• Тестовый период: SpaceWeb — 14 дней на хостинге и VPS; ИХЦ — 7 дней хостинг / 3 дня VPS; UFO.Hosting — до 3 дней VPS; FirstVDS — по согласованию; PSB Hosting — нет; условия AdminVPS зависят от акции и выбранной услуги.
• Дата-центры: ИХЦ — Москва + Амстердам; UFO.Hosting — Москва; SpaceWeb — Москва, Санкт-Петербург, Амстердам; PSB Hosting — Amsterdam, Frankfurt, Helsinki, New York; AdminVPS предлагает VPS в разных странах; FirstVDS указывает Россию, Нидерланды и Казахстан.
• Юридика: ИХЦ, UFO.Hosting, SpaceWeb и AdminVPS работают с российской юридической рамкой; PSB Hosting ориентирован на зарубежные локации; для FirstVDS условия документов и лицензий зависят от выбранных услуг.

Вывод

Виртуальный хостинг остаётся самым простым стартом для сайта-визитки, блога или небольшого магазина: не нужно администрировать сервер, всё настроено провайдером. VPS/VDS стоит брать, когда проекту нужна изоляция, root-доступ, нестандартное ПО или рост нагрузки. Выделенный сервер — следующий шаг, когда виртуализация уже не тянет задачу.

Если приоритет — российская юридика и плавный рост от хостинга до железа, смотрите на Интернет Хостинг Центр или SpaceWeb. Если важна экосистема из доменов, защиты и серверов в одном кабинете — UFO.Hosting или AdminVPS. Если нужен недорогой вход именно в VPS/VDS — можно сравнить FirstVDS с базовыми тарифами других участников. Если нужны зарубежные локации и гибкая оплата — PSB Hosting. Перед покупкой всегда берите тестовый период и проверяйте реальную производительность под вашей нагрузкой.

Сценарий придумал разработчик и исследователь безопасности Manish Goregaokar в материале «The Future of the Con Is Already Here», опубликованном 17 июня 2026 года. Его герой проходит «собеседование», подписывает NDA через фальшивый SSO, а спустя полгода обнаруживает украденную личность, пустой брокерский счёт и отсутствие доступа к почте. И всё это — работа одной языковой модели.

Что такое LLM-афера? Это не просто сгенерированное фишинговое письмо. Это целая цепочка действий — исследование жертвы, создание правдоподобного контекста, поддельные интервью, компрометация аккаунтов и извлечение денег — которую модель может поддерживать тысячами копий одновременно.

LLM заполняют середину между дешёвым спамом и дорогими целевыми атаками: аферы становятся персонализированными и масштабируемыми одновременно.

Цена персонализированного фишинга уже измеряется центами за письмо, а успешность почти втрое выше обычной рассылки.

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

Привычные проверки реальности — красивый текст, веб-присутствие, голос, видео — перестают быть надёжными.

Новая защита: многоканальная верификация через инициированный вами контакт, аппаратный 2FA и понимание «швов» в системах.

Как выглядит атака: от письма рекрутера до пустого брокерского счёта

Подготовка и вход

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

Дальше — письмо от рекрутера, идеально попадающее в ваш опыт; короткий скрининг; и ссылка на подписание NDA в сервисе для юридических документов. Вы входите через Sign in with Google или Apple ID — и видите привычную страницу входа. Но это не настоящий OAuth: атакующий использует ваш пароль и последующий запрос двухфакторной аутентификации, чтобы создать сессию в вашем настоящем аккаунте.

Длительная эксплуатация

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

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

Финал

Когда риск раскрытия становится высоким, жертва блокируется из собственных аккаунтов. Процесс восстановления занимает месяцы, а часть средств уже не вернуть. Ирония в том, что «отказ» после собеседования был нужен только для того, чтобы вы не задавали лишних вопросов и не меняли пароли.

Почему раньше это казалось невозможным

Раньше угрозы были примерно бимодальными. С одной стороны — дешёвый спам, который ловит менее внимательных пользователей. С другой — дорогие целевые атаки, которые имеют смысл только против VIP или крупных сумм: классический пример — афера на $25 млн в Гонконге с использованием дипфейков на видеоконференции.

В принципе, вы либо имеете дело с Моссадом, либо не имеете. Если противник — не Моссад, то вам достаточно хорошего пароля и игнорирования писем от ChEaPestPAiNPi11s@virus-basket.biz.ru.

Эта шутка отражает старую реальность: возможности атакующих были либо очень дешёвыми и неточными, либо очень дорогими и точными. Целевую атаку на рядового специалиста просто не окупалось: нужна была команда, время, инфраструктура, и это не масштабировалось.

LLM меняют распределение. Исследование 2024 года показало, что персонализированный spear phishing с помощью языковых моделей обходится примерно в 4 цента за письмо, а в более позднем эксперименте на 7700 участниках LLM-письма дали кликабельность 10,0% против 3,9% у обычных рассылок. Модели 2026 года заметно сильнее.

Что даёт масштабируемость

Когда афера стоит центы, её можно запускать в цикле. Это не метафора: один оператор может вести тысячи сценариев параллельно. Масштаб открывает три новых свойства, которых раньше не было у индивидуальных атак.

• Терпение. Человеческая бригада не может ждать месяцами между этапами. LLM-жертв — тысячи, поэтому часть сценариев может «спать» полгода и активироваться в нужный момент.
• Композиция. Мелкая афера может найти «финансового мула», который потом поможет вывести крупную сумму. Маленькие разводы складываются в большую машину.
• Новые цели. Тысяча скомпрометированных аккаунтов — это не просто украденные деньги, а тысяча аутентифицированных позиций внутри платформ. Их можно использовать одновременно, чтобы эксплуатировать «швы» систем, с которыми банки и сервисы мирились как с приемлемым риском.

Goregaokar приводит аналогию с фильмом «Афера» (1973): то, что раньше требовало зала, реквизита, костюмов и десятков людей, сегодня может получиться за несколько запросов к модели.

Почему наши эвристики ломаются

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

Сегодня эти признаки генерируются за минуты. LLM пишет текст, клонирует голос, создаёт дипфейк-видео в реальном времени, делает поддельный сайт и поддельные профили. Эвристики, построенные на стоимости обмана, перестают работать.

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

Проблема касается не только людей, но и институтов. В США потребительская защита Regulation E чётко разделяет несанкционированный перевод (банк обязан вернуть деньги) и ситуацию, когда вас убедили перевести деньги сами. Когда LLM может действовать изнутри вашего аккаунта, эта граница размывается. В Великобритании в 2024 году приняли закон, обязывающий банки возмещать ущерб жертвам так называемого authorized push payment fraud — признание того, что старая логика уже не работает.

Что делать

Полностью застраховаться от обмана невозможно — оптимальное количество мошенничества не равно нулю. Но можно сделать себя дорогой и неудобной целью.

1. Ищите скелет аферы. Срочность, секретность, просьба действовать по необычному каналу — классические маркеры. Они остаются даже при идеальной подаче.
2. Верифицируйте через инициированный вами контакт. Письмо, которое вы сами написали на известный адрес, скорее всего дойдёт до адресата. Звонок, который вы сами сделали на сохранённый номер, скорее всего дойдёт до устройства. Поля From: и Caller ID подделываются.
3. Договоритесь о устных паролях с близкими. Если родственник звонит с просьбой о деньгах, попросите назвать слово, которое знаете только вы двое.
4. Используйте аппаратный 2FA. FIDO2/WebAuthn привязывает подпись к домену сайта, поэтому фишинговая страница не сможет просто перебросить подтверждение. SMS и OTP-приложения уязвимы для фишинга в реальном времени.
5. Снижайте публичное досье. Чем меньше персональных данных связано с вашим email, тем сложнее LLM построить убедительный сценарий.

Важно понимать, кого защищают системы, которыми вы пользуетесь. Многие «швы» — например, лояльное отношение к спорным переводам или простая смена получателя — существуют не потому, что банки глупы, а потому что удобство стоит дороже редких потерь. Когда такие «швы» начинают эксплуатировать тысячи скомпрометированных аккаунтов одновременно, экономика меняется, и платформам придётся пересматривать правила.

Выводы

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

Будущее мошенничества уже здесь. Оно просто распределено неравномерно.

Следующие годы станут гонкой вооружений: платформы и регуляторы будут пересматривать защиту, а атакующие — искать новые «швы». Пока институции адаптируются, единственное, что остаётся лично нам, — обновить эвристики: не доверять входящим каналам, верифицировать через исходящие и делать себя дорогой целью. И помогать разобраться родителям и друзьям, которые о таких вещах могут не знать.

Источники

— Manish Goregaokar — The Future of the Con Is Already Here, It's Just Not Evenly Distributed

— Evaluating Large Language Models' Capability to Launch Fully Automated Spear Phishing Campaigns

— Bruce Schneier — Mickens on Security

— CNN — Hong Kong worker loses $25 million in deepfake video call scam

GitLab опубликовала отчёт на основе опроса более чем 1500 разработчиков и технологических лидеров. 60% заявили, что ROI инструментов ИИ-кодирования уже превзошёл ожидания. Однако 80% организаций внедрили ИИ быстрее, чем выработали политики управления, а 82% опасаются, что ИИ-код порождает новый технический долг.

• 60% считают ROI ИИ-кодирования выше ожиданий.
• 78% команд пишут и коммитят код быстрее.
• Только 21% видят продуктивность за пределами генерации кода.
• 85% считают, что следующий этап — управление ИИ-кодом, а не его генерация.
• Agentic infrastructure состоит из четырёх слоёв: исполнение, контекст, управление и оркестрация.

Проблема в том, что современная инфраструктура создана под человеческую скорость и подотчётность. Git-бекенды, CI/CD, системы деплоя и governance-фреймворки не рассчитаны на миллионы сессий агентов. Это ведёт к деградации надёжности платформ, росту уязвимостей и перерасходу токенов.

Четыре слоя agentic infrastructure

1. Исполнение в машинном масштабе

Git-бекенды, пайплайны CI/CD и системы деплоя проектировались под темпы человеческой работы. В эпоху агентов они должны выдерживать миллионы сессий без сбоев. Когда инцидент случается в продакшене, путь от симптома к причине должен занимать минуты, а не дни.

2. Контекст, который путешествует с кодом

Агент полезен ровно настолько, насколько полный контекст ему доступен. Контекстный граф, связывающий код, задачи, пайплайны, security-фидбек и продакшен-сигналы, позволяет агентам действовать осмысленно и снижает риск «искусственной уверенности».

Агент может быть только таким хорошим, какой контекст и семантика ему предоставлены.

3. Управление, встроенное в процесс

Действия агентов должны быть привязаны к идентичности, зафиксированы в логах и проверяемы. Низкорисковые изменения проходят быстро, высокорисковые — попадают на ревью. Для компаний вроде Mercedes-Benz, работающих под автомобильными стандартами, это не опция, а требование регуляторов.

4. Оркестрация

Исполнение, контекст и управление работают только в том случае, если ими координирует единый слой. Оркестратор определяет, какие агенты запускаются, в каком порядке, и как обрабатываются ошибки и передачи между этапами. Без него agentic infrastructure остаётся набором разрозненных возможностей.

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

Выводы

Скорость и контроль перестают быть компромиссом, если управление встроено в платформу. Тогда трассируемость становится преимуществом, а контекст — институциональной памятью. Кодовая база перестаёт накапливать невидимый риск и начинает работать надёжнее с ростом нагрузки.

Источник: The New Stack — Agentic Infrastructure & AI Governance.

Вместе с моделью компания обновила плагин Codex Security. Он помогает разработчикам запускать глубокие сканы и проверять свежие изменения, расставлять приоритеты по серьёзности, прокладывать пути атаки и генерировать патчи, адаптированные под конкретную кодовую базу. Плагин также умеет обрабатывать находки из сканеров, баг-баунти-программ и тикет-систем.

OpenAI выпустила GPT-5.5-Cyber — модель для поиска и исправления уязвимостей в больших кодовых базах.

Codex Security получил апдейт: глубокие сканы, триаж, генерация патчей и предотвращение новых багов в production.

Запущена инициатива Patch the Planet совместно с Trail of Bits для помощи мейнтейнерам open source.

Инициатива Daybreak уже помогла найти десятки уязвимостей в Linux, FreeBSD, Chrome, Safari, Firefox и других проектах.

Контекст: узкое место сместилось с поиска на исправление

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

По данным канадского центра кибербезопасности, организациям стоит исходить из того, что ИИ-эксплуатация может обходить превентивные меры быстрее, чем вендоры выпускают корректирующие обновления.

Что уже нашла Daybreak

В рамках Daybreak OpenAI уже публиковала результаты совместной работы моделей и исследователей:

• 8 утечек указателей ядра Linux и 24 эксплойта повышения привилегий;
• 23-летнюю use-after-free в реализации System V semaphores в OpenBSD;
• 34 уязвимости и 7 эксплойтов повышения привилегий в FreeBSD;
• 6 уязвимостей в dnsmasq;
• технику отказа в обслуживании HTTP/2 Bomb, затронувшую NGINX, Apache, IIS и Pingora;
• 5 эксплуатируемых уязвимостей в движке V8 Google Chrome, 10 — в Apple Safari и уязвимость WebAssembly в Mozilla Firefox.

Patch the Planet для open source

Новая программа Patch the Planet, запущенная совместно с Trail of Bits, направлена на снятие нагрузки с мейнтейнеров. Инженеры будут напрямую работать с проектами — от cURL и Python до Go, freenginx, NATS Server, pyca/cryptography, Sigstore и aiohttp — помогать готовить патчи, тесты и reusable workflow для поиска багов.

Выводы

GPT-5.5-Cyber и обновлённый Codex Security — попытка перевести ИИ-инструменты кибербезопасности от простого нахождения багов к полному циклу исправления. Главный вопрос — успеют ли защитники адаптироваться быстрее атакующих.

Frontier AI models are anticipated to exceed current industry expectations, fundamentally transforming both offensive and defensive cyber capabilities. The timeline is not years, it is months.

Источники

• OpenAI Expands Daybreak With GPT-5.5-Cyber — The Hacker News

Это не очередной корпоративный конфликт. История соединяет в себе инвестиции Amazon в Anthropic, секретную программу доступа к киберспособностям ИИ, появление южнокорейского оператора в списке участников и попытку администрации США установить новый стандарт безопасности frontier-моделей. Разбираем, как звонок одного топ-менеджера запустил цепочку, которая поставила под вопрос саму возможность коммерческого запуска сильных ИИ.

Энди Джасси сообщил о jailbreak Fable 5 на регулярном звонке с Белым домом 11 июня, хотя Amazon инвестировала в Anthropic $4 млрд и является основным облачным партнёром компании.

Министр торговли США Говард Лутник поставил Anthropic ультиматум: устранить уязвимость за 90 минут или отключить Fable 5 и Mythos 5 глобально.

Дополнительный триггер — расширение программы Project Glasswing примерно на 50 организаций без предварительного одобрения национальной безопасности, включая SK Telecom.

CEO Anthropic Дарио Амодеи отверг оба варианта решения, назвав применённый стандарт невыполнимым для любой frontier-лаборатории.

Исследователи безопасности считают требование «нулевого jailbreak» технически недостижимым: такой модели не существует и в обозримом будущем не появится.

Что произошло: от звонка до отключения за 33 часа

11 июня Джасси участвовал в запланированном звонке с чиновниками Белого дома. Повестка была не про ИИ, но перед завершением он упомянул, что исследователи Amazon задокументировали метод обхода защит Fable 5 — модели, которую Anthropic выпустила за два дня до этого. Чиновники посоветовали ему обратиться напрямую к министру финансов Скотту Бессенту. Джасси сделал это в тот же день.

К следующему вечеру тема перекочевала из министерства финансов в министерство торговли. 12 июня в 17:21 Лутник подписал директиву Anthropic: компания получила 90 минут на решение — исправить jailbreak или вывести Fable 5 и Mythos 5 из эксплуатации. За такой срок техническое исправление было невозможно, и Anthropic отключила обе модели глобально ещё до 22:00.

Примечательно, что Джасси выбрал официальный канал, а не прямой разговор с Anthropic. Это ускорило реакцию и превратило уязвимость из внутреннего инцидента в государственное дело. Amazon отказалась комментировать роль Джасси; Anthropic — обсуждать внутреннюю хронологию.

Project Glasswing: почему список доступа оказался важнее самого jailbreak

Сам по себе jailbreak, скорее всего, не вызвал бы столь жёсткой реакции. Триггером стала вторая находка: недавнее расширение программы Project Glasswing, в рамках которой Anthropic давала избранным организациям доступ к Claude Mythos — модели с сильными киберрассуждениями, ориентированной на задачи национальной безопасности.

К началу июня Anthropic добавила в программу около 50 новых организаций без предварительного согласования с американскими чиновниками по национальной безопасности. Одной из них стала SK Telecom — крупнейший южнокорейский оператор связи. Компания опровергла любые связи с Китаем, но её появление в списке без согласования вызвало в Вашингтоне вопрос: а кто ещё получил доступ к Mythos?

Когда отчёт о jailbreak пришёл на фоне уже накопившихся подозрений, два фактора сложились. Расширение Glasswing разрушило доверие между Anthropic и национально-безопасственным истеблишментом, а уязвимость дала повод действовать немедленно. Расследование Fortune, опубликованное 18 июня, называет именно эту комбинацию ключевой в решении Белого дома.

Позиция Anthropic: почему Дарио Амодеи сказал «нет»

Ультиматум Лутника предполагал два варианта: устранить jailbreak или отключить модели. CEO Anthropic Дарио Амодеи отверг оба на принципиальной основе. Дело в том, что уязвимость связана с обычным запросом: попросить модель просмотреть код и исправить ошибки. Это легитимный и распространённый сценарий использования, а не экзотическая атака.

В публичном заявлении Anthropic назвала находку «узким, неуниверсальным jailbreak'ом», который не соответствует планке для полного коммерческого отзыва. Компания также предупредила, что если такой стандарт применить отраслево, он фактически остановит все новые релизы frontier-моделей.

Если этот стандарт будет применяться ко всей индустрии, мы считаем, что это по сути остановит все новые развёртывания моделей для всех поставщиков frontier-моделей.

Советник Белого дома по ИИ Дэвид Сакс сначала высказался оптимистично, назвав проблему «легко решаемой». Однако к 16 июня переговоры зашли в тупик, экспортные ограничения для иностранных пользователей оставались в силе, а Сакс действовал уже в консультативном качестве после ухода с формальной должности. 19 июня управляющий директор Anthropic по международным вопросам Крис Чаури сообщил журналистам, что модели появятся «в ближайшие дни», но точной даты не назвал.

Технический разбор: может ли frontier-модель быть безупречно защищённой?

В центре конфликта — требование, которое администрация фактически выдвинула Anthropic: гарантия отсутствия jailbreak'ов. Исследователи безопасности, опрошенные несколькими изданиями, единодушны: модель, устойчивая к jailbreak'ам на 100 %, не существует.

Невозможно гарантировать, что модель останется неуязвимой к jailbreak'ам навсегда. Тот, кто это обещает, что-то продаёт.

Аргумент Anthropic строится именно на этом. Компания не отрицает наличие уязвимости, но оспаривает стандарт. Если один узкий jailbreak в коммерческой модели оправдывает глобальный отзыв, то ни одна frontier-лаборатория не сможет выпускать продукты: каждый релиз так или иначе содержит слабые места, обнаруживаемые сообществом в течение дней или недель.

Это ставит регуляторов перед дилеммой. С одной стороны, нужен механизм реагирования на опасные уязвимости, особенно когда речь идёт о моделях с киберспособностями и секретных программах доступа. С другой — стандарт «нулевого jailbreak» технически недостижим, и его применение превратит frontier-рынок в поле для политического произвола.

Что это значит для России и остального мира

Для российских разработчиков и компаний инцидент — ещё один сигнал, что доступ к сильным зарубежным моделям может исчезнуть за часы. Экспортные ограничения после 12 июня коснулись не только российских пользователей, но и европейских, азиатских и латиноамериканских. Разница между «коммерческий API доступен» и «модель отключена» сократилась до 90 минут одного чиновника.

В России это усиливает аргументы в пользу собственных ИИ-инфраструктур и моделей: отечественные чипы, национальная облачная платформа, локальные large language models. Но копировать архитектуру недостаточно — важны процессы безопасности, аудита и прозрачного доступа. История с Glasswing показывает, что скрытое расширение списка партнёров может разрушить доверие быстрее, чем любая техническая уязвимость.

Выводы: дилемма, которую пока никто не решил

История с Fable 5 — не просто очередной конфликт ИИ-лаборатории и регулятора. Это демонстрация того, как быстро инфраструктура доступа к сильному ИИ может быть перекрыта одним политическим решением. Джасси поднял тревогу, Лутник перевёл её в ультиматум, Амодеи отказался подчиниться — и миллионы пользователей лишились доступа к двум лучшим моделям Anthropic.

Главный вопрос остаётся без ответа: какой стандарт безопасности применим к коммерческим frontier-моделям? Белый дом хочет гарантий, которых технически не существует. Anthropic хочет сохранить способность выпускать продукты, не рискуя отключением из-за каждого найденного jailbreak'а. Пока эти позиции не сойдутся, ни одна сторона не сможет объявить победу.

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

Правительство требует условия, которое Anthropic технически не может выполнить. Anthropic требует условия, которое оно не может принять, не открыв дверь для отключения любой модели по одному найденному jailbreak'у. Пока такого компромисса нет.

Источники

Основа материала — расследование Fortune о роли Энди Джасси в отключении Fable 5 и Mythos 5, опубликованное 18 июня 2026 года. Дополнительный контекст — официальные заявления Anthropic, комментарии Дэвида Сакса и оценки исследователей безопасности.

• The Inside Story of the Call That Banned Fable 5 — Awesome Agents (на основе расследования Fortune)
• Statement on the US government directive to suspend access to Fable 5 and Mythos 5 — Anthropic
• Anthropic suspends all access to Mythos model after US government bans foreign nationals use — CNN Business
• US orders Anthropic to disable AI models for all foreign nationals — Al Jazeera
• The White House Wants Anthropic to Block All Jailbreaks. That May Be Impossible — Gadget Review