С ростом автоматизации владельцы облачных инфраструктур всё чаще сталкиваются с угрозами, которые исходят от ботов, парсеров, агентов, сервисных и других подобных автоматизированных аккаунтов. По данным Google Cloud Threat Horizons Report, эксплуатация злоумышленниками таких непользовательских сущностей (или non‑human identities, NHI) остаётся в топе угроз, при этом тактики атак постоянно усложняются.
В ответ на это некоммерческая организация OWASP в 2025 году выпустила отдельный рейтинг по топ-10 атак для NHI: OWASP Non‑Human Identities Top 10.
Меня зовут Дмитрий Лютов, я занимаюсь продуктами безопасности в Yandex Cloud и в этой статье я пройдусь по основным угрозам из рейтинга OWASP. Покажу, каким образом владельцы облаков могут позаботиться о безопасности инфраструктуры.
NHI1:Improper Offboarding
В чём угроза. NHI часто создаются внутри организации, например, в виде системных агентов или сервисных аккаунтов, от имени которых управлять ресурсами можно посредством скриптов и других программных средств. И если для пользовательских аккаунтов есть понятные правила управления жизненным циклом учётных записей, то для сервисных аккаунтов это сложный и часто дорогой процесс.
Нередко бывает так, что части приложения или сервиса становятся неактуальными, а связанные с ними сервисные аккаунты в компании забывают удалить, или вообще забрасывают, например, если ответственный сотрудник уволился. Злоумышленники могут специально сканировать ресурсы в поисках забытых ключей от таких аккаунтов.
Как защититься?
Эксперты OWASP рекомендуют включить в процесс увольнения сотрудников обязательный шаг, на котором проверяются все связанные с уходящим специалистом сервисные аккаунты. На практике это не всегда реализуемо в таком виде. Но для снижения риска можно, например, автоматически отслеживать дату последней аутентификации сервисного аккаунта и через определённое время удалять неиспользуемые.
Вести учёт и проводить аудит имеющихся NHI, мониторить их использование и следить, чтобы у каждой такой сущности был свой владелец.
Регулярно проводить ротацию ключей или использовать короткоживущие токены — об этом мы ещё поговорим дальше.
Наш опыт. В нашем облаке разработан Стандарт по защите облачной инфраструктуры Yandex Cloud, который содержит рекомендации по конкретным мерам защиты от существующих угроз. Для упрощения аудита NHI пользователям облака в консоли мы предоставляем дополнительную информацию о времени последнего использования сервисных аккаунтов и ключей для них.
NHI2:Secret Leakage
В чём угроза. Проблема в том, что ключи, токены от сервисных аккаунтов и другие подобные секреты не подразумевают защиты с помощью многофакторной аутентификации. Поэтому их хранение где‑либо в открытом виде чревато утечкой — а на практике такое встречается в конфигурационных файлах или в логах. Также бывает, что разработчики могут захардкодить креды и выложить в репозитории или передать их через общедоступные мессенджеры.
Как защититься? Здесь правила те же, что и с другими секретами:
Использовать временные учётные данные — секреты, которые можно сгенерировать по требованию на короткий срок.
Хранить в секретницах. Для контейнерных сред себя зарекомендовал HashiCorp Vault (а для нашего облака мы, конечно же, напомним про Yandex Lockbox).
Автоматизировать обнаружение учётных данных с помощью сканеров секретов.
Ограничить области действия и права доступа к секретам. Поможет принцип наименьших привилегий (PoLP), а также управление доступом на основе ролей (RBAC) для обеспечения гранулярного контроля прав.
Регулярно ротировать секреты.
Наш опыт. Пользователям нашего облака доступен сервис, который ищет утечки ключей и токенов и автоматически уведомляет об этом — коллеги уже писали подробнее, как устроен такой поиск в этой статье. Также сканер секретов доступен в модуле контроля данных (DSPM) в рамках сервиса для комплексного управления безопасностью Security Deck.
Механизмы IAM (Identity and Access Management) позволяют заменить долгоживущие креды для сервисных аккаунтов сразу несколькими способами:
Подробнее все способы получения IAM‑токена для сервисных аккаунтов Yandex Cloud описаны в документации.
NHI3:Vulnerable Third-Party NHI
В чём угроза. В мире разработки многие решения переиспользуются, и программисты могут применять сторонние расширения для своих IDE. Часто это требует значительных прав на машине разработчика — включая возможность читать исходный код, получать доступ к переменным окружения, взаимодействовать с другими системными ресурсами, в том числе с помощью чувствительных данных. Соответственно, любая уязвимость в таком расширении повышает риск атак на цепочку поставки.
Как защититься?
Проверять и ограничивать сторонние интеграции в IDE. Предоставляйте доступ только к необходимым ресурсам и отзывайте его при завершении работы.
Мониторить активность сторонних сервисов. Поможет инвентаризация всех интеграций и выданных им разрешений, а также регулярный аудит.
Использовать ротируемые учётные данные. Так, в нашем стандарте мы рекомендуем ротировать ключи минимум раз в 90 дней.
NHI4:Insecure Authentication
В чём угроза. Некоторые методы аутентификации устарели, уязвимы к известным атакам или считаются ненадёжными из‑за использования устаревших практик обеспечения безопасности. Например, OAuth Implicit Flow и Authorization Code Flow без PKCE, которые сейчас считаются deprecated и содержат серьёзные уязвимости.
Как защититься?
Использовать современные стандарты аутентификации: OAuth 2.1 и OpenID Connect (OIDC).
Использовать ограниченные по времени и скоупу учётные данные.
Избегать кастомных реализаций протокола OAuth, отклоняющихся от спецификации.
Проводить регулярные аудиты безопасности, чтобы выявлять и устранять устаревшие конфигурации.
Наш опыт. В Yandex Cloud используется несколько типов аккаунтов и соответственно несколько методов аутентификации:
Сервисные аккаунты, у которых есть несколько видов ключей: API‑ключи, авторизованный ключ для обмена на IAM‑токен, статический ключ для AWS‑совместимых API. Первое, что мы рекомендуем здесь пользователям — использовать методы получения IAM‑токенов, не требующие создания ключей.
Федеративный аккаунт — это рекомендованный способ аутентификации пользователей, при котором используется сторонний Identity Provider.
Федерация сервисных аккаунтов (Workload Identity Federation), которая по умолчанию не предусматривает создания долгоживущих ключей. Этот метод основан на протоколе OpenID Connect (OIDC) и может быть использован, когда необходимо обращение к API облака из внешних сервисов, таких как GitHub/k8s или других облаков. Он предполагает обмен JWT‑токена на IAM‑токен, всегда имеющий ограниченный срок и скоуп. Этот вариант считается наиболее безопасным.
Также мы используем PKCE для аутентификации в наших публичных OAuth‑клиентах (например, Yandex Cloud CLI) и DPoP для дополнительной защиты refresh‑токенов.
NHI5:Overprivileged NHI
В чём угроза. Сервисные аккаунты с правами доступа шире, чем это необходимо для выполнения функций, несут угрозу расширения потенциального масштаба ущерба в случае компрометации. Злоумышленники могут использовать избыточные привилегии для:
Доступа к конфиденциальным данным: несанкционированного получения файлов, содержимого баз данных или пользовательской информации.
Эскалации привилегий: получения более высокого уровня доступа, вплоть до административного или root‑доступа.
Горизонтального перемещения: доступа к другим системам и сервисам внутри корпоративной инфраструктуры.
Развёртывания вредоносного ПО: установки шифровальщиков и инструментов удалённого доступа (RAT).
Полного захвата облачного аккаунта: в случае утечки NHI, связанного с root‑учётной записью или облачным администратором, возможен полный захват управления над облачной инфраструктурой.
Как защититься?
Использовать принцип наименьших привилегий (PoLP): в особенности избегать административных прав, если в них нет обоснованной необходимости.
Внедрять защитные ограничения (guardrails): запрещающие политики на уровне организации для исключения избыточных конфигураций.
Использовать доступ по требованию (Just‑in‑Time, JIT): инструменты, обеспечивающие временное и контролируемое повышение привилегий.
Наш опыт. Для аудита прав сервисных аккаунтов в Yandex Cloud в Security Deck реализован CIEM‑модуль «Диагностика доступа».
С его помощью можно анализировать пользовательские роли в одном месте, в разрезе конкретных пользователей и групп.
В нашем стандарте мы также обращаем внимание пользователей на принцип минимальных привилегий для сервисных аккаунтов, а также даём рекомендации для защиты root-учётной записи.
NHI6:Insecure Cloud Deployment Configurations
В чём угроза. Инструменты CI/CD позволяют командам разработки автоматизировать процессы сборки, тестирования и развёртывания кода — но для интеграции CI/CD‑конвейерам требуется аутентификация в облачных сервисах. Небезопасной практикой считается использование в CI/CD‑конвейерах сервисных аккаунтов со статическими учётными данными.
Как защититься?
Использовать OIDC для безопасной аутентификации: заменить долгоживущие секреты на временные, динамически генерируемые токены с помощью OIDC и обеспечить строгую валидацию токенов, включая проверку
issuer,audienceиclaims.Соблюдать принцип наименьших привилегий: в том числе ограничивать доверительные отношения в IAM‑ролях и конфигурациях OIDC.
Избегать хардкодинга чувствительных данных.
Наш опыт. Для безопасного подключения к API Yandex Cloud из CI/CD‑систем мы также рекомендуем переходить на федерацию сервисных аккаунтов (Workload Identity Federation). Для пользователей популярных платформ разработки мы создали детальные рекомендации: для интеграции с GitHub, а также GitLab.
NHI7:Long-Lived Secrets
В чём угроза. На первый взгляд, кажется, что мы обсудили этот риск с точки зрения утечки секретов, однако компрометация долгоживущего ключа создаёт комбинацию угроз. Секрет с длительным сроком действия в случае утечки предоставляет злоумышленнику неограниченный по времени доступ к чувствительным сервисам.
Как защититься?
Включить автоматическую ротацию ключей. Это в том числе снизит человеческий фактор.
Использовать короткоживущие учётные данные: подойдут механизмы для создания учётных данных, которые автоматически истекают и обновляются после выполнения конкретной задачи.
Применять принципы Zero Trust: требовать повторной аутентификации для NHI, получающих доступ к чувствительным ресурсам или выполняющих действия повышенного риска.
Придерживаться принципа наименьших привилегий (PoLP).
Наш опыт. В нашем облаке мы регулярно напоминаем пользователям о важности перехода на короткоживущие IAM‑токены. Рекомендуем не применять долгоживущие ключи там, где это возможно, и в качестве альтернативы использовать получение токенов через метаданные виртуальных машин или функций, а также имперсонацию или WLIF.
Если ограничить срок жизни секретов возможно не везде, важно проводить регулярные ротации долгоживущих ключей. В консоли мы показываем пользователям дату последнего использования ключей сервисных аккаунтов, это упрощает их регулярную ротацию.
NHI8:Environment Isolation NHI
В чём угроза. Общепринятая практика в разработке — использование разделённых окружений: dev, тестирование, предпродакшн и продакшн. Однако если при этом повторно используются одни и те же сервисные аккаунты в нескольких средах — особенно между тестовой и продакшн‑окружением, — это может привести к серьёзным инцидентам. Если сервисный аккаунт, применяемый в менее защищённой тестовой среде, также имеет доступ к продакшн‑ресурсам, то в случае компрометации тестовой среды злоумышленник сможет использовать NHI для проникновения в продакшн‑среду.
Как защититься?
Использовать уникальные NHI для каждой среды: cервисные аккаунты, ключи и т. п. Назначайте отдельные идентификаторы для каждой среды (dev‑, test‑, prod‑), чтобы исключить случайности.
Применять принцип наименьших привилегий (PoLP): минимально необходимые права должны соответствовать задачам в конкретной среде.
Реализовать средоспецифичные политики доступа: явно запретить сервисным аккаунтам вне прода иметь доступ к продакшн‑ресурсам.
Проводить периодический аудит и мониторинг: отслеживать активность сервисных аккаунтов на предмет несанкционированных попыток доступа или аномального поведения.
Дополнительно изолировать инфраструктуру для чувствительных ресурсов: использовать отдельные ресурсные группы, подписки или аккаунты для изоляции от других сред. Это позволяет ограничить «радиус поражения» даже в случае компрометации одного из аккаунтов.
Наш опыт. CIEM‑модуль для диагностики доступа в Security Deck может помочь и в этом случае. С его помощью можно определить, к каким ресурсам имеют доступ сервисные аккаунты, и отозвать их, если это необходимо.
NHI9:NHI Reuse
В чём угроза. Помимо уже перечисленных проблем, связанных с повторным использованием сервисных аккаунтов в разных средах, можно также столкнуться с переиспользованием их для разных приложений. Ко всему сказанному добавим то, что повторное использование сервисного аккаунта затрудняет реагирование на инциденты и может усложнить проведение аудита безопасности.
Изоляция NHI позволяет локализовать потенциальные инциденты и предотвратить горизонтальное перемещение злоумышленника внутри инфраструктуры.
Как защититься?
Использовать уникальные NHI в каждом приложении и в каждой среде. Аутентификация с использованием этого NHI должна быть возможна только из соответствующего компонента.
Применять принцип наименьших привилегий (PoLP).
Проводить аудит и ревизию использования NHI, включая предоставленные им права доступа и назначенные системные компоненты.
NHI10:Human Use of NHI
В чём угроза. На этапах разработки и сопровождения приложений разработчики или администраторы могут неправомерно использовать сервисные аккаунты для выполнения ручных задач, которые по правилам должны выполняться от персональных учётных записей с соответствующими правами доступа. Такая практика создаёт серьёзные риски безопасности, включая:
Превышение уровня привилегий, необходимого для выполнения задачи.
Отсутствие детализированного аудита действий.
Смешение активности людей и автоматизированных процессов.
Усложнение выявления действий злоумышленников.
Как защититься?
Использовать персональные учётные записи с ограниченными правами. Для отладки и обслуживания лучше использовать персональные учётные записи с чётко определёнными ролями и правами.
Анализировать и отслеживать активность NHI. Использовать инструменты и платформы, обеспечивающие мониторинг использования NHI, чтобы различать и фиксировать случаи ручного доступа к ним.
Применять контекстно‑зависимые политики доступа. Условные политики доступа способны обнаруживать и блокировать попытки доступа к NHI с признаками ручного использования (например, доступ из браузера, отсутствие автоматизации).
Обучать разработчиков и администраторов по поводу рисков ручного использования. А также предоставлять альтернативные методы доступа, соответствующие требованиям безопасности.
Наш опыт. С помощью сервиса Audit Trails мы можем мониторить активность сервисных аккаунтов и отслеживать подозрительные сценарии, когда они используются не по назначению.