Безопасность изменилась. Но забытые основы всё ещё ломают её

Кибербезопасность за последние два десятилетия изменилась почти до неузнаваемости. Организации перешли от офисных сетей и периметровых firewall к SaaS, public cloud, удалённой работе, identity-платформам, API, мобильным устройствам и рабочим процессам с поддержкой AI. Изменились и атакующие: phishing стал индустриальным, ransomware превратился в бизнес-модель, а automation снизила стоимость разведки и эксплуатации уязвимостей.

Но недавний ретроспективный материал Dark Reading делает важное практическое наблюдение для команд безопасности: модель изменилась, однако многие провалы по-прежнему возникают из-за забытых основ. Индустрия говорит о zero trust, assume-breach, cloud posture, identity threat detection и AI-driven defense. Но реальные инциденты часто начинаются со старых учётных записей, открытых наружу сервисов, слабого покрытия MFA, непропатченных edge-систем, избыточных прав или логов, которые никто не просматривает.

Это не противоречие. Это главный урок. Современные сбои безопасности часто происходят тогда, когда старые операционные слабости переносятся в новые архитектуры.

От доверия к периметру к реальности assume-breach#

Многие годы организации рассматривали сетевой периметр как главную границу безопасности. Логика была простой: держать атакующих снаружи, а внутренние системы считать доверенными. Firewall, VPN, email gateways и endpoint-контроли поддерживали эту модель.

Эти средства всё ещё важны. Проблема в том, что допущение о доверии больше не соответствует тому, как организации реально работают.

Современные среды распределены между cloud providers, SaaS-платформами, домашними сетями, устройствами подрядчиков, mobile endpoints, identity providers, developer tools и third-party integrations. Пользователь может аутентифицироваться из личной сети в SaaS-панель, которая управляет production-данными, хранящимися в cloud-среде, за которую отвечает другая команда. В таком мире «внутри» и «снаружи» уже не являются аккуратными категориями.

Подход assume-breach начинается с другой базовой установки: в какой-то момент учётная запись, устройство, token, API key или workload могут быть скомпрометированы. Вопрос безопасности становится другим: насколько далеко сможет продвинуться атакующий, как быстро защитники это заметят и насколько чисто организация сможет восстановиться.

Этот сдвиг меняет приоритеты. Командам безопасности нужно задавать практические вопросы:

• Что произойдёт, если один почтовый ящик сотрудника будет скомпрометирован?
• Может ли обычный пользователь добраться до чувствительных внутренних систем?
• Отделены ли privileged accounts от повседневных рабочих учётных записей?
• Являются ли cloud permissions узкими, регулярно проверяемыми и логируемыми?
• Могут ли атакующие создавать новые access tokens без срабатывания alert?
• Изолированы ли backups от той среды, которую они должны восстанавливать?
• Могут ли incident responders доверять логам, которые им понадобятся во время расследования?

Именно здесь современные модели безопасности становятся не теорией, а операционной практикой. Assume-breach — не лозунг. Он требует least privilege, segmentation, сильных identity controls, detection engineering, протестированных backups и отработанной incident response-практики.

Новые технологии часто усиливают старые слабости#

AI, cloud adoption и remote work — реальные изменения. Они влияют на поведение атакующих, рабочие процессы защитников и скорость операций. Но они часто вскрывают те же базовые проблемы: плохой inventory, слабое governance, непоследовательный patching, избыточное доверие и ограниченный monitoring.

AI меняет скорость, но не отменяет проверку#

AI может помочь атакующим быстрее готовить убедительные сообщения, автоматизировать части reconnaissance, адаптировать социальную инженерию и масштабировать попытки эксплуатации. Но это не отменяет старых защитных вопросов: кто имеет доступ, какие действия разрешены, какие изменения логируются, какие сигналы проверяются и какие процедуры восстановления уже протестированы.

Если в организации нет нормального учёта активов, слабая дисциплина access review и нерегулярное обновление exposed systems, AI лишь ускорит использование этих пробелов. Технология меняет темп, но не заменяет необходимость validation, контроля прав и проверки предположений.

Cloud увеличивает масштаб ошибок#

Cloud даёт скорость и гибкость, но также делает ошибки более масштабируемыми. Неверно настроенный storage, слишком широкая роль, забытый access key или service account без владельца могут открыть путь к данным и системам, которые раньше были отделены физической инфраструктурой и более медленными процессами изменений.

Практические проверки остаются приземлёнными:

• Есть ли актуальный inventory cloud-активов и владельцев?
• Проверяются ли permissions на избыточность?
• Логируются ли administrative actions и обращения к sensitive data?
• Есть ли alert на создание новых keys, tokens, users и privileged roles?
• Удаляются ли неиспользуемые accounts и integrations?

Cloud security не сводится к включению очередного продукта. Она требует операционной дисциплины: знать, что развёрнуто, кто этим владеет, какие права выданы и какие события должны считаться подозрительными.

Remote work расширяет поверхность идентичности#

Удалённая работа сделала identity главным периметром. VPN и endpoint controls по-прежнему важны, но доступ всё чаще начинается с аутентификации в identity provider или SaaS-сервисе. Поэтому слабое MFA coverage, неотключённые бывшие сотрудники, устаревшие contractor accounts и overly permissive groups становятся прямыми путями к инциденту.

Здесь важны простые проверки:

• Включён ли MFA для всех критичных приложений, а не только для части пользователей?
• Отслеживаются ли suspicious logins, impossible travel и изменения MFA-настроек?
• Удаляются или блокируются ли accounts при увольнении и завершении контракта?
• Разделены ли admin accounts и обычные user accounts?
• Проверяются ли access groups и inherited permissions?

Почему neglected basics всё ещё ломают защиту#

Современные атаки часто выглядят сложными в отчётах, но их начальная точка бывает банальной. Скомпрометированная почта, открытый management interface, непропатченный edge device, leaked API key, слабая MFA-политика или сервисная учётная запись с чрезмерными правами могут дать атакующему первую опору.

Дальше включается цепочка: разведка, расширение доступа, lateral movement, сбор credentials, отключение защитных механизмов, exfiltration или запуск ransomware. На каждом этапе продвинутые инструменты могут играть роль, но возможность двигаться обычно появляется из-за недостатка базовой дисциплины.

Поэтому практическая программа безопасности должна включать не только новые инициативы, но и постоянную проверку основ:

• Inventory: организация знает свои systems, users, devices, cloud resources, APIs и third-party integrations.
• Patch management: особенно для internet-facing и edge systems.
• Identity hygiene: MFA, удаление stale accounts, разделение privileged access и регулярный access review.
• Least privilege: права выдаются минимально необходимыми и пересматриваются.
• Logging and detection: важные действия логируются, alerts проверяются, а логи доступны incident responders.
• Backup resilience: backups изолированы, защищены и реально тестируются.
• Incident response: команды не просто имеют план, а тренируются по нему.

Практический вывод для команд безопасности#

Главный вывод не в том, что новые технологии не важны. Они важны. Zero trust, cloud posture, identity threat detection, AI-assisted defense и modern endpoint telemetry могут существенно повысить устойчивость. Но они не компенсируют отсутствующие основы.

Если организация внедряет современные инструменты поверх старых проблем — неизвестных активов, неуправляемых прав, непросматриваемых логов, слабого MFA и непротестированных backups, — она получает более сложную, но не обязательно более безопасную среду.

Хорошая проверка для руководителей и security teams проста: выбрать один реалистичный сценарий компрометации и пройти его до конца. Например: один сотрудник попался на phishing, один API key утёк, один cloud admin token украден, один edge device эксплуатирован. Затем спросить:

• Как быстро мы это заметим?
• Какие системы окажутся достижимы?
• Какие права можно будет расширить?
• Какие логи подтвердят действия атакующего?
• Какие controls остановят движение дальше?
• Как мы восстановимся, если часть среды будет повреждена?

Такие упражнения показывают, где современная архитектура реально устойчива, а где старые слабости просто переехали в новый технологический стек.

Кибербезопасность действительно изменилась. Но организации по-прежнему чаще всего ломаются там, где базовые процессы были оставлены без внимания.