Фантомные учётные данные становятся новой статьёй расходов в облачном бюджете

Цифра, которая должна лежать на столе каждого руководителя платформенной команды в этом квартале, — 244. Именно столько нечеловеческих идентификаторов может накопить один разработчик, согласно исследованию архитектора безопасности Александра Краснова. Это соотношение превращает управление идентификацией из строки бюджета четвёртого квартала в предмет обсуждения на уровне совета директоров. Для любой команды, готовящейся подписать многолетний контракт с IAM-вендором или платформой AI-оркестрации, эта цифра меняет расчёты при выборе между разработкой и покупкой.

Цифры

Ситуация, о которой сообщило Dark Reading, выглядит обманчиво незначительной. Один AI-агент рабочего процесса, простаивавший 30 дней, внезапно начинает отправлять API-вызовы в нестандартное время. Это вызвало расследование аномалии, и Краснов, ведущий архитектор безопасности в Ducker Tech Consulting, потянул за нить. Под ней оказалась сеть фантомных учётных данных: токены, агенты и сервисные аккаунты, находящиеся за пределами традиционного периметра доверия, но сохраняющие способность к горизонтальному перемещению и эскалации привилегий.

Краснов отказался называть пострадавшую организацию, однако характер инцидента важнее личности клиента. Рассмотрим экономику с точки зрения злоумышленника. Две недели на проведение фишинговой кампании — или пять минут на поиск открытых токенов. По словам Краснова, рациональный злоумышленник выбирает пятиминутный путь. Это обрушивает кривую затрат на вторжение так, как большинство бюджетов безопасности не были рассчитаны учитывать.

Теперь добавим к этому цифру 244. Команда из 50 инженеров при наивном умножении теоретически отвечает за более чем 12 000 нечеловеческих идентификаторов. Большинство директоров по информационной безопасности, с которыми я общался, по-прежнему планируют бюджет управления идентификацией так, словно поверхность атаки масштабируется вместе со штатом. Это не так. Она масштабируется с произведением численности персонала и плотности NHI, а эта плотность — неуправляемая функция от того, сколько AI-агентов, CI/CD-пайплайнов и SaaS-интеграций команда приняла на вооружение с 2024 года.

При неформальном тестировании своего нового инструмента с открытым исходным кодом NHI Hound Краснов работал с компаниями численностью до 2 000 сотрудников. Заявленный горизонт очистки для таких организаций — от шести до девяти месяцев. Это не спринт. Это полное финансовое полугодие, посвящённое распутыванию доверительных отношений, созданных по умолчанию, которые никто не проверял. Выше 2 000 сотрудников, по словам Краснова, граф становится «невероятно, невероятно запутанным», а текущий вывод инструмента рискует стать слишком зашумлённым для принятия решений. Таким образом, полезное окно для проактивной очистки с помощью готовящегося к выходу инструментария узко: команды среднего сегмента, достаточно дисциплинированные, чтобы потратить на это два квартала, — до того как они пересекут порог сложности в 2 000 сотрудников.

Что действительно нового

Риск нечеловеческих идентификаторов — не новая категория. Сервисные аккаунты были головной болью для соответствия требованиям ещё со времён SOX, и каждый облачный IAM-вендор уже десять лет продаёт «минимальные привилегии» как ценностное предложение. По-настоящему новым в этом цикле является сочетание трёх факторов.

Первый: AI-агент теперь сам является держателем учётных данных. Триггерный инцидент был вызван не утечкой с ноутбука разработчика и не неправильно настроенным S3-бакетом. Это был агент рабочего процесса, 30 дней простоявший в тишине, а затем проснувшийся. Это принципиально новый сценарий сбоя. Агенты создаются продуктовыми командами, выпускающими функции, а не IAM-командами, проверяющими запросы доступа. Путь доверия возникает как побочный эффект разработки, и никто не отвечает за его прекращение.

Второй: цепочка поворотов теперь ведёт напрямую к провайдерам идентификации. Сессия Краснова на Black Hat, включённая в онлайн-программу в конце Black Hat USA 2026, планирует продемонстрировать, как один утёкший ключ превращается в полную компрометацию облака путём злоупотребления цепочками доверия к провайдерам вроде Okta. Именно это должно напугать каждого вице-президента по инжинирингу, считавшего инвестицию в SSO границей безопасности. Если сам IdP достижим через фантомный NHI, вся концепция нулевого доверия сводится к тому, что позволяет токен самого слабого агента.

Третий: инструментарий наконец догоняет инвентаризацию. NHI Hound собирает данные об идентификаторах из Okta, GitHub и облачных IAM-платформ, классифицирует идентификаторы по уровням критичности доверия и отмечает то, что Краснов называет «критическими» условиями — когда низкодоверенный идентификатор фактически действует как суперадминистратор из-за неявных доверительных отношений, которые никто явно не определял. Последняя фраза — ключевая. Риск — не те права, которые вы предоставили. Это права, возникшие из комбинаций разрешений между системами, которые ни один администратор никогда не санкционировал как единое целое. Это чётко соответствует техникам MITRE ATT&CK в части валидных аккаунтов и облачных поворотов, однако проблема обнаружения всегда опережала инструментарий детектирования.

Что уже заложено в бюджеты команд безопасности

Большинство зрелых команд безопасности уже знают, что разрастание NHI — проблема. Тезисы в духе Gartner циркулируют уже восемнадцать месяцев, и у каждого вендора на RSA 2026 на баннере стенда красовался термин «нечеловеческая идентификация». Что уже учтено: общая тревога, осознание того, что агенты размножаются быстрее, чем люди, и ощущение, что CIEM-инструментарий от крупных облачных вендоров неполон.

Что не учтено — и здесь я бы поспорил с рыночным консенсусом — так это операционные затраты на устранение последствий. Шесть-девять месяцев целенаправленной работы по очистке в компании с менее чем 2 000 сотрудников — это реальная цифра. Это решение о найме. Для финтех-компании на серии B, работающей в режиме экономии, это либо новый сотрудник в платформенную команду, либо отложенный продуктовый роадмап. CFO почувствует это раньше, чем CISO, потому что именно CFO подписывает заявку на найм платформенного инженера.

Также не учтена привязка к конкретному вендору. Если NHI Hound (или любой аналогичный инструмент) становится источником истины для вашего графа идентификации, вы только что добавили ещё одну зависимость, охватывающую Okta, GitHub и ваш облачный IAM. Пока инструмент имеет открытый исходный код и разворачивается самостоятельно — это нормально. Разговор становится совершенно иным в тот момент, когда кто-то приобретает проект или предлагает его управляемую версию. Команды, оценивающие эту категорию, должны моделировать трёхлетние затраты, а не стоимость пилота.

Контрарный взгляд

Консенсусная интерпретация этой истории такова: каждая организация должна немедленно провести упражнение по обнаружению NHI. Я бы возразил обратное для конкретного сегмента: предприятиям свыше 2 000 сотрудников, вероятно, стоит подождать.

Сам Краснов говорит, что при таком масштабе текущий вывод становится подавляющим. «Слишком много беспорядка и слишком много шума» — его слова, и они указывают на реальную динамику. Запуск инструмента обнаружения, выявляющего тысячи критических доверительных условий без операционной возможности их устранить, создаёт юридические и регуляторные риски, которых у вас прежде не было. Как только ваш генеральный юрисконсульт узнает, что у вас есть задокументированный список из 4 000 критических рисков идентификации, расчёт вокруг раскрытия информации об утечках и стандартов разумной осторожности изменится. Есть весомый аргумент в пользу ожидания — пока инструментарий не созреет, визуализация не улучшится и не появятся плейбуки по устранению, — прежде чем создавать артефакт, который делает вас ответственным.

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

Вопрос о заинтересованных сторонах

Руководитель платформы в любой компании на серии B или C, использующей более нескольких AI-агентов, должен на этой неделе спросить своего CFO: следующая строка бюджета на управление идентификацией — это расходы на инструментарий или на найм? Это разные ответы с разными трёхлетними кривыми затрат. Путь с открытым исходным кодом занимает время платформенного инженера на шесть-девять месяцев. Путь с вендором обходится дешевле авансом и дороже впоследствии, когда инструмент становится несущим. Ни один из вариантов не бесплатен, и предположение, что это проект, умещающийся в существующий IAM-бюджет, — та ошибка, которая всплывает в постмортеме.

Ключевые выводы

• Показатель 244 NHI на одного разработчика означает, что поверхность атаки идентификации масштабируется с произведением численности персонала и плотности агентов, а не только с численностью персонала. Планируйте бюджет соответственно.
• Злоумышленники теперь выбирают пятиминутный поиск токенов вместо двухнедельной фишинговой кампании. Любая модель угроз, по-прежнему считающая социальную инженерию основным вектором, устарела.
• Критический риск — не явные разрешения, а возникающая суперадминистративная способность из цепочек доверительных отношений, которые ни один администратор не санкционировал как единое целое.
• Шесть-девять месяцев целенаправленной очистки реалистичны для организаций с менее чем 2 000 сотрудников. Выше этого порога текущий инструментарий производит больше шума, чем сигнала, и ожидание может быть оправданным.
• Команды, оценивающие инструменты обнаружения NHI, должны теперь спрашивать, кто отвечает за устранение, а не только за обнаружение, и создаёт ли вывод юридические риски, с которыми они не готовы работать.