«Когда мощный ИИ станет обычным делом, что изменится в безопасности?» Ответ на удивление будничен: вам не нужен особый новый механизм; растёт ценность выполнения обычных основ сейчас. Вот почему, и в каком порядке их закрывать (с упором на защиту; без шагов атаки).
Почему именно сейчас
ИИ в основном усиливает атаки, а не изобретает их. С точки зрения защиты следите за этими пятью направлениями (общие тренды, которые стоит знать, — без инструкций):
Общее у всех: каждая атака проникает через обычную базовую слабость. Поэтому чем больше основ вы закрыли, тем чаще даже масштабные атаки не могут проникнуть. Базовые пробелы, которые вы откладывали, автоматизированные атаки находят первыми. Поэтому это важно именно сейчас.
Цифры это подтверждают. Mandiant (Google Cloud) выяснила, что среднее время от раскрытия уязвимости до её эксплуатации сократилось с 32 дней в 2021–2022 годах до 5 дней в 2023 году. В январе 2024 года Национальный центр кибербезопасности Великобритании (NCSC) также оценил, что в ближайшие два года ИИ «почти наверняка» увеличит объём кибератак. Привычка обновляться раз в месяц иногда будет слишком медленной.
Закрывайте в этом порядке (приоритетный чек-лист)
Сверху вниз. Каждый пункт ведёт к подробному руководству на этом сайте.
Мониторьте CVE зависимостей и закрывайте быстро
Прекратите повторно использовать пароли и включите MFA
Удалите открытые файлы секретов
.env, ключи и резервные копии, оставленные в веб-корне, — автоматические сканы хватают их первыми (→ секреты в публичных директориях · случай открытого .env · основы .env и API-ключей).Минимум привилегий, чтобы взлом нанёс меньше ущерба
Сократите публичную поверхность, остановите подделку
Укрепите зависимости и Git
Храните логи; умейте замечать по IOC
Имейте резервные копии и восстановление
Краткая таблица: частота и инструменты
Восемь пунктов выше, разделённые на то, что сделать сначала, и как часто потом. Частота — рекомендуемый ориентир этого сайта.
| Пункт | Сначала | Затем как часто | Инструменты (в основном бесплатные) |
|---|---|---|---|
| 1. Уязвимости зависимостей | Один раз просканировать зависимости во всех проектах | Еженедельно или автоматически при каждом изменении кода | osv-scanner, npm audit, composer audit, оповещения GitHub Dependabot |
| 1. Сроки закрытия | Сначала закрыть уязвимости с подтверждённой эксплуатацией (из KEV) | Записи KEV — от нескольких дней до двух недель | расстановка приоритетов по CVSS, EPSS и KEV |
| 2. Многофакторная аутентификация | Начать с учётных записей администраторов почты, GitHub, облака и управления доменом | При создании каждой учётной записи | Passkey, приложения-аутентификаторы |
| 3. Открытые секреты | Проверить публичные директории и публичные репозитории; отозвать любой найденный ключ | Перед каждым релизом | сканер утечки секретов, аудит сайта |
| 4. Минимум привилегий | Отключить неиспользуемые ключи, токены и учётные записи | Раз в три месяца | Список токенов доступа в каждом сервисе |
| 6. Защита Git | Добавить проверку, которая останавливает секреты до коммита | Автоматически (каждый коммит) | gitleaks, GitHub push protection |
| 8. Резервные копии | Хранить копию в другом месте и один раз попробовать восстановление | Проверка восстановления раз в три месяца | Снимки провайдера, внешнее хранилище |
GitHub push protection включена по умолчанию, когда личный аккаунт отправляет push в публичный репозиторий. Приватные репозитории и другие Git-сервисы она не покрывает, поэтому сочетайте её с локальной проверкой вроде gitleaks.
Частые ошибки и как их исправить
| Частая ошибка | Что происходит | Как исправить |
|---|---|---|
| Получить уведомление об обновлении, но не проверить, что оно применилось | Дыра остаётся открытой, хотя исправление существует | После обновления проверьте версию и снова запустите сканирование |
| Удалить утёкший ключ из файлов и истории и на этом остановиться | Если ключ не отозван, любой, у кого есть копия, по-прежнему может им пользоваться | Сначала отзовите его у выдавшего сервиса, затем перейдите на новый ключ |
| Включить MFA только для своей учётной записи | Кто-то входит через общую администраторскую или старую учётную запись | Составьте список всех учётных записей с правами администратора и включите MFA для всех |
| Хранить резервные копии на том же сервере | Если сервер выйдет из строя или будет зашифрован, копия пропадёт вместе с ним | Храните копию в другом месте и действительно проверьте восстановление |
| Выкатывать конфигурацию или код, написанные ИИ, сразу в продакшен | Остаются отладочный вывод или захардкоженные секреты | Перед релизом запустите поиск секретов и сканирование зависимостей |
Реальные случаи
Инцидент, с которого начался этот сайт, — типичный пример. API-ключ украли вскоре после выкатки кода, написанного ИИ, затем последовали мошеннические списания. Причина: опубликованная CVE высшей серьёзности (CVSS 10.0), месяцами остававшаяся незакрытой. Это конкретный пример того, как ИИ делает незакрытые слабости дороже (→ случай с утечкой API-ключа из кода ИИ).
Есть и другие случаи того же типа.
- Equifax (2017): исправление уязвимости Apache Struts вышло в день её раскрытия, но не было применено к публичной системе, и утекли персональные данные примерно 147 миллионов человек. Так выглядит пропуск пункта 1 (→ утечка Equifax).
- Hugging Face (2026): вторжение исследовательского ИИ-агента началось с учётных данных, оказавшихся в открытом доступе. Так выглядит пропуск пункта 3 (→ вторжение в Hugging Face, на английском).
Взгляд этого сайта: ИИ делает незакрытые слабости дороже, поэтому делайте основы сейчас
На этом сайте мы трактуем готовность к эпохе ИИ как выполнение основ раньше, а не добавление особых новых механизмов. Сильнее всего злоумышленникам с мощным ИИ в руках помогает не изобретение zero-day, а дешёвое и масштабное нахождение и удар по основам, которые вы отложили (незакрытое, повторно используемое, открытое). Поэтому работают скучные основы, сделанные в правильном порядке, сейчас. Проверьте свой сайт с помощью аудита безопасности сайта, проверки почтовой аутентификации и сканера зависимостей. Настроить — ещё не достаточно: защита работает, только когда вы её проверили.
Источники
- Google Cloud (Mandiant), «How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends» — cloud.google.com
- UK NCSC, «The near-term impact of AI on the cyber threat» (24 января 2024 г.) — ncsc.gov.uk
- US CISA, «BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities» — cisa.gov
- GitHub Docs, «About push protection» — docs.github.com
Читать дальше
-
Вторжение ИИ-агента: Вторжение в Hugging Face (2026): атака автономного ИИ-агента (на английском)
-
Распространённые заблуждения: Что работает (и что нет) для безопасности эпохи ИИ
-
Инструмент: Аудит безопасности сайта
-
Управление ИИ на работе: Что такое теневой ИИ (shadow AI)? (неодобренные ИИ-инструменты на работе и что делать)