Non-Human Identities: масштаб проблемы и риски для бизнеса
Соотношение NHI к человеческим пользователям достигает 50:1. Каждый под, функция и агент — это потенциальная точка входа для атаки. Разбираем, почему классическое управление учётными данными здесь не работает.
Non-Human Identities: масштаб проблемы и риски для бизнеса
Что такое NHI
Non-Human Identities — это учётные записи и криптографические идентичности, которыми пользуются не люди, а программы, сервисы, устройства и агенты. К ним относятся:
- сервисные аккаунты и учётные записи приложений;
- рабочие нагрузки Kubernetes и CI/CD-конвейеры;
- облачные функции и serverless-задачи;
- API-ключи, OAuth-клиенты и сертификаты;
- AI-агенты и их подчинённые компоненты.
Каждый такой субъект нуждается в аутентификации, авторизации и аудите. Проблема в том, что управление ими исторически было вторичным по отношению к управлению сотрудниками.
Масштаб, который сложно представить
Аналитики оценивают соотношение NHI к человеческим идентичностям в корпоративных средах как 50:1. В крупных организациях речь идёт о миллионах сущностей, каждая из которых имеет права, токены и историю доступа.
| Источник NHI | Типичные примеры | Скорость роста |
|---|---|---|
| Облачная инфраструктура | IAM-роли, Lambda, VMs | Высокая |
| Kubernetes | Service accounts, pods | Очень высокая |
| CI/CD | Pipeline tokens, deploy keys | Высокая |
| SaaS-интеграции | OAuth-клиенты, webhooks | Средняя |
| AI-агенты | Агенты оркестрации, инструменты | Экспоненциальная |
AI-агенты добавляют новое измерение. Они не просто используют статичные учётные данные: они создают подзадачи, делегируют полномочия другим агентам и существуют в течение секунд. Это делает традиционный жизненный цикл учётной записи неприменимым.
Почему NHI так рискованны
Управление учётными данными выходит из-под контроля
80% инцидентов с NHI связаны с ошибками управления секретами: устаревшие токены, неотозванные ключи, учётные данные в репозиториях. В отличие от человеческих сотрудников, NHI не увольняются, не меняют пароли и не сообщают о подозрительной активности.
Избыточные привилегии становятся нормой
Чтобы ускорить разработку, команды часто выдают сервисным аккаунтам широкие права. Со временем эти права забывают сузить. Агенты, работающие с такими токенами, получают доступ к данным, которые им не нужны для конкретной задачи.
Жизненный цикл не отслеживается
Эфемерные агенты и функции появляются и исчезают автоматически. Если их идентичности не создаются и не удаляются централизованно, в инфраструктуре остаётся «тёмная материя» — живые токены от мёртвых сервисов.
Слепые зоны в аудите
Когда агент действует от имени человека или другого агента, стандартные журналы часто фиксируют только последнее звено. Цепочка делегирования теряется, и расследование инцидента превращается в детектив.
Каскадная компрометация
Агенты работают в цепочках. Если скомпрометирован оркестратор, злоумышленник получает доступ ко всем делегированным агентам и их ресурсам. Без краткосрочных токенов и явного контроля делегирования радиус атаки непредсказуем.
Последствия для бизнеса
Риски NHI транслируются в конкретные потери:
| Риск | Возможное последствие | Пример |
|---|---|---|
| Утечка данных | Штрафы, репутационный ущерб | Украденный API-ключ к CRM |
| Простой системы | Потеря выручки | Компрометация CI/CD и внесение вредоносного кода |
| Несоответствие требованиям | Штрафы регуляторов | Отсутствие аудита действий агентов |
| Рост операционных расходов | Ручное управление миллионами токенов | Увеличение команды безопасности |
В условиях агентных систем эти риски растут не линейно, а экспоненциально. Каждый новый агент увеличивает поверхность атаки и добавляет звенья в цепочку доверия.
Что меняет Agentic IAM
Агенто-центричный подход решает проблему NHI на архитектурном уровне:
- Краткосрочные идентичности. SPIFFE/SPIRE выдают токены с TTL в минуты и автоматической ротацией.
- JIT-провижининг. Идентичность создаётся только на время выполнения задачи и явно отзывается после.
- Неизменяемый контекст. Транзакционные токены передают авторизационный контекст через всю цепочку.
- Минимальные привилегии. Область действия токена привязана к намерению, а не к роли.
- Полный аудит. Каждое делегирование логируется и может быть верифицировано криптографически.
Рекомендации для руководителей
Управление NHI — это не только задача ИБ-команды. На уровне бизнеса важно принять три решения:
- Признать NHI стратегическим активом. Учитывать их при планировании безопасности, compliance и архитектуры.
- Внедрить стандарты идентичности рабочих нагрузок. SPIFFE/SPIRE, WIMSE и транзакционные токены должны стать частью технической дорожной карты.
- Встроить аудит в агентные процессы. Любое действие агента должно быть связано с принципалом, актором и контекстом.
Почему NHI размножаются быстрее, чем управляются
Рост NHI ускоряется по объективным причинам. Облачные платформы создают виртуальные машины и функции по запросу. Kubernetes запускает и уничтожает поды каждую секунду. CI/CD-конвейеры генерируют временные токены для каждого деплоя. AI-агенты добавляют ещё один уровень: они порождают подзадачи, каждая из которых может получать собственную идентичность.
При этом процессы управления идентичностью остаются человеко-ориентированными. Заявки на доступ, пересмотр ролей, отзыв прав — всё это рассчитано на дни и недели. В результате NHI создаются автоматически, а управляются вручную. Этот разрыв и порождает основные риски.
Shadow identities: невидимый риск
Не все NHI видны централизованной службе безопасности. Shadow identities возникают, когда команды:
- используют личные API-ключи сотрудников в автоматизации;
- создают сервисные аккаунты в облачных консолях без согласования;
- хранят секреты в репозиториях и конфигурационных файлах;
- подключают SaaS-интеграции через неучтённые OAuth-клиенты.
Такие идентичности не попадают в IAM-реестр, не ротируются и не отзываются при увольнении сотрудника или смене проекта. Для злоумышленника shadow identity — удобная дверь, для аудитора — красный флаг.
Когда NHI становятся угрозой
Риск переходит в угрозу, когда NHI получают доступ к критичным данным без адекватного контроля. Классические примеры:
- сервисный аккаунт с правами администратора в облаке, ключ которого оказался в публичном репозитории;
- CI/CD-токен, не отозванный после увольнения инженера;
- AI-агент, которому выдан широкий доступ к CRM «на время теста», а затем забытый.
В каждом случае ущерб многократно превышает затраты на внедрение современного управления NHI. Поэтому вопрос не в том, нужно ли управлять NHI, а в том, насколько быстро компания это сделает.
Вывод
Non-Human Identities — это уже не «техническая деталь», а фундаментальный элемент корпоративной инфраструктуры. Их количество, эфемерность и способность к делегированию делают классическое управление учётными данными неэффективным. Компании, которые осознают масштаб проблемы и начнут внедрять стандарты Agentic IAM, снизят риски и подготовят почву для безопасного роста агентных систем.
