Почему нечеловеческие идентичности стали главным вектором атак в облаках
По данным SC Media, тема workload identity и non-human identity в облачных средах за последние дни вышла в топ инфополя — параллельно на ту же проблему высказались Oracle и SentinelOne.
Владислав Донской·обновлено 28 сентября 2026 г.

Когда сразу несколько крупных вендоров одновременно поднимают один и тот же вопрос, это не совпадение: где-то уже обожглись, и индустрия теперь пытается понять, как прикрыться. Типичная история — у среднего облачного проекта машинных учёток больше, чем живых пользователей, а управляются они по остаточному принципу.
Почему NHI уже главный слой, а не «ещё один»
SC Media в материале от 25 сентября относит workload identity и нечеловеческие идентичности к ключевым проблемам облачной безопасности — и это не преувеличение. Служебные учётки Kubernetes, токены пайплайнов CI/CD, ключи HashiCorp Vault, сертификаты service mesh, API-ключи интеграций — всё это NHI. В зрелом облаке их количество на порядок превышает число живых пользователей, а жизненный цикл превращается в отдельную боль: выдано в 2022-м, забыто в 2024-м, реально дёргается третьим микросервисом, о котором в команде уже никто не помнит.
Вектор здесь максимально банальный. Старый токен из пайплайна коммитится в репозиторий, через полгода кто-то находит его в git history, токен всё ещё валиден, секрет утекает через публичные логи в Telegram-каналы. Никакой экзотики — просто ошибка конфигурации: длинный срок жизни секрета, отсутствие ротации, раздутые policies. Всё это превращает NHI в самый дешёвый вектор первичного проникновения, который любая red team возьмёт первой строкой в плейбуке.
Oracle: Workload Identity для тех, кто держит k8s на своих плечах
Oracle в блоге от 24 сентября сообщает о включении поддержки Workload Identity для Self-Managed Kubernetes в OCI. Функциональность позволяет workload в кластере получать короткоживущую идентичность от облачного провайдера без долгоживущих секретов в манифестах и ConfigMap. По сути — реализация того же паттерна, что AWS IRSA и GCP Workload Identity, только в экосистеме Oracle.
Задержка с выходом фичи показательна: Oracle догоняет по важному куску cloud-native стека, который конкуренты закрыли ещё в 2021–2022 годах. Но для команд на OCI это реальный шаг к тому, чтобы «секретики в YAML» окончательно перестали быть нормой. Дальше вопрос — дотянут ли они это до уровня, который уже есть у AWS и GCP, или сделают «как обычно, лишь бы в roadmap было».
SentinelOne Wayfinder: identity как новая плоскость EDR
Help Net Security 25 сентября пишет, что SentinelOne расширил покрытие Wayfinder — теперь продукт закрывает не только эндпоинты и облачные workload'ы, но и идентичности. Вендор объединяет в одной консоли наблюдение за живым входом (человек) и машинным входом (сервис-аккаунт, токен, workload). Фактически это попытка склеить EDR и CIEM в одно решение, чтобы SOC видел аномалии и от пользователей, и от машин в одном дашборде.
Идея правильная — фрагментация между Cloud Detection, IAM-аудитом и EDR уже давно мешает нормальному расследованию инцидентов. Вопрос в том, не превратится ли «единая плоскость» в ещё одну платформу, в которой вместо ответа SOC получает ещё один дашборд с красивыми графиками и нулём полезного сигнала.
Что делать, пока вендоры догоняют
Практический минимум для команд, которые не собираются покупать маркетинговый буклет про «военный уровень шифрования»:
1. Полная инвентаризация NHI. Все ключи, токены, сертификаты с любыми permissions в облаке — в одну таблицу. Без инвентаря всё дальнейшее — карго-культ.
2. Короткоживущие секреты. Service account token, привязанный к конкретному workload, а не к YAML в репозитории. Если токен живёт дольше пайплайна, который его запросил, вы уже в зоне риска.
3. Автоматическая ротация и отзыв. Без Terraform/Ansible-job, который сам убивает ключи старше N дней, ничего не работает. Ручная ротация — иллюзия безопасности.
4. Мониторинг аномалий. Если сервисная учётка внезапно открывает порты в S3, о которых в команде не знали, это событие, а не строка в логе. SIEM должен это видеть как алерт, а не как info.
5. Минимальные scope. Не выдавать permissions «на всякий случай». Это главная причина, по которой NHI превращаются в точку входа. Конкретный scope под конкретную задачу — единственный рабочий вариант.
И да, раз уж речь о SOC: операторы, не забывайте про собственное состояние — многосуточные incident response выжигают быстрее, чем хочется думать. Складной велотренажёр для домашних тренировок не спасёт от утечки, но хотя бы снизит шансы на инфаркт в третью ночь дежурства.