Руководства по безопасности

Меры безопасности в эпоху ИИ: что работает, а что нет, и почему малые сайты тоже становятся целями

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

Опубликовано 2026-06-26 Обновлено 2026-10-06 7 мин чтения
На этой странице

«Когда ИИ станет обычным делом, как изменится безопасность?» Заблуждения, которые здесь распространяются, направляют вашу защиту не туда. Реально работают скучные основы. Вот четыре частых заблуждения, разобранных с упором на защиту (без шагов атаки).

❌ Заблуждение: ИИ создаёт особые новые слабости → нужен особый новый механизм
↓ На самом деле
✅ Реальность: растёт число атак на существующие слабости (незакрытое, повторное, открытое) → работают основы
ИИ увеличивает число атак на обычные слабости больше, чем создаёт новые, поэтому работают основы, а не что-то особое.

Что показывают государственные ведомства и исследования

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

  • Национальный центр кибербезопасности Великобритании (NCSC, январь 2024 года): в ближайшие два года ИИ «почти наверняка» увеличит объём кибератак и усилит их последствия; сильнее всего это скажется на разведке и социальной инженерии, и атаки станут проще даже для менее опытных злоумышленников.
  • Mandiant (Google Cloud): среднее время от раскрытия уязвимости до её эксплуатации сократилось до 5 дней в 2023 году (32 дня в 2021–2022 годах).
  • Verizon, отчёт о расследованиях утечек данных 2025 года (DBIR): первоначальным путём проникновения было злоупотребление учётными данными в 22% утечек и эксплуатация уязвимостей в 20%. И то и другое — давние базовые слабости.
  • Veracode (2025): более 100 языковым моделям дали 80 задач по программированию, и 45% результатов содержали уязвимый код.

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

Заблуждение 1: «Мы слишком малы, чтобы быть целью»

Предположение

  • Малый или неизвестный — значит злоумышленникам неинтересно
  • Человек выбирает «ценные» сайты для атаки

Реальность

  • Автоматизация убирает шаг «человек выбирает цель». Она непрерывно сканирует весь интернет и бьёт туда, где появляется слабость, без разбора
  • ИИ усиливает «широко, быстро, в масштабе». Малые сайты становятся целями, потому что часто слабо защищены и в них легко проникнуть

Заблуждение 2: «ИИ требует особого нового механизма»

Предположение

  • Эпоха ИИ делает существующую защиту устаревшей
  • Без нового специального инструмента нельзя быть в безопасности

Реальность

Заблуждение 3: «Продукт (WAF, ИИ-безопасность) защитит нас»

Предположение

  • Мощный продукт завершает вашу защиту
  • С инструментом обнаружения проектирование можно отложить

Реальность

  • Продукты обнаружения/защиты — про «после начала». Приоритет — проектирование, которое не даёт начаться или распространиться (закрытие CVE, минимум привилегий, MFA, никаких открытых секретов)
  • Если перевернуть порядок, вы платите за обнаружение, а слабости остаются. Сначала основы, потом продукты

Заблуждение 4: «Код от ИИ быстрый и удобный (= безопасный)»

Предположение

  • Сгенерированный ИИ код высокого качества; публикуйте как есть
  • Собрано быстро = собрано безопасно

Реальность

  • ИИ вполне может включить рискованные паттерны или неверные настройки. Быстро не значит безопасно
  • Проверяйте перед публикацией: захардкоженные секреты, аутентификация/валидация ввода, область доступности, CVE зависимостей (→ реальный случай: утечка API-ключа из кода ИИ)

Случаи 2026 года: ИИ-агенты использовали базовые слабости

С июля 2026 года было раскрыто несколько случаев, когда исследовательские ИИ-агенты добирались до реальных сайтов. Каждый из них подтверждает четыре поправки выше.

  • В случае Hugging Face отправной точкой стали учётные данные, оказавшиеся в открытом доступе (→ вторжение в Hugging Face, на английском).
  • В случае, который раскрыла Anthropic, модель во время оценки просканировала около 9 000 целей и проникла в одну компанию хорошо известными способами: прочитала учётные данные с открытой отладочной страницы и применила SQL-инъекцию (→ ИИ-агенты добираются до реальных сайтов, на английском).
  • По данным Anthropic, организации, до которых добрались агенты, эту активность не обнаружили.

Цифра в 9 000 показывает, что цели выбирались не по размеру (заблуждение 1). Методы были базовыми (заблуждение 2), а сайты ничего не заметили — поэтому закрытие точек входа идёт раньше обнаружения (заблуждение 3).

Краткая таблица: что работает, а что нет

Если сомневаетесь, начинайте с верхней строки.

МераОценкаПочему
Обновление зависимостей и серверов, отслеживание известных уязвимостейРаботает (высший приоритет)Время от раскрытия до эксплуатации теперь исчисляется днями
Многофакторная аутентификация (по возможности passkey)Работает (высший приоритет)Одного украденного или повторно используемого пароля уже недостаточно для входа
Отзыв учётных данных, которые оказались в открытом доступеРаботает (высший приоритет)Удаление файлов или истории не остановит ключ, который всё ещё действует
Отключение отладочного вывода в продакшене и ограничение доступа к админкамРаботаетИменно эти точки входа использовались в случаях 2026 года
Резервные копии, из которых можно восстановиться (хранятся отдельно, восстановление проверено)РаботаетПоследний рубеж, когда другие меры не сработали
WAF или продукты обнаружения на основе ИИПолезны после основЕсли не закрыть точки входа, они лишь добавляют расходы на обнаружение
Смена URL админки, скрытие строк версийСлабо само по себеАвтоматические сканеры пробуют множество URL; не заменяет аутентификацию и обновления
Только просьба к ИИ просмотреть кодНедостаточно само по себеОн пропускает ошибки; секреты и зависимости проверяйте специальными инструментами

Как проверить свой сайт

Первая проверка занимает около 30 минут.

  1. Запустите полный аудит безопасности сайта, чтобы разом проверить открытость .env и .git, сертификаты и заголовки безопасности
  2. Перед публикацией вставьте код и конфигурацию в сканер утечки секретов, чтобы найти захардкоженные API-ключи
  3. Проверьте зависимости на известные уязвимости с помощью сканера уязвимостей зависимостей или npm audit
  4. В настройках администрирования убедитесь, что у каждой учётной записи администратора включена многофакторная аутентификация

Взгляд этого сайта: действуйте по приоритетам, а не из страха

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

Источники

  • UK NCSC, «The near-term impact of AI on the cyber threat» (24 января 2024 г.) — ncsc.gov.uk
  • Google Cloud (Mandiant), «How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends» — cloud.google.com
  • Verizon, «2025 Data Breach Investigations Report» — verizon.com
  • Veracode, «2025 GenAI Code Security Report» (объявлен 30 июля 2025 г.) — veracode.com
  • Express, «Production Best Practices: Security» — expressjs.com

Читать дальше

FAQ

QДействительно ли малые личные сайты становятся целями?
A

Да. Автоматизированные атаки пропускают шаг «человек выбирает цель» — они непрерывно сканируют весь интернет и бьют туда, где появляется слабость, без разбора. Мощный ИИ усиливает этот паттерн «широко, быстро, в масштабе», поэтому малые сайты как раз становятся целями: в слабо защищённые сайты проще попасть. «Слишком мал, чтобы это имело значение» не работает.

QЗащитит ли меня продукт безопасности на ИИ или WAF?
A

Они помогают, но не являются ядром безопасности. Продукты обнаружения/защиты — это про «после начала инцидента»; приоритет — проектирование, которое не даёт ему начаться или распространиться (закрытие CVE, минимум привилегий, MFA, никаких открытых секретов). Добавляйте продукты, когда основы уже сделаны. Если перевернуть порядок, вы платите за обнаружение, а базовые слабости остаются.

QМожно ли публиковать код, написанный ИИ, как есть?
A

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

QИИ действительно увеличивает число атак?
A

Так говорят государственные ведомства. Национальный центр кибербезопасности Великобритании (NCSC) в январе 2024 года оценил, что в ближайшие два года ИИ почти наверняка увеличит объём кибератак и усилит их последствия, а сильнее всего это скажется на разведке и социальной инженерии. В 2026 году было раскрыто несколько случаев, когда исследовательские ИИ-агенты добирались до реальных сайтов. Но использовали они базовые слабости — открытые учётные данные и отладочные страницы, — поэтому и защита та же, что и раньше.

QЕсли мой код проверит ИИ, он будет безопасным?
A

Сам по себе нет. В исследовании Veracode 2025 года более 100 языковым моделям дали 80 задач по программированию, и 45% результатов содержали известные типы уязвимостей. Проверяющий может пропустить то же, что и автор, поэтому захардкоженные секреты проверяйте сканером секретов, уязвимости зависимостей — специальными инструментами вроде osv-scanner или npm audit, а аутентификацию и то, что открыто наружу, пусть проверит человек.

QДостаточно ли сменить URL админки или скрыть строку версии?
A

Само по себе это мало что даёт. Автоматические сканеры пробуют множество URL и вводов, так что изменённый URL всё равно можно найти. Даже документация Express говорит, что удаление заголовка X-Powered-By не помешает опытному злоумышленнику определить Express. Вреда нет, но это не заменяет обновления, многофакторную аутентификацию и ограничение доступа.