Возьмём типичную IT-компанию со штатом в 100 человек. Как думаете, сколько учётных записей существует в их облачной инфраструктуре? 150? 200?

В действительности — около 2000.

И самое удивительное, что только десятая часть из них принадлежит реальным людям. Остальные — это боты, сервисные аккаунты, API-ключи, агенты ИИ, токены CI/CD систем. Они работают 24/7, имеют доступ к критичным данным и почти никогда не попадают в фокус отделов безопасности.

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

Несколько цифр:

• 51% специалистов по безопасности считают угрозу от NHI равной угрозе от компрометации человеческих аккаунтов

• В облаках нечеловеческих идентификаторов в 10-20 раз больше, чем людей

• Месяцы — типичное время, которое проходит от компрометации NHI до её обнаружения

Вся индустрия кибербезопасности заточена под защиту людей. MFA, SSO, биометрия, анализ поведения пользователей — всё работает отлично. Для людей. А боты остались без должного внимания и контроля.

Что такое Non-Human Identity

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

В облачной инфраструктуре их много:

Сервисные аккаунты — учётки, под которыми работают приложения. Контейнер в Kubernetes, подключение к базе данных, облачная функция — всем нужна своя идентичность.

API-ключи и токены — ключи для доступа к API. Лежат в переменных окружения, конфигах, иногда в системах управления секретами, а иногда... в git-репозиториях.

SSH-ключи — для автоматического доступа к серверам. CI/CD без них не работает.

OAuth токены — приложение обращается к внешнему сервису от имени пользователя или от своего имени.

CI/CD credentials — токены систем непрерывной доставки. Обычно с очень широкими правами, потому что «надо деплоить в прод».

Боты и автоматизация — скрипты по расписанию, webhooks, планировщики задач.

AI-агенты — новый и быстрорастущий класс. LLM-системы, автономные агенты, которые принимают решения и выполняют действия. Часто с очень широкими правами «для гибкости».

Главное отличие от аккаунтов людей в том, что NHI живут по другим правилам:

• У человека есть двухфакторка. У бота — статический токен.

• Человек меняет пароль раз в квартал. Токен бота не меняется годами.

• Человек работает 8 часов в день. Бот — 24/7.

• Активность человека мониторится SIEM. Активность бота — «технический шум».

• Токен человека живет часы. Токен бота — месяцы или вообще бессрочно.

В чём проблема

Когда сотрудник логинится, он проходит проверки: двухфакторка, иногда включающая биометрию, проверка на подозрительную активность.

А у бота есть токен, созданный когда-то давно. Этот токен не требует MFA, может быть скопирован, куда угодно, работает, откуда угодно, и имеет те же права, что были выданы при создании.

Представьте себе классическую ситуацию: разработчик создаёт API-ключ «для тестирования на пару дней». Даёт ему широкие права, чтобы «точно всё работало». Тест проходит, ключ остаётся в конфиге и забывается. Через полгода разработчик увольняется. Ключ живёт дальше. О нём никто не помнит.

Невидимки в системах мониторинга

SIEM ищет аномалии в поведении пользователей. Логин ночью? Странно. Доступ из другой страны? Подозрительно. Неудачные попытки входа? Алерт.

Но сервисный аккаунт всегда активен ночью — это норма. Он всегда ходит к одним ресурсам — это его работа. Он генерирует один и тот же трафик — это ожидаемо.

Злоумышленник с украденным токеном выглядит как легитимный сервис. Перемещение по инфраструктуре через учётные записи почти невидимо. Месяцы незамеченной активности — обычная история.

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

Экспоненциальный рост в облаке

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

В облаке всё иначе:

• Каждый контейнер может создавать новый NHI

• Автомасштабирование = размножение учётных данных

• Бессерверные функции плодят роли выполнения

• Микросервисная архитектура = десятки сервисов, каждый со своими токенами

• Kubernetes создаёт сервисные аккаунты автоматически

У компании с 50 разработчиками запросто может быть:

• 150-300 сервисных аккаунтов в Kubernetes

• 500+ паролей и ключей

• Сотни IAM в облаке

• Десятки баз данных пользователей 

• API-ключи для интеграций

• SSH ключи в CI/CD

Больше тысячи NHI. И число растёт с каждым новым микросервисом.

Никто не знает полной картины

DevOps-инженеры обычно не могут точно сказать, сколько сервисных аккаунтов существует в боевом окружении. Учётные данные разбросаны по оркестраторам контейнеров, системам управления секретами (если таковые вообще есть), переменным окружения, конфигурационным файлам, CI/CD системам. Они лежат в git-репозиториях, в корпоративной базе знаний, на общих дисках.

Единого реестра нет. За большинство токенов никто конкретно не отвечает. Полную картину не видит никто.

Когда разработчик увольняется, его личный аккаунт блокируют, почту отзывают, ноутбук забирают. Но все API ключи, которые он создал за время работы, все сервисные аккаунты, которые он настроил, все токены в CI/CD, созданные для тестов — всё это продолжает работать. О них просто забывают.

Как это эксплуатируют

Учётные данные утекают проще, чем кажется. Вот самые распространенные сценарии.

Публичные репозитории — золотое дно для атакующих. Разработчик работает локально, добавляет API ключ в конфигурационный файл для теста. Фиксирует изменения. Забывает исключить файл из системы контроля версий. Учётные данные попадают в репозиторий. Автоматические сканеры находят это за минуты и начинают эксплуатировать.

Пароли и токены в логах. Разработчик добавляет вывод токена в отладочные сообщения «для проверки». Логи попадают в централизованную систему, сохраняются в резервных копиях, хранятся месяцами. Учётные данные остаются там практически навсегда.

Конфигурационные файлы в открытом виде. Пароли прямо в YAML. «Это же внутренний репозиторий» — до первой компрометации любого аккаунта с доступом.

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

Избыточные права

Сервисному аккаунту часто дают больше прав, чем нужно, «чтобы точно работало».

Сервисная учётная запись получает права администратора всего кластера, хотя нужно развёртывать всего одно приложение. Пользователь базы данных имеет доступ ко всем таблицам, когда реально нужны только две. Ключ программного интерфейса создаётся с полным доступом, хотя достаточно только чтения. Бот системы непрерывной доставки может заходить в боевое окружение, хотя работает только с тестовым.

Почему так происходит? «Так быстрее», «не хочу разбираться с правами», «потом ограничим». Но потом не наступает никогда.

Дальше — как по цепочке. Атакующий компрометирует систему непрерывной доставки через фишинг, получает токен бота развёртывания с широкими правами. У бота есть доступ ко всем паролям. Через пароли атакующий добирается до учётных данных баз. В базе находит ключи внешних программных интерфейсов. И получает полный доступ.

CI/CD как золотая жила

CI/CD особенно привлекательны:

• Автоматический доступ 

• Выполняют код без участия человека

• Часто избыточные права «для удобства»

• Учётные данные хранятся в системе

В итоге разворачивается типичный сценарий: компрометация аккаунта разработчика с доступом к системе непрерывной доставки, внедрение конкурентного кода через запрос на изменения, подмена зависимостей или образов контейнеров.

AI-агенты: новая угроза

С распространением LLM появился новый класс проблем:

• AI-агенты с правами на выполнение действий в системе

• Автоматические помощники с доступом к базам

• Автономные системы, принимающие решения

• Интеграции с внешними AI-сервисами

Тут есть своя спецификация. Ведь ИИ можно обмануть с помощью внедрений в запросах — поведение непредсказуемо, права часто используются «для гибкости», сложно проверять решения, нет устоявшихся проверенных методов.

Что с этим делать

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

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

• Внедрите принцип минимальных привилегий доступа: назначьте средства управления доступом на основе ролей (RBAC) и установите политики истечения срока действия учетных данных по времени, чтобы гарантировать, что медицинские работники получают доступ только к необходимым ресурсам и в нужное время.

• Используйте преимущества доступа «точно в срок» (JIT) и временных паролей: исключите постоянный доступ, заменив статические учетные данные кратковременными токенами API. Кроме того, автоматизируйте обновление учетных данных после завершения задачи или по заданному расписанию.

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

Роль облачного провайдера

В управляемых сервисах ответственность распределяется. Вы контролируете: аккаунты своих приложений, API ключи интеграций, учётные данные в контейнерах, политики внутри приложений. Провайдер контролирует: системные компоненты, базовую аутентификацию, облачный IAM, мониторинг платформы.

Подход с управляемыми сервисами имеет смысл, когда:

• Нет выделенной безопасность команды

• DevOps перегружен

• Нужна экспертность в облачной безопасности

• Критично быстрое реагирование

• Хочется фокусироваться на продукте, а не на инфраструктуре

В Cloud4Y контроль NHI встроен в 24/7 мониторинг: автоматическое детектирование аномалий, zero-trust архитектура, управляемые Kubernetes и другие сервисы с безопасностью из коробки. Это позволяет вашей команде сосредоточиться на разработке.

Главное

NHI — это не завтрашняя проблема. Это сегодня. В вашем облаке прямо сейчас ботов в 10-20 раз больше, чем людей.

Традиционные инструменты безопасности не работают для ботов — они созданы для людей. Боты, AI-агенты и сервисные аккаунты требуют других подходов.

Месяцы незамеченной компрометации — норма при отсутствии мониторинга NHI.

Это постоянная работа, а не разовый аудит. NHI создаются автоматически каждый день.

Управлять тысячами идентификаторов вручную невозможно — нужна автоматизация.

Начните сейчас. Каждый день промедления — это ещё один день жизни забытого токена с правами администратора где-то в вашем облаке.