Более 100 компаний ждут волну ИИ-атак — на подготовку остались месяцы
В публикации Reuters от 27 августа 2026 года говорится, что OpenAI, Anthropic, Microsoft, Alphabet и Amazon вместе с более чем 100 другими компаниями призвали ускорить подготовку к атакам с применением ИИ. Подписанты ожидают, что в ближайшие месяцы такие атаки станут распространённее и сложнее.
Опубликованное OpenAI открытое письмо также подписали AWS, Google, Cisco, Cloudflare, CrowdStrike, IBM, Mastercard, Oracle, Visa, Deutsche Telekom, General Motors и другие организации. Они рекомендуют исправить наиболее опасные уязвимости, ограничить права доступа, проверять сгенерированный ИИ код и применять компенсирующие меры там, где быстрое обновление невозможно.
Фраза об оставшихся месяцах не означает, что известна дата начала конкретной атаки. Материал Axios о предупреждении уточняет, что письмо не содержит обязательств подписантов, контрольных сроков или конкретных инвестиций.
Кто подписал письмо и какой риск они описывают
Состав подписантов выходит далеко за пределы разработчиков моделей. В перечне есть облачные платформы, поставщики средств защиты, банки, телекоммуникационные операторы, промышленные компании и профессиональные организации.
Авторы связывают риск не с одной новой техникой взлома, а с возможностью быстрее и шире использовать уже накопленные слабости. Они перечисляют давние ошибки, избыточные разрешения, неверные настройки, слабую аутентификацию, необновлённое программное обеспечение и технический долг устаревших систем.
Особое внимание уделено службам, от которых зависит повседневная жизнь: больницам, водоочистным сооружениям и инфраструктуре интернета. При этом письмо не оценивает вероятность атаки для отдельной организации и не доказывает, что каждая компания столкнётся с ней в обозначенный период.
Что компания может проверить за один день
Первый приоритет — составить короткую очередь наиболее опасных разрывов, а не начинать полную перестройку защиты. За рабочий день можно сопоставить доступные из интернета системы, критичные учётные записи и известные уязвимости с сотрудниками, отвечающими за исправление.
В начале очереди должны оказаться слабости с наиболее тяжёлыми возможными последствиями: уязвимые внешние сервисы, административный доступ без достаточной защиты и учётные записи с правами, которые не нужны для текущей работы. Для каждой позиции следует зафиксировать владельца, временную защиту или способ исправления и условие повторной проверки.
Одновременно можно пересмотреть административные, сервисные и автоматизированные учётные записи. Удаление очевидно лишних разрешений обычно требует прежде всего времени специалистов, но результат необходимо проверить: необдуманное ограничение доступа способно остановить критичную операцию.
Деление задач на день, неделю и квартал — редакционная схема приоритетов, а не график из письма. Реальные сроки зависят от масштаба инфраструктуры, доступности специалистов и допустимых перерывов в работе.
Что следует закрыть за неделю
На недельном горизонте найденные риски нужно перевести из списка в проверенные изменения. Для обновления это означает убедиться в установке нужной версии и работоспособности сервиса; для настройки доступа — проверить, что прежний путь получения избыточных прав закрыт, а разрешённые операции продолжают выполняться.
Сгенерированный ИИ код нельзя считать безопасным только из-за способа его создания. Приоритетной проверке подлежат новые изменения, внешние зависимости и участки, работающие с секретами, персональными, платёжными или административными данными.
К такому коду применимы те же процедуры, что и к написанному человеком: рецензирование, анализ зависимостей, автоматические проверки, испытание обработки входных данных и контроль секретов. Если провести полную проверку за неделю нельзя, выпуск наиболее рискованных изменений разумно отложить либо ограничить их доступ к критичным данным и системам.
Цель недельного этапа — закрыть наиболее опасные и доступные для исправления разрывы. Остальным нужны временная защита, ответственный сотрудник и понятное условие, после которого мера будет пересмотрена.
Как защитить системы, которые нельзя быстро обновить
Для устаревших или непрерывно работающих систем письмо предусматривает компенсирующие меры. Если исправление нельзя установить без нарушения основной услуги, альтернативный контроль должен снизить риск и пройти отдельную проверку.
В зависимости от архитектуры такими мерами могут быть сетевое разделение, ограничение разрешённых соединений, усиление контроля административного доступа, отключение ненужных интерфейсов и наблюдение за журналами. Эти действия не устраняют саму уязвимость: они сокращают доступную атакующему поверхность или возможный масштаб ущерба до ремонта либо замены системы.
Квартал подходит как ориентир для решений, которым необходимы бюджет, тестовая среда и согласованное окно обслуживания. К ним относятся замена неподдерживаемого компонента, перестройка схемы доступа и внедрение многоуровневой защиты. Для критичной системы срок может потребоваться короче, даже если это увеличивает стоимость работ.
Технические рекомендации письма не привязаны к законодательству одной страны, поэтому применимы и к инфраструктуре компаний в СНГ. Однако выбор средств защиты, хранение журналов и обработку данных организациям придётся соотносить с местными требованиями и доступностью поддержки.
Какие обязательства пока не появились
Письмо распределяет задачи между организациями, поставщиками технологий, государствами и разработчиками передовых моделей. От компаний в сфере кибербезопасности ожидают непрерывной проверки защиты, обмена сведениями об угрозах и проверенными сценариями реагирования. Государствам предлагают финансировать защиту служб с нехваткой сотрудников и бюджета.
Разработчиков моделей призывают предоставлять защитникам ответственный доступ к технологиям, обучение, средства наблюдения, финансирование и практическую поддержку. Для критической инфраструктуры отдельно упомянуты временные рекомендации от производителей и интеграторов, если исправление ещё не готово.
На 28 августа обращение остаётся добровольным отраслевым призывом, а не нормативным документом или общим планом исполнения. Дальнейшее развитие истории будет зависеть от появления конкретных программ поддержки, временных инструкций для необновляемых систем и измеримых данных о том, сколько организаций действительно устранили наиболее опасные слабости.
Читайте также:
Подпишитесь на рассылку
Получайте свежие новости Web3, AI и криптовалют прямо на вашу почту.