Мы всё ещё часто говорим, что злоумышленник “проник в инфраструктуру”. Но всё чаще он никуда не проникает — он входит.

Под действующей учётной записью. С валидным токеном. Через штатный интерфейс. Иногда даже с корректно подтверждённым MFA-запросом.

После этого технические действия атакующего могут долго выглядеть как обычная работа сотрудника или администратора.

Поэтому я считаю, что identity уже стала новым периметром бизнеса.

Не сеть. Не офис. Не конкретное облако.

Периметр сегодня формируется вокруг ответа на четыре вопроса:

Кто действует?
От чьего имени?
Какие полномочия использует?
Соответствует ли действие текущему контексту?

Verizon указывает, что злоупотребление credentials оставалось ведущим способом первоначального доступа в подтверждённых утечках. Mandiant также зафиксировала рост использования украденных учётных данных, которые вышли на второе место среди первоначальных векторов в расследованиях компании. (Verizon⁠)

Но компании нередко отвечают на этот риск фрагментарно: — IAM внедряет одна команда; — PAM — другая; — MFA подключают только к части систем; — IGA превращается в автоматизацию заявок; — сервисные аккаунты остаются вне полноценного контроля; — SOC получает события, но не всегда понимает бизнес-контекст identity.

Формально технологии есть. Целостного управления доверием нет.

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

Зрелая identity-программа должна отвечать не только на вопрос «может ли пользователь войти?».

Она должна определять:

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

Особенно важным это становится с появлением AI-агентов.

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

На мой взгляд, это серьёзная архитектурная ошибка.

Prompt injection опасен не сам по себе. Масштаб ущерба определяют доступные агенту identity, инструменты и данные.

Поэтому до промышленного запуска AI-агента необходимо определить его владельца, отдельную identity, минимальный набор полномочий, срок доступа, журналирование и операции, требующие подтверждения человеком. Международные практики уже развиваются именно в этом направлении: Microsoft описывает governance agent identities, а OWASP включает identity и tool access в поверхность атаки agentic-систем. (Microsoft Learn⁠)

Я бы оценивал зрелость identity security не по количеству подключённых систем и выданных MFA-токенов.

Гораздо важнее другое:

— знает ли компания все человеческие и машинные identity; — есть ли бизнес-основание для каждого критичного доступа; — уменьшается ли количество постоянных привилегий; — отзываются ли сессии и токены вместе с учётной записью; — включены ли подрядчики, SaaS и AI-агенты в единый lifecycle; — способен ли SOC увидеть за событием реальную роль и уровень риска.

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

Как вы считаете: в большинстве компаний identity security уже стала самостоятельной программой управления риском — или пока остаётся набором проектов IAM, MFA и PAM?