готовность к эпохе ИИ
12 статей с этим тегом
Безопасность для эпохи ИИ: что закрыть прямо сейчас (приоритетный чек-лист)
ИИ в основном усиливает атаки на СУЩЕСТВУЮЩИЕ слабые места (незакрытые CVE, повторно используемые пароли, открытые секреты), а не изобретает новые — найденные автоматически, быстро, в масштабе. Поэтому лучшая подготовка — закрыть основы в правильном порядке: закрытие CVE + мониторинг зависимостей, искоренение повторного использования + MFA, удаление открытых секретов, минимум привилегий, сокращение публичной поверхности, логи/IOC, резервные копии.
Что работает (и что нет) для безопасности эпохи ИИ — почему по малым сайтам тоже бьют
Четыре мифа эпохи ИИ развенчаны: (1) слишком мал, чтобы стать целью → автоматизация убирает «человек выбирает вас»; (2) нужен особый новый механизм → основы по-прежнему побеждают; (3) продукт делает вас безопасными → проектирование профилактики раньше обнаружения; (4) код от ИИ быстрый, значит безопасный → он выходит с уязвимостями, проверяйте перед публикацией. Работают скучные основы в правильном порядке.
Фишинговое письмо подделало ваш собственный домен? Подделка против взлома и как это остановить
Подозрительное письмо, которое будто пришло с вашего домена, обычно не взлом, а поддельный From, потому что SMTP позволяет кому угодно вписать строку From. Чтение заголовков (Authentication-Results, Received, Reply-To) отличает взлом от подделки. Главная причина, почему оно доходит до входящих, — отсутствие политики DMARC. Исправьте это через SPF → DKIM → DMARC (p=none → reject).
Как правильно выбирать MFA: что значит «устойчивый к фишингу» и почему SMS слаб
MFA — это второй замок, чтобы один лишь утёкший пароль не пустил внутрь, но то, что вы включаете, меняет его силу по трём уровням. Коды SMS/email падают перед релейным фишингом и SIM-swap; приложения-аутентификаторы (TOTP) — средний уровень; passkey/аппаратные ключи (FIDO2) вообще нельзя предъявить поддельному сайту — это и есть устойчивость к фишингу. Высший приоритет: поставьте устойчивый к фишингу MFA на ключи от королевства (почта, домен, платежи). Хранение кодов восстановления и наличие резервного фактора завершают настройку.
Основы резервного копирования: правило 3-2-1 и план восстановления, переживающий программу-вымогатель
«У меня есть резервная копия» недостаточно — настоящей является только та копия, восстановление из которой вы проверили. Основа: правило 3-2-1 (три копии, два типа носителей, одна вне площадки). Против программы-вымогателя также нужна хотя бы одна «офлайновая или неизменяемая» копия — постоянно подключённая копия шифруется вместе с оригиналом. Облачная синхронизация — не резервная копия (она тиражирует и удаления, и шифрование). Версионирование и периодический тест восстановления завершают практику.
Безопасны ли менеджеры паролей? Как они работают, облако vs локально и как выбрать
Менеджер паролей безопаснее переиспользования или хранения открытым текстом. Ключ — шифрование с нулевым разглашением: ваш мастер-пароль расшифровывает хранилище только на вашем устройстве, провайдер держит только шифртекст, поэтому взлом провайдера не раскрывает ваши пароли. Настоящая единая точка — это ваш мастер-пароль плюс MFA на хранилище. Выбирайте облако (Bitwarden/1Password) или локально (KeePass) по применению.
Базовая безопасность для инди-разработчиков и малых операторов: весь стандартный набор
База — это не «всё одинаково важно». Порядок приоритета этого сайта: 1) ключи от королевства (MFA, домен, почта), 2) секреты и код, 3) само приложение, 4) патчи, обнаружение, восстановление. При конечном времени заполняйте сверху вниз. Большинство серьёзных взломов происходит не из-за новых атак, а из-за пробела в этом фундаменте.
Как по-настоящему закрывать CVE в зависимостях: сканировать, исправлять, изолировать и продолжать следить
Работа с уязвимостями не закончена, когда вы «исправили». Готово = 1) скан, 2) фикс, 3) изоляция/передача, 4) мониторинг. Пока не налажен мониторинг (ежедневное обнаружение изменений), это незавершённо — зависимости снова станут уязвимыми завтра. Идеальное исправление, которое перезаписывает следующий деплой, стоит ноль. Малые команды остаются в безопасности за счёт двух дисциплин: автоматического обнаружения изменений и «локально→push→деплой».
Установка и использование osv-scanner: найти CVE в ваших зависимостях
osv-scanner сканирует lock-файлы и контейнеры, выявляя CVE в ваших зависимостях, бесплатно. Здесь разобраны установка, запуск и интеграция в CI, плюс когда применять его vs npm/pnpm audit vs Dependabot. Взгляд этого сайта: правильный инструмент определяется ВАШЕЙ конфигурацией — берите osv-scanner для проектов с несколькими экосистемами или без GitHub, и встроенный pnpm audit для одного npm-дерева.
Оставили файл с секретом в публичной директории? Проверьте свой webroot
Всё, что в вашем webroot, любой может скачать по URL. Забытый JSON с токеном/учётными данными, .env или резервная копия означают мгновенную утечку — и если он пришёл из общего шаблона, дыра одна и та же у каждого сайта. Исправление: кладите в публичную директорию только то, чем можно публично делиться, держите секреты вне webroot с правами 600, а найдя один — проверьте каждый сайт и хост.
Не давайте root-ключи средам, которые можно скомпрометировать: наименьшие привилегии SSH-ключа
Регистрация root-ключа в продакшене из эфемерной, компрометируемой среды (под GPU, раннер CI, одноразовая ВМ) означает, что в тот миг, когда среда скомпрометирована, продакшен забирают с root. Исправление: никаких root-ключей в эфемерных средах; убирать ключи, когда не используются; если снова нужно — пользователь не root плюс ключ с ограничением команды, ограничивающий ключ одной операцией. Переиспользуемый ключ — ваш самый критичный актив; никогда не стройте конфигурацию «одна утечка — всё».
Код, написанный ИИ, привёл к утечке API-ключа и мошенническим списаниям — настоящей причиной была незакрытая уязвимость CVSS 10.0
Скачок счёта был симптомом. Настоящей причиной была незакрытая публичная RCE с CVSS 10.0. Обезличенный случай, сведённый к урокам по защите.