Почему старая модель периметра больше не описывает реальную атаку Мы привыкли думать о кибератаке примерно так: внешний злоумышленник → эксплойт → malware → lateral movement → данные. Но всё чаще современная атака выглядит иначе: легитимная учётная запись → легитимный токен → легитимный API → легитимное SaaS-приложение → нелегитимное действие. И именно поэтому классической схемы «MFA + EDR + firewall» уже недостаточно. CrowdStrike в Global Threat Report 2026 сообщает, что 82% обнаружений в 2025 году были malware- free. Среднее eCrime breakout time сократилось до 29 минут, а самый быстрый зафиксированный breakout занял 27 секунд. Это означает, что злоумышленнику всё чаще не требуется долго «ломать» периметр: он использует доверенные идентичности, облачные сервисы, SaaS и легитимные инструменты. Verizon в DBIR 2026 фиксирует ещё один важный сдвиг: эксплуатация уязвимостей впервые стала главным начальным вектором и связана примерно с 31% подтверждённых breaches. Одновременно доля инцидентов с участием третьих сторон выросла до 48%. Защищать нужно не только endpoint. Защищать нужно границы доверия. API может корректно проверить подпись JWT и всё равно быть уязвимым. Например, запрос может выглядеть полностью «валидным»: подпись корректна, срок жизни токена не истёк, пользователь аутентифицирован. Но backend при этом не проверяет audience, scope, role, tenant или ownership конкретного объекта. В результате система принимает технически корректный запрос к данным или функции, к которым пользователь доступа иметь не должен. Это уже не проблема authentication. Это проблема authorization. Именно здесь появляются BOLA/IDOR, BFLA, privilege escalation и cross-service token replay. Доверенная идентичность — не то же самое, что доверенное действие То же самое происходит в SaaS и cloud. Атакующему необязательно устанавливать malware, если он получил действующую сессию, OAuth grant или API token. Для системы такой запрос может выглядеть абсолютно нормальным. Проблема в том, что инфраструктура традиционно отвечает на вопрос «кто ты?», а реальная безопасность требует каждый раз отвечать ещё на несколько вопросов: что именно тебе разрешено, в каком контексте, для какого объекта, из какой среды и почему это действие сейчас допустимо? Практическая модель защиты  phishing-resistant authentication: FIDO2/passkeys вместо надежды только на OTP;  короткоживущие и, где возможно, device-bound sessions;  строгая проверка iss / aud / exp / nbf / scope / role;  server-side authorization для каждого чувствительного объекта и функции;  negative authorization testing: проверять не только разрешённые сценарии, но и всё, что система обязана запрещать;  минимальные privileges для CI/CD, SaaS и service accounts;  pinning dependencies/actions, SBOM и контроль software supply chain;  мониторинг identity, SaaS, cloud и API telemetry, а не только endpoint events; внешние действия: AI здесь не создаёт совершенно новый класс атак. Он ускоряет уже существующие техники. CrowdStrike в 2026 году фиксирует рост активности AI-enabled adversaries на 89% год к году. Более чем в 90 организациях наблюдалось злоупотребление легитимными AI-инструментами для генерации вредоносных команд и кражи чувствительных данных. Для защитника это означает ещё более короткое окно между первичным доступом и реальным ущербом. Поэтому вопрос, который сегодня стоит задавать при аудите системы, звучит не: «Можно ли войти без пароля?» а: «Что сможет сделать атакующий после того, как система уже решила ему доверять?» И вот этот вопрос обычно оказывается намного интереснее.