Identity — новый периметр: почему злоумышленникам проще войти, чем взломать

Долгое время корпоративная безопасность строилась вокруг понятной модели: есть внутренняя инфраструктура, есть внешний мир, а между ними — защищённый периметр.

Сегодня эта схема существует скорее на архитектурных диаграммах, чем в реальности.

Сотрудники работают удалённо. Бизнес-процессы распределены между SaaS-сервисами. Разработчики используют облачные платформы, CI/CD, внешние репозитории и десятки интеграций. Машинных учётных записей, API-ключей и сервисных токенов часто больше, чем людей. К этой системе добавляются AI-ассистенты и автономные агенты, которым тоже нужен доступ к данным и корпоративным инструментам.

В результате главным вопросом безопасности становится уже не только «откуда пришёл запрос?», а:

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

Моя позиция проста: identity security должна стать ядром программы информационной безопасности. IAM, PAM, MFA и IGA нельзя рассматривать как набор изолированных инфраструктурных проектов. Вместе они образуют систему управления цифровым доверием компании.

Атаковать учётные записи экономически выгоднее, чем преодолевать многоуровневую защиту инфраструктуры.

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

Именно поэтому такие атаки особенно опасны: с технической точки зрения многие действия выглядят нормально.

По данным Verizon 2025 Data Breach Investigations Report, злоупотребление учётными данными оставалось наиболее распространённым вектором первоначального доступа и встречалось в 22% подтверждённых утечек. Mandiant также зафиксировала рост использования украденных учётных данных: в расследованиях компании они стали вторым по распространённости первоначальным вектором и составили 16% случаев. (Verizon⁠)

Microsoft сообщает, что 97% наблюдавшихся identity-атак были связаны с password spraying. Одновременно растёт рынок infostealer-вредоносов, которые собирают из браузеров пароли, cookies и другие данные, позволяющие захватывать уже созданные сессии. (Microsoft⁠)

Это меняет саму логику нападения.

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

Компании часто сводят identity security к паролям и MFA. Это слишком узкий взгляд.

Злоумышленнику могут быть интересны:

Поэтому задача не сводится к тому, чтобы «лучше проверять пароль». Нужно управлять полным жизненным циклом доступа: от появления identity до её удаления, включая выдачу полномочий, изменение ролей, контроль привилегий, анализ поведения и отзыв доступа.

NIST в модели Zero Trust предлагает переносить фокус со статических сетевых сегментов на защиту пользователей, активов и ресурсов. Сетевое местоположение само по себе больше не должно считаться достаточным основанием для доверия. (csrc.nist.gov⁠)

Слабость многих программ ИБ состоит не в отсутствии технологий, а в их разобщённости.

IAM знает, кто вошёл в систему.

MFA подтверждает, что пользователь предъявил необходимые факторы.

IGA отвечает, почему ему выданы права и кто их согласовал.

PAM контролирует использование критичных полномочий.

SIEM, UEBA и identity threat detection анализируют, соответствует ли поведение ожидаемому контексту.

По отдельности эти механизмы закрывают только фрагменты риска. Зрелость появляется тогда, когда они объединены общими политиками, данными и процессами принятия решений.

Например, рискованный вход должен не просто создать событие в SIEM. Он может автоматически повысить уровень аутентификации, ограничить сессию, заблокировать привилегированную операцию или запустить переоценку доступа.

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

Увольнение должно отзывать не только доменную учётную запись, но также активные токены, доступы к SaaS, API-ключи, привилегии, сертификаты и связанные делегирования.

Identity security — это не экран входа. Это непрерывный цикл проверки доверия.

Компания должна видеть не только сотрудников, но и подрядчиков, сервисные аккаунты, приложения, роботов, интеграции и AI-агентов.

Для каждой identity должны быть определены:

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

Постоянные привилегии удобны для пользователей и опасны для бизнеса.

Для критичных операций предпочтительны:

Цель — уменьшить не количество администраторов на бумаге, а время, в течение которого атакующий способен воспользоваться привилегиями.

Начинать нужно с:

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

Ключевые процессы joiner–mover–leaver должны быть автоматизированы и связаны с HR-событиями.

Особенно важен этап mover: при переходе сотрудника на новую роль компании часто добавляют права, но не удаляют старые. Так возникает privilege creep — постепенное накопление полномочий, не соответствующих текущим обязанностям.

SOC должен видеть не только IP-адрес и устройство, но также:

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

AI-агенты не должны становиться ещё одним классом shadow IT.

До предоставления доступа необходимо определить:

Я не считаю, что identity security — это очередное направление внутри инфраструктурной безопасности.

Это управляющий слой цифрового бизнеса.

Через identity компания определяет, кто может принимать решения, читать данные, изменять системы, запускать процессы и действовать от имени организации.

Поэтому IAM, PAM, MFA и IGA должны проектироваться не как четыре независимых внедрения, а как единая программа, связанная с архитектурой, HR-процессами, разработкой, облаками, SOC, управлением рисками и внедрением AI.

Главная ошибка — измерять зрелость количеством подключённых систем или купленных лицензий.

Правильные вопросы звучат иначе:

Подписывайтесь на мой ТГ канал: @ib_decisions