23 июля 2026 года The Hacker News обратил внимание на риск, о котором в IAM и cloud security говорят заметно реже, чем о краже учёток: поддельные машинные идентичности. Для российских команд это неприятный сигнал: если в компании уже тысячи сервисных аккаунтов, токенов и агентских сущностей, атакующему всё чаще выгоднее не угонять существующую запись, а quietly добавить в зоопарк ещё одну, очень похожую на легитимную.
Как пишет The Hacker News, логика тут та же, что и в синтетическом мошенничестве с человеческими данными. Вместо кражи реальной личности злоумышленник собирает новую из правдоподобных фрагментов: немного настоящих атрибутов, немного выдумки, и на выходе получается сущность, за которой никто не следит. В мире non-human identities, или NHI, это означает сервисный аккаунт, машинную учётку или другую техническую идентичность, которой вообще не должно было существовать, но она выглядит так, будто её кто-то штатно завёл.
В этом и проблема. Украденная учётка хотя бы связана с реальным владельцем: кто-то может заметить подозрительный вход, странное использование секрета или утечку в дарквеб. У фальшивой машинной идентичности владельца нет по определению. Она не вызывает у человека вопроса «почему от моего имени что-то происходит», а у инфраструктуры не вызывает паники, потому что снаружи выглядит вполне штатно: правильный домен, знакомый шаблон имени, правдоподобные метаданные, набор разрешений как у соседних сервисов. Для администратора, который смотрит на каталог из десятков тысяч записей, это просто ещё одна рутинная сущность.
Издание выделяет несколько способов, которыми строятся такие машинные идентичности. Первый и самый прямолинейный: злоумышленник, уже получивший доступ в среду, создаёт новый service account, похожий на существующие. Не ломает старый, не ворует пароль, а добавляет ещё один объект с привычным названием и standing access. Второй сценарий связан с DCShadow: атакующий с правами администратора домена временно регистрирует поддельный контроллер домена, чтобы вредоносные изменения выглядели как легитимная репликация от доверенного узла. Это уже не подделка одной учётки, а подмена самого источника доверия. Третий вариант — shadow credentials, когда к существующему объекту незаметно добавляют контролируемый злоумышленником материал для аутентификации. Снаружи объект тот же, но фактически в нём появилась встроенная лазейка.
Важно не путать это с synthetic persona, термином, который NHI Management Group использует для поддельных профилей, созданных ради обмана людей через социнженерию. Там цель — выглядеть убедительно для человека. Здесь наоборот: поддельная сущность живёт внутри систем, получает реальные права и никому не принадлежит. Если synthetic persona играет в фальшивого коллегу в мессенджере, то фальшивая машинная идентичность играет в обычный инфраструктурный компонент. И именно поэтому риск долго оставался на периферии внимания: защитные практики строились вокруг компрометации существующих секретов, а не вокруг самого факта, что кто-то сумел незаметно «родить» новую сущность внутри контура.
Контекст для этого подхода у злоумышленников отличный. Во многих компаниях машинные идентичности уже давно обогнали людей по количеству. Каждый новый микросервис, CI/CD-пайплайн, облачная функция, контейнер, интеграция или AI-агент тянет за собой аккаунты, токены, сертификаты и роли. Учёт таких объектов обычно отстаёт от темпов разработки, особенно если команды живут в нескольких облаках и половина доступов создаётся автоматически. На таком фоне ещё одна машинная идентичность не выглядит аномалией. Скорее наоборот: аномалией становится попытка всерьёз ответить на вопрос, кто именно владеет этой сущностью, зачем она создана и когда должна исчезнуть.
Отдельно The Hacker News подчёркивает, почему тема становится особенно актуальной на волне agentic AI. Если раньше злоумышленнику нужно было вручную проникнуть в систему, завести новую учётку и выдать ей права, то теперь всё больше платформ сами создают идентичности в фоне. AI-агенты динамически получают креды во время выполнения и всё чаще способны запускать других агентов со своими собственными идентичностями. Граница между «система сама легитимно создала новую техническую сущность» и «внутри среды появилась хорошо замаскированная подделка» начинает размываться. Для атакующего это подарок: шум инфраструктуры делает маскировку дешевле, а проверку происхождения каждой записи — дороже.
Для разработчиков и платформенных команд вывод довольно приземлённый. Если учёт машинных сущностей устроен по принципу «оно как-то появилось и вроде работает», то разговоры о zero trust быстро превращаются в декорацию. Защита, по сути, сводится не к охоте на каждый фальшивый аккаунт вручную, а к нормальной гигиене управления идентичностями. У каждой NHI должен быть назначенный человек-владелец, понятная цель и срок жизни. Секреты нужно хранить централизованно и регулярно ротировать, чтобы внедрённые shadow credentials не жили годами. Права доступа — сжимать до минимума и по возможности выдавать по модели Just-in-Time, чтобы даже удачно созданная подделка не наследовала бессрочный административный доступ.
Ещё один практический вывод касается детекта. Если доверие к машинной сущности устанавливается один раз в момент provisioning, дальше поддельная запись может спокойно существовать месяцами. Поэтому верификация должна быть непрерывной: не только «кто ты по имени», но и «как ты себя ведёшь». Для SOC и IAM-команд это означает смещение фокуса с разовых проверок на поведенческий контроль: какие секреты использует сущность, откуда аутентифицируется, какие роли запрашивает, не выбивается ли жизненный цикл объекта из нормы. Иначе машинные идентичности превращаются в идеальный канал для тихого накопления привилегий.
Сейчас главный вопрос уже не в том, возможна ли подделка машинной идентичности, а в том, сколько таких сущностей современная инфраструктура готова проглотить без малейшего сопротивления. Чем активнее компании автоматизируют создание агентов, сервисов и доступов, тем ценнее становится не скорость выпуска новых идентичностей, а способность доказать происхождение каждой из них.